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 >>
Forwarded message 1
JJ,
I'm having difficulty netting out your discussion. I see only one
form of composition relevant to choreography. That is the form
described by Martin, below.
Composition of web services I see as fundamentally composition of
a web service where a web service may incorporate and thus encapsulate
other web services in the performance of its offering. In this case,
there is choreography between the web service provider (not the role
of the service offered) and each of the incorporated services. There
will then be a choreography between the service offered role and
a user of the service.
It is possible that we could see a situation where both of these
apply. For example, if we have a buyer and a seller, and the seller
is a service composed of a warehouse, as carrier and a bill collector.
The warehouse may be fully encapsulated, but the carrier and bill
collector may interact with the buyer. Thus there are several
choreographies:
buyer-seller
seller-warehouse
seller-carrier
seller bill collector
carrier-buyer
bill collector-buyer
and potentially two composite choreographies:
1) buyer-seller, carrier-buyer and bill collector-buyer
2) buyer-warehouse, buyer-carrier, buyer-bill collector
I don't see a choreography composition that combines
these two composites since that would break the
encapsulation of the buyer service. From a buyer
perspective, the seller, the carrier and the bill collector
could all be the same entity in different roles without
any choreography defining the internal business processes.
Fred
> -----Original Message-----
> From: Jean-Jacques Dubray [mailto:jjd@eigner.com]
> Sent: Tuesday, July 08, 2003 7:46 AM
> To: 'Martin Chapman'; 'Champion, Mike'; public-ws-chor@w3.org
> Subject: RE: Revised: Mission Statement
>
>
>
> Martin, Mike:
>
> There is clearly a concept of "choreography composition"
> whereby someone
> is able to reuse a choreography within another choreography. I think
> that this is the example that you provided. I personally view this as
> significantly different from "web service composition" . WSC assumes
> that there will be a specific (system) process that will do
> the routing
> and mapping to the back end services. This process is very thin and
> should be completely metadata driven.
>
> My view (fantasy?) on how web services are created is such that people
> will tend to wrap coarse "modules" (order entry, billing, inventory,
> shipping, ...) behind web service. The question will
> inevitably come on
> how do I use my "n" services in "p" choreographies (each one could
> require a slightly different format or sequence of message
> interchanges). It would be very useful to have some Web Service
> Composition metadata defined somewhere by a spec with standard
> implementations/engines. Now, is this the task of WS-Chor? is it the
> task of the WSDL group using WS-CHOR? Is it yet another spec?
>
> I view this level as different from Orchestration. For me
> orchestration
> is "embedded" within these coarse modules providing them with the
> ability to manage their long running state. Pretty much every business
> object or collection of business objects has a long running
> state within
> any given module: Every purchase order has a lifecycle within the OE
> module. Traditionally this long running state management of business
> object has been address by specific code. Now that these modules are
> more and more interconnected, there a big need to standardize
> how we go
> about managing this long running state.
>
> Of course the confusion stems from the fact that all 3 levels
> (Choreography, WSC, Orchestration) have overlapping semantics. For
> instance, BPEL has tried to achieve the 3 levels in one specification.
> Maybe that's a little too much to attempt in one step. It can create
> cases where semantics are missing in order to fully address one level
> (e.g. choreography) or offer semantics that cannot not be used at all
> levels (e.g. the "partner" tag :-).
>
> Ultimately, this WSC layer (Martin, I think you called it the glue at
> some point) is key to both the success of choreography and
> orchestration.
>
> JJ-
>
>
>
> >>-----Original Message-----
> >>From: public-ws-chor-request@w3.org
> [mailto:public-ws-chor-request@w3.org]
> >>On Behalf Of Martin Chapman
> >>Sent: Montag, 7. Juli 2003 12:05
> >>To: Champion, Mike; public-ws-chor@w3.org
> >>Subject: RE: Revised: Mission Statement
> >>
> >>
> >>I think Mike has made a good point here. If a composition presents a
> new
> >>wsdl, it has to be hosted somewhere, even if its job is just to
> delegate
> >>out
> >>to the parties (Yaron made a similar point the other week).
> I thought
> we
> >>had
> >>ruled out this sort of central controller, for autonomous peer-peer
> >>environments.
> >>Thinking about this a little more, the only way I can see nesting of
> >>choreographies is for one choreography to take on the
> role(s) defined
> in
> >>another choreography. Something like:
> >>
> >>Choreo 1: pay
> >> role payer
> >> role payee
> >> role cardagency
> >>
> >> payer sends payment details to cardagency
> >> //cardagency verifies and does stuff
> >> cardagency deposits money from payers card
> >> cardagency credits money (minus fee) to payees account
> >>
> >>Choreo 2: Purchase goods
> >> role buyer
> >> role seller
> >> reuses Choreo 1: buyer=payer, seller=payee
> >>
> >> buyer submits PO
> >> seller checks warehouse
> >> seller send invoice to buyer
> >> buyer submits payment details (kicks off choreo 1)
> >>
> >> blah, blah
> >>
> >>Something like that anyway.
> >>
> >>Martin.
> >>
> >>> -----Original Message-----
> >>> From: public-ws-chor-request@w3.org
> >>> [mailto:public-ws-chor-request@w3.org]On Behalf Of Champion, Mike
> >>> Sent: Monday, July 07, 2003 7:20 AM
> >>> To: public-ws-chor@w3.org
> >>> Subject: RE: Revised: Mission Statement
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> > -----Original Message-----
> >>> > From: Monica J. Martin [mailto:monica.martin@sun.com]
> >>> > Sent: Monday, July 07, 2003 10:02 AM
> >>> > To: Jim Hendler
> >>> > Cc: Steve Ross-Talbot; Nickolas Kavantzas; Cummins,
> Fred A; Martin
> >>> > Chapman; Yaron Y. Goland; public-ws-chor@w3.org
> >>> > Subject: Re: Revised: Mission Statement
> >>> >
> >>>
> >>> > mm1: Then could we revise this working definition?
> >>> >
> >>> > > **A service composition is a composition of services that
> >>> > results in a
> >>> > > ANOTHER service. THIS service can be the combination of
> >>> > distinct parts
> >>> > > to form a whole of the same generic type. The web
> services could
> be
> >>> > > combined to achieve a specific goal.*
> >>>
> >>> I appreciate the power of recursion as much as anyone <grin> but
> >>> defining a
> >>> service composition as a composition of services is not likely to
> win us
> >>> great praise for our grasp of the subtlties here. Could
> we say "is
> a
> >>> [concatenation | embedding | nesting | combination | whatever
> >>> combination ]
> >>> ..."? Or something other than "composition" anyway. Or is
> >>"composition"
> >>> well-defined somewhere else?
> >>>
> >>> Also, we need to keep the other parts of the mision statement in
> >>> mind here.
> >>> If, when when one is combining services to present a single WSDL
> >>interface
> >>> to the outside world and the global state of the interaction does
> not
> >>have
> >>> to be exposed, one is doing that O-word thing rather than
> >>"Choreography."
> >>> How can we distinguish Composition in the BPEL sense from
> >>> Composition in the
> >>> Choreography sense?
> >>>
> >>>
>