RE: Yet Another Choreography Specification

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 -
    http://www.omg.org/cgi-bin/doc?ptc/2002-02-05

  - 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



Hi,

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.

Thanks,

Christoph

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


--
------------------------------------------------------
Christoph Bussler
ChBussler@aol.com
hometown.aol.com/ChBussler/
www.google.com/search?q=bussler
www.google.com/search?hl=en&q=bussler&btnI=I%27m+Feeling+Lucky
------------------------------------------------------

Received on Thursday, 30 January 2003 21:44:46 UTC