Is JBI an ESB?
By rtenhove on Jun 30, 2008
In his book, Enterprise Service Bus, JBI expert group member Dave Chappell presents a very useful model of what an ESB is, and what it does. One of the major features of his model is the service container, a node on the bus where services are provided and consumed. The service container includes integrated applications, of course, presenting them to the bus as services invoked by XML message exchange. In Dave's model JBI is a technology for creating such service containers from standardized pieces (namely the NMR and the plug-in components).
JBI was deliberately crafted to support multiple approaches to building an ESB. This has resulted in some quite different approaches. Some ESBs use multiple JBI instances linked by JMS message queues. Others use multiple replicated JBI instances running together in a cluster, providing in essence a large, highly available and scalable virtual JBI instance. Still others approaches exploit more elaborate ESBs, using JBI to create highly flexible, componentized service containers.
Okay, this is all stuff that was published three years ago, so why am I bothering to write about it today? I have seen recent reports of certain ESB vendors running around claiming that JBI is a terrible ESB, saying things like "the NMR is a single point of failure," and "it is a hub-and-spoke architecture, not a bus". This either reflects a genuine misunderstanding of what JBI is (which seems unlikely after three years), or an attempt to spread self-serving lies and old-fashioned FUD.
So if you are contemplating buying an ESB that supports JBI, please look closely, and educate yourself about the benefits of using open standards, especially in avoiding vendor lock-in. And please, don't take too seriously any "technical advice" about JBI coming from a company that doesn't support JBI. The chances are, they just want to lock you in to their proprietary ESB, and they won't let the truth stand in their way.