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 Monday, 24 March 2003 19:52:13 UTC