RE: Proposed text for Choreography concepts

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>