Thursday, March 10, 2011

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.

4 comments:

  1. this article is the simplest way to understand "orcestration and choreography" :)

    but when I browse in the Internet about how implement Choreography, there is few solution on it. One of the newest engine I found is Savara ( http://www.jboss.org/savara ). And I still it's not easy to implement it.

    ReplyDelete
  2. First, Thanks for the comment. Second,orchestration uses one of several language of which the The most common is Business Process Execution Language (BPEL), which OASIS has made a standard as Web Services-Business Process Execution Language (WS-BPEL. On the other hand, standards for choreography languages are much less well known, and to your point, have fewer implementations available. Currently, there are several candidate choreography languages. These include candidate standards/languages like the W3C’s WS-Choreography, the Object Management Group’s Business Process Model Notation (BPMN), and several others.

    But, the key issue is both technical and business related. Choreography is highly dependent on being able to find Service Components on the Internet. This requires standardize key words in the WSDL (Web Services Desciption Language) or its equivalent, so that the when a Choreography-based Service searches for it, the Service Component can be discovered easily. Additionally, it requires a registry on the Internet with dependable Service Components. As I discussed in my post "SOA, the User Interface Service Components, Apps, and Validation before Registering", validation is exceptionally important if the component is going to be used more than once; and, as I discussed, before an App (which is essentially, a Service Component) is sold through its Apps Store, Apple spends a good deal of effort validating it. If Oracle or SAP were to do the same with their Web Services, then Choreography would become much more useful. This is what the originators of Web Services had envisioned.

    ReplyDelete
  3. First, Thanks for the comment. Second,orchestration uses one of several language of which the The most common is Business Process Execution Language (BPEL), which OASIS has made a standard as Web Services-Business Process Execution Language (WS-BPEL. On the other hand, standards for choreography languages are much less well known, and to your point, have fewer implementations available. Currently, there are several candidate choreography languages. These include candidate standards/languages like the W3C’s WS-Choreography, the Object Management Group’s Business Process Model Notation (BPMN), and several others.

    But, the key issue is both technical and business related. Choreography is highly dependent on being able to find Service Components on the Internet. This requires standardize key words in the WSDL (Web Services Desciption Language) or its equivalent, so that the when a Choreography-based Service searches for it, the Service Component can be discovered easily. Additionally, it requires a registry on the Internet with dependable Service Components. As I discussed in my post "SOA, the User Interface Service Components, Apps, and Validation before Registering", validation is exceptionally important if the component is going to be used more than once; and, as I discussed, before an App (which is essentially, a Service Component) is sold through its Apps Store, Apple spends a good deal of effort validating it. If Oracle or SAP were to do the same with their Web Services, then Choreography would become much more useful. This is what the originators of Web Services had envisioned.

    ReplyDelete
  4. The article is very useful for understand when implemment orchestration and choreography.

    About choreography, can you explain what is exactly models "invisible hub" and "sum of the parts"

    Regards

    ReplyDelete