Orchestration
• Orchestration has following applications
1. To provide centrally controlled workflow logic for
interoperability – For legacy systems
2. To act as a service which represents business logic
in a standard venue – For SOA
• WS-BPEL (Business Process Execution Language)
standardizes orchestration
1
Figure 6.32. An orchestration controls almost every facet of a complex activity.
The role of orchestration broadens in service-oriented environments. Through the
use of extensions that allow for business process logic to be expressed via services,
orchestration can represent and express business logic in a standardized, services-
based venue. When building service-oriented solutions, this provides an extremely
attractive means of housing and controlling the logic representing the process being
automated.
Orchestration further leverages the intrinsic interoperability sought by service designs
by providing potential integration endpoints into processes. A key aspect to how
orchestration is positioned within SOA is the fact that orchestrations themselves exist
as services. Therefore, building upon orchestration logic standardizes process
representation across an organization, while addressing the goal of enterprise
federation and promoting service-orientation.
2
Business Protocols and Process
Definition
• Business Protocols:
– Define the rules , conditions and events by which
the participants can interoperate to complete a
business task
– Part of Orchestration
• Process Definition:
– The details of the workflow logic are contained
within process definition
3
Process Service and Partner Services
• Process definition (process service) contains process
participants’ details
• Process service can invoke partner services and it can
also be invoked by partner services
4
Process Services and Partner Services
Figure 6.33. A process service coordinating and exposing functionality from three
partner services.
Identified and described within a process definition are the allowable process
participants. First, the process itself is represented as a service, resulting in a process
service (which happens to be another one of our service models, as shown in Figure
6.33).
Other services allowed to interact with the process service are identified as partner
services or partner links.
5
Process Service and Partner Services
Figure 6.34. The process service, after first being invoked by a partner service, then
invokes another partner service.
Depending on the workflow logic, the process service can be invoked by an external
partner service, or it can invoke other partner services (Figure 6.34).
6
Basic Activities and Structured
Activities
• WS-BPEL breaks down workflow logic into a series of
predefined primitive activities.
• Basic activities (receive, invoke, reply, throw, wait)
represent fundamental workflow actions
– which can be assembled using the logic supplied
by structured activities (sequence, switch, while,
flow).
A primary industry specification that standardizes orchestration is the Web services
Business Process Execution Language (WS-BPEL)
7
Sequences, Flows, and Links
• A sequence aligns groups of related activities into a
list that determines a sequential execution order.
• Flows also contain groups of related activities, but
they introduce different execution requirements.
– Flows ensures a form of synchronization among
application logic residing in individual flows.
• Links are used to establish formal dependencies
between activities that are part of flows.
Basic and structured activities can be organized so that the order in which they
execute is predefined. A sequence aligns groups of related activities into a list that
determines a sequential execution order. Sequences are especially useful when one
piece of application logic is dependent on the outcome of another.
Flows also contain groups of related activities, but they introduce different execution
requirements. Pieces of application logic can execute concurrently within a flow,
meaning that there is not necessarily a requirement for one set of activities to wait
before another finishes. However, the flow itself does not finish until all encapsulated
activities have completed processing. This ensures a form of synchronization among
application logic residing in individual flows.
Links are used to establish formal dependencies between activities that are part of
flows. Before an activity fully can complete, it must ensure that any requirements
established in outgoing links first are met. Similarly, before any linked activity can
begin, requirements contained within any incoming links first must be satisfied. Rules
provided by links are also referred to as synchronization dependencies.
8
Orchestration and Others
• Orchestration and Activities:
– A single orchestration can be classified as a
complex, long running activity
• Orchestration and Coordination:
– Orchestration can use WS- Business Activity
coordination type
9
Orchestration and SOA
Business process logic is at the root of automation solutions. Orchestration provides
an automation model where process logic is centralized yet still extensible and
composable (Figure 6.35). Through the use of orchestrations, service-oriented
solution environments become inherently extensible and adaptive. Orchestrations
themselves typically establish a common point of integration for other applications,
which makes an implemented orchestration a key integration enabler.
These qualities lead to increased organizational agility because:
The workflow logic encapsulated by an orchestration can be modified or extended in
a central location.
Positioning an orchestration centrally can significantly ease the merging of business
processes by abstracting the glue that ties the corresponding automation solutions
together.
By establishing potentially large-scale service-oriented integration architectures,
orchestration, on a fundamental level, can support the evolution of a diversely
federated enterprise.
Orchestration is a key ingredient to achieving a state of federation within an
organization that contains various applications based on disparate computing
platforms. Advancements in middleware allow orchestration engines themselves to
become fully integrated in service-oriented environments.
10
Figure 6.36. The extended TLS Purchase Order Submission Process managed by an
orchestration and involving numerous potential partner organizations.
The series of steps we wrapped into a business activity in the previous case study
example demonstrated how TLS used the WS-BusinessActivity protocol to add
context management and exception handling to a long-running, complex activity.
Even though the scope of a business activity can constitute a business process, it
does not provide TLS with a standard means of expressing the underlying workflow
logic. For that, TLS employs a WS-BPEL orchestration (Figure 6.36).
The orchestration establishes comprehensive process logic that encompasses the
business activity and extends it even further to govern additional interaction
scenarios with multiple vendor services. For example, when one vendor cannot fulfill
an order, the next vendor in line is sent the same purchase order. This cycle is
repeated until either one vendor can complete the order in its entirety (within certain
price limitations) or until all vendors have been queried. In the latter situation, the
system simply assesses the best deal on the table by applying a formula that takes
into account the price, percentage of order to be filled, and backorder terms.
The orchestration logic manages all aspects of the process, including the involvement
of multiple vendor partner services, as well as the business activity that kicks in when
a PO is processed.
11
So far,
• An orchestration expresses a body of business process
logic that is typically owned by a single organization.
• An orchestration establishes a business protocol that
formally defines a business process definition.
• The workflow logic within an orchestration is broken
down into a series of basic and structured activities
that can be organized into sequences and flows.
• Orchestration has been called the "heart of SOA," as it
establishes a means of centralizing and controlling a
great deal of inter and intra-application logic through a
standardized service model.
12
Choreography
In a perfect world, all organizations would agree on how internal processes should be
structured, so that should they ever have to interoperate, they would already have
their automation solutions in perfect alignment.
Though this vision has about a zero percent chance of ever becoming reality, the
requirement for organizations to interoperate via services is becoming increasingly
real and increasingly complex. This is especially true when interoperation
requirements extend into the realm of collaboration, where multiple services from
different organizations need to work together to achieve a common goal.
The Web Services Choreography Description Language (WS-CDL) is one of several
specifications that attempts to organize information exchange between multiple
organizations (or even multiple applications within organizations), with an emphasis
on public collaboration (Figure 6.37). It is the specification we've chosen here to
represent the concept of choreography and also the specification from which many of
the terms discussed in this section have been derived.
13
Choreography
• When different organizations interoperate via
services, common collaboration is needed to work
together
• WS-CDL (Choreography Description Language) allows
information exchange between multiple
organizations with public collaboration
After a few months in operation, our little car washing enterprise achieves some success.
With our flexible and adaptive system, we have been able to efficiently wash enough cars to
make some profit. Once word in the car washing circles gets around, we are contacted by a
nearby car washing company.
Even though this team of car washers is located only a kilometer away, they are not
considered competitors. We positioned ourselves at a gas station located at the off ramp of a
highway, and they are on the other side. Our customers originate from North-bound traffic,
whereas theirs come from cars heading South. As a result, we have different peak hours
corresponding directly to the traffic patterns of the highway. Our volume peaks during the
morning rush hours, whereas theirs peaks in the afternoon.
It is suggested to us that we could form a partnership whereby we pool our respective
resources (workers) to allow each of our companies to maximize the potential of each rush
hour period. This form of collaboration appeals to us, as so far we've never been able to wash
as many cars as we could at peak times. When customers entering the gas station grounds
see a line up to our car wash, they often change their minds and drive away.
We decide to join forces with the other team. However, this arrangement soon affects our
original business process. We now have to introduce a process that imposes new conditions
and constraints. At the same time, though, we want to protect our existing system because it
has been successful. After discussing these issues with our new partner, we come to an
agreement that results in a flexible collaboration process.
A choreography is essentially a collaboration process designed to allow organizations to
interact in an environment that is not owned by any one partner.
14
Collaboration
• An important characteristic of choreographies is that
they are intended for public message exchanges.
• No one entity (organization) necessarily controls the
collaboration logic.
• Choreographies therefore provide the potential for
establishing universal interoperability patterns for
common inter-organization business tasks.
An important characteristic of choreographies is that they are intended for public
message exchanges. The goal is to establish a kind of organized collaboration
between services representing different service entities, only no one entity
(organization) necessarily controls the collaboration logic. Choreographies therefore
provide the potential for establishing universal interoperability patterns for common
inter-organization business tasks.
Note
While the emphasis on choreography is B2B interaction, it also can be applied to
enable collaboration between applications belonging to a single organization. The use
of orchestration, though, is far more common for this requirement.
15
Roles and Participants
• Within any given choreography, a Web service
assumes one of a number of predefined roles.
• Related services are grouped accordingly, categorized
as participants (services).
Within any given choreography, a Web service assumes one of a number of
predefined roles. This establishes what the service does and what the service can do
within the context of a particular business task. Roles can be bound to WSDL
definitions, and those related are grouped accordingly, categorized as participants
(services).
16
Relationships and Channels
• Each potential exchange between two roles in a
choreography is defined individually as a
relationship.
• Every relationship consequently consists of exactly
two roles.
• Channels define the characteristics of the message
exchange between two specific roles.
Every action that is mapped out within a choreography can be broken down into a
series of message exchanges between two services. Each potential exchange
between two roles in a choreography is therefore defined individually as a
relationship. Every relationship consequently consists of exactly two roles.
17
Interactions and Work Units
• The actual logic behind a message exchange is
encapsulated within an interaction.
• “Interactions are the fundamental building blocks of
choreographies because the completion of an
interaction represents actual progress within a
choreography.”
• Related to interactions are work units. These impose
rules and constraints that must be adhered to for an
interaction to successfully complete.
18
Orchestrations and Choreographies
Figure 6.39. A choreography enabling collaboration between two different
orchestrations.
While both represent complex message interchange patterns, there is a common
distinction that separates the terms "orchestration" and "choreography." An
orchestration expresses organization-specific business workflow. This means that an
organization owns and controls the logic behind an orchestration, even if that logic
involves interaction with external business partners. A choreography, on the other
hand, is not necessarily owned by a single entity. It acts as a community interchange
pattern used for collaborative purposes by services from different provider entities
(Figure 6.39).
One can view an orchestration as a business-specific application of a choreography.
This view is somewhat accurate, only it is muddled by the fact that some of the
functionality provided by the corresponding specifications (WS-CDL and WS-BPEL)
actually overlaps. This is a consequence of these specifications being developed in
isolation and submitted to separate standards organizations (W3C and OASIS,
respectively).
An orchestration is based on a model where the composition logic is executed and
controlled in a centralized manner. A choreography typically assumes that there is no
single owner of collaboration logic. However, one area of overlap between the
current orchestration and choreography extensions is the fact that orchestrations can
be designed to include multi-organization participants. An orchestration can
therefore effectively establish cross-enterprise activities in a similar manner as a
choreography. Again, though, a primary distinction is the fact that an orchestration is
generally owned and operated by a single organization.
19
Orchestrations Choreographies
An orchestration expresses A choreography, on the other
organization-specific business hand, is not necessarily owned
workflow. by a single entity.
An organization owns and It acts as a community
controls the logic behind an interchange pattern used for
orchestration, even if that logic collaborative purposes by
involves interaction with external services from different provider
business partners. entities
An orchestration is based on a A choreography typically
model where the composition assumes that there is no single
logic is executed and controlled owner of collaboration logic.
in a centralized manner.
20
Choreography and SOA
The fundamental concept of exposing business logic through autonomous services
can be applied to just about any implementation scope. Two services within a single
organization, each exposing a simple function, can interact via a basic MEP to
complete a simple task. Two services belonging to different organizations, each
exposing functionality from entire enterprise business solutions, can interact via a
basic choreography to complete a more complex task. Both scenarios involve two
services, and both scenarios support SOA implementations.
Choreography therefore can assist in the realization of SOA across organization
boundaries (Figure 6.40). While it natively supports composability, reusability, and
extensibility, choreography also can increase organizational agility and discovery.
Organizations are able to join into multiple online collaborations, which can
dynamically extend or even alter related business processes that integrate with the
choreographies. By being able to pass around channel information, participating
services can make third-party organizations aware of other organizations with which
they already have had contact.
21
So far,
• A choreography is a complex activity comprised of a
service composition and a series of MEPs.
• Choreographies consist of multiple participants that
can assume different roles and that have different
relationships.
• Choreographies are reusable, composable, and can
be modularized.
• The concept of choreography extends the SOA vision
to standardize cross-organization collaboration.
22
In past discussions we established a series of composition and activity management
concepts, each with a different scope and purpose, but all somewhat related within
the context of composable SOA. Those initial concepts are complemented by
additional WS-* extensions that govern specific areas of the SOAP messaging
framework, the creation and exchange of metadata, and the introduction of message-
level security. (Figure 7.1 introduces the individual concepts and shows how they
typically inter-relate.)
Figure 7.1. Specifications and concepts covered in this chapter.
As we explore the various extensions in this chapter, it becomes increasingly clear
that SOAP messaging is the lifeblood of contemporary service-oriented architecture.
It realizes not only the delivery of application data, but also the composable nature of
SOA.
23
In the previous chapter we provided several examples that explained the steps
behind the vendor invoice submission process. One of these steps required that,
upon receiving an invoice from a vendor, the TLS Accounts Payable Service interacts
with the TLS Vendor Profile Service to have the received invoice validated against
vendor account information already on file.
Due to the volume of invoice submissions received by TLS, there can be, at any given
time, multiple active instances of the Accounts Payable Service. Therefore, as part of
the message issued by the Accounts Payable Service to the Vendor Profile Service, a
SOAP header providing a reference id is included. This identifier represents the
current instance of the Accounts Payable Service and is used by the Vendor Profile
Service to locate this instance when it is ready to respond with the validation
information (Figure 7.6).
Figure 7.6. Separate service instances communicating using endpoint references and
MI headers across two pools of Web services within TLS.
24
