2pc as bilateral (from RE: General Choreography and Bi-lateral Choreography)

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