QOS IN WS-BPEL PROCESSES A DISSERTATION SUBMITTED TO DEPARTMENT OF COMPUTER SCIENCE & ENGINEERING AT THE INDIAN INSTITUTE OF TECHNOLOGY DELHI IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF MASTER OF TECHNOLOGY Debdoot Mukherjee May 2008 c Copyright by Indian Institute Of Technology Delhi 2008 All Rights Reserved
84
Embed
QOS IN WS-BPEL PROCESSESto ascertain QoS for BPEL processes. In this thesis, we illustrate the difierences in expressiveness of BPEL and conventional work°ow systems and show that
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Figure 2.1: A system that is neither series nor parallel
X O R J o i n T a s k
X O R S p l i t T a s k
C o n d i t i o n a l T a s k s
S u c h a t r a n s i t i o ni s n o t a l l o w e d
Figure 2.2: Synchronization with links
where, g(x) takes up either 0 or 1 for values x > 0 and x ≥ 0 respectively
Limitations
There is a restrictive rider added with most of the reduction rule-sets given above.
For example, in the sequential system the start task cannot be a split and the end
task cannot be a join. Cardoso’s model adapts from the reductions used in standard
reliability theory for computing reliability of series-parallel systems [33, 27]. But the
model is not capable of handling complex systems such as the one shown in Figure 2.1
that can neither be reduced to a series nor decomposed as a parallel system. Reliabil-
ity modeling of such systems can be performed using various approaches such as path
tracing, state enumeration, decomposition method and cut set method. Again, only
structured programming constructs have been considered here. Presence of goto-like
transitions that extend from one structured construct to another as shown in Figure
2.2 prevent application of the proposed reductions. Cardoso treats QoS for a task as
a deterministic value. But due to the uncertainty that is generally associated with
web services, especially if they are not owned by the integrator’s enterprise, it is more
2.1. QOS IN WORKFLOWS 14
realistic to model QoS probabilistically.
2.1.2 Other Efforts
Hwang et. al. [28] propose a probabilistic framework for QoS computation. They
extend Cardoso’s model to have each QoS parameter for a web service represented by
a discrete random variable having a certain probability mass function (PMF). The
work discusses how to efficiently aggregate PMFs of a number of random variables
over different domains and contrasts greedy and dynamic programming approaches
for sample space reduction in the aggregation problem.
Canfora et al. [9] apply Cardoso’s QoS model with minor modifications in their
middleware that uses genetic algorithms for QoS aware composition and replanning.
They make use of estimated number of loop iterations in the reduction for a loop
rather than unfolding loops based on probability of repeating the loop. They also
introduce availability as a parameter with exactly same reduction rules as reliability.
Zeng et al. [61] model composite web services as state charts and put forward aggre-
gation functions to ascertain QoS of execution plans. The critical path of all possible
execution paths is determined and the duration of that path is taken to be the dura-
tion of the composite service. Estimation of successful execution rate and availability
taken into consideration only critical tasks based on the assumption that non-critical
tasks can be re-executed successfully without altering the QoS characteristics of the
final response. The model is simplistic since the state charts are allowed to have only
two types of compound states, namely, AND states and OR states, with no provision
for conditional or loop constructs. Menasce [43] presents a formulation to determine
throughput in composite web services from the flow graph that lists the web service
invocations. Jaeger et al. [35] propose aggregation of QoS dimensions on the workflow
patterns listed in Van der Aalst’s seminal work [1]. The approach is an elegant one
but the authors do not explain how to dig out such workflow patterns from a process
an to carry out an implementation of the same. Model-driven computation of QoS
has gained attention of late. We briefly look at some of the techniques used in the
section below.
2.2. FAULT TOLERANCE 15
Model Driven QoS Computation
D’Ambrogio and Bocciarelli [16] propose a model driven approach wherein a BPEL
process is described by an UML (Unified Modeling Language) model, extended ac-
cording to the UML Profile for Automated Business Processes [3]. The UML model
is then annotated with performance data and a LQN (Layered Queueing Network)
model is obtained, which is solved to predict performance of the BPEL process. Al-
though the process of conversion of models built according to the UML Profile into
BPEL has been thoroughly described in [3], the complex control flow offered by BPEL
have not been exhaustively mapped back onto the UML profile. However, BPEL to
UML transformation is an active research topic [48].
2.2 Fault Tolerance
Traditionally, software fault tolerance research has revolved around two approaches
- N-Version programming formulated by Avizienis [6] and Randell’s Recovery Blocks
[46]. N-version programs run multiple implementations providing the same function-
ality but having diverse designs in parallel. Thereafter, majority voting is done to
obtain the result of the programs. Recovery blocks invoke the redundant alternate
implementations sequentially if the output produced by one cannot pass assertion
checks. These two fault tolerant constructs have been studied in various contexts.
Reliability improvement that may be possibly derived through the use of these con-
structs have been analyzed [21, 20, 15, 44]. Other topics that have gained interest in
fault tolerance research include how to provision voting mechanisms [45] and generate
acceptance tests [4].
The notion of dependability has been studied at various levels in the area of web
services. Figure 2.3 lists the different levels where various standards exist to model
behavior of web services. Reliability of message exchanges has been documented in
OASIS standards such as WS-Reliability and WS-ReliableMessaging. A host of se-
curity standards (WS-Security, WS-Trust, WS-SecurityPolicy etc. make use of avail-
able encryption techniques to model integrity and confidentiality in SOAP messages.
2.2. FAULT TOLERANCE 16
W S - R e l i a b l eM e s s a g i n g ,W S - R e l i a b i l t y
W S - S e c u r i t y +
H T T P S
W S - T r a n s a c t i o n W S - C o o r d i n a t i o n
W S - B P E LF a u l t H a n d l e r sC o m p e n s a t i o nH a n d l e r s
R e d u n d a n c y i nW S c o m p o n e n t s
N e t w o r k L e v e l
M e s s a g e L e v e l
T r a n s a c t i o n L e v e l
C o m p o n e n t L e v e l
Figure 2.3: Dependability Stack in Web Services
WS-Transaction and WS-Coordination define mechanisms for transactional interop-
erability between Web services domains and seeks to ratify transactional qualities of
service in web services applications. At the level of web service composition, we have
WS-BPEL constructs such as fault handlers and compensation handlers that help the
designer incorporate error handling and backward recovery in case of failures. The
block at the top right corner signifies our focus area of research, i.e., how to make
use of redundant components to improve dependability. No web services standard
exists as of date in this area. However, there have been some research efforts that use
redundancy as a tool for dependabilty enhancement.
2.3. WS-BPEL 17
2.3 WS-BPEL (Business Process Execution Lan-
guage)
2.3.1 Evolution
Web services aim at providing an environment that supports flexible integration of
business processes implemented as heterogeneous systems and in diverse platforms
across enterprise boundaries. A standard process integration model is essential to let
business processes and applications carry out complex interactions that are often long
running.
A host of standards have come up in the process integration space, each sup-
ported by a company or a standards body. Microsoft’s XLANG (Web Services for
Business Process Design) [52], one of the earliest process modeling languages, is block-
structured with basic control flow structures such as sequence, switch, while, all (for
parallel routing), and pick (for forking activities based on timing or external triggers).
IBM’s WSFL (Web Service Flow Languages) is a unique graph based language, offers
capabilities to represent control flow as directed graphs that can be nested but must
be acyclic. Again it derives most of its control flow constructs from the workflow lan-
guage of IBM’s MQ Series Workflow. Web Service Choreography Interface (WSCI) is
an XML-based interface description language that describes the flow of messages ex-
changed by a Web Service participating in interactions with other services. WSCI was
conceived and developed by BEA, SAP, Intalio and Sun Microsystems. Intalio pro-
moted the Business Process Management Initiative (BPMI.org) which came up with
BPML (Business Process Markup Language). ebXML (Electronic Business using eX-
tensible Markup Language) contains BPSS (Business Process Schema Specification),
which is yet another workflow language with similar capabilities. The plethora of
standards, most of which are overlapping and add no real value, have contributed in
great measure only to WSAH (Web Services Acronym Hell).
Business Process Execution Language (BPEL), combines the capabilities of both
XLANG and WSFL. BPEL 1.0 was jointly developed by IBM, BEA, SAP, Siebel,
2.3. WS-BPEL 18
and Microsoft in August 2002. In April 2003, BPEL 1.1 [53], which came to be
known as BPEL4WS, was submitted to OASIS for ratification. WS-BPEL 2.0 was
approved as an OASIS standard in April, 2007 by a technical committee with rep-
resentatives from 37 different organizations. Two other standards, WS-Coordination
and WS-Transaction strengthen to BPEL’s cause in supporting long running trans-
actions. They lend a framework for distributed processes to interact and let ACID
transactions to happen between business activities. Also, WS-BPEL utilizes several
XML specifications: WSDL 1.1, XML Schema 1.0, XPath 1.0 and XSLT 1.0. Due to
BPEL’s greater expressive power (see a comparison of various workflow languages in
[57] in terms of the different workflow patterns supported by them) and the patronage
it received from the two giants IBM and Microsoft, it eventually managed to leave
the pack behind to emerge as the choicest of all web service composition languages.
2.3.2 Brief Overview
WS-BPEL is intended for modeling two types of processes: executable and abstract
processes. An abstract process may hide some of the concrete operational details that
are required by an executable artifact and can thereby serve as a process template
capturing the process logic embodying the domain specific best practices. WS-BPEL
lays down a grammar for capturing the behavior of a business process based on inter-
actions between the process and its partner processes. The notion of 〈partnerLinks〉is used to model peer-to-peer conversational partner relationships. Again, the actual
partner service may be dynamically determined within the process.
A WS-BPEL process specification is analogous to a flow-chart. Each element in
the process is called an activity. An activity can be of two types: basic or structured.
Basic activities either describe interactions with other partners or model primitive
steps in the process. Structured activities encode control-flow logic and can have
other activities nested in them. WS-BPEL 2.0 has nine different basic activities that
are listed below:
1. invoke: An 〈invoke〉 activity is used to call operations (either one way or
2.3. WS-BPEL 19
request-response) embodied in web services offered by partners of the business
process being described.
2. receive: A 〈receive〉 activity is used to accept inbound messages from part-
ners of the service being provided by the business process. A receive activity
annotated with createInstance = ”yes” denotes the starting point of execution
of the service.
3. reply: A 〈reply〉 activity is used to send a response to a request previously
accepted through an inbound message activity such as receive or pick.
4. assign: An 〈assign〉 is used carry out updates on variables.
5. throw: A 〈throw〉 activity is used to signal an internal fault explicitly.
6. wait: A 〈wait〉 activity forces the process to be delayed for a certain period of
time or wait until a certain deadline is reached.
7. exit: A 〈exit〉 activity immediately ends the business process instance terminat-
ing all running activities without execution of any fault handlers or termination
handlers.
8. rethrow: A 〈rethrow〉 activity is used inside fault handlers to rethrow the fault
they caught, propagating the fault name and the fault data of the original fault.
9. empty: An 〈empty〉 activity does nothing but sometimes finds use as a syn-
chronization point or for supression of faults.
Apart from these basic activities, WS-BPEL has a provision for addition of new
activities using the tag 〈extensionActivity〉. WS-BPEL also enumerates seven differ-
ent structured activities.
1. sequence: A 〈sequence〉 activity contains one or more activities that are per-
formed sequentially, in the order in which they appear within the 〈sequence〉element. The 〈sequence〉 activity completes when the last activity nested within
in the sequence has completed.
2.3. WS-BPEL 20
2. flow: A 〈flow〉 activity provisions execution of activities concurrently and also
allows for synchronization between the activities contained in it through the
notion of links. The 〈flow〉 completes on completion of all activities nested
directly within the flow. However, skipping execution of activities within a flow
is allowed if their enabling conditions evaluate to false.
3. if: An 〈if〉 activity consists of one or more conditional branches defined by
the 〈if〉 and optional 〈elseif〉 elements, followed by an optional 〈else〉 element.
The first branch whose 〈condition〉 holds good is taken, and the activity nested
within it is executed.
4. pick: A 〈pick〉 activity waits for the occurrence of exactly one event from a
set of events and executes the activity contained within that event. The events
can either be receipt of inbound messages (〈onMessage〉) or triggering of timer
based alarms (〈onAlarm〉).
5. while: A 〈while〉 activity is one of the three constructs for provisioning loops.
The activity contained in 〈while〉 is executed until the 〈condition〉 at the start
of the loop evaluates to false.
6. repeatUntil: In a 〈repeatUntil〉 activity, the contained activity is executed
until the given 〈condition〉 becomes true.
7. forEach: A 〈forEach〉 activity provides a loop structure controlled by an
implicit index variable that is initialized to 〈startCounterV alue〉 and ends in
〈finalCounterV alue〉. The number of iterations can be further limited by spec-
ifying a 〈completionCondition〉 wherein one can force the construct to happen
”atleast K-out-of-N” times, where K is the unsigned integer value given by the
〈branches〉 expression. The value of the parallel attribute lends an unique fea-
ture where the ”iterations” of the loop can happen in parallel. In case the
parallel attribute is set to ”yes”, the nested 〈scope〉 is replicated as many times
as the number of iterations of the loop and the index variable takes up val-
ues from 〈startCounterV alue〉 through 〈finalCounterV alue〉 in each of these
2.3. WS-BPEL 21
branches.
WS-BPEL’s notion of a 〈scope〉 offers the ability to specify a behavioral context
within which an activity may execute. A scope allows definition of variables, partner
links, message exchanges and correlation sets that are visible only within the scope.
Event handlers, fault handlers, a compensation handler, and a termination handler
may also be attached to a scope. A brief description of these handlers are given below.
• Event Handler: It provisions event driven programming to some degree in
WS-BPEL. The activity associated with an event is executed when the corre-
sponding event is fired. Again events may be either incoming messages or timer
based alarms.
• Fault Handler: The 〈catch〉 or 〈catchAll〉constructs inside a fault handler
help to intercept faults that might occur and specify appropriate measures that
need to be taken to negate their effects.
• Compensation Handler: It allows backward recovery through the compen-
sation logic that it contains.
• Termination Handler: It helps forced termination of a scope by terminating
its primary activity, stop all running event handler instances and then execution
the activity contained in the termination handler.
Chapter 3
QoS Computation
We have already argued in previous chapters that the workflow QoS models available
in literature are geared towards structured programming constructs and illustrated
their inabilities to cope with the graph based patterns supported through BPEL (See
Section 2.1.1). Our QoS model is specifically designed to deal with the complex graph-
like structures that may be written by tapping WS-BPEL’s greater expressive power.
Also, it provides mechanisms to handle fault handlers and event driven programming
that may be embedded in WS-BPEL processes .
The QoS dimensions considered in our framework, namely, response time, reliabil-
ity and cost; are the three most important parameters that all successful companies
must track in their strife to remain competitive [25, 24]. In the approach outlined
here, these QoS dimensions are evaluated at each activity enroute to QoS computation
for the overall BPEL process.
In a reduction based approach for computation of a QoS parameter of a structured
In our QoS model, invocations of external web services are considered to be the only
activities that may be regarded as source of failures. All basic activities except invoke
are assumed to complete successfully provided they do start. Hence, their probability
of successful completion is equal to the probability that they get to execute. Thus,
we have,
P (successX) = P (startX) (3.3)
where X may be one of the following:
(a) receive
(b) reply
(c) assign
(d) wait
(e) throw
3.4. RELIABILITY MODELING 35
(f) rethrow
(g) exit
(h) empty
(i) compensate
(j) compensateScope
Sequence
A sequence said to be complete when the last activity contained in it completes
successfully. An activity nested inside a sequence can only start if the previous
activity in the sequence has been successful. Thus, if the ith child of sequence is
executing, then all child activities from the first to the (i − 1)th can be taken to be
complete . Therefore, we can model success of a sequence by:
P (successsequence) = P (successlastChild) (3.4)
Flow
A flow activity is deemed to complete only if all activities enclosed by it are complete.
If the suppressJoinFailure attribute is set to no, the flow terminates because of a
joinCondition being evaluated to false and a bpel:joinFailure is thrown to the enclosing
scope. The notion of activities being skipped and the flow still completing is applicable
only when the suppressJoinFailure has the value yes. We track Type C dependencies
and estimate the probability of joinCondition being true, to figure out whether an
activity may start. The synchronization links in effect model the control flow of
execution. Thus, it may be contended (with a similar argument to that posed in case
of sequence) that the completion of all child activities without any outgoing links
would mark the completion of the flow. Therefore, the probability of success of a flow
3.4. RELIABILITY MODELING 36
activity may be written as:
P (successflow) =∏
∀iP (successflowSinki
) (3.5)
where, flowSinki is a child activity of flow with no outgoing links, i.e., an activity
where the 〈sources〉 element is absent. In our passport application example, the 〈if〉activity is the sink since it does not have any outgoing links. Thus, P (successflow) =
P (successif )
If
An if activity is complete when the activity nested in the taken branch completes.
It completes immediately when no condition evaluates to true and no else branch is
specified. In order to elucidate the model, we assume a else branch with an empty
activity to be inserted where no else exists. The probability with which a branch is
taken P (branchTakeni) is obtained as an input. The probability of selection of the
else branch is computed as
P (branchTakenelse) = 1−n−1∑i=1
P (branchTakeni)
where, n is the total number of branches in an if activity.
The probability of success of an if activity is calculated as a weighted sum of
the probabilities of success of the activities contained in all its branches, the weights
being the probability with which a branch gets selected for execution.
P (successif ) =n∑
i=1
P (branchTakeni)× P (successbranchActivity) (3.6)
The 〈if〉 activity in our example does not have an else branch. Thus, we simulate
an else branch, which is selected with a probability that the bank payment is not
done.
3.4. RELIABILITY MODELING 37
Pick
Pick activities are treated in a similar way as if activities; with probabilities of
selection of each event being taken as input. Since, WS-BPEL stipulates that exactly
one event should be executed when a pick is started, the inputs should be validated
to check whether they add upto 1.
P (successpick) =n∑
i=1
P (eventSelectedi)× P (successeventActivity) (3.7)
where, n is the total number of events in an pick activity.
Loops
QoS modeling for loops follows a reduction based approach in the sense that com-
putation of QoS parameters for the child activity may be performed independently
without requiring QoS information of its parent activity. This is facilitated by the
WS-BPEL stipulation (see WS-BPEL 2.0 Static Analysis requirement SA00070) that
synchronization links cannot enter into repeatable constructs by crossing their bound-
aries. Note that we have not included loops in the list of structured activities that
can lead to a Type A dependency because they are dealt with differently.
Loops are handled by unfolding them to the number of iterations that they make.
In case of while and repeatUntil, the number of iterations is taken as an input, pre-
sumably obtained from execution logs. In a forEach activity, the number of iterations
is taken to be either of the following:
numIterations =
B, unsigned int value of completionCondition, if it exists,
The cost an event handler of an event is determined by the sum of costs of all the
events multiplied by their number of occurrences.
CosteventHandler =numEvents∑
i=1
numOccuri × Costeventi (3.43)
Chapter 4
QoS Improvement with Fault
Tolerance
During orchestration of a web service composition, the designer may be unable to find
a web service for some task in the workflow that meets the reliability requirements. If
the task is central to the workflow, the impact on the reliability of overall web service
composition will be severe. Again, it may be possible that all web services available
to perform a certain task on the critical path in a workflow, show huge variations in
their response time (indicated by high standard deviations in our QoS model). In
such cases, fault tolerant constructs may be used to create dependable web services
out of undependable ones and attain the desired reliability and performance levels.
Ofcourse, keeping redundant implementations will mean incurring higher costs.
In this chapter, we present four conventional fault tolerance (FT) techniques,
namely, N-version programming, Recovery Blocks, Return Fastest Response and Dead-
line Mechanisms ; show how they may be implemented with the help of standard
WS-BPEL 2.0 and derive expressions that help in QoS determination of these FT-
constructs. The first two constructs focus on reliability improvement and the latter
two seek to enhance performance. The rest of chapter is organized as follows. For
each of the fault tolerance approaches, we list the scheme used in its WS-BPEL imple-
mentation, their QoS estimation formulae, followed by a demonstration of the utility
of the approach through the running example of the Passport Application Service
4.1. N-VERSION PROGRAMMING (NVP) 56
4.1 N-Version Programming (NVP)
Avizienis and Chen [6] defines N-version programming as the independent generation
of N ≥ 2 functionally equivalent programs, called “versions”, from the same initial
specification. In a N-version program, multiple implementations of a program having
diverse designs are invoked in parallel. After all of them complete execution, a voting
function decides the output of the N-version program. Traditionally, N-version pro-
grams use majority voting on some attribute of the output of the program. However,
voting mechanisms often turn out to complex (especially in inexact cases), require
considerable user intervention and are seldom automatically generated. Our N-version
framework assumes as input - multiple web services having the same functionality and
a voter web service that acts upon the outputs of the redundant services to supply
the result.
N-version programming may used to improve reliability of a task without com-
promising on time very much. Thus, it may be applied to tasks on the critical path
of a workflow where increase in response time is an issue. The N-version program
has to wait for all the implementations to be complete and also the additional voting
method, but it performs better with respect to response time as compared to recovery
blocks when the response times of services are close to each other. However, it may
prove to be more costly than other FT approaches.
4.1.1 WS-BPEL implementation
Given, a set of web services (A1, A2, . . . , An) offering the same functionality and
a voting web service, our N-version program in BPEL can be laid out as follows.
A1, A2, . . . , An are all invoked from inside a 〈flow〉. The voter web service is called
after the completion of the flow to obtain the result. Thus, the 〈flow〉 and the
〈invoke〉 for the voter web service are in a 〈sequence〉. The voter web service must
expect as input an array of the output type of the other web services and produce
an output of the same type as that of the redundant web services. All the 〈invoke〉activities have attached catch blocks to ensure that only outputs of successful web
4.1. N-VERSION PROGRAMMING (NVP) 57
services reach the voting web service.
4.1.2 QoS formulation
We denote the reliability, time and cost of a redundant web service Ai to be denoted by
(Ri, Ti, Ci). We consider the voting web service to perform majority voting and thus
it may work only if k ≥ 2 out of n services have completed successfully. We compute
the probability that at least two implementations succeed as below. (k denotes the
number of successful services, P (X) gives the probability that X is successful, P (X)
gives the probability that X fails)
P (k = 0) =n∏
i=0
(1−RAi)
P (k = 1) =n⋃
i=0
P (A1A2 . . . Ai . . . An)}
=n⋃
i=0
RAi× P (k = 0)
1−RAi
P (k ≥ 2) = 1− (P (k = 0) ∪ P (k = 1)) (4.1)
Now, the Rvoter will denote the conditional probability of success of the voting
web service provided atleast two redundant services have been successful. The voter
program requires at least two values to perform matching or majority voting.
P (voter) = P (voter|K ≥ 2)× P (k ≥ 2)
= Rvoter × P (k ≥ 2) (4.2)
Finally, reliability of the N-version program is given by the probability of success
of the voter service.
RNV P = P (voter) (4.3)
Time taken by a N-version program may be estimated as below.
TNV P = Tvoter + Max∀iTAi(4.4)
4.2. RECOVERY BLOCKS 58
Cost is simply a sum of the costs of all the redundant web services and the voter web
service.
CNV P =n∑
i=0
CAi(4.5)
4.2 Recovery Blocks
In a recovery block, the redundant components are executed sequentially. A comput-
ing element is run and an acceptance test or assertion check is applied to the result.
An alternative implementation is invoked only if the output fails the acceptance test.
There can be many redundant services lined up, each of which may be executed only
if all the services prior to it have failed the assertion test.
Recover block is used when the user has an order of preference amongst the various
services. The primary service is the choicest of all the redundant implementations
and thus is invoked first. A recovery block always costs less than an equivalent NVP
implementation with same services, assuming the costs of the assertion checker and
the voter to be comparable.
In our case, the redundant programs (A1, A2, . . . , An) in a recovery block as well
as the assertion checker (AC) are implemented as web services. Again, the framework
assumes as input the values of (R, T, C) for each of these web services.
4.2.1 WS-BPEL Implementation
All invocations of redundant web services along with the various calls made to the
assertion checker (after execution of each Ai) are in a 〈sequence〉. The alternative
implementation are conditionally invoked inside 〈if〉 activities if the implementations
prior in sequence have either failed to respond (error status set by an attached catch)
or failed the assertion test.
4.2. RECOVERY BLOCKS 59
4.2.2 QoS Formulation
In a recovery block, a service Ai is said to be successful when it returns successfully
and its output is passed by the assertion checker. Thus, the conditional probability
that a service succeeds given it starts execution may be written as:
P (Ai|StartAi) = RAi
×RAC
Since, a service in a recovery block may only start if preceding activity failed
after being invoked. The probability of start of a service Ai is given by the following
recurrence:
P (StartA1) = 1
P (StartAi) = P (StartAi−1
)× P ( ¯Ai−1|StartAi−1) if i > 1 (4.6)
where, P ( ¯Ai−1|StartAi−1) = 1− P (Ai−1|StartAi−1
)
Now, the probability of success of a service may be given as:
P (Ai) = P (Ai|StartAi)× P (StartAi
)
Finally, since the events of success of the redundant services are mutually exclusive,
we can write:
RRB = P (A1 ∩ A2 ∩ . . . ∩ An)
=n∑
i=0
P (Ai) (4.7)
Both Response Time and cost of a recovery block construct is estimated as a
weighted sum of the response times/costs of the several units of execution (including
time taken by the assertion checker in each case), the weights being the probabilities
of execution for the units, P(Start) (given by Equation 4.6 However, the time/cost
4.3. RETURN FASTEST RESPONSE 60
for assertion checker is incorporated only in case the service returns.
TRB =n∑
i=0
P (startAi)× (TAi
+ RAi× TAC) (4.8)
CRB =n∑
i=0
P (startAi)× (CAi
+ RAi× CAC) (4.9)
4.3 Return Fastest Response
The Return Fastest Response construct primarily aims to improve the performance
levels of a web service. All the redundant services are executed in parallel and the
first response obtained is chosen as the result of the FT-construct. Such a construct
is especially helpful if the redundant programs have comparable reliabilities and per-
formance is crucial.
4.3.1 WS-BPEL Implementation
The WS-BPEL implementation of this construct is the same as that proposed in
[17]. The set of redundant web services are invoked in parallel in a 〈flow〉 activity.
However, a 〈flow〉 activity completes on the completion of all the activities nested
inside it which will not serve our purpose. Thus, on completion of execution of one
activity we copy its result as output and forcibly terminate the 〈flow〉 activity to
stop all other executions of redundant services by throwing a fault that is caught by a
fault handler of the enclosing scope. These faults are simply ignored within the fault
handlers by placing an empty activity in the catch block.
4.3.2 QoS Formulation
In any invocation of a Return Fastest Response (RFR) block, the service that returns
within minimum time gets counted. Thus, in order to compute the reliability of such
a block, we require the probability that a service takes minimum time and happens
to be the first to return. The probability, P (FirstAi) that a web service Ai returns
4.4. DEADLINE MECHANISM 61
the first response in an execution of the RFR block is written as:
P (FirstAi) = P (TAi
= Min{TA1 , TA2 , . . . , TAn}) (4.10)
The reliability of the RFR block may be then computed as a weighted sum of
reliabilities, RAi, of all the constituent services.
RRFR =n∑
i=0
P (FirstAi)×RAi
(4.11)
Time taken by the RFR block is simply the minimum of the response times of all
services.
TRFR = Min∀i{TAi} (4.12)
Cost of the RFR block is the sum of costs of all services in it.
CRFR =n∑
i=0
CAi(4.13)
Note that time in our QoS model is represented as random variables and mini-
mum of a set of random variables is obtained through simulation. In Equation 4.10
and Equation 4.12 P (FirstAi) and Min{TAi
} are estimated by simulating the time
quantities as normally distributed random variables.
4.4 Deadline Mechanism
In case of time critical applications, a designer may want to impose hard deadlines for
completion of certain activities within the workflow. Deadline mechanisms support
setting deadlines for completion of tasks and provision forking off redundant services
for a task if a primary service does not complete within some specified length of time.
In our model, the user sets a hard deadline for completion of a task. If a output is
to be returned from the deadline mechanism block, then one of the constituent services
must return within the specified hard deadline. Moreover, the designer is allowed to
4.4. DEADLINE MECHANISM 62
specify the time instants when the alternate implementations may be invoked if no
response is received from services that have been running.
4.4.1 WS-BPEL implementation
Deadline mechanisms can be incorporated with the help of the event handler construct
available in WS-BPEL. The primary web service is run inside a scope and the alternate
services are placed inside the event handler of the same scope with a timer based alarm
event, 〈onAlarm〉, associated with each alternate implementation. We ensure that
the response is returned as soon as it is received from a constituent service invocation,
in the same manner as in the Return Fastest Response construct. If a service returns
successfully we copy its response to the output and throw a fault that is caught by
an empty fault handler of the enclosing scope. In case as service fails we make the
scope to wait till the deadline is reached with the help of a wait activity inside the
catchAll block attached to the invoke activity for the service.
4.4.2 QoS Formulation
The model would require the hard deadline HD for the process and for each service
Ai in a deadline mechanism (DM) block, its Firing Time TFAiapart from the regular
inputs of (R, T, C). We denote the sum of the firing time and the response time
as T ′ for our purposes. In a similar analysis to that done in case of Return Fastest
Response, for each service in a DM block, we find the probability that it returns the
first response.
P (FirstAi) = P (T ′
Ai= Min{T ′
A1, T ′
A2, . . . , T ′
An} and T ′
Ai< HD) (4.14)
The reliability of the DM block is then computed as a weighted sum of reliabilities,
RAi, of all the constituent services in exactly the same way as in RFR.
RDM =n∑
i=0
P (FirstAi)×RAi
(4.15)
4.4. DEADLINE MECHANISM 63
Time taken by the DM block is the minimum of the sums of response times and firing
times of all services.
TDM = Min∀i{T ′Ai} (4.16)
For cost estimation in deadline mechanism we find for each service the probability
that it is invoked inside the DM block. A service inside a DM block may start if a
successful response has not been generated by other services till the point of its firing.
P (StartAi) = P (TFAi
≥ Min{T ′A1
, T ′A2
, . . . , T ′An
, HD}) (4.17)
Cost of the DM block is a weighted sum of costs of all services in it, the weights
being the probabilities of start of the services.
CDM =n∑
i=0
P (StartAi)× CAi
(4.18)
Chapter 5
Implementation Details
We have implemented the QoS model for WS-BPEL 2.0 processes presented in the
last two chapters in a stand-alone software using Java 1.5. The QoS Calculator built
takes as input the values for reliability, time and cost for the constituent web services
and the various essential control flow parameters of the business process outlined
in Section 3.2.2. Also, for improving QoS through fault tolerant constructs it takes
WSDLs of several redundant web services and web services for voting and assertion
checking. In this chapter, we look at the utility of some of the important modules in
our implementation and describe the interactions that take place between them.
Figure 5.1 shows that the implementation may be organized under two major heads,
namely, BPEL parser and QoS Calculator. We discuss these two modules, explore the
components within them and explain the flow of data in and out of these modules.
5.1 BPEL Parser
The BPEL parsing unit is responsible for parsing the BPEL file and converting the
business process into an internal graph-like representation consisting of nodes which
may be either activities or scopes or handlers. Such a node is the central data structure
in the implementation as QoS computation happens at this level. We track all three
types of dependencies (we can treat them as different classes of directed edges) for
5.1. BPEL PARSER 65
Use r I n t e r f a c e
X M L P a r s e r W S D L P a r s e r
B P E L P a r s e r
A c t i v i t y G r a p h G e n e r a t i o n
D e p e n d e n c y M a n a g e r
B o o l e a nC o n d i t i o n P a r s e r
C r e a t e B P E LP r o j e c t F i l e s
S e r v i c e N o d e G e n e r a t i o n
N V P
R F R D M
R B
Re l iab i l i t y M o d e l e r
R e s p o n s e T i m e Mode le r
C o s t M o d e l e r R a n d o m V a r i a b l e S imu la to r
A c t i v i t y G r a p h a n n o t a t e d w i t h d e p e n d e n c i e sa n d c o n t r o l f l o w p a r a m e t e r s
S e r v i c e N o d e st a g g e d w i t h Q o S p a r a m e t e r s
Q o S C a l c u l a t o r
Fau l t To le ran tB P E L P r o j e c t F i l e s
E s t i m a t e d Q o S f o rO v e r a l l P r o c e s s + A c t i v i t y W i s e Q o S
S o u r c e B P E L P ro j ec t F i l es
C o n t r o l F l o w P a r a m e t e r s
Q o S V a l u e s f o r C o m p o n e n t W S
Figure 5.1: Block Diagram of Implementation
each node in the graph. Thus, the module takes the input BPEL file and produces a
graph structure out of it that clearly shows the dependencies between the activities,
scopes and handlers present in the BPEL process. The invoke nodes in the graph are
specially stored as service nodes and annotated with the values of the QoS parameters
for the web services being called. In case of redundant web services being introduced
they are also represented as service nodes. Further, several service nodes may be
suitably composed to form a fault tolerant structure which is composite service node.
Whilst adding fault tolerant constructs for various constituent web services, the user
is shown a listing of the service nodes already introduced and for each original external
web service he chooses one service node that may be a composite one. The QoS values
are also listed against every service node. Waiting times of incoming messages are
set against the nodes receiving them. Various other inputs (listed in Section 3.2.2)
are also appropriately stored in the data structures maintained for nodes and links.
Figure 5.1 shows the different sub-modules within the system. Here, we discuss
each of them briefly.
5.1. BPEL PARSER 66
(a) XML Parser:We make use of a Xerces implementation (Xerces2 Java Parser
2.9.1) of an XML-DOM parser for all our purposes. The DOM style of parsing
suits use better than SAX parsing because we need to keep the parsed DOM
tree in memory for a great length of time and frequently access widely separated
parts of the document at the same time.
(b) Workflow Graph Generation: Transforming the BPEL process alongwith
other inputs into a workflow data structure that may be easily tapped by the
QoS calculator is the key functionality rendered by the BPEL parsing unit.
The XML-DOM tree produced by the XML parser is traversed in order to build
the workflow graph structure. All activities / links / handlers for which one
would require additional inputs from the user are extracted and fed into the
User Interface module so that the user may be intimated about what all inputs
are to be supplied. For example, the User Interface is provided with operations,
portTypes and partnerLinks(required for uniquely identifying an invoke) for all
invoke activities so that it can seek QoS inputs from the user. The workflow is
generated after all forms of dependencies between nodes have been incorporated
into it.
(c) User Interface: The BPEL file is first loaded and passed onto the XML parser.
The workflow generation module provide a list of fields whose values will be
necessary for QoS computation and the user is required to enter these inputs
through a graphical interface. The inputs are passed back into the workflow
builder so that they may be properly maintained for future use.
(d) Dependency Manager: All dependencies in the BPEL process are properly
classified and maintained against the dependent nodes. Each link gets annotated
by the probability that its transition condition is evaluated to true (this is
obtained as an input).
(e) Boolean Condition Parser: A join condition defined for an activity/scope is
a boolean expression (containing boolean operators such as AND and OR) on
5.2. QOS CALCULATOR 67
incoming links. The expression is parsed from the BPEL file and converted into
a tree where each non-leaf vertex is an operator and leafs contain identifiers for
links. This expression tree is then transformed such that it represents a canon-
ical boolean expression (ORs of ANDs analogous to the sum of products form).
The probability of success of such an expression may be easily evaluated given
the probability of success of the links that are involved in it (See Evaluation of
Join Conditions in Section 3.3).
(f) Service Node Generation: This block provisions generation of BPEL imple-
mentations for each of the four fault tolerant constructs. It also documents how
the various redundant web services are arranged and which are the ones that
will feature in the final BPEL file to be created.
(g) WSDL Parser: WSDLs of the various redundant web services are taken as
input. They are parsed to show the user the various elements present in them
and allow him to select the operations, port types, bindings and addresses to
be used in the fault tolerant constructs.
(h) Creation of BPEL project files: The final service nodes are considered in
the production of the fault tolerant BPEL file. Also all WSDLs and deployment
descriptors are suitably enhanced to generate a BPEL project that is ready to
be deployed. We follow the directory structure laid out by the ActiveBPEL
engine and produce files that may be readily deployed using it.
5.2 QoS Calculator
The QoS calculator implements the various mathematical formulations presented in
the previous two chapters. It may be noted that reliability modeling must be carried
out before response times and costs may be estimated because the latter computations
make use of P (start) and P (success). All values that help in QoS computation viz.
P (start), P (success), ST , ET , PC and Cost are evaluated and stored at each node
in the workflow graph. All QoS computations for the fault tolerant constructs are
5.2. QOS CALCULATOR 68
performed at the service node level. Figure 5.1 also shows a module for performing
simulations to compute the maximum, minimum etc. for a set of random variables
used to represent time values. A random variable is simulated by a set of 100000 data
points having the specified mean and standard deviation.
Chapter 6
Conclusions
A comprehensive QoS model has been presented in this work. The model is capable
of estimating QoS of arbitrarily complex structures that may be written through WS-
BPEL. To the best of our knowledge, no QoS estimation technique exists in literature
for graph based flow languages. As argued in previous chapters, most QoS modeling
frameworks are customized for structured programming languages and thus support
only a handful of workflow patterns. In presence of goto-like links that may extend
from within one structured construct into another, QoS modeling for an activity has
to involve tracking QoS of more activities than just those which are nested within it.
This work should also come as the first attempt that lends QoS determination support
in presence of event driven programming, fault handling and backward recovery.
Unlike some other approaches in literature, our model does not call for transfor-
mation of BPEL processes to formalizations which have ratified QoS determination
frameworks. Instead, it offers a direct approach that is firmly grounded in probability
theory. The model tries to exhaustively cover all aspects of BPEL and can scale very
well in face of increasing complexity in BPEL processes.
The QoS calculator provides values for reliability, response time and cost for each
activity / scope / handler. This feature enables the designer to track the critical
parts of the program more closely. For example, the end times for each activity allows
70
the user to detect the activity that might be a possible performance bottleneck for
the composite process. Again low reliabilities for certain activities may prompt the
application of redundancies and fault tolerance constructs. The designer may choose
to modify parts of the BPEL process workflow (differently organize the control flow or
add/remove fault handlers and compensation handlers etc.) and then check whether
the QoS has improved. The model will aid the integrator to improve upon QoS by
making appropriate changes to the bindings for constituent web services.
The QoS tool also provisions increasing dependability of the web service com-
position through fault tolerant constructs. All fault tolerant constructs have been
implemented in a manner that is compliant with WS-BPEL 2.0 standard. Again, our
work becomes the first to introduce the notion of enforcing hard deadlines through
the deadline mechanism constructs in web services compositions. However, the QoS
computation of a fault tolerant BPEL file cannot be performed in an uniform way
through our QoS model. In order to detect the presence of redundant services inside
a BPEL file will require to track data dependencies in the BPEL file. It may be
noted that our QoS determination model for WS-BPEL only tracks control depen-
dencies. Finding fault tolerance structures inside a BPEL file through static analysis
of the BPEL code remains a challenge and provides scope for future work. Our QoS
tool may be utilized to create highly dependable web service compositions out of
undependable web services.
References
[1] Aalst, W. M. P. V. D., Hofstede, A. H. M. T., Kiepuszewski, B., andBarros, A. P. Workflow Patterns. Distrib. Parallel Databases 14, 1 (2003),5–51.
[2] Aggarwal, R., Verma, K., Miller, J., and Milnor, W. Constraintdriven web service composition in METEOR-S. In SCC ’04: Proceedings of the2004 IEEE International Conference on Services Computing (Washington, DC,USA, 2004), IEEE Computer Society, pp. 23–30.
[3] Amsden, J., Gardner, T., Griffin, C., and Iyengar, S. Draft UML 1.4profile for automated business processes with a mapping to BPEL 1.0, 2004.
[4] Anderson, T., and Kerr, R. Recovery blocks in action: A system supportinghigh reliability. Proceedings of the 2nd international conference on Softwareengineering (1976), 447–457.
[5] Avizienis, A. The N-Version Approach to Fault-Tolerant Software. IEEETrans. Softw. Eng. 11, 12 (1985), 1491–1501.
[6] Avizienis, A., and Chen, L. On the implementation of N-version program-ming for software fault tolerance during execution. Proc. IEEE COMPSAC 77(1977), 149–155.
[7] Baresi, L., and Guinea, S. Towards Dynamic Monitoring of WS-BPELProcesses. Proceedings of the 3rd International Conference on Service OrientedComputing (2005).
[8] Berbner, R., Spahn, M., Repp, N., Heckmann, O., and Steinmetz, R.Heuristics for QoS-aware web service composition. In ICWS ’06: Proceedingsof the IEEE International Conference on Web Services (Washington, DC, USA,2006), IEEE Computer Society, pp. 72–82.
[9] Canfora, G., Penta, M. D., Esposito, R., and Villani, M. L. Anapproach for QoS-aware service composition based on genetic algorithms. InGECCO ’05: Proceedings of the 2005 conference on Genetic and evolutionarycomputation (New York, NY, USA, 2005), ACM, pp. 1069–1075.
[10] Cappiello, C., Pernici, B., and Plebani, P. Quality-agnostic or quality-aware semantic service descriptions?
REFERENCES 72
[11] Cardoso, A. J. S. Quality of Service and Semantic Composition of Workflows.PhD thesis, University of Georgia, Athens, Georgia, 2002.
[12] Chen, L., and Avizienis, A. N-Version Programming: A Fault-ToleranceApproach to Reliability of Software Operatlon. Fault-Tolerant Computing,1995,’Highlights from Twenty-Five Years’., Twenty-Fifth International Sympo-sium on (1995).
[13] Clark, D. D., Shenker, S., and Zhang, L. Supporting real-time applica-tions in an integrated services packet network: Architecture and mechanism. InSIGCOMM (1992), pp. 14–26.
[14] Cruz, R. L. Quality of service guarantees in virtual circuit switched networks.IEEE Journal on Selected Areas in Communications 13, 6 (1995), 1048–1056.
[15] CSENKI, A., Square, N., and London, E. Recovery Block reliabilityanalysis with Failure Clustering. Dependable Computing for Critical Applications(1991).
[16] D’Ambrogio, A., and Bocciarelli, P. A model-driven approach to describeand predict the performance of composite services. In WOSP ’07: Proceedingsof the 6th international workshop on Software and performance (New York, NY,USA, 2007), ACM, pp. 78–89.
[17] Dobson, G. Using WS-BPEL to implement Software Fault Tolerance for WebServices. In EUROMICRO ’06: Proceedings of the 32nd EUROMICRO Con-ference on Software Engineering and Advanced Applications (Washington, DC,USA, 2006), IEEE Computer Society, pp. 126–133.
[18] Dobson, G. Using WS-BPEL to Implement Software Fault Tolerance for WebServices. Proceedings of the 32nd EUROMICRO Conference on Software Engi-neering and Advanced Applications (2006), 126–133.
[19] Dobson, G., Hall, S., and Sommerville, I. Dependable Service En-gineering: A Fault-tolerance based Approach. Submitted to ACM Trans-actions on Software Engineering and Methodology, http://digs. sourceforge.net/papers/2005 tosem ftc. pdf (2005).
[20] Dugan, J., and Lyu, M. System reliability analysis of an N-version program-ming application. Reliability, IEEE Transactions on 43, 4 (1994), 513–519.
[21] Ege, M., Eyler, M., and Karakas, M. Reliability analysis in N-versionprogramming with dependent failures. Euromicro Conference, 2001. Proceedings.27th (2001), 174–181.
[22] Frolund, S., and Koistinen, J. Quality-of-service specification in distributedobject systems. IOP/BCS Distributed Systems Engineering Journal (December1998). to appear.
REFERENCES 73
[23] Gorbenko, A., Kharchenko, V., Popov, P., Romanovsky, A., andBoyarchuk, A. Development of Dependable Web Services out of UndependableWeb Components. School of Computing Science, University of Newcastle uponTyne CS-TR-863 (2004).
[24] G.Rommel. Simplicity Wins: How Germanys Mid-Sized Industrial CompaniesSucceed,. Harvard Business School Press, Boston, 1995.
[25] G.Stalk, and T.M.Hout. Competing Against Time: How Time-Based Com-petition is Reshaping Global Markets. Free Press, New York, 1990.
[26] Hillier, F. S., and Lieberman, G. J. Introduction to Operations Research,7th ed. Mc-Graw Hill, 2002.
[27] Hoyland, A., and Rausand, M. System Reliability Theory: Models andStatistical Methods. John Wiley and Sons, 1994.
[28] Hwang, S.-Y., Wang, H., Tang, J., and Srivastava, J. A probabilisticapproach to modeling and estimating the QoS of web-services-based workflows.Inf. Sci. 177, 23 (2007), 5484–5503.
[29] International Standards Organization. Model for quality assurance, iso9000:1987 ed., 1987.
[30] International Standards Organization. Information Technology - Soft-ware Product Evaluation - Quality Characteristics and Guidelines for their Use,iso/iec is 9126 ed., 1991.
[31] International Telecommunication Union (ITU). Terms and definitionsrelated to quality of service and network performance including dependability,ITU recommendation e.800 ed., 1994.
[32] International Telecommunication Union (ITU). Communications Qual-ity of Service: A framework and definitions, ITU recommendation g.1000 ed.,2001.
[33] Ireson, W., Jr., C., and Moss, R. Y. Handbook of Reliability Engineeringand Management. McGraw Hill, New York, 1996.
[34] Jaeger, M., and Ladner, H. Improving the QoS of WS Compositions Basedon Redundant Services. Next Generation Web Services Practices, 2005. NWeSP2005. International Conference on (2005), 189–194.
[35] Jaeger, M. C., Rojec-Goldmann, G., and Muhl, G. QoS Aggregation forWeb Service Composition using Workflow Patterns. In EDOC ’04: Proceedingsof the Enterprise Distributed Object Computing Conference, Eighth IEEE Inter-national (Washington, DC, USA, 2004), IEEE Computer Society, pp. 149–159.
[36] Jalote, P. Software Design Faults. John Wiley and Sons Ltd, 1994, ch. FaultTolerance in Distributed Systems, pp. 355–396.
REFERENCES 74
[37] Leymann, F. Web Services Flow Language (WSFL 1.0). IBM, May 2001.
[38] Looker, N., and Munro, M. WS-FTM: A Fault Tolerance Mechanism forWeb Services. University of Durham, Technical Report 19 (2005).
[39] Looker, N., and Xu, M. Increasing Web Service Dependability Through Con-sensus Voting. Computer Software and Applications Conference, 2005. COMP-SAC 2005. 29th Annual International 2 (2005).
[40] Ludwig, H. Web services QoS: external SLAs and internal policies or: how dowe deliver what we promise? Web Information Systems Engineering Workshops,2003. Proceedings. Fourth International Conference on (2003), 115–120.
[41] Maximilien, E. M., and Singh, M. P. Conceptual model of web servicereputation. SIGMOD Rec. 31, 4 (2002), 36–41.
[42] Menasce, D. Composing Web Services: A QoS View. IEEE INTERNETCOMPUTING (2004), 88–90.
[43] Menasce, D. A. QoS issues in web services. IEEE Internet Computing 6, 6(2002), 72–75.
[44] Musa, J., Iannino, A., and Okumoto, K. Software reliability: measure-ment, prediction, application. 1987.
[45] Purtilo, J. M., and Jalote, P. An Environment for Developing Fault-Tolerant Software. IEEE Trans. Softw. Eng. 17, 2 (1991), 153–159.
[46] Randell, B. System structure for software fault tolerance. In Proceedings ofthe international conference on Reliable software (New York, NY, USA, 1975),ACM, pp. 437–449.
[47] Randell, B., and Xu, J. The Evolution of the Recovery Block Concept.Software Fault Tolerance (1995), 1–22.
[48] Reiter, T. Transformation of web service specification languages into UMLactivity diagrams. Diploma thesis.University of South Australia, 2005.
[49] Rud, D., Schmietendorf, A., and Dumke, R. Performance Modeling ofWS-BPEL-Based Web Service Compositions. Services Computing Workshops,2006. SCW’06. IEEE (2006), 140–147.
[50] Sherchan, W., Loke, S. W., and Krishnaswamy, S. A fuzzy model forreasoning about reputation in web services. In SAC ’06: Proceedings of the 2006ACM symposium on Applied computing (New York, NY, USA, 2006), ACM,pp. 1886–1892.
[51] Tartanoglu, F., Issarny, V., Romanovsky, A., and Levy, N. Coordi-nated Forward Error Recovery for Composite Web Services. Proceeding of the22nd International Symposium on Reliable Dependable Systems, SRDS 2003 .
REFERENCES 75
[52] Thatte, S. XLANG: Web Services for Business Process Design. Microsoft,2001.
[53] Thatte, S. BPEL4WS: Business Process Execution Language for Web ServicesVersion 1.1. BEA, IBM, Microsoft, SAP and Siebel, May 2003.
[54] Tian, M., Gramm, A., Naumowicz, T., Ritter, H., and Freie, J. Aconcept for QoS integration in Web services. Web Information Systems Engineer-ing Workshops, 2003. Proceedings. Fourth International Conference on (2003),149–155.
[55] Tian, M., Gramm, A., Ritter, H., and Schiller, J. Efficient selectionand monitoring of QoS-aware web services with the WS-QoS framework. In WI’04: Proceedings of the 2004 IEEE/WIC/ACM International Conference on WebIntelligence (Washington, DC, USA, 2004), IEEE Computer Society, pp. 152–158.
[56] Tian, M., Gramm, A., Ritter, H., and Schiller, J. Efficient Selectionand Monitoring of QoS-Aware Web Services with the WS-QoS Framework. WebIntelligence, 2004. WI 2004. Proceedings. IEEE/WIC/ACM International Con-ference on (2004), 152–158.
[57] van der Aalst, W. Don’t go with the flow: Web services composition stan-dards exposed, 2003.
[58] Wang, G., Wang, C., Chen, A., Wang, H., Fung, C., Uczekaj, S.,Chen, Y.-L., Guthmiller, W. G., and Lee, J. Service level managementusing QoS monitoring, diagnostics, and adaptation for networked enterprise sys-tems. In EDOC ’05: Proceedings of the Ninth IEEE International EDOC En-terprise Computing Conference (Washington, DC, USA, 2005), IEEE ComputerSociety, pp. 239–250.
[59] Wohed, P., van der Aalst, W. M., Dumas, M., and ter Hofstede,A. H. Analysis of web services composition languages: The Case of BPEL4WS,2003.
[60] Wu, B., Chi, C.-H., and Xu, S. Service Selection Model Based on QoSReference Vector. IEEE Congress on Services (2007), 270–277.
[61] Zeng, L., Benatallah, B., Ngu, A. H., Dumas, M., Kalagnanam, J.,and Chang, H. QoS-aware middleware for web services composition. IEEETrans. Softw. Eng. 30, 5 (2004), 311–327.
[62] Zeng, L., Lei, H., and Chang, H. Monitoring the QoS for web services.Service-Oriented Computing - ICSOC 2007 (2007), 132–144.
[63] Zhou, C., Chia, L., and Lee, B. DAML-QoS ontology for Web services. WebServices, 2004. Proceedings. IEEE International Conference on (2004), 472–479.
REFERENCES 76
[64] Zinky, J. A., Bakken, D. E., and Schantz, R. E. Architectural supportfor quality of service for CORBA objects. Theory and Practice of Object Systems3, 1 (1997).