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
>