Conference PaperPDF Available

SAVVY-WS at a glance: Supporting verifiable dynamic service compositions

September 2008

September 2008

DOI:10.1109/ASEW.2008.4686293

Source
DBLP

Conference: 23rd IEEE/ACM International Conference on Automated Software Engineering - Workshop Proceedings (ASE Workshops 2008), 15-16 September 2008, L'Aquila, Italy

Authors:

Domenico Bianculli

University of Luxembourg

Carlo Ghezzi

Politecnico di Milano

Service-oriented architectures support the development of distributed and evolvable applications that live in an open world. We focus on Web service compositions through which new added-value services are provisioned by integrating pre-existing services through a workflow. We assume that such pre-existing services can be selected and bound at run time to support continuous evolution and contextual adaptive policies. We illustrate a methodology and a set of tools supporting both design-time and run-time verification of service compositions.

Content uploaded by Carlo Ghezzi

Content may be subject to copyright.

SAVVY-WS at a glance: supporting veriﬁable dynamic service compositions∗

Domenico Bianculli

University of Lugano - Faculty of Informatics

Lugano, Switzerland

domenico.bianculli@lu.unisi.ch

Carlo Ghezzi

Politecnico di Milano - DEEP-SE group - DEI

Milano, Italy

carlo.ghezzi@polimi.it

Abstract

Service-oriented architectures support the development

of distributed and evolvable applications that live in an

open world.

We focus on Web service compositions through which

new added-value services are provisioned by integrating

pre-existing services through a workﬂow. We assume that

such pre-existing services can be selected and bound at run

time to support continuous evolution and contextual adap-

tive policies.

We illustrate a methodology and a set of tools supporting

both design-time and run-time veriﬁcation of service com-

positions.

1. Introduction

Service-oriented architectures (SOAs) are emerging as

a promising solution to the problem of developing decen-

tralized, distributed, and evolvable applications that live in

an open world [3]. In these architectures, services repre-

sent software components that provide speciﬁc functional-

ity, exposed for possible use by many clients, who can then

dynamically discover the services and access them through

network infrastructures. This emerging scenario is highly

dynamic, open, and decentralized; it is an instantiation of

the open-world software scenario described in [3]: services

may evolve dynamically and autonomously. New services

may be developed and published in registries, and then dis-

covered dynamically by possible clients. Previously avail-

able services may disappear or become unavailable.

The goal of SAVVY-WS (Service Analysis, Veriﬁcation

and Validation methodologY for Web Services) is to sup-

port the development and operation of added-value Web ser-

vices built by composing third-party services through the

∗Part of this work has been supported by the EU project “PLASTIC”

(contract number IST 026995) and by the EU project “S-Cube” (funded

within FP7/2007-2013 under Objective 1.2 “Services and Software Archi-

tectures, Infrastructures and Engineering”).

workﬂow language BPEL [17]. In particular, it supports

veriﬁable compositions, which are guaranteed to satisfy cer-

tain explicitly formulated global correctness properties, in-

volving both functional and non-functional aspects. These

properties are described in the ALBERT assertion language

[2], which is brieﬂy reviewed hereafter.

To support continuous evolution and contextual adapta-

tion of composite services, we need dynamic binding, that

is the ability to dynamically link service invocations from

the workﬂow to speciﬁc service instances. This implies that

at design time we should assume that external services or-

chestrated by the workﬂow are only known through their

speciﬁcations, while their identity will only become known

at run time.

SAVVY-WS supports design-time veriﬁcation by a for-

mal veriﬁcation tool that can check whether a composite

service delivers its expected functionality and meets the re-

quired quality of service, under the assumption that the ex-

ternal services used in the composition fulﬁll their speciﬁ-

cation.

Design-time veriﬁcation, however, does not prevent er-

rors from occurring at run time. In fact, there is no guaran-

tee that a service implementation eventually fulﬁlls the con-

tract promised through its provided interface. The service

provider may either be malicious, by offering a service with

an inferior experienced quality of service and/or a wrong

functionality to increase its revenue on the service provi-

sion, or it might change the service implementation as part

of its standard maintenance process: in this case, a service

that worked properly might be changed in a new version

that violates its previous contract.

Furthermore, during design-time veriﬁcation, it is not

possible to model the behavior of the network, which plays

an important role in the provision of networked services.

Although service providers’ speciﬁcations could take into

account, to some extent, the role of the network, it is vir-

tually impossible to foresee all possible network conditions

during design-time analysis.

To solve these problems, SAVVY-WS supports contin-

uous veriﬁcation by automatically generating run-time as-

sertions that are monitored to check for possible deviations

from the correct behavior veriﬁed at design time. If a devia-

tion is caught, suitable compensation policies and recovery

actions should be activated.

SAVVY-WS is supported by several prototype tools that

are currently being integrated in a comprehensive design

and execution environment.

The paper is organized as follows. Section 2 informally

introduces a simple motivating example of a composite ser-

vice. Section 3 provides a brief introduction to the language

we designed to express properties. Section 4 shows how

SAVVY-WS supports the lifetime of the example composite

service through design-time and run-time veriﬁcation activ-

ities. Section 5 illustrates the related work. Section 6 con-

cludes the paper.

2. Running example: On Road Assistance

This example is inspired by one of the scenarios devel-

oped in the context of the EU IST project SENSORIA1. We

considered the On Road Assistance scenario, which takes

place in an automotive domain, where a SOA interconnects

(the devices running on) a car, service centers providing fa-

cilities like car repair, towing and car rental, and other ac-

tors.

The On Road Assistance process, is supposed to run

on an embedded module in the car and is executed after a

breakdown, when the car becomes not drivable.

The Diagnostic System sends a message with diagnostic

data and the driver’s proﬁle (which contains credit card data,

the allowed amount for a security deposit payment, and

preferences for selecting assistance services) to the work-

ﬂow, which starts by executing the startAssistance re-

ceive activity. Then, it starts a ﬂow (named flow1) contain-

ing two parallel sequences of activities.

In one sequence, the process ﬁrst requests the Bank ser-

vice to charge the driver’s credit card with a security deposit

payment, by invoking the operation requestCardCharge

and passing the credit card data and the amount of the pay-

ment. Then, it waits for the asynchronous reply of the Bank,

modeled by the requestCCCallBack receive activity.

In the other parallel sequence, the process ﬁrst asks the

GPS service —which represents a Web service interface for

the GPS device installed on the car— to provide the posi-

tion of the car (requestLocation invoke activity). The re-

turned location is then used to query (findLocalServices

invoke activity) a Registry to discover appropriate services

close to the area where the car pulled out. The Registry

service will return a sequence of triples —each of which

contains a suitable combination of locally available services

providing car repair shops, car rental, and tow trucking—

stored in the foundServices process variable.

1http://www.sensoria-ist.eu.

Subsequently, this variable is used as an input parame-

ter in the selectServices operation of the Reasoner ser-

vice, which is supposed to select the best available service

triple matching the driver’s preferences, and to store the se-

lected services’ endpoint references in the bestServices

process variable. After assigning (assignPLs assign activ-

ity) the endpoint references to partner links corresponding

to the Garage,Car Rental Agency and Tow Truck Dispatch-

ing Center services, the process ﬁrst sets an appointment

with the garage, by sending to it the car diagnostic data

(orderGarage invoke activity). The garage acknowledges

the appointment by sending back the actual location of the

repair shop.

Afterwards, the process starts a ﬂow (named flow2) with

three activities. Two activities are grouped in a sequence,

where the process ﬁrst contacts the towing service dispatch-

ing center (orderTowTruck invoke activity), and then it

waits for an acknowledgment message ack conﬁrming that

a tow truck is in proximity of the car; this message is con-

sumed by the towTruckProgressNotice receive activity.

The other activity is executed in parallel to the sequence

mentioned above, and is used to contact the car rental

agency (orderRentalCar invoke activity). In both invoke

activities of flow2, the garage location is sent as an input

parameter, representing the coordinates where the car is to

be towed to and where the rental car is to be delivered.

To keep the example simple, we assume that at least

one service triple is retrieved after invoking the Registry,

and that the selected garage, towing service, and car rental

agency can cope with the received requests.

3. ALBERT

The ALBERT assertion language [2] is a temporal spec-

iﬁcation language for stating functional and non-functional

properties of BPEL compositions. It is used in SAVVY-WS

at design time according to an assume/guarantee speciﬁca-

tion and proof pattern. Certain ALBERT properties (AAs–

assumed assertions) specify external services as seen by the

workﬂow: they deﬁne the assumptions made on the exter-

nal services that are composed. Other ALBERT proper-

ties (GAs–guaranteed assertions) deﬁne the properties the

BPEL workﬂow ought to guarantee. GAs precisely state

the proof obligations to be honored at design time. AAs

precisely state the properties to be veriﬁed at run time, when

external service invocations are bound to concrete services,

to ensure that they behave as expected.

ALBERT formulae predicate over internal and external

variables. The former represent data pertaining to the in-

ternal state of the BPEL process in execution. The latter

represent data that are used in the veriﬁcation, but are not

part of the process’ business logic and must be obtained ex-

ternally (for example, by invoking other Web services, or

by accessing some global, persistent data representing his-

torical information).

Given a ﬁnite set of variables Vand a ﬁnite set of natural

constants C, an ALBERT formula φis deﬁned according to

the following grammar:

φ::= χ| ¬φ|φ∧φ|((forall |exists)id

in var ;φ)|Becomes(χ)|Until(φ,φ)|

Between(φ,φ,K)|Within(φ,K)

χ::= ψrelop ψ| ¬χ|χ∧χ|onEvent(µ)

ψ::= var |ψarop ψ|const |

past(ψ,onEvent(µ),n)|count(χ,K)|

count(χ,onEvent(µ),K)|fun(ψ,K)|

fun(ψ,onEvent(µ),K)|elapsed(onEvent(µ))

relop ::= <|≤|=| ≥ | >

arop ::= +|−|×|÷

fun ::= sum |avg |min |max |...

where var ∈V,const ∈C,n∈N,K∈R+and onEvent is

an event predicate. Becomes,Until,Between and Within are

temporal predicates. count,elapsed,past, and all the func-

tions derivable from the non-terminal fun are temporal func-

tions of the language. Parameter µidentiﬁes an event: the

start or the end of an invoke or receive activity, the receipt of

a message by a pick or an event handler, or the execution of

any other BPEL activity. The above syntax only deﬁnes the

language’s core constructs. The usual logical derivations

are used to deﬁne other connectives and temporal operators

(e.g., ∨,Always,Eventually,. . .).

As an example, a functional AA that should hold af-

ter the execution (as a post-condition) of an invoke ac-

tivity Act on an external service Scan be written as

onEvent(end Act)→AA where AA is a predicate on the

values returned by activity Act.

It is also possible to express nonfunctional AAs, such

as latency in a service response. An ALBERT for-

mula that speciﬁes that the duration of an invoke activ-

ity should not exceed 5 time units can be expressed as

onEvent(start Act)→Within(onEvent(end Act),5). We

leave the choice of the most suitable timing granularity to

the veriﬁcation engineer, who can then properly convert the

informal system requirements to formal, real-time speciﬁ-

cations [13].

ALBERT can also be used to express GAs. For exam-

ple, one may state an upper bound to the duration of a cer-

tain sequence of activities, which includes external service

invocations, performed by a composite BPEL workﬂow in

response to a user input request.

ALBERT semantics is deﬁned in [2] rather convention-

ally over a timed state word, an inﬁnite sequence of states

s=s1,s2, . . . , where a state siis a triple (Vi,Ii,ti).Viis

a set of hψ,valueipairs, where ψis an expression that ap-

pears in a formula, Iiis a location of the process and tiis a

time-stamp. States can therefore be considered as snapshots

of the process.

4. SAVVY-WS

SAVVY-WS’s goal is to support, by means of an inte-

grated set of tools, the designers of composite services dur-

ing the veriﬁcation phase, which extends from design time

to run time.

When a service composition is designed, SAVVY-WS

assumes that the external services orchestrated by the work-

ﬂow are only known through their speciﬁcations. The actual

services that will be invoked at run time, and hence their im-

plementation, may not be known at design time. The speci-

ﬁcation describes not only the syntactic contract of the ser-

vice (i.e., the operations provided by the service, and the

type of their input and output parameters), but also their

expected effects, which include both functional and non-

functional properties. Functional properties describe the be-

havioral contract of the service; non-functional properties

describe its expected quality, such as its response time.

Specifying functional and non-functional properties only

at the level of interfaces is required to support lifelong vali-

dation of dynamically evolvable compositions, which mas-

sively use late-binding mechanisms. Indeed, at design time

a service refers to externally invoked services through their

required interface. At run time, the service will resolve its

bindings with external services that provide a matching in-

terface, i.e., their provided interface conforms to the one

used at design time.

Therefore, the second step of the SAVVY-WS-aware de-

velopment process is to annotate the BPEL process with

AAs and GAs written in ALBERT. The BPEL process, an-

notated with ALBERT properties, is then translated by a

tool, BP EL2BI R, into a representation suitable for static

analysis. We use the Bogor model checker [8] to check that

the GAs are satisﬁed, assuming that the external services

behave as speciﬁed by the AAs.

The BPEL process is then put into operation by deploy-

ing it on a standard BPEL engine, which we have extended

with Dynamo, our monitoring framework. At run time, Dy-

namo checks the BPEL process and the external services it

interacts with, for possible deviations from the correct be-

havior veriﬁed at design time.

In the rest of this section, we show how ALBERT can

be used as a speciﬁcation language (Sect. 4.1), how ver-

iﬁcation is performed at design time via model checking

(Sect. 4.2) and how continuous veriﬁcation of service com-

positions can be achieved at run time (Sect. 4.3).

4.1. Specifying the On Road Assistance example

Hereafter we provide some properties of the On Road

Assistance process: each property is ﬁrst stated informally

and then in ALBERT, followed by an additional clarifying

comment, when necessary. We assume that each time tick

of the system represents one minute.

•BankResponseTime: After requesting to charge the

credit card, the Bank will reply within 4 minutes when

a low-cost communication channel is used, and it will

reply within 2 minutes if a high-cost communication

channel is used. In ALBERT this AA can be expressed

as follows:

onEvent(end requestCardCharge)→

(VCG::getConnection()/cost=‘low’∧

Within(onEvent(start requestCCCallBack),4)∨

(VCG::getConnection()/cost=‘high’∧

Within(onEvent(start requestCCCallBack),2))

where VCG is the Web service interface for the local

vehicle communication gateway, providing contextual

information on the communications channels currently

in use within the car. VCG::getConnection()/cost

represents an external variable retrieved by invoking

the getConnection operation on the VCG service and

accessing the cost part of the returned message.

•AllButBankServicesResponseTime: The interactions

with all external services but the Bank, namely GPS,

Registry,Reasoner,Garage,Tow Truck Dispatching

Center and Car Rental Agency will last at most 2 min-

utes. This AA is expressed as a conjunction of formu-

lae, each of which follows the pattern:

onEvent(start Act)→Within(onEvent(end Act),2)

where Act ranges over the names of the invoke activi-

ties interacting with the external services listed above.

•AvailableServicesDistance: The Registry will return

services whose distance from the place where the car

pulled out is less than 50 miles. This AA can be ex-

pressed as follows:

onEvent(end findLocalServices)→

(forall t in $foundServices/[*] ;

(forall s in $foundServices/t/[*] ;

s/distance <50))

where foundServices contains a sequence of triples,

where elements contain a distance message part.

•TowTruckServiceTimeliness: The Tow Truck Dis-

patching Center service selected by the Reasoner will

provide assistance within 50 minutes from the service

request. This AA can be expressed as follows:

onEvent(end selectServices)→

($bestServices/towing/ETA ≤50)

where the ETA message part represents the maximum

time bound guaranteed by a service to provide assis-

tance.

•TowTruckArrival: The time interval between the end

of the order of a tow truck and the arrival of the ack

message (notifying that the tow truck is in proximity

of the car) is bounded by the ETA of the Tow Truck

Dispatching Center service, that is 50 minutes. This

AA can be expressed as follows:

onEvent(end OrderTowTruck)→

Within(onEvent(start TTPN),50)

where TTPN is the short form for

TowTruckProgressNotice.

•AssistanceTimeliness: The tow truck that will be re-

quested will be in proximity of the car within 60 min-

utes after the credit card is charged. This property must

be guaranteed to the user by the On Road Assistance

workﬂow. It is a GA, whose validity is (rather trivially)

assured at design time by the AllButBankServicesRe-

sponseTime, the TowTruckServiceTimeliness and the

TowTruckArrival AAs, and by the structure of the pro-

cess. The property can be expressed as follows:

onEvent(end requestCCCallBack)→

Within(onEvent(start TTPN),60)

4.2. Model checking the On Road Assistance process

Our design-time veriﬁcation phase is based on model

checking. We developed BPEL 2BIR, a tool that translates

a BPEL process and its ALBERT properties into BIR (Bo-

gor’s input language).

A BPEL process is mapped onto a BIR system composed

of threads that model the main control ﬂow of the process

and its ﬂow activities.

Data types are deﬁned using an intuitive mapping be-

tween WSDL messages/XML Schema types and BIR prim-

itive/record types. In this mapping, XML schema simple

types (e.g., xsd:int,xsd:boolean) correspond to their

equivalent ones in BIR (e.g., int and boolean). Moreover,

the mapping also supports some XML schema facets, such

as restrictions on values (e.g., minInclusive) over integer

domains and enumeration, which is translated into an enu-

meration type. For example, the message that is sent by the

Diagnostic System to the process, contains diagnostic data

and the driver’s proﬁle (which includes credit card data, the

allowed amount for the security deposit payment and prefer-

ences for selecting assistance services). This complex type

can be modeled as follows, using a combination of record

types in BIR:

enum TDiagnosticData {dd1 , dd2 }

enum TCustomerPreference {cp 1 , c p 2 }

enum TCreditCard {c c c 1 , c c c 2 }

r e c o r d T Sta rt M sg {

T D i a g n o s t i c D a t a d i a g D a t a ;

TCre di tC a r d c cDa ta ;

int ( 1 , 1 0 ) d e p o s i t ;

TCustomerPreference cpData ;

}

where we assume, based on the WSDL speciﬁcation associ-

ated with the BPEL process, that the amount for the security

deposit payment is an integer value between 1 and 10 and

that dd1, dd2, cp1, cp2, cc c1 and cc c2 are enumeration

values.

The input variables of receive activities and the out-

put variables of invoke activities, whose values result

from interactions with external services, can be modeled

using non-deterministic assignments. For example, the

startAssistance receive activity can be modeled as fol-

lows:

TS t a rt M sg s t a r t M s g ;

startMsg := new TSta rtM sg ;

choose

when <true>do s t a r t M s g . di a g D a t a :=

T D i a g n o s t i c D a t a . d d1 ;

when <true>do s t a r t M s g . di a g D a t a :=

T D i a g n o s t i c D a t a . d d2 ;

end

// s ame p a t t e r n f o r g e n e r a t i n g c r e d i t c a r d

// d a t a a nd c u st o me r ’ s p r e f e r e n c e s

choose

when <true>do s t a r t M s g . d e p o si t : = 1 ;

when <true>do s t a r t M s g . d e p o s i t : = 2 ;

...

when <true>do s t a r t M s g . d e p o s i t : = 9 ;

when <true>do s t a r t M s g . d e p o s i t : = 1 0 ;

end

Activities nested within a ﬂow are translated into separated

threads. In our example, flow1 contains two sequence ac-

tivities; flow2 contains a sequence and an invoke activ-

ity. For each of these activities, we declare a corresponding

global tid (thread id) variable:

tid flow1 sequence1 tid ;

tid flow1 sequence2 tid ;

tid flow2 sequence1 tid ;

tid f l o w 2 i n v o k e 1 t i d ;

For each activity in the ﬂow we declare a thread, named

after the corresponding tid variable. This thread con-

tains the code that models the execution of the corre-

sponding activity. For example, the thread corresponding

to the sequence that includes requestCardCharge and

requestCCCallBack activities, has the following struc-

ture:

thread flow1 sequence1 ( ) {

// c o d e m o d e l i n g r e q u e s t C a r d C h a r g e

// c o d e m o d e l i n g r e q u e s t C C C a l l B a c k

exit ;

}

Finally, the actual execution of a ﬂow is translated into

the invocation of a helper function launchAndWaitFlowi,

which creates and starts a thread for each activity in the

ﬂow, and returns to the caller only when all the launched

threads terminate. This function has the following form (in

the case of flow1):

f u n c t i o n l a u nc h An d Wa i t Fl o w1 ( ) {

boolean temp0 ;

l o c l o c 0 : d o {

flow1 sequence1 tid := start

flow1 sequence1 () ;

flow1 sequence2 tid := start

flow1 sequence2 () ;

}goto l o c 1 ;

l o c l o c 1 : d o {

temp0 := t h r e a d T e r m i n a t e d (

flow1 sequence1 tid)

&& t h r e a d T e r m i n a t e d (

flow1 sequence2 tid);

}goto l o c 2 ;

l o c l o c 2 : wh en temp0 do { } return ;

when ! temp0 do {} go t o l o c 1 ;

}

The assignPL activity is not translated since it only up-

dates the partner link references of the process and thus it

does not change the state of the process.

Once the basic model of the BPEL process has been cre-

ated, it can be then enriched by exploiting assumed asser-

tions. AAs can provide a better abstraction of the values de-

riving from the interaction with external services and they

can also express constraints on the timeliness of the activi-

ties involving external services.

For example, property TowTruckServiceTimeliness rep-

resents a constraint on the value of variable bestServices.

This means that we can restrict the range of the values that

can be non-deterministically assigned to that variable, when

modeling the output variable of the selectServices ac-

tivity. This is shown in the following code snippet:

choose

when <true>do b e s t S e r v i c e s . t ow i ng . ETA : =1 ;

when <true>do b e s t S e r v i c e s . t ow i ng . ETA : =2 ;

...

when <true>do b e s t S e r v i c e s . t ow i ng . ETA := 4 9;

when <true>do b e s t S e r v i c e s . t ow i ng . ETA := 5 0;

end

The next example shows how AAs can be used to deﬁne

time constraints for modeling either the execution time of

or the time elapsed between BPEL activities. The adopted

technique is based on previous work on model checking

temporal metric speciﬁcations [7]. We insert a code block

that randomly generates the duration of the activity within

a certain interval, bounded by the value speciﬁed in an AA.

For ﬂow activities, the time consumed by the ﬂow is the

maximum time spent along all paths. By focusing on flow2

of our example and using properties AllButBankServiceRe-

sponseTime and TowTruckArrival, we get the following

code:

int ( 0 , 5 2 ) f l o w 2 s e q u e n c e 1 c l o c k ;

int ( 0 , 2 ) f l o w 2 i n v o k e 1 c l o c k ;

// o t h e r c od e

thread flow2 sequence1 ( ) {

// c o d e m o d e l i n g o r de r T o wT r u c k

choose