In my previous post ("What Does Sun See Beyond SeeBeyond?"), I discussed Phil Wainewright's concerns around the openness and maturity of Java Business Integration (JBI). In his Loosely Coupled Weblog, Wainewright states that IBM and BEA feel JBI may be too closely tied to Java, rather than being completely language independent.
There are other voices that say JBI is just what is needed for SOA development, however. PolarLake's Ronan Bradley, for one, says JBI "provides the core standards required to build SOA-based integration server software. I believe, that JBI is the only way forward, and it should be watched with interest as it evolves."
Bradley opines in a recent post that "JBI provides the core standards required to build SOA-based integration server software. It focuses on standardizing the interoperation semantics (and associated bindings and interfaces) between what it calls service engines and a normalized message router, which links the engines together." JBI does not define what service engines are required, which can be anything from the generic (such as BPEL engines, business rules engines and transformation services) to a service specific to an organization’s solution.
While Bradley adds that BPI is more focused on the vendor community than the user community, benefits will trickle down to users in terms of increased ease in plugging together best-of-breed service engines, and increased compatibility between integration products – "making it easier to create solutions spanning multiple products: overcoming the common problem of ‘islands of integration’. Web services on its own is helpful (as is XML-based messaging), but JBI takes it a step further."
In addition, Bradley observes, "I strongly believe that JBI and BPEL [Business Porcess Execution Language] are complementary technologies: JBI provides the framework to build a SOA-based integration layer, BPEL provides the standard for one of the key capabilities: orchestration."