Watch out for JBI 2.0

Currently, JBI 2.0 specification is in progress. It is expected to be finalized in Q1 of 2008. The JCP reference for JBI 2.0 is JSR 312. [Link to JSR 312]

The scope of JBI 2.0 includes followings:

• Enhancements to facilitate the use of JBI in clustered or distributed environments, principally with respect to administration rather than the clustering/distribution mechanism itself.
• Enhancements to clarify and enhance the use of JBI in a SOA-based approach to the creation, deployment and runtime support of Composite Applications.
• Enhancements to support requirements stemming from WS-Policy.
• Enhancement to support Web 2.0 technologies and usage models.
• Introduction of a Message Exchange handler/interceptor model.
• Enhancements to facilitate performance optimizations by component and container implementers.
• Improved alignment with Java EE (e.g. use of transactions).
• Recoverability of Message Exchanges.
• Improved readability of the specification to clarify the needs of container, component and application developers.
• Alignment with the Service Component Architecture (SCA) specifications (see www.osoa.org) with the goal of making JBI 2.0 a standard Java runtime for SCA .
• Enhancements to support full compatibility with OSGi, without necessarily requiring OSGi.
• Technical issues stemming from implementation experience using the JBI 1.0 specification (e.g. life-cycle of components, error handling, interop profiles, examination of the utility of WSDL definitions for non-Web Services deployed components, component attributes, threading, NIO use, classpath or endpoint activation)

The above list is taken from the proposal of JSR 312. I am more interested in the highlighted items. One of the most important drawback of JBI 1.0 is that its Normalized Message Router (NMR) is not based on a messaging system, but it is an in-memory router. It makes it a single point of failure in the system. I hope that the scope named as "Recoverability of Message Exchanges" address this issue.

Is JBI 1.0 true ESB?

Sun has taken a big leap with new integration specification JBI 1.0. The JCP reference for this specification is JSR 208. The specification is available here for download: JBI 1.0 Specification.

One of the key component of JBI 1.0 is Normalized Message Router (NMR). It routes normalized messages from the source component to its destination using some kind of routing policy.

In a true ESB based architecture or product, the integration is based on a messaging system, which acts as a message broker. The role of this message broker is to provide abstraction between application components. It routes the message from one component to another component, and the components are not aware of location of each other. It provides following functionality:

1. Reliability: In case of failure or unavailability of any component, the messages are persisted in a queue.
2. Scalability: The end point of ESB can be deployed on multiple servers. These servers are linked together with the messaging system. The ESB knows the location and type of services deployed on each server. It uses this information to route the messages to its destination.
3. Security: Transport level or message level security can be provided by the messaging system while transporting the messages from one server to another server.

In JBI 1.0 specification, the Normalized Message Router (NMR) is expected to play the role of message-broker for the ESB. However, the NMR in JBI 1.0 is designed as in-memory message router. It is not based on any messaging system. Therefore, it does not provide all the functionality of the message broker of a true ESB. Moreover, it becomes a single point of failure. In case JBI 1.0 based server crashes, the in-transit messages are lost.  In my opinion, JBI 1.0 based product does not qualify for a true ESB solution.