JBI 2.0 at JavaOne
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!)
all technology is political
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...
Jon Brisbin,Stephane Maldini Nov 26, 2014