Architect Consultant blog

This was a presentation given by Mark Richards and describes the role of an ESB and particularly what it provides. It is an old presentation (23 oct 2006) but still very true, in the fact that there are still a lot of different definitions of an ESB within the world. This is a short recap of this presentation. Capabilities He emphasizes that we need to understand the capabilities of an ESB. The capabilities are defined from an architectural context and he first explains why an ESB is used (loose coupling, agility, location transparency, services reuse, separate business services from service providers). The following core capabilitities are described. Note that not all capabilities need to be present within the ESB, but only use the one the customer needs. Next the capabilities are described in short. Routing The ability to channel a request to a particular provider based on routing criteria (types are: deterministic, content-based, policy-based, complex rules-based). Message Transfor

The NodeManager is an important part of a weblogic server and this blog will give a short introduction and more detailed information on system administration can be found here . Node Manager is a WebLogic Server utility that enables you to start, shut down, restart, and monitor remote WebLogic Server instances. To enable these capabilities, you run an instance of Node Manager on each physical machine in your domain. WebLogic Server provides two versions of Node Manager, Java-based and script-based, with similar functionality. However, each version has different configuration and security considerations. Java-based Node Manager runs within a Java Virtual Machine (JVM) process (start as a service). BEA provides native Node Manager libraries for Windows, Solaris, HP UX, Linux on Intel, Linux on Z-Series, and AIX operating systems. A script based version is provideded for UNIX and Linux systems. This script is based on UNIX shell scripts, but uses SSH for increased security. SSH uses user

See here The bottom line: "The full integration of the BEA products into Oracle's middleware will not come out until somewhere in 2009" Gartner analysts recommend waiting for Oracle Fusion Middleware (OFM) 11g, due in the next six to 12 months.

This is the first blog in a series about WebLogic JMS (WLS 10.0). Full description can be found here . The Java Message Service (JMS) is a standard API for accessing enterprise messaging systems. WebLogic Server is compliant with the Java Platform, Enterprise Edition (Java EE) Version 5.0 specification and fully compliant with the JMS 1.1 Specification and can be used in production. The major components of the WebLogic JMS are: JMS servers that hosts a set of modules and any associated persistent storage that reside on a WebLogic Server instance. JMS modules contains configuration resources conform the weblogic-jmsmd.xsd schema. JNDI (Java Naming and Directory Interface), which provides a resource lookup facility. JMS resources such as connection factories and destinations are configured with a JNDI name. WebLogic persistent storage (file store or JDBC-accessible) for storing persistent message data. Messaging Models JMS supports two messaging models: point-to-point (PTP) and pu

I came across a good article about what XA transactions here.

This item is about a CDM a.k.a CMM (Common Message Model) on the Bus, why is it wise and how can it be done. First of all when you face a integration challenge the systems to be integrated are heterogeneous and use different data models (syntactically and semantically). So the data needs to be mapped from requester data to provider data. 1) Direct mapping, this results in n * m mappings (n=#requestors, m=#providers) and is very costly when a new provider or requester is added. 2) CDM, this results in n + m mappings A CDM gives you: Message consistency Message maintainability A CDM is a set of data representing the business entities used in all messages on the Bus. This does not mean that each provider or requestor uses the same set of messages but that the messages are all based on the same types. Possible implementations for CDM on ESB Option 1: ESB translates The requestor and provider keep their own models Only CDM is used on ESB Existing services do not have to be changed (especial

With M essage O riented M iddleware you can have several different communication mechanisms. The most common are Queues and Publish-Subscribe . Queues are mostly point-to-point, so therefore not loosely coupled, location-based addressing. What does Pub-Sub give you? Decoupling of Producers and Consumers Producers and consumers do not know each other Flexible number of producers and consumers Addressing Models With pub-sub there are a number of addressing models. Channel or Topic based Subject based Content based Concept based (not further described here, but tries to describe interest on a high level) Topic based addressing This is simple but less powerfull. Example JMS topics. You basically get every message that is published on a particular topic. However you have the possibility to set a filter when a subscription is taken that will filter the messages on attributes in the header of the JMS message. This is supported by BEA AquaLogic Service Bus. Subject based addressing It avoids t