I mentioned the JBI specification a year ago in this post. This month (June, 2005) the JCP passed the final approval with almost all companies voting yes, with two notable exceptions. IBM and BEA the two largest application server vendors had interesting remarks with regarding their abstaining vote:
IBM abstains because the JBI specification doesn’t represent a sufficient step forward in terms of what we believe our customers need, and above what they can already do. Many technologies and open specifications are available to the Java programmer today with more compelling interoperability and better mechanisms for component composition. IBM’s priority is to enable integration with the broadest range of platforms, applications, and existing business assets. This demands a language-neutral approach using today’s Web Services standards, and simpler programming and application models.
Coming from IBM this makes sense. IBM doesn’t believe in a 100% pure java solution in the EAI space. Their transformation engine (i.e. WBI Data Integrator) has yet to be ported to Java, so you can understand their reluctance in supporting a Java solution that their customers are perceived to not need. Furthermore, the remark about Web Services standards being a simpler programming model is marketspeak. BEA remarked:
BEA believes that the JBI specification is an incomplete attempt to standardize the interfaces between multi-vendor infrastructure and contributes little to the usefulness of the Java platform for business application integration, one of the real pain point for our customers. It’s unfortunate that it’s name alone will result in significant confusion in the marketplace.
A bit hypocritical of a comment, after all, EJB (Enterprise Java Bean) a specification heavily supported by BEA, is the poster boy of misleading specification names. Does this unveil a hidden unease that JBI may supplant EJB as the preferred java enterprise solution? To be fair, BEA has already made great strides in the integration space. BEA has already proposed their component model to the java community. For the unitiated it is called “Pollinate”. The component model in Pollinate drives their Aqualogic line of integration products. There is obviously a real danger that a new integration standard would undermine their leadership in this area. Even worse, prompt a rewrite of their components and their customers configurations.
IBM and BEA without a doubt have leadership positions in the integration space. The incumbents will do as little as possible to aid alternative candidates to the throne. This of course includes not making any positive statements about an emerging standard. Abstaining from a vote indeed has its tactical benefits. Finally, it is important to note that the JBI specification doesn’t require an EJB container.
Anyway, let’s go beyond trying to deconstruct IBM and BEA’s remarks. There is real action now happening in the JBI space. In the past few weeks, two organizations have announced their open source JBI projects. The first to do so was James Strachan’s LogicBlaze company, they announced ServiceMix. ServiceMix uses Spring for its configuration, apparently a lighter weight approach than proposed by the standard.
This was followed by Iona, which donated portions of their Artix product to the ObjectWeb community. The new project is dubbed “Celtix“, the hope is for a useful product by the end of the year. Artix marketing brochures claim that is built on top of some kind of microkernel. Worthy of a peek when the code is released.
The Java integration space has quite fragmented for so long. It’s high time for some consolidation. The promise of JBI is that there exists a standard component model for integrating the various engines already out there. It allows application developers to stitch together best of breed solutions rather than being locked-in with a single vendor.
The stakes a quite high for many of the traditional EAI and BPM vendors. The winner may be the group that can gather the largest mindshare the quickest. Any new standard will tend to be incomplete (update: there is a Sun reference implementation). Because LogicBlaze (CodeHaus) and Iona (ObjectWeb) have made the first move they both are in position to fill in the gaps. It’s now up to everyone else to respond, support a project, introduce a new project or modify an existing project to support the standard. As for the incumbents, they can always choose to ignore the tide.
[update] Sun will announce in JavaOne an Open Source ESB.
[update] CNET reports that open source projects: ServiceMix, Celtix and Synapse intend on combining their efforts.