Looking for a Clue

Don Box's Spoutlet

Syndication

I'm seeing lots of noise about JSR-208/Java Business Integration (JBI) out of this year's JavaOne. 
 
As a layperson, JBI looks to me like yet another container/component model to add to the EJB/Spring/Pico family.
 
Naturally, JBI defines a new set of lifecycle, context, deployment and configuration details, but the basic "message comes in, container loads code, code sees message" machinery we all know and love from ASP.NET/Servlets/CORBA/DCOM/ISAPI/httpd is there in all its glory.
 
What I don't understand is how a JBI container all that different from an EJB container, and if not, why does the world need both?  Moreover, when would someone write a JBI service engine vs. writing a JAX-WS component? Also, why didn't IBM and BEA embrace this thing last fall?
 
Hopefully, the Java cognoscenti will educate me…

Posted Jul 01 2005, 10:15 PM by don-box

Comments

Middleware Matters wrote July/August IC column: JBI
on 07-05-2005 11:26 PM
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...

Add a Comment

(required)  
(optional)
(required)  
Remember Me?