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

RE: Internal processes and/or external choreographies (was RE: Ev ents and States ...

From: Burdett, David <david.burdett@commerceone.com>
Date: Sun, 13 Apr 2003 16:12:03 -0700
Message-ID: <C1E0143CD365A445A4417083BF6F42CC053D1993@C1plenaexm07.commerceone.com>
To: "'Assaf Arkin'" <arkin@intalio.com>, "Burdett, David" <david.burdett@commerceone.com>
Cc: "'Martin Chapman'" <martin.chapman@oracle.com>, "'Cummins, Fred A'" <fred.cummins@eds.com>, jdart@tibco.com, public-ws-chor@w3.org

Assaf

Thanks for doing this, it really helps! Below I copy the essence of your
definition of the External Choreogaphy, and then ask a few
questions/comments ...

EXTERNAL CHOREOGRAPHY
process buyerSeller (Note could be called Choreography xxx instead of
Process xxx)
  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  

QUESTIONS/COMMENTS
1. I don't think I would call it "process buyerSeller" as buyer and seller
are roles and they can have more than one choreography between them. I also
like the word Choreography rather than process (as you describe), so perhaps
a better name  would be something like "Choreography orderManagement".

2. Following on in the same theme, using "process seller" and "process
buyer" is ambiguous as you will have more than one process at the buyer and
seller. So how about "process acceptOrder" and "process placeOrder" where
each has a property that identifies the role which performs the process
giving you: "process acceptOrder, role seller" and "proccess placeOrder,
role buyer".

3. The two statements "receive order" and "send order" are not targeted at
any particular role. If you have more than two roles (I know this example
hasn't) then where a message is sent to or comes from is not clear. So would
it make sense to have, instead, "send order to seller" and "receive order
from buyer"? Alternatively would it make even more sense to target the
process at the buyer or seller as in "send order to seller:acceptOrder" and
"receive order from buyer:placeOrder"?

4. In the current definitions, the sending and receiving of the order is
defined separately for each role/process. There is nothing that separately
identifies the sending of a message. Therefore there is no single place to
define its semantics. Would it make sense to separately define:
  a) The Message first (strictly I mean the Message Family),
  b) The Interactions, i.e the sending of a message in a message family
(this would let you distinguish between instances when the same message is
sent more than once), this could also then define the from and to roles /
processes.
  c) The use of the interactions in the individual processes (e.g. process
AcceptOrder)

5. For each choreography to be correct, each send of a message of a
particular type, must have a corresponding receive and vice versa. How do
you check the individual processes to make sure that this is correct? Also,
how do you make sure that the individual processes exchange messages in the
correct sequence? For example, you could have the following incorrect
choreography ...

process buyer (placeOrder)
  receive orderResponse
  ...
  send order
  ...
  receive errorResponse

process seller (acceptOrder)
  receive order
  ...
  send orderResponse

... which is wrong as there is a receive (errorResponse) without a sendand
the sequence of sends and receives is wrong (receive orderResponse before
the send). It's also doesn't seem obvious (to me) how to easily spot the
mistake. A more intuitive (but not necessarily better) approach might be to
have a single definition that covers both roles from which individual roles
can be extracted as in, for example ...

Choreography OrderManagement
  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

... in this case you just need to check that for every send of a message to
a role there is one receive. The dependencies and sequencing of the messages
are implicit and each statement stands on its own and could, in theory occur
in any sequence. However this does not seem to map to the internal business
processes so easily.

6. I also have some questions about composing one choreography out of two or
more others, but think we should save that for later ;)

Thoughts?

David



-----Original Message-----
From: Assaf Arkin [mailto:arkin@intalio.com]
Sent: Saturday, April 12, 2003 2:36 PM
To: Burdett, David
Cc: 'Martin Chapman'; 'Cummins, Fred A'; jdart@tibco.com;
public-ws-chor@w3.org
Subject: Re: Internal processes and/or external choreographies (was RE:
Ev ents and States ...


Burdett, David wrote:

>Assaf
>
>You seem to have a very clear idea of how both requirements (internal and
>external definitions) can be met by one language based on pi-calculus.
>
Or even two different languages which are simply designed based on some 
common principal to allow that.
</snip>
Received on Sunday, 13 April 2003 19:12:19 UTC

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