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 >>
>

Received on Wednesday, 16 July 2003 12:24:39 UTC