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

Received on Thursday, 17 July 2003 07:37:38 UTC