RE: More about the patient/receptionist/doctor use case.

Nice example. Suppose, due to an epidemic (of an internal complaint :-),
the doctor and receptionist change their interactions, so there are also
sequences like

a) Doctor informs Receptionist he is available all morning
b) Doctor asks Receptionist to ensure there is always a stock of 5 doses
of the
   medicine for the current epidemic

1) Patient sends a "I want to see doctor" message to the Receptionist

   Receptionist selects doctor from those available

5) Receptionist send a "Go see doctor" message to the Patient
6) Patient send a "I feel sick" message to Doctor

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

Of course, if the patient's problem isn't the common disease, the
original 7 applies.

Is it the same choreography for the patient ?  The interactions
involving the patient are the
same. The underlying semantics of all the messages is the same (e.g.
AppointmentReceipts identify available doctors, PrescriptionReceipts
identify medicine that will be available).  The way by which the
receptionist and doctor know that they are issuing semantically truthful
messages has changed - but that only affects the patient as a sort of
QoS issue.

Would it count as the same choreography if a) and b) used the same 3)
and 7) messages pre-emptively.

Since, as Edwin points out, the Doctor doesn't really care how the
patient got the appointment receipt, and the receptionist doesn't know
what motivated the doctor to ask for the medicine whether this should be
broken down into two-party choreographies, or into one-party service
definitions may depend on what the intent of a choreography
specification is - internal, external or global.


Peter




> -----Original Message-----
> From: Edwin Khodabakchian [mailto:edwink@collaxa.com] 
> Sent: 25 March 2003 00:52
> To: 'Ricky Ho'; jdart@tibco.com
> Cc: public-ws-chor@w3.org
> Subject: More about the patient/receptionist/doctor use case.
> 
> 
> 
> Ricky,
> 
> I would like to propose a different grouping of these sets of 
> interactions that will enhance reuse, increase the level of 
> decoupling and make sure that in case of exceptions there is 
> a clear notion of responsibality.
> 
> <<<<<<<<<
> 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
> >>>>>>>>>
> 
> Suggested break down:
> 
> Service 1: Appointment Management Service
>    Input:    
>       AppointmentRequest.
>    Output:   
>       AppointmentReceipt.
>    Provider: 
>       Receptionist.
>    Pre-requisit: 
>       If you know how to create an AppointmentRequest, you 
> can participate.
>    Covers Interactions: 
> 	1, 2, 3, 4, 5
>    Note:
>       2, 3, 4 are really private implementation of that 
> service and define
>       the logic of how the receptionist orchestrates the private flow 
>       needed to implement the service.
> 
> Service 2: DoctorService
>     Input:  
> 	AppointmentReceipt
>     Output: 
> 	PrescriptionReceipt
>     Provider: 
> 	Doctor
>     Pre-requisit: 
> 	Again from the patient point of view this is a simple request
>       response interactions. To participate, the patient needs an 
>       AppointmentReceipt. How he gets it is not important I think:
>       We want the doctor service to be reusable.
>     Covers Interaction:
>       6, 7, 8
> 
> Service 3: MedicineDelivery
>     Input:     
>     	PrescriptionReceipt
>     Provider: 
> 	Receptionist
>     Pre-requisit: 
>       If you have a PrescriptionReceipt, you can participate.
>     Covers:
>       9,10
> 
> Thoughts?
> 
> Edwin
> 
> > -----Original Message-----
> > From: public-ws-chor-request@w3.org
> > [mailto:public-ws-chor-request@w3.org] On Behalf Of Ricky Ho
> > Sent: Monday, March 24, 2003 4:06 PM
> > To: jdart@tibco.com; Daniel_Austin@grainger.com
> > Cc: public-ws-chor@w3.org
> > Subject: Re: requirements summary
> > 
> > 
> > 
> > I was originally thinking that a multi-party choreography can
> > always be 
> > broken down into multiple "inter-dependent" bi-party 
> > choreography.  But I 
> > am convinced that this is NOT always possible.
> > 
> > See
> > http://lists.w3.org/Archives/Public/public-ws-> 
> chor/2003Mar/0052.html
> > 
> > So I think bi-party choreography is a special case of multi-party
> > choreography.  Bi-party choreography has some interesting 
> > properties that 
> > can simplify the modeling.  (e.g. Bi-Party choreography 
> > doesn't need to 
> > worry about dynamic participation because any change of a 
> binding can 
> > simply terminate the choreography).
> > 
> > I think we should covered multi-party choreography.  In
> > additional, we may 
> > also need to investigate this special subset called bi-party 
> > choreography.
> > 
> > Best regards,
> > Ricky
> > 
> > At 02:28 PM 3/24/2003 -0800, Jon Dart wrote:
> > 
> > >Daniel_Austin@grainger.com wrote:
> > >>2. Multi-party vs. bilateral choreography: there is some 
> skepticism
> > >>that modelling bilateral interactions is sufficient.
> > >>       I certainly don't think that is it sufficient to 
> model only 
> > >>bilateral transactions. Many business transactions have multiple 
> > >>actors, and we want to build standards that will work for common 
> > >>service transaction models.
> > >
> > >Note that it is not exactly all or nothing here. BPSS for example
> > >supports
> > >"MultiParty Collaborations", but does so by composing them 
> > out of "Binary
> > >Collaborations".
> > >
> > >--Jon
> > >
> > >
> > 
> > 
> 
>

Received on Tuesday, 25 March 2003 12:23:34 UTC