JBI 2.0 at JavaOne

Posted by Mark Little on May 17, 2007

Sections

Development,

Enterprise Architecture

Topics

ESB ,

Java ,

SOA Platforms ,

SOA ,

SOA Appliance

Tags

JBI 2.0 ,

Java One

Two years after it was released, the number of ESB implementations that do not use JBI outweighs the number that do. Some vendors even announce that they are dropping JBI because of lack of applicability. It is fair to say that the original intention of JBI, to provide a standards based architecture for integration solutions, has not been met. Or at least if it was met, the industry has ignored it. There have been a number of reasons for this, including the inevitable impact of Web Services and that the industry probably wasn't quite ready for JBI. Plus, IBM and BEA were not involved in the specification because they did not believe it was needed. Whether or not that was a self fulfilling prophecy, the likes of Sonic, TIBCO and Sun have not been able to save JBI. Then along comes SCA with what some perceive as overlap in the JBI+JEE space and many people are already nailing the coffin shut on JBI.

However, Sun, Red Hat, TIBCO, IONA and many others don't believe it is over for JBI. Furthermore, since several of them are also co-authors on the SCA specifications, they don't necessarily agree that it's a JBI versus SCA debate: JBI can be a good platform on which to build SCA. Probably as a result of SCA and Web Services hype, and the fact that JBI wasn't really going anywhere, Sun formed the JBI 2.0 technical committee to revise the specification and incorporate user/developer feedback along with changes in the industry since it was first released.

The things the committee may be looking at include:

• Alignment with SCA.
• Performance optimisations (e.g., it doesn't always make sense to normalize your messages).
• Be clearer about where transactions, security etc. play in a JBI environment.
• Explicitly address distributed JBI.
• Leveraging OSGi where it makes sense.
• Standard interfaces for standard components.

At JavaOne 2007, Sun had a JBI 2.0 evening of BOFs, covering developer and user feedback on JBI 1.0 as well as a one BOF targeted specifically at what users expect from JBI 2.0. Everyone seemed to agree that JBI 2.0 should become the standards-based deployment platform for ESB/SOA. There were few people interested in deploying to SCA, but it was "on the radar" as something they may need in conjunction with JBI. Plus, versioning of services is critical: systems simply cannot be taken down in order to upgrade a service, so this capability needs to be in from the start and managed in a dynamic way.

The general conclusion from the entire JBI evening was that JBI 2.0 is needed and will be an important addition to the JEE platform. Both user and developer communities want to see more adoption. They also want to see better integration between JBI 2.0 and SCA. With the relatively quick timeline associated with JBI 2.0 (less than a year), it is likely that we'll see it standardised before SCA gets out of OASIS. With any luck, 2008 will be the year of JBI (at long last!)

1. Back to top

   all technology is political

   by douglas dooley

   In the words of John Doerr, circa: sometime in the '90s at Stanford Business School, the battle between 'competing' integration approaches is exhbit 1. All of this is predicated on the theory that ESBs are another round of app server competition, which could be correct, but in this case, there are two standard approaches. One, in OSGi, and the second, in the JSP, to be integrated with JEE...
   
   This is a good write-up overview for anyone trying to figure out which horse to bet on, even though most vendors will try and convince you that there is no competition, only collaboration. I find it hard to believe that the most significant new spec. from the JSP in the last 2 years, that was outright disregarded by two leading JEE vendors (WL and WS), would be collaborative not confrontational...
   
   There is a lot of work going on to make these two technology platforms - SCA & JBI - seem overlappable, i just think that there is too much at stake for some vendors to support the other; though Sun has surprised me by supporting the new component model of SCA, why? who knows...but it will someday have to choose between Java and non-Java specs, whether they want to do that today or not...
   
   I am sure I will hear it from someone about the love between the two technologies and technologists that support these specs, i just don't see it...there is a way to do SOA in the Java world, and its called EJB/JAX...whether some vendors like this reality or not is almost beside the point, customers have bought in to it, why resurrect C++, for Microsoft integration purposes? seems like a ridiculous argument...
   
   JBI 2.0 needs to be the main additional ingredient in JEE6, and let the app server vendors figure out how to deal with it...sometimes, Sun bugs me with their inter-spec acnowledgement, when they have the advantage with their own specs...but maybe the splintering of the JEE community is too much of a risk to do over some ESB approach, but if you were Sun and had to recommend a platform approach for customers, why would u introduce a spec. that opens up competing development models? sometimes, Doerr's comments are more relevant than other times, this time, it seems to be right on...

   Reply

• Older >