1
TQoS: Transactional and QoS-aware selection
algorithm for automatic Web serv ice composition
Joyce El Haddad, Maude Man ouvrier, and Marta Rukoz
Abstract—Web Services are the most famous implementation of service or iented architectures that has brought some challenging
research issues. One of these is the composition, i.e. the capability to recursively construct a composite Web service as a workflow
of other existing Web services, which are developed by different organizations and offer diverse functionalities (e.g. ticket purchase,
payment), transactional properties (e.g. compensatable or not) and Q u a lity o f Service (Qo S) values (e.g. execution price, success
rate). The selection of a Web service, for each activity of the workflow, meeting the user’s requirements, is still an important
challenge. Indeed, the selection of one Web service among a set of them that fulfill some functionalities is a critical task, generally
depending on a combined evaluation of QoS. However, the conventional QoS-aware composition approaches do not consider the
transactional constraints during the composition process. This paper addresses the issue of selecting and composing Web services
not only according to their functional requirements but also to their transactional properties and QoS characteristics. We propo se a
selection algorithm that satisfies user’s preferences, expressed as weights over QoS criteria and as risk levels defining semantically
the transactional requirements. Proofs and experimental results are presented.
Index Terms—Web Service Selection, Automatic Composition, Transactional Web Service, Local Optimization of Quality of Service,
Workflow Patterns.
✦
1INTRODUCTION
W
EB Services (WSs) are the most famous implemen-
tation of service oriented architectures allowing
the construction and the sharing of independent and
autonomous softwa res. Web service composition consists
in combining Web services, developed by different or-
ganizations and offering diverse functional (e.g. ticket
purchase, payment), behavioral (e.g. compensatable or
not) and non-functional properties (i.e. Qua lity of Service
values – e.g. exe cution price, success rate ), to offer more
complex services.
The Web service composition can be view as a three-
steps process: (1) composite Web service specification,
(2) selection of the component Web services and (3)
execution of the composite Web services. At the first
step, the user submits the goal he/she wants the com-
posite service achieves, along with some constraints and
preferences that need to be satisfied [1]. Workflows c an
be used to model the composite Web service specifica-
tion. During the second step, component Web service s
fulfilling the user’s goal are sele cted among a set of
available services. This WS se lection could be done by
hand (in this case , steps specification and selection are
integrated) or could be automatically decid ed by the
• Joyce El Haddad, Maude Manouvrier and Marta Rukoz are with the
LAMSADE, Paris-Dauphine University, Place du Mar´echal de Lattre de
Tassigny 75775 Paris Cedex 16 - France.
E-mail: elhaddad@lamsade.dauphine.fr,manouvrier@lamsade.dauphine.fr,
Marta.Rukoz@dauphine.fr
• Maude Manouvrier and Marta Rukoz are with WISDOM, Federation of
the three database research teams, LIP6 (Paris 6 University), LAMSADE
and CEDRIC (CNAM). http://wisdom.lip6.fr/
• Marta Rukoz is with Paris Ouest Nanterre La D´efense University,
200 avenue de la R´epublique, 92100 Nanterre, France. On leave from
Universidad Central de Venezuela.
system. When component WS are selected at design
time, the third step of the composition process consists
in executing the selected component WS. At run-time,
selection and ex ecution of component WS are integrated
and the selection is described as dynamic. In this paper,
we focus on design-time WS selection and particularly
on automatic selection where the user is relieved as
much as possible from the composition process. We do
not focus on the ex ecution step neither on the recovery
or re-planning problems.
While many works have been done for Web se rvice
selection, designing a composite Web service to ensure
not only correct and reliable exec ution but also optimal
Quality of Service (QoS) remains an important challenge
[2]. Indeed, WSs composition based on transactional
properties e nsures a reliable exec ution however an opti-
mal QoS composite Web service is not guaranteed. More-
over, composing optimal QoS Web services does not
guarantee a reliable execution of the resulting composite
Web service. Thus, QoS-aware and transactional-aware
should be integrated. Howeve r, the problem is ge nerally
addressed from the QoS side or from the transactional
side separately. The conventional QoS-aware composi-
tion approaches [3], [4], [5], [6], [7] do not consider the
transactional constraints dur ing the composition process,
likewise transactional-aware ones [ 8], [9], [10], [11], [12]
do not consider QoS. As far as we know, only [2]
proposes a composition model in design-time which
captures both aspects in order to evaluate the QoS of a
composite WS with various transactional requirements.
However, the authors do not consider the automatic
selection step a nd only analyze the impa ct of the trans-
actional requirements on the QoS of the composite WS.
Our research objective is to propose a design-time
2
selection algorithm for automatic WS composition where
transactional and QoS requirements are b oth integrated
in the selection process. It is evide nt that such integration
could only be done by considering first the transactional
requirements. In fact, as we mentioned above, a local or
global optimized QoS composition may not guarantee
transactional execution. If the selection is done in two
separate steps (transactional selection followed by a
QoS one), it is nece ssary to consider all the transac-
tional combinations satisfying the global transactional
requirements, which is a combinatorial problem. For
all these reasons, we embedded the QoS-aware service
selection with the tr ansactional-aware service selection,
using local QoS optimization in order to reduce the set
of possible transactional solutions.
Our contribution is a Web servic e selection algorithm
which guarantees that each selected component WS of
a composite one is loca lly the best QoS WS among
all the WS f ulfilling the global transaction requirement.
Moreover, our algorithm is scalable because the user has
only to define a global tr ansaction requirement and does
not have to define the possible termination states of all
component WS, as done for e xample in [8], [11], [13],
because the complexity of such a process increases with
the number of component WS.
This paper extends our previous work presented in
[14], where the composition was limited to elementary
(non composite) WS. In this pa p er, we extend our design-
time selection algorithm to any component WS (ele-
mentary or composite). Moreover, it contains a formal
analysis of our algorithm and a more extended state of
the ar t study.
The paper is organized as follows. Section 2 presents
our system architecture. Section 3 describes the behav-
ioral and non-functional properties of elementary WS.
Section 4 defines the properties of composite Web ser-
vices. Our approach is presented in Section 5. Exper-
imental results are shown in Section 6. A discussion
about related work is done in Section 7. Finally, Section
8 c onclude s and gives perspectives.
2S
YSTEM ARCHITECTURE
Fig. 1. Architecture of our system
Our system, represented in Figure 1, takes two inputs:
a workflow and the user’s preferences. The workflow de-
fines the execution order of a set of n a ctivities, each
one being performed b y a WS. It represents the skeleton
of an application in terms of activities and temporal
dependencies betwee n them. The user’s preferences are
expressed as weights over QoS criteria and as risk le v els.
They define semantically the transactional requirements
of the resulting Composite Web service (CWS), which
corresponds to the assignation of one component WS to
each activity of the workflow. In this paper, for the sake
of simplicity, we consider that one WS e xecutes only one
activity.
Based on the input workflow, the Composition Manager
contacts the Web services registry to search for candidate
component WS for each activity of the workflow, accord-
ing to the user’s preferences. The Web Service Registry
provides the means for registering and discovering WS,
and managing associated metadata and artifacts securely
and reliably. The metadata describe the functional, be-
havioral and non-functional properties of a WS. Based on
the candidate WS retrieved, the Planner Engine generates
an execution plan, i.e. an assignment of a component WS
to each activitie s of the input workflow. Based on the
execution plan, the Execution Engine then orchestrates the
component WS to execute the instance of the composite
WS, which enf orces the transactional requirements and
the QoS criteria d efined by the user.
3W
EB SERVICE DESCRIPTION
Since WS are intended to be discovered and used by
other applications, they need to be described and un-
derstood in terms of functional capabilities as well as
behavioral properties and non-functional properties. In
this paper, we only discuss the last two types of prop-
erties. Section 3.1 defines the behavioral properties of a
WS. Section 3.2 presents the QoS properties we consider
for a WS in the paper.
3.1 Web Service behavioral properties
The behavioral description of a WS is regarding how
the functionality of a WS can be achieved in terms of
interaction with the other WS. In a composition where
several component WS inter act, unexpected behavior
from a component WS might, not only lead to its failure,
but also may bring negative impact on all the partic-
ipants of the composition. Therefore, as for all cross-
organizational collaborative systems, the execution of
a CWS requires Transactional Properties (TP) so that
the overall consistency is ensured. We consider three
behavioral properties of WS, pivot (p), compensatable (c)
and retriable (r). Inspired by [15], we have the following
definitions:
Definition 1 (Pivot WS): A WS is said to be pivot (p) if
once it successfully completes, its effects remains forever
and cannot be semantically undone. If it fails it has no
effect at all. A completed pivot WS cannot be rolled back.
Definition 2 (Compensatable WS): A WS s is c ompensa-
table (c) if it exists another WS s
!
which can semantically
undo the execution of s.
3
Definition 3 (Retriable WS): A WS is retriable (r) if it
guarantees a successfully termination a fter a finite num-
ber of invocations.
A WS can combine behavioral properties, then the set
of a ll possible combinations for a WS is { p, c, pr, cr}.
3.2 Web service non-fun ctional properties
When several functionally and transactionally equivalent
WS are available to perform the same activity, their
QoS properties such as price, availab ility, reliability and
reputation become important in the selection process. In
order to reason about QoS properties in WS, a model is
needed to capture the descriptions of these properties
from a user perspective. Such model must take into
account the fact that QoS involves multiple dimensions.
In this paper, we consider the following five generic
quality criteria for a WS s:
1) Execution price (q
ep
(s)): which is the fee that a
requester has to pay for invoking s.
2) Execution duration (q
ed
(s)): that measures the ex-
pected delay time betwee n the moment when s is
invoked and when the results are received.
3) Reputation (q
r
(s)): which is a measure of trustwor-
thiness of s. Generally this measure is defined as
the average ranking given to the se rvice by end
users.
4) Successful execution rate (q
sr
(s)): which is the
probability that s responds correctly to the user
request.
5) Availability (q
a
(s)): which is the probability that s
is accessible.
Properties 1, 2, 4 and 5 can be dynamically updated
by the system.
The following section defines a CWS whose compo-
nents have the five properties defined above.
4COMPOSITE WEB SERVICE DESCRIPTION
A CWS is a conglomeration of existing WS interacting
together to offer a new value-added service. It coordi-
nates a set of WS as a cohesive unit of work to achieve
common goals. Section 4.1 presents how to specify a
CWS. Sections 4.2 a nd 4.3 present the CWS behavioral
and non-functional properties.
4.1 Composite Web Service specification
Currently, several process modeling languages including
YAWL [16] and BPEL [17] have been proposed to cap ture
the logic of a CWS. In this pape r, we choose YAWL
to represent the workflows model and to describe the
composition. However, any other language could ha v e
been used. In a WS environment, a workflow represents
a composition of WS. When each activity of a work-
flow is implemented by a component WS, we obtain
a CWS. Several C WSs can be associated to the same
workflow, depending on the assigned component WSs.
The orchestration of the component WSs is defined by
specifying dependencies between them. These depen-
dencies are defined by the associated workflow patterns
and by the transa ctional properties. The first ones specify
how WSs are coupled and how the behavior of certain
WSs influence the behavior of other one(s). While the
transactional properties specify the behavior of certain
WSs in case of failure.
Fig. 2. Symbols used in YAWL
Fig. 3. Workflow patterns
In this paper, for the sake of simplicity, we restrain
the temporal dependencies between activities to the
following workflow patterns: sequence, parallel split
(AND-split), exclusive choice (XOR-split), synchroniza-
tion (AND-join) and simple merge (XOR-join), presented
in Figure 2. Figure 3.(a) represents a sequential pattern
between two activities A
1
and A
2
. Using this pattern,
when a service WS
1
is assigned to activity A
1
and a
service WS
2
is assigned to activity A
2
, the obtained
composite Web service CW S
1
is represented in text
by (WS
1
; WS
2
) where symbol ; represents a sequential
execution: WS
1
is executed before WS
2
. Figure 3.(b)
represents the AND-split and AND-join patter ns. In
this case, when a service WS
1
is assigned to activity
A
1
and a service WS
2
is assigned to activity A
2
, the
resulting composite Web service CW S
2
is represented
in text by (WS
1
//W S
2
), meaning that both services are
executed in parallel. For a XOR-pattern ( see Figure3.(c)),
the obtained CW S
3
corresponds to one of its component.
Then, when a service WS
1
is assigned to activity A
1
and
a service WS
2
is assigned to activity A
2
, the obtained
CWS is represented in text by (WS
1
| WS
2
), meaning
that either service WS
1
either service WS
2
is executed.
For more details, not needed to understand the rest of
this paper, readers are referred to [18] for a uniform
approach to describe workflow characteristics and to
[3] for a description of relevant patterns for the WS
composition.
A workflow pattern can be composed by other work-
flows patterns. In this way, we can represent a CWS by
the composition of other CWS, or by the composition
of CWS with elementary WS. In the following sections,
when it is not specified, WS represents an elementary
WS or a CWS.
The next section describe s the CWS behavioral (i.e.
transactional) and QoS (i.e. non-functional) properties.
4
TABLE 1
Aggregation functions for QoS criteria
Criteria Aggregation function
Price q
ep
(CW S)=
!
n
i=1
q
ep
(s
i
)
Duration q
ed
(CW S)=
!
n
i=1
q
ed
(s
i
)
Reputation q
r
(CW S)=
1
n
!
n
i=1
q
r
(s
i
)
Success rate q
sr
(CW S)=
"
n
i=1
q
sr
(s
i
)
Availability q
a
(CW S)=
"
n
i=1
q
a
(s
i
)
4.2 Composite Web Service behavioral p roperties
CWS are ofte n long-running, loosely coupled and cross-
organizational applications. In this context, we are inter-
ested in transactional behavior of the resulting WS com-
position. The transactional properties of a CWS highly
depend on the transactional properties of its component
WSs and on the structure of the workflow. We hav e the
following definitions:
Definition 4 (Atomic CWS): A CWS is atomic if once
all its component WSs complete successfully, their effect
remains forever and cannot be semantically undone. On
the other hand, if one component WS does not complete
successfully, then all previously successful component
WSs have to be compensate d. In the following, !a is used
to indicate an atomic CWS while ˜a is used to indicate a
non-atomic one.
Definition 5 (Compensatable CWS): A CWS is compen-
satable (c) if all its component WSs are compensatable.
Definition 6 (Retriable CWS): An atomic or a compen-
satable CWS is retriable (r) if a ll its components are
retriable.
Definition 7 (Transactional CWS): A Transactional
Composite Web Service (TCWS) is a CWS whose
transactional behavioral property is in {!a,!ar, c, cr}.
A TCWS takes advantage of component service be-
havioral properties to specify mechanisms for failure
handling and recovery. It can be composed of elementary
WSs, whose properties are in {p, pr, c, cr}, and/or can be
composed of CWSs, whose properties are in {!a,!ar, c, cr}.
In this paper, we are interested in properly assigning
component WSs (elementary or composite) in order to
obtain a TCWS. Section 5 presents the assignation pro-
cess.
4.3 Composite Web Service non-functional proper-
ties
A C WS has the same quality properties as an elementary
WS, i.e. execution price, execution dura tion, reputation,
successful execution rate, and availability. When a use r
wants to execute a CWS, it indica tes, among other things,
the quality of the wished result. This one is expressed
as weight in ea ch of the quality cr iterion. In this paper,
the QoS of a CWS is evaluated by using the aggregation
functions defined in Table 1. It is obvious, that activities
in all execution paths between AND-split a nd AND-
join are considered in the aggregation functions. While,
activities in only one execution path between XOR-split
and XOR-join constructs are considered. However, any
other QoS evaluation could be used.
5TRANSACTIONAL QOS-DRIVEN SELECTION
FOR WS COMPOSITION
In this paper, we are interested in properly selecting
component WSs in order to obtain a TCWS which maxi-
mizes the user satisfaction in terms of QoS criterion and
satisfies the transactional requirements set by the user
and by the input workflow.
As expla ined in Section 2, the input of the assigna-
tion process is a workflow, a tra nsactional requirement,
expressed in term of risk (see Section 5.1), and a set of
weights over QoS criteria. The output of the process is
a TCWS which assigned WS components maximiz e the
QoS criter ia.
The process is sequential: WSs are assigned to each
activity by analyzing the workflow from the left to the
right. In a split pattern, services a re assigned from top
to down. The transactional driven service selection is
presented in Section 5.2. The QoS-driven service selec-
tion is presented in Section 5.3. Finally, the algorithm of
our Transactional QoS-driven (TQoS) selec tion for WS
Composition is given in 5.4.
5.1 Definition of risk
In order to ex p lain the transactional WS selection pro-
cess, it is necessary to establish how the user c an exp ress
their transactional criteria. Although, expressing the QoS
criteria is significant for the user, the risk or the possi-
bility that an application will be unsuccessfully executed
has a more significant effect on the user’s decisions. The
importance of the uncertainty of application completion
and recovery is sema ntically expressed under a criterion
called risk. For example, the set {!a,!ar, c, cr} of the behav-
ioral properties of CWS can be divided into two subsets
{!a,!ar} and {c, cr}, each one can be associated with a
level of risk. For instance, in terms of the transactional
properties, we believe that p roperties !a and !ar are riskier
than c and cr. Indeed, properties !a and !ar mean that
once a service has bee n executed, it can not be rolled
back. Therefore, we define two notions of execution risk
in a transactional system like:
• Risk 0: the system guarantees tha t if the execution is
successful, the obtained results can be compensated by
the user.
• Risk 1: the system does not guarantee the successful
execution and even if the execution is successful, the
system does no t guarantee the result ca n be compensated
by the user.
In this paper, we only study the risk level 0 and 1
as defined above. However, other levels of risk could
be defined in terms of compensation of the different
components of the CWS. For example, the system can
guarantee that if the execution is successful, some results
5
can be compensated by the user or some results cannot
be compensated by the user. In this case, the transac-
tional properties must be relaxed.
In the following section, we present the WS selection
algorithm used by the composition manager for WS
composition with risk and QoS preferences.
5.2 Transactional driven service selection
This section shows the process of assigning an WS to
each activity in a workflow, in order to obta in a TCWS.
For simplicity, we supp ose a workflow containing only
two activitie s. We first c onsider the assignation of two
WSs to the activities of a sequential pattern ( see Section
5.2.1). Then, we consider the assignation of two WSs to
the activities of a parallel pattern (AND-split, see Section
5.2.2). We do not consider the XOR-pattern due to if the
workflow contains only two a ctivities in a XOR-pattern,
then the resulting ”Composite” WS contains only one
Web service WS
i
hence the WS transactional property
corresponds to the transactional property of WS
i
. Then,
we present a generalization of the transactional driven
service selection to a worklfow of n activities (see Se ction
5.2.3). A summary is presented in Section 5.2.4 and an
example is given in Section 5.2.5.
5.2.1 Sequential pattern assignation
Prop. 1: In a sequential pattern, if the WS assigned
to the first activity of the pattern is pivot (p), pivot
retriable (pr), atomic (!a), or atomic retriable (!ar) then, to
obtain a TCWS, the WS assigned to the second activity
should be pivot retriable (pr), atomic retriable (!ar), or
compensatable retria b le (cr). The Transactional Property
(TP) of the resulting TCWS is atomic (!a) and is moreover
atomic retriable (!ar) if all its components are retriable.
Proof: If the WS assigned to the first ac tivity of the
pattern is p, pr, !a, or !ar then by de finition (see def. 1
and 4), its effects cannot be semantically undone, thus
the execution of the second WS should guarantee a suc-
cessfully termination. The only condition to guarantee
a successfully termination is the retriable property (see
def. 3 and 6). Therefore, the WS assigned to the second
activity should be pr, !ar, or cr.
Prop. 2: In a sequential pattern, if the WS a ssigned to
the first activity of the pattern is compensatable (c) or
compensatable retriable (cr), then the resulting CWS is
always transactional (T CW S) whatever the TP of the
WS assigned to the second activity is. The TP of the
resulting TCWS is atomic (!a) if the WS assigned to the
second activity is either pivot (p), pivot retriable (pr ),
atomic (!a), or atomic retriable (!ar). The T CW S TP is
compensatable (c) if the WS assigned to the second
activity is either compensatable (c) or compensatab le
retriable (cr). Moreover, when both component WSs are
retriable, the resulting TCWS is retriable.
Proof: When service WS
1
assigned to the first ac -
tivity of the pattern is c or cr, the resulting CWS is
at least !a ( see def. 4) because if the WS assigned to
the second activity fails, then WS
1
can be compensated.
Moreover, the resulting CWS is c (see def. 5) when the
WS assigned to the second activity is c or cr, because all
the components of the resulting CWS are c.
5.2.2 Parallel pattern assignation
Prop. 3: If a pivot (p ) or an atomic (!a) WS is assigned
to one activity of a parallel pattern, then the WS assigned
to the other activity should be compensatable retriable
(cr) to obtain a TCWS. The tr ansactional property of the
resulting TCWS is atomic (!a).
Proof: If a p or !a Web service WS
1
is assigned to
one activity of a parallel p attern and if it successfully
completes, then by definition (see def. 1 and 4) its effects
cannot be semantically undone. Therefore, the execution
of the other WS should gua rantee a successfully termina-
tion in case of WS
1
successfully termination and should
be able to be compensated in case of WS
1
failure. By def-
inition (see def. 3 and 6), the only condition to guarantee
a successfully termination which can be compensated is
property cr. Consequently, the WS assigned to the other
activity of the pattern should be cr.
Prop. 4: If a pivot retriable (pr) or an atomic retriable
(!ar) WS is assigned to one activity of a parallel pattern,
then the WS assigned to the other activity should b e
pivot retriable (pr), atomic retriable (!ar), or compen-
satable retriable (cr) in order to obtain a TC WS. The
transactional property of the resulting TCWS is atomic
retriable (!ar).
Proof: If a pr or an !ar service WS
1
is assigned to
one activity of a parallel p attern, then, by definition (see
def. 3 and 6), it guarantees a successfully termination,
but it cannot be compensated. Thus, the WS assigned
to other activity cannot fail. So to obtain a TCWS, the
only solution is to assign a pr, cr, or !ar WS to the other
activity of the pattern.
Prop. 5: If a compensatab le (c) WS is assigned to one
activity of a parallel pattern, then the WS assigned
to the other activity should be compensatable (c) or
compensatable retriable (cr ) in order to obtain a TC WS.
The transactional property of the resulting TCWS is
compensatable (c).
Proof: If a c service WS
1
is assigned to one activity
of a parallel pattern and if it successfully complete,
then, by definition (see def. 2 and 5), its effects can be
semantically undone. But it can fail. Therefore, to obtain
a TCWS the WS assigned to the other activity of the
pattern should be at least c (and possibly cr) in order to
be able to be compensated.
Prop. 6: If a compensatable retriable (cr) WS is as-
signed to one activity of a p arallel pattern, then the
resulting CWS is transac tional (T CW S) independently
of the WS transactional p roperty assigned to the other ac-
tivity. The transactional property of the resulting TCWS
is respectively atomic (!a), compensata b le (c), atomic re-
triable (!ar), or compensatable retriable (cr), if the WS as-
signed to the other activity is respectively pivot/atomic
