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

good idea about having pictures for the use cases

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
> 
>   ------------------------------------------------------------------------
>                                 Name: 3Part_Pat-Recp-Doc.jpg
>    3Part_Pat-Recp-Doc.jpg       Type: JPEG Image (image/jpeg)
>                             Encoding: base64
>                          Description: 3Part_Pat-Recp-Doc.jpg
> 
>                                   Name: 3_2Part_Pat-Recp-Doc.jpg
>    3_2Part_Pat-Recp-Doc.jpg       Type: JPEG Image (image/jpeg)
>                               Encoding: base64
>                            Description: 3_2Part_Pat-Recp-Doc.jpg

Received on Wednesday, 26 March 2003 14:26:40 UTC