There was a fair amount of coverage and talk of JBI
at JavaOne. This was particularly good as we're close to our first
release of our open source JBI container and component suite, ServiceMix.
I'm not completely sure folks quite grok JBI yet; there seemed to be
some folks with confused looks on their faces in some JBI talks at
JavaOne. I think a few articles are required to explain it, its value
proposition and how to use it.
My brief take on JBI is that its a simple API to a Normalized Message Service and Router
along with a component and management model for deploying integration
services such as routing engines, BPEL engines, rule systems,
transformation engines etc.
JBI provides a logical XML messaging network which maps well to HTTP,
email and JMS/MOM while easily adapting to legacy systems, binary
transports and RPC systems like EJB and CORBA. Think of it as the next
logical abstraction above JMS, with support for different message
exchanges (one way, request response etc).
The binding components deal with all the plumbing and protocol stuff, then service engine components work on a logical XML layer, providing content based routing, orchestration, rules, transformations and custom enrichment etc.
So BPEL engines no longer need to deal with all of the possible
protocols, transports and wire formats; they can just delegate to JBI
for the physical routing to service endpoints. Similarly content based
routers, rules engines, transformation engines can sit on the JBI bus
and do their thing. So I see JBI as being a great API for integration
component developers.
Sure most application developers will still end up writing POJO
services and dropping them into their container and exposing them as
web services - so often they won't need to use the JBI APIs directly;
but for integration companies like ourselves, it provides a way for middleware and integration vendors and OSS projects to work together at the ESB level.
9:49:11 AM 
|
|
