Java Business Integration 2.0 Takes Shape

By Alex Handy

March 15, 2008 — (Page 1 of 2)
When the original Java Business Integration 1.0 specification was released, some in the development world mistook it for an enterprise services bus. That was unfortunate, because JBI was never intended to be an ESB in the first place. Now, the specification leads of JBI 2.0 are working on ways of better integrating Web services in a Java world, and hoping that this time developers get the right impression of what the software can do.

Peter Walker and Ron Ten-Hove are co-specification leads on JSR 312, the expert group behind JBI, and both are engineers at Sun Microsystems. They're hoping to invert their development and creation process for JBI 2.0: Although version 1.0 began with a specification and ended with a reference implementation, they hope that version 2.0 will do it the other way around.

This time out of the gate, they're also aware of the mistakes made with the presentation of the JBI 1.0 specification in 2005 by what was the JSR 208 expert group. “When we first released the specification,” said Walker, “we knew in our own minds it was positioned as a sort of augmentation to existing enterprise infrastructure. But a lot of people took it to be a specification for ESBs. That set us off a little bit on the wrong track. If I was writing an ESB, I'd use JSB as its heart, but it's technology that really just deals with a model of mediated message exchange. When we first introduced it, a lot of people were looking for an API, and there really isn't one in JBI because it's a middleware specification.”

2.0 Means New Point Oh
Ten-Hove said that the JBI 1.0 specification was as much about what was missing as what was there. This time around, many of the ideas they initially ignored in favor of simplicity may be addressed and added to the specification.

“One [idea] we left out for simplicity was interceptors: the notion of having some sort of pluggable piece that can intercept message exchanges,” said Ten-Hove. “They can be used as debugging aids, or to build certain kinds of application enhancements like retry logic. We quite deliberately left that out because we wanted to make sure people left the boundary between business and infrastructure. We didn't want people composing applications out of interceptors.”

Pages 1 2

Share this link: http://sdt.bz/31823

Technorati

Digg

Slashdot

Facebook

Friendfeed

Twitter

del.icio.us

Stop hard-coding business rules Giving more power to "business developers" can streamline production, though it has its drawbacks

Zeichick’s Take: Java, Java everywhere The results are in from SD Times' Java & SOA Study, and it shows that out-of-date systems are still being widely used

Integration Watch: Java EE: The dead man walking The drive toward small, user-made solutions will push Java's future away from the cumbersome Java EE