- From: Burdett, David <david.burdett@commerceone.com>
- Date: Tue, 15 Apr 2003 21:47:57 -0700
- To: "'Miles Sabin '" <miles@milessabin.com>, "'public-ws-chor@w3.org '" <public-ws-chor@w3.org>
- Message-ID: <C1E0143CD365A445A4417083BF6F42CC053D19B5@C1plenaexm07.commerceone.com>
To sum up I have, in recent email threads, observed several different styles
of defining a choreography ...
THE PI-CALCULUS approach as defined by Asaf, for example:
process buyerSeller
process buyer
process seller
process seller
receive order
switch
case conditionX
send orderResponse
default
send errorResponse
process buyer
send order
choice
case 1
recieve orderResponse
case 2
receive errorResponse
... and the EVENT DRIVEN approach, for example as ...
send order from buyer to seller
on receive order at seller
switch
case conditionX
send orderResponse from seller to buyer
default
send errorResponse from seller to buyer
on receive orderResponse at buyer
on receive errorResponse at buyer
... and the MESSAGE FLOW/STATE TRANSITION APPROACH, for example as in ...
send order from buyer to seller
(buyer postState=orderSent,
seller postState=orderReceived
)
ProcessOrder
(role=seller,
precondition=orderReceived,
postState=(choice (orderOk|orderError))
)
Send orderResponse from seller to buyer
(precondition=orderOK
seller postState=orderResponseSent
buyer postState=OrderResposneReceived
)
etc...
What the PI CALCULUS approach has going for it is a sound theoretical base.
What it does not have is an easily visible message flow in the definition,
which is at the heart of choreography design. Instead you have to infer the
message flow by matching up the sends and receives over the same channels.
What the EVENT DRIVEN approach has going for it, is that it mirrors what you
actually do since just about everything, sending a message, processing a
message, handling timeouts can be described as an event. What it hasn't got
(I believe) is a sound theoretical base that would allow one to prove tha
correctness and completeness of a design.
What the MESSAGE FLOW/STATE TRANSITION approach has going for it is that it
is much closer to the message/work flow models that business analysts use to
define a choreography. I don't believe that many business analysts tend to
think in a co-operating process stytle that is required for PI Calculus. On
the other, hand, there could be issues around how you compose one message
flow out of another with this approach.
NET, NET ...
I guess that **my** ideal approach (i.e. it's just my opinion) would be one
that combined the theoretical rigor of PI Calculus with the graphical
representations you can more easily see with Message Flow - I think that
this is what JJ was getting at. Who knows, it might even be possible to map
between a PI Calculus and a Message Flow approaches and back ... I don't
know.
What do other folks think?
David
-----Original Message-----
From: Miles Sabin
To: public-ws-chor@w3.org
Sent: 4/15/2003 3:27 PM
Subject: Re: Terminology - What is a process? Was: Internal processes
and/or external choreographies (was RE: Ev ents and States ...
Jean-Jacques Dubray wrote,
> With respect to pi-c no matter how I stear at it I don't see an
> explicit choreography specification. All I see is the specification
> of the behavior of agents which are capable of communicating which
> each other. If you take the example: _xy.0 | x(u)._uv.0 | _xz.0, it
> expresses the behavior of each agent and the composition "point" but
> by no means the "choreography" is "visible" there. Furthermore,
> pi-calculus seem to be limited to request/response message exchange
> patterns (I'd be curious to know how one would model complex MEPs).
I think there might be some truth in this.
That said, there's work being done on extending pi with "session types"
... roughly speaking these allow protocols to be encoded as the types
of channels. It's possible that this might be useful approach to making
choreographies visible in the way you want.
I think this paper,
http://www.di.fc.ul.pt/~vv/papers/stipc.pdf
by Simon Gay, Vasco Vasconcelos and and Antonio Ravara might be helpful.
Also this one,
http://www.dcs.gla.ac.uk/~simon/publications/TR-2003-131.pdf
which uses POP3 as an example of a not completely trivial protocol which
can be encoded in this way.
Cheers,
Miles
Received on Wednesday, 16 April 2003 00:48:05 UTC