Re: [wsbpel] Interoperability, protocols, and BPEL

["Danny van der Rijn" <dannyv@tibco.com>]

you are paraphrasing me accurately, tony.  while i agree with you that BPEL
will be used to create protocols, i'm at a loss to figure out how we would
come up with a set of such protocols on which to test interoperability.
that seems far beyond the scope of what i can see anyone signing up to do.

in other words, in order to get "2) a set of BPEL implementations that
faithfully implement all of the behavioral details & edge cases in a
consistent or compatible way", i don't think it is required that coming up
with "a set of "compatible" BPEL process definitions" is required.

i am hoping that the behavioral details & edge cases that would be exercised
by such interop testing could be exercised either by other test cases, or
virtually, in people's minds.  in the end, i would hope that the spec would
be very clear on all of this stuff, and if it ends up requiring what you
describe, then so be it.

danny

----- Original Message ----- 
From: "Tony Andrews" <tandrews@microsoft.com>
To: <wsbpel@lists.oasis-open.org>
Sent: Wednesday, July 23, 2003 10:53 AM
Subject: [wsbpel] Interoperability, protocols, and BPEL


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

---------------------------------------------------------------------
To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: wsbpel-help@lists.oasis-open.org