Quality Driven Web Services Composition
Liangzhao Zeng
University of New South Wales
Sydney, Australia
zlzhao@cse.unsw.edu.au
Boualem Benatallah
University of New South Wales
Sydney, Australia
boualem@cse.unsw.edu.au
Marlon Dumas
Queensland University of
Technology
Brisbane, Australia
m.dumas@qut.edu.au
Jayant Kalagnanam
IBM T.J. Watson Research
Center
New York, USA
jayant@us.ibm.com
Quan Z. Sheng
University of New South Wales
Sydney, Australia
qsheng@cse.unsw.edu.au
ABSTRACT
The process-driven composition of Web services is emerg-
ing as a promising approach to integrate business applica-
tions within and across organizational boundaries. In this
approach, individual Web services are federated into com-
posite Web services whose business logic is expressed as a
process model. The tasks of this process model are essen-
tially invocations to functionalities offered by the underly-
ing component services. Usually, several component services
are able to execute a given task, although with different lev-
els of pricing and quality. In this paper, we advocate that
the selection of component services should be carried out
during the execution of a composite service, rather than at
design-time. In addition, this selection should consider mul-
tiple criteria (e.g., price, duration, reliability), and it should
take into account global constraints and preferences set by
the user (e.g., budget constraints). Accordingly, the pa-
per proposes a global planning approach to optimally select
component services during the execution of a composite ser-
vice. Service selection is formulated as an optimization prob-
lem which can be solved using efficient linear programming
methods. Experimental results show that this global plan-
ning approach outperforms approaches in which the com-
ponent services are selected individually for each task in a
composite service.
Categories and Subject Descriptors
H.3.5 [Information Systems]: Web-based services
General Terms
Management, Performance
Keywords
Web services, QoS, Service Composition
1. INTRODUCTION
Web services technologies are emerging as a powerful vehi-
cle for organizations that need to integrate their applications
Copyright is held by the author/owner(s).
WWW2003, May 20–24, 2003, Budapest, Hungary.
ACM 1-58113-680-3/03/0005.
within and across organizational boundaries. In particular,
the process-based composition of Web services is gaining
a considerable momentum as an approach for the effective
integration of distributed, heterogeneous, and autonomous
applications [1]. In this approach, applications are encapsu-
lated as Web services and the logic of their interactions is
expressed as a process model. This approach provides an at-
tractive alternative to hand-coding the interactions between
applications using general-purpose programming languages.
A Web service is a self-described application that uses
standard Internet technologies to interact with other Web
services. An example of a Web service is a SOAP-based in-
terface to place bids in an auction house. Once deployed,
services can be aggregated into composite services. An ex-
ample of a composite service would be a “Travel Planner”
system that aggregates multiple component services for flight
booking, travel insurance, accommodation booking, car ren-
tal, and itinerary planning, which are executed sequentially
or concurrently.
The process model underlying a composite service identi-
fies the functionalities required by the services to be com-
posed (i.e., the tasks of the composite service) and their
interactions (e.g., control-flow, data-flow, and transactional
dependencies). Component services that are able to provide
the required functionalities are then associated to the indi-
vidual tasks of the composite services and invoked during
each execution of the composite service.
The number of services providing a given functionality
may be large and constantly changing. Consequently, ap-
proaches where the development of composite services re-
quires the identification at design-time of the exact services
to be composed are inappropriate. The runtime selection
of component services during the execution of a composite
service has been put forward as an approach to address this
issue [2, 6, 11]. The idea is that component services are se-
lected by the composite service execution engine based on
a set of criteria. However, previous approaches in this area
have not identified a set of criteria (other than price and
application-specific criteria) for selecting Web services. In
addition, existing service selection approaches adopt a local
selection strategy, meaning that they assign a component
service to an individual tasks, one at a time. As a result,
these approaches are not able to handle global user con-
411
straints and preferences. For example, the overall duration
of the composite service execution should be minimized, or
a given budget constraint should be satisfied.
In this paper, we present quality-driven approach to se-
lect component services during the execution of a composite
service. The salient features of our approach are:
• A Web services quality model. We propose an exten-
sible multi-dimensional Web services quality model.
The dimensions of this model characterize non-functi-
onal properties that are inherent to Web services in
general: execution price, execution duration, reputa-
tion, reliability, and availability.
• Quality-driven service selection. In order to overcome
the limitations of local service selection outlined above,
we propose a global planning approach. In this ap-
proach, quality constraints and preferences are assigned
to composite services rather than to individual tasks
within a composite service. Service selection is then
formulated as an optimization problem and a linear
programming method is used to compute optimal ser-
vice execution plans for composite services. Experi-
mental results show that the proposed service selec-
tion strategy significantly outperforms local selection
strategies.
The rest of the paper is organized as follows. Section 2
presents the service composition model and defines some key
concepts used throughout the paper. Section 3 defines the
service quality criteria used for service selection and explains
how the values of these quality criteria can be computed for
a given service. Section 4 formulates the global service se-
lection problem and describes a linear programming method
to efficiently solve it. Section 5 presents a prototype imple-
mentation of the proposed approach, as well as a set of ex-
periments comparing the global planning approach with the
local selection approach. Finally, Section 6 discusses related
work, and Section 7 draws some conclusions.
2. WEBSERVICECOMPOSITIONMODEL
In this section, we will present some basic concepts in
Web service composition first, then give some definitions on
composite service execution planning.
2.1 Composite services and communities
A composite Web service is an umbrella structure aggre-
gating multiple other elementary and composite Web ser-
vices, which interact with each other according to a pro-
cess model. Following our previous work [2], we choose to
specify the process model of a composite service as a stat-
echart [12]. The choice of statecharts for specifying com-
posite Web services is motivated by two main reasons: (i)
statecharts have a well-defined semantics; and (ii) they of-
fer the basic flow constructs found in contemporary process
modeling languages (i.e., sequence, conditional branching,
structured loops, concurrent threads, and inter-thread syn-
chronization). The first characteristic facilitates the applica-
tion of formal manipulation techniques to statechart models,
while the second characteristic ensures that the service com-
position mechanisms developed in the context of statecharts,
can be adapted to other process modeling languages like,
for example, those that are being designed by Web services
standardization efforts (e.g., BPEL4WS, WSCI, BPML)
1
.
A statechart is made up of states and transitions. In the
proposed composition framework, the transitions of a stat-
echart are labeled with events, conditions, and assignment
operations over process variables. States can be basic or
compound. Basic states are labelled with invocations to Web
services operations. Compound states contain one or several
statecharts within them. Specifically, compound states come
in two flavors: OR and AND states. An OR-state contains
a single statechart within it whereas an AND-state contains
several statecharts (separated by dashed lines) which are in-
tended to be executed concurrently. Accordingly, OR-states
are used as a decomposition mechanism for modularity pur-
poses, while AND-states are used to express concurrency:
they encode a fork/join pair. The initial state of a state-
chart is denoted by a filled circle, while the final state is
denoted by two concentric circles: one filled and the other
unfilled.
A simplified statechart W specifying a “Travel Planner”
composite Web Service is depicted in Figure 1. In this com-
posite service, a search for attractions is performed in par-
allel with a flight and an accommodation booking. After
these searching and booking operations are completed, the
distance from the hotel to the accommodation is computed,
and either a car or a bike rental service is invoked. Note that
when two transitions stem from the same state (in this case
the state t
4
), they denote a conditional branching, and the
transitions should therefore be labelled with disjoint condi-
tions.
Legend
Initial State Final State
Transition
State And−state
AttractionSearching
FlightTicketBooking
HotelBooking
DrivingTimeCalculation
BikeRental
CarRental
PSfrag replacements
t
i
t
f
t
c
t
d
t
1
t
2
t
3
t
4
t
5
t
6
t
7
t
8
W
s1
W
s2
W
s3
W
s4
W
s5
(W
e1
)
(W
e2
)
⇐⇒
Figure 1: Statechart of a composite service “Travel
Planner”
A basic state
2
of a statechart describing a composite ser-
vice can be labelled with an invocation to either of the fol-
lowing:
• An elementary Web service, i.e., a service which does
not transparently rely on other Web services.
• A composite Web service aggregating several other ser-
vices.
• A Web service community, i.e., a collection of Web
services with a common functionality although dif-
ferent non-functional properties (e.g., with different
providers, different QoS parameters, reputation, etc.)
The concept of Web service community addresses the is-
sue of composing a large and changing collection of Web
services. Service communities provide descriptions of a de-
sired functionality (e.g., flight booking) without referring to
any actual service (e.g., Qantas flight booking Web service).
1
See http://dev2dev.bea.com/techtrack/standards.jsp
2
Also called task in remainder of this paper.
412
The set of members of a community can be fixed when the
community is created, or it can be determined through a reg-
istration mechanism, thereby allowing service providers to
join, quit, and reinstate the community at any time. When
a community receives a request to execute an operation,
this request is delegated to one of its current members. The
choice of the delegatee is done at execution time based on the
parameters of the request, the characteristics of the mem-
bers, the history of past executions, and the status of ongo-
ing executions. Sections 3 and 4 deal with the selection of
delegatees during the execution of a composite service whose
states are labelled with invocations to communities.
2.2 Execution paths and plans
In this section, we define two concepts used in the rest of
the paper: execution path and execution plan.
Definition 1 (Execution path). An execution path of a
statechart is a sequence of states [t
1
, t
2
, .. t
n
], such that t
1
is the initial state, t
n
is the final state, and for every state
t
i
(1 < i < n), the following holds:
• t
i
is a direct successor of one of the states in [t
1
,...,t
i−1
]
• t
i
is not a direct successor of any of the states in
[t
i+1
,...,t
n
]
• There is no state t
j
in [t
1
, ..., t
i−1
] such that t
j
and t
i
belong to two alternative branches of the statechart.
• If t
i
is the initial state of one of the concurrent regions
of an AND-state AST, then for every other concurrent
region C in AST, one of the initial states of C appears
in [t
1
, ..., t
i−1
, t
i+1
, ..., t
n
]. In other words, when an
AND-state is entered, all its concurrent branches are
executed.
This definition relies on the concept of direct successor of
a state. A basic state t
b
is a direct successor of another
basic state t
a
if there is a sequence of adjacent transitions
3
going from t
a
to t
b
without traversing any other basic state.
In other words, the first transition in the sequence stems
from t
a
, the last transition leads to t
b
, and all intermediate
transitions stem from and lead to either compound, initial,
or final states, but are not incident to a basic state.
It is straightforward to see that an acyclic statechart has
a finite number of execution paths. To simplify the presen-
tation, we initially assume that all the statecharts that we
deal with are acyclic. If a statechart contains cycles, a tech-
nique for “unfolding” it into an acyclic statechart needs to
be applied beforehand. The method used to unfold the cy-
cles of a statechart is to examine the logs of past executions
in order to determine the average number of times that each
cycle is taken. The states appearing between the beginning
and the end of the cycle are then cloned as many times as
the cycle is taken in average. Details about this unfolding
process are omitted for space reasons.
Under the assumption that the underlying statechart is
acyclic, it is possible to represent an execution path of this
statechart as a Directed Acyclic Graph (DAG) as follows.
3
Two transitions are adjacent if the target state of one is
the source state of the other.
Definition 2 (DAG representation of an execution path).
Given an execution path [t
1
, t
2
, .. t
n
] of a statechart ST,
the DAG representation of this execution path is a graph
obtained as follows:
• The DAG has one node for each task t
1
, t
2
, .. t
n
.
• The DAG contains an edge from task t
i
to task t
j
iff
t
j
is a direct successor of t
i
in the statechart ST.
If a statechart diagram contains conditional branchings,
it has multiple execution paths. Each execution path rep-
resents a sequence of tasks to complete a composite service
execution. Figure 2 gives an example of a statechart’s exe-
cution paths. In this example, since there is one conditional
branching after task t
4
, there are two paths, called W
e1
and
W
e2
respectively. In execution path W
e1
, task t
6
is executed
after task t
5
, while in execution path W
e2
, task t
7
is executed
after task t
5
.
Execution Path 1
Execution Path 2
PSfrag replacements
t
i
t
f
t
a1
t
a2
t
1
t
1
t
2
t
2
t
3
t
3
t
4
t
4
t
5
t
5
t
6
t
7
t
8
t
8
W
s1
W
s2
W
s3
W
s4
W
s5
(W
e1
)
(W
e2
)
⇐⇒
Figure 2: DAG representation of the execution
paths of the statechart of Figure 1.
As stated before, the basic states of a statechart describ-
ing a composite service can be labelled with invocations to
communities. If this is the case, actual Web services (i.e.,
members of communities) need to be selected during the ex-
ecution of the composite service. Hence, it is possible to
execute a path in very different ways by allocating differ-
ent Web services to the states in the path. The concept of
execution plan defined below captures the various ways of
executing a given execution path.
Definition 3 (Execution plan). A set of pairs p = {<
t
1
, s
i1
>, < t
2
, s
i2
>, . . . , < t
N
, s
iN
>} is an execution plan
of an execution path W
e
iff:
• {t
1
, t
2
, ... t
N
} is the set of tasks in W
e
.
• For each 2-tuple < t
j
, s
ij
> in p, service s
ij
is assigned
the execution of task t
j
.
413
3. WEB SERVICE QUALITY MODEL
In a Web environment, multiple Web services may provide
similar functionalities with different non-functional property
values (e.g., different prices). In the composition model pre-
sented in the previous section, such Web services will typi-
cally be grouped together in a single community. To differ-
entiate the members of a community during service selec-
tion, their non-functional properties need to be considered.
For this purpose, we adopt a Web services quality model
based on a set of quality criteria (i.e. non-functional prop-
erties) that are transversal to all Web services, for example,
their pricing and reliability. Although the adopted quality
model has a limited number of criteria (for the sake of illus-
tration), it is extensible: new criteria can be added without
fundamentally altering the service selection techniques built
on top of the model. In particular, it is possible to extend
the quality model to integrate non-functional service char-
acteristics such as those proposed in [22], or to integrate
service QoS metrics such as those proposed by [25].
In this section, we first present the quality criteria in the
context of elementary services, before turning our attention
to composite services. For each criterion, we provide a defi-
nition, indicate its granularity (i.e., whether it is defined for
an entire service or for individual service operations), and
provide rules to compute its value for a given service.
3.1 Quality Criteria for Elementary Services
We consider five generic quality criteria for elementary
services: (1) execution price, (2)execution duration, (3) rep-
utation, (4) reliability, and (5) availability.
• Execution price. Given an operation op of a service
s, the execution price q
price
(s, op) is the amount of
money that a service requester has to pay for executing
the operation op. Web service providers either directly
advertise the execution price of their operations, or
they provide means to enquire about it.
• Execution duration. Given an operation op of a ser-
vice s, the execution duration q
du
(s, op) measures the
expected delay in seconds between the moment when a
request is sent and the moment when the results are re-
ceived. The execution duration is computed using the
expression q
du
(s, op) = T
process
(s, op) + T
trans
(s, op),
meaning that the execution duration is the sum of
the processing time T
process
(s, op) and the transmis-
sion time T
trans
(s, op). Services advertise their pro-
cessing time or provide methods to enquire about it.
The transmission time is estimated based on past ex-
ecutions of the service operations, i.e., T
trans
(s, op) =
P
n
i=1
T
i
(s,op)
n
, where T
i
(s, op) is a past observation of
the transmission time, and n is the number of execu-
tion times observed in the past.
• Reliability. The reliability q
rel
(s) of a service s is
the probability that a request is correctly responded
within a the maximum expected time frame (which is
published in the Web service description). Reliabil-
ity is a technical measure related to hardware and/or
software configuration of Web services and the net-
work connections between the service requesters and
providers. The value of the reliability is computed
from historical data about past invocations using the
Table 1: Aggregation functions for computing the
QoS of execution plans
Criteria Aggregation function
Price Q
price
(p) =
P
N
i=1
q
price
(s
i
, op
i
)
Duration Q
du
(p) = CP A(q
du
(s
1
, op
1
), ..., q
du
(s
N
, op
N
))
Reputation Q
rep
(p) =
1
N
P
N
i=1
q
rep
(s
i
)
Reliability Q
rel
(p) = Π
N
i=1
(e
q
rel
(s
i
)∗z
i
)
Availability Q
av
(p) = Π
N
i=1
(e
q
av
(s
i
)∗z
i
)
expression q
rel
(s) = N
c
(s)/K, where N
c
(s) is the num-
ber of times that the service s has been successfully
delivered within the maximum expected time frame,
and and K is the total number of invocations.
• Availability. The availability q
av
(s) of a service s is
the probability that the service is accessible. The value
of the availability of a service s is computed using the
following expression q
av
(s) = T
a
(s)/θ, where T
a
is the
total amount of time (in seconds) in which service s is
available during the last θ seconds (θ is a constant set
by an administrator of the service community). The
value of θ may vary depending on a particular appli-
cation. For example, in applications where services
are more frequently accessed (e.g., stock exchange), a
small value of θ gives a more accurate approximation
for the availability of services. If the service is less fre-
quently accessed (e.g., online bookstore), using a larger
θ value is more appropriate. Here, we assume that
Web services send notifications to the system about
their running states (i.e., available, unavailable).
• Reputation. The reputation q
rep
(s) of a service s is
a measure of its trustworthiness. It mainly depends on
end user’s experiences of using the service s. Differ-
ent end users may have different opinions on the same
service. The value of the reputation is defined as the
average ranking given by to the service by end users,
i.e., q
rep
=
P
n
i=1
R
i
n
, where R
i
is the end user’s ranking
on a service’s reputation, n is the number of times the
service has been graded. Usually, the end users are
given a range to rank Web services, for example, in
Amazon.com, the range is [0, 5].
Given the above quality criteria, the quality vector of a
service s is defined as follows:
q(s) = (q
price
(s), q
du
(s), q
av
(s), q
re
(s), q
rep
(s)) (1)
Note that the method for computing the value of the qual-
ity criteria is not unique. The global planning model pre-
sented Section 4 is independent of these methods.
3.2 Quality Criteria for Composite Services
The above quality criteria are also applied to evaluate the
QoS of composite services. Table 1 provides aggregation
functions for the computation of the QoS of a composite
service CS when executed using plan p = {< t
1
, s
i1
>, <
t
2
, s
i2
>, . . . , < t
N
, s
iN
>}. A brief explanation of each
criterion’s aggregation function follows:
414
• Execution price: The execution price Q
price
(p) of an
execution plan p is a sum of every service s
i
’s execution
price q
price
(s
i
, op
i
).
• Execution duration: The execution duration Q
du
(p)
of an execution plan p is computed using the Critical
Path Algorithm (CPA) [23]. Specifically, the CPA is
applied to the the execution path of execution plan
p, seen as a project digraph. The critical path of a
project digraph is a path from the initial state to the
final state which has the longest total sum of weights
labelling its nodes. In the case at hand, the weights
labelling the nodes correspond to the maximum ex-
pected execution durations. A task that belongs to
the critical path is a critical task, while a service that
belongs to the critical path is a critical service.
Figure 3 provides an example of critical path. In this
example, the project digraph represents execution path
W
e1
and its execution plan p, where p={ < t
2
, s
23
>,
< t
3
, s
38
>, < t
4
, s
45
>, < t
5
, s
59
>, < t
6
, s
62
> }.
Each task’s execution duration is given in the project
digraph. There are two project paths in this project
digraph, where project path 1 is < t
2
, t
5
, t
6
> and
project path 2 is < t
3
, t
4
, t
5
, t
7
>. The total execution
time of project path 1 (project path 2) is 37 seconds
(62 seconds). Since project path 2’s total execution du-
ration is longer than that of project path 1, the critical
path for the project digraph is project path 2. Thus,
the execution plan’s total execution duration is 62 sec-
onds. Task t
3
, t
4
, t
5
and t
7
are critical tasks. Services
s
38
, s
45
, s
59
and s
62
are critical services.
Legend: critical path of project digraph critical task critical service
s23, 20 Seconds
s38, 25 Seconds
s45, 20 Second
s59, 2 Second
s62, 15 Seconds
PSfrag replacements
t
a1
t
a2
t
i
t
f
t
1
t
2
t
3
t
4
t
5
t
6
t
8
s
13
s
28
s
35
s
49
s
52
W
s1
W
s2
W
s3
W
s4
W
s5
(W
e1
)
(W
e2
)
⇐⇒
Figure 3: Critical Path
• Reputation: The reputation Q
rep
(p) of an execution
plan p is the average of each service s
i
’s reputation
q
rep
(s
i
) in the execution plan p.
• Reliability: Reliability Q
rel
(p) of an execution plan p
is a product of e
q
rel
(s
i
)∗z
i
. In the aggregation function,
z
i
is equal to 1 if service s
i
is a critical service in the
execution plan p, or 0 otherwise. If z
i
= 0, i.e., service
s
i
is not a critical service, then e
q
rel
(s
i
)∗z
i
= 1, and
hence, the reliability of service s
i
will not affect the
value of execution plan’s reliability.
• Availability: The availability Q
av
(p) of an execution
plan p is a product of e
q
av
(s
i
)∗z
i
, where q
av
(s
i
) is ser-
vice s
i
’s availability.
Using above aggregation functions, the quality vector of
a composite service’s execution plan is defined as:
Q(p) = (Q
price
(p), Q
du
(p), Q
av
(p), Q
re
(p), Q
rep
(p)) (2)
4. GLOBAL SERVICE SELECTION
As mentioned before, in existing approaches, the selec-
tion of component service to execute a task is determined
independently to other tasks of composite services [2, 11, 6].
More precisely, in our previous work [2], service selection
is done at each service community locally. The selection of
a service is based on a selection policy involving parame-
ters of the request, the characteristics of the members, the
history of past executions, and the status of ongoing execu-
tions. Although service selection can be locally optimized,
the global quality constraints may not be satisfied. For ex-
ample, a global constraint such as composite services’ exe-
cution price is less than 500 dollars can not be enforced. In
this section, we present a global planning based approach
for Web services selection. We first present an approach of
selecting an optimal execution plan for a composite service,
then present a novel linear programming based method for
optimal execution plan selection.
4.1 Selecting an Optimal Execution Plan
The basic idea of global planning is the same as query op-
timization in database management systems. Several plans
are identified and the optimal plan is selected. The fore-
going discussion makes it clear that a statechart has mul-
tiple execution paths and each execution path has its own
set of execution plans if the statechart contains conditional
branchings. In this subsection, we assume that the state-
chart does not contain any conditional branchings and has
only one execution path. We will discuss the case where a
statechart has multiple execution paths in Section 4.2.
We also assume that for each task t
j
, there is a set of
candidate Web services S
j
that are available to which task
t
j
can be assigned. Associated with each Web service s
ij
is a quality vector (see equation 1). Based on the available
Web services, by selecting a Web service for each task in
an execution path, the global planner will generate a set of
execution plans P :
P = {p
1
, p
2
, ..., p
n
} (3)
n is the number of execution plans. After a set of execution
plans is generated, the system needs to select an optimal
execution plan. When selecting the execution plan, instead
of computing the quality vector of a particular Web service,
each execution plan’s global service quality vector needs to
be computed.
The selection of execution plan uses Multiple Attribute
Decision Making (MADM)[16] approach. Once the quality
vector for each execution plan is derived, by accumulating
all the execution plans’ quality vectors, we obtain matrix
Q, where each row represents an execution plan’s quality
vector.
Q =
Q
1,1
Q
1,2
. . . Q
1,5
Q
2,1
Q
2,2
. . . Q
2,5
.
.
.
.
.
.
.
.
.
.
.
.
Q
n,1
Q
n,2
. . . Q
n,5
(4)
415
