Drexel University Date: 11/07/05
CS 575 Dr. Mitchell
Max Lincoln e-mail: email@example.com
Slava Sadkhin e -mail: firstname.lastname@example.org *** team contact
Yaqi Zhang e-mail: email@example.com
Kathy Yang e-mail: firstname.lastname@example.org
Topics in SOA: Orchestration versus Choreography
Extended Abstract: Orchestration vs. Choreography in Single Organizational SOAs
Services utilized within a Service Oriented Architecture (SOA) may be provided by
different organizations. Often, a service provided by one organization may be the constructed
by aggregating services provided by other organizations. This is especially common in
Business-to-Business (B2B) transactions performed through the SOA. SOAs are useful in single
organizational environments as well, however. In a Business to Consumer (B2C) service over
an SOA, a service may be an aggregation of services provided by a single organization.
Two distinct styles of composing a single service from multiple services exist. Services
based on the orchestration model have a central control point, which may invoke both internal
and external services. Choreographed services do not have a central control point, requiring
each service to know how it interacts with other services. Choreographed services have the
advantage in B2B transactions that a central party does not have to be defined to control the
service, but it also means that services require more knowledge of each other to interact.
This paper considers usage models for Choreography and Orchestration within a single-
organization, B2C application. It argues that the centralized control provided by Orchestrated
services offers many benefits to application development and maintenance, and simplifies the
high-level picture of the SOA so it can more easily be understood and implemented.
Web services are business processes that run over a network using standards such as
XML-RPC or, most commonly, SOAP. SOAP stands for the Simple Object Access Protocol but
this is generally considered a misnomer, and there is a movement in a software engineering
community to redefine SOAP acronym to better reflect direction in Service Oriented
Architecture. This architecture is principally an XML messaging standard, where XML
documents are sent to and optionally returned from URLs, referred to as service endpoints.
Web Services can be viewed as an extension of component models, such as Sun's Enterprise
JavaBeans (EJB) and Microsoft's Component Object Model (COM).
With the introduction of web services, “web services composition” is used to describe
the composition of web services into a process. We can derive two ways to design a service
composition: choreography or orchestration. Martin Chapman, co-chair of the WS-
Choreography working group and a member of Oracle's Web-services strategy team
emphasizes the importance of careful defining the differing process composition terminology
used in the industry, such as orchestration, collaboration, coordination, conversations: "By
orchestration you mean there is a central controller and the business process is run by that
controller, and by choreography you mean there is no controller and the business process is run
in a distributed way by each of the participants..."
Choreography is defined as “collaboration between some enterprise services to achieve a
common goal”. It doesn’t focus on one service, but its control logic is visible when services
interact with each other. The relationship between the distributed services can be tracked by
the sequence of messages that may involve, for instance, multiple parties and multiple sources,
including customers and suppliers. Choreography is typically associated with the public
message exchanges that occur between multiple web services, rather than a specific business
process that is executed by a single party.
One of characteristics of Choreography an organization needs to consider are simple
consumer oriented interactions. Processes are short-lived and don’t require business
collaboration. Companies should not make their emphasis on security and reliability. There is
no one centralized repository, and processes require synchronization with much maintenance
costs involved over the long run.
In choreography, services must perform transformations themselves, or call a service to
perform the transformation. Steps in choreography are performed to following a predefined
scheme, maintaining its overall global perspective. So, Choreography is more collaborative,
and each party involved in a process has a specific part of interaction. It implies that there is no
centralized control, and actual control is shared among module domains.
For example, large ERP systems consist of functional modules. Each independent
module maintains its integrity and consistency through the use of synchronizing interfaces.
Each interface behaves to a predefined collaboration scheme, where all exceptions are managed
based on system’s state. If a purchase order is received and distributed, then the related
transaction information needs to be updated on accounts payable side. This is done through an
interface where each required field has to be filled in and validated.
On another hand, Orchestration implies a centralized control mechanism. It describes a
behavior that “a service provider implements to realize a service”. Orchestration describes how
web services can interact with each other at the message level, including the business logic and
execution order of the interactions. A step process model is introduced to deal with these
interactions. An orchestration processes are run by orchestration engines, which act as the
central control point.
Since orchestration uses a centralized control point, this central point may be used to
handle problems that all services may face. For example, an orchestration process engine could
act as a primary transaction, security and reliability manager. Orchestration can also help
reduce coupling between services, since they do not communicate directly, and the
input/output of each service may be transformed by the orchestration engine to “fit” services
together. Orchestration-oriented languages such as BPML and BPEL support these capabilities.
An advantage that we are looking for in an orchestrated approach is that web services
are controlled to be dynamic, adaptable and flexible to changing business needs. If the web
services utilized are granular enough, business processes may be changed by changing the way
the services interact or the set of services used, rather than by changing the underlying service
The largest advantage of an orchestrated service may lie at the conceptual level.
Orchestrated systems are easy to understand, implement, and maintain, since the interaction
between services happens in a consistent way. Unlike most choreography-based approaches,
services do not need to consider and synchronize state, which results in less design and
implementation time, and less lines of code.
Combining Orchestration and Choreography
Orchestration and choreography are mutually exclusive high-level process management
patterns, but it is important to note that a real-life system may use a combination of the two.
Although they are mutually exclusive, it is possible to layer the technologies. For example, it is
not uncommon for choreographed services to consist of orchestrated participants. In this case,
the global business process is defined by the choreographed interaction, but each participant
may be defining an internal business process through orchestration. In this scenario, the
choreographed process would likely be multi-organizational, while the orchestrated process
would be within an organization. A simple example of this type of combination is shown in
The opposite scenario is also possible, orchestrated services may utilize a choreographed
process. This is illustrated in Figure 2. This scenario seems to negate many of the benefits of
both choreography and orchestration. For example, it has added a central control point to an
otherwise choreographed system, and it has coupled the services so that the process can’t be
redefined using only changes at the orchestration engine level.
(Shin, Sun Microsystems)
Web services standards for process execution and modeling based on the concept of
aggregating services into a process are still developing. There are many options available to
organizations, which makes the choice of a standard a difficult one that should be thoroughly
investigated. However, several architectural styles have emerged to classify the different
standards, and organizations may use characteristics of these styles to guide their
investigations. In this paper, we found that the orchestration style, characterized principally by
a central control point, offers advantages to business processes that do not cross-organizational
boundaries. Coordination was found to have some benefits for cross-organizational processes.
Therefore, projects that are proposed within the scope of a single organization should seriously
consider using an orchestration-based approach to their SOA. Since choreographed services
often utilize orchestrated participants, this approach does not prevent systems from becoming
part of cross-organizational processes later.
Chris Peltz, “Web services orchestration and choreography”, Computer,
Volume 36, Issue 10, Oct. 2003 Page(s):46 - 52, IEEE.
R. Shapiro "A Comparison of XPDL, BPML, and BPEL4WS," draft document, Cape
Visions, May 2002; http://xml.coverpages.org/Shapiro-XPDL.pdf.
S. Kumaran and P. Nandi "Conversational Support for Web Services: The Next Stage of
Web Services Abstraction," research report, IBM developerWorks, Sept. 2002;
BPMI, "The BPML Specification", http://www.bpmi.org/bpml-spec.htm
BEA Systems, IBM Corporation, Microsoft Corporation, SAP AG, Siebel Systems,
“Business Process Execution Language for Web Services, Version 1.1”, May 5, 2003;