Java Reference
In-Depth Information
In reality, by 2009, few commercial vendors support the JBI spec as the centerpiece of their
ESBs. There are a variety of reasons for this. One is that some vendors realized that they could
spruce up and re-package EAI offerings that they already had implemented. By tying together
a set of connectors and adapters they had previously developed, they could breathe new life
(and new sales) into existing products.
But in contrast to something like Java application servers, the industry was not just waiting
for Sun to come out with a specification for ESB. They had their own ideas about what ESB
could and should mean, and they were free to implement it however they saw fit. This has
led, in part, to less support for JBI than a Java developer might imagine. In addition to this,
the benefit of being able to port a service engine or binding component as a pluggable object
from one JBI container to another is not entirely clear. Presumably, the vendor that develops
the engine will see the best return on investment by optimizing performance and adding fea-
tures that rely on intimate knowledge of the underlying container. That has played out in the
market, where each vendor that implements JBI actually does all of the work of implement-
ing their own SEs and BCs for HTTP, FTP, JMS, File, BPEL, and so on. Because of this, the
barrier for developing an ESB based on the JBI specification is set rather high for vendors,
and given the lack of clarity as to what benefit they receive from making their SEs and BCs
portable, vendors have been reluctant to implement JBI.
In addition, there is a practical limitation in that JBI expects all service contracts to be
WSDLs. This does not account for WADL contracts, which may become popular for POX/
HTTP, or for straight Java.
NOTE
The complete list of BCs and SEs for OpenESB is available at https://open-esb.dev.java.net/Compon-
ents.html .
JBI also has some problems with its classloader and packaging architecture, such that the Ser-
viceMix project is adding support for OSGi in order to make it easier to work with. Deploying
to a JBI meta-container can require lots of files that are rather opaque.
Finally, because the normalized message router in a JBI container specifies that the message
format must be XML, some have objected to the fact that this transformation produces unne-
cessary overhead for non-XML based messages. JBI also does not allow for streaming data
within the NMR, adding further to the processing overhead in certain cases. It's worth noting,
however, that XML is used as the basis for many commercial normalized messages internal to
the bus, including products such as TIBCO's ActiveMatrix.
Search WWH ::




Custom Search