Interoperability, protocols, and BPEL

["Tony Andrews" <tandrews@microsoft.com>]

I just wanted to follow up on one comment made during the call today.
During the interop discussion, the statement was made that one typically
thinks of interoperability in the context of protocols definitions, and
since BPEL isn't a protocol we should be more concerned about
portability (I hope I've paraphrased accurately).

I just wanted to add that while BPEL isn't itself a protocol, it *will*
be used to define application-level protocols, so in that respect
interoperability is very relevent. For our users to build processes that
successfully interoperate two things will be required 1) a set of
"compatible" BPEL process definitions, and 2) a set of BPEL
implementations that faithfully implement all of the behavioral details
& edge cases in a consistent or compatible way.
 
The first requirement can be satisfied through static analysis, and IMO
part of our job is to ensure that BPEL enables the creation of such
tools. A precise definition of BPEL's operational semantics (in some
appropriate form) would go a long way toward satisfying the second
requirement and would give us a way of sorting out the interoperability
issues between implementations which are bound to arise.

A standard for protocol description (& execution) is only useful if
everyone can agree about not only what they will accept as input (i.e.
compile & execute), but also about precisely how they will behave in
response to that input. Maybe people feel that this is just another
aspect of portability, but I think it's a little deeper and more subtle
than that.

Thanks, Tony