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!)