RE: Yet Another Choreography Specification

Assaf,

Thanks very much for these pointers.  I wonder, are there any resources that
might bridge the gap between theoretical treatments of pi-calculus and its
manifestation in or influence on the BPML specification?  I've read numerous
papers on pi-calculus, and I've pored through the BPML spec many times, and
I'm afraid I'm missing the connection.

Regards,
Ed

> -----Original Message-----
> From: public-ws-chor-request@w3.org
> [mailto:public-ws-chor-request@w3.org]On Behalf Of Assaf Arkin
> Sent: Friday, January 31, 2003 1:52 AM
> To: abarros@dstc.edu.au; ChBussler@aol.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
> Subject: 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 10:53:20 UTC