It's good to see the current debate in the blogosphere around Java Business Integration (JBI). For one thing it's good because once we are seeing this kind of reaction and this level of attention in Don Box's blog it means JBI is starting to get some mindshare.
Don mentions Steve Vinoski's entry although that entry was actually primarily about Celtix. But because Celtix supports JBI we are inevitably drawn into this debate.
In response, the first question to ask is whether one container can fulfill every requirement. This is kind of like asking whether one computing language meets every developer's needs. The answers seem to be no and no.
If we can agree that multiple containers are necessary because one size fits all is not a good approach in software, then the next question is which containers do we need, and for what purpose(s).
JBI is aimed at messaging and integration, whereas EJB is really a transaction processing container. Sure EJB has support for "message beans" but these are in the context of transaction processing, a sort of messaging add on to the synchronous orientation of EJBs, like queuing is an add-on to popular TP monitors when applications needed both. This is not the same thing as a pure messaging solution since the queuing in these environments is always done within the context of the TP monitor environment and uses its development metaphors and APIs (i.e. not independent ones).
The answer to Don's question about JCA vs JBI is pretty much the same, that is, within the context of whether you are doing OLTP (Online Transaction Processing) or asynchronous messaging-based integration. If it's the former, use JCA since you are already using EJBs. If it's the latter, use JBI since you don't really need all the other EJB APIs. EJB and JBI containers can co-exist, just the way TP monitors and independent messaging systems have co-existed for years.
The JBI container model is needed because asynchronous m
To continue reading for free, register below or login
To read more you must become a member of SearchSOA.com
essaging and integration functions need to be first class citizens of many applications, not simply add-ons to TP monitor style interactions. However, equating EJB and JBI is also not quite correct.
The EJB container is all about concentrating user transaction requests into a shared database. The application server is the modern TP monitor, and the EJB is where the transactional interaction with the database happens.
JBI has no concept of the three tiers the way application servers do (servlet = presentation tier, session bean = application logic tier, EJB = database server tier). JBI is a container designed to support plug-and-play relationships between integration components and messaging systems instead. While EJB is designed for application developers, JBI is designed for software vendors.
You can use an application server for integration, just like you can use a TP monitor, but it isn't designed for that, and it takes a lot more coding.
That's why EAI (Enterprise Application Integration) solutions were originally developed as distinct from TP monitors and became popular for a while. There's a big difference between technology designed to support online transactions against a shared database and technology designed to share data across disparate applications (which may or may not be online, transactional, off the shelf, or even in the same part of the world).
If you take the single container argument to its logical conclusion you end up with a single software system trying to meet both OLTP and integration requirements. While this is possible it does not seem practical. Costs and time to market can be significantly reduced using software systems specialized toward particular types of requirements.
Some of the biggest new trends at Microsoft (of which Don is certainly aware) are software factories and domain specific languages (DSL). This is very innovative work with significant potential. A major concept of DSL is that a single general purpose language is never going to be the best solution for all jobs.
The industry would benefit from the adoption of JBI (or something similar) since it promotes a best of breed approach to integration. IBM is unlikely to support that, of course, since they want to be your single software supplier. But for smaller vendors specializing in business process management, transaction management, security, transformation, or messaging for that matter, a container model oriented toward integration requirements makes it easier to combine their software with other vendors' software.
Where BEA is in all of this I'm not sure but it may be that they think they will be competing to become your single supplier as well, although the AquaLogic announcement makes it seem as if they are starting to move away from that idea.
JBI also makes perfect sense for open source, by the way, which may (come to think of it) contribute to some of the skepticism. Open source projects benefit from the ability to divide up work using a plug-in architecture. This is one of the features of the Celtix project, and one of the reasons Celtix supports JBI in addition to our own plug-in model.
The jury may still be out on whether or not JBI will succeed, and if it does whether it will achieve the level of adoption that EJB has, but at the recent JavaOne show the industry saw JBI off to a good start.
This article originally appeared in Eric Newcomer's weblog.
About the Author:
Eric Newcomer is Chief Technology Officer at IONA, where he leads the company's participation in industry standardization activities. Eric was a founding member of the XML Protocols Working Group at W3C, which produced SOAP 1.2. He is a former editor of the Web Services Architecture specification and is also co-author and editor of the Web Services Composite Application Framework (WS-CAF) set of specifications and co-chair of the WS-CAF technical committee at OASIS.
