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

I would recommend starting with a previos article by Milner's called
"Calculi for Interaction". It describes Action Calculi which is required
reading in order to understand bigraphs:

ftp://ftp.cl.cam.ac.uk/users/rm135/ac9.ps

In there you will find a model that unifies PetriNet with process calculi by
describing the system as a set of concurrent processes, and also covering
controls. More information about push outs is available here:

http://pauillac.inria.fr/~leifer/articles/leifer-synlt1.pdf

Bigraphs then introduce a graphical model that can describe both the
interaction between the processes (the monograph) and the interactions
within each process (the topograph) using actions, controls and pushouts:

http://www.cl.cam.ac.uk/~rm135/bigraphs.ps.gz

Of course, I am biased when I stress the importance of these models for the
development of concurrent distributed systems ;-)

arkin

>
>   - 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 Friday, 31 January 2003 01:52:59 UTC