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

Thanks !  Exactly correct !

At 09:30 AM 3/26/2003 -0800, Stephen White wrote:
>I was having trouble following the use case as a text description, so I 
>made up a couple of diagrams to help me follow the example. There is a 
>diagram with a 3-party choreography (3Part_Pat-Recp-Doc.jpg) and three 
>separate diagrams of the individual 2-party choreographies (within 
>3_2Part_Pat-Recp-Doc.jpg). I am sending in the diagrams to help those like 
>me who need to see pictures.
>
>A note about the diagrams: The activities of the three parties are 
>separated by swimlanes. The solid lines between activities indicate the 
>sequence of activities for each party. The dashed lines show the flow of 
>messages between the parties. I numbered the messages as was presented in 
>the example. The activities within the swimlanes represent only the 
>interface for that party. Presumably, there are activities that go on 
>behind the scenes, but are not modeled in the choreography.
>
>-Steve
>
>-----Original Message-----
>From: Ricky Ho [mailto:riho@cisco.com]
>Sent: Tuesday, March 25, 2003 1:46 PM
>To: edwink@collaxa.com; jdart@tibco.com
>Cc: public-ws-chor@w3.org
>Subject: 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.
> >
> >I am not sure that I understand your point:
> >Are you trying to say that it is important that the patient knows how
> >the receptionist query doctors or that once an appointment receipt has
> >been generated, the patient might decide not to show up and you want to
> >manage the appropriate timeout and release of resources?
>
>No.  The patient doesn't care but the doctor may care.
>In a multi-party choreography, this is NOT just the patient's concern, but
>also the receptionist as well as the doctor's concern.
>
>
> > > 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.
> >
> >This is where I think that the notion of responsibility is important. I
> >expect the doctor service to do the right thing and issue a valid
> >prescription receipt. If the receipt end up being invalid, I can go back
> >to the doctor and complain.
>
>Yes, but how do you express that responsibility in the choreography
>definition ?
>
>
> > > 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.
> >
> >Same as previous answer here. The appointment receipt is contractual
> >binding. The receptionist is responsible for offering that service. In
> >my opinion, micro managing how the service is provided creates
> >unecessary complexity and seems going against how business operate
> >today.
> >
> >The point that I was trying to make is NOT that multi-party interactions
> >do not exist and should not be modeled. My point is that given the
> >business and legal contractual overhead of collaboration, most
> >interactions tend to orbit towards bi-party interactions. Those bi-party
> >interactions can be interlinked in a very loosely-coupled fashion using
> >"typed" contractual documents.
>
>I agree.  I certainly think the majority use cases are bi-party contract.
>
>Best regards,
>Ricky
>

Received on Wednesday, 26 March 2003 13:55:49 UTC