|
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.
|
