BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Orchestration vs. Choreography: Debate Over Definitions

Orchestration vs. Choreography: Debate Over Definitions

This item in japanese

Bookmarks

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.

Rate this Article

Adoption
Style

BT