1

The 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. In an activity, multiple Web services collaborate to do a specific piece of
work.

2
3
4
5
Figure 6.12. A complex activity involving four services.
Complex activities involve many services (and MEPs) that collaborate to complete
multiple processing steps over a long period of time.

6
Figure 6.13. A sample complex activity spanning RailCo and TLS boundaries.
The message path traveled by a RailCo invoice submission is a great example of a
complex activity.
Here is a recap of the Invoice Submission Process we introduced in Chapter 5:
[Link] initial sender, RailCo's Invoice Submission Service, transmits the invoice
message.
[Link] message is first received by a passive intermediary, TLS's Load Balancing
Service, which routes the message according to environmental conditions. The
message subsequently arrives at TLS's Accounts Payable Service.
[Link] Accounts Payable Service acts as a controller and initiates a service
composition to begin processing the message contents. It begins by interacting with
the Vendor Profile Service to validate invoice header data and attaches the invoice
document to the vendor account.
[Link] Accounts Payable Service then extracts taxes, shipping fees, and the invoice
total. It passes these values to the Ledger Service, which updates various ledger
accounts, including the General Ledger.
[Link] the activity ends, as the Accounts Payable Service completes its processing
cycle by sending a response message back to RailCo.
Collectively, these processing steps constitute a complex activity involving five
services (Figure 6.13).

7
8
Every activity introduces a level of context into an application runtime environment.
Something that is happening or executing has meaning during its lifetime, and the
description of its meaning (and other characteristics that relate to its existence) can
be classified as context information.
The more complex an activity, the more context information it tends to bring with it.
The complexity of an activity can relate to a number of factors, including:
the amount of services that participate in the activity
the duration of the activity
the frequency with which the nature of the activity changes
whether or not multiple instances of the activity can concurrently exist

9
11
Coordination provides services that introduce controlled structure into activities.

12
WS-Coordination establishes a framework that introduces a generic service based on
the coordinator service model (Figure 6.15). This service controls a composition of
three other services that each play a specific part in the management of context
data.
The coordinator composition consists of the following services:
Activation service responsible for the creation of a new context and for
associating this context to a particular activity.
Registration service allows participating services to use context information
received from the activation service to register for a supported context
protocol.
Protocol-specific services represent the protocols supported by the
coordinator's coordination type.
Coordinator is the controller service of this composition, also known as the
coordination service.

13
14
Each coordinator is based on a coordination type, which specifies the nature and
underlying logic of an activity for which context information is being managed.
Coordination types are specified in separate specifications. The WS-Coordination
framework is extensible and can be utilized by different coordination types, including
custom variations. However, the two coordination types most commonly associated
with WS-Coordination are WS-AtomicTransaction and WS-BusinessActivity. (Concepts
relating to these specifications are explained in the upcoming Atomic transactions
and Business activities sections.)
Coordination type extensions provide a set of coordination protocols, which
represent unique variations of coordination types and consist of a collection of
specific behaviors and rules. A protocol is best viewed as a set of rules that are
imposed on activities and which all registered participants must follow.

15
A context created by the activation service is referred to as a coordination context. It
contains a collection of information that represents the activity and various
supplementary data.
Examples of the type of data held within a coordination context include:
a unique identifier that represents the activity
an expiration value
coordination type information

16
A service that wants to take part in an activity managed by WS-Coordination must
request the coordination context from the activation service. It then can use this
context information to register for one or more coordination protocols. A service
that has received a context and has completed registration is considered a
participant in the coordinated activity.

17
The coordination service composition is instantiated when an application service
contacts the activation service (Figure 6.16). Via a CreateCoordinationContext
request message, it asks the activation service to generate a set of new context data.
Once passed back with the ReturnContext message, the application service now can
invite other services to participate in the coordination. This invitation consists of the
context information the application service originally received from the activation
service.
Any Web service in possession of this context information may issue a registration
request to the registration service. This allows the service to enlist in a coordination
based on a specific protocol. (Protocols are provided by separate specifications and
are discussed later in this chapter as part of the Atomic transaction and Business
activities sections.) Upon a successful registration, a service is officially a participant.
The registration service passes the service the location of the coordinator service,
with which all participants are required to interact. At this time, the coordination
service is also sent the address of the new participant.
Figure 6.16. The WS-Coordination registration process.

18
The application service can request that a coordination be completed by issuing a
completion request message to the coordination service. The coordinator, in turn,
then issues its own completion request messages to all coordination participants.
Each participant service responds with a completion acknowledgement message
(Figure 6.17).
Figure 6.17. The WS-Coordination completion process.

19
A coordinator-based context management framework, as provided by WS-
Coordination and its supporting coordination types, introduces a layer of composition
control to SOAs (Figure 6.18). It standardizes the management and interchange of
context information within a variety of key business protocols.
Coordination also alleviates the need for services to retain state. Statelessness is a
key service-orientation principle applied to services for use within SOAs.
Coordination reinforces this quality by assuming responsibility for the management
of context information.
Figure 6.18. Coordination as it relates to other parts of SOA.

20
In the previous case study example, we established the individual process steps that
comprised a complex activity. Once the processing of this activity enters the TLS
environment, TLS employs a context management system to coordinate the flow of
the message through its internal services.
As shown in Figure 6.19, coordination is applied to the following steps:
[Link] Accounts Payable Service uses the Vendor Profile Service to validate the
invoice header data. If the data is valid, the invoice document is attached to the
vendor account.
[Link] Accounts Payable Service extracts taxes and shipping fees from the invoice
document. These values, along with the invoice total, are submitted to the Ledger
Service. The Ledger Service is responsible for updating the General Ledger and
numerous sub-ledgers, such as the Accounts Payable Ledger.
The atomic transaction coordination type is used to coordinate these processing
steps, as explained in the next two case studies.
Figure 6.19. The TLS Accounts Payable, Vendor Profile, and Ledger Services being
managed by a coordination.

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

22
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:
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.
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.
Isolated: If multiple transactions occur concurrently, they may not interfere with
each other. Each transaction must be guaranteed an isolated execution environment.
Durable: Upon the completion of a successful transaction, changes made as a result
of the transaction can survive subsequent failures.

23
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:
A Completion protocol, which is typically used to initiate the commit or abort states
of the transaction.
The Durable 2PC protocol for which services representing permanent data
repositories should register.
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.

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

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

26
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.23. The transaction participants voting on the outcome of the atomic
transaction.

28
Figure 6.24. The coordinator aborting the transaction and notifying participants to
rollback all changes.
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).

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

30
Figure 6.26. All changes made by the TLS Accounts Payable, Vendor Profile, and
Ledger Services are under the control of an atomic transaction.
Continuing with our previous case study example, a look under the hood reveals that
TLS actually wraps Steps 3 and 4 into an atomic transaction. This guarantees that
should any one update fail by any of the services involved in this composition, all
previous updates performed (as of Step 3) will be rolled back (Figure 6.26).
To accomplish this, TLS relies on WS-Coordination, as implemented by the WS-
AtomicTransaction coordination type. It utilizes the context coordinator along with
the Complete transaction protocol to incorporate ACID-type transaction features into
this complex activity.

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

32
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).

33
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.
The BusinessAgreementWithParticipantCompletion protocol, which allows a
participant to determine when it has completed its part in the business activity.
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.

34
When its protocols are used, the WS-Coordination controller service assumes a role
specific to the coordination type in 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.

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

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

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

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

39
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.
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.)

40
The TLS Purchase Order Submission Process (illustrated in Figure 6.31) involves the
TLS Purchase Order Service acting as the initial sender, responsible for transmitting a
SOAP message containing PO details to the RailCo Order Fulfillment Service (Step 2).
Further complicating this process is the fact that purchase orders for amounts
exceeding $100,000 require a separate approval step by a TLS manager (Step 1).
Vendors are given a period of 48 hours during which they are expected to check for
the availability of the requested inventory and respond with either an
acknowledgement message indicating that the order will be shipped or a message
explaining that an order cannot be filled (or only partially filled), along with any
relevant back-order information (Step 3).
Even though the PO Submission Process also can be classified as a complex activity, it
is different from our previous case study example, as follows:
It can take a long time for this activity to complete.
It includes a manual review step (which can result in an approval or a rejection of the
purchase order request).
To best manage this complex activity, TLS has used the same WS-Coordination
context management framework applied in the previous case study example, only
this time the WS-BusinessActivity coordination type is chosen instead.
Figure 6.31. The TLS Purchase Order Submission Process wrapped in a long-running
business activity and spanning two organizations (two participants).

41