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

RE: Yet Another Choreography Specification

From: Alistair Barros <abarros@dstc.edu.au>
Date: Fri, 31 Jan 2003 12:13:41 +1000
To: <ChBussler@aol.com>, "\"Assaf Arkin\"" <arkin@intalio.com>, <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: <HIEFLCBPHBOMEAGKKEPICEEJCEAA.abarros@dstc.edu.au>

I agree, a distinction needs to be made for external
service coordination. This is important when long-running
(web) services - each encapsulating one or more workflows -
interact in B2B style applications.

I can think of at least three sources that have considered
the issue of external service coorination:

  - Biographical reactive systems proposed by Robin Milner in:
    "Bigraphs as a model for Mobile Interaction", First International
    Conference, ICGT 2002

  - In OMG's specification of an enterprise component
    framework, UML Profile for EDOC, there is a modelling
    provision (Component Collaboration Architecture) which is
    devoted to capturing external interactions regardless of
    internal implementations (workflows, EJBs etc). The CCA model
    is at the FTF stage -

  - Inter-workflow messaging and workflow service models
    proposed by Arthur ter Hofstede and myself. A discussion
    was provided in "Retrofitting workflows for B2B component
    assembly", 25th International Conference, COMPSAC 2001.
    (I can provide a copy for anyone interested).

Cheers, Alistair.

-----Original Message-----
From: public-ws-chor-request@w3.org
[mailto:public-ws-chor-request@w3.org]On Behalf Of ChBussler@aol.com
Sent: Friday, 31 January 2003 9:59 AM
To: "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
Subject: RE: Yet Another Choreography Specification


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
>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
>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
>> 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
>> 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 21:44:46 UTC

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