RE: Case for multi-party choreography

+1. If we don't do multiple party choreography, then B2B will need to invent
it as it can't work without it!
 
David

-----Original Message-----
From: Ricky Ho [mailto:riho@cisco.com]
Sent: Monday, March 17, 2003 1:09 PM
To: Furniss, Peter; public-ws-chor@w3.org
Subject: 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 <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