Unit III: Web Services and Contemporary SOA: Message exchange patterns – Service

activity- coordination – Atomic transactions – Business activities- Orchestration

Web Services and Contemporary SOA

The messaging model used for inter-service communication is simple in nature. The challenge lies in implementing this model
on an enterprise level while supporting SOA characteristics and preserving the principles of service-orientation.

To execute an automated business task with any substance, we need to be able to coordinate and compose a set of available
services. To successfully perform this type of coordination requires that we have control over messaging that occurs between
our composed services. Both conversational characteristics inherent in the Web services framework and specific features
provided by key WS-* specifications provide a means to assert this control.

This chapter explains key concepts that define the messaging-based services activity model and also discusses the role and
context of concepts derived from WS-* specifications that implement standardized activity management and composition
mechanisms. Collectively, these concepts (and the specifications from which they are derived) contribute to a robust,
coordinated, and transaction-capable service-oriented architecture that is characteristically composable and extensible. (Figure
6.1 illustrates the concepts discussed in this chapter and shows, on a high-level, how they can inter-relate.)

Figure 6.1. Specifications and concepts covered in this chapter.

To demonstrate common concepts, this chapter uses terms provided by current
specifications in various stages of industry acceptance. In particular:

o WS-Coordination (including WS-AtomicTransaction and WS-BusinessActivity coordination types)

o WS-BPEL (also known as BPEL4WS)
o WS-CDL (also known as WS-Choreography)

Message exchange patterns

Every task automated by a Web service can differ in both the nature of the application logic being executed and the role played
by the service in the overall execution of the business task. Regardless of how complex a task is, almost all require the
transmission of multiple messages. The challenge lies in coordinating these messages in a particular sequence so that the
individual actions performed by the message are executed properly and in alignment with the overall business task (Figure 6.2).

Figure 6.2. Not all message exchanges require both requests and responses.
Message exchange patterns (MEPs) represent a set of templates that provide a group of already mapped out sequences for
the exchange of messages. The most common example is a request and response pattern. Here the MEP states that upon
successful delivery of a message from one service to another, the receiving service responds with a message back to the initial
requestor.

Many MEPs have been developed, each addressing a common message exchange requirement. It is useful to have a basic
understanding of some of the more important MEPs, as you will no doubt be finding yourself applying MEPs to specific
communication requirements when designing service-oriented solutions.

6.1.1. Primitive MEPs

Before the arrival of contemporary SOA, messaging frameworks were already well used by various messaging-oriented
middleware products. As a result, a common set of primitive MEPs has been in existence for some time.

Request-response

This is the most popular MEP in use among distributed application environments and the one pattern that defines synchronous
communication (although this pattern also can be applied asynchronously).

The request-response MEP (Figure 6.3) establishes a simple exchange in which a message is first transmitted from a source
(service requestor) to a destination (service provider). Upon receiving the message, the destination (service provider) then
responds with a message back to the source (service requestor).

Figure 6.3. The request-response MEP.

Note that within this MEP, services typically require a means of associating the response message with the corresponding
request message. This can be achieved through correlation, a concept explained in Chapter 7.

Fire-and-forget

This simple asynchronous pattern is based on the unidirectional transmission of messages from a source to one or more
destinations (Figure 6.5).

Figure 6.5. The fire-and-forget MEP.

A number of variations of the fire-and-forget MEP exist, including:

o The single-destination pattern, where a source sends a message to one destination only.
o The multi-cast pattern, where a source sends messages to a predefined set of destinations.
o The broadcast pattern, which is similar to the multi-cast pattern, except that the message is sent out to a broader
range of recipient destinations.

The fundamental characteristic of the fire-and-forget pattern is that a response to a transmitted message is not expected.

Complex MEPs

Even though a message exchange pattern can facilitate the execution of a simple task, it
is really more of a building block intended for composition into larger patterns. Primitive
MEPs can be assembled in various configurations to create different types of messaging
models, sometimes called complex MEPs.

A classic example is the publish-and-subscribe model. Although we explain publish-and-

subscribe approaches in more detail in Chapter 7, let's briefly discuss it here as an
example of a complex MEP.

The publish-and-subscribe pattern introduces new roles for the services involved with the message exchange. They now
become publishers and subscribers, and each may be involved in the transmission and receipt of messages. This
asynchronous MEP accommodates a requirement for a publisher to make its messages available to a number of subscribers
interested in receiving them.

The steps involved are generally similar to the following:

Step The subscriber sends a message to notify the publisher that it wants to receive messages on a particular topic.
1.
Step Upon the availability of the requested information, the publisher broadcasts messages on the particular topic to all of that
2. topic's subscribers.

This pattern is a great example of how to aggregate primitive MEPs, as shown in Figure 6.7 and explained here:

o Step 1 in the publish-and-subscribe MEP could be implemented by a request-response MEP, where the subscriber's
request message, indicating that it wants to subscribe to a topic, is responded to by a message from the publisher,
confirming that the subscription succeeded or failed.
o Step 2 then could be supported by one of the fire-and-forget patterns, allowing the publisher to broadcast a series of
unidirectional messages to subscribers.

Figure 6.7. The publish-and-subscribe messaging model is a composite of two primitive MEPs.
WS-* specifications that incorporate this messaging model include:

o WS-BaseNotification
o WS-BrokeredNotification
o WS-Topics
o WS-Eventing

Concepts relating to these specifications are discussed in the next chapter as part of the Notification and eventing section.

6.1.2. MEPs and SOAP

On its own, the SOAP standard provides a messaging framework designed to support single-direction message transfer. The
extensible nature of SOAP allows countless messaging characteristics and behaviors (MEP-related and otherwise) to be
implemented via SOAP header blocks. The SOAP language also provides an optional parameter that can be set to identify the
MEP associated with a message. (Note that SOAP MEPs also take SOAP message compliance into account.)

6.1.3. MEPs and WSDL

Operations defined within service descriptions are comprised, in part, of message definitions. The exchange of these messages
constitutes the execution of a task represented by an operation. MEPs play a larger role in WSDL service descriptions as they
can coordinate the input and output messages associated with an operation. The association of MEPs to WSDL operations
thereby embeds expected conversational behavior into the interface definition.

WSDL operations support different configurations of incoming, outgoing, and fault messages. These configurations are
equivalent to message exchange patterns, but within the WSDL specification, they often are referred to simply as patterns. It is
important to note that WSDL definitions do not restrict an interface to these patterns; they are considered minimal
conversational characteristics that can be extended.

Release 1.1 of the WSDL specification provides support for four message exchange patterns that roughly correspond to the
MEPs we described in the previous section. These patterns are applied to service operations from the perspective of a service
provider or endpoint. In WSDL 1.1 terms, they are represented as follows:

o Request-response operation Upon receiving a message, the service must respond with a standard message or a
fault message.
 o Solicit-response operation Upon submitting a message to a service requestor, the service expects a standard
response message or a fault message.
o One-way operation The service expects a single message and is not obligated to respond.
o Notification operation The service sends a message and expects no response.

Of these four patterns (also illustrated in Figure 6.9), only the request-response operation and one-way operation MEPs are
recommended by the WS-I Basic Profile.

Figure 6.9. The four basic patterns supported by WSDL 1.1.

Not only does WSDL support most traditional MEPs, recent revisions of the specification have extended this support to include
additional variations. Specifically, release 2.0 of the WSDL specification extends MEP support to eight patterns (and also
changes the terminology) as follows.

o The in-out pattern, comparable to the request-response MEP (and equivalent to the WSDL 1.1 request-response
operation).
o The out-in pattern, which is the reverse of the previous patternwhere the service provider initiates the exchange by
transmitting the request. (Equivalent to the WSDL 1.1 solicit-response operation.)
o The in-only pattern, which essentially supports the standard fire-and-forget MEP. (Equivalent to the WSDL 1.1 one-
way operation.)
o The out-only pattern, which is the reverse of the in-only pattern. It is used primarily in support of event notification.
(Equivalent to the WSDL 1.1 notification operation.)
o The robust in-only pattern, a variation of the in-only pattern that provides the option of launching a fault response
message as a result of a transmission or processing error.
o The robust out-only pattern, which, like the out-only pattern, has an outbound message initiating the transmission.
The difference here is that a fault message can be issued in response to the receipt of this message.
o The in-optional-out pattern, which is similar to the in-out patternwith one exception. This variation introduces a rule
stating that the delivery of a response message is optional and should therefore not be expected by the service
requestor that originated the communication. This pattern also supports the generation of a fault message.
o The out-optional-in pattern is the reverse of the in-optional-out pattern, where the incoming message is optional.
Fault message generation is again supported.

6.1.4. MEPs and SOA

MEPs are highly generic and abstract in nature. Individually, they simply relate to an interaction between two services. Their
relevance to SOA is equal to their relevance to the abstract Web services framework. They are therefore a fundamental and
essential part of any Web services-based environment, including SOA.

Service activity
he completion of business tasks is an obvious function of any automated solution. Tasks
are comprised of processing logic that executes to fulfill a number of business
requirements. In service-oriented solutions, each task can involve any number of
services. The interaction of a group of services working together to complete a task can
be referred to as a service activity (Figure 6.10).

Figure 6.10. In an activity, multiple Web services collaborate to do a specific piece of

work.

Note

Though there is no formal definition of the term "activity," it is used by several of the
specifications we discuss in this book. It is a generic term that is most frequently
associated with a logical unit of work completed by a collection of services.

6.2.1. Primitive and complex service activities

The scope of an activity can drastically vary. A simple or primitive activity is typified by
synchronous communication and therefore often consists of two services exchanging
information using a standard request-response MEP (Figure 6.11). Primitive activities
are almost always short-lived; the execution of a single MEP generally constitutes the
lifespan of a primitive activity.

Figure 6.11. A primitive service activity consisting of a simple MEP.

Complex activities, on the other hand, can involve many services (and MEPs) that
collaborate to complete multiple processing steps over a long period of time (Figure
6.12). These more elaborate types of activities are generally structured around
extension-driven and composition-oriented concepts, such as choreography and
orchestration. However, a business task automated by a series of custom-developed
services and without the use of a composition extension can just as easily be classified
a complex activity.

Figure 6.12. A complex activity involving four services.

6.2.2. Service activities and SOA

In SOAs, activities represent any service interaction required to complete business

tasks. The scope of a service activity is primarily concerned with the processing and
communication between services only. The underlying application logic of each Web
service, whether it consists of a single component or an entire legacy system, is
generally not mapped as part of a service activity. Complex activities are commonplace
in larger service-oriented solutions and can involve numerous participating services.

Note

The term "Web services activity" also happens to represent the ongoing Web services-
related work being performed by numerous W3C working groups.

Figure 6.13. A sample complex activity spanning RailCo and TLS boundaries.
Atomic transactions
Transactions have been around for almost as long as automated computer solutions
have existed. When managing certain types of corporate data, the need to wrap a series
of changes into a single action is fundamental to many business process requirements.
Atomic transactions implement the familiar commit and rollback features to enable cross-
service transaction support (Figure 6.20).

Figure 6.20. Atomic transactions apply an all-or-nothing requirement to work performed

as part of an activity.

Note

The concepts discussed in this section were derived from the WS-AtomicTransaction
specification, which defines protocols for use with WS-Coordination. (For a simple
example of how the WS-AtomicTransaction coordination type is referenced as part of a
SOAP header, see the WS-Coordination overview section in Chapter 16.)
6.4.1. ACID transactions

The protocols provided by the WS-AtomicTransaction specification enable cross-service

transaction functionality comparable to the ACID-compliant transaction features found in
most distributed application platforms.

For those of you who haven't yet worked with ACID transactions, let's quickly recap this
important standard. The term "ACID" is an acronym representing the following four
required characteristics of a traditional transaction:

o Atomic Either all of the changes within the scope of the transaction succeed, or
none of them succeed. This characteristic introduces the need for the rollback
feature that is responsible for restoring any changes completed as part of a failed
transaction to their original state.
o Consistent None of the data changes made as a result of the transaction can
violate the validity of any associated data models. Any violations result in a
rollback of the transaction.
o Isolated If multiple transactions occur concurrently, they may not interfere with
each other. Each transaction must be guaranteed an isolated execution
environment.
o Durable Upon the completion of a successful transaction, changes made as a
result of the transaction can survive subsequent failures.

6.4.2. Atomic transaction protocols

WS-AtomicTransaction is a coordination type, meaning that it is an extension created for

use with the WS-Coordination context management framework we covered in the
previous section. To participate in an atomic transaction, a service first receives a
coordination context from the activation service. It can subsequently register for
available atomic transaction protocols.

The following primary transaction protocols are provided:

o A Completion protocol, which is typically used to initiate the commit or abort

states of the transaction.
o The Durable 2PC protocol for which services representing permanent data
repositories should register.
o The Volatile 2PC protocol to be used by services managing non-persistent
(temporary) data.

Most often these protocols are used to enable a two-phase commit (2PC) that manages
an atomic transaction across multiple service participants.

6.4.3. The atomic transaction coordinator

When WS-AtomicTransaction protocols are used, the coordinator controller service can
be referred to as an atomic transaction coordinator. This particular implementation of the
WS-Coordination coordinator service represents a specific service model. The atomic
transaction coordinator (Figure 6.21) plays a key role in managing the participants of the
transaction process and in deciding the transaction's ultimate outcome.
Figure 6.21. The atomic transaction coordinator service model.

6.4.4. The atomic transaction process

As previously mentioned, the atomic transaction coordinator is tasked with the

responsibility of deciding the outcome of a transaction. It bases this decision on
feedback it receives from all of the transaction participants.

The collection of this feedback is separated into two phases. During the prepare phase
(Figure 6.22), all participants are notified by the coordinator, and each is asked to
prepare and then issue a vote. Each participant's vote consists of either a "commit" or
"abort" request (Figure 6.23).

Figure 6.22. The coordinator requesting that transaction participants prepare to vote.
Figure 6.23. The transaction participants voting on the outcome of the atomic
transaction.

After the votes are collected, the atomic transaction coordinator enters the commit
phase. It now reviews all votes and decides whether to commit or rollback the
transaction. The conditions of a commit decision are simple: if all votes are received and
if all participants voted to commit, the coordinator declares the transaction successful,
and the changes are committed. However, if any one vote requests an abort, or if any of
the participants fail to respond, then the transaction is aborted, and all changes are
rolled back (Figure 6.24).

Figure 6.24. The coordinator aborting the transaction and notifying participants to
rollback all changes.
6.4.5. Atomic transactions and SOA

Much of the transactional functionality implemented in service-oriented solutions is done

so among the components that execute an activity on behalf of a single service.
However, as more services emerge within an organization and as service compositions
become more commonplace, the need to move transaction boundaries into cross-
service interaction scenarios increases. Being able to guarantee an outcome of an
activity is a key part of enterprise-level computing, and atomic transactions therefore
play an important role in ensuring quality of service.

Not only do atomic transactional capabilities lead to a robust execution environment for
SOA activities, they promote interoperability when extended into integrated
environments. This allows the scope of an activity to span different solutions built with
different vendor platforms, while still being assured a guaranteed all-or-nothing outcome.
Assuming, of course, that WS-AtomicTransaction is supported by the affected
applications, this option broadens the application of the two-phase commit protocol
beyond traditional application boundaries (thus, supporting service interoperability).
Figure 6.25 illustrates how atomic transactions support these aspects of SOA.

Figure 6.25. Atomic transaction relating to other parts of SOA.

Business activities

Business activities govern long-running, complex service activities. Hours, days, or even
weeks can pass before a business activity is able to complete. During this period, the
activity can perform numerous tasks that involve many participants.

What distinguishes a business activity from a regular complex activity is that its
participants are required to follow specific rules defined by protocols. Business activities
primarily differ from the also protocol-based atomic transactions in how they deal with
exceptions and in the nature of the constraints introduced by the protocol rules.

For instance, business activity protocols do not offer rollback capabilities. Given the
potential for business activities to be long-running, it would not be realistic to expect
ACID-type transaction functionality. Instead, business activities provide an optional
compensation process that, much like a "plan B," can be invoked when exception
conditions are encountered (Figure 6.27).

Figure 6.27. A business activity controls the integrity of a service activity by providing
participants with a "plan B" (a compensation).

Note

The concepts discussed in this section are derived from the WS-BusinessActivity
specification, which (like WS-AtomicTransaction) provides protocols for use with WS-
Coordination. The WS-Coordination overview section in Chapter 16 contains a brief
example of how a coordination type referencing WS-BusinessActivity exists within a
SOAP header.

6.5.1. Business activity protocols

As with WS-AtomicTransaction, WS-BusinessActivity is a coordination type designed to

leverage the WS-Coordination context management framework. It provides two very
similar protocols, each of which dictates how a participant may behave within the overall
business activity.

o The BusinessAgreementWithParticipantCompletion protocol, which allows a

participant to determine when it has completed its part in the business activity.
o The BusinessAgreementWithCoordinatorCompletion protocol, which requires that
a participant rely on the business activity coordinator to notify it that it has no
further processing responsibilities.

Business activity participants interact with the standard WS-Coordination coordinator

composition to register for a protocol, as was explained in the previous Coordination
section.

6.5.2. The business activity coordinator

When its protocols are used, the WS-Coordination controller service assumes a role
specific to the coordination typein this case it becomes a business activity coordinator
(Figure 6.28). As explained in the previous section, this coordinator has varying degrees
of control in the overall activity, based on the coordination protocols used by the
participants.

Figure 6.28. The business activity coordinator service model.

6.5.3. Business activity states

During the lifecycle of a business activity, the business activity coordinator and the
activity participants transition through a series of states. The actual point of transition
occurs when special notification messages are passed between these services.
For example, a participant can indicate that it has completed the processing it was
required to perform as part of the activity by issuing a completed notification. This moves
the participant from an active state to a completed state. The coordinator may respond
with a close message to let the participant know that the business activity is being
successfully completed.

However, if things don't go as planned during the course of a business activity, one of a
number of options are available. Participants can enter a compensation state during
which they attempt to perform some measure of exception handling. This generally
invokes a separate compensation process that could involve a series of additional
processing steps. A compensation is different from an atomic transaction in that it is not
expected to rollback any changes performed by the participating services; its purpose is
generally to execute plan B when plan A fails.

Alternatively, a cancelled state can be entered. This typically results in the termination of
any further processing outside of the cancellation notifications that need to be
distributed.

What also distinguishes business activities from atomic transactions is the fact that
participating services are not required to remain participants for the duration of the
activity. Because there is no tight control over the changes performed by services, they
may leave the business activity after their individual contributions have been performed.
When doing so, participants enter an exit state by issuing an exit notification message to
the business activity coordinator.

These and other states are defined in a series of state tables documented as part of the
WS-BusinessActivity specification. These tables establish the fundamental rules of the
business activity protocols by determining the sequence and conditions of allowable
states.

6.5.4. Business activities and atomic transactions

It is important to note that the use of a business activity does not exclude the use of
atomic transactions. In fact, it is likely that a long-running business activity will
encompass the execution of several atomic transactions during its lifetime (Figure 6.29).

Figure 6.29. Two atomic transactions residing within the scope of a business activity.
6.5.5. Business activities and SOA

Business activities fully complement the composable nature of SOA (Figure 6.30) by
tracking and regulating complex activities while also allowing them to carry on for long
periods of time. Service autonomy and statelessness are preserved by permitting
services to participate within an activity for only the duration they are absolutely required
to. This also allows for the design of highly adaptive business activities wherein the
participants can augment activity or process logic to accommodate changes in the
business tasks being automated. Through the use of the compensation process,
business activities increase SOA's quality of service by providing built-in fault handling
logic.

Figure 6.30. A business activity relating to other parts of SOA.

As with WS-AtomicTransaction, support of the WS-BusinessActivity extension by
multiple solutions promotes inherent interoperability and can greatly simplify integration
architectures. Business activities take this a few steps further, though, by allowing the
scope of the activity to include interaction with outside business partners. (Note that
there is nothing restricting atomic transactions from being utilized across organizations.
However, business activities are typically more suitable for this type of communication.)

Orchestration
Organizations that already have employed enterprise application integration (EAI) middleware products to
automate business processes or to integrate various legacy environments will likely already be familiar with the
concept of orchestration. In these systems, a centrally controlled set of workflow logic facilitates interoperability
between two or more different applications. A common implementation of orchestration is the hub-and-spoke
model that allows multiple external participants to interface with a central orchestration engine.

One of the driving requirements behind the creation of these solutions was to accommodate the merging of large
business processes. With orchestration, different processes can be connected without having to redevelop the
solutions that originally automated the processes individually. Orchestration bridges this gap by introducing new
workflow logic. Further, the use of orchestration can significantly reduce the complexity of solution environments.
Workflow logic is abstracted and more easily maintained than when embedded within individual solution
components.

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.

Figure 6.32. An orchestration controls almost every facet of a complex activity.

A primary industry specification that standardizes orchestration is the Web services Business Process Execution
Language (WS-BPEL). This book recognizes WS-BPEL as a key second-generation extension and therefore
uses its concepts and terminology as the basis for a number of discussions relating to business process
modeling.

Note

WS-BPEL is the most recent name given to this specification, which also is known as BPEL4WS and just BPEL.
For an overview of the primary parts of the WS-BPEL language and a discussion of how the name change came
about, see Chapter 16.

6.6.1. Business protocols and process definition

The workflow logic that comprises an orchestration can consist of numerous business rules, conditions, and
events. Collectively, these parts of an orchestration establish a business protocol that defines how participants
can interoperate to achieve the completion of a business task. The details of the workflow logic encapsulated and
expressed by an orchestration are contained within a process definition.

6.6.2. Process services and 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).

Figure 6.33. A process service coordinating and exposing functionality from three partner services.
Other services allowed to interact with the process service are identified as partner services or partner links.
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).

Figure 6.34. The process service, after first being invoked by a partner service, then invokes another partner
service.

6.6.3. 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, pick). How these activities can be used to express
actual business process logic is explored in Chapter 16.

6.6.4. Sequences, flows, and links

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.

6.6.5. Orchestrations and activities

As we defined earlier, an activity is a generic term that can be applied to any logical unit of work completed by a
service-oriented solution. The scope of a single orchestration, therefore, can be classified as a complex, and
most likely, long-running activity.

6.6.6. Orchestration and coordination

Orchestration, as represented by WS-BPEL, can fully utilize the WS-Coordination context management
framework by incorporating the WS-BusinessActivity coordination type. This specification defines coordination
protocols designed to support complex, long-running activities.

6.6.7. 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.

Figure 6.35. Orchestration relating to other parts of SOA.

These qualities lead to increased organizational agility because:

o The workflow logic encapsulated by an orchestration can be modified or extended in a central location.
o Positioning an orchestration centrally can significantly ease the merging of business processes by
abstracting the glue that ties the corresponding automation solutions together.
o 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.
The concept of service-oriented orchestration fully leverages all of the concepts we've discussed so far in this
chapter. For many environments, orchestrations become the heart of SOA.