SOA Orchestration and Choreography Comparison

In Service Oriented Architecture, the definition of the concepts of Orchestration and Choreography have confused many people.  Here is my understanding of these two concepts, how they relate to one another, and how they may be used.

Definition of Orchestration

A technique used to compose hierarchical and self-contained service-oriented business processes that are executed and coordinated by a single agent acting in a "conductor" role.  (From OASIS Reference Architecture for Service Oriented Architecture Version 1.0 ,Public Review Draft 1, 23 April 2008, p. 69). 

Using the comparison of code compiler and interpreters as an analog, an orchestration engine ("the conductor") executes compiled process code as a complete application.  The composite application is complete before it is rolled out into operation, that is, all of the service components locations are known and the process flow is fully coded.  This means that there is no need for dynamic linking of service components. 

Generally, this also means that all of the service components exist within a single ownership domain.  Consequently, some SOA architects would define the environment within which orchestration is used as an Enterprise SOA.  Using "Cloud" terminology, this would be a Private Cloud at the SaaS and PaaS layers.

Definition of Choreography

A technique used to characterize and to compose service-oriented business collaborations based on ordered message exchanges between peer entities in order to achieve a common business goal.  (From OASIS Reference Architecture for Service Oriented Architecture Version 1.0 ,Public Review Draft 1, 23 April 2008, p. 71). 

On the other hand, using the same analog, a Choreography engine is like a code interpreter.  An interpreter executes or processes a single statement or step and then gets the next to execute; so it is a stepwise processor.  This is exactly the way Choreography works.  The reason that Choreography works this way is that a choreography enables a composite application to dynamically link to its service components.  This means that at each step in the process, the choreography engine can search and discover service components (across the Internet) that  meet its parametrized requirements and its internal policy and standard restraints and constraints.

Therefore, choreography is used when the service components for a given composite application exist in multiple ownership domains.  SOA experts frequently refer to this environment as an Ecosystem SOA; while cloud terminology would call this environment a Public Cloud.
  

When they Might be Used

Given the description above, it is readily apparent that Orchestration and Choreography have quite different characteristics and uses.

Orchestration:

• The composite application exists within a single ownership domain, so security of the composite application is less complex
• The organization can count on a given level of performance and can increase the performance with additional investments in its own service components and systems
• The organization can count on a given level of reliability
• There is stability in the operation of the system from the users' perspective (it does the same thing the same way all the time).
• If there are defects, the sub-organization responsible for the composite application can correct it without (formal or informal) contract negotiations.
• If new technology should be inserted into one or more service components, the organization owning the composite application can implement it without reference other organization's.

Consequently, organization's should always implement composite applications supporting "business critical" processes and functions using orchestration.

Choreography:

• The composite application exists across two or more ownership domains, so that in teaming, sub-contracting, and similar situations the dynamic linkage of Choreography is very helpful.
• If there is a highly specialized service component that is required to perform a particular function, then choreography is preferred.
• In intelligence gathering situations
• In non-core "business" functions.  For example, if you are the business of manufacturing ice cream cakes, then having a full time HR function, or even accounting function may not be cost efficient and is not part of the core functions of the organization.  Instead, they are sustaining functions, which can be outsourced.   In smaller businesses, linking to outside HR and Accounting functions for various services may, likewise, be sensible.
• Finally, if service components are treated as "apps for applications" then many of the benefits are the same as for end-user using "apps" on their wireless device.

The problem with choreography is that it is not within the control of the organization wanting to use it.  Consequently:

• It can't control the policies and standards used within the service component(s) that are outside its ownership domain; it can only contract for its use.  This means that it has little power to audit the service component other than for the contractual obligations, such as Service Level Agreements (SLAs).
• The standards and policies to which the services are built may change, so that a customer organization may need to either change it interface, wavier one or more of its policies and standards, or discover a new service.

So there are pluses and minisus to each.  Also see my Posts "Assembling Services: A paradigm shift in creating and maintaining  applications", "Asset and Enterprise Architecture Repository", and "Using Enterprise Architecture to Reduce the Federal Debt".