- From: Monica J. Martin <monica.martin@sun.com>
- Date: Fri, 27 Jun 2003 14:06:31 -0600
- 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