Re: [wsbpel] Interoperability, protocols, and BPEL

[Monica Martin <monica.martin@sun.com>]

Danny van der Rijn wrote:

>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.
>  
>
mm1: However, there could be a subset that is required to enable 
interoperability and that could be beneficial in many ways.  That gets 
back to ensuring consistency in the specification to encourage 
conformance and enable interoperability.

>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
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
>For additional commands, e-mail: wsbpel-help@lists.oasis-open.org
>
>  
>