JBI Approved – Dawn of Easier J2EE Integration?

A new era in easier J2EE-based integration may be at hand for Java devs and architects, as the long-standing Java Business Integration specification (JSR 208) has been approved as a formal JSR by a 14-0 vote. But, notably, J2EE giants IBM and BEA abstained. Nonetheless, plans move forward to deliver a reference implementation by JavaOne. Get a look at the JBI, and its impact on J2EE enterprises - and vendors

Tags: JBI, Integration, Chappell, Java, ESB, Integration Components, Vendors,

A new era in easier J2EE-based integration may be at hand for Java devs and architects, as the long-standing Java Business Integration specification (JSR 208) has been approved as a formal JSR by a 14-0 vote - but 2 notable abstentions, J2EE app server market leaders IBM and BEA .

The formal work to begin codifying the spec and including all the final comments received during the public review period has begun, and so things look good to have this all done by JavaOne," said Dave Chappell, vice president and chief technology evangelist from Sonic Software, an originator of the JBI, and an outspoken proponent.

"Congratulations are most definitely in order," Chappell told IDN with a few days of the vote. "It is real exciting that it [JSR 208] went through the executive committee process with no 'no' votes. Now, the next steps for us is to incorporate the comments from the review period, and then finish up the reference implementation for JBI and the GTK. SO, we're on schedule for a formal release by JavaOne."

Other vendors voting "yes" on the JBI (JSR 208) include: Novell, Oracle, SAP, SeeBeyond, Sybase, Sun, TIBCO, webMethods, Iona, and Open Source projects Apache, JBoss.

The implication of JBI could be enormous, Chappell said. "Once vendors start implementing JBIs, enterprises will have the option of picking and choosing best-of-breed implementations [of integration components] that can in turn be plugged into an Enterprise Service Bus."

The result, he added, is that integration between J2EE app servers and other data or application servers will be much quicker and more cost-effective, as the ESB and JBI plug-ins will replace a lot of the design work done by architects and hand coding by developers. Chappell put it this way: "There are a lot of enterprise IT folks who will benefit from JBI because they are tired of giving up control of their IT resources to large consulting groups that also happen to be J2EE app server vendors."

Chappell gives an example: "Say a rules-engine vendor could write their rules engine to support the JBI interface. That could then let enterprise IT users plug that rules engine into any ESB, whether from us at Sonic or any other vendor."

We asked Chappell, if he thought that now JBI was adopted, if the technology might be picked up as part of the on-going work on defining specs for EJB 3.0, the next-generation J2EE app server architecture.

"That's an interesting thing to consider. One can only hope," Chappell said. While overall, he wasn't sure if the timing would permit the EJB 3.0 work to consider JBI in this version, but he sees similarities in the two projects than might help bring the two projects together at some point: " Overall, the EJB 3.0 is moving in a POJO (Plain Old Java Object) environment, which is a good thing. Because that's the direction we took with JBI. But for the moment, we're going to be focused on making JBIs successful.

So, what happens now to build up an inventory of JBI components? Chappell was very pragmatic: "The first thing is that every ESB should consider embracing JBI. That's part of what will help accelerate its adoption and prosper this ecosystem where vendors can offer individual components." .

Finally, Chappell wasn't too flustered by the abstentions of IBM or BEA, ad doesn't expect either firm to obstruct JBIs - at least at in the standards process:

"In IBM's case, they have no interest in making it easier for IT to do integration projects, or to pick from best-of-breed components. After all, they have built up a huge consulting business that is now approaching 50% of the whole company." And BEA? Didn't they support JSR 208 at one point? "Well, I think there are some at BEA that now feel it's unfortunate they dropped out in the first place. They may at some point decide to get back in," Chappell said.

"But, look at it this way. At least neither one of them said no."

Inside the Java Business Integration (JBI)

The following extract is from an IDN interview with Dave Chappell about the convergence of ESBs and JBI conducted last year.
IDN: Describe your goal for JBI?

Chappell: JBI is really about being able to provide pluggable integration components that can interoperate with each other, and have those pluggable integration components come from different vendor implementations and house things that are proprietary, even opaque to the JBI environment.

IDN: Would you say that JSR 208 is a piece of helping Java developers move into integration more easily -- in other words, moving from learning about Java APIs to a world where you're working with Java to non-Java resources?

Chappell: That would be one aspect of it: being able to house integration components that are non-Java services. But to get back to this idea of separating the processing logic from the actual code implementation itself, in a JBI environment, an integration architect doesn't need to know the intimate details of the thing that the JBI container is holding. All you need to know is that the container holds an integration component, and you're plugging together a number of these containers into an integration architecture. It's very much like an ESB approach.

IDN: How important are JBIs to the delivery of value from Enterprise Service Bus?

Chappell: On the implementation side of the ESB, you don't actually need to code up all that stuff; you can just plug that into a tool environment where you administratively configure how they talk to each other. That's where this new idea of an IDE for the integration architect comes into play. You're not coding JMS and coding JCA adapters; you're buying an adapter from a 3rd party, or licensing it from an ESB vendor.

And you're using a tool infrastructure to administratively specify that this is going to talk to this application, it sits inside a particular ESB container and it's going to route messages inside this message queue until it gets to a point where I want it to be translated into another format. At which point, it will plug into another service, which may be a JBI-compliant transformation service that was acquired from somebody else.