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

RE: Yet Another Choreography Specification

From: Assaf Arkin <arkin@intalio.com>
Date: Thu, 30 Jan 2003 14:42:18 -0800
To: <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>
Message-ID: <IGEJLEPAJBPHKACOOKHNCEBJDCAA.arkin@intalio.com>

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 Thursday, 30 January 2003 17:43:15 GMT

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