- 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