Ensuring Required Failure Atomicity of Composite Web
Services
Sami Bhiri
LORIA-INRIA
BP 239, F-54506
Vandoeuvre-les-Nancy Cedex,
France
bhiri@loria.fr
Olivier Perrin
LORIA-INRIA
BP 239, F-54506
Vandoeuvre-les-Nancy Cedex,
France
operrin@loria.fr
Claude Godart
LORIA-INRIA
BP 239, F-54506
Vandoeuvre-les-Nancy Cedex,
France
godart@loria.fr
ABSTRACT
The recent evolution of Internet, driven by the Web services
technology, is extending the role of the Web from a support
of information interaction to a middleware for B2B interac-
tions.
Indeed, the Web services technology allows enterprises to
outsource parts of their business processes using Web ser-
vices. And it also provides the opportunity to dynamically
offer new value-added services through the composition of
pre-existing Web services.
In spite of the growing interest in Web services, current
technologies are found lacking efficient transactional support
for composite Web services (CSs).
In this paper, we propose a transactional approach to en-
sure the failure atomicity, of a CS, required by partners. We
use the Accepted Termination States (ATS) property as a
mean to express the required failure atomicity.
Partners specify their CS, mainly its control flow, and the
required ATS. Then, we use a set of transactional rules to
assist designers to compose a valid CS with regards to the
specified ATS.
Categories and Subject Descriptors
H.3.5 [Information Storage and Retrieval]: Online In-
formation Services—Web-based services; H.2.4 [Database
Management]: Systems—Transaction Processing; K.4.4
[Computers and Society]: Electronic Commerce—Dis-
tributed commercial transactions
General Terms
Design, Reliability
Keywords
Reliable Web services compositions, Failure atomicity, Trans-
actional models
1. INTRODUCTION
Web services are emerging as a promising technology for
automating B2B interactions. Nowadays, enterprises are
Copyright is held by the International World Wide Web Conference Com-
mittee (IW3C2). Distribution of these papers is limited to classroom use,
and personal use by others.
WWW2005, May 10–15, 2005, Chiba, Japan.
ACM 1-59593-046-9/05/0005.
able to outsource their internal business processes as ser-
vices and make them accessible via the Web. Then they
can dynamically combine individual services to provide new
value-added services.
A main problem that remains is how to ensure a correct
composition and a reliable execution of a composite service
(CS) with regards to partners transactional requirements.
Despite growing interest, Web services middleware is still
rather primitive in terms of functionality, far from what cur-
rent EAI middleware can provide for intra-enterprise appli-
cations [2].
The current Web services technologies ensure communi-
cation interoperability which is a part of the problem when
considering the building of reliable Web services composi-
tions [16]. Indeed, unlike activities in traditional workflows,
services are defined independently of any computing context.
Thereafter, the task of building composite Web services re-
quires mechanisms to deal with the inherent autonomy, and
heterogeneity of Web services.
Although powerful, Advanced Transaction Models (ATMs)
[6] are found lacking functionality and performance when
used for applications that involve dynamic composition of
heterogenous services in a peer-to-peer context.
Their limitations come mainly from their inflexibility to
incorporate different transactional semantics as well as dif-
ferent interactions patterns into the same structured trans-
action [8].
In this paper, we propose a transactional approach for
reliable Web services compositions by ensuring the failure
atomicity required by the designers.
From a transactional point of view, we consider a CS as
a structured transaction, Web services as sub transactions
and interactions as inter sub transactions dependencies. We
use the Accepted Termination States (ATS) property as a
correctness criteria to relax atomicity.
To the best of our knowledge, defining a transaction with a
particular set of properties, in particulary ATS, and ensuring
that every execution will preserve these properties remains
a difficult and open problem [18].
The paper is organized as follows. Section 2 introduces
a motivating example and gives the main points which has
driven our approach. In section 3, we explain the notion of
transactional web service and show how we express its trans-
actional properties. Section 4 presents the notion of Trans-
actional Composite (Web) Service (TCS) and explains our
transactional point of view. Section 5 presents the notion
138
of Accepted Termination States (ATS) as a mean to express
the required failure atomicity. Section 6 illustrates how our
approach proceeds (using a set of transactional rules) to
assist designers to compose valid TCSs. In section 7, we
discuss some related work. Section 8 concludes our paper.
2. MOTIVATING EXAMPLE AND
METHODOLOGY
Let us first present a motivating example. We consider
an application dedicated to the online purchase of personal
computer. This application is carried out by a composite
service as illustrated in figure 1. Services involved in this
application are: the Customer Requirements Specifi-
cation (CRS) service used to receive the customer order
and to review the customer requirements, the Order Items
(OI) service used to order the computer components if the
online store does not have all of it, the Payment by Credit
Card (PCC) service used to guarantee the payment by
credit card, the Computer Assembly (CA) service used
to ensure the computer assembly once the payment is done
and the required components are available, and the Deliver
Computer (DC) service used to deliver the computer to
the customer (provided either by Fedex (DC
F ed
) or TNT
(DC
T NT
)).
Figure 1: A composite service for online computer
purchase.
When a user designs a composite service, he expects the
service execution to be reliable. That means he particularly
pays attention to failure handling. In our example, the de-
signer may want to be sure: that one of the two delivery
services will succeed, that the service CA is sure to com-
plete, and that it is possible for the service OI to undo its
effects (for instance when the payment fails). These proper-
ties define what we call the transactional behavior of the ser-
vice. This behavior is specified using a set of transactional
requirements. Since these requirements may vary from one
context to another, the transactional behavior will vary too.
For instance, a designer may accept the failure of the DC
F ed
service in a context, while in another one he may not toler-
ate such a failure at such an advanced stage. So the mean
of a reliable execution is tightly related to transactional re-
quirements and it may vary according to designers.
In the same time, in order to ensure a reliable execution,
we have to be sure that a specified transactional behavior
is consistent with the set of selected services and the trans-
actional requirements. Back to our example, we can easily
notice that since the OI service is not sure to complete, the
payment service PCC have to be compensatable (and it must
be compensated when the OI service fails).
The following points introduce our approach and its con-
cepts for supporting this kind of scenarios.
First, we believe that we must enhance Web services de-
scription for a better characterization of their transactional
behavior. This can be done by enhancing WSDL interface
with transactional properties.
Second, we have to model services composition and chore-
ography, in particular mechanisms for failure handling and
recovery.
Third, we have to provide designers with a mean to ex-
press their transactional requirements, in particular their
required failure atomicity level. Finally, we have to sup-
port composite service validation with regards to designers’
requirements.
In the rest of the paper we detail each of these issues
and especially our set of transactional management rules
for composite service validation.
3. TRANSACTIONAL WEB SERVICE
DESCRIPTION
A Web service is a self-contained modular program that
can be discovered and invoked across the Internet. Web
services are typically built with XML, SOAP, WSDL and
UDDI specifications [4] [17]. A transactional Web service is
a Web service that emphasizes transactional properties for
its characterization and correct usage.
The main transactional properties of a Web service that
we are considering are retriable, compensatable and pivot
[14]. A service s is said to be retriable if it is sure to
complete after several finite activations. s is said to be
compensatable if it offers compensation policies to seman-
tically undo its effects. Then, s is said to be pivot if once
it successfully completes, its effects remains for ever and
cannot be semantically undone. Naturally, a service can
combine properties, and the set of all possible combinations
is {r; cp; p; (r, cp); (r, p)}.
In order to model the internal behavior of a service, we
have adopted a states/transitions model. A service has a
minimal set of states (initial, active, aborted, cancelled, failed
and completed), and it also includes a set of transitions (ac-
tivate(), abort(), cancel(), fail(), and complete()). The figure
2.a shows the internal states/transitions diagram of a pivot
service.
When a service is instantiated, the state of the instance is
initial. Then this instance can be either aborted or activated.
Once it is active, the instance can normally continues its
execution or it can be cancelled during its execution. In
the first case, it can achieve its objective and successfully
completes or it can fail.
The requested transactional properties can be expressed
by extending the service states and transitions. For instance,
for a compensatable service, a new state compensated and a
new transition compensate() are introduced (e.g., service in
figure 2.b). Figure 2 illustrates the states/transitions dia-
gram of a retriable service (figure 2.c) and states/transitions
diagrams of services combining different transactional prop-
erties (figures 2.d and 2.e).
Within a transactional service, we also distinguish be-
tween external and internal transitions.
External transitions are fired by external entities. Typi-
cally they allow a service to interact with the outside and to
specify composite services choreographies (see next section).
The external transitions we are considering are activate(),
abort(), cancel(), and compensate().
Internal transitions are fired by the service itself (the ser-
139
Figure 2: Services states/transitions diagrams according to different transactional properties.
vice agent). Internal transitions we are considering are com-
plete(), fail(), and retry().
4. COMPOSITION OF TRANSACTIONAL
WEB SERVICES
A composite Web service is a conglomeration of existing
Web services working in tandem to offer a new value-added
service [13]. It coordinates a set of services as a cohesive
unit of work to achieve common goals.
A Transactional Composite (Web) Service (TCS) empha-
sizes transactional properties for composition and synchro-
nization of component Web services. It takes advantage of
services transactional properties to specify mechanisms for
failure handling and recovery.
4.1 Dependencies between services
A TCS defines services orchestration by specifying depen-
dencies between services. They specify how services are cou-
pled and how the behavior of certain service(s) influence the
behavior of other service(s).
Definition 4.1 (Dependency from s
1
to s
2
). A
dependency from s
1
to s
2
exists if a transition of s
1
can
fire an external transition of s
2
.
A dependency defines for each external transition of a
service a precondition to be enforced before this transition
can be fired.
In our approach, we consider the following dependencies
between services:
Activation dependency from s
1
to s
2
: There is an
activation dependency from s
1
to s
2
if the completion of s
1
can fire the activation of s
2
.
We can tailor activation dependencies between services by
specifying the activation condition, ActCond(s), of each ser-
vice s. ActCond(s) defines the precondition to be enforced
before the service s can be activated (only after the comple-
tion of other service(s)). There is an activation dependency
from s
1
to s
2
iff s
1
.completed ∈ ActCond(s
2
). Reciprocally
for each service s
1
∈ ActCond(s
2
), there is an activation de-
pendency from s
1
to s
2
according to ActCond(s
2
).
For example, the composite services defined in figure 3
define an activation dependency from OI and P CC, to CA
such that CA will be activated after the completion of OI
and P CC. That means ActCond(CA) = OI.completed
V
P CC.completed.
Alternative dependency from s
1
to s
2
: There is an
alternative dependency from s
1
to s
2
if the failure of s
1
can
fire the activation of s
2
.
We can tailor alternative dependencies between services
by specifying the alternative condition, AltCond(s), of each
service s. AltCond(s) defines the precondition to be en-
forced before the service s can be activated as an alterna-
tive of other service(s). There is an alternative dependency
from s
1
to s
2
iff s
1
.failed ∈ AltCond(s). Reciprocally
for each service s
1
∈ AltCond(s
2
), there is an alternative
dependency from s
1
to s
2
according to AltCond(s
2
)
For instance the composite service cs
1
in figure 3.b defines
an alternative dependency from DC
F ed
to DC
T NT
such that
DC
T NT
will be activated when DC
F ed
fails. That means
AltCond(DC
T NT
) = DC
F ed
.failed.
Abortion dependency from s
1
to s
2
: There is an abor-
tion dependency from s
1
to s
2
if the failure, cancellation or
the abortion of s
1
can fire the abortion of s
2
.
We can tailor abortion dependencies between services by
specifying the abortion condition, AbtCond(s), of each ser-
vice s. AbtCond(s) defines the precondition to be enforced
before the service s can be aborted. There is an abortion
dependency from s
1
to s
2
iff s
1
.aborted ∈ AbtCond(s
2
))
W
s
1
.failed ∈ AbtCond(s
2
)
W
s
1
.cancelled ∈ AbtCond(s
2
).
Reciprocally for each service s
1
∈ AbtCond(s
2
), there is an
abortion dependency from s
1
to s
2
according to AbtCond(s
2
).
Compensation dependency from s
1
to s
2
: There is
140
Figure 3: Two composite services defined according to the same skeleton.
a compensation dependency from s
1
to s
2
if the the failure
or the compensation of s
1
can fire the compensation of s
2
.
We can tailor compensation dependencies between ser-
vices by specifying the compensation condition, CpsCond(s),
of each service s. CpsCond(s) defines the precondition to
be enforced before the service s can be compensated. There
is a compensation dependency from s
1
to s
2
iff s
1
.failed ∈
CpsCond(s
2
)
W
s
1
.compensated ∈ CpsCond(s
2
). Recipro-
cally for each service s
1
∈ CpsCond(S
2
), there is a compen-
sation dependency from s
1
to s
2
according to CpsCond(s
2
).
Composite services in figure 3 define a compensation de-
pendency from P CC to OI such that OI will be comp-
ensated when P CC fails. That means CpsCond(OI) =
PCC.failed.
Cancellation dependency from s
1
to s
2
: There is a
cancellation dependency from s
1
to s
2
if the failure of s
1
can
fire the cancellation of s
2
.
We can tailor cancellation dependencies between services
by specifying the cancellation condition, CnlCond(s), of
each service s. CnlCond(s) defines the precondition to be
enforced before the service s can be cancelled. There is
a cancellation dependency from s
1
to s
2
iff s
1
.failed ∈
CnlCond(s
2
).
Reciprocally for each service s
1
∈ CnlCond(s
2
), there is
a cancellation dependency from s
1
to s
2
according to
CnlCond(s
2
).
Composite services in figure 3 define a cancellation depen-
dency from PCC to OI such that OI will be cancelled when
P CC fails. That means CnlCond(OI) = P CC.failed.
For clarity reasons, we do not deal with abortion depen-
dencies. We call transactional dependencies the compensa-
tion, cancellation and alternative dependencies.
4.2 Relations between dependencies
Dependencies specification must respect some semantic
restrictions. Indeed, transactional dependencies depend on
activation dependencies according to the following relations:
R
1
: An abortion dependency from s
1
to s
2
can exist only
if there is an activation dependency from s
1
to s
2
.
R
2
: A compensation dependency from s
1
to s
2
can exist
only if there is an activation dependency from s
2
to s
1
,
or s
1
and s
2
execute in parallel and are synchronized.
R
3
: A cancellation dependency from s
1
to s
2
can exist only
if s
1
and s
2
execute in parallel and are synchronized.
R
4
: An alternative dependency from s
1
to s
2
can exist only
if s
1
and s
2
are exclusive.
Section 4.4 shows how these relations define potential de-
pendencies induced by given activation dependencies.
4.3 Control and transactional flow of a TCS
Within a transactional composite service, we distinguish
between the TCS control flow and the TCS transactional
flow.
Control flow: The control flow (or skeleton) of a TCS
specifies the partial ordering of component services activa-
tions. Activation dependencies between component services
define the corresponding TCS control flow.
We use (workflow-like) patterns to define a composite ser-
vice skeleton. As defined in [7], a pattern “is the abstrac-
tion from a concrete form which keeps recurring in specific
non arbitrary contexts”. A workflow pattern can be seen as
an abstract description of a recurrent class of interactions
based on (primitive) activation dependency. For example,
the AND-join pattern [21] (see figure 3.a) describes an ab-
stract services choreography by specifying services interac-
tions as following: a service is activated after the completion
of several other services.
Example: Figure 3.a illustrates a TCS skeleton defined
using an AND-split, an AND-join and an XOR-split pat-
terns.
141
Transactional flow: The transactional flow of a TCS
specifies mechanisms for failures handling and recovery.
Transactional dependencies (like compensation, cancellation
and alternative) define the TCS transactional flow.
4.4 Pattern’s potential dependencies
Several TCSs can be defined based on a skeleton. Each
TCS adopts the activation dependencies defined by the skele-
ton’s patterns and may extend them by specifying additional
transactional dependencies.
Example: Figure 3 shows two TCSs, cs
1
and cs
2
, de-
fined using the same skeleton. Each of these TCSs adopts
this skeleton (figure 3.a) and refines it with an additional
transactional flow.
Additional transactional dependencies are a subset of po-
tential transactional dependencies defined by the skeleton’s
patterns. Indeed, a pattern defines in addition to the default
activation dependencies, a set of potential transactional de-
pendencies.
A potential dependency is a dependency that is not ini-
tially defined by the pattern but that can be added by TCSs
using this pattern. Potential dependencies are directly re-
lated to the pattern’s activation dependencies according to
the relations we have introduced in section 4.2.
We have shown above that dependencies between services
can be tailored by specifying preconditions on services’ ex-
ternal transitions. And potential transactional dependencies
are not an exception to this fact. So a TCS skeleton defines
for each service the potential conditions corresponding to the
potential dependencies. A pattern defines for each service s
it is connected with:
• ptCpsCond(s): its potential compensation condition,
• ptAltCond(s): its potential alternative condition,
• ptCnlCond(s): its potential cancellation condition.
We can write each of these conditions in exclusive dis-
junctive normal form. For instance, we can write the po-
tential compensation condition of a service s as follows:
ptCpsCond(s) =
L
i
ptCpsCond
i
(s). Then ptCpsCond
i
(s)
is one potential compensation condition of s.
Example: The TCS skeleton illustrated in figure 3.a uses
an AND-join pattern to define activation dependencies be-
tween services OI, P CC and CA. According to the rela-
tion R
2
given in section 4.2, a TCS based on this skele-
ton can eventually specifies the following compensation de-
pendencies: from OI to P CC, from P CC to OI, from
CA to OI and from CA to P CC. Similarly, according
to the relation R
3
, this pattern defines the following po-
tential cancellation dependencies: from OI to P CC, and
from P CC to OI. That means, among other, that ptCp-
sCond(PCC)=OI.failed
L
CA.failed
L
CA.compensated
and ptCnlCond(OI)=PCC.failed.
In the same way, according to the relation R
4
, the XOR-
split pattern connecting CA, DC
F ed
and DC
T NT
defines the
following potential alternative dependencies: from DC
T NT
to DC
F ed
and from DC
F ed
to DC
T NT
.
That means that ptAltCond(DC
T NT
) =DC
F ed
.failed and
that DC
T NT
.failed = ptAltCond(DC
F ed
).
Finally, note that both TCSs cs
1
and cs
2
define their
transactional flow as a subset of the potential transactional
flow presented above. Both define compensation and can-
cellation dependencies from P CC to OI. cs
1
defines an
alternative dependency from DC
F ed
to DC
T NT
.
5. FAILUREATOMICITYREQUIREMENTS
OF A TCS
Several executions can be instantiated according to the
same TCS. The state of an instance of a TCS composed of
n services is the tuple (x
1
, x
2
, ..., x
n
), where x
i
is the state
of service s
i
at a given time. The set of termination states
of a TCS cs, ST S(cs), is the set of all possible termination
states of its instances.
Back to our motivating example limited to the three ser-
vices CRS, OI and P CC, we can have the following set of
termination states: (CRS.completed, OI.completed, PCC.co-
mpleted); (CRS.completed, OI.failed, PCC.completed);
(CRS.completed, OI.completed, PCC.failed); (CRS.compen-
sated, OI.failed, PCC.initial); (CRS.compensated, OI.initial,
PCC.failed); (CRS.compensated, OI.failed, PCC.failed).
In order to express the designer’s requirements for failure
atomicity, we use the notion of Accepted Termination States
([18]). In other word, the concept of ATS represents our
notion of correction.
Definition 5.1 (Accepted Termination States).
An accepted termination state, ats, of a composite service cs
is a state for which designers accept the termination of cs.
We define AT S the set of all Accepted Termination States
required by designers.
An execution is correct if f it leads the CS into an ac-
cepted termination state. A CS reaches an ats if (i) it
completes successfully or (ii) it fails and undoes all undesir-
able effects of partial execution in accordance with designer
failure-atomicity requirements [18].
Back to our example, a designer may choose the following
ATS: ATS(CS)={(CRS.completed, OI.completed, PCC.co-
mpleted); (CRS.compensated, OI.failed, PCC.failed)} that
means that an execution is correct when all of the services
complete, or when CRS is compensated (given the failure of
OI and P CC). Obviously, we note that a composite service
transactional behavior may vary according to the required
ATS.
6. TRANSACTIONAL RULES
To explain the rules and to illustrate how they are work-
ing, we go back to our motivating example of personal com-
puter online purchase. We suppose in addition that design-
ers specify the AT S illustrated in the figure 5 to express
their required failure atomicity.
Intuitively, the execution of a composite service can gen-
erate various termination states. A composite service is not
valid if it exists some termination states that do not belong
to the ATS specified by the designers.
Definition 6.1 (Validity according to an AT S).
A CS cs is said to be valid according to AT S iff its set of
termination states is included in AT S, written ST S(cs) ⊆
AT S.
Example: The composite service cs
1
(illustrated in figure
3.b) is valid because ST S(cs
1
) ∈ AT S. However regard-
ing the composite service cs
2
(illustrated in figure 3.c), we
142