Composite Materials

Clues for Don Box?

Judging from some recent blogs, some folks are getting lost in the details of the JBI specification, and not seeing "the forest for the trees." This is understandable -- we are used to most JSRs being focussed on very narrow technical domains. However, this isn't true of JBI.

When I explain JBI to people, I usually start a statement like "JBI is a meta-container" or "JBI is a container of containers." This is an extremely important architectural point that must not be ignored in the urge to get the "meat" of the API's and SPI's that are defined. Why is this so important?

A JBI plug-in is typically a container of some sort. A familiar example is a EJB container. Others include BPEL engines, transformation engines, and, of course, bindings to various protocols. The point of the meta-container concept is to allow these various specialized (concrete, if you will) containers to interoperate. Let me say that again: JBI allows plug-in containers to interoperate.

Pause and think about that for a moment. The JCP has been very good at defining many Java-based technologies, including several very important container types. Getting those containers to interoperate has required "hard coded" provisions within the container specifications, and appserver implementations are usually very messy as a consequence of this. As a thought experiment, try imagining adding one more container type to the J2EE suite. Adding it as a standalone container would be easy; getting it to interoperate with existing containers would be no mean feat. Getting the N plus 1th container type to interoperate with the previously defined N container types would likely require N separate "connections" to achieve interoperation. Ugly, not scalable, and very brittle.

This type of interoperation problem isn't unique to Java EE, or Java at all. We in the integration community know this problem intimately. The solution is to be found in architecture. A service-oriented approach (with a distinct WS flavour) is the architecture that JBI defines to achieve interoperability between plug-in containers.

That takes me to the second point I usually make when explaining JBI: don't look on the JBI API's and SPI's as something you will use in your application. For the vast majority of users, JBI will simply be a framework that will be used to host a set of containers that will provide the functions needed by the user. The user will be using things like BPEL, XSLT, and SOAP, and will deal only with BPEL processes, XSLT style sheets, and WSDL definitions. The only points where JBI will become visible are a) knowing that you need to assemble the right JBI components to provide the types of functions you need, and b) having a centralized administrative capability, allowing you to administer these separate containers together.

So let's conduct that thought experiment again, where we added a new container type, but this time let's use JBI. What are the effects of adding a new (plug-in) container to a system with pre-existing containers? None. Nothing. The plug-ins are loosely coupled, meaning that we don't have to change the existing container components to accommodate a new container type. Much better!

This inter-container interoperability is more than a technically meritorious achievement. This has many implications for the marketplace, but that is a separate topic.

Posted at 11:16AM Jul 14, 2005 by rtenhove in Java Business Integration  |  Comments[0]