1. Introduction
First things first. At the time of this writing (2009) and for the past few years, there has been a big controversy about what exactly an ESB is. There are largely two opposing camps:
- ESB is a concrete instance of a SOA where some standardized ways of invoking services are implemented, enterprise wide.
- ESB is a software product, that connects different technological applications together.
The first approach is an interpretation where an Enterprise Architecture is introduced, relying on SOA principles. An ESB then is SOA as required by and seen from the perspective of a single company. Where SOA could be more general spanning different companies and service providers - e.g. a social networking site A relying on a service implemented and hosted by another company B for SMS messages and company C for backup etc.
The second approach is the one favored by EAI vendors who sell a product, often relying on messaging systems - MoM . For a few years now, this last interpretation seems to win the upper hand. Big marketing efforts might have something to do with this. On the other hand, an integration effort that promises leveraging existing (legacy) applications and related investments, has its own merits of course.
One difference between both approaches is that in a EAI approach, communication flows in both directions.
Personally, I prefer the first approach, since I believe this empowers the enterprise (customer) and not the vendor.
An article about this subject summarizes some of these concerns. Incidentally, the article was edited to reflect the fact that IBM still thinks their ESB offerings are OK - which shows the entire ESB concept has a lot of controversies...
An increasingly common request from clients is to complete a project that does not use SOA as a whole, but instead implements only an enterprise service bus (ESB) architecture. Such an ESB-oriented architecture is easy to envision, but its success is difficult to measure. What clients requesting such projects don't understand is this: An ESB-oriented architecture doesn't produce business value. A project based on ESB-oriented architecture needs to be made into one based on SOA to help ensure that it successfully delivers business value.
I found a very good definition that would cover both ideas in an article on the ServiceMix website:
The Enterprise Service Bus (ESB)- which can be defined as middleware that brings together both integration technologies and runtime services to make business services widely available for reuse - offers the best solution for meeting today's enterprise application integration challenges by providing a software infrastructure that enables SOA.
I think the main business value comes from the promise to write or reuse software and integrate them easily, as any "appliance" you plug in to your personal computer, such as USB keys, digital cameras and cell phones. My personal attempt at an informal definition then, would be:
An ESB is an architecture or software product that envisages a pluggable enterprise architecture - where services and applications can be plugged in and work together easily.
2. An Example
Let's take a look at an ESB from a more concrete point of view.
This example is mainly provided as an illustration on how different components in an ESB work together. It is not a complete solution...
2.1. Introduction
Imagine a company producing and selling goods. They have sales people visiting customers looking up information about their customers, offering quotes, registering orders. There is a financial department doing the billing, detecting overdue payments, reporting revenue and cost to management. These business activities are supported by different applications.
Now look at the particular use-case of salesman who just entered the data for a new order, on his laptop in the offices of the customer. The order can be printed and sent by mail - or in a PDF-format by e-mail - together with service contracts etc.
His laptop shows a web application in a browser, his browser connects to the application running on a server of his company, the application is plugged into the ESB and uses the "Printing Service" to generate and send the documents to the customer.
2.2. Consumer
Consumer in this context means "consumer of the provided services".
The user hits a button in his web browser, a JSP is invoked, and this uses the ESB to send a message to the printing service, typically the payload of that message would be XML in a format favored by that web application. This message is the green one in the illustration.
An important difference with a basic, plain SOA is that our web application does not need to know about the actual format used by the service, it still has to send sufficient data though. It does not need to know about the location of the server that hosts the service, only about how to contact the ESB. Even if the application uses a multitude of services on different hosts, it only needs to know one address: that of the ESB.
2.3. Provider
The Printing Service receives a message from the ESB to generate some documents, print them and send them by mail (more probably print them on a dedicated printer...). This message arrives as XML containg the necessary data to perform these tasks, in a format favored by that service , possibly a different format to the one that was sent initially. This message is the blue one in the illustration.
2.4. Functions
Our ESB receives the original message from the web application (Consumer), determines by the origin in what format it is. Extracts information about which kind of service is required and determines which service to use. Next, the ESB determines which format is expected by the concrete selected service, then transforms the incoming message (green) to the format of the service and invokes the service with the transformed message (blue).
This course of events shows some internal functions of our ESB: routing and mediation. A typical ESB might offer much more functions, but this will do for the moment. These functions are represented as the black boxes in the illustration.
Let's look a little more into the routing function. The consumer requests a service invocation with some data. But it only specifies what kind of service: "print". The ESB also offers a management console or application that allows for configuration of the routing (and mediation) function. You could introduce logical rules ("if application 'crm' requires printing, then select 'any PrintingService, version 123' on host 'SERVER002 or SERVER005'") or hard wire the routing information ("if application 'crm' requires printing, then select 'PrintingService001' on host 'SERVER002'").
The mediation function is often implemented using XSL-T , for each possible transformation, an XSL-T document must be provided so that an incoming message can be transformed into the format required by the invoked service. This XSL-T document is the red one in the illustration.
