Predictive Failure Recovery in Constraint-aware Web Service

Composition

Touraj Laleh, Joey Paquet, Serguei Mokhov and Yuhong Yan

Concordia University, Montreal, Quebec, Canada

Keywords:

Web Service Composition, Service Constraints, Service Failure Recovery.

Abstract:

A large number of web service composition methods have been proposed. Most of them are based on the

matching of input/output and QoS parameters. However, most services in the real world have conditions or re-

strictions that are imposed by their providers. These condition should be met to ensure the correct execution of

the service. Therefore, constraint-aware service composition methods are proposed to take care of constraints

both at composition and execution time. Failure to meet constraints inside a composite plan results in the fail-

ure of execution of the whole composite service. Recovery from such failures implies service usage rollback

as an alternate plan is found to continue the execution to completion. In this paper, a constraint-aware failure

recovery approach is proposed to predict failures inside a composite service. Then, a method is proposed to

do failure recovery based on those predictions and minimize the number of service rollbacks. The proposed

solution includes an AI-planning-based algorithm and a novel constraint processing method for service failure

prediction and recovery. A publicly available test set generator is used to evaluate and analyze the proposed

solution.

1 INTRODUCTION

Web services are self-contained, self-describing,

modular applications that can be published, located,

and invoked across the Web (Rao and Su, 2005).

Services can be registered and subsequently selected

based on customer’s requirements. However, if there

is no speciﬁc web service that can fulﬁll a customer’s

requirements, there should be a possibility to com-

bine existing services together to accomplish a user-

speciﬁed task. Automatic web-service composition

(AWSC) consists in the automated design of an appro-

priate combination of existing web services to achieve

a global goal. A large number of approaches have

been proposed to solve AWSC and most of them

involve mixing and matching web services compo-

nents according to their input, output and QoS fea-

tures (Ponnekanti and Fox, 2002; L

ecu

e and L

eger,

2006; Berardi et al., 2003; Oh et al., 2008; Zheng and

Yan, 2008; Hashemian and Mavaddat, 2005). There

are limitations and preferences, called constraints,

that must be considered to ensure correct execution of

composite services. Such preferences and limitations

which are speciﬁed by customers are called customer

constraints. Furthermore, services have usage restric-

tions and QoS limitations (called service constraints)

that are imposed by their providers.

For a composite service, the set of constraints are

derived from the union of all constraints of the ser-

vices that compose them. Whenever a composite ser-

vice is executed, all its constraints should be veriﬁed

to ensure its correct execution. Constraint veriﬁcation

for a composite service is different from constraint

veriﬁcation for a single service. The constraints of

an individual service only have to be veriﬁed before

its execution. However, constraints applied on a com-

posite service can be veriﬁed during its execution, as

each individual component service is executed. In-

deed, the veriﬁcation of some individual services con-

straints actually depend on the values that are to be

provided by users or other services during the execu-

tion of a composite service. In this situation, if the

restrictions that are set by these constraints will not

be met at execution time, the service execution fails

and consequently fails the execution of the compos-

ite service. This failure might result in service roll-

backs if some already used services have to be re-

placed in order to successfully execute a composite

service. For example, consider a composite shopping

service including product search, payment and ship-

ment services, where the shipment service can only

ship products to speciﬁc areas in North America. Dur-

ing the execution of a shopping task, if the search

service selects a product outside North America and

Laleh, T., Paquet, J., Mokhov, S. and Yan, Y.

Predictive Failure Recovery in Constraint-aware Web Service Composition.

DOI: 10.5220/0006313802410252

In Proceedings of the 7th International Conference on Cloud Computing and Services Science (CLOSER 2017), pages 213-224

ISBN: 978-989-758-243-1

213

payment service makes a payment, the shipment ser-

vice fails the execution of the whole composite ser-

vice even though the order has already been paid be-

fore the shipment service fails. In this case, the exe-

cution of the payment service needs to be rolled back.

This is an example that shows how service constraint

failure can result in the failure of the execution of a

composite service, where rollback is necessary in or-

der to ﬁx the situation.

Many failure recovery approaches have been pro-

posed to manage and recover failure in the execution

of composite services (Gao et al., 2011). Web service

transaction (WST) approaches (Dolog et al., 2014;

Xu et al., 2016; El Hadad et al., 2010) use recovery

mechanisms, including forward and backward recov-

ery. Forward recovery attempts to reach the original

goal of the composite service by retrying or replacing

components and continuing the process. Backward

recovery is essentially a form of rollback that unrolls

the transaction and tries to ﬁnd another solution.

Some approaches consider component services

constraints in web service composition (Wang et al.,

2014; Wang et al., 2015). In these approaches, con-

straints are embedded inside a composite plan to be

veriﬁed as the composite service is being executed.

However, current failure recovery approaches do

not consider individual service constraints.Therefore,

these approaches are not useful for the execution of

constraint-aware composite services because anytime

a service is added or removed from a composite ser-

vice, the set of constraints of the composite service

needs to be updated accordingly. In addition, fail-

ure recovery approaches start recovery from the bro-

ken point in the plan and if the plan cannot be recov-

ered from the broken point, the results of all services

have been executed before the broken point should

be rolled back (Dolog et al., 2014; Xu et al., 2016;

El Hadad et al., 2010). Wang et. al (Wang et al., 2014)

proposed a formal constraint-aware service composi-

tion method and introduced conditional branch struc-

tures into the process model of a solution. Then

in (Wang et al., 2015), the uncertain effects of com-

posite service execution are managed. In (Xu et al.,

2016) a framework to improve and optimize the suc-

cess rate of transactional composite services is pro-

posed. (Dolog et al., 2014) introduced an approach

to model compensation capabilities and requirements

using a forward recovery approach and proposed a

framework to reduce time and resource waste.

In this paper, a constraint-aware failure predication

and recovery approach is proposed to to reduce the

cost of service failures inside a composite plan us-

ing failure prediction. We provide a novel solution to

assemble a composite service package including all

possible solutions for a service composition problem.

There are approaches that have tried to address

problems related to constraint veriﬁcation, failure re-

covery and web service composition reliability. To the

best of our knowledge, no approach provides a sin-

gle solution for all the above problems. First, through

some real-world business scenarios, we describe the

problem. Second, a new constraint-aware composite

service model is discussed. An algorithm to combine

all possible solutions and create a composite service

package is developed. Finally, two constraint-aware

execution algorithms are developed to enable the ex-

ecution of constraint-aware composite service pack-

ages. Section 1.1 describes a real world business sce-

nario to show the issues involved. Section 1.2 dis-

cusses related work. Section 2 provides deﬁnitions

for our composite service model and discusses re-

search issues, and describes our proposed solutions

for constraint-aware web service composition. Sec-

tion 3 describes our approach to execute constraint-

aware composite services, including recovery upon

failure. A comparative experimental analysis of our

approach versus other solutions is presented and dis-

cussed in Section 4. Finally, Section 5 concludes this

paper.

1.1 Motivation Scenario

Consider a shopping application that consists of a set

of tasks: searching for products, submitting an or-

der, paying for the order, and shipping/delivery of

the order. A customer application makes a request

to the composition engine for a composite service

that lets a user with a DeliveryAddress order a prod-

uct (ProductName) and do the shipment. The user

also speciﬁes a constraint on the cost of the compos-

ite service. The available individual services are de-

picted in Table 1. For instance, the three shipping ser-

vices have different applicable constraints, e.g., the

standard shipping service (w

) is available only for

products whose delivery address is located in Mon-

treal; two-day delivery (w

) is available only for or-

ders whose delivery address is located in the province

of Quebec; while other shipping services (w

and w

)

are available for orders found in the other regions of

Canada. Given the customer constraints and all re-

spective service constraints, Figure 1 shows all pos-

sible composition plans that could fulﬁll the request

from the customer.

Based on what we discussed in Section 1.1,

there are three composition plans for the shopping

service request that can accomplish the shopping

task. In each plan, the shipment service has its

CLOSER 2017 - 7th International Conference on Cloud Computing and Services Science

214

Table 1: Available Services.

# Service Input Output Cost Constraints

Search {ProductName, {ProductNumber, 0.4 C

DeliveryAddress} ProductAddress}

Order/Payment {ProductNumber} {PaymentNumber, 4 C

OrderNumber}

Shipment {PaymentNumber, {ShipmentConﬁrm} 2 C

= DeliveryAddress ∈ Montreal

DeliveryAddress, C

= ProductAddress ∈ Montreal

ProductAddress,

OrderNumber}

Shipment {PaymentNumber, {ShipmentConﬁrm} 2.5 C

= DeliveryAddress ∈ Quebec

DeliveryAddress, C

= ProductAddress ∈ Quebec

ProductAddress,

OrderNumber}

Order {ProductNumber} {OrderNumber} 3 C

Payment {ProductNumber} {PaymentConﬁrm} 3 C

Shipment {PaymentConﬁrm, {ShipmentConﬁrm} 1 C

= DeliveryAddress ∈ Canada

DeliveryAddress, C

= ProductAddress ∈ Canada

ProductAddress,

OrderNumber}

Shipment {PaymentConﬁrm, {ShipmentConﬁrm} 10 C

= ProductAddress ∈ Canada

DeliveryAddress, C

= DeliveryAddress ∈ Canada

ProductAddress,

OrderNumber}

Figure 1: Possible composition plans.

own constraints based on the ProductAddress and

DeliveryAddress of the orders. Consider that a user

wants to use the composite service to buy a book.

Given that the user speciﬁed cost optimization as a

requirement, composition 1 (Figure 1) will be picked

for shopping as the best composite service (minimum

cost). During the execution of the composition plan,

after searching the book (executing w

), it may turn

out that the product address is in Toronto. In this case,

after ordering the product and making the payment

(executing w

), the execution of the shipment service

) fails, as the product’s address is not in Montreal.

In this situation, w

and w

have already been exe-

cuted and their executions results need to be rolled

back.

This example shows that there are constraints (e.g.

shipment constraint related to the delivery address)

that can be veriﬁed before execution of the ﬁrst ser-

vice in the composition plan. However, some ser-

vice constraints can only be veriﬁed during the ex-

ecution (e.g. constraint related to product address)

and their failure can fail the execution of the whole

composite service. These sorts of failures cannot be

predicted at composition time, as the veriﬁcation de-

pends on the values that are going to be produced

during the execution of the composite service (e.g.

ProductAddress). In this situation, a failure recovery

approach is required to recover the plan. In (Xu et al.,

2016; Gao et al., 2011) different dynamic failure

recovery approaches are discussed including back-

ward and forward recovery approaches. These ap-

proaches only start recovery in case a service failure

happens. Backward recovery approaches (El Hadad

et al., 2010) mostly need to rollback effects of ex-

ecuted services (w

and w

) and ﬁnd an alternative

composite service to execute the task. However, as

they do not consider service constraints, the alterna-

tive plans might also fail. For example, the best alter-

native plan (for composition 1) based on cost is com-

position 2, whose execution will fail as a result of the

constraints imposed by w

. Forward recovery based

approaches (Dolog et al., 2014) look for an alternative

service with the same functionality (input/output) to

repair the plan (e.g. w

for w

). However, as forward

recovery approaches do not consider the constraints

of alternative services, the recovered plans might fail

again. Current recovery approaches do not consider

service constraints and that could result in a recovered

plan that fails again. They might ﬁnd an alternative

plan that executes the same services and fail the exe-

cution over and over or they might not even be able to

recover the plan.

Having a constraint-aware composite service

which is aware of its component services constrains

during the execution can help to predict failure and

avoid some wasted executions. For example, if the

composite service execution system is aware of com-

ponent services constraints during the whole execu-

tion process, it could check the shipment service con-

straint right after execution of the search service and

avoid execution of payment service when the product

address is not in the Montreal area. Therefore, the ﬁrst

issue is to design constraint-aware plans to be able to

verify constraints more effectively to predict failures

inside a composition plan. In addition, when failures

are predicted, a constraint-aware failure recovery ap-

proach needs to be used to complete the task. Such

failure recovery approach starts recovery sooner and

minimizes rollbacks. As a result, the second issue

will be designing a constraint-aware failure recovery

mechanism to use failure prediction and start recovery

as soon as a failure is predicted. Finally, the execution

effects of some services are often uncertain because

of the complex and dynamically changing application

environments in the real world. This can cause differ-

ent results in veriﬁcation of the following constraints

inside a composite service. Therefore, the third is-

sue is to design an execution method that can ver-

ify constraints at run-time and make proper decisions

for failure recovery. To the best of our knowledge,

there is no constraint-aware failure recovery approach

that can resolve all of the above-mentioned issues in

which we are interested.

Predictive Failure Recovery in Constraint-aware Web Service Composition

215

1.2 Literature Review

A considerable amount of work has been done in the

theoretical modeling and practical implementation of

web services. In this section, ﬁrst we discuss service

constraints and web service composition. Then, we

review related work on composite service recovery

approaches.

1.2.1 Web Service Composition and Constraints

Web Service composition researches are discussed

into three different categories such as: formal

methods-based approaches (L

ecu

e and L

eger, 2006;

Berardi et al., 2003), AI planning techniques (Oh

et al., 2008; Zheng and Yan, 2008) and graph-search-

based approaches (Hashemian and Mavaddat, 2005;

Wang et al., 2014; Brogi and Corﬁni, 2007).

Graph-based approaches usually construct a ser-

vice dependency graph to show all possible depen-

dencies based on input and output parameters. In

most graph-based approaches the service dependency

graph is a reﬂection of the underlying data inter-

face relationships among services. In this context,

AWSC acts like a graph search problem and ﬁnds

a path either from provided inputs to required out-

puts or vice-versa. Most graph-based approaches do

not consider service constraints and they model ser-

vices based on input/output parameters. Hashemian

et. al (Hashemian and Mavaddat, 2005) uses a mod-

eling tool to convert the WSC problem into a gen-

eral graph problem. Lang et. al (Liang and Su, 2005)

present an AND/OR graph representation of search

dependency graph and its search algorithm for the dis-

covery of composite services. Wang et. al (Wang

et al., 2014) propose a formal constraint-aware ser-

vice composition method. The proposed solution in-

cludes a graph-search-based algorithm which gener-

ates all possible solutions. It then introduces condi-

tional branch structures into the process model of a

solution to solve the problems brought by service con-

straints, in case different services could accomplish

the same task. However, this approach only considers

the situation where different concrete services can be

used for a sub task in a composition plan and does not

discuss how to verify these constraints.

AI planning is another approach for the AWSC

problem in which, given an initial state and a goal

state, a sequence of actions can be acquired automat-

ically through planning (Rao and Su, 2005). This

approach is done in two stages: a forward expan-

sion stage constructs a search graph and a backward

searching stage retrieves a solution (Li et al., 2016).

Some AI planning approaches (McIlraith and Son,

2002) address the web service composition problem

through the provision of high-level generic proce-

dures and customizing users constraints. Moreover,

there are AI planning-based approaches (Oh et al.,

2007; Oh et al., 2008) using heuristic algorithms to

compute the cost of achieving individual parameters

starting from the inputs, and search to approximate

the optimal sequence of services that properly con-

nect inputs to outputs. In addition, many of the AI

planning approaches support the use of precondition

and effects to describe services (Rao and Su, 2005).

For instance, SWORD (Ponnekanti and Fox, 2002) is

a developer toolkit for building composite web ser-

vices using rule-based plan generation. In SWORD,

a service is modeled by its pre-conditions and post-

conditions and a web service is represented in the

form of a Horn rule that denotes that post-conditions

are achieved if the preconditions are true. However,

looking through many of AI planning approaches, the

pre-conditions express the required input parameters

and effects specify expected services outputs which

could be useful only for reasoning during planning. It

is clear that this representation of pre- condition and

effects cannot express other limitations of services

such as service usage constraints as we discussed ear-

lier.

In addition, service composition can be modeled

as an optimization problem (Aggarwal et al., 2004;

Channa et al., 2005). The optimization approach has

appeared under different names such as QoS-driven or

QoS-aware web service composition and web service

composition optimization (Moghaddam and Davis,

2014). In (Hassine et al., 2006), Hassine et al. pro-

pose a constraint-based approach for the service com-

position problem. It provides a generic formaliza-

tion of the web service composition problem as a

constraint-optimization problem and then constructs

a protocol to solve any composition problem by con-

sidering customer constraints. However, service con-

straints are not addressed in this approach.

1.2.2 Failure Recovery Approaches

The problem of failure recovery in web service com-

position is a problem that was discussed in many re-

search works. This problem is addressed in different

domains including software adaptation (Marconi and

Pistore, 2009; Yan et al., 2010a; Laleh et al., 2014)

and web service composition transactions (Gao et al.,

2011; El Hadad et al., 2010; Dolog et al., 2014; Xu

et al., 2016).

Software adaptation is a complementary domain

that was devoted to the generation of mediators (also

called software adapters, or simply adapters) to solve

mismatch between components or services (Papa-

zoglou et al., 2008; Yan et al., 2010a). Replace-

CLOSER 2017 - 7th International Conference on Cloud Computing and Services Science

216

ment is one of the ﬁrst adaptation approaches to re-

act to a faulty service (Grigori et al., 2006; Caval-

laro et al., 2009). Replacement is limited to 1-1 sub-

stitution and it focuses on ﬁnding a replacement for

a broken service by another one. There are differ-

ent solutions for this, such as ﬁnding a service that

can use less input and produce more outputs than the

original one. Replacement is an efﬁcient solution in

terms of computation time, however the limit of re-

placement is that a broken service often cannot be

replaced by another unique service. Re-composition

and repair are two approaches that support 1-n sub-

stitution. Re-composition re-builds the broken ser-

vice by a 1-n substitution. Re-composition could also

go further by using a completely different set of ser-

vices and hence would correspond to an n-m substi-

tution. Repair is also another solution that goes be-

yond the limits of service replacement while avoid-

ing re-composition. This technique aims not only at

keeping most of the above mentioned models as-is

(i.e., not recompute them), but also takes beneﬁt from

them while computing a corrected composition. As

such, repair is a form of heuristic and guided partial

re-composition. In case of 1-1 substitution, repair per-

forms as replacement and is as efﬁcient. In other cases

and for added needs, repair yields better computation

time than re-composition while retrieving solutions of

the same quality (Yan et al., 2010a).

Dynamic transaction support for web services is

another approach to ensure that the composite ser-

vice is executed correctly and achieves the overall de-

sired result (Gao et al., 2011). Transactions are an

approach employed to address system reliability and

fault-tolerance (El Hadad et al., 2010) and the goal

of service composition based on transactional proper-

ties is to ensures a reliable execution of the compos-

ite service. Traditional web services transaction pro-

cessing mechanisms handle exception by forward and

backward recovery approaches (El Hadad et al., 2010;

Dolog et al., 2014). Backward recovery is essentially

a form of rollback that unrolls the transaction and re-

stores the original state of the system. Forward recov-

ery approaches attempt to reach the original goal of

the composite service by retrying or replacing compo-

nents and continuing the process (Meyer et al., 2007;

Yan et al., 2010b). In (Xu et al., 2016) a framework

to optimize the success rate of transactional compos-

ite services is proposed. The framework considers the

success rate of a service to include it as candidate in

the composition process. In this way they improve the

success rate of composite services completing suc-

cessfully and thus reduce the need to employ failure

recovery approaches.

1.3 Our Solution

Figure 2 shows the architecture of our solution includ-

ing two main components: service composition, and

composite service execution. The ﬁrst component de-

signs the composite services while taking into consid-

eration user constraints and service constraints. The

ﬁrst step is to ﬁnd all possible solutions for a compos-

ite service problem. Then, the constraints are adjusted

inside the composite service to enable failure predic-

tion, based on the algorithm we discuss in Section 2.

Finally, a composite service package is assembled to

create a composition including all solutions. The sec-

ond component executes the composite service pack-

age considering the constraints of all individual ser-

vices and recovers from failures.

Figure 2: The architecture of our constraint-aware failure

recovery approach.

2 COMPOSITE SERVICE MODEL

This section discusses our proposed approach for a

constraint-aware composite service. First, we deﬁne

basic concepts such as Service and Constraint that

need to be used later in our model.

Deﬁnition 1. A Service is deﬁned as a tuple s =<

I, O,C,E,QoS > where:

• I is a set of ontology types representing the input

parameters of the service.

• O is a set of ontology types representing the output

parameters of the service.

• C is a set of constraint expressions representing

limitations on services features.

• E is a set of ontology types representing param-

eters whose value are affected as a result of the

execution of the service.

• QoS is the set of quality parameters of the service.

In our deﬁnitions, we used ontology to deﬁne con-

cepts (ontology type) and the relations between them.

QoS criteria determine usability and utility of a ser-

vice (Papazoglou, 2008).

Predictive Failure Recovery in Constraint-aware Web Service Composition

217

We also need to deﬁne Constraint to specify the

limitations on service features (input/output and QoS)

that must be considered to ensure correct execution of

services. A constraint is a function that maps a ser-

vice feature to a set of values. To express constraints

formally, we use the following deﬁnition:

Deﬁnition 2. A Constraint Expression is an expres-

sion that can be evaluated to either true or false.

For simplicity, we restrict ourselves to expressions of

the form: < feature >< operator >< literalValue >,

where:

• < f eature > represents a service feature.

• < operator > represents operators such as

=,6=, <,>,≤, ≥,∈, ⊂,⊃,⊆, ⊇.

• < literalValue > represents a value or a set of

values of the same data type as the expression fea-

ture.

For example, C = cost ≥ 10 expresses a constraint

on the cost QoS feature of a service. In addition, there

needs to be a mechanism to evaluate constraint satis-

faction. Therefore, we deﬁne Satisfaction Degree as

a mechanism to verify constraints.

Deﬁnition 3. If c is a constraint expression and f

is a service feature, Satisfaction Degree (SD(f ,c)) is

a function that calculates a quantitative measure to

evaluate the satisfaction of the value assigned to f

according to c.

For example, if C = cost ≤ 10, for any value as-

signed to cost (cost ← value) :

SD(cost, c) =

(

true value ≤ 10

f alse otherwise

In addition, when there are more than one applicable

constraint, General Satisfaction Degree veriﬁes sat-

isfactions of all constraints.

Deﬁnition 4. If C is a set of constraints and f

is a service feature, General Satisfaction Degree

(GSD( f ,C)) is a function that calculates a quantita-

tive measure to evaluate the satisfaction of the value

assigned to f according to all related constraints in

If C is a set of constraints that includes n con-

straints that are applicable to f : GSD( f ,C) =

∏

SD( f ,c

) In addition, if more than one constraint

targets the same feature in a service, we deﬁne inter-

section as a mechanism to ﬁnd all accepted values for

the service feature according to both constraints.

Deﬁnition 5 . If f is a service feature, and

and c

are two constraints on f , intersection

(Intersection(c

)) is a constraint that expresses all

accepted values for f .

For example, c

= payment Method /∈ {Visa}

and c

= payment Method ∈ {Visa,MasterCard}

express two constraints on payment Method.

Then Intersection(c

) = payment Method ∈

{MasterCard}

Now we can deﬁne the service composition prob-

lem :

Deﬁnition 6. A Service Composition Request R is a

tuple R =< I,O,QoS,C > where:

• I is the set of ontology types representing the input

the customer can provide.

• O is the set of ontology types representing the out-

put expected by the customer.

• QoS is the set of quality parameters expected from

the service by the customer.

• C is the set of constraints representing limitations

of customer-required features.

The result of the service composition algorithm is

the set of all plans that could accomplish the task ex-

pressed by the service composition request. There-

fore, we deﬁne plan as:

Deﬁnition 7. A Plan is a directed graph in which

each node is a service that has sets of predecessor

and successor services.

The predecessor set represents the set of services

that must be executed directly before the execution of

the service node, and successors represent the set of

services that are going to be executed directly after the

execution of a service node in the plan. For example,

for w

in composition 3 (Figure 1), the predecessor

and successor sets are: predecessors(w

) = {w

}

and successors(w

) =

2.1 Constraint-aware Service

Composition

In this section we discuss our solution to introduce

constraint awareness in composite service. Our ap-

proach aims at modeling composite services such that

their constraints can be veriﬁed at runtime to predict

service failures and minimize service rollbacks. The

planning search graph constructs a composition plan

by Algorithm 1, which starts by initiating a list of

temporary plans (tempPlansList) to produce input pa-

rameters (I)(Line 2). Then, it searches into SR (set

of all available services) for services whose input pa-

rameters are available in the input request by the cus-

tomer. This process is repeated and each time new

services are selected form SR to generate new plans

by extending already generated plans (Line 5-8). To

extend a plan using a service, all input parameters of

the service must have been produced by the plan (Line

CLOSER 2017 - 7th International Conference on Cloud Computing and Services Science

218

6). Algorithm 2 adds the new service into the plan. If

the new generated plan could satisfy design-time con-

straints such as the overall cost of the plan, it will be

added to newPlansList (Line 10-11). If a plan pro-

duces the required outputs of the composition prob-

lem (O), it will be added to the list of successful plans

(goalPlansList) (Line 12-16). The algorithm extends

each newly generated plan and this process ends when

the graph reaches a goal in which all parameters in O

are produced or no more services can be added to the

generated plans. If the output parameters cannot be

produced in the search graph, the problem can not be

solved.

Algorithm 1: Service Composition.

Input: R (composition request), SR (set of available

services)

Output: list of plans or failure

1: tempPlansList.Add(initPlan)

2: newPlansList = Null

3: repeat

4: for each plan in tempPlansList do

5: for each service in SR do

6: if (INPUT (service) ⊆

OUT PUT (plan)), and (service not

in plan) then

7: create Plan p

8: p = addService(plan,service)

9: if (CheckConstraints(p, R.C)) then

10: newPlanList.Add(p)

11: if (R.O ⊂ OUT PUT (p)) then

12: p.Add(p

)

13: goalPlansList.Add(p)

14: newPlanList.Remove(p)

15: end if

16: end if

17: end if

18: end for

19: end for

20: tempPlansList = newPlansList

21: until (newPlansList 6= Null)

22: return goalPlansList

In our approach, services can be composed in se-

quence or in parallel. AddService (Algorithm 2) de-

cides the order of the service in the newly created

plan by specifying the predecessor services of each

service in the plan. Therefore, for each input parame-

ters of newService, Algorithm 2 searches back to ﬁnd

the latest service in the plan which produces the in-

put parameter. Then, the service will be added to the

set of predecessor services of newService (Line 4-5).

Besides, the veriﬁcation points of service constraints

will be moved in the plan as early as possible toward

the beginning of the plan in order to enable better

failure prediction. Finally, Algorithm 2 calculates

Algorithm 2: Add Service.

Input: plan (composition plan), newService (A ser-

vice)

Output: plan (composition plan)

1: I = INPU T (newService)

2: i = NumberO f Service(plan)

3: while I 6=

0 do

4: if (OUT PUT (plan.Service(i) ∩

INPUT (newService) 6=

0) then

5: newService.predessesor.Add(plan.Service(i))

6: I = I − (OUT PU T (plan.Service(i)) ∩

INPUT (newService))

7: for (each e ∈ (newService.C. f eatures ∩

plan.Service(i).E)) do

8: plan.Service(i).predecessors.constraints.

Add(newService.Constraint(e))

9: end for

10: else

11: break

12: end if

13: i = i − 1

14: end while

15: for (each preService ∈

(newService.predecessors)) do

16: resp = calculateResponse(preService)

17: if (plan.QoS.ResponseTime <

resp + newService.QoS.ResponseTime)

then

18: plan.QoS.ResponseTime =

newService.QoS.ResponseTime + resp

19: end if

20: end for

21: plan.QoS.Cost = s.QoS.Cost + plan.QoS.Cost

22: plan.Add(newService)

23: return plan

the QoS criterion of the plan using the calculation ap-

proach discussed in (Lee et al., 1999; Li et al., 2016).

In this approach, based on the order that concrete ser-

vices are composed, the algorithm calculates the value

of each QoS criterion of the plan.

2.2 Composite Service Package

The result of Algorithm 2 is a set of constraint-aware

composite plans that could satisfy the initial service

request by the user. During execution, the plan with

the best utility function result value is selected. In

Section 2.1, we discussed how our constraint veri-

ﬁcation approach aims at minimizing service usage

rollbacks resulting from service failure and recovery.

Predictive Failure Recovery in Constraint-aware Web Service Composition

219

Different recovery approaches that can be used in this

situation. One approach can be replacement in which

the execution system stops executing the failed plan

and uses an alternative plan in the set of composite so-

lutions. However, this solution might result in many

rollbacks being required. Besides, like the situation

discussed in Section 1.1 for executing w

and w

composition 1 and composition 2 , the same services

might be executed and their execution results need to

be rolled back several times. Another solution can be

using forward and backward failure recovery mecha-

nisms to recover constraint-aware plans. However, all

forward and backward recovery approaches (Dolog

et al., 2014; Xu et al., 2016) require to replace, add or

remove new services to the broken plan, while adding

a new service could result in a need to repeat the con-

straint adjustment process discussed in Section 2.1.

As a result, we propose the notion of composite

service package to manage failure recovery in a way

to save waste executions and rollbacks, and does not

impose constraint adjustment every time the compo-

sition plan changes.

Deﬁnition 8. A Composite Service Package is a

constraint-aware composition plan including all pos-

sible plans that can accomplish the same task.

Figure 3 depicts a composition package that in-

cludes all composition plans discussed in Section 1.1.

To create a composition package an algorithm is de-

veloped to integrate all possible composition plans

into a composite package. We use the following oper-

ators discussed in (Hamadi and Benatallah, 2003; Wu

et al., 2016) to describe a service composition work

ﬂow and then make a composition package.

• → : Is an operator representing that the second

service is executed when the execution of the ﬁrst

service is ﬁnished.

• ⊕ : Is an operator representing that the two ser-

vices are executed simultaneously.

• ⊗ : Is an operator representing that one of the two

services is selected to be executed.

First of all we add a service (w

) to all the plans to

make all the plans to have the same starting service.

=< I,O,C,E,QoS > is a service where I =

0 and

O = I

where I

is the set of input parameters of

the service composition problem. Now, to combine

all possible composition plans in a composite pack-

age, we start with a plan with the highest utility func-

tion and then gradually add other plans to build the

composition package. During execution of the pack-

age, the plans are going to be executed in this or-

der in the composition package. In Algorithm 3, To

make the composite service package, all plans (like

p = w

→ w

... → w

) need to be converted in a

format as they only have → operator and each w

could be a combination of services which can be ex-

ecuted in parallel (⊕) or individual (⊗). For exam-

ple, composition 3 can be depicted as w

→ w

when w

= w

⊗ w

If p

and p

are two plans such that: p

= w

→

... → w

→ w

k+1

→ .... → w

= w

→ w

... →

→ w

k+1

→ .... → w

and we have : V

= w

→

.... → w

= w

→ .... → w

Then, these two plans

are combined in a plan p: p = w

→ w

... → w

→

⊗ V

) Algorithm 3 gets a set of constraint-aware

plans and creates a composite service package out of

these plans. It starts with considering the ﬁrst plan

as the composite package. Then, in each step, it adds

a new plan to the composite package. Every time a

plan needs to be added to the composition package,

the intersection of the plan with the composite pack-

age should be found (Line 3-12). Then, based on what

we discussed, the two plans should be combined to-

gether (Line 13-16).

Algorithm 3: Composite Package Creation.

Input: P (set of constraint-aware plans)

Output: pkg plan (composition package)

1: pkg plan = P.getPlan()

2: P = P − pkg plan

3: for (each p ∈ P) do

4: i = 0

5: repeat

6: for (each service ∈ pkg plan.service(i)) do

7: if (service /∈ p.service(i)) then

8: break

9: end if

10: end for

11: i = i + 1

12: until (i ≤ pkg plan.length)

13: l

= partialPlan(i + 1, pkg plan.length)

14: l

= partialPlan(i + 1, p.length))

15: tempPlan = l

⊗ l

16: pkg plan = pkg plan.part(i) → tempPlan

17: end for

18: return pkg

plan

3 COMPOSITE SERVICE

PACKAGE EXECUTION

Algorithm 4 proposes a solution to execute a compos-

ite service package. As it is depicted in Figure 3, the

structure of a composite service package is different

from the structure of a simple composite service plan.

In the following, we deﬁne the required concepts and

then discuss the composite service package execution

CLOSER 2017 - 7th International Conference on Cloud Computing and Services Science

220

algorithm in detail.

In AI planning for AWSC, a web service alters the

state of the composite service upon execution. When

a composite service is being executed, the state of

the composite service changes step by step by exe-

cution of each component service. The composite

service execution ends when all component services

have been executed and the output of the ﬁnal service

in the plan is returned as the result of the execution of

the composite service.

Deﬁnition 9. A State is the set of all ontology types

representing all features of the component services in

the plan, each of them being initially assigned NULL

values.

We also need to deﬁne the way that a service

changes a state value by its execution and in which

condition a service can be applicable to a state.

Deﬁnition 10. A service w =< I,O,QoS,C,E > is

applicable to a state S = {< T

7→ v

> ... < T

7→

>}, (where {T

,..., T

} is a set of ontology types

representing all features in a composition plan, and

,...v

} are literal values of the same respective

types) denoted as S  w, if all constraints of the ser-

vice would be satisﬁed based on the values assigned

to the features in S.

Additionally, if a service applies to a state, a state

transition function is applied to change the state of the

composite service execution.

Deﬁnition 11. When service w is applicable to state S

(S  w), a Service Transition Function (γ) is applied

to change the state of service execution to S

: S

γ(S,w).

It should be noted that if all services of a compos-

ite service are composed in sequential order like com-

position 1 in the motivation scenario, the goal state

will be calculated as: G = (γ(γ(γ(S

),w

However, if services are composed in parallel or-

der (like W

and W

in composition 3), the goal

state of the composition will be calculated as: G =

(γ(γ(γ(S

),w

)

γ(γ(S

),w

). Since a

composite service package has a different structure

compared to a regular composite service plan, we pro-

vide a different execution mechanism for it. Figure 3

shows the constraint-aware composite package of the

scenario discussed in Section 1.1. The general idea

behind the composite service package execution is to

execute all plans inside the package one by one. Dur-

ing the execution of each plan, if the veriﬁcation of a

service constraint fails, the execution system prunes

all plans that are related to the failed constraint. Then

the execution continues with one of the remaining

plans. For example for the composition package of

our discussed scenario (Figure 3), the execution starts

with the ﬁrst service (w

) of composition 1. Before

the execution of w

all constraint moved before w

including C

, will be veriﬁed. Then, if

the veriﬁcation of any of them fails, the package will

prune all plans related to the failed constraint. For

example, consider the case where C

fails the veri-

ﬁcation before execution of w

. It means that, based

on the delivery address of the shopped item, the item

cannot be shipped using w

. As a result, any plan

that includes w

(e.g. composition 1) will be pruned

from the composite service package. This process

will continue until all plans are pruned or at least

one plan successfully completes the execution. Algo-

Figure 3: Composition Service Package with Constraints.

rithm 4 represents the recursive approach that is de-

signed to execute a composite service package. The

execution starts from the root and in each step, based

on the item (services/ operator) in the root, the exe-

cution proceeds. To execute a service (or set of ser-

vices) in the root, the algorithm veriﬁes that the set

of constraints of the service in advance. If the veriﬁ-

cation of all constraints succeeds, it executes the ser-

vices (Lines 1-7). However, if the veriﬁcation fails,

the composite package should be pruned.

In addition, if there is an operator in the root, the

algorithm should make the right decision to continue

the execution of the plan (Lines 13-28). To do that, it

ﬁrst starts with computing the left and right sub-trees

of the composition tree. Then, based on the operator

in the root, it continues the execution. For →, ﬁrst

the left sub-tree should be executed. Then, after it ﬁn-

ished successfully, the right sub-tree will be executed.

⊗ means execution of one of the left or right sub-tree

is enough. Finally, ⊕ means both sub-tree must be

executed in parallel.

Predictive Failure Recovery in Constraint-aware Web Service Composition

221

Algorithm 4: Composite Package Execution.

Input: pkg plan (a composition package), S

(initial

state of execution)

Output: either goal state or NULL

1: if (IsService(pkg plan) then

2: if (GSD(s

, pkg plan.C)) then

3: StateList[pkg plan] = γ(pkg plan,S

)

4: return StateList[pkg plan]

5: else

6: Prune(pkg plan)

7: end if

8: else

9: operator = getOperator(pkg plan)

10: t

= Le f t(pkg plan,operator)

11: t

= right(pkg plan,operator)

12: if (operator is →) then

13: temp = executionTree(t

)

14: result = executionTree(t

,temp)

15: end if

16: if (operator is ⊗) then

17: result = Null

18: result = executionTree(t

)

19: if (result is Null) then

20: result = executionTree(t

)

21: end if

22: end if

23: if (operator is ⊕) then

24: temp1 = executionTree(t

)

25: temp2 = executionTree(t

)

26: result = combine(temp1,temp2)

27: end if

28: end if

29: return Null

4 EXPERIMENTAL RESULTS

This section presents experimental results compar-

ing the proposed composite service package execu-

tion approach with other failure recovery approaches

including replacement, re-planning, re-composition

and repair (Section 1.2). First we generated 5 dif-

ferent data sets using the WSC 2009 Testset Gener-

ator (WS-Challenge, 2009). Each data set contains a

WSDL ﬁle which is the repository of web services.

An OWL ﬁle lists the relationship between concepts

and things. The number of services for each dataset

are around 4000, and the number of concepts varies

from 3000 to 3500 accordingly. In addition, the num-

ber of solutions in each dataset varies from 2 to 4 so-

lutions. Since the generated data using this genera-

tor is not oriented to service composition considering

constraints (C) and effects (E), in the following exper-

iments we augmented the data sets with sets of effects

to different services to meet our experimental needs.

As we discussed in Section 2, E represents set of pa-

rameters whose value are affected as a result of the

execution of the service. Therefore, for each service

we consider the set of output parameters as the set E.

In addition, in each service, for any item in E, a con-

straint is considered. However, instead of generating

a constraint expression and a satisfaction degree for

that, we deﬁned a boolean variable to only consider

the result of satisfaction of the constraint. This vari-

able is initialized to true for all constraints. Then to

simulate a service failure, we change values of all its

constraints to false inside the plan.

To test the effectiveness of our approach we ran-

domly failed services inside composite solutions and

our composite service package. Then, different ap-

proaches were compared to see how many rollbacks

were imposed as a result of the failure recovery. In

re-composition, replacement and repair approaches,

if the plan cannot be recovered, all the services until

the broken point need to be rolled back. Each point

is obtained from the average of 3 independent runs

which in total is 15 different runs.

We compare all approaches from two aspects in-

cluding the number of rollbacks (Figure 4) and the

computation time (Figure 5). Figure 4 depicts the re-

sults of our experiments in terms of the number of

rollbacks. It shows that re-planning imposes more

rollbacks than other approaches. The reason is that

every time a failure happens, re-planning needs to de-

sign the plan from the beginning. It is also clear that

our approach imposes the fewest number of rollbacks

compared to other approaches. This is due to the fact

that our solution potentially reuses partially executed

parts that are common between the current failed plan

and its alternative selected after the failure. Our solu-

tion also allows to predict some failures that are going

to happen later and to avoid going forward on a plan

that we know is going to fail, thus saving rollbacks by

predicting failure.

We also compared all approaches based on the

computation time required to proceed with failure re-

covery (Figure 5), i.e. the time that the algorithm re-

quires to do the recovery. Replacement is the fastest

technique as it only requires one comparison with

each available service in the repository. Re-planning

has the worst time as it is the same as running the

composition algorithm from the beginning after ex-

cluding failed services from the repository. In addi-

tion, the performance of our approach is not signiﬁ-

cantly different from repair and re-composition.

We also compared the success rate of the differ-

ent approaches, i.e. the proportion of eventually suc-

CLOSER 2017 - 7th International Conference on Cloud Computing and Services Science

222

cessful execution of a composite service. Among all

approaches, re-planning and composite service pack-

aging have better success rate as, unlike other ap-

proaches, they can step back from the broken point

in the plan and start recovery. However, other ap-

proaches only move the plan forward during failure

recovery. Replacement only looks for a service with

the same same inputs/outputs and concepts. Repair

and re-composition look for a new path to re-build

the composition plan.

Figure 4: Number of rollbacks.

Figure 5: Time performance of different approaches.

5 CONCLUSION AND FUTURE

WORK

In this paper, a constraint-aware failure recovery ap-

proach is proposed to ﬁrst predict failures inside a

composite service and, upon failure, proceed with re-

covery based on those predictions to reduce the num-

ber of rollbacks. We compared our approach to other

failure recovery approaches from different perspec-

tives. The experimental results demonstrate that our

approach better minimizes the number rollbacks that

are imposed as a result of failure recovery compared

to other approaches. However, it is clear that our ap-

proach has limitations in cases where the number of

possible solutions is potentially very large. We plan to

use genetic algorithms to solve this problem as an op-

timization problem and come up with a local optimal

set of solutions.

REFERENCES

Aggarwal, R., Verma, K., Miller, J., and Milnor, W. (2004).

Constraint driven web service composition in meteor-

s. In Services Computing, 2004. (SCC 2004). Pro-

ceedings. 2004 IEEE International Conference on,

pages 23–30.

Berardi, D., Calvanese, D., De Giacomo, G., Lenzerini,

M., and Mecella, M. (2003). Automatic compo-

sition of e-services that export their behavior. In

Service-Oriented Computing-ICSOC 2003, pages 43–

58. Springer.

Brogi, A. and Corﬁni, S. (2007). Behaviour-aware discov-

ery of web service compositions. International Jour-

nal of Web Services Research, 4(3):1.

Cavallaro, L., Di Nitto, E., and Pradella, M. (2009). An au-

tomatic approach to enable replacement of conversa-

tional services. In Service-Oriented Computing, pages

159–174. Springer.

Channa, N., Li, S., Shaikh, A. W., and Fu, X. (2005). Con-

straint satisfaction in dynamic web service composi-

tion. In Database and Expert Systems Applications,

2005. Proceedings. Sixteenth International Workshop

on, pages 658–664. IEEE.

Dolog, P., Sch

afer, M., and Nejdl, W. (2014). Design and

management of web service transactions with forward

recovery. In Advanced Web Services, pages 3–27.

Springer.

El Hadad, J., Manouvrier, M., and Rukoz, M. (2010). Tqos:

Transactional and qos-aware selection algorithm for

automatic web service composition. IEEE Transac-

tions on Services Computing, 3(1):73–85.

Gao, L., Urban, S. D., and Ramachandran, J. (2011). A

survey of transactional issues for web service compo-

sition and recovery. International Journal of Web and

Grid Services, 7(4):331–356.

Grigori, D., Corrales, J. C., and Bouzeghoub, M. (2006).

Behavioral matchmaking for service retrieval. In

2006 IEEE International Conference on Web Services

(ICWS’06), pages 145–152. IEEE.

Hamadi, R. and Benatallah, B. (2003). A petri net-based

model for web service composition. In Proceedings

of the 14th Australasian database conference-Volume

17, pages 191–200. Australian Computer Society, Inc.

Hashemian, S. V. and Mavaddat, F. (2005). A graph-based

approach to web services composition. In The 2005

Symposium on Applications and the Internet, pages

183–189.

Hassine, A. B., Matsubara, S., and Ishida, T. (2006). A

constraint-based approach to horizontal web service

composition. In The Semantic Web-ISWC 2006, pages

130–143. Springer.

Laleh, T., Khodadadi, A., Mokhov, S. A., Paquet, J.,

and Yan, Y. (2014). Toward policy-based dynamic

context-aware adaptation architecture for web service

composition. In Proceedings of C3S2E’14, pages

158–163. Short paper.

ecu

e, F. and L

eger, A. (2006). A formal model for seman-

tic web service composition. In The Semantic Web-

ISWC 2006, pages 385–398. Springer.

Predictive Failure Recovery in Constraint-aware Web Service Composition

223

Lee, C., Lehoezky, J., Rajkumar, R., and Siewiorek, D.

(1999). On quality of service optimization with dis-

crete qos options. In Proceedings of the Fifth IEEE

Real-Time Technology and Applications Symposium,

pages 276–286.

Li, J., Yan, Y., and Lemire, D. (2016). Full solution index-

ing for top-k web service composition. IEEE Trans-

actions on Services Computing, PP(99):1–1.

Liang, Q. A. and Su, S. Y. (2005). And/or graph and

search algorithm for discovering composite web ser-

vices. International Journal of Web Services Re-

search, 2(4):48.

Marconi, A. and Pistore, M. (2009). Synthesis and compo-

sition of web services. In Bernardo, M., Padovani, L.,

and Zavattaro, G., editors, Formal Methods for Web

Services, volume 5569 of Lecture Notes in Computer

Science, pages 89–157. Springer Berlin Heidelberg.

McIlraith, S. and Son, T. C. (2002). Adapting golog for

composition of semantic web services. KR, 2:482–

493.

Meyer, H., Kuropka, D., and Tr

oger, P. (2007). Asg-

techniques of adaptivity. In Autonomous and Adaptive

Web Services.

Moghaddam, M. and Davis, J. G. (2014). Service selection

in web service composition: A comparative review

of existing approaches. In Web Services Foundations,

pages 321–346. Springer.

Oh, S.-C., Lee, D., and Kumara, S. R. (2008). Effective web

service composition in diverse and large-scale service

networks. Services Computing, IEEE Transactions

on, 1(1):15–32.

Oh, S.-C., Lee, D., and Kumara, S. R. T. (2007). Web ser-

vice planner (wspr): An effective and scalable web

service composition algorithm. Int. J. Web Service

Res., 4(1):1–22.

Papazoglou, M. (2008). Web services: principles and tech-

nology. Pearson Education.

Papazoglou, M. P., Traverso, P., Dustdar, S., and Leymann,

F. (2008). Service-oriented computing: a research

roadmap. International Journal of Cooperative Infor-

mation Systems, 17(02):223–255.

Ponnekanti, S. R. and Fox, A. (2002). Sword: A developer

toolkit for web service composition. In Proc. of the

Eleventh International World Wide Web Conference,

Honolulu, HI, volume 45.

Rao, J. and Su, X. (2005). A survey of automated web ser-

vice composition methods. In Cardoso, J. and Sheth,

A., editors, Semantic Web Services and Web Process

Composition, volume 3387 of Lecture Notes in Com-

puter Science, pages 43–54. Springer Berlin Heidel-

berg.

Wang, P., Ding, Z., Jiang, C., and Zhou, M. (2014).

Constraint-aware approach to web service composi-

tion. IEEE Transactions on Systems, Man, and Cy-

bernetics: Systems, 44(6):770–784.

Wang, P., Ding, Z., Jiang, C., Zhou, M., and Zheng, Y.

(2015). Automatic web service composition based on

uncertainty execution effects.

WS-Challenge (2009). Testsetgenera-

tor2009. https://code.google.com/p/wsc-pku-

tcs/downloads/list.

Wu, Q., Ishikawa, F., Zhu, Q., and Shin, D. H. (2016). Qos-

aware multigranularity service composition: Model-

ing and optimization. IEEE Transactions on Systems,

Man, and Cybernetics: Systems, PP(99):1–13.

Xu, J., Li, Z., Chi, H., Wang, M., Guan, C., Reiff-

Marganiec, S., and Shen, H. (2016). Optimized com-

posite service transactions through execution results

prediction. In Web Services (ICWS), 2016 IEEE Inter-

national Conference on, pages 690–693. IEEE.

Yan, Y., Poizat, P., and Zhao, L. (2010a). Repair vs. recom-

position for broken service compositions. In Service-

Oriented Computing, pages 152–166. Springer.

Yan, Y., Poizat, P., and Zhao, L. (2010b). Repairing ser-

vice compositions in a changing world. In Lee, R.,

Ormandjieva, O., Abran, A., and Constantinides, C.,

editors, Proceedings of SERA 2010 (selected papers),

volume 296 of Studies in Computational Intelligence,

pages 17–36. Springer Berlin Heidelberg.

Zheng, X. and Yan, Y. (2008). An efﬁcient syntactic web

service composition algorithm based on the planning

graph model. In Proceedings of the IEEE Interna-

tional Conference on Web Services (ICWS’08), pages

691–699. IEEE.

CLOSER 2017 - 7th International Conference on Cloud Computing and Services Science

224