Orchestration vs. Choreography: Debate Over Definitions

Posted by Boris Lublinsky on Sep 01, 2008 03:37 PM

Community

SOA

Topics

Choreography ,

Business Process Management ,

Composition

Tags

WS-CDL ,

BPEL

With increasing attention given to SOA, it becomes more and more important to standardize (give precise meaning) the terminology used. An interesting discussion illuminates that point.The discussion was started by Michael Poulin who was asking the question about the difference between "orchestration" and "choreography" hoping to be pointed to the place where the difference "had been clearly articulated". Instead of a simple answer, his question caused a flurry of replies, each giving a slightly different meaning to the terms and interpreting them differently..

Anne Thomas Manes starts her explanation by referring to the Merriam-Webster dictionary for the traditional meaning of the words:

Choreography - the art of symbolically representing dancing:

• the composition and arrangement of dances especially for ballet
• a composition created by this art

 

Orchestration - the arrangement of a musical composition for performance by an orchestra; also: orchestral treatment of a musical composition

Although that definition does not really help to clarify the differences between orchestration and choreography in IT, it was implicitly used by many participants in the discussion. Anne continues her explanation by referring to the meanings used in existing WS-* specifications namely Business Process definition Language (BPEL) and Web services Choreography Definition language (WS-CDL):

Orchestration refers to automated execution of a workflow, i.e., you define workflow using an execution language such as BPEL, and you have an orchestration engine to execute the workflow at runtime. An orchestrated workflow is typically exposed as a service that can be invoked through an API. It does not describe a coordinated set of interactions between two or more parties.

Choreography refers to a description of coordinated interactions between two or more parties. For example, you request a bid, I return a quote, you submit a purchase order, I send you the goods

A slightly different point of view is expressed by John Evdemon, classifying the two terms based on their visibility:

Orchestrations describe what an overall process appears to do without specifying how any of it is implemented.

I view choreography as a form of peer-to-peer interaction because there is no "conductor". The choreography is an agreed-upon model for interactions that may consist of a series of orchestrations.

From a B2B perspective, orchestrations are intra-organization while choreographies are inter-organization. Put more simply, one organization does not orchestrate another

That definition is refined by Steve Johns:

Orchestrations are "fixed" in that there is a described set of steps and decisions. Choreographies, should be, more goal oriented and be about the co-ordination of resources towards that goal

Alan Dean distinguishes the two terms based on whether there is a "centralized controller" as part of the overall architecture:

It seems to me that Orchestration / Co-ordination has a central Conductor / Co-ordinator whereas Choreography does not...

• Orchestration is Autocratic
• Choreography is Autonomous

Ashley McNeile at Metamaxim traces choreography to the RosettaNet’s "Partner Interface Processes" standard, and considers it the description of certain fixed patterns of (interaction) behavior between participants. He considers that the dispute:

...is not so much on the distinction between "choreography" and "orchestration" as concepts, but on the need for a language to describe/capture choreography independently of orchestration.

Rob Eamon sides with Ashley, saying:

At what point in an architecture definition, or in a design, does the distinction between choreography and orchestration matter? In an architecture or design will the use of one or the other term be sufficient without further explanation? Seems to me to be yet another case where assumptions about what a particular means in a particular context will lead to miscommunication. One is wise to ensure that the parties involved have a common understanding of the terms being used, however said terms are defined.

This opinion is also shared by Gregg Wonderly:

As is normal, computer scientists are taking words that already exist, and trying to make them apply in a particular context. People, who know and use these words in different contexts, have bias and experience which makes them perceive those usages as either right or wrong (binary logic, "sometimes" is hard to use as a logical explanation in a world of absolute logic). So, we get to have all these discussions trying to shape everyone’s view to something that we can all agree on, no matter how contorted the arguments get..

I just wish that the SOA crowd would learn to be happy with using all the words and terms that are the "definitative" meaning instead of trying to shoehorn some silly word into being the place holder for that.

Steve Jones summarized this discussion really well:

Basically I think the point is that choreography, orchestration, co-ordination, process management and all the other words are very badly defined. I wouldn't be surprised if a vendor pitched a BPEL engine as a choreography product. One reason (IMO) that choreography hasn't caught on as well is that its real world equivalent (dance) isn't really an IT specialty.

This discussion is just one example of the situation that is becoming more and more common in SOA and IT in general. People are using the same words while they really mean different things and keep arguing because they are using different words although in reality they are in complete agreement.

1. Back to top

   +1 for Anne's definition

   Sep 2, 2008 4:47 AM by Tammo van Lessen

   I'd give my +1 for Anne Thomas Manes' definition. However, I'd put the choreography definition slightly different: "A requests a bid, B returns a quote, A submits a purchase order, B sends A the goods". As soon as you talk about "I/me" and "you", it's getting difficult to separate a local view from a global view and you glue them together. Its like a "deployment" of a choreography into a specific setting where "I/me" and "you" are "endpoints" with a certain "orchestration", that fit to the global view defined in the "choreography". That thus results in

   • Choreography -- global view of the interaction/interconnection of participants
   • Orchestration -- local part of a Choreography from a participants point of view (aka behavioral interface)

   Reply

2. Back to top

   Re: +1 for Anne's definition

   Sep 2, 2008 9:32 AM by Stefan Tilkov

   Hi Tammo, when I posed a question on the "local" role of BPEL to Gregor Hohpe, he pointed out that BPEL can be used to describe these dependencies in an abstract way, too. Do you agree?

   Reply

3. Back to top

   Deja vu all over again....

   Sep 2, 2008 12:40 PM by John Reynolds

   I wrote a similar blog back in 2006: Service Orchestration vs. Service Choreography. Looks like we're all still confused.

   Reply

4. Back to top

   Hilarious.

   Sep 2, 2008 1:01 PM by Zubin Wadia

   If we all stepped back and swapped the "C" in WS-CDL to mean Conversation instead of Choreography, I believe this may be the last time we read such an article.
   
   I think Gregor Hohpe put it really well: WS-CDL is the superior specification for conversations & message exchange, but the pervasiveness of BPEL in the enterprise environment makes it the better bet for modeling these interactions even with its perceived shortcomings.
   
   Zubin Wadia
   
   www.zwadia.com

   Reply

5. Back to top

   Re: +1 for Anne's definition

   Sep 3, 2008 4:01 AM by Tammo van Lessen

   Hi Stefan, I absolutely agree with Gregor, but as he said it depends on the scenario. In a very simple scenario where just 2 services/processes are connected, an abstract BPEL describing each behavioral interface is sufficient for describing the choreography. If you imagine a more complex scenario like the request-with-referal service interaction pattern, the abstract BPEL is not explicit enough because the local BPEL process can not know what happens between other participants. For instance process A is buying something by sending a PO to B and later receives the goods (something immaterial of course ;) ). Now B has decided to outsource the shipping part and delegates it to partner C who sends the shipping message to A. Although it is possible in A's BPEL to define that the response is expected from another participant, it is unknown to A what happens between partner B and C. To make this knowledge explicit, you would need to capture the global model. Of course it is possible to derive the global behavior of a set of BPEL processes but this can be tricky because BPEL aims at hiding the binding to concrete partners so you would need to analyze a specific deployment setting to know which process plays which role and with whom it interacts. In this case it appears more appropriate to model the global choreography (e.g. with WS-CDL or BPEL4Chor) and then split it to abstract BPELs that are then implemented by the participating processes/services.

   Reply

6. Back to top

   Re: +1 for Anne's definition

   Sep 3, 2008 9:21 AM by Stefan Tilkov

   Thanks for the comment (and incidentally, the BPEL4Chor pointer which I admit I hadn't heard of before :-) )

   Reply

7. Back to top

   Choreography vs BPEL

   Sep 5, 2008 4:22 AM by Steve Ross-Talbot

   I think the title does little to help the debate. It is not "vs" because that implies one or the other. It is about understanding what each does. BPEL is all about execution. It is about implementation. CDL is all about description. It is all about architecture but in a way that describes intent without elaborating the how (execution). BPEL does not describe without introducing a specific view point (that of the service that it realises - the end point view). This is why it is unsuitable for description. CDL deso describe but does not execute. This is why it is unsuitable for execution (it needs many other moving parts, i.e. the non-observable logic that BPEL is so good at modeling and BPEL engines good at realising). We all need architecture and implementation. CDL is architecture and BPEL is implementation. CDL provides testable architecture (against requirements) which ensures that subsequent implementation (of which BPEL is a key target) is correct against the description (the architecture). So both are needed - describe architecture, validate it and realise it. They are used at different levels of abstraction with CDL being higher than BPEL. The "WS" in WS-CDL is a misnomer. It applies with or without Web Services which is why the interfaces on roles in WS-CDL (which references WSDL) is optional.

   Reply

8. Back to top

   Orchestration vs Choreogrpahy

   Sep 5, 2008 4:33 AM by Steve Ross-Talbot

   Sorry the last post did not capture breaks. So here it is again properly formatted.
   
   I think the title does little to help the debate. It is not "vs" because that implies one or the other. It is about understanding what each does.
   
   BPEL is all about execution. It is about implementation.
   
   CDL is all about description. It is all about architecture but in a way that describes intent without elaborating the how (execution).
   
   BPEL does not describe without introducing a specific view point (that of the service that it realises - the end point view). This is why it is unsuitable for description.
   
   CDL does describe but does not execute. This is why it is unsuitable for execution (it needs many other moving parts, i.e. the non-observable logic that BPEL is so good at modeling and BPEL engines good at realising).
   
   We all need architecture and implementation. CDL is architecture and BPEL is implementation. CDL provides testable architecture (against requirements) which ensures that subsequent implementation (of which BPEL is a key target) is correct against the description (the architecture).
   
   So both are needed - describe architecture, validate it and realise it. They are used at different levels of abstraction with CDL being higher than BPEL.
   
   The "WS" in WS-CDL is a misnomer. It applies with or without Web Services which is why the interfaces on roles in WS-CDL (which references WSDL) is optional.

   Reply

• Older >