RE: choreography & orchestration must be defined in a context

JJ
 
I don't think we are as far apart in our thinking as you suggest - comments
inline.
 
David

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


David:
 
thanks for forwarding this definition, however, I cannot disagree more with
the association of "orchestration" and "business process". If a business
process language were to be defined one day, it will be layered on top of a
choreography language as (as you put it yourself) a co-operation of
"orchestration nodes". The fact that you talk about orchestration nodes
(plural) participating in a business process and you say that the business
process is an orchestration is antinomic.
</DavidBurdett> What I think I am really saying is that Orchestration occurs
when a single entity can define what happens without there being any need
for cooperation with others. Sometimes, these orchestrations could define a
complete business process, but they will not always. Sometimes, as you say,
the implementation of a business process will require cooperation with
others businesses. However this cooperation is limited to how those business
processes interact. The owner of the business process will still have a lot
of control over how they carry out major parts of their business process.
For example if a business defines a process that allows placement of orders,
then you could imagine it consisting of a number of steps:
1. Determine demand for a product - this is strictly internal and private to
the busines
2. If more product is required then - this is also strictly a private
decision
3. Place an order with the supplier - how this is done is NOT private as it
depends on the buyer and supplier agreeing how the order will be placed.
So I would say that steps 1 through 3 are all part of a private process and
would be defined using an Orchestration Language as there is clearly one
entity in contorl. However, one part of the process (step 3) must conform to
a previously agreed definition which is where the choreography definition
comes in.</DavidBurdett>
 
 
Yes I totally agree that there are ochestration nodes, of course, these
nodes represent the "things" where the activities of "the business process"
are performed.
 
Business processes that map to a single orchestration node are the exception
rather than the rule. These type of orchestration definitions require that
all units of work/activites be modeled as a web service (with
request/response operations). They also create de facto a "center" of
business processes which does not exist in reality, we all know that.
<DavidBurdett> I would disagree that single orchestration nodes are the
exception. They are as common as business processes that involve multiple
nodes where a single orchestration node is at the end of the branches of a
business process as in ...
BP1 consists of
  - BP2 which consists of
    - BP3 which consists of
      - Orchestration 4, and
      - Orchestration 5, with
   -Orchestration 6
</DavidBurdett>
  These are 2001 concepts, in 2003, we are thinking of service oriented
architectures. We finally realized that units of work/activities cannot be
modeled as request/responses but rather as orchestrated nodes that
co-operate within a business process.<DavidBurdett> I totally agree.
However, at the lowest level, you will have either request-responses or
one-way messages.</DavidBurdett>  
There is no center to a business process, therefore a single orchestration
engine cannot be used for that. <DavidBurdett> This is sometimes true, but
not always.</DavidBurdett>
 
Please take a look at this presentation I am giving next week:
<http://www.ebpml.org/technoforum_2003_b_eng.ppt>
http://www.ebpml.org/technoforum_2003_b_eng.ppt it gives a detailed
definition of orchestration and choreography as well as collaboration (sorry
I did not have time to put coordination in the mix but it is coming).
<DavidBurdett>I've looked at your presentation and I really like it and
agree with it totally in terms of what you are saying. I think that, in the
article, I used the term Business Process Language as a shorthand for BPEL
which I think is what you would call an orchestration language - is that
right?</DavidBurdett>
 
I also published this paper in the summer of 2002 that expresses a business
process as a multiparty collaboration of orchestrated nodes (
http://www.ebpml.org/ebpml2.2.doc <http://www.ebpml.org/ebpml2.2.doc> ).
This approach enables the definition of end-to-end processes either within
or even beyond corporation boundaries if needed. It also provide a seemless
model to go from public business processes to private business processes
since both are a co-operation of nodes.
 
Neither BPEL or WS-CDL have any business semantics to reach the level of
business process definitions we all know that. However, they provide the
substrate or the foundation upon which a business process definition can be
specified.
 
WS-CDL also lacks three concepts (that I know of) to be able create a
business process definition language (BPDL is not yet taken by any spec):
a) WS-CDL lacks the ability to express transformations along with the
message definition (ideally transformation are expressed from the consumer
point of view to reach the maximum level of decoupling) 
b) WS-CDL lacks the ability to express simple routing rules between nodes,
again to acheive a good level of decoupling
c) WS-CDL lacks the ability to express the ability to define domains of
control to which a message can be sent. The domain may then implement
special rules to route a message sent to the domain, to a particular node.
If we had c) we may not need b). There is a very obvious domain of control,
it is called a company boundary, but I think the concept would be useful
even within a company.

 
All these concepts are not in pi so I am not surprised they don't show up in
WS-CDL or BPEL. However, they are essential to achieve the level of SOA,
without them, we cannot start building a BPDL.
<DavidBurdett>All these ideas are very necessary and useful before we can
get to the interoperability Nirvana we want to reach. However we are now
getting into scope issues. Should the WS Choreography group describe how you
do transformations, how you do routing, how you do security, how you do
reliable messaging, how identify a message, etc - all of these are
necessary. I don't think so. What we really need to do is allow these
specifications to be separately specified then work out how they are going
to be used together.</DavidBurdett>
 
If you use an orchestration engine between "nodes" you are doing EAI or
integration scenarios, a very particular form of SOA. (see this article that
explains why ESB is different from SOA:  <http://www.ebpml.org/indigo.htm>
http://www.ebpml.org/indigo.htm) 
<DavidBurdett>I wasn't suggesting this. I was suggesting that between the
nodes, you do need to define how they will cooperate - this is the
choreography. I think the misunderstanding is that I tended to use the
definition of a business process as being specific to an individual role,
e.g. a Buyer, OR a Seller, whereas I think that you also consider the
process that involves the Buyer AND the Seller as a business process where
no one is in control. This is technically correct, however, largely because
of BPEL, I think that people think that business processes are within the
enterprise.</DavidBurdett> 
 
Cheers,

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

 

  _____  

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 <http://www.ebpml.org/indigo.htm>  (ESB vs
SOA) 
http://www.ebxmlforum.org/ <http://www.ebxmlforum.org/>  "Standards for a
Service Oriented Architecture" 
http://www.ebpml.org/technoforum_2003_b_eng.ppt
<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
<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.

>>>      
>>>