The JSR-208 specification is an industry-wide initiative to create a standardized integration platform for Java and business applications. The spec has been in development for 18 months. Sun announced that an early draft of JSR-208 has been released, and welcomed new members JBoss and ASF, who will provide technical support. This news comes after IBM and BEA backed out.

While dissenting companies, IBM and BEA, have no intention of rejoining JSR-208, or offering any support; they will continue focusing their resources on the creation of related applications. IBM said tersely, "IBM is focusing efforts at business integration around other specs that are further along such as BPEL. IBM continues to participate as a leader in the JCP process."

Sun's Nolan said caustically that IBM and BEA were guilty of "standards voyeurism." He was referring to requests from the two companies to see the JSR-208 specification early on, before anyone else. Nolan said the companies were supporting the initiative because they wanted to preserve their customer base by offering proprietary extensions. He said IBM and BEA would "jump back in" if JSR-208 is successful.

Read more: JBoss and ASF Join Java Business Integration Initiative

I'm much more interested in this spec now that BEA/IBM have jumped. They obviously think it threatens their bottom line somehow. I'm also more interested now the ASF/JBoss have jumped in. It sounds like it will be a very viable piece of functionality.

The supposedly novel utility of JBI has already been debunked. Almost all of its major features collide with existing standards, such as BPEL and JCA. Only its NMS offers a hint of new standardization, though woefully inferior to the leading commercial service buses, integration brokers, and workflow managers. Also, JBI lacks the essential facility of semantic mapping, ala Microsoft's BizTalk Mapper.

BEA and IBM were right to complain about its current sorry incarnation, but if they had stayed, they could have helped expand JBI to encompass important integration functionality not yet sufficiently standardized.

I would be interested to hear why you think that BPEL and JBI clash, since I don't see it.

I would be interested to hear why you think that BPEL and JBI clash, since I don't see it.

BPEL is very important. BPEL is a scripting language, like Ant, so it's closest to the business processing. BPEL is the ultimate container, and doesn't necessarily need a fluffy wrapper. Nearly everything above BPEL is just tooling, the stuff vendors are supposed to compete at. IBM and BEA know this. JBI needs to better explain why BPEL projects aren't yet portable. Then JBI would have a point.

Of course there's still the matters of semantic data mapping, but JBI doesn't cover that.

Where's JBI's security API? JBI says "The NMS may choose to reserve certain property names to declare QoS, security, transaction, or other operational meta-data." May?! Does that sound like standardization to you? WS-Security and WS-Transaction are at least two years old. JBI's wire protocol is WSDL, so why can't JBI endorse existing WS-* standards? Why is discovery unmentioned in JBI? Is it presumed to be UDDI as suggested by BPEL?

Of course, I agree with you that BPEL is very important. However, I'm not sure I would generically describe BPEL as a scripting language although one might implement it that way. Also, I would characterize BPEL as a solution to a relatively <em>narrow</em> set of concerns related to service orchestration.

It's important to understand that a BPEL process is separate from the concrete service interfaces that it invokes or exposes at runtime. Specifically, a BPEL partner link is an abstract WSDL-typed port that is <em>not intrinsically</em> associated with any concrete service endpoint. This kind of pluggability is a key feature of BPEL.

In JBI terms, a BPEL "service engine" in a JBI "environment" has its partner links connected directly to the NMS, and the bindings between a partner link and a concrete endpoint are realized by "business connectors".

For some of your other questions, think of external contexts and internal contexts separately. For example, WS-Security is a protocol-level concern, so that would be dealt with in the context of a "business connector", and it would be the responsibility of the connector to bridge the external security context (described according to WS-Security) with the internal security context (managed by the JBI container). This is generic -- any WS-Security implementation is responsible for converting the message-level information into something that the internal service implementation understands.

However, I'm not sure I would generically describe BPEL as a scripting language although one might implement it that way.

I consider BPEL a scripting language because its mission is almost identical to Bash. Both regard external processes as black boxes, and the mission of both is to orchestrate them.

Brian,

I think that the challenge here is that JBI is poorly named and defined.

One of the most interesting aspects of WS-* is the binding capability of WSDL. WSIF is a proof of that: It allows one to use WSDL and XML Schema as metadata while leveraging native transports and data formats at runtime. That unified metadata is key and extend SOA and WS-* to the edge where not everything is SOAP and HTTP, not even XML.

Think of JBI as a standard WSIF++: WSIF with true 2-way interaction capability and more advanced binding features.

Finally, the last confusion about JBI is that the API it exposes are not targeted to Java developers but to binding and BPEL engine developers. As such you comment about BPEL, WSDL and WS-* being the ultimum API for the developer is correct.

If JBI can successfully solve the WSIF++ problem, it will be a huge success.

Edwin
(Oracle - http://otn.oracle.com/bpel)

I couldn't agree more with Edwin. He is absolutely right.

The problem with JBI is that, the message hasn't come across clearly as to who the target audience is for JBI. JBI is not for end-user/application developers. It is for system integrators trying to plug-in their legacy components into the mainstream.

WSIF, plus the server side equivalent of WSIF (which is what I think Edwin is referring to as WSIF++) is really what is useful and what JBI should clearly address.

Sastry Malladi
SpikeSource