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

Edwin,

In your example, you haven't covered the contract of collaboration between 
the receptionist and the doctor.  After your break down, there is nothing 
saying that step (1) must happen before step (2).  It is possible that a 
doctor say "I'm available" but then no patient shows up.

Look at the pre-requisite of "MedicineDelivery" service.  It may not be 
sufficient by just having the Prescription Receipt.  What if step (7) 
hasn't happened.  the doctor hasn't told the receptionist to prepare 
medicine so even though the patient presents the prescription receipt, the 
receptionist is not going to delivery the medicine.

Similar argument in "DoctorService", the pre-requisite is not 
sufficient.  What if the doctor hasn't been asked by the receptionist 
before the patient shows up in his door with the appointment receipt.

Of course, if the private implementation behaves correctly, then the above 
problem will not happen.  But there is no way you can specify that unless 
you use a multi-party choreography, rather than breaking down into multiple 
bi-party ones.

Best regards,
Ricky

At 04:52 PM 3/24/2003 -0800, Edwin Khodabakchian wrote:
>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:40:23 UTC