Cicero Rautenbach

Currently, the only standards specification I can find for ESBs is the Java Technology Specification JSR 208 – Java^TM Business Integration (JBI).

This standard is closely tied to Java and J2EE/J2SE. This is perhaps not strange as almost all commercial and open source ESBs are developed using Java. As a matter of fact, I know of only one ESB product not based on Java technology; Microsoft’s BizTalk.

The architecture of JBI is interesting as a baseline for understanding ESB architecture using a common and well described terminology and to help you evaluate ESBs against each other using this common terminology, and not the vendor specific and bias terminology.

JSR 208 calls for 4 types of components making up the ESB:

• A Normalized Message Router (NMR) – ESB vendor supplied component that moves the payload (Normalized Message) between Service Engines and Binding Components.
• Service Engines (SE) – Components that does some useful work (transformations and/or business logic in the enterprise for example a SAP Service Engine allowing you to extract SAP data, an JDBC component allowing you to issue SQL calls to a relational database or an XSLT transformation component. The SEs can come from anywhere as long as they comply to the interface standards.
• Binding Components (BC) – Components that receive and send data outside the ESB for example a File Binding Component that will monitor a directory for changes and pick up new files for processing or an e-mail Binding Components. The BCs can come from anywhere as long as they comply to the interface standards.
• JMX based Administration tools supplied by the ESB vendor to manage the Normalized Message Router, deploy Service Engines and Binding Components and to manage the runtime life cycle (start/stop/end) of all components.

Communication between the Normalized Message Router and the Service Engines/Binding Components are based on a mediated message exchange based on WSDL (Web Services Description Language) and the 4 WSDL-defined Message Exchange Patterns (WEPs).

The Normalized Message Router is responsible for delivering the Normalized Message to the Service Engines (SE) and Binding Components (BC). The structure of the Normalized Message consists of the following parts:

• XML message
• Message context containing meta data about the message and data that may be used by Service Engines and Binding Components (key/value pairs)
• Attachments (normally binary and non-XML)

From what I could determine, only Apache ServiceMix, Bostech’s ChainBuilderESB and the Sun Community effort OpenESB are based on the JSR 208 specification. Many of the commercial ESB vendors participated in setting this standard. A lot of these vendors are now very negative about JBI and various blog entries can be found on their sites badmouthing JBI. This is somewhat understandable as the JBI architecture provides for a pluggable architecture where any component complying with the standard can be plugged in. The only components that the vendor have to supply are the Normalized Message Router and the JMX based administration tools. Any vendor’s components (Service Engines and Binding Components) can be plugged into the Normalized Message Router. This architecture does however have huge potential for providing professional services around the JBI compliant ESB.

My view is that the most likely pricing model for a JBI compliant ESB will be the base package (Starter Edition) consisting of the Normalized Message Router and Admin tools with a few basic (but important) Service Engines and Binding Components included. More complex and valuable Service Engines and Binding Components can be bundled with predefined bundles like the Work Group Edition, Enterprise Edition or SAP Edition. These components can also be priced individually. It is however very likely that customers will use Open Source Service engines and Binding Components. My suspicion is that this is really where vendors are making their money, and not on the base products thus making JSR208 compliancy unattractive for these vendors.

So how would I use the JBI architecture to evaluate a non-JBI ESB?

1) Binding Components – Look at the binding components available, the protocols supported and other software needed to make them work. Are there Binding Components available for the enterprise applications and databases you are using in the enterprise? How easy is it to create your own Binding Component when you need to do that. My list of basic Binding Components includes File System, Scheduler, JDBC, SMTP, FTP, SOAP and JMS.

2) Service Engines – What Service Engines are available and how do you develop and deploy your own. My list of basic Service Engines includes Transformation, Conversion (office documents to XML, ini files to XMLs etc.), JDBC gateways, JMS gateways, SOAP gateways, SMTP Gateways.

3) Look at the Normalized Message. Can binary attachments be handled? What happens if the only message you have is the binary document (no XML)? Are there Service Engines available to surface the contents of the binary attachments, for example extract the contents of an Excel spreadsheet into XML? Can you inspect the message context and do content based routing using it?

4) Distribution – How can Binding Components and Service Engines be distributed in the network to ensure high availability and load sharing. Can the Administration Components manage these distributed components.

5) What does the API look like to add Service Engines or Binding Components?

6) Normalized Message Router – How well does the Normalized Message Router perform?

Here is a list of all the ESBs I could locate. As a base definition for what an ESB is, I am using the definition as found on Wikipedia.

From my own experience of implementing solutions using the earliest ESB prototypes from late 1999 and early 2000 (yes, even before anybody coined the term ESB and before any services standardization) this definition is pretty accurate. It is also open for public discussion and moderation through the WikiPedia process.

The other source I found useful is the book “Enterprise Service Bus” by David Chappell (Publisher: O’Reilly Media, Inc.; 1st edition (June 2004) ISBN-10: 0596006756; ISBN-13: 978-0596006754). Although this book is now almost 4 years old, it is still valid and a useful resource.

WARNING: For some of these products you need a fair bit of imagination to recognize the ESB functionality. That however does not stop the vendors from trumpeting their products as ESBs. Anyways, more power to them – you can fool most people most of the time but not all people al of the time. Sooner or later your customers will find out as the tale goes, that the emperor (no relation to the now infamous club with the same name) has no clothes. Unfortunately this stinks up the world for the true ESB vendors but who am I to judge them.

• osESB -Open Source ESB
• Apache Servicemix – The Apache Software Foundation [Open Source JBI Compiant]
• OpenESB – Open ESB A Sun Open Cummunity effort [JBI Compliant]
• WSO2 ESB – WSO2
• Mule ESB – MuleSource Inc. [Open Source]
• ChainBuilderESB – Bostech Corporation [JBI Compliant]
• BizTalk – Microsoft
• Cape Clear ESB – Cape Clear
• Cordys ESB – Cordys
• Fiorano ESB – Fiorano
• FusionWare Integration Server – FusionWare Corporation
• Iona Artix ESB – Iona
• PolarLake Integration Suite – PolarLake
• Progress Sonic ESB – Progress Software
• JBoss ESB – JBoss (RedHat)
• WebSphere Enterprise Service Bus – IBM
• BEA Aqualogic Service Bus – BEA
• Sun Java Enterprise Service Bus Suite – Sun Microsystems
• webMethods ESB Platform – Software AG
• Oracle SOA Suite – Oracle

(The sequence of the listed products and companies does not have any meaning.)

After some recent projects I did and looking at the performance of other projects I am beginning to form a definite opinion about using an ESB for batch processing.

What do I consider to be batch processing? Gathering up data for a period of time, daily, weekly, monthly, quarterly or yearly and then submitting it all at once for processing by the ESB. I am definitely not talking about running the ESB in the background.

Firstly it must be stated that there is normally no difference in processing data in batch or in real-time, except for the timing and the volume. The ESB does not have any concept of batch or real-time and can not tell the difference. by definition the ESB is loosely coupled to consumers of its services.

I often hear the comment from customers and consultants that the ESB is adding no value. “I can do everything that the ESB does with a simple Java object or Java Servlet. This is often true but also frequently misguided. The idea behind the ESB is not compete with Java technologies for the job. Using an ESB allows you to configure rather than develop the processes. This allows for easier debugging, maintenance and flexibility in deployment architectures. These benefits are seldom apparent up-front but will become apparent over time. Unfortunately this configuration to tie loosely coupled components together in a flow/sequence or orchestration is not as performant as a tightly coupled Java object or Servlet.

This fact have servere implications for batch processing. If each data element takes 50% longer to process through the ESB than through a Java object, this can add hours to the processing of the batch. Handling errors also becomes a bigger challenge when there is a potential for a high volume of errors.

For these reasons I have become of the opinion that that the enterprise is much better served by executing ESB processes in real-time or near real-time