W3C home > Mailing lists > Public > public-ws-chor@w3.org > January 2003

RE: Yet Another Choreography Specification

From: <ChBussler@aol.com>
Date: Thu, 30 Jan 2003 18:59:10 -0500
To: arkin@intalio.com ("Assaf Arkin"), bill.flood@sybase.com, public-ws-chor@w3.org
Cc: W.M.P.v.d.Aalst@tm.tue.nl, m.dumas@qut.edu.au, l.aldred@qut.edu.au, a.terhofstede@qut.edu.au, chbussler@aol.com
Message-ID: <62B35209.7E216DBF.02220297@aol.com>


there is another question altogether. 'Plain' web services distinguish the interface (WSDL) from implementation (your favorite programming language).

Complex web services have the same issue: distinguishing the external behavior from the implementation that enforces the external behavior.

The question is if you need a 'full' workflow/process/etc. language for the external behavior definition if this distinction is made. So I suggest this discussion, too, at least concurrently, if not upfront.



In a message dated 1/30/2003 5:42:18 PM Eastern Standard Time, "Assaf Arkin" <arkin@intalio.com> writes:

>I tend to agree with W.M.P. van der Aalst and the conclusion, though I would
>disagree on the context in which it is presented.
>In our research we have concluded that a modern process language, in
>particular one that makes extensive use of messaging, should be based on
>PetriNet and process algebra. While PetriNet is sufficient for modeling
>internal activities, it lacks the ability to describe interactions between
>concurrent distributed systems. This is where we see the value of process
>I have used both models to guide me in working on both BPML and WSCI. That
>would answer one of the most commonly asked questions: why does BPML and
>WSCI look different from languages based purely on PertiNets? The difference
>stems from the introduction of process algebra into the underlying model.
>I would definitely urge the WS Choreography WG to look at models that
>combine PetriNet with process algebra and pursue the development of a
>specification along these lines.
>> -----Original Message-----
>> From: public-ws-chor-request@w3.org
>> [mailto:public-ws-chor-request@w3.org]On Behalf Of bill.flood@sybase.com
>> Sent: Tuesday, January 28, 2003 3:54 PM
>> To: public-ws-chor@w3.org
>> Cc: W.M.P.v.d.Aalst@tm.tue.nl; m.dumas@qut.edu.au; l.aldred@qut.edu.au;
>> a.terhofstede@qut.edu.au
>> Subject: Yet Another Choreography Specification
>> All,
>> I seriously considered joining this working group but have deferred that
>> decision to better try to understand the direction that it is taking.
>> Examining WSCI, BPEL4WS (XLANG., WSFL), BPML, XPDL, and the host of other
>> "specifications" or notes does not seem fruitful without some ability to
>> understand them in context of the entire problem.
>> What is needed is a neutral justification for defending the arrived-upon
>> stance.  I'm afraid the alternative is that WS-Chor will simply be another
>> impotent footnote rendered meaningless by the vendors that have their
>> favorite specification and the ability to push them forward.  After all,
>> minus a logical argument, why should one vendor endorsed standard give way
>> for just another unjustified standard?
>> An excellent article on this subject can be found at:
>>      http://tmitwww.tm.tue.nl/research/patterns/ieeewebflow.pdf
>> The author is on the CC list and my hat is off to him and his colleagues
>> for this valuable work.  I hope that the vendor community can learn from
>> their efforts.
>> This article is really about recognizing the entire range of workflow
>> patterns that address more than the subsets presented through vendor
>> specific approaches.  A markup language has been developed (YAWL) that
>> describes these patterns in XML.  Researchers have also mapped from
>> vendor-specific markups to the patterns.
>> The WS-Chor, in my belief, will only be successful if it takes the high
>> road - a defensible position that avoids pitting one vendor approach
>> against another (or for that matter one standards organization against
>> another).  If the WS-Chor can see itself in a position of supporting a
>> neutral approach to the choreography issue, the industry as a whole will
>> benefit and I will be there to support it.
>> Best Regards,
>> --Bill Flood, Sybase
>> Supporting documents in a similar vein can be found at:
>> http://idevnews.com/CaseStudies.asp?ID=52
>> http://www.daimi.au.dk/CPnets/workshop02/cpn/slides/w_aalst.ppt
>> http://tmitwww.tm.tue.nl/research/patterns/yawl_qut_report_FIT-TR-2002-0

Christoph Bussler
Received on Thursday, 30 January 2003 19:02:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:29:52 UTC