choreography & orchestration must be defined in a context

Even though I no longer belong to the ws-chor working group :-( I felt that
I needed to add my 2c to this question.

IMHO, these concepts must be defined in the context in which you use them.

Today, the "web services stack" has divided itself in three parts:
- messaging
- web services
- service oriented architecture

Within the SOA layer, one must also distinguish specification that are
relevant to the behavior of a service in an SOA, and specifications that are
relevant to the web service fabric.

What I mean by that is that I can use some "web services" specifications to
simply exchange messages, I don't really care if these messages are composed
in "web services". They could but I don't use WSDL, UDDI or any "web
service" specification. SOAP with a bit of ws-addressing is enough.

Then, I can also define "web services" as a composition of messages. These
web services can be formally described and sometimes "discovered". The UDDI
piece is optional. 

Finally, I can build a "service oriented architecture" which may, IMHO
leverage both messages and web services, one not excluding the other.

The confusion comes from the fact that we try to define concepts such as
orchestration, choreography, coordination, protocols, collaborations and
many more outside a given context. 

For instance, orchestration could be a model of "composition" of web
services in the context of the "web service layer, i.e. I want to build a
web service by assembling/composing other services. However, in the context
of a Service Oriented Architecture, Orchestration clearly describes the
behavior of one "Service" with respect to all the other (peer) services it
interacts with.

Interestingly enough, when you deal with composition(orchestration) at the
web service layer, it somehow overlaps heavily with choreography. What I
mean by that, it that I could almost use a choreography description to
describe composition as well.

However, when I go to the SOA level, choreography describes the overall
message interchange between "orchestrated services" and simple services
(i.e. request/response type). In a SOA, Orchestration cannot be used to
describe the global, peer to peer message exchange. The reason is simple:
orchestration assumes that there is a "center", i.e. where the orchestration
engine is. In a SOA, there is no center, peers talk to each other
arbitrarily (see the links below). Forcing all the messages to go through a
center would IMHO be an architectural mistake, and I don't think anyone is
suggesting that. The "center" of an SOA looks more like a "fabric" or a
"grid". There is an instance of an SOA where there is a center, it is called
EAI (or ESB), but it is not general enough, there are other models supported
by SOA that would not work if a center existed. Orchestration works well for
a service in an SOA, because we can define a center within a service. Even
at the composition level, a center exist, it is the composed web service.

I found this definition of Orchestration on the web, I like it very much
(the author was talking about BPEL not orchestration)

Orchestration 
« … is an emerging [concept] that would give programmers a way to formally
describe processes underlying business applications so that they can be
exposed and linked to processes in other applications »

I added this, but I am sure you guys can do better.
Choreography
Is a concept that specifies how these processes are linked together across
the enterprise
Choreography can be « active » when mapping and routing are necessary

I would like to add one thing about WSCI. If you agree with these different
layers of the ws-stack, then you can see that WSCI fits very well at the web
service layer and amounts to an abstract BPEL, it merely describes the
behavior (in time) of a web service. This is a useful thing in itself to
communicate to a web service consumer, it will convey more information than
WSDL. IMHO, it was a mistake to add a "global model" to WSCI because the
global model is useful in the context of the SOA layer, but in this context
it does not scale well, this is what will happen to abstract BPEL as well if
one tries to use it at the SOA layer. 

Here is a few things I wrote that might be of interest to continue this
discussion:
http://www.ebpml.org/indigo.htm (ESB vs SOA)
http://www.ebxmlforum.org/ "Standards for a Service Oriented Architecture"
http://www.ebpml.org/technoforum_2003_b_eng.ppt 


JJ-
tel: 425-649-6584
Cell: 508-333-7634

-----Original Message-----
From: Monica J. Martin [mailto:Monica.Martin@Sun.COM] 
Sent: Friday, November 14, 2003 7:11 PM
To: Ugo Corda; Steve Ross-Talbot
Cc: public-ws-chor@w3.org
Subject: Re: A trial balloon distinction between choreography &
orchestration



>Corda: Steve,
>
>I think your orchestration definition below is too vague and could refer to
meanings that are not related to orchestration at all (for example, "the way
a single Web service should be used is by sending messages as specified in
the corresponding WSDL file, at the address specified in the same file"). 
>
>A more appropriate definition would be, in my mind, something like:
>
>A written business protocol (i.e. abstract WS-BPEL) description documents
how a set of Web Services should be "used", as expressed from the point of
view of one of the participating Web services......
>
mm1: I would be inclined to agree with Ugo. On Steve's point (and thanks
Steve for the impetus), I would add that the choreography definition
describes how a set of web services conforms to the definition when the
services are used.

>Ross-Talbot: As an aside from all of the stuff going on in requirements I
would be interested on peoples take on what Frank postulated as a
distinction between the O word and the C word. As a guiding principle in how
we may view a CDL is this helpful?
>
>Suppose we changed it slightly to read:
>
>	A written choreography description documents how a set of Web
Services should be "used".
>
>This minor change could then incorporate design-time use as well as
run-time use (for conformance and compliance to a choreography).
>  
>
>>>McCabe:
>>>I am aware that the O word is taboo. However, the following occurred to
me during the last F2F: A written choreography description documents how to
*use* a set of Web services: A written orchestration description documents
how to *control* a set of Web services.
>>>      
>>>