Re: Simple Choreography composition suggestion

Both are in the requirements spreadsheet.

On Thursday, July 17, 2003, at 07:40  pm, Yaron Y. Goland wrote:

>
> I see two different requirements here, both of which I believe WS-Chor 
> must
> meet.
>
> The first requirement is to support hierarchy (awful word I know). This
> enables one to specify a choreography as being made up of other 
> choreography
> components. This requirement is critical for re-use and I expect the 
> ability
> to re-use choreography components will be one of the biggest value adds
> WS-Chor will provide as it will give choreography developers easy 
> access to
> ready made (and tested) libraries of choreographies to re-use.
>
> The second requirement is to support multi-party global view. The 
> classic
> example is the travel scenario where the traveler sends a request to 
> the
> travel agency who sends a request to the airline who sends a 
> confirmation to
> the traveler. In order to validate that the system will work properly
> end-to-end it is necessary to be able to model all the states of all 
> the
> participants and how they change due to externally visible behavior. 
> If we
> break the description up into three separate choreographies (Traveler 
> to
> Travel Agency, Travel Agency to Airline and Airline to Traveler) then 
> we
> lose the connection between the states and so cannot properly validate 
> that
> the system will work.
>
> This then leads to a third requirement, segmentation. Segmentation 
> allows us
> to take a multi-party global view and break it up into pieces which 
> only
> contain a sub-set of the parties. For example, at run time we probably 
> only
> want to feed the travelers software the choreography information for
> communications with the travel agency and from the airline. There is no
> point in programming it with information about the travel agencies
> communications with the airline as none of this will be visible at run 
> time
> to the traveler.
>
> Segmentation is also very important for validating choreographies who 
> have
> components that are not necessarily intended to be shared with all the
> involved parties. For example, the travel agency may explicitly not 
> want to
> share the choreography of how it communicates with the airline with the
> customer as this could reveal proprietary information. The travel 
> agency
> still needs a multi-party global view in order to validate its own 
> behavior
> but in the end it will use segmentation to 'break off' the pieces of 
> the
> choreography relevant to the traveler and just send those pieces to the
> traveler.
>
> 		Yaron
>
>> -----Original Message-----
>> From: public-ws-chor-request@w3.org
>> [mailto:public-ws-chor-request@w3.org]On Behalf Of Fletcher, Tony
>> Sent: Thursday, July 17, 2003 4:38 AM
>> To: Cummins, Fred A; public-ws-chor@w3.org
>> Subject: RE: Simple Choreography composition suggestion
>>
>>
>>
>> Dear Fred and others,
>>
>> OK, I think we are probably agreed then actually.
>>
>> I agree that this group should not be concerned with the internal
>> implementation of a 'node'.  I also agree that there will be many
>> occasions were one just wants to focus on an A - B relationship and 
>> any
>> other relationships that A and B might have are not of concern.  The
>> WS-Chor language should be applicable in that case.  But I also wanted
>> to make sure we were not limiting ourselves to that case and that the
>> language we produce will be able to express relationships between 
>> (sub-)
>> choreographies that can be viewed as an overall choreography.
>>
>> Maybe somewhat heretically for this group, I am not sure that
>> concentration on Web Service is actually that helpful for us at 
>> present.
>> We will get to that when we come to answer the question 'How does this
>> message / interaction get sent?'  For the moment I think we should 
>> focus
>> on the sequencing of interactions between roles / parties (nodes) and
>> the triggering of one (sub-)choreography by another.
>>
>> Best Regards     Tony
>> A M Fletcher
>>
>> Cohesions  (TM)
>>
>> Business transaction management software for application coordination
>> www.choreology.com
>>
>> Choreology Ltd., 13 Austin Friars, London EC2N 2JX     UK
>> Tel: +44 (0) 20 76701787   Fax: +44 (0) 20 7670 1785  Mobile: +44 (0)
>> 7801 948219
>> tony.fletcher@choreology.com     (Home: amfletcher@iee.org)
>>
>>
>> -----Original Message-----
>> From: public-ws-chor-request@w3.org
>> [mailto:public-ws-chor-request@w3.org] On Behalf Of Cummins, Fred A
>> Sent: 16 July 2003 17:24
>> To: Fletcher, Tony; public-ws-chor@w3.org
>> Subject: RE: Simple Choreography composition suggestion
>>
>>
>>
>> Tony,
>>
>> My assertion is based on a concern that the scope of
>> choreograpy not creep into the specification of implementation of
>> services but stop at the interfaces.  In the example, as I indicated,
>> incorporating the detail of B's use of C within the choreography 
>> between
>> B and A restricts the design options
>> of B, i.e., breaks encapsulation.
>>
>> However, I can conceive of a situation where it might be necessary to
>> impose this restriction as where there is a requirement that B use C,
>> and that there be a specific ordering of messages so that C does not
>> receive a request that is misleading about the state of A.  This might
>> be a contractual obligation.  In such a circumstance, the choreography
>> might express the relationships between the A-B choreograpy and the 
>> B-C
>> choreograpy.
>>
>> This does further restrict the behavior of B, but does not define its
>> implementation, per se.  It reflects a
>> relationship between A and C that is not expressed in
>> the choreography in terms of an exchange of messages.  I
>> suppose such a restriction might also be used within the B
>> enterprise to define a business constraint on the
>> relationship between B's interactions with A and C.
>>
>> Fred
>>
>>> -----Original Message-----
>>> From: Fletcher, Tony [mailto:Tony.Fletcher@choreology.com]
>>> Sent: Wednesday, July 16, 2003 9:12 AM
>>> To: public-ws-chor@w3.org
>>> Subject: FW: Simple Choreography composition suggestion
>>>
>>>
>>> Dear Fred, Mike and others,
>>>
>>> I feel that Fred has made a very important intervention /
>>> assertion here
>>> and this seems to be supported by Mike (Champion) who wrote:
>>> "+1 This is
>>> the differentiator between "the O-word" and Choreography,
>>> +IMHO.
>>>
>>> Or as David Burdett put it, "The common thread in all these
>>> choreographies is the idea of exchanging information which results in
>>> a changes of state of the roles involved." Only those  parties who
>>> communicate directly in a manner that could cause state changes are
>>> engaged in a "choreography" IMHO. "
>>>
>>> I currently strongly disagree, but if others agree with this position
>>> then it changes my perception of Choreography very significantly.
>>>
>>> I agree with David's statement above - and also basically with the
>>> hierarchal composition idea that David is developing (where perhaps a
>>> message is the basic form of interaction, but we talk about an
>>> 'interaction', or something, which can itself be a choreography of
>>> 'interactions').
>>>
>>> The point I disagree with is the notion that something is not a
>>> Choreography if somewhere, at some level it involves 'orchestration'
>>> within a single system.  If we accept this notion / restriction it
>>> means that you can only have Choreographies involving exactly two
>>> parties where each party only plays a single role - we will not be
>>> able to have
>>> Choreographies with more than two parties / roles at all.
>>>
>>> Consider Figure 1 in the attached slide.  The 'order' choreography is
>>> one choreography (1) and the stock level another (2).  It seems to me
>>> that we would want to be able to compose these two together to form
>>> the overall choreography (3).  At some level of detail does this
>>> involve 'orchestration' within system B - of course it does, but that
>>> should not
>>> prevent us expressing the overall choreography.  I might not
>>> quite agree
>>> with Yaron, but I am not far from his view, so I think we
>>> need a 'light
>>> touch' as to how we express the fact that the receipt of an 'order'
>>> message acts as a 'trigger' for choreography (2) within B.
>>>
>>> Similarly with Figure 2 which illustrates a possibility rather than 
>>> an
>>
>>> actual 'use case'.  System or Party P interacts with 3 other parties
>>> (/roles) Q, R and S according to the individual
>>> choreographies (4), (5)
>>> and (6).  We should be able to compose these into and overall
>>> choreography involving all 4 parties (/roles) - also compose
>>> intermediate choreographies of (4) + (5), and so on.  Again this will
>>> involve 'orchestration' (at P in this case), but our language
>>> will just
>>> express the messages (more generally 'interactions' or some such 
>>> name)
>>> and the sequencing between them.
>>>
>>>
>>> Best Regards     Tony
>>> A M Fletcher
>>>
>>> Cohesions  (TM)
>>>
>>> Business transaction management software for application coordination
>>> www.choreology.com
>>>
>>> Choreology Ltd., 13 Austin Friars, London EC2N 2JX     UK
>>> Tel: +44 (0) 20 76701787   Fax: +44 (0) 20 7670 1785  Mobile: +44 (0)
>>> 7801 948219
>>> tony.fletcher@choreology.com     (Home: amfletcher@iee.org)
>>>
>>>
>>> -----Original Message-----
>>> From: Cummins, Fred A [mailto:fred.cummins@eds.com]
>>> Sent: 15 July 2003 18:00
>>> To: Tony Fletcher; public-ws-chor@w3.org
>>> Subject: RE: Simple Choreography composition suggestion
>>>
>>>
>>> Tony,
>>>
>>> I do not consider your order-stock-leve composition to be a
>>> choreography
>>>
>>> composition, but rather the expansion of detail of the
>>> implementation of
>>> a
>>> service.  There is no direct interaction defined between A and C, and
>>> thus
>>> the relationship between the exchanges is determined internally by B.
>>> While
>>> one might use choreography to describe the behavior of B,
>>> that should be
>>>
>>> internal to B, and the use of C, should be hidden from A
>>> since there is
>>> no need to expose this detail, and it restricts the design
>>> options of B.
>>>
>>> In an earlier message, attached, I described a composition in which
>>> there is a relationship between the composite choreographies and
>>> associated parties.
>>>
>>> I agree with your composition (2), but it is fundamentally the same 
>>> as
>>
>>> the composition depicted in my example.
>>>
>>> Fred
>>>
>>>  <<RE: Revised: Mission Statement>>
>>>
>>>>  -----Original Message-----
>>>> From: 	Tony Fletcher [mailto:tony_fletcher@btopenworld.com]
>>>> Sent:	Monday, July 14, 2003 11:08 AM
>>>> To:	public-ws-chor@w3.org
>>>> Subject:	Simple Choreography composition suggestion
>>>>
>>>>  << Message:  >>  << File: 2003-07-14_Composition.ppt >>
>>>
>>
>>
>
> This email is confidential and may be protected by legal privilege. If 
> you are not the intended recipient,  please do not copy or disclose 
> its content but  delete the email and contact the sender immediately. 
> Whilst we run antivirus software on all internet emails we are not 
> liable for any loss or damage. The recipient is advised to run their 
> own antivirus software.
>

This email is confidential and may be protected by legal privilege. If you are not the intended recipient,  please do not copy or disclose its content but  delete the email and contact the sender immediately. Whilst we run antivirus software on all internet emails we are not liable for any loss or damage. The recipient is advised to run their own antivirus software.

Received on Friday, 18 July 2003 04:28:47 UTC