Another Clue

It's good to see the current debate in the blogosphere around JBI. For one thing it's good because once we are seeing this kind of reaction and this level of attention in Dons blog it means JBI is starting to get some mindshare... Don mention's Steve'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 developers' 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...

Don's already mentioned it, but my July'August Internet Computing (IC) column is now available, either as PDF or on the Distributed Systems Online site. This column covers Java Business Integration (JBI, aka JSR 208). In the context of JBI, Don asks about containers. My take is that containers aren't as special as we'd like to think they are. A container really just supports a particular programming model or style. Some do this by forcing certain inheritance structures, others do it by providing particular service APIs, still others state via some sort of contract what they expect of things that they contain. Most use a combination of these approaches. A good container handles the tedious or error-prone details of a particular approach, letting developers focus on their business logic. Containers have been around for decades and won't disappear anytime soon. Writing good containers is pretty hard. Therefore, rather than seeking the...

JBI defines a "container of containers", with a strong emphasis on getting those containers to interoperate. This will be of assistance to the EJB container, and will certainly strengthen the overall EJB story. Put another way: integration technologies aren't about obsoleting what they are integrating!

It is a mistake to look at JBI as some sort of replacement container for previous technologies that served as containers, such as EJB and Servlets. JBI is the next step in a broader architecture: a container of interoperable containers. See http://blogs.sun.com/roller/page/rtenhove/20050714 for details.

Finally, JBI isn't a Java EE-specific technology. It covers both the standard and enterprise editions. A lot of integration projects don't need the full power of EE; SE is more than adequate for many such tasks. This is equally applicable to purely SOA endeavours. JBI is applicable to far more things than Java EE application servers.

There is a moderately common misconception that JBI is a technology for making services available on an enterprise service bus. Actually it is for hosting "service engines". To see the difference, I wrote a service engine that only provides one "hello world" service.