A relaxable service selection algorithm for QoS-based web service composition
Chia-Feng Lin
a, Ruey-Kai Sheu
b,⇑, Yue-Shan Chang
c, Shyan-Ming Yuan
aa
Department of Computer Science, National Chiao Tung University, Hsinchu, Taiwan
b
Department of Computer Science, Tunghai University, Taichung, Taiwan
c
Department of Computer Science and Information Engineering, National Taipei University, Taipei, Taiwan
a r t i c l e
i n f o
Article history:
Received 2 February 2010
Received in revised form 30 May 2011 Accepted 29 June 2011
Available online 13 July 2011 Keywords: Web service Quality of service Service composition Service selection
a b s t r a c t
Context: Web services are emerging technologies that enable application to application communication and reuse of autonomous services over Web. Composition of web services is a concept of integrating indi-vidual web services to conduct complex business transactions based on functionality and performance constraints
Objective: To satisfy user requirements, technologies of Quality of service (QoS)-based web service com-position (QWSC) are widely used to build complex applications by discovering the best-fit web services in term of QoS.
Method: In this paper, a QoS-based service selection (RQSS) algorithm is proposed to help composite web application development by discovering feasible web services based on functionalities and QoS criteria of user requirements. The RQSS recommends prospective service candidates to users by relaxing QoS con-straints if no suitable or available web service could exactly fulfill user requirements.
Results: A generic framework is implemented to demonstrate the feasibility and performance of RQSS by adapting WS-BPEL standards, and can be reused for QoS-based web composition applications. Conclusion: The experimental results show that the RQSS algorithm indeed performs well and increases the system availability and reliability.
2011 Elsevier B.V. All rights reserved.
1. Introduction
Web services are considered as self-contained, self-describing, modular applications that can be published, located, and invoked across the web[10]. An increasing amount of companies and orga-nizations only implement their core business and outsource other services over Internet. If no single web service can satisfy the func-tionality of user needs, there should be a possibility to combine existing services together in order to fulfill the user requirements. If the implementation of a web service’s business logic involves the invocation of other web services, it is necessary to combine the functionality of several web services. The process of developing such composite service is called service composition. Composite services are recursively defined as an aggregation of elementary and composite services.
With the increasing number of web services providing similar functionalities, the QoS is becoming an important criterion of selection of the best available service. There are two major prob-lems in using QoS for service discovery, and they are the specifica-tion and storage of the QoS informaspecifica-tion, and the specificaspecifica-tion of the customer’s requirements [31]. Some researchers used the
linear integer programming (LIP) model to solve the service selec-tion problem by maximizing the utility value which is a weighted sum of user-defined QoS attributes[4,11,32]. LIP-based approaches can be used for service matching, ranking and selection. However, the computation complexity and cost of the LIP solution will in-crease exponentially with the growth of the size of web services. Some studies tried to extend the multi-dimension multi-choice 0–1 knapsack problem (MMKP) with heuristic algorithms to get near-optimal solutions for service selection problems [8,21,31]. Although the heuristic algorithms improve the efficiency of service selection, they might fail if no feasible service exists. Recently, some researchers proposed the similarity-based web service dis-covery mechanisms by calculating the semantic similarity, and tried to maximize the number of candidate services to reduce the possibility of system failure[15,18]. However, the similarity-based solution might be not feasible for engineering or manufacturing industries because the accuracy of engineering application seman-tics should be very precise. In addition, the research in[32]was proposing a QoS-aware fault tolerant middleware. They aim at advancing the current state-of-the-art in fault tolerance technolo-gies for dependable service composition.
Obviously, most of existing approaches were endeavoring to look for suitable services for composing the business logic of appli-cation. They either did not aim at the possible failure of service selection or did make too many constraints to find efficiently 0950-5849/$ - see front matter 2011 Elsevier B.V. All rights reserved.
doi:10.1016/j.infsof.2011.06.010
⇑Corresponding author.
E-mail addresses:cflin@cs.nctu.edu.tw(C.-F. Lin),rickysheu@thu.edu.tw(R.-K. Sheu),ysc@mail.ntpu.edu.tw(Y.-S. Chang),smyuan@cs.nctu.edu.tw(S.-M. Yuan).
Contents lists available atScienceDirect
Information and Software Technology
j o u r n a l h o m e p a g e : w w w . e l s e v i e r . c o m / l o c a t e / i n f s o fsuitable services. Undoubtedly, stringent constraints might close to infeasibility solution. It is desirable to minimize the frequency of failure in finding a feasible solution, if one exists. Such problem can be viewed as a maximum feasible subsystem problem (MaxFS)1
which is a NP-hard problem.2The MaxFS is that wishes to find a
fea-sible subsystem containing a maximum number of inequalities. There are so far various heuristic approaches[36–39]have been pro-posed to find the approximation solution. Recently, some researches have shown that the relaxation method[36,39]is an admirable heu-ristic to approximate the solution of MaxFS.
Most of approaches to service selection do not handle the situ-ation when there is no feasible solution to fulfill QoS constraints set by users. Also, some approaches may fail in finding the feasible solution if ones exist. To improve these problems, in the paper, we propose a relaxable QoS-based service selection algorithm (RQSS). The term of ‘‘relaxable’’ means that RQSS will release or relax the degree of constraints heuristically. The idea of proposed algorithm is to find a solution with smaller amount of constraints violation if there is no a feasible solution to fulfill the QoS constraints. Also, if no feasible can be found, a recommended solution is presented to the user by relaxing the QoS constraints. In other words, some QoS constraints have to be relaxed to find such a solution.
From the point of view of users, there may be some QoS con-straints which cannot be relaxed. Therefore, users can specify each QoS constraint as either a relaxable constraints or a non-relaxable constraint. According to the relaxability of QoS constraints, the relaxable QoS constraints are relaxed to find a solution which can fulfill the non-relaxable QoS constraints if no feasible solution exists. Note that it is expected that the amount of relaxation of QoS constraints is as small as possible. Moreover, the proposed selec-tion algorithm is a heuristic algorithm that is not an exhaustive search. We expect the algorithm can lower the rate of failure in finding a feasible solution when the heuristic is used.
We adopt the idea of a heuristic algorithm proposed in[17], which is to find the feasible solution for MMKP, to design the relax-able QoS-based service selection algorithm. In addition, a generic framework is proposed to simulate the feasibility and performance of RQSS. The results of the simulation experiments show that the idea of relaxing QoS criteria in RQSS performs well with lower fail-ure rate especially when no web service could exactly match users’ QoS constraints.
The remainder of the paper is organised as follows. Section2
surveys some related work including web service standards, web service composition techniques, and other QoS constraint web ser-vice composition research; and briefly introduce the concept and notations used in the paper. Section3describes the model of pro-posed RQSS QoS web service composition, including basic defini-tions, constraints and functions. Section 4 depicts the design of relaxable QoS-based service selection algorithm, its complexity analysis, and QoS-based Web Service Composition Framework. Section 5presents the evaluation setup, experiment results and analysis. In addition, we also make a comparison with other similar approaches and give a discussion. And finally, the conclusions and future work are given in Section6.
2. Background 2.1. Related work
It is well-known that there are many industrial standards have been developed for service oriented computing and web service
composition. The WS-Policy standard3can be used to specify
poli-cies expressing non-functional requirements for Web Services (WS), while WS-QoS is for specifying provided and required Web Services QoS[40]. And the Web Services flow specification languages like WS-BPEL4(Web service Business Process Execution Language)
provides a programming-language like constructs as well as graph-based links that represent additional ordering constraints on the constructs, while the WSCI5is to describe the messages exchanging
order between services. In addition, semantic annotations have been widely discussed in the Semantic Web community where precondi-tions and the effects of services are explicitly declared in the Re-source Description Format (RDF).
Web service composition is a very complex and challenging task beyond human capability. Many researches tried to simplify the integration of web services by defining several standard interfaces, and proposed many models and approaches for static or dynamic service composition [22,23,26–28]. Dustdar et al. suggested six major issues that have a large impact on service composition and many researches took them into consideration seriously[6]. They are coordination, transaction, context, conversation modeling, exe-cution monitoring, and infrastructure of web services. Besides, Dustdar et al. categorized five composition strategies which is used by most researches [6]. These approaches are static/dynamic mechanism, model driven, declarative, automated/manual, and context based web service discovery and composition.
Alonso et al. summarized six different dimensions of service composition models which make different assumptions of what a component is and what it is not[1]. For instance, an orchestration model defines abstractions and languages to define the order in which and the conditions under which web services are invoked. Most of these models focus on the matching, selection and execu-tion of web services to meet funcexecu-tional requirements. As for non-functional constraints or Quality of Service (QoS) of a composite web service, such as latency, throughput, reliability, availability, cost, etc. are out of the major scopes of their researches.
Alrifai and Risse[33]proposed a solution that combined global optimization with local selection techniques to benefit from the advantages of both worlds. The proposed solution consists of two steps: first, they used mixed integer programming (MIP) to find the optimal decomposition of global QoS constraints into local con-straints. Second, they used distributed local selection to find the best web services that satisfy these local constraints. But they do not take possible failure in finding a feasible solution into consideration.
Canfora et al. [34] proposed a QoS-aware composite service binding approach based on Genetic Algorithms (GAs). The main advantage in the use of GAs is the possibility to apply the approach in presence of arbitrary, non-linear QoS aggregation formulae, whereas traditional approaches, such as linear integer program-ming, require linearization. Obviously, they also do not take possi-ble failure in finding a feasipossi-ble solution into consideration.
Yu et al.[21]modeled web services selection with end-to-end QoS constraints in two ways. The first model is the combinatorial model that defines the problem as a multidimension multichoice knapsack problem (MMKP). The second model is the graph model that defines the problem as a multiconstrained optimal path (MCOP) problem. Based on both models, they specified a user-defined utility function of some system parameters to optimize application-specific objectives. In addition, Yu et al. also proposed heuristic algorithms to find near-optimal solutions in polynomial time which is more suitable for making runtime decisions. There-fore, they also do not take possible failure in finding a feasible solu-tion into considerasolu-tion.
1
MaxFS problem: Given an infeasible linear system AX P b, find a Maximum Feasible Subsystem, i.e., a feasible subsystem containing a maximum number of inequalities. 2 http://risorse.dei.polimi.it/maxfs/. 3http://www.w3.org/TR/ws-policy/. 4 http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsbpel. 5 http://www.w3.org/TR/wsci/.
Pastrana et al.[35] presented a methodology for Web Service composition and coordination based on connectors which are de-fined by Web Service client and automatically generated by the COMPOSITOR tool authors have developed. Connectors use con-tracts to express the non-functional requirements and the behavior desired by the client of a service, such as QoS (Quality of Service) features. The work is mainly aiming at proposing a framework for QoS-enabled and self-adaptive connectors for Web Services composition and coordination. Adaption[5,25,35]is also an impor-tant feature for web service composition. But, they do not find out the feasible solution for composition.
Ko et al.[19]addressed web service composition planning from the aspect of QoS and proposed an efficient QoS-oriented web ser-vice composition algorithm. This algorithm is characterized as a hybrid meta-heuristics that combines tabu search and simulated annealing and designed not only to find constraint–compliant composition plans but also to reduce the computational burden re-quired for searching the plans. The algorithm takes a composition schema, six QoS permissible values, and their weights as the inputs and generates a composition plan that satisfies the client’s QoS requirement as the output. In addition, under a given composition plan, the algorithm creates a better neighbor plan by modifying a restricted number of decision variables. Obviously, it does not deal with finding feasible solution while possible failure.
Liu et al.[29]proposed a QoS-based dynamic web service com-position approach. In the approach, they also model web service selection using multi-choice knapsack problem, and divide the ser-vice selection problems into two classes to facilitate the serser-vice selection process. The mathematical models are established for each class respectively. Accordingly, the heuristic selection algo-rithms are proposed to solve the models.
In summary, most of existing approaches were endeavoring to look for suitable services for composing the business logic of appli-cation. These approaches do not handle the situation when there is no feasible solution to fulfill QoS constraints. It is an important is-sue for finding a solution with smaller amount of constraints vio-lation if there is no a feasible solution to fulfill the QoS constraints. Therefore, to get higher system reliability and avail-ability, a relaxable QoS-based service selection algorithm is pro-posed in the paper.
2.2. Preliminary
Web service interactions can be described in two ways: execut-able business processes, and abstract business processes. Execut-able business processes model actual behavior of a participant in a business interaction. WS-BPEL is meant to be used to model the behavior of both executable and abstract processes. WS-BPEL provides a language for the specification of executable and abstract business processes[13]. Building composite web services are sim-ilar to the construction of a workflow for executable business pro-cesses [7]. For the emulation of RQSS, the WS-BPEL is used to describe the control flow of abstract processes. In order to clearly identify the concept, we first define the abstract process.
Definition 1 (Abstract Process). An abstract process AP can be represented by a DAG, so it can be defined as a tuple of (GAP, ASAP).
That is AP = (GAP, ASAP), where
GAP= (V, E) is a directed and acyclic graph, whereV = {
v
1, . . . ,v
n}represents a set of activities. Each vertex in V is a tuple
v
= (ATv, Av), where– ATv is the activity type of the vertex where ATV2
{Process-Start, ProcessEnd, IF{Process-Start, IFEnd, Flow{Process-Start, FlowEnd, Loop-Start, AbstractService}.
– Av is the activity associated with the vertex.
E V V is a set of directed edges indicating the transition among two activities.
ASAP= {as1, . . . , asn} is for a set of abstract services involved in
the abstract process where n is the number of the abstract services.
In an AP, there are five basic patterns of relationship are used to integrate individual services for business processes construction, and they are ‘‘sequence’’, ‘‘if’’, ‘‘flow’’, ‘‘while’’ and ‘‘repeatUntil’’. The five relations will be used in an abstract process to construct the fundamental control flow structures of business workflows, including ‘‘sequential structure’’, ‘‘parallel structure’’, ‘‘conditional structure’’ and ‘‘loop structure’’. All user requirements will be described by abstract services of an abstract process using the WS-BPEL. In addition, a loopNumber attribute is defined as the upper bound for the loop number of iterations. It determines the expected maximum number of iteration used to unfold the loop when calculating the QoS of loop structures. By using the ba-sic notations of patterns, an abstract process specification can be represented by a directed acyclic graph (DAG).
An abstract process could be treated as a set of activities which consist of a start point, an end point, and other intermediate activ-ities which are represented by the ProcessStart, ProcessEnd and other activity notations, respectively. The abstract process can orchestrate the set of abstract services in a precedence order. Accordingly, the sequences of activities are connected by the direc-ted edges based on the order of them and conduct a DAG state dia-gram. The directed edges indicate the precedence relationship between two activities. Since ‘‘if’’, ‘‘flow’’, ‘‘repeatUntil’’ and ‘‘while’’ activities are all the non-loop structures, each of them can be represented by an entry point and an exit point. The IFStart notation is used to connect with the branches of possible condi-tions of an ‘‘if’’ activity, and an IFEnd notation is used for the con-vergence of the activity. For a ‘‘flow’’ activity, a FlowStart notation is used to connect each of the activities involved in it and these activities will be converge on a FlowEnd activity eventually. For a ‘‘repeatUntil’’ or a ‘‘while’’ activities, a LoopStart activity and a Loo-pEnd activity can be used to represent the activities which need to be repeated several times.
In addition, an abstract service describes the functionalities but not the execution details of a web service. The functionalities of-fered by a web service are usually performed by its provided oper-ations. Thus, the definition of an abstract service should include the name, required operations, inputs, and outputs.
Definition 2 (Abstract Service). An abstract AS is a tuple of (N, OT, I, O), where
N is the name of the abstract service.
OT is the type of required operation in terms of ontology concepts.
I = {I1, . . . , Im} is a set of inputs of required operations, where m is
the number of inputs. Ii= (IN, IT), where i = 1, . . . , m. IN is the
name of input. IT is the input type in terms of ontology concepts.
O = {O1, . . . , On} is a set of outputs of the required operations,
where n is the number of outputs. Oi= (ON, OT), where
i = 1, . . . , n, and ON is the name of output. OT is the output type in terms of ontology concepts.
The functional characteristics of an abstract service contain the inputs, outputs and the classification type representing an ontology concept. The operation type stands for the classification type of a web service operation. A WSDL example of an abstract service in the abstract process specification is shown inTable 1.
USWeatherForecast, USAddress, and FiveDayWeatherInformation are operation types which will be used for ontology mapping or matching during the service selection process. The mapping and matching of ontology concepts are out of the scope of this paper.
Definition 3 (Selection Plan). A selection plan SP of an abstract process AP is a set of (asi, opi) pairs. That is SP = {(as1, op1), . . . ,
(asn, opn)}. For each pair (asi, opi) in SP, the service operation opi
provides the required function of an abstract service asi, where
i = 1, . . . , n.
The selection plan describes a combination of operations of-fered by concrete services for an abstract process. It can be viewed as a service assignment for the abstract process.
3. The RQSS QoS model
This section articulates the QoS model that is the basis of the RQSS algorithm. Here describe the QoS criteria, aggregation func-tions, and constraints are described.
3.1. QoS criteria
QoS criteria are used to differentiate the web services providing the same functionality during the service selection process of QWSC. Each operation of a web service will be associated with a set of QoS criteria. To reduce the complexity, the RQSS uses the generic QoS criteria as the basis for further discussions which are also used in[4,11,16].
Execution Time ET(op): The execution time of the service oper-ation op is a time interval between when the op is invoked and when the op finished.
Reliability Rel(op): The reliability of the service operation op is the probability that a request is correctly responded within the expected time.
Availability A(op): The availability of the service operation op is the probability that the operation is accessible during a period of time.
Reputation Rep(op): The reputation of the service operationop is the measurement of trustworthiness. It is an integer range from 1 to 10. The higher the value, the better the reputation is. Price P(op): The price of the service operationop is the cost
which a service requester has to pay to the service provider of op.
3.2. QoS aggregation functions
To calculate the quality of a web service, aggregation functions are defined inTable 2for each QoS criterion. Piis the probability
that an abstract service asiwill be executed for a conditional
struc-ture. The probability can be evaluated from statistical execution logs. If an abstract process has never been executed before, the probability will be assumed to be uniform distribution (pi= 1/n).
As defined above, an abstract process is a set of abstract services. The service selection would be the key for the construction of an abstract process from composite services.
3.3. QoS constraints
The QoS constraints represent the minimum thresholds which an abstract process has to reach to. For an abstract process, a QoS constraint can be identified by one of the QoS criteria which are ‘‘Execution Time’’, ‘‘Reliability’’, ‘‘Availability’’, ‘‘Reputation’’ and ‘‘Price’’. Besides, a relaxability of QoS constraints is introduced to specify whether a QoS constraint is relaxable or not. During the pro-cess of service selection, relaxable QoS constraints could be relaxed when no service can fulfill the requirements of QoS constraints. Definition 4 (QoS constraint). A QoS constraint is a tuple QC = (N, V, R) where
N is the name of the QoS criterion associated with QC. V is the value of the QoS criterion associated with QC desired to
be satisfied. It is a real number.
R is the relaxability of the QoS constraint which indicates whether the QoS constraint is relaxable or not. It is a Boolean value.
4. The relaxable QoS-based service selection algorithm
The service selection process of a QWSC takes abstract processes as inputs, and then comes out a set of qualified service operations supported by composite web services. That is, for an abstract pro-cess AP containing n abstract services, where ASAP = {as1, . . . , asn},
there will be a set of qualified service operation groups OP = {OP1, . . . , OPn} associated with each asi, where.
Each abstract service asi(i = 1, . . . , n) has licandidates of service
operations. OPi¼ fopi1; . . . ;opilig is a service operation group of asi.
Each candidate operation opij(j = 1, . . . , li) 2 OPiis associated with
a QoS vector (ET(opij), Rel(opij), A(opij), Rep(opij), P(opij)).
The QoS constraints of the AP defined by users are QC = {qcET,
qcRel, qcA, qcRep, qcP}.
Based on the above analysis, a service selection process could be formulated as Eq.(1).
Find X ¼ ðx1; . . . ;xnÞ;
8
xi2 f1; . . . ; lig; i ¼ 1; . . . ; n such thatETðfðas1;op1x1Þ; . . . ; ðasn;opnxnÞg; APÞ 6 qc
ET;
Relðfðas1;op1x1Þ; . . . ; ðasn;opnxnÞg; APÞ P qc
Rel;
Aðfðas1;op1x1Þ; . . . ; ðasn;opnxnÞg; APÞ P qc
A;
Repðfðas1;op1x1Þ; . . . ; ðasn;opnxnÞg; APÞ P qc
Rep;
Pðfðas1;op1x1Þ; . . . ; ðasn;opnxnÞg; APÞ P qc
Rep;
ð1Þ
Table 1
A WSDL example of an abstract service.
<abstractService name=‘‘example’’ operationType=‘‘USWeatherForecast’’> < inputs>
< input name=‘‘input’’ inputType=‘‘USAddress’’> </inputs>
< outputs>
< output name=‘‘output’’ outputType=‘‘FiveDayWeatherInformation’’> </outputs>
</abstractService>
Table 2
Aggregation functions for QoS criteria.
Sequence Conditional Parallel Execution Time Pn
i¼1ETðopiÞ
Pn
i¼1ETðopiÞ pi Maxni¼1ETðopiÞ
Reliability Qn i¼1RelðopiÞ
Pn
i¼1RelðopiÞ pi Qni¼1RelðopiÞ
Availability Qn i¼1AðopiÞ Pn i¼1AðopiÞ pi Qn i¼1AðopiÞ Reputation 1 n Pn i¼1RepðopiÞ 1n Pn i¼1RepðopiÞ 1n Pn i¼1RepðopiÞ Price Pn i¼1PðopiÞ Pn i¼1PðopiÞ pi Pn i¼1PðopiÞ
X is a vector representing the feasible solution containing the indi-ces of selected service operations for every abstract service in AP. It can be viewed as a selection plan of AP which can satisfy all the QoS constraints. It is expected to find a selection plan which can satisfy the QoS constraints based on a set of QoS criteria of an abstract pro-cess. Accordingly, Eq.(1)can be used to model the service selection problem for a QWSC solution. In the following section, the RQSS algorithm is proposed for solving the service selection problem for QWSC.
4.1. The design of RQSS algorithms
The original motivation of RQSS is to find out a feasible solution which minimizes the differences between selected web service operations with user-defined requirements when no web service exactly matching the QoS constraints. In other words, by adding user-defined relaxable QoS constraints to RQSS, some constraints could be relaxed to find alternative services if none of the services can match the QoS criteria. It is not users’ intention to release the QoS constraints, so the QoS relaxing process can only be triggered when no feasible solution could be found. And, it is expected that the degrees of relaxation of QoS constraints are as small as better. Similar to the algorithm of multi-dimension multi-choice 0–1 knapsack problem (MMKP) proposed in[17,21], the proposed algo-rithm assigns a value to every candidate item by evaluating the number of resource consumptions. In RQSS, the value of resource consumption is assigned to each item based on the degree of the constraint violation. Based on the value, the RQSS tries to find an initial solution by selecting an item from each group with the low-est value. If no feasible initial solution could be found, the one with the second lowest value will be selected from each group recur-sively. However, to increase the service availability or reduce the rate of failure, a new item is practically considered to be selected only if it has lower value and less number of violated constraints. It is one of the major purposes of the RQSS algorithm to balance the resource consumption and service availability.
To simplify the algorithm design, based on the Eq.(1), all of the QoS constraints inequalities are transformed into less than-or-equal inthan-or-equalities before performing the RQSS algorithm. The values of reliability, availability and reputation of each service operation and the values of the constraints on these QoS criteria are set to the reciprocals. Hence, all of the values of QoS constraints would be the upper bounds for all QoS criteria. Let QCnr=
{qc1,. . ., qcr} be the set of non-relaxable QoS constraints set by
the user. The details of the RQSS algorithm are shown in
Tables 3–5.
There are three major steps in the RQSS algorithm. The first step of RQSS is to sort the service operations for each service operation group and service operation groups based on the normalized qual-ity value (nqv). The normalized qualqual-ity value is calculated for each service operation opijin the each service operation group OPiusing
the following equation: nq
v
ij ¼ ffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffi ETðopijÞ qcET 2 þ RelðopijÞ qcRel 2 þ AðopijÞ qcA 2 þ RepðopijÞ qcRep 2 þ PðopijÞ qcP 2 s ð2Þ We use the normalized quality value as a heuristic to select service operations. For service operations opi1and opi2, the heuristic impliesthat the probability of service operation opi1may be greater than
the one of opi2if nqvi1> nqvi2. Therefore, the candidate service
oper-ations in each service operation group OPiare sorted based on the
normalized quality value. All OPiof abstract services are also sorted
based on their lowest normalized quality values of the service operations.
In the second step, a naı¨ve service selection (NSS) is performed to select the service operations with lower normalized quality val-ues. As depicted inTable 4, the solution is initialized by selecting the service operation with the lowest normalized quality value from each group. Then, the service selection process is applied repeatedly to every operation group based on their order. Once all the operations are examined and selected, i.e. no feasible solu-tion is found; the naı¨ve service selecsolu-tion procedure stops, and RQSS goes to the third step.
In the final step of RQSS, a heuristic is proposed to find a feasible solution by the average violated quality value (avqv), as shown in
Table 5. The avgv represents the degree of the constraint violation Table 3
Relaxable QoS-based service selection algorithm. Algorithm RQSS:
// n: the total number of abstract services of a abstract process // li: the number of candidate service operations in the service operation
group i
// nqvij: normalized quality value of candidate service operation j in the
service // operation group i
// Xold: old solution vector used to record the solution which satisfies all of
QoS
// constraints in the step 3
// Xnrold: old solution vector used to record the solution which satisfies
non-relaxable
// QoS constraints in step 3
// QCnr: the set of non-relaxable QoS constraints
1. Service operation sorting
1.1. Calculate the normalized quality value for every candidate service operation "i = 1, . . . , n, j = 1, . . . , li, calculate nqvij.
1.2. Sort the candidate service operations in non-descending order in each service group according to nqvij
1.3. Sort the service operation groups in non-descending order according to the normalized quality values of the service operations with the lowest normalized quality value and go to step 2.
2. Naı¨ve service selection 2.1. Perform the NSS algorithm
2.2. if no feasible solution can be found in the step 2.1 then go to step 3 3. Service selection with QoS constraints relaxation
3.1. Perform the SS_QCR algorithm
3.2. if no feasible solution could be found in step 3.1 then if jQCnr
j = 0 then return the solution Xoldelse return the solution Xnrold.
Table 4
Naı¨ve service selection algorithm. Algorithm NSS:
// n: the total number of abstract services of an abstract process // li: the number of candidate service operations in the candidate service
// operation group i
// isFeasible(X): a function which returns true if the solution X satisfies the // constraints and false otherwise
// X: current solution vector
// min_cso: the minimum number of candidate service operations among all // service operation groups
X the service operation of the lowest normalized quality value from each group
if isFeasible(X) then
A feasible solution is found and return X endif
j 2 repeat
for i 1 to n do
Choose the service operation j from service operation group i Update solution X
if isFeasible(X) then
a feasible solution is found and return X endif
next j j + 1
of a solution. The reduction of the average violated quality value for all QoS constraints is applied here to find a feasible solution or a solution that satisfies non-relaxable constraints if no feasible one could be found, respectively. Two solutions, Xoldand Xnrold, will
be generated to record the solution fulfilling all of QoS constraints and the one of satisfying non-relaxable QoS constraints, respec-tively. Similar to the NSS algorithm, in this step, a solution is also initialized by selecting the service operation with the lowest nor-malized quality value from each group. It then goes throughout all the groups to evaluate either a feasible solution exists or avqv of Xoldand avqvnrof Xnroldcan be reduced. If no feasible solution
ex-ists, it switches to next group and performs the same examination process recursively. The average violated quality value of Xoldis
cal-culated using Eq.(3), a
v
qv
¼1k Xk
i¼1
Qiðfðas1;op1x1Þ; . . . ; ðasn;opnxnÞg; APÞ
qci
ð3Þ where k represents the total number of the QoS constraints violated, i represents the indexes of the QoS constraints violated by Xoldand
Qi is the QoS aggregation function of the corresponding QoS
criterion.
The average violated quality value of Xold is denoted as
avqvold. In this step, the average violated quality values are used
as a heuristic to select service operations. Given that there are two non-feasible solutions, and they are X1 and X2. The concept
of the heuristic is: if avqv1> avqv2, the probability that X1becomes
a feasible solution may be greater than the one for X2. That is, it
would be better to create a new feasible solution by choosing the one of lower average violated quality value. After identifying Xold,
Vold and calculating the average violated quality value avqvold,
we can create selection plans to find a feasible solution. We denote the new solution as Xnew. If avqvnew< avqvold, then set Xold= Xnew,
avqvold= avqvnew. In the first service operation group, the above
expression will be performed for all service operations, and the se-lected service operation will be changed to the one of the lowest normalized quality value eventually. At the same time, the idea can be also applied to find the solution which satisfies the non-relaxable QoS constraints. There is also an initial solution Xnr
oldwhich is set equal to Xold. The only difference is that the
aver-age violated quality value should be calculated based on non-relax-able QoS constraints and relaxnon-relax-able QoS constraints. The average violated quality value of Xnr
old for non-relaxable QoS constraints
and relaxable QoS constraints are calculated using the following formulas: a
v
qv
nr ¼1s
Xs i¼1 Qiðop1x1; . . . ;opnxn;APÞ qci ð4Þ av
qv
r ¼ 1 jQCjs
X jQCjs j¼1 Qjðop1x1; . . . ;opnxn;APÞ qcj ð5Þ wheres
is the number of the non-relaxable QoS constraints vio-lated, i represents the indexes of the non-relaxable QoS constraints that are violated by Xnroldand j represents the indexes of the relaxable QoS constraints that are violated by Xnrold.As mentioned above, if there is no feasible solution, it is ex-pected to find a solution to fulfill the non-relaxable QoS constraints by relaxing the relaxable QoS constraints. The average violated quality value for non-relaxable QoS constraints is used to match the idea. The proposed algorithm could find a solution that can ful-fill the non-relaxable QoS constraints by reducing the average vio-lated quality value during the selection process. Moreover, if a solution satisfying the non-relaxable QoS constraints is found, an additional examination will be performed to check whether the Table 5
Service Selection Algorithm with QoS Constraints Relaxation. Algorithm SS_QCR:
// n: the total number of abstract services in AP
// li: the number of candidate service operations in the candidate service
operation group i
// isFeasible(X): a function which returns true if the solution X satisfies the constraints and false otherwise
// select(X, i, j): a function used to switch the selection of service from // operation group i to service
// operation jbased on X and update the value of solution X // Xold: old solution vector, Vold: the set of QoS constraints that is
// violated by Xold
// Xnrold: old solution vector used to record the solution which satisfies
// non-relaxable QoS constraints // Vnr
old: non-relaxable QoS constraints which are violated by Xold
// avqvold: average violated quality value of Xold
// avqvnr
old: average violated quality value of X nr
oldfor non-relaxable QoS
constraints
// Xnew: new solution vector, Vnew: the set of QoS constraints which are
// violated byXnew
// Xnr
new: new solution vector used to record the solution which
// stratifies non-relaxable // QoS constraints // Vnr
new: non-relaxable QoS constraints which are violated by Xnew
// avqvnew: average violated quality value of Xnew
// avqvnr
new: average violated quality value of Xnrnewfor non-relaxable
// QoS constraints // avqvr
old: average violated quality value of X nr
oldfor relaxable QoS constraints
// avqvr
new: average violated quality value of Xnrnewfor relaxable QoS
constraints
// iterationmax: maximum number of iterations
Initialize Xold;Xnew;Xnr
oldand Xnrnewby selecting the service operation with the
lowest normalized quality value from each group Identify Voldand Vnrold, and then compute avqvoldand avqvnrold
avqvr
old avqvold avqvnrold
iteration 1 stop false repeat
stop true// check whether the avqv and avqvnr
are reduced in an iteration for i 1 to n do
for j 1 to lido
cur_sel current selection of service operation group i based on Xnew
if j – cur_sel then select(Xnew, i, j)
if isFeasible(Xnew) then
Substitute Xoldwith Xnewand return the feasible solution Xold
endif
Identify Vnewand computeavqvnew
if avqvnew< avqvoldthen
Substitute Xoldand avqvoldwith Xnewand avqvnew
stop false endif
cur_sel current selection of service operation group i based on Xnr new endif if j – cur_sel and jQCnr j – 0 then selectðXnr new;i; jÞ Identify Vnr
newand QCnr Vnrnew, and then compute avqvnrnewand
avqvr new
if avqvnr
new<avqvnroldthen
Substitute Xnr
old;avqvnroldand avqvroldwith Xnrnew;avqvnrnew
andavqvr new
stop false endif if avqvnr
new¼ 0 and avqvrnew<avqvroldthen
Substitute Xnr
old;avqvnroldand avqvroldwith X nr
new;avqvnrnewand
avqvr new stop false endif endif next next iteration iteration + 1
avqvr can be reduced or not. The purpose of the additional
examination is used to minimize the total number of the relax-ations for finding solutions for the non-relaxable QoS constraints. If a solution that satisfies the non-relaxable QoS constraints is found, an extra examination for minimizing the amount of the relaxation is performed to check whether avqvr can be reduced
or not. The final step is an iterative process performed when all ser-vice operation groups are evaluated. The process will stop at the maximum iteration or no more reduction of avqvold and a
v
qv
nroldhappened after some iterative runs. If no feasible solution could be found in this step (Xoldis infeasible), the final solution Xnroldwill
be recommended. In the step 3.2, if the jQCnrj = 0, it represents no
QoS constraints are involved in the service selection algorithm. We can simply return Xoldto the caller procedure, otherwise the
RQSS will return Xnr
old to the caller procedure. Obviously, the final
solution can be considered as a better solution than others because that not only does it satisfy all non-relaxable QoS constraints but it also has the lower average violated quality value for relaxable QoS constraints.
4.2. Complexity analysis of RQSS
To simplify the complexity analysis, it is assumed that each ab-stract service has s candidate service operations. Let n be the total number of abstract services in an abstract process, m be the number of QoS criteria and qnrbe the number of non-relaxable QoS
con-straints. For the first step of RQSS, the complexity of computing the normalized quality values of all candidate service operations is O(s.n.m). The complexity of sorting service operations of every service operation group is O(s.n.log s). The complexity of performing the sorting of service operation groups is O(n.log n). Consequently, the computational complexity of the first step of RQSS is O(s.n.log s). Similar to the first step, the computational complexity of the second step of RQSS is also O(s.n.m). For the third step, the complexity of calculating the average violated quality value is O(m.n). Finally, there are n. (s 1) candidate service operations to be explored in one iteration to evaluate whether a new solution exists or not. If the maximum number of iterations is l, which is used in the SS_QCR in theTable 5, the total complexity of the third step is O(l.m.n2.s).
According to above analysis, the complexity of the RQSS algorithm is O(l.m.n2.s).
4.3. The QoS-based web service composition framework
For the reliability and availability simulation, the test data and algorithms are implemented based on the framework shown in
Fig. 1. An abstract process is used to describe the functional requirement of a process of web services at an abstract level. The functionality of required service of an abstract process is repre-sented by an abstract service. The abstract services and the service advertisements published in the service registry are described using ontology. The available and feasible services are then discov-ered effectively by a semantic search[9,12,24]. Moreover, based on a set of QoS criteria, QoS constraints can also be specified to repre-sent the non-functional properties of the whole abstract process to be satisfied. According to abstract process and the QoS constraints, selection algorithms can select a set of operations offered by con-crete web services, which provide the required functionalities ful-filling the QoS constraints. If no feasible solution can be identified by the selection algorithm, the framework will recommend alter-native solutions based on user pre-defined relaxable constraints. It is expected that the recommended solution for service selection has small amount of relaxation for relaxable QoS constraints.
As shown inFig. 1, users can use the GUI Console (GC) to build the abstract processes and set the QoS constraints according to their functional requirement and non-functional requirement, respectively. To reduce the development effort, users can also re-use the existing abstract processes loaded from Abstract Process Repository (APR). The Service Selector (SS) is responsible for select-ing web services accordselect-ing to the abstract process specification and QoS constraints forwarded from GC. During the service selec-tion process, Service Brokersearches for candidate services from Service Registry (SR) which is an extension to UDDI registry which record the published service information as well as the QoS infor-mation[2]. These services published in SR are described by ontol-ogy stored in the Ontolontol-ogy Repository. When a feasible solution is found in APR, Feasible Solution Manager stores this feasible solution into Feasible Solution Repository (FSR). Users can reuse existing
User Abstract Process Repository Feasible Solution Repository Ontology Repository Service Selector GUI Console Service Broker Binder Execution Engine QoS Manager Publish Use Service Registry QoS WSM WS Service Provider Feasible Solution Manager
abstract processes from the FSR easily. After the feasible solution is identified, users can then composite the selected services by define the flow of input and output data binding to each services. Based on WSBPEL[13], the Binder generates the executable process spec-ification according to the abstract process and binding information. The executable process specification is then forwarded to the Exe-cution Engine to construct and execute the process instance. Fur-thermore, aQoS Manager (QM) is responsible for managing and monitoring QoS information of web services published in service registry[3]. QM collaborates with WSM[14,20]which is a web ser-vice management process to collect QoS information such as of the invoked service.
5. Experimental analysis 5.1. The evaluation setup
In this section, we compare the performance of proposed RQSS, WFlow[21] and RWSCS_KP[8]. WFlow and RWSCS_KP that are both well-known heuristic algorithms for QWSC only consider finding a feasible solution. They did not take the rate of failure in finding a feasible solution. We try to analyze the rate of failure in finding a feasible solution for QWSC and the average violated qual-ity value if no feasible solution is found for these algorithms.
Especially, in the WFlow[21]approach, Yu et al. divided the ser-vice selection problem into two categories. One is to composite services with a sequential flow structure; the other is to composite services with a general flow structure. In the latter, it may contain complex structure between function nodes, such as loop. In order to simplify the problem, the WFlow removed the loop operations by unfolding the cycle. Based on the categorization, WFlow consid-ering different objective function proposed two distinct algo-rithms; there are WFlow_EU and WFlow_HP respectively. In the experiments, we compared our approach only with the WFlow_EU (short for WFlow).
We utilized Java programming language to implement these algorithms and ran them on an Intel Pentium (R) D 3.4 Ghz, 2 GB RAM desktop PC with 100 MB/s Ethernet card, Window XP and JDK 6.0. In the simulation, test pattern generation is the same as what is introduced in[30]. The value of each service is not directly proportional to the QoS consumption. The random function of inte-ger i gives an inteinte-ger from 0 to i, following the uniform distribu-tion. To generate the test instances, we first randomly generate the abstract processes, each containing two or more control flow patterns. For simplicity, we assume that each abstract service con-tains the same number of candidate service operations. For each candidate of abstract service, five QoS parameters (q1, q2, q3, q4, q5): execution time, reliability, availability, reputation and price are considered. Each quality value is randomly generated with a uniform distribution in a range, as shown inTable 6.
These parameters are exploited in some researches[32,35]and refer them to set the values. In the simulation, we assume that all services can be completed within 100 ms. And most of services are robustness enough. Therefore the reliability and availability of ser-vices are ranging from 0.95 to 0.99999. We think that is reasonable for most of web services. In addition, the reputation is between
[1,10]according to how popular of the service is and the price is assumed that is between[1]based on the access cost of the service. These assumptions are all reasonable in various applications.
Moreover, the QoS constraint on each QoS criteria is generated using the Eq.(6). The concept of generating the QoS constraints re-fers to the test pattern generation for QWSC presented in[30]. The constraint factor is defined to increase the difficulty to find a feasi-ble solution.
QCi¼ n Qmaxi CF; i ¼ 1; . . . ; 5 ð6Þ
where n is the number of abstract services in an abstract process, Qmax
i is the maximum value of a quality parameter Qi of a service
and CF is the constraint factor which is used to adjust the strength of a QoS constraint.
The constraint factor CF is a real number between [0, 1]. It can be used to represent the strength of a QoS constraint. The lower the constraint factor value is, the higher the strength of the QoS constraint is. When CF = 1, there is no constraint on QoS require-ment. CF = 0.5 means there is 0.5 probability that a random gener-ated service in a group satisfies the average value. The default value of CF in this paper is 0.5. As shown inTable 7, the generated constraints are the upper bounds for the QoS constraints. In the generation of the QoS constraints, all the QoS metrics are assumed as the additive metrics. Since the reliability and availability are multiplicative metric, they can be transformed into additive parameters using logarithmic function. It should be noted that RQSS algorithm does not transform the reliability and availability into additive parameters. Therefore, the generated constraints on reliability and availability need to be transformed back into multi-plicative metrics, i.e. 1
0:95
nCF
. 5.2. Experimental results
WFlow[21]and RWSCS_KP[8]are implemented and compared with RQSS here because both of them are well-known heuristic algorithms for QWSC. Only the parts of finding a feasible solution in WFlow and RWSCS_KP are considered for justice.
From the proposed approach and algorithm mentioned in Sec-tion4, there are three aspects related to the will be illustrated in the experiments, as follows:
1. The failure rate is reduced in finding a feasible solution while the abstract service increasing.
2. The strength of QoS constraints is increasing while the con-straint factor value is decreasing.
3. The lower the avgv value is, the better the performance of the algorithm is.
5.2.1. Comparison of failure rate in finding a feasible solution
Fig. 2shows the experiment results of examining impact factors for RQSS, WFlow and RWSCS_KP respectively. The analysis of the impact focuses on the variances of the number of abstract services in an abstract process, the number of candidate service operations and the strength of the QoS constraints (constraint factor). Since the number of abstract services will affect the failure of finding a feasible solution. The more the abstract services are, the lower
Table 6
The range of the value for each QoS parameter. QoS parameter Range Execution Time [1, 100] Reliability [0.95, 0.99999] Availability [0.95, 0.99999] Reputation [1, 10] Price [1, 100] Table 7
The generation of the QoS constraints.
QoS parameter QoS constraint generation Execution Time n 100 CF Reliability n log 1 0:95 CF Availability n log 1 0:95 CF Reputation n10CF Price n100CF
failure rate in finding a feasible solution is. Similarly, the number of candidate service operations is also affect the failure rate. In the simulation, we vary the two factors to analyze failure rate in find-ing a feasible solution. In addition, since the constraint factor is used to increase the difficulty to find a feasible solution, in the sim-ulation, we also analyze the influence of constraint factor regarding to failure rate in finding feasible solution.
5.2.1.1. Impact of the number of abstract services. In the simulation, the numbers of abstract services are set from 5 to 50 to analyze the influence over the three algorithms. There are 50 test cases imple-mented and examined per number of abstract services. For each test case, there are 50 candidate service operations for each ab-stract service and the constraint factor is fixed to 0.4. As depicted inFig. 2a, RQSS has lower failure rate in finding a feasible solution than the other two algorithms for almost of the test cases. When the number of abstract service is equal to 5, all algorithms have unacceptable high failure rates to find feasible solutions. The rea-son is that the number of abstract services is so few that the con-straints relatively become very severe. When the number of abstract services is more than twenty, the failure rates of all algo-rithms behave stably. It can be said that the effects are few on the failure rate when the number of abstract services is more than a constant value.
5.2.1.2. Impact of the number of candidate service operations. Similar to the previous analysis, the numbers of candidate service opera-tions aer also set from 5 to 50, and the number of abstract services
and constraint factor are fixed as 50 and 0.4, respectively. As de-picted in Fig. 2b, the failure rates are higher along with the decreasing number of candidate service operations. It is natural that the more choices the less failures will happen. And, the con-straints are relatively severer when the number of candidate ser-vice operations decreases.
5.2.1.3. Impact of constraint factor. To measure the influence of con-straint factor, the values are set from 0.1 to 0.65 and 50 test cases are generated for each. There are 50 abstract services and 50 can-didate service operations for each abstract service.Fig. 2c shows that when the constraint factor is less than 0.1, no feasible solution will be discovered for all algorithms. When the constraint factor is greater than 0.65, every algorithm can find feasible solution. 5.2.2. Comparison of average violated quality value
The average violated quality value (avqv) represents the degree of the constraint violation of a solution. To evaluate the perfor-mance of our proposed QoS constraint relaxation technique, we compare the average violated quality value of RQSS with WFlow and RWSCS_KP. We only consider the situations where all the algo-rithms fail in finding a feasible solution and use the final solutions found in these algorithms to calculate the average violated quality values. As the previous analysis, we analyze the impact of varying the number of abstract services in the abstract process, varying the number of candidate service operations and varying the constraint factor. The numbers of non-relaxable QoS constraints for RQSS are set from 1 to 3 respectively for each test case. But, the items of non-relaxable QoS constraints are randomly selected. Note that the va-lue of avqv is greater than 1 in all cases and the lower the vava-lue is, the better the performance of the algorithm is. The factors for ana-lyzing the impact are the same as previous subsection.
5.2.2.1. Impact of the number of abstract services. Again, the num-bers of abstract services are set from 5 to 50 and there are 50 test cases for each. The number of candidate service operations for every abstract service is set as 50 and the constraint factor is fixed as 0.4.Fig. 3a shows that RQSS performs better than the other two 0.1 0.2 0.4 0.6 0.8 Rate of failure 0 0.1 0.2 0.3 0.4 0.5 0.6 Rate of failure 0 0.2 0.4 0.6 0.8 1 Rate of failure 0.3 0.5 0.7 0.9 0 0.3 0.7 0.9 0.5 0.1 5 10 15 20 25 30 35 40 45 50
Number of abstract services
Number of candidate service operations
0.1 0.15 0.2 0.25 0.3 0.35 0.4 0.45 0.5 0.55 0.6 0.65 Constraint Factor 5 10 15 20 25 30 35 40 45 50 RQSS WFlow RWSCS_KP RQSS WFlow RWSCS_KP RQSS WFlow RWSCS_KP
(a)
(b)
(c)
Fig. 2. Comparison of failure rate.
1 1.05 1.1 1.15 1.2 1.25 1.3 0 0.05 0.1 0.15 0.2 0.25 0.3 5 10 15 20 25 30 35 40 45 50 5 10 15 20 25 30 35 40 45 50
(a) average violated quality values
RQSS (nr=1) RQSS (nr=2) RQSS (nr=3) WFlow RWSCS_KP RQSS (nr=1) RQSS (nr=2) RQSS (nr=3) WFlow RWSCS_KP
(b) standard deviation of avqv
Average violated
quality
value
Standard deviation of avqv
Number of abstract services
Number of abstract services
algorithms for every test case.Fig. 3b shows the standard deviation of avqv for 50 test cases per number of abstract services. All of standard deviations of avqv in RQSS are less than 0.15. In addition, the behaviors of both WFLow and RWSCS_KP are too unstable to be accepted. It is because the objective of the two algorithms is to find a feasible solution but not suggest alternative solutions when no feasible one can be discovered. This result highlights the impor-tance of relax of QoS constraints.
5.2.2.2. Impact of the number of candidate service operations. The variances of the number of candidate service operations are set from 5 to 50. The number of abstract services is fixed as 50 and the constraint factor is set as 0.4. As depicted inFig. 4a, RQSS has lower rate of failure in finding a feasible solution than other two algorithms for all of the tested number of candidate service opera-tions. Obviously, the number of candidate service operations or the number of the non-relaxable QoS constraints increase, the avqv va-lue of RQSS decreases. The more the number of candidates, the higher the possibility of finding a feasible solution is. It is because that the constraints are severer along with the decreasing number of candidate service operations and the relaxable QoS constraints are fewer. Thus, the number of constraints to be relaxed will sub-stantially affect the avqv value.Fig. 4b shows that all of standard deviations of avqv in RQSS are less than 0.3. Similar to the analysis of impact of the number of abstract services, WFLow and RWSCS_KP also have more unstable avqv.
5.2.2.3. Impact of constraint factor. The constraint factors are from 0.1 to 0.45 to analyze the effect for each algorithm. Fifty test cases are generated for each constraint factor. There are 50 abstract ser-vices and 50 candidate service operations for each case. Fig. 5a shows that RQSS performs better than the other two algorithms when the constraint factor is greater than 0.2. RWSCS_KP can even perform better than RQSS when the constraint factor and the num-ber of non-relaxable QoS constraints are small. It is in the situation when both the values of constraint factor and number of relaxable constraints are small enough. RQSS has to substantially release relaxable QoS constraints causing the high avqv value. Note that when the constraint factor is below 0.1, the constraint is too severe to find the solution that satisfies non-relaxable QoS constraints.
When the constraint factor is greater than 0.45, there should exists at least one feasible solution in RQSS. Therefore, we exclude these situations.
Fig. 5b shows that when the constraint factor is greater than 0.2, the standard deviation of avqv is less than 0.4. When the constraint factor is less than 0.2 and the numbers of non-relaxable QoS con-straints are 2 and 3, the standard deviation of avqv is larger. The reason is also that the constraints are much severer in some test cases. RQSS has to substantially relax relaxable QoS constraints and thus the avqv of those test cases are much higher.
5.3. Discussion
From the experimental results, we conclude that, since the RQSS adopt heuristic approach to design the relaxable QoS-based service selection algorithm, it leads to significantly better QoS of compos-ite service executions with lower the rate of failure in finding a fea-sible solution. Even if there is no a feafea-sible solution to fulfill the QoS constraints, the RQSS can also find a solution with smaller amount of constraints violation. Table 8 shows the comparison with the WFlow and RWSCS_KP in terms of time complexity, fail-ure rate in finding feasible solution, availability, and adaptation respectively. Even if the time complexity of the RQSS is similar to the others due to adopting similar heuristic approach, the 1 1.1 1.2 1.3 1.4 1.5 5 10 15 20 25 30 35 40 45 50
Number of candidate service operations
Average violated quality value
RQSS (nr=1) RQSS (nr=2) RQSS (nr=3) WSFlow RWSCS_KP
(a) average violated quality values
0 0.15 0.3 0.45 0.6 0.75 0.9 5 10 15 20 25 30 35 40 45 50
Number of candidate service operations
Standard deviation of avqv RQSS (nr=1) RQSS (nr=2) RQSS (nr=3) WSFlow RWSCS_KP
(b) standard deviation of avqv
Fig. 4. Impact of the number of candidate service operations for avqv.
0.1 0.15 0.2 0.25 0.3 0.35 0.4 0.45 0.1 0.15 0.2 0.25 0.3 0.35 0.4 0.45 1 1.2 1.4 1.6 1.8 2 2.2 2.4 2.6 0 0.2 0.4 0.6 0.8 1 1.2 1.4 Average violated quality value
Standard deviation of avqv
Constraint Factor
Constraint Factor
(a) average violated quality values
(b) standard deviation of avqv
RQSS (nr=1) RQSS (nr=2) RQSS (nr=3) WFlow RWSCS_KP RQSS (nr=1) RQSS (nr=2) RQSS (nr=3) WFlow RWSCS_KP
Fig. 5. Impact of constraint factor for avqv.
Table 8
Comparison with existing methods.
WFlow RWSCS_KP Proposed RQSS Time complexity O(n2
(s 1)2
m). O(n2
(s l)2
)m) O(l.m.n2
.s) Failure rate in finding a
feasible solution
Middle Middle Low
Availability Middle Middle High
Adaption Good Good Good
n is the total number of abstract services in an abstract process. m is the number of QoS criteria.
l is the maximum number of iterations.
complexity of RQSS is possibly superior to the WFlow and RWSCS_KP while the s is far greater than l. It will be possible when the number of alternative web service increasing.
In addition, the failure rate and the availability can be proved that the RQSS is superior to the others from the simulation result in previous subsection. It is the main contribution of the proposed algorithm. The other factor in the comparison is the adaptation. Self-adapting [35] is an important feature of dynamic software architecture, especially for large scale web service composition. Systems which can monitor and adapt to the changes in their envi-ronment are known as self-adaptive, self-healing, or self-managing systems. Since WFlow, RWSCS_KP, and RQSS are all adopting heuristic approach to find feasible solution in each composition of web service, they can be adaptive to the changes in their envi-ronment as well as possible. Obviously, the only shortcoming is that the RQSS needs the user intervention to specify which QoS constraints are relaxable before the service selection.
In summary, we have stated that the heuristic algorithm is sim-ilar to the MMKP[17,21]in Section4.1, which have shown that their algorithms are near-optimal solution for web service compo-sition. In addition, based on the comparison, it is obvious that the RQSS is also a near-optimal solution for web service composition with lower failure rate and high availability.
6. Conclusions and future work
It is not easy to implement a development environment for users to reduce the complexity application building based on the web service composition technology. Most researches or studies do not deal with the situation of no suitable or feasible solution can be found during the service composition process. To get higher system reliability and availability, a relaxable QoS-based service selection algorithm, RQSS, is proposed in this paper. Not only does the RQSS help users to discover web services fulfilling the func-tional requirements and non-funcfunc-tional QoS constraints, but also it recommends solutions which could satisfy the non-relaxable QoS constraints by relaxing the relaxable QoS constraints. Besides, a generic framework is also designed for the evaluation of system performance for service selection algorithms. The experiment re-sults reveal that the failure rate of finding a feasible solution in RQSS is much lower than those of WFlow and RWSCS_KP approaches. RQSS also has the lower average violated values for almost of the test cases, especially when no feasible solutions could be discovered. That is, RQSS performs well not only because of the low computation complexity of itself but also the idea of relax of QoS constraints.
In the next step, we plan to complete the framework for partic-ular domain applications. We will also try to extend the RQSS algo-rithm for the case of contingencies and dynamic service composition which are currently out of the scope of our study.
References
[1] G. Alonso, F. Casati, H. Kuno, V. Machiraju, Web Services Concepts, Architectures and Applications, Springer-Verlag, Berlin, Heidelberg, 2004. [2] A. ShaikhAli, O.F. Rana, R.A. Ali, D.W. Walker, UDDIe: an extended registry for
web services, in: Proceedings of the Symposium on Applications and the Internet Workshops, January, 2003, pp. 85–89.
[3] C. Zhou, L.T. Chia, B.S. Lee, QoS-aware and federated enhancement for UDDI, International journal of Web Services Research 1 (2) (2004) 58–85. [4] D. Ardagna, B. Pernici, Adaptive service composition in flexible processes, IEEE
Transactions on Software Engineering 33 (6) (2007) 369–384.
[5] Quan Z. Sheng, Boualem Benatallah, Zakaria Maamar, Anne H.H. Ngu, Configurable composition and adaptive provisioning of web services. IEEE Transactions on Services Computing 2 (1) (2009), 34–49.
[6] S. Dustdar, W. Schreiner, A survey on web services composition, International Journal of Web and Grid Services 1 (1) (2005) 1–30.
[7] F. Casati, M. Sayal, M.-C. Shan, Developing e-services for composing e-services, in: Proceedings of 13th International Conference on Advanced Information Systems Engineering, Interlaken, Switzerland, June, 2001, pp. 171–186. [8] H. Cao1, X. Feng, Y. Sun1, Z. Zhang, Q. Wu, A service selection model with
multiple QoS constraints on the MMKP, in: Proceeding of the IFIP International Conference on Network and Parallel Computing Workshops, September, 2007, pp. 584–589.
[9] J. Cardoso, A. Sheth, Semantic e-workflow composition, Journal of Intelligent Information Systems 21 (3) (2003) 191–225.
[10] Jinghai Rao, Xiaomeng Su, A survey of automated web service composition methods, in: Proceedings of the First International Workshop on Semantic Web Services and Web Process Composition, San Diego, California, USA, July, 2004, pp. 43–54.
[11] L. Zeng, B. Benatallah, QoS-aware middleware for web services composition, IEEE Transactions on Software Engineering 30 (5) (2004) 311–327. [12] M. Paolucci, T. Kawamura, T.R. Payne, K. Sycara, Importing the semantic web in
UDDI, in: Proceedings of Workshop on Web Services, E-Business and Semantic Web, 2002, pp.225–236.
[13] Organization for the Advancement of Structured Information Systems (OSAIS), Web Services Business Process Execution Language (WSBPEL). <http://
www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsbpel>.
[14] Organization for the Advancement of Structured Information Systems (OSAIS) and Web Services Distributed Management (WSDM). <
http://www.oasis-open.org/specs/index.php#wsdmv1.1>.
[15] P. Plebani, B. Pernici, URBE: web service retrieval based on similarity evaluation, IEEE Transaction on Knowledge and Data Engineering 21 (11) (2009) 1629–1642.
[16] R. Aggarwal, K. Verma, J. Miller, W. Milnor, Constraint driven web service composition in METEOR-S, in Proceedings of the IEEE International Conference on Services Computing, 2004, pp. 23–30.
[17] R. Para-Hernández, N.J. Dimopoulos, A new heuristic for solving the multichoice multidimensional Knapsack problem, IEEE Transactions on Systems, Man, and Cybernetics – Part A: Systems and Humans 35 (5) (2005) 708–717.
[18] D. Stefan, G. Alessio, D. John, Exploiting metrics for similarity-based semantic web service discovery, in: Proceedings of International Conference on Web Services, July, 2009, pp. 327–334.
[19] J.M. Ko, C.O. Kim, I. Kwon, Quality-of-service oriented web service composition algorithm and planning architecture, The Journal of Systems and Software 81 (2008) 2079–2090.
[20] S.M. Yuan, Chia-Feng Lin, Ruey-Shyang Wu, Kuan-Yu Chen, Distributed systems management for enterprise web services environment, in: Proceedings of International Conference on New Trends in Information and Service Science, 2009, pp. 384–389.
[21] T. Yu, Y. Zhang, K.J. Lin, Efficient algorithms for web services selection with End-to-End QoS constraints, ACM Transactions on the Web 1 (1) (2007). Article 6.
[22] The Workflow Management Coalition, ‘‘The Workflow Reference Model’’, Document Number TC00-1003, January, 1995.
[23] UDDI.org. <http://www.uddi.org>.
[24] V. Suraci1, S. Mignanti, A. Aiuto, Context-aware semantic service discovery, in: Proceedings of the Third International Conference on Semantics, Knowledge and Grid, October, 2007, pp. 499–502.
[25] Romain Rouvoy, Paolo Barone, Yun Ding, Frank Eliassen, Svein O. Hallsteinsen, Jorge Lorenzo, Alessandro Mamelli, Ulrich Scholz, MUSIC: middleware support for self-adaptation in ubiquitous and service-oriented environments, Software Engineering for Self-adaptive Systems (2009) 164–182.
[26] W3C WS-Policy Framework Ver. 1.2. <
http://www.w3.org/Submission/WS-Policy/>.
[27] World-Wide Web Consortium (W3C), Simple Object Access Protocol (SOAP).
<http://www.w3.org/2000/xp/Group/>.
[28] World-Wide Web Consortium (W3C), Web Services Description Language (WSDL). <http://www.w3c.org/TR/wsdl>.
[29] X. Liu, G. Huang, H. Mei, Discovering homogeneous web service community in the user-centric web environment, IEEE Transactions on Services Computing 2 (2) (2009) 167–181.
[30] Y.S. Luo, Y. Qi, L.F. Shen, D. Hou, C. Sapa, Y. Chen, An improved heuristic for QoS-aware service composition framework, in: Proceeding of IEEE International Conference on High Performance Computing and Communications, September, 2008, pp. 360–367.
[31] Ziqian Xu, Patrick martin, Wendy Powley, Farhana Zulkernine, Reputation-enhanced QoS-based web service discovery, in: Proceedings of International Conference on Web Services, July, 2007, pp.249–256.
[32] Zibin Zheng, Michael R. Lyu, A QoS-aware fault tolerant middleware for dependable service composition, in: Proceeding of IEEE/IFIP International Conference on Dependable Systems & Networks, 2009, pp. 239–248.
[33] M. Alrifai, T. Risse, Combining global optimization with local selection for efficient QoS-aware service composition. In: International Conference on World Wide Web 2009 Proceedings, pp. 881–890.
[34] G. Canfora, M. Di Penta, R. Esposito, M.L. Villani, A framework for QoS-aware binding and re-binding of composite Web services, Journal of Systems and Software 81 (10) (2008) 1754–1769.
[35] J.L. Pastrana, E. Pimentel, M. Katrib, QoS-enabled and self-adaptive connectors for Web Services composition and coordination, Computer Languages, Systems & Structures 37 (1) (2011) 2–23.
[36] E. Amaldi, M. Bruglieri, G. Casale, A two-phase relaxation-based heuristic for the maximum feasible subsystem problem, Computers & Operations Research 35 (5) (2008) 1465–1482.
[37] E. Amaldi, V. Kann, The complexity and approximability of finding maximum feasible subsystems of linear relations, Theoretical Computer Science 147 (1– 2) (1995) 181–210.
[38] John W. Chinneck, Fast heuristics for the maximum feasible subsystem problem, INFORMS Journal on Computing 13 (3) (2001) 210–223. Summer.
[39] Edoardo Amaldi, Pietro Belotti, Raphael Hauser, Randomized relaxation methods for the maximum feasible subsystem problem, Lecture Notes in Computer Science 3509/2005 (2005), 249–264.
[40] T. Rajendran, P. Balasubramanie, Resmi Cherian, An efficient WS-QoS broker based architecture for web services selection, International Journal of Computer Applications 1 (9) (2010) 79–84.
