Orchestration vs. Choreography: Debate Over Definitions
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 for Anne's definition
by
Tammo van Lessen
- Choreography -- global view of the interaction/interconnection of participants
- Orchestration -- local part of a Choreography from a participants point of view (aka behavioral interface)
Re: +1 for Anne's definition
by
Stefan Tilkov
Deja vu all over again....
by
John Reynolds
Looks like we're all still confused.
Hilarious.
by
Zubin Wadia
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
Re: +1 for Anne's definition
by
Tammo van Lessen
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.
Re: +1 for Anne's definition
by
Stefan Tilkov
Choreography vs BPEL
by
Steve Ross-Talbot
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.
Orchestration vs Choreogrpahy
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 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.
Service Orchestration & Process Choreography
by
Ramchandra Koty
Orchestration means any executable Process with-in a single Party
Choreography means Multi-party Collaboration to achieve the end goal
Service Orchestration & Service Choreography is different than Process Orchestration & Process Choreography
Service Orchestration relates to describing externally observable interactions between web services
Process Choreography simply means "flow of business process end-2-end with/without interruption, includes/excludes human intervention and MUST involve different systems/Parties
Educational Content
Writing Usable APIs in Practice
Giovanni Asproni May 19, 2013




Hello stranger!
You need to Register an InfoQ account or Login to post comments. But there's so much more behind being registered.Get the most out of the InfoQ experience.
Tell us what you think