JBI is still dead

Bookmark Blog Post

	del.icio.us
	Digg
	DZone
	Furl
	Reddit

Dain Hansen's Blog | January 31, 2008   8:22 AM | Comments (0)

About a year an a half ago I wrote a highly infamous blog stating that JBI is dead. At the time of my blog I had some suspicions of the limitations of the standard. As it turns out, my suspicions are still warranted.

From polling our customers, partners and folks out there like you, we’ve heard that JBI 1.0 is not ready for prime time. The JBI 1.0 standard focuses primarily on a few vendors and doesn’t deliver on the promise of ESB-portability or ease of creating SOA. As a result, it contributes little to the usefulness to business integration, one of the real pain points for our customers. There have been a few articles that disagree with me although the disagreement is not with me on the 1.0 standard, but rather on the future of what JBI potentially can deliver in 2.0. A great quote from Mark Little, “JBI isn’t dead but pining for the Fjords”. Well possibly. But let’s take an objective look at it.

What is actually included in JBI 2.0? Below is an excerpt from the JCP’s plan with my annotations in red.

Enhancements in JBI 2.0 will include:

• Enhancements to facilitate the use of JBI in clustered or distributed environments, principally with respect to administration rather than the clustering/distribution mechanism itself

Many of the open ESBs which are based on non-J2EE container architectures and only JBI ones, are finding themselves unable to meet scalability requirements. J2EE offers clustering/distribution options, so it is not likely we’d see rapid adoption of new standards in this area.

• Enhancements to clarify and enhance the use of JBI in a SOA-based approach to the creation, deployment and runtime support of Composite Applications.

Composite applications are where SCA has a sweet spot; the ability to design, deploy SCA is where everyone is heading. Do we need another level of abstraction for deployment objects?

• Enhancements to support requirements stemming from WS-Policy.

Great idea; wrong standard for it. Policy in general has become one of the most hot topics in SOA Governance. It requires adoption by not just the ESBs but by the repositories, management vendors, and SOA Governance solutions. A JBI standard-only for policy would be quite limiting for SOA Governance.

• Enhancement to support Web 2.0 technologies and usage models.

Well that’s a different standard isn’t it? It is called AJAX and REST? Do we need another level of abstraction for the binding here?

• Introduction of a Message Exchange handler/interceptor model.

Makes perfect sense, the ESB vendors are noticing that the JBI standard isn’t ideally situated for ESB approach.

• Enhancements to facilitate performance optimizations by component and container implementers.

Ok I am not sure how you are going to make a standard here to make competitors beat each other in performance; what would be more useful is a standard way to measure performance in general among ESBs.

• Improved alignment with Java EE (e.g. use of transactions).

That would be simply adopt the J2EE standard.

• Recoverability of Message Exchanges.

Recoverability is again something handled quite well in today’s J2EE containers. We don’t need to reinvent this wheel.

• Improved readability of the specification to clarify the needs of container, component and application developers.

Keep it simple. Totally agree. JBI 1.0 had millions of marketecture interpretations – but few cases that met the promises of vendor neutrality and openness.

• Alignment with the Service Component Architecture (SCA) specifications (see www.osoa.org) with the goal of making JBI 2.0 a standard Java runtime for SCA.

Alignment is another word for … borrow… or perhaps recognize that the standard is much better at managing complex composite applications across not just JAVA but across all.

• Enhancements to support full compatibility with OSGi, without necessarily requiring OSGi.

Makes sense, no comment here. Although again, sounds like another unnecessary level of abstraction. 

• Technical issues stemming from implementation experience using the JBI 1.0 specification (e.g. life-cycle of components, error handling, interop profiles, examination of the utility of WSDL definitions for non-Web Services deployed components, component attributes, threading, NIO use, classpath or endpoint activation)

Bug fixing. Yes Good idea.

The recurring theme here: JBI is pulling itself back to life on the other standards which have become more popular and widely adopted, especially SCA (Service Component Architecture). I think this is especially important. JBI yearns to be like SCA in the way it meets interoperability above and beyond simply Java-based bindings. Do you need both or just one? If you’d like to see the relationship between JBI and SCA you should definitely read this great blog by Mike Edwards. You should definitely make your own determination if you think this standard has life left in it. Will the ubiquity of SCA, BPEL, J2EE hang make JBI the forgotten standard of the past? Feel free to send me your comments; even if you think JBI still has some air left in it. I’d love to hear from you.

BEA’s AquaLogic Service Bus 3.0 will take advantage of the SCA standard along with BEA AquaLogic; today it supports interoperability to BPEL and leverages one of the most widely adopted J2EE platforms on the market.

Comments