Case for multi-party choreography

I'm starting to be convinced by Assaf that multi-party choreography is not 
that rare and so there isn't a need to separate out bi-party 
choreography.  Maybe 2PC is not a good example.  Let me try the 
patient/receptionist/doctor

1) Patient send a "I want to see doctor" message to the Receptionist
2) Receptionist send a "Are you available ?" message to a a list of Doctors
3) One doctor send a "I'm available" message to the Receptionist.
4) Receptionist send a "I'll book you" message to the Doctor.
5) Receptionist send a "Go see doctor" message to the Patient
6) Patient send a "I feel sick" message to Doctor
7) Doctor send a "Prepare this medicine" message to Receptionist
8) Doctor send a "Pickup your medicine and you can leave" message to Patient
9) Patient send a "I need my medicine" message to Receptionist
10) Receptionist send a "Here is your medicine" message to Patient

If I break down into three bi-party choreographies,

Patient / Receptionist
Steps: 1, 5, 9, 10

Patient / Doctor
Steps: 6, 8

Receptionist / Doctor
Steps: 2, 3, 4, 7

Then how do I enforce the followings ...
Step 2 happens after step 1
Step 5 happens after step 4
Step 6 happens after step 5
Step 7 happens after step 5
etc...

Best regards,
Ricky

At 11:56 AM 3/17/2003 +0000, Furniss, Peter wrote:
>Good challenge :-)
>
>Yes, there are three choreographies, but the relation between them can be 
>viewed as by reference, or by contract. The real 2pc relationship is only 
>the Coordinator:Provider one. The "doWork" message passes a reference to 
>the Coordinator (probably termed a context). The coordinator/provider 
>exchange is often fully defined without reference or knowledge of the 
>details of that. (sometimes there may be something in the same document, 
>but it is separable, and usually only on of several alternatives). The 
>context could be passed to the provider (to be used in the enrollment) by 
>lots of different methods and how it gets there is not central to 2pc.
>
>The consumer/coordinator relationship is more closely related, but is also 
>not a necessary part of 2pc - it is the means by which the consumer 
>delegates control of the 2pc to the coordinator. In general, 2pc does 
>*not* imply atomicity, it only allows it. The coordinator in your example 
>is following the (normal) rule of all-or-none among its enrolled 
>participants. But it could offer a service to the consumer that involved 
>passing some other rule (ensure confirmation from exactly three (or none), 
>say). Those variations do not change the interactions between the 
>coordinator and the provider(s) - the providers still get to see regular 
>2pc.  Defining the behaviour of the coordinator is part of its contract 
>with the consumer.  I agree that is perhaps most easily expressed by 
>assuming all the coordinators communcations use directly inter-expressible 
>choreographies.
>
>But the primary reqirement is to express the message patterns and their 
>meanings between directly communicating pairs. Then you don't have to 
>worry about how the communications "behind" the other party are 
>implemented (the "consumer" and "coordinator" may be in the same address 
>space and communicate by proprietory api, for example), nor what level of 
>visibility, ownership and control is.
>
>
>Peter
>
>
>-----Original Message-----
>From: Ricky Ho [mailto:riho@cisco.com]
>Sent: 17 March 2003 08:04
>To: Furniss, Peter; public-ws-chor@w3.org
>Subject: RE: General Choreography and Bi-lateral Choreography
>Peter, use the following simple example, can you show me how a 2PC can be 
>broken down into multiple bi-lateral choreograpies ?
>
>1) Consumer send a "startTransaction" message to Coordinator and get back 
>a transaction id
>2) Consumer send a "doWork" message to a Provider
>3) Provider send "enroll" message to Coordinator
>4) Provider send a "workResult" message to the Consumer
>5) Consumer send a "commit" message to Coordinator
>6) Coordinator send a "prepare" message to Provider
>7) Provider send back a "prepared" message or a "cancelled" message
>8) If all providers send back a "prepared" messages, the coordinator send 
>a "commit" message to all providers.
>>2-pc can certainly be defined, precisely and fully, involving only two 
>>parties. This was done in the OSI Commitment, Concurrency Recovery (CCR) 
>>spec [ in fact, because standards politics meant it wasn't allowed to 
>>have normative multi-party text, but also was required to have normative 
>>semantic definition], and is also (I hope) complete in the BTP 
>>specification of the "outcome" protocol (the superior:inferior bit). 
>>There are implications for what is going on with other parts of the 
>>transaction tree, but the fundamental protocol is in fact two-party. (my 
>>diagram with the 3 dumbells and the box, on about my 4th slide was meant 
>>to show this, but I fear may not have explained it well] (I mention CCR 
>>and BTP because I know them - there may be other specs of similar nature)
>>
>
>I'm guessing you'll break down the above into multiple choreographies in 
>the following ways
>
>Consumer / Coordinator choreography
>Steps 1, 5
>
>Consumer / Provider choreography
>Steps 2, 4
>
>Coordinator / Provider choreography
>Steps 3, 6, 7, 8
>
>But then how do we express the following dependencies
>Step 1 has to happen before step 2.  Step 2 happen before 3, 3 before 4, 4 
>before 5
>
>Rgds, Ricky