- From: Assaf Arkin <arkin@intalio.com>
- Date: Tue, 25 Mar 2003 15:07:39 -0800
- To: edwink@collaxa.com
- CC: "'WS Choreography (E-mail)'" <public-ws-chor@w3.org>
Edwin Khodabakchian wrote: >Assaf, > >Just to make sure that I understand your point of view. Why isn't the >definition of the interactions between the patient and the receptionist >also called a choreography? > > There is no reason not to call it a choreography. I wanted to illustrate a choreography that has n conversations. It may well be that n=1. Regardless of how n is there is exactly one choreography instance, so the point is to distinct between the two since a choreography instance may range over n>=1 conversations. >It seems to me that you are introducing the term choreography and >conversation to address the problem of recursive composition (or lack of >it). > At this level I'm only discussing composition. There's nothing recursive about it. If you describe X as sending, Y as receiving, and X+Y as choreography that's a composition. If you describe conversation X, conversation Y, and interleaving of X, Y as choreography that's also a composition. At this level there is no recursion. >Let's imagine that we need to expand the use case and add support >of hospital ticket validation (which is described as another >choreography). Can you compose the PRD choreography with the Hospital >Ticket Validation choreography, if so how and what would you call the >result. > This is where you introduce recursion. You begin with a PRD choreography, then describe a larger choreography that includes Ticket Validation. When you include one choreography within another you get recursive composition, since you can do it over and over at different levels. You can also have overlapping not-nested choreographies. 1. PRD is one choreography. 2. Ticket validation another choreography. 3. Patient record handling (usually at end of day) another choreography. 4. PRD + Ticket validation is a choreography and a recursive composition 5. Ticket validation + patient record handling is a choreography and a recursive composition #4 and #5 overlap but are not nested within each other. But #1-#3 can be reused to define #4 and separately #5, which is the benefit of reuse, but also explains the interest behind the pi-calculus model. arkin > >Edwin > > > > >And >* there is another choreography that defines how those > sub choreographies are composed > > > >>When two participants talk to each other they engage in a >>conversation. >>All other participants are not necessarily aware of that >>conversation, >>when it does not involve them. So a multi-party choreography >>can express >>multiple conversations that are going on and overlapping with each >>other, by allowing a conversation to be scoped to a subset of >>the parties. >> >>In fact, what a multi-party tries to do is express how multiple >>conversations are brought together in a larger context. It >>can express >>the causal dependency between these conversations and put a larger >>context in which such relationships can be depicted. >> >>For example, the patient-receptionist-doctor (PRD) scenario involves >>three conversations and expresses the relationship between these >>conversations: >> >>1. Patient-receptionist >>2. Receptionist-doctor >>3. Doctor-patient >> >>These conversations do not follow each other: they are >>interleaved. The >>choreography starts and actuall ends in the scope of the >>patient-receptionist conversation (from hi to bye). The >>receptionist-doctor conversation starts before the doctor-patient but >>concludes after the doctor-patient (doctor notifies recipient >>it is now >>able to accept patients). >> >>There are much easier means to express sequences of >>conversations, but >>the only one that can express interleaved conversations with >>dependency >>between these conversations, is the multi-party choreography, >> >>arkin >> >> >>-- >>"Those who can, do; those who can't, make screenshots" >> >>---------------------------------------------------------------------- >>Assaf Arkin arkin@intalio.com >>Intalio Inc. www.intalio.com >>The Business Process Management Company (650) 577 4700 >> >> >>This message is intended only for the use of the Addressee >>and may contain information that is PRIVILEGED and >>CONFIDENTIAL. If you are not the intended recipient, >>dissemination of this communication is prohibited. If you >>have received this communication in error, please erase all >>copies of the message and its attachments and notify us immediately. >> >> >> >> >> >> -- "Those who can, do; those who can't, make screenshots" ---------------------------------------------------------------------- Assaf Arkin arkin@intalio.com Intalio Inc. www.intalio.com The Business Process Management Company (650) 577 4700 This message is intended only for the use of the Addressee and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not the intended recipient, dissemination of this communication is prohibited. If you have received this communication in error, please erase all copies of the message and its attachments and notify us immediately.
Received on Tuesday, 25 March 2003 18:09:18 UTC