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

Re: Yet Another Choreography Specification

From: Steve Ross-Talbot <steve@enigmatec.net>
Date: Fri, 31 Jan 2003 06:54:13 +0000
Cc: <bill.flood@sybase.com>, <public-ws-chor@w3.org>, <W.M.P.v.d.Aalst@tm.tue.nl>, <m.dumas@qut.edu.au>, <l.aldred@qut.edu.au>, <a.terhofstede@qut.edu.au>
To: "Assaf Arkin" <arkin@intalio.com>
Message-Id: <CEA1D0E0-34E8-11D7-AB48-000393AD2AA6@enigmatec.net>

I have also tracked the use of PetriNets and process algebras.  
PetriNets tends to be understood on a more intuitive level whereas  
process algebras are a little more tricky to get a handle on. I think  
it is pretty important that we level the playing field on formalisms so  
that people are more comfortable around them (particularly process  
algebras).

I know Assaf has some experience of both pi and join calculus. I could  
probably get Prof Robin Milner involved so that we can understand more  
fully the relationship between the requirements that we write down and  
the expressive power of pi-calculus. I am sure that we would also be  
able to handle the blend of pi and PetriNets and possibly show that one  
subsumes the other.

On Thursday, January 30, 2003, at 10:42 PM, Assaf Arkin wrote:

>
> 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
> algebra.
>
> 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.
>
> arkin
>
>> -----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
>
Received on Friday, 31 January 2003 01:50:20 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 18 December 2010 01:00:00 GMT