Web Service Composition Based on QoS Rules | SpringerLink

Zhang MW, Zhang B, Liu Y et al. Web service composition based on QoS rules. JOURNAL OF COMPUTER SCIENCE AND TECHNOLOGY 25(6): 1143–1156 Nov. 2010. DOI 10.1007/s11390-010-1091-6

Web Service Composition Based on QoS Rules

Ê

Ming-Wei Zhang1,2 ( ), Member, CCF, Bin Zhang2 ( ), Senior Member, CCF, Ying Liu1,2 ( 1,2 1 Jun Na ( ), and Zhi-Liang Zhu ( ), Senior Member, CCF 1 2

ýã

)

College of Software, Northeastern University, Shenyang 110004, China College of Information Science and Engineering, Northeastern University, Shenyang 110004, China

E-mail: {zhangmw, zhangbin, liuying, najun, zzl}@mail.neu.edu.cn Received July 15, 2009; revised January 26, 2010. Abstract For workflow-based service composition approach, the relations between the Web service QoS and environments are usually not considered, so that the information about QoS for composite service selection is inaccurate. It makes the selected composite service inefficient, or even unexecutable. To address this problem, a novel service composition approach based on production QoS rules is proposed in this paper. Generally, it is very difficult to directly analyze how different kinds of environment factors influence the Web service QoS. We adopt “black-box” analysis method of optimizing composite services, discovering the knowledge such as “the QoS of one Web service will be higher in specific environments”. In our approach, the execution information of the composite service is recorded into a log first, which will be taken as the basis of the subsequent statistical analysis and data mining. Then, the timely QoS values of the Web services are estimated and the production QoS rules being used to qualitatively express the different performances of the Web service QoS in different environments are mined. At last, we employ the mined QoS knowledge of the Web services to optimize the composite service selection. Extensive experimental results show that our approach can improve the performance of selected composite services on the premise of assuring the selecting computation cost. Keywords

1

service composition, service selection, QoS, data mining, production rules

Introduction

Nowadays, the Web service composition has attracted a wide attention in the research and industry groups. It supplies a new development model for networked software and applications[1-2] . Since composite services can be used to build business processes flexibly and efficiently, it is helpful to construct the new business system and update or extend the old business systems easily and quickly. In the area of the Web service composition, the workflow-based service composition is one of the most widespread approaches. Based on the specified composite service model, the workflow-based service composition approach can guarantee the best quality of the composite service selection under the premise of meeting user’s constraints. In this approach, each abstract service needs to select one concrete service according to the QoS (quality of service) of its candidate services. Generally, there are two kinds of the Web service QoS for composite service selection. They are the true QoS (TQoS) and the acquired QoS (AQoS). The former

can be gotten only after the execution the Web service; the latter can be obtained from the publishing of Web service providers, the monitoring of the third QoS center parties[3-4] , the feedback of service users[5-6] or the SLA contracts etc. As we know, AQoS of the Web service may greatly deviate from TQoS when composite service selection is running, which will make the selection of composite service non-optimal, or even unsuccessful. Compared with AQoS, TQoS of the Web service is the client QoS on the composite service side. However, it is difficult for the current Web service technologies to provide the Web service QoS support for each client side. Furthermore, TQoS of the Web service is influenced by many factors. For example, the TQoS of the Web service will be different if it interacts with different services, is invoked at different time period, or processes different amount of data. Without considering the above factors, AQoS of the Web service is usually inaccurate when it does service selection, making the selected composite service unreliable. To solve this problem, a production QoS rule-based service composition approach is proposed by adopting

Regular Paper This work is supported by the National Natural Science Foundation of China under Grant Nos. 60773218, 60903009 and 61073062, and the National High Technology Research and Development 863 Program of China under Grant No. 2009AA01Z122. 2010 Springer Science + Business Media, LLC & Science Press, China

1144

J. Comput. Sci. & Technol., Nov. 2010, Vol.25, No.6

“black box” analysis method. Based on the execution information of composite services, knowledge about the Web service QoS is mined and discovered to optimize composite service selection. The mined knowledge is like “the QoS of a Web service will be higher in given specific environment”. The idea of our approach can be briefly described as follows. We first construct the execution repository by recording the execution information of the composite service into the log. Then we extract the QoS point dataset of Web services, estimate the Web service timely TQoS values, and mine the production QoS rules that are used to qualitatively express the different performances of the Web services in different environments. At last, we utilize the estimated TQoS and production QoS rules of the Web services to optimize the composite service selection. The difference between TQoS and AQoS of the Web services is taken into account in our approach, which is also helpful to improve the performance of service composition. The major contributions of this paper can be summarized as follows. Firstly, a new composite service selection approach is proposed for improving the quality of the selected composite service based on the mined knowledge of the Web service QoS. Secondly, an execution log-based estimation of the Web service timely TQoS is designed. Finally, we propose the concept of Web service production QoS rules and design the corresponding mining algorithms. We predict in complex situation production QoS rules can be employed to estimate the Web service performance in the current environment accurately. This approach and its techniques can also be applied to other fields. The remainder of this paper is organized as follows. In Section 2, we describe the motivation and related work of this paper. Section 3 shows our research idea and defines related concepts. In Section 4, we analyze the execution log recording approach and the required contents to be recorded. Sections 5∼7 describe the extract approach of the Web service QoS point dataset,

the mining approach of production QoS rules, and the composite service selection approach based on production QoS rules, respectively. The experimental results and the conclusions with the discussion of the future work are provided in Section 8 and Section 9 respectively. 2 2.1

Motivation and Related Work Motivation

In workflow-based service composition, most existing QoS-based composite service selection approaches assume that the quality of candidate services is fixed, namely the AQoS. However, the actual executing QoS of the Web service (namely the TQoS) is greatly relevant to the environment in which the service does exist. For example, the concrete services’ correlations in a composite service, the invoking time period, and the amount of data to be transferred and processed, all these may affect the quality of the Web services directly. Considering the example of the “Travel Planning” composite service shown in Fig.1, the influence of concrete services’ correlations on the Web service QoS will be analyzed below. This service is composed of the service set {WS 1 , WS 2 , WS 3 , WS 4 , WS 5 , WS 6 , WS 7 , WS 8 }, which represent that the tourist attraction searching, can be done at the same time when airplane ticket reserving and hotel reserving. After that, the travel route between the selected attraction and the hotel should be chosen. Then the distance of the route is calculated, determining whether to hire a taxi or a bicycle. To facilitate explanation, suppose that the candidate service set of WS 1 is {American Airlines, United Airlines}, the candidate service set of WS 2 is {Hotel Pennsylvania, Wellington Hotel} and the candidate service set of WS 3 is {Bank of America, Citibank}. First, let us do analysis from the aspect of data. Taking the example of “Travel Planning”, suppose that

Fig.1. Example of “Travel Planning” composite service.

Ming-Wei Zhang et al.: QoS Rule Based Service Composition

the required input parameters of the payment service WS 3 are the bank accounts and dollar amounts, then WS 3 cannot be executed if WS 1 and WS 2 just provide the company name, and WS 3 will be executed wrongly if WS 1 and WS 2 provide the RMB amounts to be paid. Therefore, we can see that the data relation among atomic services will affect some QoS attributes of composite services, such as availability and robustness. Second, let us see from the aspect of business. Taking the example shown in Fig.1, as a candidate service of WS 1 , American Airlines makes a flexible pricing strategy for sale promotion. The customer could get a cheaper airplane ticket if he uses Visa Card for payment, or while reserving the airplane ticket, he reserves a hotel service belonging to “Hotel Alliance”. However, among candidate services of the payment service WS 3 , only some of them accept Visa Card. For example, Bank of America accepts Visa Card, but Citibank accepts Master Card. It is the same for candidate services of the hotel service WS 2 , i.e., only some of them belong to “Hotel Alliance”. For example, Hotel Pennsylvania belongs to the “Hotel Alliance” but Wellington Hotel does not. Therefore, the price of American Airlines depends on the selecting results of WS 2 and WS 3 . Furthermore, a candidate service may change its execution strategy such as security level or resource allocation priority according to whether another candidate service is chosen or not. So, the business relation among atomic services may influence many QoS attributes of composite services, such as cost, response time and security. Last, let us show the influence of environment. Taking the example of “Travel Planning” composite service, and considering Citibank which is one of candidate payment services, due to network environment etc., the response time will be shorter and operation will be securer if the receiver is also a client of Citibank, and the situation will be opposite if the receiver is another bank’s client. In this example, American Airlines and Hotel Pennsylvania are the clients of Bank of America, and United Airlines and Wellington Hotel are clients of Citibank. Therefore, the selecting results of the airplane service WS 1 and the hotel service WS 2 will influence the QoS of Citibank. Therefore, the environment relation among atomic services could influence some QoS attributions, like response time, robustness and security, etc. From the above analysis, we can see that there are many complex correlations among atomic services in one composite service, which may affect the QoS of atomic services and the composite service itself. Consequently, the knowledge like “the QoS of one Web service will be higher interacting with specific services”

1145

will be useful for composite service optimization. So it is worth researching discovery of this kind of knowledge. For another two factors “data amount” and “time period”, they also influence the Web service QoS obviously. For example, an information processing service will response quickly if the amount of input data is less than 1 Mbytes and in the time period of 3:00∼7:00 AM, and it will not response at all if the data amount larger than 5 Mbytes or in the time period of 13:00∼15:00 PM. Therefore, it is a necessary and challenging issue in service composition when considering the above discussed factors of the Web service QoS. 2.2

Related Work

There are three approaches from different communities, that address the Web service composition. The first approach is to leverage on the various planningbased solutions of AI community. Regarding representative AI planners capable of being used by service composition solvers, there are Graphplan[7] , the SATPlan algorithm[8], and the WSPR algorithm[9]. The second approach is to utilize the Semantic Web features for the service matching and composability. Medjahed et al.[10] proposed an ontology-based framework for the automatic composition of the Web services. Sirin et al.[11] demonstrated how an OWL reasoner can be integrated with an AI planner to overcome automatic WSC problems. Zeng et al.[12] proposed a semantic framework OntoMat-Service. The third is the most prevalent workflow-based composition approach, which adopts the idea of semiautomatic service composition where GUI-based software and human experts can work together to generate composite services by allowing binding manually the generated workflows to the corresponding concrete Web services, and then to do composite service selection. To that end, Proteus[13] , Kepler[14] , and e-Flow[15] were suggested. Composite service selection problem has been extensively studied recently, mostly based on quality of service (QoS). Zeng et al.[16] presented a global planning approach to selecting an optimal execution plan by means of integer programming. Ardagna and Pernici[17] modeled the composite service selection as a mixed integer linear problem where both local and global constraints are taken into account. Yu and Lin[18] discussed selection algorithms for multiple QoS attributes, using a utility function that is an increasing function of the QoS quality. The optimization problem is formulated as a knapsack problem. Korkmaz and Krunz[19] formalized the theoretical properties of the nonlinear cost function, and proposed a heuristic algorithm, which attempts to minimize both the nonlinear cost function

1146


and the primary cost function. Canfora et al.[20] adopted a quite different strategy for optimal selection based on genetic algorithms. Cardellini et al.[21] proposed a service selection scheme which optimizes the end-to-end aggregated QoS of all incoming flows of requests by means of linear programming. There are also many excellent studies of composite service selection which are not listed here, but most of them do not consider the accuracy of the Web service AQoS. For the Web service logging, there have been a few researches. [22] proposed a classification of the Web service logs according to the contained information, and analyzed how to acquire the corresponding information of each log level. [23] presented a Web services logging architecture WSLogA based on SOAP intermediaries that captures comprehensive services usage information. [24] presented a method of auditing the distributed processing of data in service-oriented systems named DIALOG (DIstributed Auditing LOGs). But, it is difficult to record process information of composite services for all above studies. For the workflow-based service composition, this paper proposes a new service selection approach based on the Web service QoS knowledge (namely estimated Web Service timely TQoS and production QoS rules) mined from composite service execution logs. Considering the environments’ influence on the Web service TQoS, this approach can improve the performance of selected composite services.

3 3.1

Research Ideas and Basic Concepts The Idea of Production QoS Rule-Based Service Composition

The idea of the production QoS rule-based service composition approach proposed in this paper can be generally described as the follows: 1) recording the execution information of composite services to generate the execution log repository; 2) mining the Web service QoS knowledge from the log repository; 3) applying the mined knowledge to optimize service selection to produce more reliable and efficient composite service execution instance. Its specific process is shown in Fig.2, having four steps such as execution log recording, the Web service QoS point data extracting, production QoS rule mining, and QoS rule-based composite service selecting. Recording of Composite Service Execution Log. It needs to have a log recording architecture for composite service, aiming at the Web service QoS knowledge mining to analyze the log contents necessary to be recorded. The generated composite service execution log repository of this step is the data basis of our approach. The contents of this part will be described in Section 4. Extracting of the Web Service QoS Point Data. The Web service QoS data generally means the statistical value of one Web service on each QoS attribute in a given time span, and it should be computed on the basis of the QoS values of this service at each moment in

Fig.2. Approach of service composition based on production QoS rules.


the time span. The Web service QoS value at the given moment is called QoS point data, and the QoS value in the given time span is called QoS statistical data (simply referred to as QoS data). The QoS values of atomic services at each invoking moment are extracted from past composite service execution instances in this step. The extracted Web service QoS point dataset is the basis of mining production QoS rules, and it also can be used to estimate the Web service timely TQoS values which are applied to optimize service selection. The contents of this part will be given in Section 5. Mining of Production QoS Rules. The Web service QoS is different in different environments which include the current selected concrete services, the invoking time period, and the amount of data needing to be transferred and processed etc. The environment factors are too complex to find a suitable prediction model to accurately predict the Web service TQoS. The production QoS rules, which are used to describe the different performances of the Web service QoS in different environments, are adopted to qualitatively analyze the Web service QoS in this paper. The form of the mined production QoS rules is like that “On the premise of some selected concrete services, in specific time period and under given data amount, how will the performance of the Web service TQoS be”. Finally, the QoS rules are used to do the optimization of composite service selection. The contents of this part will be described in Section 6. Composite Service Selection Based on Production QoS Rules. The estimated Web service timely TQoS and production QoS rules acquired from execution log repository can be used to predict the Web service TQoS accurately when the Web service is executed. These kinds of knowledge should be applied to improve the performance of the selected composite service execution instance. The contents of this part will be given in Section 7. 3.2

Basic Concepts

We give basic concepts of our approach. Definition 1 (Tri-Value QoS Attribute). Given a QoS attribute A of the Web service ws, the tri-value attribute Atri can be obtained by conceptually generalizing the attribute A. It can be calculated as follows: ⎧ b A(ws) max(A(ws)), ⎪ ⎨ 1, Atri (ws) = 0.5, a < A(ws) < b, ⎪ ⎩ 0, min(A(ws)) A(ws) A(ws) a. (1) Here, A(ws) represents the QoS value of ws on the attribute A, Atri is the corresponding tri-value QoS

1147

attribute of A, V = {0, 0.5, 1} is the range of the tri-value QoS attribute Atri . min(A(ws)) < a < b < max(A(ws)), and the values of a and b can be acquired by intelligent algorithms. Suppose that a1 and a2 are two variables of the trivalue QoS attribute Atri , then the “And operation ∧” and “Or operation ∨” on Atri are defined as follows: a1 ∧ a2 = min(a1 , a2 ),

(2)

a1 ∨ a2 = max(a1 , a2 ),

(3)

namely the value of “And operation” of two tri-value QoS attribute variables equals the smaller one, and the value of “Or operation” equals the larger one. Definition 2 (Production QoS Rule). Given a trivalue QoS attribute Atri of the Web service ws. Let E = {e1 , e2 , . . . , em } be the set of all items. Here, item means the related data of composite service execution, such as an executed service, the execution time period or the transferred data amount of the executed service. Let O = {0, 0.5, 1} is the set of the items about the values of ws on Atri . O is a subset of E. Let D = {T1 , T2 , . . . , Tn } be the set of transactions and each transaction Ti ⊆ E (1 i n), which has an identifier called TID, is the set of items. Given an item set A, a transaction T contains A if and only if A ⊆ T . In actual service execution situations, it means that the information set T of one composite service execution instance contains all the data of A. The support s of the item set A is the percentage of the transactions which contain A, namely support(A) = P (A) = |A(T )|/|D|. Here, |A(T )| and |D| represent the number of tuples in the set A(T ) and D respectively, and A(T ) is the set of transactions containing A. |A(T )| is called the support count of A. If support(A) min sup (the minimun support), A is called the frequent item set. A production QoS rule of the Web service ws on the tri-value QoS attribute Atri is the expression of the form A ⇒ e (A ⊂ E, e ∈ O, and e ∈ A). The rule A ⇒ e exists in the transaction set D, and its support s is the percentage of transactions containing A ∪ {e} in D, namely support (A ⇒ e) = P (A ∪ {e}). The confidence c of the rule A ⇒ e in D is the percentage of the ones containing {e} in the transactions containing A, namely confidence(A ⇒ e) = P ({e}|A). The production QoS rules which satisfy the minimum support threshold min sup and the minimum confidence threshold min conf at the same time, are called the strong production QoS rules. Web service production QoS rules express the knowledge of the form such as “given a specific item set that occurred, how will the performance of the service QoS be”. The support estimates the potential usefulness of the rules, and the confidence is the certain measurement

1148

of the effectiveness of the rules. According to the item types in the item set A, production QoS rules can be classified into correlation QoS rules, time QoS rules, and data amount QoS rules. Production QoS rules are the qualitative analysis of the Web service QoS in different environments, and applying them into service composition, the reliability and efficiency of selected composite services can be improved. 4

Recording of the Composite Service Execution Log

The knowledge of the Web service QoS is mined based on the composite service execution information in our approach. Consequently, the execution information of composite services needs to be recorded into logs first. It is difficult to do log recording distributedly because the Web services are distributive and autonomic. So, logs are recorded on the client side in a centric way in this paper, and a log recording architecture for service composition system is designed to record the execution information conveniently and flexibly. In addition, the contents which should be recorded into the log are analyzed according to the target of QoS knowledge mining. By embedding log recording function into composite service execution engine (such as ServiceMix, BPMS, and ActiveBPEL), our log recording architecture of composite services CSLRA shown in Fig.3, can easily log process information. It is composed of 5 components: the service composition system, the composite service execution engine, the log recorder, the log repository and log configuration parameters. The service composition system used by composite

Fig.3. Composite service log recording architecture CSLRA.


service providers integrates the atomic Web services to process the complex business requirements of customers. The atomic Web service providers register them into the UDDI to support the service querying and invoking. The composite Web service providers, who use the atomic service in the UDDI, provide addedvalue composite services to customers by the service composition system. The main functions of the composition system include interacting with customers, building or choosing the business processes of composite services, and discovering, selecting and invoking the related atomic Web services according to the specific business process. The composite service execution engine is the core component of the service composition system, and it dispatches and executes the selected business process instance. The log recorder, configured in the composite service execution engine records related information into log files when the SOAP messages are transferred between execution engine and atomic services. The log repository is composed of flat ASCII files. The format of those files is similar to the Web server log files, and their contents are generated by the log recorder. The log configuration parameters are provided as an XML file, containing data such as log name, date/time format, and date/time referee which states the date/time used to register standard date and time measures. Compared with the distributed log recording, the log architecture CSLRA can collect more valuable client data. A wealth of execution information of composite service can be recorded by CSLRA to launch a lot of work, such as monitoring the Web service usage, evaluating quality of the Web services, and analyzing commercial activities. The composite service execution information is used to do the Web service QoS knowledge mining in this paper. For this target, the information needed to be recorded for each SOAP message is given in Definition 3. Definition 3 (SOAP Log Item SLI). It is a tuple which is recorded by the log recorder for each SOAP message, represented as ProcessID, InstanceID, ServiceID, RequestID, Type, Time, info . The meaning of each item is described as follows: ProcessID : It is the business process identifier, specifying the composite service producing the tuple; InstanceID : Like the instance handle of an application, it identifies one execution instance of a composite service; ServiceID : It specifies the concrete service which sends the request/response message. Each Web service


can be identified by the tuple Url, portType, operation , and it can be obtained from WSDL files; RequestID : It is the Web service requesting identifier, used to identify one request to a given Web service in a composite service execution instance; Type : It specifies the type of the SOAP message — request message of response message; Time : Specifying the sending date/time of SOAP request/response messages; Info : It is the input/output data that the SOAP message contains. Using the SLI contents, the Web service QoS point data can be extracted and the production QoS rules can be mined. Here, it needs to be emphasized that the contents which the CSLRA records can be customized and can be extended to fit new requirements, for example, mining new kinds of QoS rules. 5

Extracting Web Service QoS Point Data

Given a Web service ws, one QoS point data of ws extracted from the composite service execution log is composed of the TQoS values of ws on each QoS attribute which are perceived on the composite service side at the invoking moment. Before the Web service QoS point data set is extracted, the QoS attributes needing to extract point data and their measurement expressions should be determined. Considering the importance of QoS attributes, four generic quality criteria for the Web services are used in this paper. 1) Response Time. Given a Web service ws, the response time Qrt (ws) measures the expected delay in seconds between the moment when a request is sent and the moment when the results are received at the composite service side. The response time is computed using the expression: Qrt (ws) = tsr-recieve − tsr-send ,

(4)

where tsr-receive and tsr-send represent the request sending time and the response receiving time respectively. 2) Availability. The availability of a Web service ws Qav (ws) is the probability that the service is accessible in a given time span Δt. The value of the availability of a service ws is computed using the following expression: Qav (ws) =

Rsr Ssr

(5)

where Rsr and Ssr represent the number of times that the requestor has received response messages and the total number of invocations in the given time span Δt respectively. The value of Δt may vary depending on a particular application. For example, in an application

1149

where the Web services are more frequently accessed (e.g., stock exchange), a small value of Δt gives a more accurate approximation for the availability of services. If the service is less frequently accessed (e.g., online bookstore), using a larger Δt value is more appropriate. The value of Δt can be given by users when they query the QoS data. 3) Reliability. The reliability of a Web service ws Qre (ws) is the probability that a request is correctly responded (i.e., the response message indicating that the execution has been successfully completed is received by service requestor) in a given time span Δt. The value of the reliability of a service ws is computed using the following expression: Qre (ws) =

Nsr Ssr

(6)

where Nsr is the number of times that the service ws has been successfully completed within the given time span Δt, and Ssr is the total number of invocations. 4) Robustness. It is the probability that a Web service ws can react properly to invalid, incomplete or conflicting request messages. It can be measured by tracking all the incorrect request messages and put them in relation with all valid responses in a given time span Δt. Ssir f (resp i (req i (ws))) Vsr Qrob (ws) = = i=1 , (7) Ssir Ssir here Vsr and Ssir represent the number of times that the service ws has been successfully completed and the total number of incorrect requests respectively. resp i (req i (ws)) represents the i-th response to the ith request to the service ws. The utility function f is calculated as follows: 1, isValid(resp i ), f= (8) 0, ¬isValid(resp i ). It is used for evaluation if the response is valid for a given request. Given the above considerations, the vector of the QoS point data can be represented as ServiceID, Time, Qrt , Qav , Qre , Qrob . For example, given a Web service ws, one possible QoS point data is ws, 2009-7-1 10:25:38, 172, 1, 0, −1 , representing that at the moment of “2009-7-1 10:25:38”, the response time of ws is 172 s, the service ws is available, unreliable, and the robustness of ws is not collected. The idea of the Web service QoS point data extracting can be generally described as follows: 1) grouping the data of the composite service execution log by ServiceID; 2) for each Web service, extracting one

1150

corresponding QoS point data for every non-processed request in the log using an incremental algorithm. To extract the related QoS indicators, it needs to judge the condition (correct, valid or invalid) of one Web service response. There are 2 kinds of methods. The first is that the conditions of the Web service execution results are judged by some rules and composite service execution logs. For example, if many concrete services are invoked for the same abstract service, it may indicate that the responses of the previous invoked concrete services are incorrect. The second is to make judgment based on the WSDL files of the Web services. Comparing the 2 methods, the latter is inefficient, but more accurate. The second method is adopted in this paper. To extract one QoS point data for each Web service request, the corresponding response data in the log and the WSDL file of the Web service are needed. Next we describe the extracting method of the Web service QoS point data. Given a Web service ws, ws, RequestID, Time req , Time resp , Info req , Info resp is one execution data of ws in the log, Pin and Pout are, respectively, the expected input and output of ws described in the WSDL file, and Cin and Cout are, respectively, the constraints on Pin and Pout . Then, the request condition variable sreq is defined as: 1, (Inforeq ⊇ Pin ) ∧ Cin (Info req ), sreq = (9) 0, ¬(Info req ⊇ Pin ) ∨ ¬Cin (Info req ), representing that when the actual request data Info req contains the expected input data Pin , and Info req satisfies the constraint Cin , sreq equals 1 (i.e., the request is correct). Otherwise, sreq equals 0 (i.e., the request is incorrect). The response condition variable sresp is defined as: ⎧ 1, (Info resp ⊇ Pout ) ∧ Cout (Info resp )∧ ⎪ ⎪ ⎪ ⎪ Time resp , ⎪ ⎨ sresp = 0, (¬(Info resp ⊇ Pout ) ∨ ¬Cout (Info resp ))∧ ⎪ ⎪ ⎪ Time resp , ⎪ ⎪ ⎩ −1, Time resp = NULL, (10) representing that sresp equals −1 if the response message is not received. If the actual response data Info resp contains the expected output data Pout , and Info resp satisfies the constraint Cout , sreq equals 1 (i.e., the response is valid). Otherwise, sreq equals 0 (i.e., the response is invalid). To convert the above data recorded in the composite service execution log into one QoS point data, it can be accomplished by calculating the value for each item of ServiceID, Time, Qrt , Qav , Qre , Qrob . The


calculating expressions are listed as follows: ServiceID = ws,

(11)

Time = Time req , Timersp − Time req , VResponseTime = −1,

sresp

(12) −1, =

sresp = −1, (13) = 0, (14)

1, sresp = 1 ∨ sresp VAvailability = 0, sresp = −1, ⎧ sreq = 1 ∧ sresp = 1, ⎪ ⎨ 1, VReliability = 0, sreq = 1 ∧ sresp = 1, ⎪ ⎩ −1, sreq = 0, ⎧ sreq = 0 ∧ sresp = 1, ⎪ ⎨ 1, VRobustness = 0, sreq = 0 ∧ sresp = 1, ⎪ ⎩ −1, sreq = 1.

(15)

(16)

Using (11)∼(16), one request data to a given Web service can be simply converted into one QoS point data. The incremental QoS point data extracting algorithm (QoSEA) uses (11)∼(16) repeatedly to convert all the Web service request in the composite service execution log into QoS point data. Due to space limitations, the algorithm QoSEA is not described anymore. 6

Production QoS Rule Mining

The Web service timely TQoS can be estimated based on the extracted QoS point data set. However, the Web service QoS is related with environments, and a given Web service will have different QoS in different time period, with different data amount, or interacting with different concrete services. Consequently, the concrete services, which are used frequently in the composite service, should be analyzed further, to discover the knowledge about the QoS performance in different conditions, namely to mine more detailed production QoS rules. The production QoS rules, whose definition is given in the Subsection 3.2, are classified into three types in this paper. Service correlation QoS rules are used to analyze the Web service QoS when the given concrete services have been executed in the composite service. Time QoS rules are used to analyze the Web service QoS in a given time period. Data amount QoS rules, which are only applied to the Web services with large data amount needing to be transferred and processed, are used to analyze the relations between the data amount and the Web service QoS. Before the production QoS rules are mined, the mining dataset has to be generated based on the composite service execution log and Web service QoS point dataset. Then the mining of production QoS rules can


be launched. We next describe the production QoS rule mining approach in detail. 6.1 Generating of the Mining Dataset The mining dataset which can be represented as ServiceID, Attribute, Time, Sws , STime , Bytes, Vtri , needs to be generated before the mining of the production QoS rules. Here, ServiceID specifies the Web service that the production QoS rules belong to, and Attribute specifies the QoS attribute that the rules belong to. Time means the Web service invoking moment. Sws is the set of concrete services which have been executed in the composite service when ServiceID starts its execution at the moment Time. STime used to mine the time QoS rules specifies the time period that the moment Time belongs to. For example, STime = {7 clock (hour period), Date 13 (day period), Monday (week period), July (month period)}. Bytes is the data amount transferred for invoking the service ServiceID, and it is used to do data amount QoS rule mining. Vtri is the QoS value of the service ServiceID at the moment Time and on the Attribute’s corresponding tri-value QoS Attribute (e.g., Vtri = 1). There are two tasks to generate the mining data of production QoS rules. The first is to extract related information (i.e., Sws , STime , Bytes and V ) based on composite service execution log and the Web service QoS point data set. Here, V is the value of ServiceID at the moment of Time and on the Attribute. This task is simple and is not described anymore. Second is to convert Attribute into tri-value QoS attribute, and transform V to Vtri . Now we describe the converting process. Given an abstract service WS in the composite service CS, {ws 1 , ws 2 , . . . , ws n } is the candidate service set of WS, A is a Web service QoS attribute, and v1 , v2 , . . . , vn represent the values of ws 1 , ws 2 , . . . , ws n on the attribute A respectively. For the Web service ws i having been recorded in the log, the value vi can be estimated by the log (the estimating method is described in Section 7), and for the Web service ws j not having been recorded, the value vj is acquired from its AQoS. It can be seen from (1) that the main task of converting A to the tri-value QoS attribute Atri is to determine the values of a and b. The method of determining the parameters a and b can be described as follows: the proportion coefficient k1 with “0” value and the proportion coefficient k2 with “1” value (i.e., the proportion of the times that “Atri = 0” or “Atri = 1”) are inputted by the user. k1 = k2 = 0.1 in this paper. Then, a = decs(n × k1 , v1 , v2 , . . . , vn )

(17)

1151

b = asc(n × k2 , v1 , v2 , . . . , vn )

(18)

namely, a is the n×k1 -th smallest value of v1 , v2 , . . . , vn , and b is the n × k2 -th largest value of v1 , v2 , . . . , vn . It can be seen, from Definition 1, that it is easy to convert a Web service QoS attribute to its tri-value QoS attribute to analyze the Web service QoS qualitatively when the parameters a and b are determined. The mining dataset of production QoS rules will be generated through the above processing steps, to form the basis of the next QoS rule mining. 6.2

Production QoS Rule Mining Algorithm QoSR

Taking the example of service correlation QoS rules, we will next describe the mining approach of the Web service production QoS rules. Regarding Time as TID, then the mining dataset generated in the above subsection can be transformed to the set of transactions D = {Time, Sws ∪ Vtri }, based on which service correlation QoS rules can be discovered by association mining. The dynamic character of the Web services needs to be considered when we mine QoS rules by association analysis, and the recent QoS data should play a greater role in the mining. Based on the above consideration, a time weighed QoS rule mining algorithm QoSR is proposed in this paper. The algorithm QoSR, taking the classical Apriori algorithm[25] as prototype, solves the problem of ineffectiveness of the past QoS data by assigning higher weights to recent transactions. In our new algorithm, we redefine the concept of support. Definition 4 (Support). Given a transaction set D in the item set E = {e1 , e2 , . . . , em }, for any subset A ∈ E, the support of A in D is defined as: l wid support D (A) = ni=1 . j=1 wid

(20)

Here, l is the number of transactions in D which contain A, and n is the total number of transactions in D (i.e., n = |S|). wid is the weight of the transaction Time, which can be computed as follows : wid =

1 . k(tcurrent − Time) + ε

(21)

Here, tcurrent is the current time. k and ε are weight accommodation coefficients (0 < k, ε < ∞), whose values can be set by the user. We can see from (20) that the larger the value of k is, or the smaller the value of ε is, the greater the time factor affects the weight of transactions. It can be seen from the above definition that support D (A) ∈ [0, 1]. Using the new definition, the

1152

support and confidence of the QoS rule A ⇒ e can be recalculated for association mining by setting corresponding thresholds. The association rule discovery is composed of two steps. The first step is to discover all the frequent itemsets, and the second step is to generate association rules from these frequent item-sets. Based on the definition of production QoS rules, all the frequent item-sets discovered in the first step must include the value item in the set O = {0, 0.5, 1}. Consequently, it is enough to find the frequent 1 item-sets only in O. In addition, the association rules generated in the second step must let the item in O be the post condition. The computation of the first step (i.e., finding the frequent item-sets) is much more expensive than the second step (i.e., finding the rules from these frequent item-sets). Except the new definition of “support” and the specific mining context, the algorithm QoSR has generally the same idea as the classic algorithm Apriori’s. Here, the algorithm QoSR is not described anymore. The time QoS rules and data amount QoS rules can also be discovered using the algorithm QoSR just changing the mining dataset simply. All the mined production QoS rules can be used to optimize the composite service selection. 7

Production QoS Rule Based Composite Service Selection

As an important step of service composition, composite service selection is used to select one concrete service for each abstract service among a lot of Web services with the same function, to make the selected composite service have the best quality on the premise of satisfying the user’s constraints. Most existing approaches are based on the QoS of concrete services to do selection. However, the acquired Web service quality (i.e., AQoS) used by service selection usually has a comparatively large deviation from the actual Web service quality (i.e., TQoS), which makes the selected composite service not optimal, or even unexecutable. The idea of the production QoS-rule-based service selection approach proposed in this paper can be generally described as follows: 1) estimating the service timely TQoS based on the Web service QoS point dataset, and replacing the AQoS with the estimated TQoS; 2) in the process of service selecting, evaluating the timely quality of the Web services based on current conditions and Web service production QoS rules, to recommend or exclude concrete services. We next describe the pre-selection optimization approach based on estimated TQoS and the in-selection optimization approach based on production QoS rules.


7.1

Estimating of Web Service Timely TQoS Values

The Web service timely TQoS is estimated by the Web service past TQoS extracted from the composite service execution log. It is usually more accurate than the AQoS. Consequently, the performance of the selected composite service can be improved by replacing the AQoS with the estimated TQoS before selection. The Web service QoS point dataset-based estimating method of the Web service timely TQoS is described below. The dynamic character of the Web service is considered in this paper when the Web service timely TQoS is estimated, namely, the Web service QoS is changing over time, and the more current the QoS point data is, the more effective it is for estimating the timely TQoS. Given a QoS attribute A, suppose that the QoS values of the Web service ws on A and at the moment of t1 , t2 , . . . , tn (ti < ti+1 , 1 i < n) are v1 , v2 , . . . , vn , then the timely TQoS of ws on A is: A(ws) =

n

ki vi ,

(21)

i=1

where ki is the time attenuation factor, computed using the following expression: ki = eti −tcurrent

n

eti −tcurrent .

(22)

i=1

Here, tcurrent represents the current time. The longer from tcurrent the ti is, the smaller the ki is. In addition, the timely TQoS cannot be estimated for any Web service recorded in the log. If the Web service ws has not been used for a long time, considering the accuracy, the timely TQoS of ws cannot be estimated again. To address this problem, a time threshold max time is given in this paper. Suppose that tlast is the last moment of the point QoS data of the Web service ws, the timely TQoS of ws cannot be estimated when tcurrent − tlast > max time. The Web service timely TQoS estimating method described above is used before selection. Next we will describe the applying approach of production QoS rules in the process of composite service selection. 7.2

Applying of Production QoS Rules

Although the Web service timely TQoS estimated in the above subsection can be used to optimize the composite service selection effectively, it is also a kind of coarse knowledge. It is a simple statistical value of all the past TQoS in different conditions. However, the


Web service TQoS is related with environments, and a specific Web service will have different TQoS in different time periods, with different data amount, or interacting with different concrete services. Consequently, the more detailed production QoS rules should be applied in the process of composite service selection. The applying method is described below. Given a Web service QoS attribute A, suppose that the current selection condition of the composite service CS is Sws , STime , Bytes . For a concrete service ws, the set of production QoS rules on A satisfying the current condition is {A1 ⇒ e1 , A2 ⇒ e2 , . . . , An ⇒ en }. Then, the QoS value of ws on A and under the current condition Sws , STime , Bytes is: Atri (ws) = e1 ∧ e1 ∧ · · · ∧ en

as the classical algorithm Apriori. So, we would not give the experimental analysis of the Web service QoS knowledge mining anymore. However, we will focus on the experimental analysis of the effectiveness of the QoS knowledge application. The general integer programming selection approach IP[16] and the general heuristic selection approach HEU[19] are adopted in our experiments, and the comparative analysis of the following 6 selection approaches in the computation cost and the quality of selected composite services is given: the original algorithms (i.e., IP and HEU), the optimization algorithms based on estimated TQoS (i.e., TQoS-IP and TQoS-HEU), and the optimization algorithms based on estimated TQoS and production QoS rules (i.e., RulesIP and Rules-HEU).

(23)

namely the QoS value of the Web service ws on A equals the smallest QoS value in all QoS rules satisfying the current condition. Given a Web service ws, suppose that the values of ws on the attributes concerned by the user are {A1 = q1 , A2 = q2 , . . . , An = qn }, then the TQoS value of ws is: n wi qi . (24) TQoS (ws) = i=1

Here, n wi is the weight of the QoS attribute Ai , and i=1 wi = 1. We can see from (24) that 0 TQoS (ws) 1, which is calculated based on the production QoS rules, which satisfy the current condition. Setting the recommendation factor r and the exclusion factor e (0 < e < r < 1) in the process of composite service selection, the Web service ws will be excluded directly if TQoS (ws) e, and the service ws will be selected if TQoS (ws) r. If many Web services are selected at the same time, then the Web service with the highest TQoS is chosen finally. The applying approach of the Web service production QoS rules for compositing service selection described above can be used to improve the performance of selected composite services further. Our production QoS rule based optimization approach can be applied to most existing QoS-based service selection approaches. The detailed optimization algorithm is not described anymore in this paper. 8

1153

Experiment

This section will give the design and analysis of experiments to validate our service composition approach. Here, the Web service QoS point data extracting algorithm is relatively simple, and the production QoS rule mining algorithm QoSR has the same time complexity

8.1

Generation of Experimental Data

The “Travel Planning” composite service shown in Fig.1 is used for comprehensive experimental analysis in our service composition approach. To do experiments effectively, 100 concrete services are generated for each of the eight abstract services. Then, for each concrete service, the following QoS attributes (response time, availability and reliability) are adopted, and to simulate different kinds of QoS in the real service composition environment, the QoS values are generated within a certain interval using normal distribution, considering the difference between AQoS and TQoS, and the influence of service correlations on the concrete service QoS. The detailed QoS generating method can be described as follows: 1) For each concrete service, generating 2 close QoS values using normal distribution and random deviation, let one be the AQoS and the other be the TQoS; 2) Selecting a certain proportion of concrete services randomly as correlation-sensitive services, and generating another QoS value for them, then for each correlation-sensitive concrete service ws: 2.1) Randomly choosing one or two abstract services except itself, like the payment service, choosing the hotel service or the airplane service or both of them; 2.2) Randomly selecting 20 to 30 candidate services for each chosen abstract service as the services correlating with the service ws, then regarding one of the three QoS values of ws as its AQoS, another one as the TQoS on the condition that there is no concrete service correlating with ws in the composite service, and the last as the TQoS having correlated services. The QoS values generated by the method of normal distribution and random deviation can reflect different kinds of QoS in the real service execution environment to a certain extent, and they will be the basis of service selection.

1154


After the concrete Web services are generated, execution instance data of the “Travel Planning” composite service needs to be produced to do QoS knowledge mining. The execution instance data generating approach is that classical selection algorithms are used to do service selection based on Web service AQoS, and the selecting results are regarded as the execution instance data. Based on the generated data, Web service timely TQoS can be estimated and production QoS rules can be mined. 8.2

Measuring Computation Cost

The first experiment aims at comparing the following four selection algorithms in computation cost: two original algorithms IP and HEU, and two optimization algorithms based on production QoS rules Rules-IP and Rules-HEU, all for the studying of the selection duration of each algorithm along with the increase of the average number of concrete services for each abstract service. Because the optimization algorithms based on estimated TQoS (i.e., TQoS-IP and TQoS-HEU) have the same computation cost as the original algorithms (i.e., IP and HEU) respectively, so the experimental analysis of them is not given here. Before doing this experiment, the TQoS values are estimated for each concrete service included in the 5000 execution instances generated in Subsection 8.1, and 80 concrete services frequently used are chosen to do production QoS rule mining. Since the data amount of each chosen service is not too large, the production QoS rule mining for the 80 services are done by batch processing. The total time of the TQoS estimating and QoS rule mining is 175.8 s. The results of this experiment are shown in Fig.4. For each test case, we executed the composite service selection ten times and computed the average selection duration.

algorithm IP in the computation cost. Second, comparing the optimization types, we can see that if the mining time (175.8 s) is considered, the proposed optimization algorithms are more time-consuming than the original algorithms. However, the results mined once can be used many times for service selection, so the QoS knowledge mining time can be neglected. If the mining time is not considered, because of the dynamic calculating of candidate service TQoS in the process of service selection, our optimization algorithm is also time-consuming, but just has a little difference compared with the original algorithms. 8.3

Measuring Quality of Composite Services

The quality of selected composite services is a more important indicator to measure selection algorithms than computation cost. In our second simulation, we study the composite service QoS selected by the six algorithms: two original algorithms IP and HEU, two estimated TQoS based optimization algorithms TQoS-IP and TQoS-HEU, and two production QoS rules based optimization algorithms Rules-IP and Rules-HEU. The quality of selected composite services is presented in Fig.5, where we vary the number of the candidate services. The QoS values shown in Fig.5 are calculated by standardizing the three QoS attributes: response time, availability, and reliability.

Fig.5. Experimental results on the quality of selected services.

Fig.4. Experimental results on computation cost.

First, comparing the types of original algorithms, it can be seen from Fig.4 that the heuristic algorithm HEU has an advantage over the integer programming

Comparing the types of original algorithms, we can draw a conclusion from Fig.5 that the integer programming algorithms (i.e., IP, TQoS-IP, Rules-IP) gain an advantage over heuristic algorithms (i.e., HEU, TQoSHEU, Rules-HEU) in the quality of selected composite services. Comparing the optimization types, it can be seen from Fig.5 that the optimization algorithms based on estimated. TQoS and production QoS rules Rules-IP and Rules-HEU are better than the estimated TQoS-based optimization algorithms TQoSIP and TQoS-HEU respectively, and the algorithms


TQoS-IP and TQoS-HEU are obviously better than the original algorithms IP and HEU. So, the production QoS-rule-based service composition approach can improve the quality of selected composite services to a great extent. From the above experiments, we can reach the conclusion that our service composition approach based on production QoS rules can improve the QoS of selected composite service instances on the premise of ensuring the computation cost of selecting. 8.4

Measuring the Effectiveness of the Mined Knowledge

In our service composition approach, the knowledge patterns mined once can be applied in service selection many times. The relation between the effectiveness of the mined production QoS rules and the rate of changed Web services is analyzed in the experiment. The TQoS values of the Web services are randomly changed to simulate the dynamic environment of the Web services, and 50 candidate services are adopted to do service selection for each abstract service. The results of this experiment are described in Fig.6.

Fig.6. Experimental results on the effectiveness of the mined knowledge.

The rate in Fig.6 means the percentage of randomly changed Web services. It can be seen from Fig.6 that along with the change of the Web services, the QoS of the selected composite services using the previous mined knowledge patterns decreases obviously, especially at the beginning stage. At last, the QoS decreases nearly to the QoS of original selection algorithms. Consequently, we can draw a conclusion that the effectiveness of the mined knowledge patterns will decrease as time goes on, and the QoS of the selected composite services will bring down. So, it has to do knowledge mining repeatedly after a given period of time to improve the selected composite services’ quality. This is a limitation of our approach.

1155

9

Conclusion

Now, most existing service selection approaches in the workflow-based service composition do not consider the difference between the Web service AQoS and TQoS and the relations between TQoS and environments, making the selected composite service ineffective or even unexecutable. To solve this problem, a production QoS-rule-based service composition approach is proposed in this paper. In our approach, the execution information of composite service is recorded into the log firstly. On this basis, the Web service QoS point data is extracted to estimate the timely TQoS of concrete service, and the more detailed production QoS rules are mined. At last, the mined Web service QoS knowledge is applied to optimize the composite service selection, improving the performance of selected composite services. This paper first analyzes the reasons that the Web service timely TQoS is difficult to acquire accurately, then gives the research ideas and basic concepts in our approach. Next, the recording approach of composite service log, the extracting approach of the Web service point data set, the mining approach of production QoS rules, and the production QoS rule based service selection approach are described in turn. At last, the experimental analysis of our approach is given. The production QoS-rule-based service composition approach proposed in this paper can be applied to service composition systems, it reduces the possibility of service system abnormality in dynamic service execution environments, increases the system stability, and improves the system efficiency. However, it needs initial accumulation of logs, and systems cannot use the approach at the beginning stage of the execution. In addition, the proposed approach needs to repeatedly do knowledge mining periodically, because the effectiveness of the previous mined knowledge will be decreased as time goes on. At last, there are also many other factors influencing the TQoS of the Web services that need to be analyzed. We will consider the above issues in our future work. References [1] Milanovic N, Malek M. Current solutions for Web service composition. IEEE Internet Computing, 2004, 8(6): 51-59. [2] Yu J, Han Y B, Han J et al. Synthesizing service composition models on the basis of temporal business rules. Journal of Computer Science and Technology, 2008, 23(6): 885-894. [3] Serhani M A, Dssouli R, Hafid A et al. A QoS broker based architecture for efficient Web services selection. In Proc. the IEEE Int. Conf. Web Services, Orlando, USA, July 11-15, 2005, pp.113-120. [4] Rosenberg F, Platzer C, Dustdar S. Bootstrapping performance and dependability attributes of Web services. In Proc. the IEEE International Conference on Web Services, Chicago, USA, Sept. 18-22, 2006, pp.205-212.

1156 [5] Wang Y, Vassileva J. A review on trust and reputation for Web service selection. In Proc. the 27th Int. Conf. Distributed Computing Systems Workshops, Toronto, Canada, June 22-29, 2007, pp.25-32. [6] Li H H, Du X Y, Tian X. A review-based reputation evaluation approach for Web services. Journal of Computer Science and Technology, 2009, 24(5): 893-900. [7] Blum A L, Furst M L. Fast planning through planning graph analysis. Artificial Intelligence, 1997, 90(1/2): 281-300. [8] Kautz H, Selman B. Unifying sat-based and graph-based planning. In Proc. the 16th Int. Joint Conf. Artificial Intelligence, San Francisco, USA, Aug. 1-6, 1999, pp.318-325. [9] Oh S C, Lee D W, Kumara S R T. Effective Web service composition in diverse and large-scale service networks. IEEE Transactions on Services Computing, 2008, 1(1): 15-32. [10] Medjahed B, Bouguettaya A, Elmagarmid A. Composing Web services on the semantic Web. The VLDB Journal, 2003, 12(4): 333-351. [11] Sirin E, Parsia B, Wu D et al. HTN planning for Web service composition using SHOP2. Journal of Web Semantics, 2004, 1(4): 377-396. [12] Zeng L, Benatallah B, Kalagnama M et al. Quality driven Web services composition. In Proc. the 12th Int. Conf. World Wide Web, Budapest, Hungary, May 20-24, 2003, pp.411-421. [13] Ghandeharizadeh S, Knoblock C, Papadopoulos C et al. Proteus: A system for dynamically composing and intelligently executing Web services. In Proc. the 1st IEEE Int. Conf. Web Services, Las Vegas, USA, June 23-26, 2003, pp.17-21. [14] Altintas I, Jaeger E, Lin K et al. A Web service composition and deployment framework for scientific workflows. In Proc. the 2nd IEEE Int. Conf. Web Services, San Diego, USA, July 6-9, 2004, pp.814-815. [15] Sun H, Wang X, Zhou B et al. Research and Implementation of Dynamic Web Services Composition. Advanced Parallel Processing Technologies, 2003, LNCS, Vol.2834, pp.457-466. [16] Zeng L Z, Benatallah B. QoS-aware middleware for Web services composition. IEEE Transactions on Software Engineering, 2004, 30(5): 311-327. [17] Ardagna D, Pernici B. Global and local QoS guarantee in Web service selection. In BPM 2005 Int. Workshops, Nancy, France, Sept. 5, 2005, LNCS, Vol.3812, pp.32-46. [18] Yu T, Lin K J. Service selection algorithms for composing complex services with multiple QoS constraints. In Proc. the 3rd Int. Conf. Service Oriented Computing, Amsterdam, Netherlands, Dec. 12-15, 2005, pp.130-143. [19] Korkmaz T, Krunz M. Multi-constrained optimal path selection. In Proc. the 20th Joint Conf. IEEE Computer and Communications Societies, Anchorage, USA, April 2226, 2001, pp.834-843. [20] Canfora G, Penta M D, Esposito R et al. An approach for QoS-aware service composition based on genetic algorithms. In Proc. the Int. Conf. Genetic and Evolutionary Computation, Washington DC, USA, June 25-29, 2005, pp.1069-1075. [21] Cardellini V, Casalicchio E, Grassi V et al. Flow-based service selection for Web service composition supporting multiple QoS classes. In Proc. the Int. Conf. Web Services, Salt Lake City, USA, July 9-13, 2007, pp.743-750. [22] Dustdar S, Gombotz R. Discovering Web service workflows using Web services interaction mining. International Journal of Business Process Integration and Management, 2006, 1(4): 256-266. [23] Cruz S M S, Campos M L M, Pires P F et al. Monitoring e-business Web services usage through a log based architecture. In Proc. the IEEE Int. Conf. Web Services, San Diego, USA, July 6-9, 2004, pp.61-69. [24] Ringelstein C, Staab S. DIALOG: Distributed auditing logs. In Proc. the IEEE Int. Conf. Web Services, Los Angeles,

J. Comput. Sci. & Technol., Nov. 2010, Vol.25, No.6 USA, July 6-10, 2009, pp.429-436 [25] Agrawal R, Imielinski T, Swami A. Mining association rules between sets of items in large databases. In Proc. the ACM Conf. Management of Data, Washington DC, USA, May 2528, 1993, pp.207-216.

Ming-Wei Zhang received his M.S. degree in computer science from Northeastern University in 2005. He is currently a Ph.D. candidate in Northeastern University of China. He is a member of China Computer Federation (CCF). His current research interests include service oriented computing and data mining.

Bin Zhang is a professor in the College of Information Science and Technology at Northeastern University, Shenyang, China. He is a senior member of China Computer Federation (CCF). He received his Ph.D. degree from Northeastern University in 1997. His current research interests include service oriented computing and information retrieval. Ying Liu received her M.S. degree in computer sciences from Northeastern University in 2006. She is currently a Ph.D. candidate in Northeastern University of China. Her current research interest is service oriented computing.

Jun Na received her M.S. degree in computer science from Northeastern University in 2006. She is currently a Ph.D. candidate in Northeastern University of China. Her current research interest is service oriented computing.

Zhi-Liang Zhu is a professor in the College of Software at Northeastern University, Shenyang, China. He is a senior member of China Computer Federation (CCF). He received his Ph.D. degree from Northeastern University in 2002. His current research interests include chaos science, image processing and service oriented computing.