RE: Simple Choreography composition suggestion

Sounds good to me.

Fred

> -----Original Message-----
> From: Yaron Y. Goland [mailto:ygoland@bea.com]
> Sent: Thursday, July 17, 2003 2:40 PM
> To: Fletcher, Tony; Cummins, Fred A; public-ws-chor@w3.org
> Subject: RE: Simple Choreography composition suggestion
> 
> 
> 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 >>
> > >
> >
> >
>

Received on Thursday, 17 July 2003 17:17:12 UTC