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

Re: Proposed text for Choreography concepts

From: Monica J. Martin <monica.martin@sun.com>
Date: Fri, 27 Jun 2003 14:06:31 -0600
Message-ID: <3EFCA3C7.6050504@sun.com>
To: "Burdett, David" <david.burdett@commerceone.com>
CC: "Champion, Mike" <Mike.Champion@SoftwareAG-USA.com>, "WS Choreography (E-mail)" <public-ws-chor@w3.org>

> XXX Choreography
> XXX.1 Definition
> A Choreography defines a shared state machine that describes interactions
> involving multiple web service invocations.
> <DB>As an alternative, I would suggest the following ... "A 
> Choreography defines the sequence and conditions under which multiple 
> cooperating independent web services exchange information in order to 
> achieve some useful function."
mm1: Our current working definition is:*
**The pattern of interaction, expressed as a pattern of types of 
messages, between requestors and providers (or a set thereof).**
*In our more detailed working definition: ***The (potentially automated) 
design, execution, and monitoring of a sequenced set of information 
exchanges (Activities or Activity Sets) among a set of participants.**

If we continue there, here are the criteria attached thus far:
**May also include: 1) The ability to specify complex sequencing of the 
use of a web service’s operations, 2) A description of the temporal 
and/or logical dependencies among Activities, 3) The necessary states 
that give rise to the particular message patterns, or 4) Within the 
context of a business transaction the description of the ordering and 
transitions between business transactions or sub collaborations within a 
binary collaboration. ....**

*The only item Dave adds that is currently missing is the outcome or 
function so we could add that (see below).

> The rationale for this is as follows:
> "shared state machine" .....vs..... "sequence and conditions in which 
> information is exchanged"
> ...an exchange of information as "Information is exchanged between 
> services by following a Message Exchange Pattern or MEP.
> ...What makes choreography different is that no single process is in 
> control and therefore the processes that do take part are independent 
> and have no option but to cooperate if they want to succeed....
> ...acheiving a useful function....
> some larger activity going on.</DB>
> XXX.2 Relationships to other elements
> A choreography is
> the pattern of possible interactions between a set of services
mm1: See original definition.

> A choreography may be expressed in
> a choreography description language
> XXX.3 Description
> SOAP and WSDL by themselves can describe only very simple Web services
> consisting of a single interaction between a consumer and provider pair.
> The SOAP Recommendation formally specifies only two MEPs, 
> "Request-Response"
> and "SOAP Response." Web Services Choreography is the subject area
> describing web services interactions involving more than two parties 
> and/or
> more than one operation.
> A choreography is model of th sequence of operations, states, and 
> conditions
> which control how the interactions occur. Successfully following the 
> pattern
> of interaction prescribed by a choreography should result in the 
> completion
> of some useful function, for example: the placement of an order, 
> information
> about its delivery and eventual payment, or putting the system into a
> well-defined error state.
> [ not sure about this: Defining the possible patterns of interactions
> between services does not itself construe a composite service; however, a
> composite service requires a definition in terms of the choreography of a
> set of services.]
> A choreography is not to be confused with orchestration. Orchestration is
> [option A: a technique for implementing a series of web service 
> invocations
> described by a choreography, but is not the only such method.] [option B:
> defintion a series of web service invocations from a single single 
> party's
> point of view (the conductor).]
> <DB>I think that an Orchestration defines a single party's 
> perspective. Although the term "party" has a B2B feel about it. I also 
> think it would be useful to also define Orchestration to avoid the 
> confustion. The sort of definition I would suggest would be one such 
> as "An orchestration defines the sequence and conditions in which one 
> web service invokes other web services in order to realize some useful 
> function". Note that this strictly a single service view.</DB>
mm1: From our working glossary, ***A choreography definition can be seen 
from a single party point of view (for example, by a conductor) and 
could also infer that the definition is executed by the service 
requester and provider as planned (centralized control may apply).***

> YYY Choreography Description Language
> <DB>The WS-Chor group seems to be using the term Choreography 
> *Definition* language since you're really defining the choreography in 
> the strict sense rather then explaining it which is what a description 
> probably suggests.</DB>
mm1: Our understanding thus far of Choreography Definition: **Public 
message exchanges between partner roles.**

> YYY.1 Definition
> A Choreography Description Language is a notation for describing a
> choreography. It may also permit the specification of a composite service
> in terms of component services.
> <DB>If you restrict choreography definitions to describing how 
> independent services co-operate, then it can't define a composite 
> service since service always belongs to just *one* party and 
> choreographies must involve at least two. You can though, use an 
> Orchestration definition (which is what languages like BPEL provide) 
> to implement a composite service. A service can also co-operate with 
> other independent services to deliver its functionality.</DB>
> YYY.2 Relationships to other elements
> A choreography Description Language describes
> the pattern of allowable interactions between a set of services
> <DB>Suggest "a set of *independent* services"</DB>
> A choreography Description Language may describe
> the life cycle of a service invocation
> <DB>I'm not sure what you mean by "life cycle" in this context.</DB>
mm1: Suggest we differentiate here was model we are pursuing. Dave, your 
paper touches on the client-server model that Gary Brown described, 
while I believe there was support within our team to work on the shared 
state or share space (peer-to-peer) model. Let's make sure we are 
talking about the same thing.

> A choreography Description Language describes
> the conversations possible between service requesters and service 
> providers.
> <DB>What does "conversations" mean in this context?</DB>
> YYY.3 Description
> A Choreography description language is a formal, machine-processable
> definition of a specific choreograpy. [Not sure about this: A 
> choreography
> descripion language formally defines the message exchange pattern(s) 
> used by
> a web service.] It permits the description of how Web services can be
> composed, how roles and associations in Web services can be 
> established, and
> how the state, if any, of composed services is to be managed.
> <DB>See earlier comments about composition.</DB>
mm1: See working definitions provided.
Received on Friday, 27 June 2003 15:55:44 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:00:59 UTC