Lots of links on JBI:
- IONA’s Eric Newcomer
- Microsoft’s Don Box
- Cape Clear’s Annrai O’Toole
- ServiceMix (and Groovy and ActiveSOAP and …) contributor James Strachan
- IONA’s Steve Vinoski (with a reply from Don Box again)
Confirmed by a recent discussion at work, I think a lot of the confusion around JBI is due to the amazingly stupid name (making it sound as if you’d use JBI to integrate business apps), the fact that quite a few people pitch it as an “SOA implementation” (which is stupid, since there can be no such thing in a vendor’s product, and certainly not in an all-Java solution) and idiotic lines like “This JSR extends J2EE™ with business integration SPIs” (from the JSR home page) that are totally misleading.
JBI essentially is a spec that standardizes the implementation an integration product. Whether that product runs on one or more nodes in an SOA scenario, or forms the basis of an ESB product, is not specified. JBI enables components from different vendors to work together in a single JVM - take a SOAP 1.2/HTTP binding component (BC) from one vendor, a CORBA/IIOP one from another, and coordinate applications accessed via these BC via a BPEL service engine (SE) from a third one.
I’m not entirely sure why a market-leading middleware vendor would want to support something like this, and the two most important ones (BEA and IBM) don’t.
Is JBI technically sound? I think so. Is it comparable to J2EE? I think that’s comparing apples and oranges (I’m totally with Eric here.)
Is it relevant? I honestly can’t make up my mind.