W3C home > Mailing lists > Public > public-ws-chor@w3.org > April 2003

RE: Terminology - What is a process? Was: Internal processes an d/or external choreographies (was RE: Ev ents and States ...

From: Burdett, David <david.burdett@commerceone.com>
Date: Tue, 15 Apr 2003 21:47:57 -0700
Message-ID: <C1E0143CD365A445A4417083BF6F42CC053D19B5@C1plenaexm07.commerceone.com>
To: "'Miles Sabin '" <miles@milessabin.com>, "'public-ws-chor@w3.org '" <public-ws-chor@w3.org>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:00:58 UTC