A Broker-Based Framework for QoS-Aware Web Service Composition

Tao Yu and Kwei-Jay Lin

Dept. of Electrical Engineering and Computer Science
University of California, Irvine
Irvine, California 92697-2625, USA

Abstract
Web services are modular web applications that
can be independently deployed and invoked by other
software or services on the web. This offers enterprises
the capability to integrate in-house business services
with external Web services to conduct complex
business transactions. The integration efficiency and
flexibility are critical for services composition. For
Web services providing a similar functionality, Quality
of Service (QoS) is the main factor to differentiate
them. The overall QoS of a business process must meet
a users requirement. In this paper, we propose a
broker-based framework to facilitate dynamic
integration and adaptation of QoS-aware Web services
with end-to-end QoS constraints. The key functions of a
dynamic broker include service collection, selection,
composition and adaptation. Our study considers both
functional and QoS characteristics of Web services to
identify the optimal business process solutions.

1.

Introduction

Web services are becoming a popular system

software framework for distributed computing and ebusinesses. Using the Web service framework,
integration and outsourcing are two key system
engineering concepts. By adopting standard-based
protocols (such as SOAP and WSDL), service
components from different providers can be
conveniently integrated into a composite service
regardless of their locations, platforms and/or hardware
speeds. Moreover, systems builders no longer need to
have a complete set of service components in-house,
since many of the components can be outsourced to
service providers either pre-selected or on-the-fly.
However, due to the dynamic nature of external
Web services, several system issues must be
considered when integrating distributed Web services
into a business process. For example,
the set of services capable of providing the same
functionality may be constantly changing;
there may be different ways to construct a business
process;
a business process needs to accommodate to
system irregularities, such as service failure;

the performance of a business process, which is

measured in terms of its overall end-to-end QoS,
must satisfy users requirements.
For all these reasons, businesses should not make
service composition decisions in an ad hoc manner.
They need to automatically and efficiently:
1. convert users requirements into a business process
that can be implemented by existing services;
2. identify the most capable yet efficient service for
each component in a business process to meet
users functional and QoS requirements;
3. compose and bind services that are cost-effective;
4. ensure that the performance of a business process
will meet a users QoS requirement;
5. monitor the execution of business process and
perform adaptation due to service failures to keep
the system optimality and service quality.
In this paper, we propose a broker-based
framework for the dynamic integration of Web services
with end-to-end QoS constraints. The main motivation
of the proposed framework is to delegate QoS brokers
to make intelligent service selection decisions for
business process requesters. The main functions of a
QoS broker include:
Service tracking: A broker has a service repository
to record all feasible Web services it is aware of;
Dynamic service composition: A broker maintains
some predefined business process plans in the
process repository. It can also build new plans or
update existing plans based on user requirements
and newly discovered services;
Dynamic service selection: This is the key
function of our service broker. A broker selects
services to execute a business process so that the
user-defined utility is maximized, and users QoS
requirements are satisfied;
Dynamic service adaptation: In case of individual
service failure during a business process
execution, a broker needs to reconstruct business
process to ensure a good performance;
In our proposed framework, QoS brokers are
services that are independently maintained and
operated, much like human travel agencies. Each
broker may concentrate on some specific sectors of
services for a certain industry and/or customer group.
In other words, we do not assume that all brokers are
equally powerful or effective. In fact, users are free to
choose among many available brokers at any time.

Also, a broker may work with other brokers to meet a

users request. After each business process transaction,
a user should report the received QoS performance
(from the services) to the QoS broker so that the broker
can update the statistical QoS data of each service.
The rest of this paper is organized as follows. In
Section 2, we review related work on Web service
composition and QoS issues. Section 3 presents the
QoS model for web service composition. Section 4
describes the broker-based architecture for dynamic
integration and adaptation of Web services. An
example workflow of using the framework to construct
a business process is given in Section 5. The paper is
concluded in Section 6.

2.

Related Work

Recently, Web service composition has received

much interest for supporting business-to-business and
enterprise application integration. Many industry
standards have been developed in recent years, such as
BPEL4WS (Business Process Execution Language for
Web Services) [1] and BPML (Business Process
Modeling Language) [2]. BPEL4WS, which combines
Microsofts XLANG [11] and IBMs WSFL (Web
Service Flow Language) [7], provides a language for
the formal specification of business processes and
business interaction protocols. It can model the
behavior of both executable and abstract processes.
BPML is XML-based meta-language developed by the
Business Process Management Initiative (BPMI) as a
means of modeling business processes. BPML supports
advanced semantics such as nested processes and
complex compensated transactions that are not
addressed by BPEL4WS. A detailed comparison
between BPML and BPEL4WS is given in [9]. Our
design in this paper is based on BPEL.
Beside business process standard specifications
proposed by industry, many academic research
activities have also been conducted. [13] describes a
framework FUSION for dynamic web service
composition and automatic execution. The projects
goal is to automatically generate an optimal execution
plan from users requirements, executing and verifying
the result against a users stated satisfaction criteria.
However, no service selection algorithm has been
designed.
Patel, Supekar and Lee [10] propose a QoSoriented framework WebQ for adaptive management of
Web service based workflows. Several QoS parameters
such as latency, throughput, reliability, availability,
cost etc. have been defined. In WebQ, every task node
has a separate set of QoS management rules for service
selection. However, each decision is only a local
decision. eFlow [4] discusses the possibility of
performing dynamic service selection based on user

requirements. In eFlow, each service node contains a

search recipe, which defines the service selection rule
to select a specific service for this node. No QoS model
is defined in eFlow. Similar to WebQ, the selection
rule is based on local criteria only. In contrast, our
work focuses on service selection from the global point
of view based on various QoS attributes (e.g. response
time, cost). The business process constructed presents
the globally optimal performance.
Some related work on QoS has been done in the
workflow area, such as the METEOR project [3]. Four
QoS attributes are defined: time, cost, reliability and
fidelity. The project focuses on analyzing and verifying
a workflow QoS instead of constructing a QoS
workflow.
The closest work to ours is [15], in which authors
present a QoS-aware middleware for Web services
composition. They propose a quality-driven approach
to select component services for a composite service.
Multiple QoS criteria, such as price, execution time,
and reliability are considered. They also take into
account of the global constraint, such as the end-to-end
delay constraint considered in this paper. However,
their work is more focused on defining the service
selection model and proposes a linear programming
technique to solve the service selection problem. The
solution is too complex for run-time broker decisions.
QoS guarantee for Web services is one of the main
concerns of the SLA framework [5, 6]. The framework
proposes that differentiated levels of Web services to
different customers on the basis of service level
agreements (SLAs). The service levels are
differentiated based on many variables such as
responsiveness, availability and performance. The
framework comprises the Web Service Level
Agreement (WSLA) language ([8]), a system to
monitor the compliance of service level agreements,
and a workload management system that prioritizes
requests according to the associated SLAs. Our
proposed QoS broker for managing end-to-end QoS
provides a composition and management solution to
ensure the end-to-end QoS of business processes.

3.
3.1

QoS Model
Composition

for

Web

Service

QoS Attributes

The area of QoS management covers a wide range

of techniques that match the needs of service requesters
with service providers. Our research assumes that all
services can deliver SLA. By defining different SLAs,
a service provider provides differentiated Web services
to different customers. Each SLA is called a service
level in our model. In this research, the following four
quality metrics of a Web service are considered:

n
s1

s2

s3

(1) sequential

s2

s3

s1

s4

(2) parallel

s2

p1
s1

s1

s4
p2

s3
(4) while/loop

(3) conditional
(p 1 +p 2 = 1,
0<p 1 <1, 0< p 2 <1)

Figure 1. Composition Flow Models

Response Time (Ts): the time interval between

when a service is invoked and when the service is
finished. More on this is discussed below;
Service Cost (Cs): the price that a service
requester has to pay for invoking the service;
Availability (A): the probability that the service is
available at some period of time;
Reliability (R): the probability that a request is
correctly responded within the expected time.

In addition to service response time, since Web

services are scattered over Internet, we also need to
consider the Network Transmission Time (Tn) (with
also the Transmission Cost Cn) for invoking a service.
In practice, Web service response time is not a
constant but varies within some range. A service
provider may provide the worst case response time Tmax
and the average response time Tavg (Tavg < Tmax). In
most cases, the actual response time will be close to
Tavg. However, when constructing a business process, a
user may decide to use Tavg or Tmax in the SLA for
service selection. Using Tavg will have a higher chance
to select the most suitable services since Tavg reflects
the service behavior more accurately.
Similar
consideration can be given to the network transmission
time that must be measured from server to server.
Initially we assume brokers have a rough estimate on
network transmission values.
A service provider defines its service response
time and cost based on their SLA. They may also
provide an expected value of availability and
reliability. These numbers will be refined by a broker
after receiving users feedback on the actual QoS
delivered by a server.

3.2

Composition flow models

We will now discuss the QoS relationships

between individual Web services in different
composition models. The QoS attributes of the

business process are decided by QoS attributes of each

individual service as well as their QoS relationships.
There are different ways individual services can
be integrated to build a business process. The four
basic relationships are (1) sequential; (2) parallel; (3)
conditional; and (4) loop, as shown in Figure 1. The
sequential model is the most fundamental and, in this
paper, all other models are converted to the sequential
model.
For a business process that is composed by several
services, the performance is measured in terms of its
end-to-end quality instead of the quality of an
individual service component. Table 1 shows the
aggregate function for computing the QoS attributes of
a business process that is consisted of n Web services
sequentially. The reliability and availability aggregate
functions are non-linear functions. In order to make all
aggregate functions to be linear ones, we transform
them by using a logarithmic function:

log( R S ) = log(

n
i =1

Ri ) =

n
i =1

log( Ri ) .

Let RS= log(RS),Ri=log(Ri), we get R S' =

n
i =1

Ri' . The

same can be applied to AS. After that, we have all QoS

aggregate functions as linear functions for the
sequential composition model. This is necessary for
our proposed service selection algorithms, which will
be described later in this paper.
Table 1. QoS Aggregate Function for the Sequential
Model
Attributes
Aggregate Function
n
Response time
T =
(Tsi + Tni )
Cost
Reliability
Availability

C =
R =
A=

i =1
n

i =1
n

C si

i =1
n
i =1

Ri
Ai

Broker
Other Brokers
BrokerService
Info Manager

Broker
Service Info
Manager

QoS Information

Service Requestor
User
requests

Services
repository

Web
Services

Execution
plan

Composition
Manager
Process
repository

QoS
requirements

Selection
Manager

QoS Confirmation
QoS Info. Update

Selection Result

Adaptation
Manager

Execution
Engine
Report,
QoS Info.

Figure 2. QoS Broker Architecture

4.

System Architecture
5.

The main motivation behind the QoS broker

architecture is to deploy a broker that can make
selection decisions for business process requestors and
thus simplifies enterprise system engineering. A broker
conducts service integration for clients according to
their requests. It has Service Info Manager, Selection
Manager, Composition Manager, and Adaptation
Manager to conduct service information collection,
composition, selection, and adaptation respectively.
Figure 2 shows the architecture of a broker. In this
section, we present the design of each component.

7.
8.

4.1

9.

Service Info Manager (SIM): Service

Information Tracking

The Service Info Manager (SIM) keeps a known

set of Web services candidates for user invocation in
Service Repository (SR). There are two key tables in
SR: Service Table and QoS Statistics Table.

Service Table
Each Web service in the Service Table includes
the following fields (both functional and QoS
characteristics, see Table 2):
1. ID: a unique representation of the record;
2. Service Name: name of the Web service;
3. URL: where the Web service is located (usually it
points to the WSDL file of the service); e.g.
http://www.xmethods.net/wsdl/xspace_v1.wsdl;
4. Namespace URI: the namespace used for
definitions in the service WSDL document. Each
Web service needs a unique namespace for client

6.

10.
11.
12.
13.
14.
15.

applications to distinguish it from other services

on the Web;
Service Class: In SR, Web services belong to
different service classes. A Service Class (SC) is a
group of services that provide similar
functionalities with possibly different nonfunctional parameters (QoS);
Operation (with input and output parameters): the
actual function provided by Web service; e.g.
weather report (input: zip code; output:
temperature);
Description: description of the operation;
Service Level: A Web service may provide several
service levels represented by different SLAs;
Maximum Capacity: the maximum number of
requests a server can handle at the service level;
Current Capacity: the current number of requests
at this service level, to derive the server load;
Worst Response Time (Tmax): the maximum time
needed for service at this service level
Average Response Time (Tavg): the average time
needed for service at this service level;
Service Cost: the service cost at this service level;
Availability;
Reliability.

Fields 8 to 15 are QoS parameters. All service

providers publish expected values about their services.
These numbers will be refined by brokers in their SR
according to the actual values received from user
feedbacks to reflect more accurate values. A Web
service may have many records in SR depending on
how many operations and service levels it provides.

Table 2. Service Table

ID
1
2
3
4
5

Service
Name
s1

URL

http:
//a.b

URI

d.e.f

Service
Class

Oper.

Input

Output

Desc.

op1

In1

Out1

des1

op2

In2

Out2

des2

S1

Service
Level
l1
l2
l1
l2
l3

Max.
Cap.
10
8
9
9
10

Cur.
Cap.
6
5
3
6
1

Tmax

Tavg

Cost

Re.

Av.

50
100
30
70
100

40
70
20
50
80

100
50
200
120
60

.8
.8
.7
.7
.7

.9
.9
.9
.9
.9

Table 3. QoS Statistics Table

Service
Name
s1
s1

Oper.
op1
op2

Service
Level
l1
l2

Invoke
Times
10
50

Table 4. Process Table

Process Plan ID

Service Classes

M1

S1, S2, S3, S7

M2

S1, S4, S5, S6

In this paper, we do not consider the service

ontology issue for service description. We assume all
services in the community using the same ontology to
describe their services, so that the broker can find the
services easily.

QoS Statistics Table

QoS Statistics Table (Table 3) records the
statistical QoS data for services. The information
includes: number of times a service has been invoked
(for each operation at each service level); last invoke
time; average response time based on previous
invocations; standard deviation of the response time to
indicate the stability of service, reliability, and
availability.
Based on the statistical QoS data, we can update
the Service Table with more accurate values of Tavg,
reliability and availability.

4.2

Composition Manager (CM): Dynamic

Service Composition

The functions of Composition Manager (CM) include:

1. Maintaining Process Repository (PR), which
stores the process plan information. A process plan
is defined by a set of service classes and the
connection relationships among them;
2. Taking a users service request to generate an
execution plan.
Both process plan and execution plan are abstract
processes, consisting of service classes and the

Latest
Invoke Time
timestamp
timestamp

Tavg
45
60

Std.
Dev.
2.3
..

Re.

Av.

.6
..

.9

connection relationships among them (only sequential

connection is discussed in this paper). A process plan
defines a flow of service classes without identifying the
actual service to be invoked. Table 4 shows the process
table in PR. Figure 3 shows the graphical
representation of M1 and M2.
CM is responsible for creating process plans and
storing them in PR. Users can select from existing
process plans or create new ones. All selected process
plan(s) are included in an execution plan. If only one
process plan is selected (created), the execution plan is
just the same as the chosen process plan. If more than
one process plans are selected, the execution plan is the
combination of all chosen process plans. The execution
plan will be used by the selection algorithm to identify
the best path for the business process request. Figure 2
shows an execution plan, which is composed by two
process plans. It can be represented by a directed
graph.
S1

S2

S3

S7
start

Process plan 1

S2

S3

S7

S4

S5

S6

end

S1
S1

S4

S5

S6

Execution plan

Process plan 2

Figure 3. Process Plan and Execution Plan

4.3

Selection

Manager

(SM):

Dynamic

Service Selection
The execution plan generated by CM is an abstract
graph. No specific service is identified in it. In order to
initiate the actual business process, the Selection
Manager (SM) needs to select a specific service and
service level along an optimal path in the execution
plan. The selection is based on a users QoS
requirements, as shown in Figure 2.

Utility function
In order to construct a composite Web service
(business process), besides satisfying users functional
and QoS requirements, we also define an objective
function for optimization. In out study, we define a
utility function as our optimization objective. The
utility function is based on a weighted sum of system
parameters, including static server information (service
level), client QoS requirement (QoS constraint),
dynamic server capacity (server load), etc. Each service
level of every individual service has its own utility
computed by the utility function. Detailed information
about the utility function definition can be found in
[13].

Problem Definition
For a business process that is composed of several
services, each service has several service levels. The
business process is constructed by a combination of
service levels of each service along an execution path.
The service selection problem can be defined as:
Definition 1: Suppose a user has n QoS
requirements Qc = (Qc1 ,Qc2 , ,Qcn). There are a total
of N service level combinations, each has an overall
QoS value defined by Qi =(Qi1 ,Qi2 , ,Qin) and a
utility value Ui, defined by the utility function. The
service selection problem for constructing an optimal
business process is to find a service level combination
that produces the highest utility while satisfying all
users functional and QoS requirements among all
service level combinations, i.e.

Find
Subject to

i
Ui U j
Q ik Q ck

(1 i , j N )
(1 k n )

Service Selection Algorithms

Our current work considers the situation when a
user has only one QoS constraint, e.g. service response
time. In [13], we have studied two approaches for
service selection: the combinatorial approach and the
graph approach. The combinatorial approach models
the selection problem as a Multiple Choice Knapsack
Problem (MCKP) and gives an efficient algorithm
(Pisingers algorithm) to solve it. However, this
approach can only treat one execution path at a time.
So for an execution plan with more than one execution
path, we need to run the algorithm more than once, and
compare the results to find the optimal solution. The
graph approach models the problem as a Directed
Acyclic Graph (DAG) and converts the original
problem to the problem of finding the highest utility
path in DAG with an end-to-end constraint. It can
handle the whole execution plan at the same time. The
CSP algorithm is used in the graph approach [13].

In our simulation study, Pisingers algorithm runs

much faster than CSP, especially when system size is
large. However, the combinatorial approach cannot
handle network transmission delays accurately. So the
result may not as good as the graph approach.
After a service at a service level for each service
class along an execution path is chosen, SM contacts
every selected service to receive a commitment on the
guaranteed QoS service level.

Service Selection with Adaptive Information

During the execution of a business process, if one
component service fails or becomes overloaded, a
mechanism is needed to ensure the running process is
not interrupted and the failed service can be quickly
and efficiently replaced. In [14], we extend the CSP
algorithm to produce CSPB and CSPR that generate
both optimal process and adaptive paths during service
selection.
CSPB generates, for each service along the
optimal path, a secondary path from the current service
(without going through its immediate successor) to the
end of the business process. The secondary path
information will be passed to every component service
during execution. So during runtime, a business
process component service can automatically switch to
the secondary path whenever its successor becomes
unavailable. CSPR is used to reconfigure a business
process to avoid a failed service. For each component
service si(lj) on the optimal path, CSPR generates a
replacement path, which is the optimal path in the
original system without si(lj).
CSPB and CSPR are designed to handle single
point of failures. Our study [14] shows that the average
running time of CSPB is about 3 times that of CSP and
CSPR is about 2 times that of CSP. If we combine
CSPB and CSPR together (in algorithm CSPBR), and
generate both backup paths and replacement paths at
the same time, the average running time is about 4
times that of CSP. So producing all dynamic adaptation
information for a business process only increases the
running time by a constant factor regardless of system
size. We believe this is a reasonable offline overhead to
enhance the system adaptation capability.
Table 4. Selection Result
Business
Process
ID

Optimal
Process

BP1

s1 (l1),
s3(l2),
s5(l1),
s7(l1)

Failed
Service
Name

Backup
process

s2 (l1), s3(l2),
s5(l1), s7(l1)

s1
s3
..

Replacement
Process

s1 (l1),
s4(l2),
s5(l1), s7(l1)
..

s1 (l1), s4(l1),
s6(l1), s8(l1)
..

The selection result produced by SM includes: the

optimal executable business process that contains a
sequence of services (with service level); backup
business processes (back up paths) and replacement
business processes (replacement paths), as shown in
Table 4.

4.4

Adaptation Manager (AM): Dynamic

Adaptation

The selection result is sent back to the service

requester. A business process execution engine (such
as a BPEL engine) is then initiated in the service
requester. Based on the optimal business process
generated, the execution engine orchestrates the
component services to execute the instance of the
business process. At run time, the execution engine
monitors the execution at every step, such as response
time at each service, network transmission delay, etc. If
everything goes well, after successful complete
executions, the execution engine reports the actual
recorded QoS to Adaptation Manager (AM) in broker.
AM will put them into the QoS Statistics Table in SR.
If a service problem occurs during process
execution, the execution engine informs the service
that is the predecessor of the failed service to switch to
the backup path to continue execution. At the same
time, the execution engine will adopt the replacement
path for all new process instances. The execution
engine then reports the failure to AM in the broker and,
in turn, AM will ask SM to generate a new set of
backup paths and replacement paths based on the
newly deployed replacement path.
On receiving execution engines exception report,
AM makes an update to the QoS Statistics Table in SR
for corresponding QoS parameter values (such as
reliability, availability, and response time.)

5.

b( s, l ) avgb
c( s, l ) avgc
) + w * (1
)
stdb
stdc
wb and wc are the weights of benefit and cost, wb + wc
=1, wb 0, wc 0
b(s,l), c(s,l): benefit and cost of service s at level l
avgb, avgc: average benefit and cost for all services in
the same service class
stdb, stdc: standard deviation of all benefits and costs;
Fsl = wb * (

Step 1. User submits the request to CM. CM checks

PR and discovers that there are 4 PPs available. It
selects all of them and constructs an execution plan,
which has four execution paths, as shown in Figure 4.
CM sends the execution plan to SM;
Step 2. SM checks SR to select services for
constructing the optimal business process. Each service
class in this example has five candidates, each
candidate defines a service level of a service, as shown
in Table 5. SM uses CSPBR to produce the optimal
path, replacement paths and backup paths. They are
shown in Table 5;
Step 3. The optimal path, replacement paths and
backup paths are returned to the service requester. The
execution engine in the service requester begins
process execution by invoking the first service on the
optimal path;
Step 4. During runtime of process execution, the
execution engine monitors the whole process and
initiate adaptation if necessary.
From Table 5, we can see that replacement paths
are usually better than backup paths. For example, the
utility produced by the replacement path for the failure
of #21 is 1404 while utility for the backup path is only
1374. This is because the replacement path is the
globally optimal solution while the backup path is only
a local one ([17]).

Business Process Example

In this section, we show an example using the

QoS business process broker presented in the previous
section. The business process request has the following
QoS parameters:
QoS constraint: end-to-end response time 91;
Tavg (average response time) is used as the
constraint for service selection
Objective function: the objective is to maximize
the total utility produced by the process.
The utility function is defined as in [13]. It defines a
benefit function based on the server load (Current
capacity vs. Max. capacity); the lighter the load, the
higher the benefit. The utility function is defined as the
weighted sum of cost and benefit, i.e.

6.

Conclusion

This paper presents a broker-based framework for

dynamic and adaptive QoS-Aware Web services
composition with QoS constraints. The components in
a broker implement dynamic service composition,
selection and adaptation in order to compose and to
adjust the business process to meet users needs.
S2

s ta rt

S1

S6
S4

S3

S5

end

S8
S7

e p 1 : S 1 ,S 2 ,S 4 ,S 5 ,S 6 ,S 8 ;

e p 2 : S 1 ,S 3 ,S 4 ,S 5 ,S 6 ,S 8

e p 3 : S 1 ,S 2 ,S 4 ,S 5 ,S 7 ,S 8 ;

e p 4 : S 1 ,S 3 ,S 4 ,S 5 ,S 7 ,S 8

Figure 4. Execution Plan

Table 5. Optimal Path, Backup Paths and

Replacement Paths
Service Class
Candidates

S1
1,2,3,4,5

S2
6,7,8,9,10

Delay Constraint

S8

36,37,38,39,40

91
Delay
91

Utility
1469

Process
1,7,16,21,29,40

Failed
Service

Delay

Utility

Backup Path

91

1337

16
21
29
40

89
88
88
88

1447
1374
1268
1439

1,10,20,21,29,39,4
1
1,7,20,21,29,40,41
1,7,16,25,29,39,41
1,7,16,21,31,40,41
1,7,16,21,29,39,41

Delay

Utility

Replacement Path

91
89
89
91
91
88

1379
1347
1447
1404
1367
1439

2,7,20,21,29,40,41
1,6,16,22,29,40,41
1,7,20,21,29,40,41
1,7,16,25,29,40,41
1,7,16,21,28,40,41
1,7,16,21,29,39,41

Replacement
Paths

Backup Paths

Optimal Path

Failed
Service
1
7
16
21
29
40

We have designed service selection algorithms for

both the optimal selection and multiple adaptive
secondary selections to be used when a service cannot
meet its SLA at run time. Service selection is based on
users end-to-end QoS requirements. As discussed, our
current service selection algorithms can only handle
one QoS constraint and a single point of failure. We are
extending our research to handle more than one QoS
constraints and multi-points of failure problems.

7.

References

[1] T. Andrews, F. Curbera, H. Dholakia, Y. Goland,

J. Klein, F. Leymann, K. Liu, D. Roller, D.
Smith, S. Thatte, I. Trickovic, S. Weerawarana,
Business Process Execution Language for Web
Services,
Version
1.1.
http://www106.ibm.com/developerworks/webservices/library
/ws-bpel, May 2003.
[2] A. Arkin, Business Process Modeling Language
(BPML), http://xml.coverpages.org/bpml.html
[3] J. Cardoso. Quality of service and semantic
composition of workflows. Ph.D Thesis,
University of Georgia, 2002.
[4] F. Casati, S. Ilnicki, L. Jin, V. Krishnamoorthy,
and M. Shan, Adaptive and dynamic service
composition in eflow. Technical Report, HPL200039, Software Technology Laboratory, Palo
Alto, CA, March 2000.
[5] A. Dan, et al., Web services on demand: WSLAdriven automated management, IBM Systems
Journal, Vol. 43, No. 1, pp. 136-158, 2004

[6] A. Keller, H. Ludwig: Defining and Monitoring

Service Level Agreements for dynamic eBusiness, in: Proceedings of the 16th USENIX
System Administration Conference (LISA'02),
November 2002
[7] F. Leymann Web service flow language
(WSFL).
http://www4.ibm.com/software/solutions/webservices/pdf/W
SFL.pdf 2001.
[8] H. Ludwig, A. Keller, A. Dan, R.P. King and R.
Franck, Web Service Level Agreement (WSLA)
Language Specification, Jan. 2003, by IBM,
http://www.research.ibm.com/wsla/WSLASpecV
1-20030128.pdf
[9] J. Mendling, M. Mller, A Comparison of
BPML and BPEL4WS. In Proceedings of the 1st
Conference "Berliner XML-Tage". Berlin 2003,
pp. 305-316.
[10] C. Patel, K. Supekar, Y. Lee, A QoS Oriented
Framework for Adaptive Management of Web
Service based Workflows Database and Expert
Systems (DEXA-2003) Conference, Prague,
Czech Republic, September 2003
[11] S. Thatte, XLANG: Web services for business
process
design.
http://www.gotdotnet.com/team/xml_wsspecs/xla
ng-c/default.htm 2001.
[12] D. VanderMeer, A. Datta, K. Dutta, H. Thomas,
K. Ramamritham, S.B. Navathe, FUSION: A
System Allowing Dynamic Web Service
Composition and Automatic Execution, In proc.
of IEEE International Conference on ECommerce, Newport Beach, CA, June 2003
[13] T. Yu and K. J. Lin, Service Selection
Algorithms for Web Services with End-to-end
QoS Constraints, to appear in the Journal of
Information
Systems
and
e-Business
Management, Springer Publisher, 2005.
[14] T. Yu and K.J. Lin, Adaptive algorithms for
Finding Replacement Services in Autonomic
Distributed Business Processes. To appear in
Proc. of the 7th International Symposium on
Autonomous Decentralized Systems, Chengdu,
China, April 2005
[15] L. Zeng, B. Benatallah, A. Ngu, M. Dumas, J.
Kalagnanam and H. Chang. QoS-Aware
Middleware for Web Services Composition.
IEEE Transactions on Software Engineering,
pp311-327, Vol. 30, No.5, May 2004