RE: choreography & orchestration must be defined in a context

Sure, I have no objection to what you just said.
 
Ugo

-----Original Message-----
From: Burdett, David [mailto:david.burdett@commerceone.com]
Sent: Tuesday, November 18, 2003 12:43 PM
To: Ugo Corda; Burdett, David; Jean-Jacques Dubray; Monica J. Martin; Steve Ross-Talbot
Cc: public-ws-chor@w3.org
Subject: RE: choreography & orchestration must be defined in a context


Ugo
 
I think we might be getting confused over the definition of terms. I would saythat an "orchestration language" defines what an "orchestration node" does. I would use the term "choreography language" to define the ways in which independently controlled and managed "orchestration nodes" should co-operate. I agree though that this co-oepration can be determined by other means. 
 
I also think that we are basically agreeing ;)
 
David

-----Original Message-----
From: Ugo Corda [mailto:UCorda@SeeBeyond.com]
Sent: Tuesday, November 18, 2003 12:19 PM
To: Burdett, David; Jean-Jacques Dubray; Monica J. Martin; Steve Ross-Talbot
Cc: public-ws-chor@w3.org
Subject: RE: choreography & orchestration must be defined in a context


David, you say:
 
> With an orchestration, someone (or something) is definitely in control, so cooperation is not needed - which makes life much easier.
 
I think this would only apply to the case where the orchestration Web service only interacts with other Web services that do not themselves contain an orchestration. But in many situations the system includes more than one single orchestration node, so that some type of cooperation among all those orchestration nodes is indeed required (otherwise nothing would work). As I said before, such cooperation can be expressed via an orchestration language, but it could be achieved by other means.
 
Ugo



-----Original Message-----
From: Burdett, David [mailto:david.burdett@commerceone.com]
Sent: Tuesday, November 18, 2003 11:31 AM
To: 'Jean-Jacques Dubray'; Ugo Corda; Monica J. Martin; Steve Ross-Talbot
Cc: public-ws-chor@w3.org
Subject: RE: choreography & orchestration must be defined in a context


Just to contribute my $0.02c to this discussion ... here's an extact from an article of mine that will be published in December's Web Services Journal:
 
A business process definition (i.e. an Orchesteration) describes how internal, private business processes work - for example the Sales Order Management process where a business uses its sales management system, stock management system and its fulfillment system to satisfy orders that the business receives. In this case, the business handling those orders is in complete control of how those internal and external systems are integrated and combined with existing manual processes.

 

Choreography definitions, on the other hand, define how one "independent" business or process interacts with another, by defining the sequence and conditions in which messages are exchanged between them. In this latter case no single business or process is in control so each has to agree with the other how to cooperate. For example if a buyer sends a supplier an order, the supplier needs to know how to respond. Should they: a) return an order response indicating the extent to which they can meet the order, b) just ship the goods and send an invoice or c) do something different. No single business can unilaterally decide what do without informing, and getting the agreement of, the other businesses involved.

 

As I think Ugo said, the key difference to my mind is that a choreography defines how two or more processes COOPERATE as no one is in control. With an orchestration, someone (or something) is definitely in control, so cooperation is not needed - which makes life much easier.

 

David

-----Original Message-----
From: Jean-Jacques Dubray [mailto:jeanjadu@Attachmate.com]
Sent: Saturday, November 15, 2003 1:39 PM
To: 'Ugo Corda'; Monica J. Martin; Steve Ross-Talbot
Cc: public-ws-chor@w3.org
Subject: RE: choreography & orchestration must be defined in a context


well, I am not sure your assessment is correct with respect to the direction the ws-stack is growing but I'll refrain from any further comments ;-)
 
 
Jean-Jacques 
tel: 425-649-6584 
Cell: 508-333-7634 
 

  _____  

From: Ugo Corda [mailto:UCorda@SeeBeyond.com] 
Sent: Saturday, November 15, 2003 10:52 AM
To: Jean-Jacques Dubray; Monica J. Martin; Steve Ross-Talbot
Cc: public-ws-chor@w3.org
Subject: RE: choreography & orchestration must be defined in a context


I think the problem you describe is a direct derivation from the fact that the WS stack is being built bottom-up. We all know there are pros and cons for both bottom-up and top-down. The risk of isolation and lack of higher context is usually a shortcoming of the bottom-up approach, and extra effort needs to be spent to overcome it.
 
Ugo

-----Original Message-----
From: Jean-Jacques Dubray [mailto:jeanjadu@Attachmate.com]
Sent: Saturday, November 15, 2003 10:37 AM
To: Ugo Corda; Monica J. Martin; Steve Ross-Talbot
Cc: public-ws-chor@w3.org
Subject: RE: choreography & orchestration must be defined in a context


Yes, I guess, this is why it is important to clearly define the context(s) in which choreography applies, its relationship to other concepts such as orchestration, composition, coordination, protocols and collaboration, and define its purpose in life, e.g :
1) choreography can support the specification of n-party
    a) protocols
    b) collaborations
2) choreography can validate complex orchestration implementation (#peers > 3) 
...
 
I personally donc think that any of these concepts can be used in isolation of each other except for very trivial cases. There is a need to objectively align all these specifications which are today still mostly work in progress.

Jean-Jacques 
tel: 425-649-6584 
Cell: 508-333-7634 

 

  _____  

From: Ugo Corda [mailto:UCorda@SeeBeyond.com] 
Sent: Saturday, November 15, 2003 10:26 AM
To: Jean-Jacques Dubray; Monica J. Martin; Steve Ross-Talbot
Cc: public-ws-chor@w3.org
Subject: RE: choreography & orchestration must be defined in a context


JJ,
 
> 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". 

As you say, I don't think anyone is suggesting that in the orchestration view of things there is only one center. There are many "centers", one for each "orchestrated service" in the SOA, corresponding to many orchestration engines. 
 
The real issue is how these various orchestrations and corresponding engines harmonize and cooperate. In the orchestration approach, that is left to be defined "out of band" (i.e. is not part of what orchestration itself describes). The way this "out of band" work is done can vary. Using a choreography language is evidently a way, but other less formal ways are also conceivable (e.g. the same designer develops all the orchestrations; different designers work closely together - a la extreme programming - when developing each individual orchestration; etc.) and potentially appropriate depending on the environment in which the SOA is developed.
 
Ugo

-----Original Message-----
From: Jean-Jacques Dubray [mailto:jeanjadu@Attachmate.com]
Sent: Saturday, November 15, 2003 9:34 AM
To: 'Monica J. Martin'; Ugo Corda; Steve Ross-Talbot
Cc: public-ws-chor@w3.org
Subject: 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.

>>>      
>>>