Java Business Integration (JSR 208) defines container services that enable system integration via Web service technologies and XML message exchanges. In this interview, JBI Spec Lead Ron Ten-Hove discusses how JBI will impact enterprise Java developers.

Read this Leading-Edge Java article:

http://www.artima.com/lejava/articles/jbi.html

What is your opinion of JBI?

I've been reading a lot about SOA, BPEL, et al recently and it all seems very "pie in the sky" to me right now. I think what is needed is a "Pet Store" type demo application that is acually implemented and widely available for everyone to examine and digest. It's one thing to write about examples such as integration of ordering with shipping, but until someone actually does it and makes it available for investigation and learning it is not likely to make any real headway in the market.

Within Java services can be defined as interfaces. WSDL is a platform / language independent way to identify services which are usually interfaces (except when using document-centric SOAP). I just don't see the benefit.

I think most people agree that to integrate the widest number of enterprise services as easily as possible, what is needed is a hub or bus that allows the services to be plugged in the back and protocol transceivers (aka binding components) to be stuck on the front.

Services may be web services, EJBs, POJOs, BPM engines, message translators (ie XSLT), rules engines, etc. The services offered can be described using WSDL.

Binding components may handle SOAP, JMS, HTTP, SMTP/POP3, + adapters for any specialised protocol.

Such an architecture decouples client from service. But whereas proprietary products offer similar functionality, they may lack a key component, eg rules engine, or may not offer best-of-breed (the BPM engine may run like a dog).

It would be nice if messages could be consumed, transformed, enriched and serviced by pluggable bespoke or best-of-breed components, and what is needed for that is a standard API for all the binding components and service engines to be bolted onto an underlying messaging infrastructure. JBI does that. It basically allows you to build your own service bus.

HTH

In addition, the more cynical might note that building your own integration bus is not what certain vendors (with competing products) want, which is why IBM and BEA voted against the JBI jsr. I couldn't possible comment :)

I guess I'm not quite getting the role of JBI in relation to UDDI and ESB's. As a "container of containers", it let's you plug in containers and wire them together using a standard. Seems like without JBI, you expose the services in the containers using WSDL, publish them as UDDI, and use ESB as the messaging backbone. So it seems like JBI is doing the same thing but as container services. Am I interpreting this correctly? Can someone elaborate on the relationship between JBI and ESB (where they may be competitive and/or complimentary)?

I think JBI is trying to standardize what products like Weblogic Workshop Integration already do. Except, WLI has a built-in business process engine which is proprietry. If this is true, I have a question. How does JBI address communicating with non-Java applications that do not work as web services (no WSDL/SOAP)? How does it work with a non-Java binding component?