Enterprise Service Buses from IBM

IBM has recently announced the IBM WebSphere Enterprise Service Bus. To be able to understand this announcement I first had to understand what IBM meant by the term ‘Enterprise Service Bus’ (ESB). Searching on ‘IBM ESB Pattern’ took me directly to a succinct, clear and comprehensive article that defines an ESB pattern.

According to this article an ESB connects ‘consuming services’ to ‘providing services’ without the need for either end to know the physical location, protocol or implementation of the other end, whilst still being able to agree the quality of service delivered. To accomplish this, the ESB is made up of the following parts:

• Service Interface Points (SIP) where the service connects to the bus.
• Mediation services that switch protocols, and transform, enrich, route, distribute, monitor and correlate messages.
• A registry that contains metadata definitions of all the services connected to the ESB to enable registration, discovery and deployment of the services.

The article then goes on to describe different deployment patterns. At this point I realised that the use of the word ‘enterprise’ is less than helpful as it is perfectly possible, and in fact likely, that one enterprise will have multiple ESBs. Although there may be technical reasons for setting up multiple ESBs, the primary reason will be business related. A single ESB will have a single registry and any service attached to it will have access to all other services defined in the registry. Enterprises tend to have organisational units that have limited spans of control and are relatively autonomous of each other. The number and relationships of the ESBs need to reflect the organisational structure of the enterprise.

The article identifies four deployment patterns: global, directly connected, brokered and federated that reflect different levels of autonomy and control. A global ESB has a single registry and all services are visible and available to all. The other patterns have multiple registries and define how the information in them can be shared across the different ESBs.

The one thing that the article does not describe is the possible physical topologies of an ESB. It is important to understand that the SIPs, mediation services and the registry could all be implemented on a single node but equally these parts could be distributed across multiple nodes in multiple locations. The only constraint is that all the parts of an ESB share the same registry.

This is just a brief resume of the article and I would recommend that you read the whole article plus other articles on SOA in the series.

Using this pattern it becomes much easier to explain what IBM WebSphere ESB supports. It supports a subset of the capabilities of the ESB pattern:

• The service integration points provide support for the standard Web Services stack, for JMS and the WebSphere Adapters. This is not as comprehensive as WebSphere Message Broker which will remain the any-to-any protocol converter.
• It provides a broad range of mediation services to transform (using XSLT), enrich (with facilities to make external calls to databases and other functions), route (using XPATH to decide on the routing), and monitor (with logging functions and connections to Tivoli) messages. All of the mediation requires that the message is in an XML format.
• It includes a UDDI 3.0 registry which enables all the services connected to the bus to be defined and discovered.
• It is built on top of the IBM WebSphere Application server which provides all the clustering support. This means that an ESB and its registry run in a single cluster.
• It only provides support for a global ESB; other ESBs are seen as external services. This means that a message flow across multiple ESBs cannot be defined or monitored as a whole.
• Its development environment uses visual development techniques and defines different roles, so the progression from business analyst to production administrator is well defined and complete.
• It is the basis for another new product—the WebSphere Process Manager—that enables business processes, including human interaction, to be implemented.

This first release of WebSphere ESB has all the basic building blocks that are needed to implement production-strength service-to-service connection and mediation. The fact that it can only support the global ESB pattern means that solutions whose scope crosses ESB boundaries will require some less automated help and careful architecture design. This is a pragmatic release that provides a standards-based ESB infrastructure for implementing SOA solutions.