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:
No comments:
Post a Comment