Choreography vs. Orchestration

Posted by Mohammed Al-Marimi on Tuesday, July 6, 2010 - 14:39

Rate this:
Total votes: 0

Is there a standard definition of Choreography & Orchestration?

I have found some definitions online, but they don’t seem consistent... anyone using a common definition that I can leverage with my team.


Login or register below to comment on this discussion.
Marlon Dumas
posted 4 years 25 weeks ago
To the question "when you would use choreography" and "when should you use orchestration", I think I have a simple answer. Choreography is above all a "design artifact". You write choreographies during the design of your system, especially when you are building a system that spans across organizational boundaries and thus you need to establish a clear agreement of how the various parts (or services) will interact with each other. The choreography serves to establish an agreement between multiple stakeholders. It allows them to understand how will their systems interact. The outcome of designing a choreography is a multi-party agreement (or a contract if you wish). Typically, each party will then go an implement its own part according to the contract. Note that a choreography may be done between two parties only (no need for more than 2 parties to call it a choreography). Orchestration on the other hand is closer to an "implementation artifact". You do an orchestration when you want to automate your process, and wrap it up in the form of a "composite service". The output of designing an orchestration is a detailed, and possibly even an executable specification of a composite service. If you go down to the low-level details, you would write your orchestration in BPEL (or executable BPMN) and you will deploy it into an orchestration engine after binding it with the relevant services. I don't mean to say that orchestration is always executable, that's up to you. I've seen people write down an orchestration in details but then give it to their J2EE programming team who then develops it in Java. In other cases, I've seen people writing their orchestrations in BPEL down to the fully executable level. The distinction between choreography as being "peer-to-peer" and "orchestration" as being "hub-and-spoke" is very often taken as the main differentiation between choreography and orchestration. While it is a reasonable distinction, it is not necessarily very relevant. It does not tell you when should you use choreography and when should you use orchestration. The fact that orchestrations are hub-and-spoke is merely a corollary of the fact that orchestrations are meant as an implementation artifact. Of course, when you implement a system, you go into details and at a given point in time you take the role of one party and describe how this party interacts (or "orchestrates") other parties. I recommend not to get bolted by this rather superficial distinction. Deep inside, the distinction is whether you are describing an agreement between parties at the design level, or you are describing how a composite service behaves at a detailed level. If you allow me a bit of self-publicity, I would recommend you type on Google "A Critical Overview of the Web Services Choreography Description Language" and follow the link to the bptrends paper with this title. There is a section there about choreography versus orchestration which says the same as above in further details and with examples.
Neil Ward-Dutton
posted 4 years 27 weeks ago
There are some good responses here, but what nobody has actually said so far, in a simple way, is why you would use one over the other! To me, once you understand that the difference becomes clear. Orchestration is useful when you have control over all the actors in a process - when they're all in one domain of control and you can dictate the flow of activities. This is of course most often when you're specifying a business process that will be enacted inside one organisation that you have control over. Choreography is a way of specifying how two or more parties - none of which has any control over the other parties' processes, or perhaps any visibility of those processes - can coordinate their activities and processes to share information and value. Use choreography when coordination across domains of control/visibility is required. You can think of choreography, in a simple scenario, as like a network protocol. It dictates acceptable patterns of requests and responses between parties.
Brian Ruter
posted 4 years 29 weeks ago
Dave, are you trying to say that if my service invokes cross so kind of boundry or firewalll then I have moved from orchestration to choreography. If so, then what constitutes an internal service? Would internal Java classes, vs web service invokes be a good analogy? thanks!
JuanCarlos Pacheco
posted 4 years 31 weeks ago
Agree with Gregg and Dave. The main idea is to identify when we must use each one, and apply the concepts in a simple and easy way..
Dave Duggal
posted 4 years 36 weeks ago
Agree with Gregg. Orchestration and Choreography might both be forms of Coordination, but they are not the same thing. Orchestration is related to coordinating internal services, while Choreography is related to inter-organizational coordination and has implications for security/reliability of partner services.
Gregg Lipson
posted 4 years 36 weeks ago
They do not mean the same thing. The difference is locus of control. A Choreography does not have a central control mechanism and, thus, there is no mechanism for maintaining any central Process (Choreography) data. From OMG BPMN 2.0 Final Spec: A Choreography is a type of process, but differs in purpose and behavior from a standard Orchestration Process, which is more familiar to most process modelers and defines the flow of Activities of a specific PartnerEntity or organization. In contrast, Choreography formalizes the way business Participants coordinate their interactions. The focus is not on orchestrations of the work performed within these Participants, but rather on the exchange of information (Messages) between these Participants. A Choreography does not have a central control mechanism and, thus, there is no mechanism for maintaining any central Process (Choreography) data. Thus, any element in a Process that would normally depend on conditional or assignment expressions, would not have any central source for this data to be maintained and understood by all the Participants involved in the Choreography. Neither Data Objects nor Repositories are used in Choreographies. Both of these elements are used exclusively in Processes and require the concept of a central locus of control. Data Objects are basically variables and there would be no central system to manage them. Data can be used in expressions that are used in Exclusive Gateways, but only that data which has been sent through a Message in the Choreography. The key question that needs to be continually asked during the development of a Choreography is “what information do the Participants in the Choreography have?” Basically, each Participant can only understand the status of the Choreography through observable behavior of the other Participants–which are the Messages that have been sent and received. If there are only two (2) Participants in the Choreography, then it is very simple—both Participants will be aware of who is responsible for sending the next Message. However, if there are more than two (2) Participants, then the modeler needs to be careful to sequence the Choreography Activities in such a way that the Participants know when they are responsible for initiating the interactions. Another way to look at Choreography is to view it as a type of business contract between two (2) or more organizations. This entails Message (document) exchanges in an orderly fashion: e.g., first a retailer sends a purchase order request to a supplier; next the supplier either confirms or rejects intention to investigate the order; then supplier proceeds to investigate stock for line-items and seeks outside suppliers if necessary; accordingly the supplier sends a confirmation or rejection back; during this period the retailer can send requests to vary the order, etc. Message exchanges between partners go beyond simple request-response interactions into multi-cast, contingent requests, competing receives, streaming and other service interaction patterns (REF for SIP). Moreover, they cluster around distinct scenarios such as: creation of sales orders; assignment of carriers of shipments involving different sales orders; managing the “red tape” of crossing customs and quarantine; processing payment and investigating exceptions. A Choreography is a definition of expected behavior, basically a procedural business contract, between interacting Participants. A problem with model interconnections for complex Choreographies is that they are vulnerable to errors – interconnections might not be sequenced correctly, since the logic of Message exchanges is considered from each partner at a time. This in turn leads to deadlocks. Deadlocks in general, however, are not that obvious and might be difficult to recognize in a orchestrated Collaboration.
Brian Ruter
posted 4 years 36 weeks ago
Actually they mean the same thing. Trying to apply different meanings to them can only serve to confuse our business partners. I believe IBM was the first to use choreography with their Buisness Process Choreographer product which later became Websphere Process Server. Orchestration is a more excepted industry term amoung those of us writing the code. People tend to use the term orchestration when refering to service orchestration choreography tends to be used when the process flow has human tasks involed, but at the end of the day we're all really just saying the same thing.
Mohammed Shaikh
posted 4 years 36 weeks ago
Thanks Scott, As you say "Choreography is a more abstract notion of process (for most people). It is used to describe the “Interactions” of collaborating entities, each of which may have their own internal orchestration processes". Does it mean Orchestration is a subsets of Choreography? [Updated on 12/17/2010 5:26 AM]
Tony Willis
posted 4 years 41 weeks ago
Not being a music guru, my take on this may be slightly distorted, but I do believe that Marco's explanation is closest to the analogies that I was using 3 years ago at the time that I was doing a significant amount of consulting on real SOA projects. The analogy seemed to resonate well with almost everyone. Orchestration and Choregraphy are not synonymous - but they can end up with a similar result if you define a conductor/director as one of your services in a choreographed model. However this is counter-intuitive, because in a choreographed model, the fundamental design approach is for each service to be reasonably self-sufficient so that they can exist without a director!! Here are the analogies: Orchestration is the approach applied to a symphony orchestra. The performance (i.e. execution of the Business Process) cannot take place without the conductor. On performance night, he comes out in front of the audience, taps his baton a few times (start event) and then cues in one or more sections of the orchestra with cue events (wave of the arm, nod of the head etc.). The important part here is that there is a specific musical score (the defined business process), but nobody plays their piece until cued in by the conductor. His job is to ensure that each part of the orchestra plays their piece at the correct point in time until the final notes are played and then he stops the execution. Should an unforseen event occur, he is the single point of conrol as to what happens next. For example, should there be a power failure, he will direct everyone to stop playing and when the lights come back on again, he will decide at which point to start the performance again and will direct the different sections of the orchestra accordingly. If the whole violin section breaks their strings simultaneously, he may actually stop the whole performance, give them a few minutes to reset their instruments and then restart the performance from a specific point in the musical score again. The point here is that he is in control - if the lights go out, the orchestra does not continue playing in the dark until the end - they are under the conductor's control at all times. As Marco said - Orchestration is when a central director takes care of deciding the execution sequence (like in an orchestra, where the director leads all the pieces) Choreography is similar but different. The best analogy for Choreography is the ballet. There is a score (the Business Process definition) and a story (the Business Process) and both an orchestra and a troupe of dancers (all of the underpinning Services). The choreographer is the Business Process designer and he/she trains the ballet dancers for weeks and months to ensure that their individual activities (and the performance as a whole) in the ballet story are performed correctly and in sequence. However, when performance night comes, the choreographer takes a back seat and the performance is driven by a set of events cued by music, light and movement stimuli. There is no conductor of the dancers. The fundamental distinction between this scenario and the orchestrated event is that should the stimuli be slightly different at any point, each and every dancer must be trained (programmed) to react appropriately to that change. For example, should any dancer slip and fall, the other dancers must know how to adjust to this situation - there is no conductor telling them what to do. It doesn't help for one dancer to continue with their steps (while everyone else is giving the fallen dancer time to recover) and as a result end up completely out of synch for the rest of the performance. And so the fundamental difference here is that in the choreographed scenario, each service has to have enough intelligence to be able to handle all of the unforseen events and know what to do if they occur - effectively the centralised intelligence of the orchestra's conductor is replicated/distributed to each ballet dancer(service) with respect to handling triggers and events. Therefore it is extremely important that a Service designer knows which model they are designing for - as the amount of intelligence designed into stand-alone web services that make up a choreographed business process needs to cater for far more triggers/stimuli than that of an orchestrated service. The issue between Choreography and Orchestration is not so much that the Business Process design is different - the actvities and associated role players can be identical in both scenarios. It is he execution model that is very different and the underlying service designs are very different. So while the analogies are great - let's focus on why we need to distinguish between these two forms of process execution in the first place!! By the way did you notice that I had an orchestra in my ballet setup? No reason that an orchestrated business process cannot be a stand alone service in its own right. Hope this helped in some way.
Bob Gehman
posted 4 years 43 weeks ago
I agree with "downesc" that a better musical metaphor for the process concepts that you want to capture is the comparison between playing an orchestral (particularly classical) piece vs. playing jazz. As a musician myself, I find the orchestration vs. choreography comparison less apropos. For one reason, choreography can be just about as structured as orchestration. (My daughter is a dancer, and has choreographed numbers many times. In classical settings [e.g., classical ballet], the instructions to the dancers are very explicit and directive. Their actions are controlled through the music itself, hence indirectly through the orchestra conductor; however, they are trained in the choreography based on detailed charts laid out and communicated with them via the artistic or dance director. On the other hand, modern dance (e.g., jazz) can be much more free form, allowing the dancers to interpret the music much more individually and freely, though within some overall artistic conception/framework. Secondly, orchestration in music technically refers to the process of allocating all the musical lines in a piece to specific instruments in the orchestra. Thus, it's about design, not so much execution. Since it is so detailed, the musicians follow the orchestration very carefully, though there is some room for interpretation overall (usually reserved mostly to the conductor, or perhaps the soloist, where there is one). I would also disagree with the notion that each player only needs to know his/her part, and not be concerned with anything else going on around him/her, or that they are a part of a larger composition. Finally, I would also agree with "downesc" that both types of process design have their place, and that many times the ideal solution may be an 80/20 combination of the two approaches - achieving the benefits of both standardization and efficiency where appropriate, but also customization/tailoring/flexibility where best suited for each particular customer/user.
Marco Brambilla
posted 4 years 44 weeks ago
I think the music metaphor is quite straightforward and helps a lot. I don't see the two terms as synonyms at all: - Orchestration is when a central director takes care of deciding the execution sequence (like in an orchestra, where the director leads all the pieces) - Choreography is when everyone is aware of his role in the ballet, nobody tells him what and when to perform, but he starts working by his own initiative when he gets the right stimulus. In a web services environment, this becomes: - Orchestration: an executable workflow of invocations of services - Choreography: a set of rule that every service complies with and exposes, so that others can interact with him. In BPM, you can apply the above concept where instead of services you have tasks and human/system executors. However, for sure I would not start from those definition as a foundation for the BPM field, which covers much more than that.
Cathy Downes
posted 4 years 46 weeks ago
Another approach to Orchestration and Choreography in business process is to take another music metaphor. I have seen it referred to a number of times - the distinction between playing jazz and playing an orchestral piece of music. I have always equated "orchestration" with the search for the perfect process (a solidly Industrial Age goal, and one that fits well with purist Lean and Six Sigma Statistical Process Control, Toyota Production System) approach. By contrasts, "playing jazz" can be equated to free-form choreography where dancers are free to form their own rhythms, moves, etc. Each dance is different (each instantiation/deployment of a process is different because it is particularly tailored to a particular customer - optimized for one customer. The latter approach is much better suited to the speed of change of the Information Age, where efficiency, matched to effectiveness, is gained through having 80/20 rules (where 80% of a process is standardized - the orchestrated bit - and 20% of the process is optimized, tailored, customized - the choreographed bit - for a particular instantiation. Thus, securing the best of both worlds - locking in best practices and standardizing them so they can be shared across the whole enterprise and beyond, and then allowing sufficient flexibility to morph, adapt, cope with changing circumstances and requirements. Depends on both these types of processes, and process owners and workers.
David Champeau
posted 5 years 5 weeks ago
according to "orchestration" and "choreography" both have their roots in Greek and refer to dance. Greek khoreia , choral dance Gk orchḗstra the space on which the chorus danced, deriv. of orcheîsthai to dance that's why it is so hard to define and distinguish them. it English. We have many words to describe the same thing.
Mohammed Al-Marimi
posted 5 years 7 weeks ago
Scott, thanks for your response / insight. The above definitions seem very similar to what the team came up with: Choreography is a collaborative effort focused on a common goal, but there is no central coordinator. Each participant involved in the collaboration effort knows exactly when to execute its operations (based on defined trigger criteria) and whom to interact with. Orchestration is a collaborative effort focused on a common goal in which there is a central coordinator that controls the involved participants and coordinates the execution of their different operations. The involved participants do not know (and do not need to know) that they are part of a composition or a higher business process. Only the central coordinator of the orchestration knows this, so the orchestration is centralized with explicit definitions of operations and the order of invocation of the participants. Scott, yours seem to be short and to the point... Thanks again, Mohammed
Scott Sirles
posted 5 years 7 weeks ago
Orchestration is a term used to describe the traditional notion of managed or directed execution, where activities are carried out, with branching and synchronization of different threads. Choreography is a more abstract notion of process (for most people). It is used to describe the “Interactions” of collaborating entities, each of which may have their own internal orchestration processes. In BPMN, orchestration occurs entirely within a single pool (i.e., within a business or other organization) and choreography spans multiple pools. See, for example, for a more detailed discussion on this topic.

Join the Discussion

Already a Member? Login Here:

Shopping cart

There are no products in your shopping cart.

0 Items

Editorial Directors

Gregg Rock
Editor & Founder
Tom Dwyer
BPM Editorial Director
James Taylor
BDM Editorial Director
William Ulrich
BA Editorial Director
Mike Rosen
SOA Editorial Director
Remind me later

Welcome! Join today and get a free 10-day Professional Membership trial. You'll receive 15% off membership and training purchases during your trial period. Join now »