A Risk-driven Selection Approach for Transactional Web Service Composition

Hai Liu,Weimin Zhang, Kaijun Ren,Cancan Liu College of Computer

National University of Defense Technology Changsha, China

liuhai1982@gmail.com,wmzhang104@163.net, renkaijun@nudt.edu.cn,liucancan2008@yahoo.com.cn

Zhuxi Zhang General Logistics Research Institute

Beijing, China zhangyishan_11@163.com

Abstract—In web service composition (WSC), quality of service (QoS)-based web services selection has been a critical research issue , and many service selection methods have been presented aiming at resolving this issue, However, most of the existing methods ignore giving a risk evaluation for critical web services in WSC where transactional requirements often require compensation cost to ensure failure atomicity . To address this issue, we present a Risk-driven selection approach by incorporating the impact of failure risk of each participating task to reduce the average losses caused by execution failures of tasks for WSC. With our method, a kind of tree called failure causing tree is built to support risk losses evaluation for each task in composition web service (CWS). Particularly, our method is more suitable to the scientific computing area where many long tasks are often involved and easily lead to a lot of losses such as computing cost, communicating cost, when some failures occur in these executing tasks. The final experiment and evaluation further demonstrate the feasibility and efficiency of our method.

Keywords-web service; composition; QoS; transaction

I. INTRODUCTION With the rapid development of internet and information

technologies, web services has de facto become one of the most significant technologies in the domains of both academia and industry [1]. Web services are modular, self-organization, and loosely coupled software which can be advertised and accessed programmatically across internet. Nowadays, more and more services have been wrapped into web services. However, single web service does not have to satisfy the requirements for users. Therefore, how to effectively integrate several web services into a composite one has been a challenge and is attracting more attention.

Web services composition is a complex process involving several steps. The significant step is the process of web services selection for each task in web services composition. Recently, lots of QoS-driven web services selection approaches [2-4] have been presented. Nevertheless, few of them consider the impact of failure risk in transactional WSC, especially in scientific computing

environment with transaction where it possibly leads to losses of cost such as the wasted time and execution resources when the exceptions even failures of individual web services in CWS occur. To address this issue, we propose a risk-driven selection approach for transactional WSC, with which we can spend the same cost on the dimension of reliability, but reduce average losses for CWS. Specifically, we first use failure causing tree based on failure atomicity to evaluate probable risk losses for each task in transactional execution path. Then, different relative impact is assigned into each task based on its risk losses to specify reliability requirements. Finally, a modified QoS-driven web services selection method has been presented. The experiment proves feasibility of our work.

The rest of this paper is organized as follows. In next section, we will give the formal representation for our model of WSC with transactional properties. A specific scenario on scientific computing domain is described. In section Ⅲ, we introduce the method of risk evaluation for participant tasks based on failure causing tree and propose two algorithms, which obtain the relative impact for each task. We next bring forth our modified web services selection algorithm based on general QoS driven web services selection method in section Ⅳ . In section Ⅴ , we firstly do an experiment for our solution, and then compare our method with others related. Section Ⅵ provides overview of related work. Finally, we conclude and indicate the future direction in the section Ⅶ.

II. FORMALIZED MODEL For the reason of expressing well later, we firstly

formalize the model for our solution to transactional WSC. According to the literature [5], it proposed that the process of WSC should be divided into two-phase which comprises application-level composition and concretion-level composition respectively. Our work is based on the second-phase composition assuming that it works after the first phase. It means our work in this paper has the precondition with finish of the first phase composition. Therefore, we formalize our model of WSC on assignment with specific instances of candidate web services by non-functional properties. We also reference the concepts proposed in the literature [2], where it calls a path for a specific workflow or a kind of type-based composition and names a plan for an executable path. For the sake of facility to represent our

This paper is supported by the Chinese 863 project “the National High-technology Research Development Planning—High-Performance computing and Grid Service Environment” (No.2006AA01A123) and The Research Center of Supercomputing Application in NUDT.

2009 Eighth International Conference on Grid and Cooperative Computing

978-0-7695-3766-5/09 $25.00 © 2009 IEEE

DOI 10.1109/GCC.2009.68

399

2009 Eighth International Conference on Grid and Cooperative Computing

978-0-7695-3766-5/09 $25.00 © 2009 IEEE

DOI 10.1109/GCC.2009.68

399

2009 Eighth International Conference on Grid and Cooperative Computing

978-0-7695-3766-5/09 $25.00 © 2009 IEEE

DOI 10.1109/GCC.2009.68

391

2009 Eighth International Conference on Grid and Cooperative Computing

978-0-7695-3766-5/09 $25.00 © 2009 IEEE

DOI 10.1109/GCC.2009.68

391

problem later, we distinguish the concepts between task and instance of web service, where the latter one will be assigned to the former one so that the former one can execute in the plan. Actually, this concept of task is an abstract web service or a service class defined as literature [2].

Definition 2.1 We define each task in a path as a seven tuple t= <tid,I,O,F,Q,e,tp>, where notation tid represents the identifier of task t; notations I and O represent set of input and set of output on this task t respectively; notation F denotes requirements for all of functional properties of task t; notation Q expresses requirements of nonfunctional properties, such as QoS parameters; notation e denotes the degree of impact, which would be calculated based on evaluation for failure risk of task t in a specific path. This attribute will be explained further in the following section. The last notation tp is defined transactional properties according to features of business application, where tp belongs to the transactional properties TP={r, c, nr, nc, rc, nrc, nrnc, rnc}. The specific description for each element in TP is shown as the literature [17].

Definition 2.2 We define a quarter tuple s=<sid,tid,Q,R> for each instance of web service. Notation sid represents the identifier of service s. Notation tid denotes the identifier of the task whose candidate services list includes the service s. Notation Q represents set of non-functional properties which should be advertised by the provider of service s. In the end, notation R denotes current reliability of the instance s. It can be advertised in the descriptive language such as WSDL.

Definition 2.3 We assume that notation P denotes an execution path. In the meanwhile, according to the literature [6], P could be represented with workflow patterns. In this paper, three typical patterns will be considered for our execution path, because the other workflow patterns can be reduced to these three patterns [4]. Now we introduce these operators to denote these workflow patterns as following:

1. Sequence pattern, we use notation ‘;’ to represent. The execution path (t1;t2) means that task t2 should be invoked after task t1 completed.

2. Parallel pattern, we use notation ‘|’ to represent. The execution path (t1|t2) means that task t1 and task t2 can execute simultaneously.

3. Condition pattern, we use notation ‘+’ to represent. The execution path (t1+t2+…+tm)n means that it can be selected n tasks to execute parallel from task set {t1,t2,…,tm}. On the condition that n equals to 1, we say that the pattern becomes a single selection pattern.

Fig. 1 shows the execution path that is our motivation application on domain of scientific computing called ensemble prediction business process which includes seventeen tasks, while each of tasks has its own transactional properties for inherent characteristics of this business process. Once a task encountered failures, in order to guarantee atomic consistency, forward recovery methods such as retrying operations or backward recovery such as compensation operations are required to execute. In this business process environment, execution of each task needs to very long execution time and expensive execution cost. Therefore, the web services selection for each task needs to consider the impact of failure risk. In the following section, a

new evaluation method based on transactional CWS will be presented.

III. EVALUATION OF FAILURE RISK LOSSES

A. The formation of failure causing tree The authors of literature [7] give the concept of failure

risk, they proposed that failure risk is a characteristic considering probability that some faults will occur and leading to impact on the composite service. Distinguished from their work, our work is to evaluate the losses caused by failure so that we can get the relative impact degree for each task in an execution path of transactional composition. Our purpose is to evaluate the losses when a task encountered failures or exceptions to support the selection method introduced in the next section. In order to evaluate failure causing losses for all tasks in a specific execution path defined above, not only should we delve into execution cost of each task in history, but also we should consider dependency among tasks in the specific execution path, especially in transactional WSC environment. Based on this idea, we first regard dependency among tasks. According to [17], it presented some dependencies between services to guarantee failure atomicity requirement for transactional CWS. It gives four dependencies related to transactional properties in transactional CWS. In this paper, we consider two dependencies, which are failure causing dependency and compensation dependency respectively to get possible losses caused by failure of individual task. Of course, these dependencies should be predefined based on atomic consistency of transactional CWS and transactional nature of individual task.

Definition 3.1 Failure causing dependency (from task t1 to task t2): It represents task t2 would be canceled or compensated because of failure of task t1. In other words, the failure of task t1 will make task t2 affected. Take Fig. 1 for example, there is one failure causing dependency from task t3 to task t4. When task t3 encounters failure, task t4 must be compensated if task t4 is completed, or task t4 must be canceled if task t4 is running. We denote 1 2failuret t⎯⎯⎯→ .

Definition 3.2 Compensation causing dependency (from task t1 to task t2): There is a compensation causing dependency from task t1 to task t2 if compensation of task t1 causes task t2’s compensation. This kind of dependency is caused indirectly by failure of one task in an execution path. We denote 1 2compensationt t⎯⎯⎯⎯⎯→ for the compensation causing dependency from task t1 to task t2, which means task t2 needs to be compensated after task t1 compensated.

Figure 1. Process of ensemble prediction formalized as

(t1;t2;((t3;t8)|(t4;t9)|(t5;t10)|(t6;t11)|(t7;t12));t13;(t14+t15+t16)1;t17).

t1

t7

t8

t12

t13 t17

t2

| | t3

t16

t14

400400392392

Theorem 3.1 Compensation causing dependency has transitivity: It means suppose 1 2compensationt t⎯⎯⎯⎯⎯→ and 2 3compensationt t⎯⎯⎯⎯⎯→ to be true, we can get that 1 3compensationt t⎯⎯⎯⎯⎯→ is true.

Prove: Let compensation causing dependency 1 2compensationt t⎯⎯⎯⎯⎯→ and 2 3compensationt t⎯⎯⎯⎯⎯→ be true. If task t1 has

been compensated then it exists in which task t2 needs to be compensated according to the dependency of compensation causing 1 2compensationt t⎯⎯⎯⎯⎯→ ; now it exists in task t2 that will be compensation. Therefore, we can get that task t3 needs to be compensated on the terms of compensation causing dependency 2 3compensationt t⎯⎯⎯⎯⎯→ ; therefore, it means that the condition of compensation of task t1 can lead to the conclusion that task t3 needs to be compensated. In other words, we can get the result of which compensation causing dependency 1 3compensationt t⎯⎯⎯⎯⎯→ is true.

Definition 3.3 Failure causing tree (let root node of the tree be task t): This kind of tree is very similar with fault tree. It consists of nodes and links, where nodes contain two types which are operator and and task respectively. There includes three kinds operators corresponding to workflow pattern defined above which are SEQ, AND and OR. While links also contain two kinds which are links based on dependencies defined above. In the failure causing tree of task t, the links connected immediately with task t or with operators that are connected directly with task t represent failure causing dependency, and the others denote compensation causing dependency. Following is several rules used for formation of this kind of tree according to the semantic transaction nature of task t.

Rule 1: If task t is retriable, as we know, in case of caused failure, it can be recovered by the mechanics of forward recovery, such as by restarting this task with other similar-function web services. Therefore, it needn’t compensate any other completed tasks. There is only one node representing the self of task t in its failure causing tree.

Rule 2: If there is a parallel pattern or a condition pattern in the original execution path, and the failure causing tree of task t includes those nodes representing tasks in a parallel pattern or in a condition pattern and contains one node representing task before these tasks, we should append these nodes representing the task to every offsets representing a parallel pattern or a condition pattern in the failure causing tree.

Rule 3: Otherwise, all nodes in the failure causing tree should conform to tasks’ structure corresponding in the original execution path.

Fig. 2 shows an example on several dependencies correlating to business transaction requirement in the execution path of ensemble prediction and a typical failure causing tree with root node of task t13. Fig. 2.a illustrates failure causing dependency and compensation causing dependency, which are represented with red arrows and dotted arrows respectively. For the space limited, we only line out the dependencies of task t13, while others aren’t drawn. It can be known from this figure that there are five

failure causing dependencies between task t13 and from task t8 to task 12. It also shows that there are five pairs of compensation causing dependencies. The tree will be ended when there is no compensation causing dependencies in the last nodes. Fig. 2.b illustrates failure causing tree according to dependencies showed by Fig. 2.a, where task t13 and task t8 to task t12 are connected with the operator AND represents they are parallel relationship in the failure causing tree, meanwhile there existing operator SEQ that has been omitted between task t8 and t3 represents they are sequence relationship in the failure causing tree.

Theorem 3.2 in the failure causing tree, all of completed nodes except for the root node need to be compensated when the root node encounters failure.

Prove that: According to theorem 3.1, definition 3.1 and definition 3.2, we can prove it directly.

B. Losses evalution of failure risk for tasks We postulate these two dependencies have been

established during the first level of WSC. So we can evaluate losses of each task with the help of these dependencies and historical execution information of individual task. According to theorem 3.2, we can infer that the losses caused by failure of a specific task should involve two parts, which are compensation cost part and execution cost part along to failure causing tree. We consider cost metrics as two dimensions that are execution time dimension and execution cost dimension respectively. We define formula (1) to evaluate cost-taken of a specific execution path or sub-path. U u f T v f Eu v 1 1

In the formula (1), functions f T and f E represent two different utility functions based on parameter of time dimension and parameter of execution cost dimension for path p respectively, these two functions can be defined to unify metrics based on users’ preferences. Variables u and v are weight values specified by user. Therefore, in order to evaluate the losses of a failure task, we should evaluate the total execution time and execution cost spent by tasks according to its failure causing tree. However, there are different computing ways between execution time and execution cost for the reason of different structure existing in the failure causing tree, which makes us evaluate them based on its inherent structure separately. In the following, we will show respective ways to evaluate these two parameters based on three different structures corresponding to operators in the failure causing tree. Without loss of generality, we postulate task t is the root node of the failure causing tree, and make variable T and variable E represent total losses of time and execution cost in a subtree p of the failure causing tree.

Case 1: If there is an operator SEQ between t1 and t2 in a path as illustrated in Fig. 3.a, we can evaluate their total time and cost consumed as formula (2). T T T T TE E C E C E C E C (2)

Case 2: If there is an operator AND between t1 and t2 to t3 as illustrated in Fig. 3.b, we can evaluate their total time and

401401393393

Algorithm 1 Evaluating losses-taken for Task t (ELT) Input:Head node T (t);// A failure causing tree of task t Output: Real LossesCFT ; Begin: 1 if T (t).child!= ∅ ; 2 then do 3 ERT(T(t),Time,Cost); 4 CaculateOvlapNodes(T(t),OvlapNodeSet); 5 EvaCosideringOvlapNodes(tempTime,tempCost, OvlapNodeSet, LossesFT , ET ); 6 else do

7 TFT Rty tEFT Rty t ;

8 end if 9 LossesFT u f TFT v f EFT ; 10 return (LossesFT ; End

cost consumed as formula (3). T T T T T,MT T,ME E C E C E C E CE C E C (3)

Case 3: If there is an operator OR between t1 and from t2 to t3 as showed in Fig. 3.c, where t2 and t3 have execution probability p2 and p3 respectively. We can evaluate their total time and cost consumed as formula (4). T T p2 T p3 TT p2 T p3 TE E C p2 E C p3 E C E C p2 E C p3 E C

4

Case 4: If there is only one node in failure causing tree, it means that task t just need executing forward recovery mechanism such as retrying this task when it encounters failure. Therefore, we can evaluate its total time and cost consuming as formula (5). T Rty tE Rty t (5)

Where T T and T T denotes execution and compensation time of task ti; Meanwhile E C and E C represent execution and compensation cost of task ti. Variables Rty t and Rty t denote execution time and cost taken by retrying operation which may be replaced by another candidate web service instances. All of variables proposed above can be predicted by history execution information of individual task. We use the method of mean value on history information [2] or other history-based methods. For instance, presuming task t has been executed five times in history, each of which has spent cost, such as 50, 65, 70, 65, 80 respectively, we can come to conclusion with following expression: T T =66.

We show our method of evaluating losses-taken for a specific task of failure causing tree in algorithm 1, as shown in Fig. 4, where step 3 is a function to compute total time and cost with failure causing tree T(t). However, there are some overlapped nodes generated in the failure causing tree T(t) existing for the reason of several patterns before them in the original execution path such as parallel pattern, since these nodes need appending to every offset for formation of the failure causing tree T(t). Meanwhile step 4 attains the set of overlapped nodes; step 5 gets the eventual result of both

Figure 3. Several probable subtrees in failure causing tree

Figure 4. The algorithm 1 for evaluating losses

execution time and cost considering overlapped nodes; step 7 represents the condition of existing one node in the failure causing tree. Finally, the algorithm gets the losses for the task t with formula (1) at step 9.

As mentioned by algorithm 1, we can get loss-taken for a specific task according to its related failure causing tree. However, what its precondition is the execution path can be recovered by backward or forward methods. We also need consider the situation that it exists in a task assigned web service class with no compensated property. For this situation, in order to ensure failure consistency for executing in the execution path, for tasks after these tasks with no compensated property, we need to keep them with retriable property or assign them highest level of impact in the execution path so that we can select higher reliable web service to execute. For instance, we can set the reliability requirement for these kind tasks as near to1.

Algorithm 2 as shown in Fig. 5 gives the approach for getting failure impact of entire tasks in a specific execution path P formalized as section 2. Step 1 is to find the first task with no compensated transactional property; step 2 initializes a set used for marking such tasks with non-retriable property; therefore step 4-8 finds these tasks with non-retriable property after task t to store in set P1; because these tasks found at step 4-8 mustn’t encounter any failures for ensuring correctness, we should set the failure impact value for these tasks higher than others, and the value is µ at step 10, which is inputted by user; for other tasks in the execution path P, we first evaluate losses for these tasks with algorithm 1,and then scale uniformly losses evaluated for these tasks to domain [0,1] at step 11-14; finally, we return the array of failure impacts for all tasks in the execution path P. Currently, we have evaluated the failure impacts for all tasks in a specific execution path, in the next section, a modified

p3 p2

t3

AND

t1

t2

(b) a subtree with operator AND

(c) a subtree with operator OR

t1

t2 t3

t1

t2

OR

(a) a subtree with operator NULL

402402394394

Algorithm 2 Calculating Impact for each Task (CIT)Input: P;//An execution path with transactional properties

generated at the first level composition), which could be formalized as defined in section two. Output: impact[t1..tn]: impact for each task’s failure risk

Begin 1 t=findFirstNCTask(P);//find t.TP not in {nc,rnc,nrnc} 2 P1={};//initialize set P1 3 t’=t.next; 4 while (t’!=null ) do 5 if (t’.TP=nr*) //’*’ represents c or nc or null. 6 Add (t’,P1); add task t’ to Set P1. 7 t’=t.next; 8 End do 9 for each task ti in P1 10 impact[ti]=µ;//specified by user; 11 for each task ti in (P-P1) 12 Losses[ti]=ELT(T(ti));//get the losses-taken of task t. 13 impact[t1..tN]=scale(losses[t1..tN]); 14 return impact[t1..tn] End

Figure 5. The algorithm 2 for calculating impact

QoS-driven web services selection algorithm would be given based on failure impact.

IV. SELECTION ALGORITHM Now we propose our web services selection approach

that is very similar with these selection methods based on QoS constraints [2, 8] . The difference from these methods is we specify firstly requirement on the reliability dimension that is one of QoS dimensions according to failure impact of each task. Certainly, in the field of QoS-driven WSC, the higher reliability requirement, the more efficient performance, however, let us consider the situation with the same total cost constrained by user, we need constrain different requirement of reliability for a task base on its failure impact evaluated above so that we can reduce average losses for the related execution path as well as save costs for users. Hence, what we do first is to decide the requirement of reliability dimension for each task in the execution path. In the following, we will give our optimization solution model with linear programming [9] .

Let set variable e to represent the equivalent weight between cost dimension and cost-taken for reliability dimension from user’s prospect. In other words, it will increase the cost-taken e units when we want to increase the requirement of reliability one unit for task i. Let set variable r to represent the reliability requirement for task i, on which standard the task i will select web service, and this kind variables will be computed by our linear programming later. The array impact[i] is calculated by algorithm 1 and algorithm 2 defined above. The constant R and C represent two variables that are the lowest requirement of reliability for composition service and cost constraint spent on reliability dimension specified by user respectively. The function Reliability r , r , … , r calculated based on

the control construct of the execution path by Jorge Cardoso et al. in literature [10] denotes the method of computing reliability dimension for composition service that contains task t , task t ,…, and task t . In order to ensure the minimizing losses and to keep the same cost spent on reliability dimension, we will use following minimum objective function: Impact 1 r impact i 6

For the purpose to keep the same cost and to guarantee the lowest reliability requirement from global prospect, the following constraints should be satisfied: r e C 7 Reliability r , r , … , r R (8) 0 , R 1 e 0 C 0 (9)

In terms of defining variables, functions and constraints above, we can compute the values r , r , … , r .

Based on steps above, we can modify web services selection algorithm such as MMKP (Multidimension Multichoice 0-1 Knapsack Problem) that has been proved np-hard problem[11, 12] solved by our previous work [8], while one kind of constraint that the requirement on reliability dimension for each task i is r should be added to [8] so as to assist selection of candidate web services for each task in a specific execution path.

V. EXPERIMENTS AND EVALUATION To prove the feasibility for our method in this paper, we

do the simulative experiment using our algorithm 1,2 and with the selection algorithm proposed in section 4. We use the execution path of CWS as illustrated by Fig. 1 in the section 2. We assume that compensation cost or retrying cost of each task is evaluated based on history information. We also presume communication cost is far less than the cost of compensation and execution in our application of ensemble prediction. So we can ignore the impact of communication between tasks.

Table 1 shows the relative cost and impact obtained by algorithm 1and 2 for each task. In this table, the symbol α represents the lowest impact factor specified by users or designers. The blank cell represents the cost related to task is infinite. The last row of this table represents impact for each task in CWS. Finally, we do the simulative experiment to measure the average losses caused by failure of tasks for CWS. For each task, we respectively limit the candidate web services providers from 5 to 12, whose reliability parameters advertised can be implemented by random function defined in JAVA. For the sake of simplification, we postulate that each the variable e for task i has the same value. The lowest requirement of initial reliability for CWS is 0.5. Meanwhile, the domain of r is divided into discrete values, which constrained in the set {0.1,0.2,0.3,0.4,0.5,0.6,0.7,0.8,0.9,1}. Therefore, we can

403403395395

make use of Integer Programming-based method to get the requirement value of r for each task i , then the method in literature [8] is applied to get the optimal execution plan.

The result as demonstrated in Fig. 6, with the increasing number of execution times of CWS, the average losses with our method are always lower than the method [2,8] of QoS-based web services selection without considering impact of failure risk. We also can see from this figure, with the number of execution times going larger, the gap of average losses between these two methods becomes more stable.

VI. RELATED WORK In this section, we compare major techniques related to

our approach. To the best of our knowledge, few literatures discuss the full similar topic as our work to predict relative impact based on evaluation of risk cost for each task in CWS with transactional properties, which provides a policy in support of web services selection for CWS. Jiangxia Wu et al. [13] studied an approach to predict QoS parameters for composition web services with transaction, and a specification model was defined to specify execution processes of CWS according to the exception handling policies of transactions. This algorithm can reduce error rate. However, our work exists in a few differences. First, our discussion is on evaluating failure risk losses for individual task, while their work focused on the entire execution process. Second, our work is based on the selection of individual web services, while it’s based on the selection of execution path.

Currently there are several work proposed to evaluate the risk cost for execution process of web service composition. Natallia Kokash et al.[7, 14] explored a method on evaluating risk cost for WSC according to probability of each candidate service. With evaluating risk cost for all combinations of WSC, they selected optimal plans to lead the least probable risk losses. Obviously, they can get optimal plans from the risk losses perspective by considering risk probability for each candidate web service. However, the complexity of their method will increase greatly as the number of combinations for WSC becomes large, and its complexity rises by exponent function. Meanwhile, it’s very hard to calculate the accurate risk cost for CWS because of uncertainty of each single web service hosted on internet. While our method to evaluate risk cost for CWS don’t base on single web service. Since our method is based on algorithm 1,2 and the selection algorithm from literature [8], our complexity is the largest one among these three algorithm which is the selection algorithm from literature [8]. Obviously, the complexity for our method is polynomial. What we do is only historical execution information for each task participating in the WSC evaluated. Therefore, the complexity of ours is lower relative than theirs. At the same time, our method can be in support of web services selection for each task in the specific composition service. Natallia Kokash in the literature [14] also proposed a means of service selection based on failure risk evaluation of composition to improve composition reliability. Our main differences from his work contain following two points. First, our method evaluating failure risk cost is in term of our

Figure 6. The results for different selection methods

proposed failure causing tree that is on the context of transactional service composition. Second, our method for evaluating failure risk cost doesn’t consider the probability of individual service anticipating in composition service so that we needn’t consider all combinations for composition service. Yudistira Asnar et al. [15] refined the Goal-Risk framework introducing the notion of trust for assessing risks on the basis of the organizational setting of the system. The assessment process was enhanced to analyze risks along trust relations among actors. This method to evaluate risk is qualitative, and it doesn’t provide quantitative risk analysis. s

More recently, it appears lots of work on WSC with transactional support. Joyce El Haddad et al. [16]studied a QoS driven web services selection approach by combining transactional property. In terms of transactional behavior characteristic of composition service, they defined two risk levels that are risk0 and risk1, where the level of risk0 guarantees the system that if the execution is successful, and the obtained results can be compensated by the user; while the level of risk1 does not guarantee for the system successful execution. But if it achieves the results, the system cannot be compensated by the users. The selection algorithm proposed in that literature should satisfy the requirement of transactional behavior of composition services firstly, and then based on QoS-driven web service selection approach proposed by Liangzhao Zeng et al. in [2]. It’s distinguishable from our work that we focus on evaluation of risk cost for each task in composition service in order to assign each task to corresponding reliability requirement, and we have predefined transactional properties for each task according to specific business requirements. In the literature [17], the authors proposed a transactional approach for reliable Web services compositions by ensuring the failure atomicity required by the designers. A set of transactional rules had been defined to assist designers to compose a valid composite Web services with regards to the specified ATS. Its failure atomicity theory pays the way for our proposed formation rules of failure causing tree, which supports evaluation of risk cost. In literature [18], the authors explored web service composition with transactional support. They orchestrated web services based on rules including both transactional behaviors and composition patterns.

VII. CONCLUSIONS Current QoS driven service selection methods for WSC

ignore failure risk impact of each task, and few works focus

404404396396

on WSC with transactional properties. In this paper, we have presented a risk driven services selection method for WSC with transactional properties. Within our methods, failure causing tree has been proposed based on failure atomicity of CWS to evaluate risk losses for each task and attain relative impact of each task in transactional execution path of CWS. Then, a linear programming method which is based on impact of each task in execution path can be used to decide requirement of reliability dimension for each task to support selection of concrete web services. Actually, our method reaches the result proved by our experiment that can reduce average losses caused by failures of tasks in scientific computing application such as ensemble prediction application. In our future, we will apply our methods to the practical application of Chinese Ensemble Prediction Application Grid to prove our conclusion further.

REFERENCES [1] L. J. Zhang and H. Cai, "Services Computing", Tsinghua University

Press, Springer, 2007. [2] L. Zeng and B. Benatallah, "QoS-Aware Middleware for Web

Services Composition", IEEE Transactions on Software Engineering, vol. 30(5), pp. 311-327, 2004.

[3] T. Yu and K. Lin, "Service selection algorithms for composing complex services with multiple QoS constraints," in ICSOC: Springer, pp. 130-143, 2005.

[4] D. Ardagna and B. Pernici, "Global and local QoS constraints guarantee in web service selection," in ICWS IEEE Computer Society, pp. 805-806, 2005.

[5] V. Agarwal, G. Chafle, K. Dasgupta, A. Kumar, S. Mittal, and B. Srivastava, "Synthy - A System for End to End Composition of Web Services", Journal of Web Semantics, Vol 3(4), 2005.

[6] W. van der Aalst, A. H. M. T. Hofstede, B. Kiepuszewski, and A. P. Barros, "Workflow pattern" , Distributed and Parallel Databases, Vol. 14(3), pp.5-51, 2003.

[7] Natallia Kokash and Vincenzo D'Andrea, "Evaluating Quality of Web Services - A Risk-Driven Approach," BIS 2007, Poznań, Poland, 2007.

[8] K. Ren, N. Xiao, J. Chen, and J. Song, "A Reverse Order-based QoS Constraint Correction Approach for Optimizing Execution Path for Service Composition", in Monterrey The 16th International conference on cooperative information systems(Coopis 2008), 2008.

[9] H. Karloff, "Linear Programming", Birkhauser, Berlin , 1991. [10] Cardoso J, Sheth A, Miller J, Arnold J, Kochut K, "Quality of Service

for Workflows and Web Service Processes", Journal of Web Semantics, Vol. 1(3), pp.281-308, 2004.

[11] D. Ardagna and B. Pernici, "Adaptive Service Composition in Flexible Processes," IEEE Transaction on Software Engineering, Vol. 33(6), pp. 369-383,2007.

[12] X. Gu and K. Nahrstedt, "On Composing Stream Applications in Peer-to-Peer Environments," IEEE Transactions on Parallel and Distributed Systems, Vol. 17(8), pp. 824-837, 2006.

[13] Jiangxia Wu, Fangchun Yang, "QoS Prediction for Composite Web Services with Transactions," in ICSOC Workshops, 2006.

[14] N. Kokash, "A Service Selection Model to Improve Composition Reliability," In: International Workshop on AI for Service Composition, University of Trento, pp. 9–14 , 2006.

[15] Asnar, Yudistira Giorgini, Paolo Massacci, Fabio Zannone, Nicola, "From Trust to Dependability through Risk Analysis," ARES 2007 Vienna.

[16] Joyce El Haddad, Maude Manouvrier, Guillermo Ramirez, Marta Rukoz, "QoS-Driven Selection of Web Services for Transactional Composition," ICWS, pp.653-660, 2007.

[17] Sami Bhiri, Olivier Perrin, Claude Godart, "Ensuring Required Failure Atomicity of Composite Web Services" in Proceedings of 14th International Conference in WWW 2005, Japan,2005.

[18] Li Li, Chengfei Liu,Junhu Wang, "Deriving Transactional Properties of Composite Web Services", in ICWS, Salt Lake City, UT, 2007.

TABLE I. SEVERAL KINDS OF COSTS FOR EACH TASK IN EXECUTION PATH OF ENSEMBLE PREDICTION

Task Cost

t1 t2 t3 t4 t5 t6 t7 t8 t9 t10 t11 t12 t13 t14 t15 t16 t17

Retry 20 15 30 compensation 30 40 20 20 20 20 20 30 30 30 30 30 25 25 25 15

execution 30 40 35 35 35 35 35 40 40 40 40 40 50 20 20 20 10 loss-taken 20 15 80 80 80 80 80 355 355 355 355 355 705 30

Impact(％) 0.7 α 9.48 9.48 9.48 9.48 9.48 49.64 49.64 49.64 49.64 49.64 100 100 100 100 2.19

Figure 2. An example of failure causing tree: (a) Several dependencies in the execution path of ensemble prediction (b) Failure causing tree of task t13

Failure causing dependency Compensation causing dependency Flow Operator

t13

AND

t8 t9 t10 t11

t3 t4 t5 t6

t12

t7

t2

(t3,nrc)

(t7,nrc)

(t8,nrc)

(t12,nrc)

(t13,nrnc)(t2,rc)

(t16,nrc)

| | (t14,nrc)

(t17,rc)

(t1,rc)

overlapped

405405397397