Tuesday, August 23, 2005

Java Business Integration (JBI)

For ipt I've given a talk on the topic of JBI recently. The rationale behind JBI is the current lack of standardization on the concept of ESB. Services developed for Sonic cannot be migrated to Iona or BEA. Different vendor’s ESB buses cannot seamlessly be integrated. This seriously hampers the adoption rate of ESBs in their current incarnation. The following statements are maybe a bit cynical, but let’s say I’m playing devil’s advocate:

ESBs are proprietary:
While most ESBs are standards based in their low-level implementation (XML, XSLT, BPEL, etc), they are proprietary at the level where custom services and integration components (such as BPEL engine, XSLT engine, BRE) live. Custom services developed on the basis of one ESB product cannot be migrated to another product without modification. Sonic's service API is incompatible with Iona's or BEA's, for example. Integration components, such as process engine, XSLT engine, BRE are tied to the vendor; no choice is possible. This may be perceived as risking vendor lock-in: who wants to build their enterprise infrastructure on a technology from a single vendor?

Different ESBs are incompatible on the transport level:

Most current ESB implementations are built on JMS. JMS guarantees reliable and guaranteed delivery of messages between components, an important basis for critical business processes. Since the JMS specification does not define a wire protocol, different ESBs are incompatible on the transport level.

On the other hand, it is unrealistic to assume that just a single ESB product will be available or can be deployed enterprise-wide. In most situations there will be variations in the installed software base, possibly as a result of mergers. What happens if external business partners want to join the service network but have invested on a different, incompatible bus? In such situations, interoperability can be established only via message bridges that link together the different ESBs. This can hardly provide the illusion of a seamless ESB service network.

Is JBI the solution?
JBI is out to change all that. JBI doesn't require a J2EE stack. This means that third-party vendors of integration components can plug their wares into the JBI framework even without having a full J2EE stack. Customers can therefore build "their" ESB server using a best-of-breed approach, e.g., take the XSLT engine, a BPEL engine, BRE engine of their choice. These might all come from different vendors who focus on their core strengths. Since components are portable between different JBI implementations, this approach avoids vendor lock-in. Different transport implementations can also be plugged in. This makes incompatible wire protocols much less of an issue.

JBI Overview

Service Engines (SE) from different vendors (e.g., an XSLT engine, BPEL engine, container for custom ESB services) plug into the normalized message router (NMR). The NMR mediates all communication between SEs. If the destination SE happens to be on a foreign host, remote communication is initiated via an appropriate protocol binding component (BC). The BC might provide JMS transport, WS-RM transport, even CORBA or EDIFACT. The meta-container maintains a routing table for this purpose. Proxying of JBI services to remote consumers is transparent at the SE-level.

Disadvantages (or why didn’t IBM and BEA join the initiative?)

Do we still need it or are WS-frameworks sufficient? They don’t see it as a sufficient step forward and believe that the area covered by JBI can equally well or better be addressed with upcoming WS-* Standards.

It is still early days to predict whether JBI will catch on or end up as yet another container architecture. The inceptors’ vision is to see JBI play an important role in enterprise integration as J2EE did/does today for application development. They also envisage the emergence of an ecosystem of pluggable SEs from different (niche-) vendors.

A few articles on JBI:

1 comment:

James McGovern said...

If there were any integrity in the blogosphere, the following discussions surrounding ESB would occur:

1. Folks would acknowledge that Sonic invented the term ESB but has lost ground to the open source community as ServiceMix (www.servicemix.org) has them beat by miles.

2. No one would ever listen to the reviews posted by either industry analysts and/or magazines since they seem to never compare non-commercial open source platforms to closed proprietary products in their reviews.

3. They would demand of all the conferences that they attend that the vast majority of speakers are customers not the folks from software vendors who provide thinly veiled powerpoint presentations chock-a-block with eye candy but lacking any substance. Customers have nothing to sell so having them present is key unless you really don't have any...