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

Comments embedded

At 05:22 PM 3/25/2003 +0000, Furniss, Peter wrote:
>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.

I'm assuming you agree that this is a multi-party choreography which cannot 
be broken down into multiple bi-party scenario.
Under this assumption, these are 2 different multi-party choreographies 
because the reception/doctor interaction has been changed.  It just happens 
that from a particular party's view (ie: patient), the interaction sequence 
is the same.


>Since, as Edwin points out, the Doctor doesn't really care how the
>patient got the appointment receipt,

What if the doctor want to make sure he is being asked for availability 
before the patient shows up ?

Rgds, Ricky

>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 15:53:55 UTC