ESB product or integration bus pattern

Written by Chintan Rajyaguru

Tuesday, 12 May 2009 07:43

The world was a happy place when ESB was a pattern. We implemented the bus pattern using a combination of tools and technologies. Now, ESB is a product. And, if you are using IBM products, you have two of them: WebSphere Message Broker and WebSphere ESB.

Here is how webster.com defines 'bus': (1) a set of parallel conductors in a computer system that forms a main transmission path (2) a spacecraft or missile that carries one or more detachable devices (as warheads). Extending the thought to enterprise architecture, it is easy to infer that the bus should be used as the transmission path or as a carrier (typically of a message) to integrate separate systems. However, since we have ESB as a product, people throw it in anytime two systems or even two services have to talk. Here are some inappropriate uses of an ESB product:

Exposing a service using an ESB because the method signature in the EJB is not web service compatible
Using ESB because there is a need to send a copybook, a proprietary XML or any other message format and you don't want your application to be tightly coupled to that format
Using ESB between different layers of the application
Using ESB because some architect decided to use canonical message format

I am not saying having ESB as a product is a bad idea but just because we have a product, we often fail to analyze the architectural need for an ESB. This leads to product first and architecture second approach, which is a bad idea. This is specially important for an ESB because it usually ends up being a central piece to which everything is connected. A bad ESB architecture will negatively impact everything that is connected to it.

In my opinion, when you have identified the need for a bus, it is often helpful to think what kind of bus you need.

Do you need to expose business services through the bus? You need a service bus
Do you need to send and receive messages, and in the process, need to validate, route or transform them? You need a messaging bus
Do you have too many applications talking to one another directly resulting in an integration spaghetti? You need an integration bus
Do you have too many sources of data in different shape, form and structure? Do you have large amounts of data moving between places but you need to improve the quality of the data before it can be delivered to the target? You need a data bus. Although the data bus is not a widely recognized concept, as an architect who comes from the middleware background, it helps me to think in terms of data bus so I can recommend a data integration solution as opposed to building services that simply move data around

Once you know what kind of bus you need, you can identify the technology that supports the bus and once the technology is known, you can select the product. This approach will lead to a more appropriate selection of the product that implements the bus pattern. There is an excellent redbook, which addresses this topic. It explains how the bus can be implemented as a pattern using different products. I can't find it anymore on ibm.com/redbooks.

Comments

Add New