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

Re: Proposed text for Choreography concepts

From: Francis McCabe <fgm@fla.fujitsu.com>
Date: Thu, 26 Jun 2003 13:24:31 -0700
Cc: "Champion, Mike" <Mike.Champion@SoftwareAG-USA.com>, www-ws-arcj@w3.org, "WS Choreography (E-mail)" <public-ws-chor@w3.org>
To: "Burdett, David" <david.burdett@commerceone.com>
Message-Id: <3165C5AF-A814-11D7-A2DB-000393A3327C@fla.fujitsu.com>

While I agree with David about the `useful functionality' requirement 
of a choreography, this raises a bunch of questions:

1. How do we define what is useful?
2. What techniques do we need to identify the useful functionality 
associated with a choreography.


On Thursday, June 26, 2003, at 02:54  AM, Burdett, David wrote:

> Mike a few comments on your draft below.
> Note that these are my opinions rather than those of the WS-Chor group 
> (who are getting a copy of this email).
> David
> -----Original Message-----
> From: Champion, Mike [mailto:Mike.Champion@SoftwareAG-USA.com]
> Sent: Wednesday, June 25, 2003 6:49 PM
> To: www-ws-arcj@w3.org
> Subject: Proposed text for Choreography concepts
> Compare with 
> http://www.w3.org/TR/2003/WD-ws-arch-20030514/#choreography
> Executive summary: wordsmithed the draft text a bit to be more in line 
> with
> recent discussions in the Choreography WG relating "choreography" to a
> shared global state machine rather than an execution language.
> Cross-checked language and issues here against the Choreography WG 
> charter
> and various email-threads, notably:
> http://lists.w3.org/Archives/Public/www-ws-arch/2002Aug/0101.html
> http://lists.w3.org/Archives/Public/www-ws-arch/2002Aug/0191.html
> http://lists.w3.org/Archives/Public/www-ws-arch/2002Aug/0193.html
> http://lists.w3.org/Archives/Public/www-ws-arch/2002Oct/0205.html
> http://lists.w3.org/Archives/Public/www-ws-arch/2002Oct/0369.html
> http://lists.w3.org/Archives/Public/www-ws-arch/2003May/0033.html
> Issues:
> - Is the "shared state machine" definition too idiosyncratic and 
> specific to
> the W3C WS-Chor WG?
> - Doe we want to wade into the swamp of defining "orchestration" or 
> should
> we follow Martin's lead and simply ban the term :-)  If so, does it 
> mean
> "choreography implementation" or "sortof like choreography, but from a
> particular actor's point of view?  See
> http://lists.w3.org/Archives/Public/www-ws-arch/2003May/0034.html
> - What's the relationship between Choreography and MEP?  There was a
> sentiment at the WS-Chor F2F last week that a Choreography language 
> should
> be able to model any MEP.
> 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."
> The rationale for this is as follows:
> 1. Using a "shared state machine" is actually an implementation 
> decision of how you define a choreography. Although I think it likely 
> that the WS-Chor group will use this approach it does not have to. 
> Using the phrases like "sequence and conditions in which information 
> is exchanged" is a more general statement of what must occur without 
> requiring that a state machine is used to control the sequence in 
> which they occur.
> 2. The term "interactions" needs definition if not defined elsewhere 
> which is why I think that "exchange information" is a better term.
> 3. You might want to add a subsequent definition that defines an 
> exchange of information as "Information is exchanged between services 
> by following a Message Exchange Pattern or MEP".
> 4. The term "invocations" suggests that there is some process in 
> control that is executing other processes which is what a process 
> definition or a procedural language such as BPEL, Java, C++ does. 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.
> 5. The idea of a "acheiving a useful function" is needed to emphasize 
> that you are trying to do more than just send a simple message. 
> Instead you are trying to illustrate that there is 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
> 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>
> 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>
> 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>
> 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>
Received on Thursday, 26 June 2003 16:25:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:30:08 UTC