OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [wsbpel] Interoperability, protocols, and BPEL


Tony Andrews wrote:

>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.
> 
>
mm1: Agreed. If you provide different mechanisms to accomplish a 
function in the specification, that is an area where
interoperability could become an issue. Efforts are ongoing in the 
business process arena to test first conformance and then 
interoperability (BPSS), so the point is relevant.

>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
>
>
>  
>




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]