W3C home > Mailing lists > Public > public-ws-chor@w3.org > July 2003

RE: Simple Choreography composition suggestion

From: Yaron Y. Goland <ygoland@bea.com>
Date: Thu, 17 Jul 2003 11:40:15 -0700
To: "Fletcher, Tony" <Tony.Fletcher@choreology.com>, "Cummins, Fred A" <fred.cummins@eds.com>, <public-ws-chor@w3.org>
Message-ID: <GMEOJGJFKALPDCNPFMDOIEOHDFAA.ygoland@bea.com>

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 14:40:33 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 18 December 2010 01:00:25 GMT