Currently, the only standards specification I can find for ESBs is the Java Technology Specification JSR 208 – JavaTM 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?
Talking to your web designer can be like going into a coma, and waking up in China – alone. Sure some small percentage of us can understand the way they talk. The vast majority will however feel inadequate, confused and frustrated.
)