HAL Id: inria-00381551https://hal.inria.fr/inria-00381551

Submitted on 5 May 2009

HAL is a multi-disciplinary open accessarchive for the deposit and dissemination of sci-entific research documents, whether they are pub-lished or not. The documents may come fromteaching and research institutions in France orabroad, or from public or private research centers.

L’archive ouverte pluridisciplinaire HAL, estdestinée au dépôt et à la diffusion de documentsscientifiques de niveau recherche, publiés ou non,émanant des établissements d’enseignement et derecherche français ou étrangers, des laboratoirespublics ou privés.

Formal Modeling and Discrete-Time Analysis of BPELWeb Services

Radu Mateescu, Sylvain Rampacek

To cite this version:Radu Mateescu, Sylvain Rampacek. Formal Modeling and Discrete-Time Analysis of BPELWeb Services. International Journal of Simulation and Process Modelling, Inderscience, 2008,�10.1504/IJSPM.2008.023680�. �inria-00381551�

Formal Modeling andDiscrete-Time Analysis ofBPEL Web Services

Radu MateescuInria / Vasy project-team, Centre de Recherche Grenoble – Rhone-Alpes655, avenue de l’Europe, Montbonnot, F-38334 Saint Ismier Cedex, FranceE-mail:Radu.Mateescu@inria.fr

Sylvain RampacekLe2i, Faculte des Sciences Mirande, Aile de l’Ingenieur,Universite de Bourgogne, BP 47870, F-21078 Dijon Cedex, FranceE-mail:Sylvain.Rampacek@u-bourgogne.fr

Abstract: Web services are increasingly used for building enterprise information sys-tems according to the Service Oriented Architecture (Soa) paradigm. We propose inthis paper a tool-equipped methodology allowing the formal modeling and analysis ofWeb services described in the Bpel language. The discrete-time transition systemsmodeling the behavior of Bpel descriptions are obtained by an exhaustive simulationbased on a formalization of Bpel semantics using the Algebra of Timed Processes(Atp). These models are then analyzed by model checking value-based temporal logicproperties using the Cadp toolbox. The approach is illustrated with the design of aWeb service for Gps navigation.

Keywords: Web services, formal specification, model checking, exhaustive simulation,process algebra.

1 Introduction

Information systems present in companies and organiza-tions are complex software artifacts involving concurrency,communication, and coordination among various applica-tions that exchange data and participate to business pro-cesses. Service Oriented Architecture (Soa) [18] is a state-of-the-art methodology for developing information systemsby structuring them in terms of services, which can be dis-tributed and composed over a network infrastructure toform complex business processes. Web services are a usefulbasis for implementing business processes, either by wrap-ping existing software or by creating new functionalities ascombinations of simpler ones. Bpel (Business Process Ex-ecution Language) [17] is a standardized language of wideindustrial usage for describing abstract business processesand detailed Web services. It allows to capture both thebehavioral aspects (concurrency and communication) andthe timing aspects (duration of activities) of Web services.

The Bpel language allows to create Web services ei-ther from scratch, or as the composition of existing sub-services, which can be invoked sequentially (one at a time)or concurrently (several ones at the same time). Each Webservice described in Bpel can be used as a sub-service byother Web services (described in Bpel or not), thus en-

abling a hierarchical construction of complex Web services.A Bpel business process is defined by a workflow consist-ing of various steps, which correspond internally to algo-rithmic computations (possibly with time constraints) andexternally to message-passing interactions with a client.Business processes are typically built upon existing Webservices (although this is not mandatory), each one beingspecialized for carrying out a particular task. These sub-services are invoked every time a specific information isneeded during a step of the workflow; therefore, a businessprocess is not simply the set of sub-services it is built upon,but acts as an orchestrator of these sub-services in orderto provide newly added functionalities.

The conjunction of concurrency and timing constraintsmakes business processes complex and requires a carefuldesign in order to avoid information losses and to obtaina satisfactory quality of service. In this context, formalmodeling and analysis techniques available from the do-main of concurrent systems allow to improve the qualityof the design process and to reduce the development costsby detecting errors as soon as possible during the businessprocess life cycle. These techniques can operate success-fully on languages equipped with a formal semantics defi-nition, from which suitable models can be constructed andanalyzed automatically.

1

In this paper, we propose a tool-supported approach forthe formal modeling and analysis of business processes andWeb services described in Bpel. Our approach consists ofthe following ingredients: the definition of a formal se-mantics of Bpel in terms of process algebraic rules, tak-ing into account the discrete-timing aspects [13, 14]; theautomated generation of models (state/transition graphs)from the Bpel specifications using an exhaustive simula-tion based on the formal semantics rules, implemented inthe WSMod tool; and the analysis of the resulting modelsby using standard verification tools for concurrent systems,such as Cadp [11]. We illustrate the application of this ap-proach to the design and discrete-time analysis of a Webservice for Gps navigation.

Related work. The modeling and analysis of Web ser-vices benefits from a considerable attention in the researchcommunity. The Wsat tool proposed in [7, 8] gives toWeb service designers the possibility of verifying Ltl prop-erties on Bpel business processes by applying the Spinmodel checker. Each Bpel process is transformed into aPromela model (via a pattern) and connected to otherprocesses in the description. This work covers only theuntimed aspects of Bpel.

Another approach, proposed in [32], uses the Cress(Chisel Representation Employing Systematic Specifica-tion) notation for specifying the untimed behavior of Webservices. Cress descriptions are translated into the for-mal description technique Lotos [16] and analyzed withdedicated tools, such as Topo, Lola or Cadp. A directtranslation from Bpel to Lotos is given in [6], enablingthe use of the aforementioned tools for analyzing the un-timed behavior of Web services. Bpel was also used as tar-get language for producing executable Web services fromLotos specifications [2, 28]; this allows to combine the ad-vantages of the formal verification using Cadp and of thedeployment and execution features of Bpel.

Compared to existing work, our approach differs in thefollowing respects: it is based on a translation of Bpeldirectly into state/transition graphs, without using an in-termediate language such as Promela or Lotos, thus be-ing potentially more efficient; and it handles not only thebehavioral, but also the discrete-time aspects of Bpel de-scriptions.

Paper outline. Section 2 presents our methodology andsoftware platform for modeling and analyzing Bpel de-scriptions. Section 3 describes the Gps Web service case-study and its analysis using the platform. Finally, Sec-tion 4 gives some concluding remarks and directions forfuture work.

2 Modeling and Analysis Approach

Web services can be seen as complex distributed systemsthat communicate by message-passing. Therefore, their

design methodology can be naturally supported by the for-mal modeling and analysis techniques stemming from thedomain of concurrent systems. To apply these techniques,it is necessary to represent the dynamic behavior of Webservices in a formal, non-ambiguous manner.

The approach we propose for the modeling and anal-ysis of Web services described in Bpel is illustrated inFigure 1. Our software platform consists roughly of twoparts, described in the sequel: the Bpel descriptions arefirst translated into discrete-time Ltss using the WSModtool, and are subsequently analyzed using the Cadp veri-fication toolbox.

2.1 Translation from BPEL to discrete-time LTSs

The behavior of a Web service comprises not only theconcurrency and communication between its various con-stituent activities, but also the delay of response of theservice. These aspects can be modeled using dtLtss(discrete-time Labeled Transition Systems), i.e., state/-transition graphs in which every transition is labeled by anaction performed by the Web service. The actions are ofthe following kinds: emissions and receptions of messages,prefixed by ’ !’ and ’?’, respectively; elapsing of time, rep-resented by the symbol χ (discrete-time tick, also notedtime); the internal action τ (or tau) denoting unobserv-able activity of the service; and the terminating action

√

(or done), which is the last internal action that a servicecan do.

The global behavior of the Web service (and therefore,the actions it can perform) is obtained by an exhaus-tive simulation of the Bpel description, performed by theWSMod tool (see Figures 2, 3), which is able to handleboth discrete [13] and continuous [14] time representations.WSMod takes two different inputs (see Figure 1):

• A Web service description in Bpel [17], a standard-ized language allowing to specify the behavior of busi-ness processes. Bpel supports two different types ofbusiness processes: executable processes specify thebehavior of business processes in full detail, such thatthey can be executed by an orchestration engine; andabstract business protocols specify the public messageexchanges between the service and a client (i.e., ex-cluding the message exchanges which take place inter-nally, e.g., during invocations of sub-services).

• A formal representation of the Bpel semantics, basedon the Algebra of Timed Processes (Atp) [27], whichspecifies using operational rules how the model of thebusiness process behavior is generated. Depending onthe time representation chosen, the resulting model iseither a dtLts, or a timed automaton (Ta) [1]. TheAtp rules formalizing the Bpel semantics in discrete-time is shown in Table 1. For example, the process“time” can only elapse time (represented by the χaction), and the process “receive” or “reply” can sendor receive a message (first rule) or elapse time too(second rule).

2

Figure 1: Platform for Web service modeling and analysis

Figure 2: Screenshot of the WSMod tool

Figure 3: Main functionality of WSMod tool (dtLts: discrete-time Lts, Ta: timed automaton)

To generate the model representing the behavior of theinput Bpel description, WSMod performs an exhaustivesimulation guided by the operational Atp rules. The toolis also able to synthesize automatically the model of anadapted client interacting with the Web service, whose be-

havior complies with that of the service as regards emis-sion and reception of messages, time elapsing, etc (see Fig-ure 3). In this study, we focus only on the Web servicemodel generation feature of WSMod in discrete time.

3

Table 1: The process algebra formalizing BPEL, in discrete-time

BPEL ATP

empty empty√

−−−→ 0

time timeχ−−→ time

throw ∀ e ∈ EX , throw[e]e−−→ 0

with EX set of exceptions that can be thrown.

receive / ∗o[m]∗m−−−−→ empty with ∗ ∈ {?, !}

reply ∗o[m]χ−−→ ∗o[m]

sequence ( ; ) ∀ a 6= √, P

a−−→P ′

P ; Qa−−→P ′ ; Q

∀ a, P

√−−−→P ′ ∧ Q

a−−→Q′

P ; Qa−−→Q′

switch switch[{Pi}i∈I ] – ∀ i ∈ I, switch[{Pi | i ∈ I}] τ−−→ Pi

while while[P ]τ−−→ P ; while[P ]

while[P ]τ−−→ empty

scope Let MI = {mi | i ∈ I} a set of messages andlet EJ = {ej | j ∈ J} a set of exceptions.

scope(P, E) with E = [{(mi, Pi) | i ∈ I}, (d, Q), {(ej, Rj) | j ∈ J}]P

√−−−→

scope(P,E)

√−−−→0

∀ a /∈ {χ,√} ∪ EX ∪ MI

Pa−−→P ′

scope(P,E)a−−→scope(P ′,E)

d > 1, Pχ−−→P ′ and ∀ a∈EX∪{τ,

√}, ¬(Pa−−→)

scope(P,Ed)χ−−→scope(P,Ed−1)

Pχ−−→P ′ and ∀ a∈EX∪{τ,

√}, ¬(Pa−−→)

scope(P,E1)χ−−→Q

∀ i ∈ I, ∀ a∈EX∪{τ,√}, ¬(P

a−−→)

scope(P,E)?mi−−−−→Pi

∀ j ∈ EJ , Pej−−−→

scope(P,E)τ−−→Rj

∀ e /∈ EJ , Pe−−→

scope(P,E)e−−→0

pick pick[E] = scope(time, E)with E = [{(mi, Pi) | i ∈ I}, (d, Q), {(ej, Rj) | j ∈ J}

flow flow[{Pi}i∈I}] executes simultaneously the set of processes {Pi}.∀ a ∈ EX ∪ {τ}, ∃ j∈I, Pj

a−−→P ′

flow[{Pi | i∈I}] a−−→flow[{Pi | i∈I\{j}}∪{P ′}]

∀m ∈ M,∃ j∈I, Pj

∗m−−−−→P ′ and ∀ i6=j, ∀ a∈EX∪{τ}, ¬ ∃k∈I, (Pk

a−−→)

flow[{Pi | i∈I}] ∗m−−−−→flow[{Pi | i∈I\{j}}∪{P ′}]∀ i∈I, Pi

√−−−→0

flow[{Pi | i∈I}]√

−−−→0

∃J 6=∅, J⊆I, ∀ i∈J, Pi

χ−−→P ′i and ∀ i∈I\J, Pi

√−−−→

flow[{Pi}i∈I ]χ−−→flow[{P ′

i}i∈J∪{Pi}i∈I\J ]

2.1.1 BPEL Process to ATP

This section describes shortly each algebra rule presentedin Table 1. In fact, each process described here correspondsto a process in Bpel language. For readability, we do notfollow the (verbose) Xml syntax of a Bpel process.

The empty process can only terminate (the notation 0is the null process).

The time process can only elapse time (represented bythe χ action).

The throw process can raise an exception. Generally,in a correct specification, the exception must the catchedin some scope process.

The receive or reply process can send (!o[m]) or receive(?o[m]) a message (first rule) or elapse time too (secondrule). They correspond to input/output Wsdl operations.

4

The sequence P ; Q process executes the process P fol-lowed by the process Q. Since the operator “;” is asso-ciative, we safely restrict the number of operands to twoprocesses. The sequence process acts as its first subprocesswhile this process does not indicate its termination. In thelatter case, the sequence process acts as the second processcan do.

The switch[{Pi}i∈I ] process chooses to execute one ofPi process. In Bpel, the choice is done internally by theWeb service: the client doesn’t know the result of the con-dition evaluation. So, we translate this choice by the in-ternal action (τ).

The while[P ] process executes the process P as longas an internal condition is evaluated at true. Again, theclient does not know the result of the condition evaluation.

The scope(P, E) process executes the process P accord-ing to some events and guards (timing and exception) de-fined by the Web services and represented here by the ex-pression E = [{(mi, Pi) | i ∈ I}, (d, Q), {(ej , Rj) | j ∈ J}],where:

• mi are the events and Pi the associated processes trig-gered;

• d the maximum execution time unit for process P(otherwise, the process Q is executed);

• ej the exceptions that can be catched and Rj the as-sociated processes triggered.

The pick process is a particular case of scope in whichthere is no main process (and more precisely, only one thatconsist to elapse time).

The flow[{Pi}i∈I}] process executes simultaneously theset of processes Pi, according to the rules concerning time,exceptions, etc. In Bpel, there is a mechanism that en-ables the Web service to do some synchronization depen-dencies (links) that is not present in the rules, but takeninto account in the WSMod tool.

2.1.2 Transition system synthesis

Transition system synthesis begins from the algebra rules(describe in Table 1) and the intermediate language (seeFigure 3). This intermediate language is based on a syn-tactical tree. We can remark that the root of the syntac-tical tree is the global business process, which denotes theglobal behavior of the Web service.

By analysing its root according to the algebra rules, wecan infer a set of actions that can be executed: these ac-tions will be represented by transitions in the dtLts. Dueto the structure of the global expression representing thebusiness process, it can be useful to repeat the analysisrecursively to refine the set of actions.

?a

?aχ→?a

?aa→ empty

(a) Process ?a

?a; !b

?a; !bχ→?a; !b

?a; !bb→ empty; !b

(b) Process ?a; !b

!b or empty; !b

!bχ→!b

!bb→ empty

(c) Process !b

empty

empty√→ 0

(d) Process empty

Figure 4: Actions set synthesis example for the process?a; !b, in discrete time.

For example, we can take the process “?a; !b” corre-sponding to the reception of an “a” message, followed se-quentially by the reply of a “b” message. The set of actionsthat a process sequence can do, depends on the first pro-cess in it. So, we must analyze, first, the process “?a”.This process can do two actions: (i) the time elapsing or(ii) receiving the message “a” (see Figure 4(a)). Next, wemust verify the compatibility of the process “?a” actionswith each guard of sequence process, and then, determinethe action set that this one can realize. Here, the two setsare identical.

The “empty; !b” process has been created during the pre-vious step. We can simplify this process, according to thesequence algebra rules, for two reasons: (i) the “empty”process can only terminate (

√action), and (ii) if the first

sub-process of a sequence can terminate, then the sequenceprocess executes the second sub-process. So, “empty; !b”process can become (or is equivalent to) “!b” process.

The analysis of “empty; !b” and empty processes are ex-plained respectively in Figure 4(c) and Figure 4(d).

Each step enables us to determine the global dtLts of“?a; !b” process (see details in Figure 4). The initial state is“?a; !b” and the final state is “0”. Of course, each analysisstep is not hard-coded, but the tool analyses the algebrarules to determine each derivate action to be executed bya given process.

2.2 Analysis of discrete-time LTSs

Once the dtLts model of the Bpel specification underdesign has been obtained, it can be analyzed by usingstandard tool environments available for concurrent sys-tems. For our purpose, we use the Cadp (Constructionand Analysis of Distributed Processes) toolbox [11] dedi-cated to the formal specification and verification of con-current asynchronous systems. Cadp accepts as inputspecifications written in process algebraic languages, suchas Lotos [16], Fsp [21, 29] or Chp [22, 30], as well asnetworks of communicating automata given in the Explanguage [19]. These formal specifications are translatedby specialized compilers into labeled transition systems(Ltss), i.e., state spaces modeling exhaustively the dy-namic behavior of the specified systems. Ltss are the for-

5

mal model underlying the analysis functionalities offeredby Cadp, which aim at assisting the user throughout thewhole design process: code generation and rapid prototyp-ing, random execution, interactive and guided simulation,model checking and equivalence checking, test case gener-ation, and performance evaluation.

An Lts can be represented within Cadp in two com-plementary ways: either explicitly, by its list of states andtransitions encoded as a file in the Bcg (Binary CodedGraphs) format equipped with specialized compression al-gorithms, or implicitly, by its successor function given asa C program complying to the interface defined by theOpen/Cæsar [9] environment for graph manipulation.The explicit representation is suitable for global verificationalgorithms, which explore transitions forward and back-ward, whereas the implicit representation is suitable forlocal (or on-the-fly) verification algorithms, which exploretransitions forward, thus enabling an incremental construc-tion of the Lts during verification. To deal with large sys-tems, Cadp provides several advanced analysis techniques:on-the-fly verification, partial order reductions, composi-tional verification, and massively parallel verification usingclusters of machines.

Cadp contains currently over 40 tools and libraries forLts manipulation, which can be invoked either in inter-active mode via the Eucalyptus graphical interface, orin batch mode via the Svl [10] scripting language dedi-cated to the description of complex verification scenarios.The toolbox was used for the validation of more than 100industrial case-studies1.

2.2.1 A fragment of the MCL language

Since we focus on model checking discrete-time propertieson dtLtss, we could apply in principle existing tools oper-ating on Ltss, such as the Evaluator 3.5 [23] on-the-flymodel checker of Cadp, which takes as input temporalformulas expressed in regular alternation-free µ-calculus,an extension of alternation-free µ-calculus [5] with regularexpressions over transition sequences. However, the eval-uation of discrete-time properties requires the counting oftime actions in the dtLts; this can be encoded in standardmodal µ-calculus [31] using fixed point operators (one oper-ator for each counter value), but may lead to prohibitivelylarge temporal formulas, as noticed in the framework oftemporal Ccs [26]. Discrete-time properties can be suc-cinctly and naturally formulated using data-handling ex-tensions of the modal µ-calculus, such as the Mcl lan-guage underlying the Evaluator 4.0 tool recently inte-grated into Cadp.

Mcl (Model Checking Language) [24] is an extension ofthe alternation-free µ-calculus [5] with regular expressionsand data-handling operators. We describe below the syn-tax and semantics of an Mcl fragment containing modaloperators equipped with extended regular expressions over

1See the online catalog athttp://www.inrialpes.fr/vasy/cadp/case-studies

transition sequences, a more detailed description of the lan-guage being available in [24]. The Mcl fragment consid-ered consists of action formulas (noted α), regular formulas(noted ρ), and state formulas (noted φ), which character-ize actions, transition sequences, and states of the dtLts,respectively. Action formulas have the following syntax:

α ::= a| true

| false

| ¬α| α1 ∨ α2

| α1 ∧ α2

An action formula α denotes a set of action names (transi-tion labels) of the dtLts. The action name a denotes thesingleton set containing the action a. The boolean connec-tors have their usual interpretation: true and false denotethe set of all actions of the dtLts and the empty set; ¬αdenotes the complement of the action set denoted by α;α1 ∨α2 and α1 ∧α2 denote the union and the intersectionof the action sets denoted by α1 and α2. Action formulasprovide a simple, yet useful means of characterizing sub-sets of actions. This kind of formulas were originally intro-duced in action-based logics such as Actl (Action-basedComputation Tree Logic) [4].

Regular formulas have the following syntax:

ρ ::= α| nil

| ρ1.ρ2

| ρ1|ρ2

| ρ∗

| ρ+

| ρ{m}| ρ{m...n}| ρ{m...}

A regular formula ρ denotes a binary relation containingthe couples of states which are source and target of a tran-sition sequence in the dtLts such that the word obtainedby concatenating all actions labeling the transitions of thesequence belongs to the regular language defined by ρ. Theregular formula α denotes all one-step sequences consist-ing of a single transition labeled by an action satisfyingthe action formula α. The nil operator denotes the emptysequence, containing zero transitions. The concatenationρ1.ρ2 denotes the sequences containing two adjacent sub-sequences satisfying ρ1 and ρ2, respectively. The choiceρ1|ρ2 denotes the sequences satisfying either ρ1, or ρ2. Thetransitive reflexive closure ρ∗ (resp. the transitive closureρ+) denotes the sequences consisting of the concatenationof zero or more (resp. one or more) subsequences sat-isfying ρ. The bounded iterations ρ{m}, ρ{m...n}, andρ{m...} denote the sequences consisting of the concatena-tion of exactly m, between m and n, and at least m sub-sequences satisfying ρ, respectively. These extended regu-lar operators are similar to the operators implemented bystring searching tools such as the egrep utility available on

6

Unix systems; in practice they turn out to be as useful fordescribing transition sequences in dtLtss as their egrep

counterparts are for describing character strings.State formulas have the following syntax:

φ ::= true

| false

| ¬φ| φ1 ∨ φ2

| φ1 ∧ φ2

| 〈ρ〉φ| [ρ]φ| X| µX.φ| νX.φ

A state formula φ denotes a set of states of the dtLts.The boolean connectors have the usual interpretation overthe set of dtLts states. The possibility modality 〈ρ〉φ de-notes the states from which there is (at least) an outgoingtransition sequence satisfying ρ and leading to a state sat-isfying φ. The necessity modality [ρ]φ denotes the statesfrom which all outgoing transition sequences satisfying ρmust lead to states satisfying φ. The minimal fixed pointoperator µX.φ (resp. the maximal fixed point operatorνX.φ) denote the minimal (resp. maximal) solution of theequation X = φ interpreted over the powerset lattice of thestate set. Propositional variables X denote sets of states;they are bound by the fixed point operators in a way simi-lar to quantifiers in first-order logic. The state formulas ofthe Mcl fragment above are similar to those of the modalµ-calculus, except for the two modalities containing regu-lar formulas, which are inspired from dynamic logics suchas Pdl (Propositional Dynamic Logic) [15].

The usage of this Mcl fragment for specifying discrete-time properties of Bpel descriptions will be illustrated inSection 3.3.

3 Case Study: A Web Service for GPS Navigation

We illustrate in this section the application of our approachto the modeling and analysis of a Web service dedicatedto Gps navigation. Given the relative complexity of thisWeb service, we do not detail here its textual Bpel andWsdl descriptions, but present its workflow graphicallyusing the Bpmn [12] notation.

3.1 System description

The purpose of the Gps Web service is to computeitineraries from a position to a destination fixed by auser (client of the service). In addition to the requesteditinerary, the user can also obtain: pictures of the travel(taken from the air), the global map of the itinerary, andvarious kinds of information (about traffic, radar stations,point of interest (Poi), etc). At last, the user can configurethe subscription to the various kinds of information, as wellas some parameters of the travel (e.g., to take motorway

or not, to deviate toward a Poi, etc.). The relationshipsbetween these functionalities are represented in Figure 5.

Figure 5: Functionality workflow of the Gps Web service

The behavior of the Gps Web service consists of twomain phases, described in the sequel: the initializationphase (login, setting of the initial position and destination)and the main loop phase (management of the itinerary,modification of the parameters, etc.).

3.1.1 Initialization phase

The initialization phase comprises three activities: login,position and destination.

Login activity. The access to the Web service is re-stricted to authenticated users only. To identify itself, theuser must send a couple login/password, to which the ser-vice responds by a message “Ok” or “NOk” dependingwhether the couple is valid or not.

Position activity. After authentication, in order to usethe main functionalities of the Web service, the user mustindicate where the start location of the travel is. Thisis done by sending a message with information about the

7

street, city, and country where the navigation session mustbe started; the message must be resent until the start lo-cation is accepted by the service (message “Ok”).

Destination activity. Finally, before the service mayattempt to calculate an itinerary, the user must enter adestination. This is similar to the position activity above:the user must retry until the end location is accepted bythe service.

3.1.2 Main loop phase

After the initialization phase, the service can compute anitinerary, send information about traffic, Poi, etc. Tomaintain the connection with the user, the service requiresthat the time elapsed between certain consecutive user ac-tions does not exceed a given timeout value (a kind of“ping alive”). In Section 3.2 we will consider for analysisconfigurations of the system with a timeout value rangingfrom 1 to 60 seconds.

From the Web service point of view (see Figure 5), thistimeout is managed by a “scope” process: when the time-out is reached, this process generates an exception thatwill be caught by another process. The main activity ofthis “scope” process is a “pick” process. This kind ofchoice enables the user to select a desired action; if we usedthe “switch” Bpel construct instead, the choice would bemade by the Web service and not by the user. Further-more, the “scope” is encapsulated into a “while”, enablingthe user to do more than one operation during the session(notice that the first action carried out by the service whenentering the “while” is the emission of a ready message tothe user). Finally, the “while” is the main activity of a sec-ond “scope”, that catches the first exception thrown whenthe timeout is reached.

The activities executed by the main loop are partitionedin two modes, described in the sequel: the navigation mode(obtaining the itinerary, modifying the current position ordestination, getting a picture or a roadmap), and the con-figuration mode (subscribing to a Poi, getting informationon radars or traffic, setting of parameters).

Navigation mode. In navigation mode, the user canchange the current position and the destination (using thesame procedure as for the initialization phase). Next, theuser can ask for the itinerary, a picture, the roadmap, orenter in configuration mode. There are two types of answerfor itinerary requests: either a complete itinerary leadingfrom the current position to the destination, with variousinformation (about street, radar, Poi, etc.) depending onthe user subscriptions, or simply a destination message

indicating that the current position is (near) to the des-tination. The requests for picture and roadmap allow theuser to obtain an air-picture of the area (in Png format)or a veritable roadmap (in Svg format).

Configuration mode. In configuration mode, the usercan subscribe or cancel his subscription to informationabout Poi, radar or traffic. This information is addedto the itinerary if necessary. Additionally, the user can setvarious parameters, such as the kind of the itinerary (onmotorway or not), etc.

3.2 Discrete-time LTS synthesis

Starting from the Bpel description of the Gps Web ser-vice, we apply the WSMod tool in order to obtain a dtLtson which the verification tools of Cadp will operate. Weshow below the dtLts model obtained for a timeout of 1second, then we study its variation in size as the timeoutvalue increases, and finally we discuss the behavior of theWeb service w.r.t. the ambiguity detection feature imple-mented in WSMod.

Discrete-timed labeled transition system. dtLtsmodels represent the observable behavior of Web services.The actions labeling the dtLts transitions denote the mes-sages exchanged (emissions and receptions are prefixed by’ !’ and ’?’, respectively), the elapse of a discrete-time unitχ (or time), the internal action τ (or tau), and the termi-nation action

√(or done). The global behavior of the Web

service is obtained by an exhaustive simulation of the Bpeldescription driven by the Atp rules given in Table 1. ThedtLts obtained in this manner for the Gps Web servicewith a timeout value of 1 second is shown in Figure 6.

Variation of DTLTS size with the timeout value.

The size of the dtLts (number of states and transitions)depends on several aspects of the Bpel description: thenumber of Bpel processes, their complexity and nesting,the amount of communications, and the values of the time-outs. For the sake of readability, we have shown in Figure 6the dtLtss for a timeout of 1 second (corresponding to oneχ in discrete-time), but we carried out verification also forlarger values of the timeout.

0

200

400

600

800

1000

1200

1400

1600

1800

0 10 20 30 40 50 60

LT

S s

ize

(n

um

be

rs o

f tr

an

sit

ion

s/s

tate

s)

TimeOut (in sec.)

Variation of LTS size depending on timeout value

transitionsstates

8

0

11

TAU

22

TAU

TIME

20

!bye

TIME

3

!Ready

1

!Destination

15

TIME

7

TAU

2

!Ok

10

TIME

!Ok

TIME

18

TIME

27

?setPosition?setDestination 5

?getItinerary

26

?getPicture

17

?getRoadMap

25

?configMode

TIME

6

?getRoadMap

12

?setPosition ?setDestination13

?configMode

24

?getItinerary

19

?getPicture

TAU

16

TAU

9

TAU

8

TAU

!Picture

TIME

!RoadMap

TIME?POISubscribe ?setRadarSubscribe?setTrafficSubscribe ?setParameters TIME

4

!GoodJourney

TIME

!Itinerary

23

TIME

!Destination

TIME

!RoadMap

TIME

TIME

!ConnexionError

14

DONE

!Itinerary

TIME

TAU

21

TAU

!NOk

TIME

TIME

?POISubscribe ?setRadarSubscribe ?setTrafficSubscribe?setParameters

!NOk

TIME

TAU TAU

!Picture

TIME

28

TAU

phaseMain loop

phaseInitialization

Figure 6: dtLts model of the Gps Web service, with zoom on the initialization phase. The action !GoodJourney makesthe link between the initialization phase and the main loop phase.

9

The figure above shows the variation of the dtLts sizefor timeout values ranging from 1 to 60. We observe alinear increase of both the number of states and transitions;this is a consequence of the fact that the Bpel descriptioncontains a single timeout (according to the Atp rules). Inthe presence of multiple, overlapped timeouts, the size ofthe dtLts may increase much more quickly.

Non ambiguous Web service. In this study, we fo-cus on the verification of the Web service behavior. How-ever, the WSMod tool can also synthesize automaticallya dtLts modeling the behavior of an adapted client in-teracting with the Web service, provided that the modelof the service respects certain properties (concerning nonambiguity in message exchanges, time elapsed, etc.) de-tailed in [13]. Here, the Gps Web service is identified asnon ambiguous by WSMod, meaning that the tool cansynthesize an adapted client that can know, on each mes-sage exchange, the exact choice made on the service side,and therefore the client and the service can evolve withoutany deadlocks or mismatches.

3.3 Verification of discrete-time properties

We analyze below the behavior of the Gps Web service(considering a timeout of 50 seconds) by means of discrete-time model checking using the Evaluator 4.0 [24] toolof Cadp. Table 2 illustrates the formulation in Mcl ofseveral safety and liveness properties, of both untimed andtimed nature. The colored parts of the formulas indicatediscrete-time properties, which involve the counting of timeactions. All properties were successfully verified on thecorresponding dtLts of the system, which has 535 statesand 1473 transitions.

Safety properties: they specify informally that “some-thing bad never happens” during the execution of the sys-tem. In the Mcl language, these properties can be ex-pressed in a concise manner by identifying the undesirableexecution sequences, characterizing them using extendedregular expressions, and forbidding their existence in thedtLts model using necessity modalities.

Properties S1 and S2 concern the ordering of actionsduring the initialization phase: S1 specifies that the usercannot set the position or the destination before logging insuccessfully, and S2 states that after requesting the posi-tion or the destination, the Web service cannot begin themain loop before receiving an appropriate answer from theuser. Properties S3 and S4 deal with the main loop phase:S3 forbids the user to make another request before the cur-rent one (here, an itinerary demand) has been handled bythe service, and S4 states that a demand cannot be fulfilledanymore by the service after the timeout has expired.

Liveness properties: they specify informally that“something good eventually happens” during the executionof the system. In Mcl, these properties contain diamond

modalities and minimal fixed point operators for encod-ing the existence of certain desirable execution sequences(potentiality) or trees (inevitability) in the dtLts.

Properties L1 and L2 concern the initialization phase:L1 specifies that after the user has logged in, the Webservice will eventually ask for the position, the destina-tion, or end the initialization, and L2 states that after theinitialization was finished the service will end up in themain loop or decide to terminate the session. PropertiesL3 and L4 deal with the main loop phase: L3 indicatesthat as long as the timeout has not expired, the servicecan still prompt for a user request, and L4 states that anexpiration of the timeout eventually interrupts the con-nection. The AF p operator of Ctl [3] expressing the in-evitable reachability of a state p is defined in µ-calculus asµX.p ∨ (〈true〉 true ∧ [true]X).

4 Conclusion and Future Work

The design of complex business processes according tothe Soa approach requires to carefully take into accountthe presence of concurrency, communication, and timingconstraints induced by the interaction of Web services.To facilitate the design process, we propose here a tool-equipped methodology for modeling and analyzing Webservices described in Bpel. We focus on the behavioraland discrete-time aspects of Web services, and rely uponthe model-based verification technologies stemming fromthe concurrency domain. The state/transition models ofBpel Web services are produced automatically by theWSMod tool, which implements an exhaustive simulationalgorithm based on a formalization of Bpel semantics bymeans of process algebraic rules. The tool is able to han-dle both discrete and continuous time constraints; for themoment we handle only discrete-time models, which canbe analyzed using the Evaluator 4.0 model checker [24]of the Cadp toolbox [11]. Discrete-time safety and live-ness properties can be concisely expressed using the data-handling facilities of the Mcl language accepted as inputby Evaluator 4.0, and particularly the extended regu-lar expressions over transition sequences, which allow tocount tick actions occurring in the model. We illustratedthe verification of discrete-time properties on the exam-ple of a Gps Web service; however, most of them can beeasily adapted for other business processes described inBpel. Our methodology enables the Web service design-ers to carry out formal analysis on complex Web servicesbefore publishing them, and thus to improve the quality ofthe design process.

We plan to continue our work along several directions.Firstly, we can improve the connection between WSModand Cadp by producing implicit dtLtss according to theinterface defined by Open/Cæsar [9]. This would enableon-the-fly verification, which allows to detect errors in largesystems without constructing the complete dtLts modelbeforehand but exploring it in a demand-driven way. Sec-ondly, using discrete-time models allows to directly reuse

10

Table 2: Safety and liveness properties of the Gps Web service (timeout of 50 sec.)

Prop. Mcl formula

S1 [ (¬!LoginOk)∗.?setPosition ∨ ?setDestination ] false

S2

[ (true∗.

((!getPosition.(¬?setPosition)∗) | (!getDestination.(¬?setDestination)∗)) .!GoodJourney) ] false

S3

[ true∗.?getItinerary.(¬(!Itinerary ∨ !Destination))∗.

(?getP icture ∨ ?getRoadMap ∨ ?configMode ∨?setPosition ∨ ?setDestination ∨ ?getItinerary) ] false

S4

[ true∗.?getItinerary.(¬(!Itinerary ∨ !Destination))∗.

(time.(¬(!Itinerary ∨ !Destination))∗){51} .

(!Itinerary ∨ !Destination) ] false

L1 [ true∗.!LoginOk ] AF 〈!getPosition ∨ !getDestination∨ !GoodJourney〉 true

L2 [ true∗.!GoodJourney.(τ ∨ time)∗ ] 〈(τ ∨ time)∗. !Ready ∨ !bye〉 true)

L3[ true

∗.!Ready. time{ 0 ... 50 } ]

〈true∗.!Picture ∨ !RoadMap ∨ !Itinerary ∨ !Destination〉 true

L4

[ true∗.!Ready.

((¬(!Itinerary ∨ !Destination ∨ !Picture ∨ !RoadMap))∗.time){51} ]

AF 〈!ConnectionError〉 true

the tools available for data-based temporal logics, such asEvaluator 4.0; however, this may lead to state explosionin the presence of numerous timeouts. An alternative so-lution would be to use continuous time models; this canbe achieved by connecting the time automata produced byWSMod with the Uppaal [20] tool dedicated to the veri-fication of continuous time models. Finally, we will extendthe methodology to handle compositions of multiple Webservices, following our previous work on automated clientsynthesis [25], but focusing on the verification of composi-tion. For this purpose, the compositional verification tech-niques available in tools such as Exp.Open [19] will becertainly useful.

REFERENCES

[1] R. Alur and D. L. Dill. A theory of timed automata.Th. Comp. Sci., 126(2):183–235, 1994.

[2] A. Chirichiello and G. Salaun. Encoding abstract de-scriptions into executable web services: Towards aformal development. In WI ’05: Proc. of the 2005IEEE/WIC/ACM International Conference on WebIntelligence, pages 457–463, Washington, DC, USA,2005. IEEE Computer Society.

[3] E. Clarke, O. Grumberg, and D. Peled. Model Check-ing. MIT Press, 2000.

[4] R. De Nicola and F. W. Vaandrager. Action versusState Based Logics for Transition Systems In Lec-ture Notes in Computer Science vol. 469, pp. 407–419,Springer Verlag, 1990

[5] E. A. Emerson and C-L. Lei. Efficient Model Checkingfor Fragments of the Propositional Mu-Calculus. InProc. of the 1st International Symposium on Logic inComputer Science LICS’86, 1986.

[6] A. Ferrara. Web services: a process algebra approach.In ICSOC, pages 242–251, 2004.

[7] X. Fu, T. Bultan, and J. Su. Analysis of interactingBPEL web services. In Proc. of the 13th InternationalWorld Wide Web Conference (WWW’04), USA, 2004.ACM Press.

[8] X. Fu, T. Bultan, and J. Su. WSAT: A tool for formalanalysis of web services. In Proc. of the 16th Inter-national Conference on Computer Aided Verification(CAV’04), 2004.

[9] H. Garavel. OPEN/CÆSAR: An open software archi-tecture for verification, simulation, and testing. Proc.of TACAS’98, LNCS vol. 1384, pp. 68–84, March1998. Springer Verlag. Full version available as IN-RIA Research Report RR-3352.

[10] H. Garavel and F. Lang. SVL: a scripting languagefor compositional verification. In M. Kim, B. Chin, S.Kang, and D. Lee, editors, Proc. of the 21st IFIP WG6.1 International Conference on Formal Techniquesfor Networked and Distributed Systems FORTE’2001(Cheju Island, Korea), pages 377–392. IFIP, KluwerAcademic Publishers, August 2001. Full version avail-able as INRIA Research Report RR-4223.

[11] H. Garavel, F. Lang, R. Mateescu, and W. Serwe.CADP 2006: A toolbox for the construction and anal-

11

ysis of distributed processes. In W. Damm and H. Her-manns, editors, Proc. of the 19th International Con-ference on Computer Aided Verification CAV’2007(Berlin, Germany), volume 4590 of Lecture Notes inComputer Science, pages 158–163. Springer Verlag,July 2007.

[12] Object Management Group. Business process model-ing notation (BPMN) specification, may 2006.

[13] S. Haddad, T. Melliti, P. Moreaux, and S. Rampacek.Modelling web services interoperability. In Proc. ofthe 6th Int. Conf. on Enterprise Information Systems(ICEIS04), Porto, Portugal, April 14–17 2004.

[14] S. Haddad, P. Moreaux, and S. Rampacek. A formalsemantics and a client synthesis for a BPEL service.In Lecture Notes in Business Information Processing,ICEIS06 Revised Selected Paper, volume 3. Springer,2008.

[15] D. Harel, D. Kozen, and J. Tiuryn. Dynamic Logic.MIT Press, 2000.

[16] ISO/IEC. LOTOS — a formal description techniquebased on the temporal ordering of observational be-haviour. International Standard 8807, InternationalOrganization for Standardization — Information Pro-cessing Systems — Open Systems Interconnection,Geneve, September 1989.

[17] D. Jordan and J. Evdemon. Web Services BusinessProcess Execution Language Version 2.0 - Oasis Stan-dard, 11 april 2007.

[18] N. Josuttis. SOA in Practice – The Art of DistributedSystem Design. O’Reilly Media, City, 2007.

[19] F. Lang. EXP.OPEN 2.0: A flexible tool integratingpartial order, compositional, and on-the-fly verifica-tion methods. In J. van de Pol, J. Romijn, and G.Smith, editors, Proc. of the 5th International Confer-ence on Integrated Formal Methods IFM’2005 (Eind-hoven, The Netherlands), volume 3771 of LectureNotes in Computer Science. Springer Verlag, 2005.

[20] K. G. Larsen, P. Pettersson, and W. Yi. Uppaal ina Nutshell. Int. Journal on Software Tools for Tech-nology Transfer, 1(1–2):134–152, October 1997.

[21] J. Magee and J. Kramer. Concurrency: State Modelsand Java Programs. Wiley, 1999.

[22] A. J. Martin. Compiling communicating processesinto delay-insensitive VLSI circuits. Distributed Com-puting, 1(4):226–234, 1986.

[23] R. Mateescu and M. Sighireanu. Efficient on-the-fly model-checking for regular alternation-freemu-calculus. Science of Computer Programming,46(3):255–281, March 2003.

[24] R. Mateescu and D. Thivolle. A model checking lan-guage for concurrent value-passing systems. In J.Cuellar and T. Maibaum, editors, Proc. of the 15th In-ternational Symposium on Formal Methods FM’2008(Turku, Finland), volume 5014 of Lecture Notes inComputer Science. Springer Verlag, 2008.

[25] T. Melliti, C. Boutrous-Saab, and S. Rampacek. Ver-ifying correctness of web services choreography. InProc. Forth IEEE European Conference on Web Ser-vices (ECOWS06), Zurich, Switzerland, December 4–6 2006. IEEE Computer Society Press.

[26] M. J. Morley. Safety-level communication in rail-way interlockings. Science of Computer Programming,29(1-2):147–170, 1997.

[27] X. Nicollin and J. Sifakis. The algebra of timed pro-cesses ATP: Theory and application, 1994.

[28] G. Salaun, A. Ferrara, and A. Chirichiello. Negoti-ation among web services using LOTOS/CADP. InL.-J. Zhang, editor, ECOWS, volume 3250 of LectureNotes in Computer Science, pages 198–212. Springer,2004.

[29] G. Salaun, J. Kramer, F. Lang, and J. Magee. Trans-lating FSP into LOTOS and networks of automata.In J. Davies, W. Schulte, and J. Song Dong, edi-tors, Proc. of the 6th International Conference on In-tegrated Formal Methods IFM’2007 (Oxford, UnitedKingdom), volume 4591 of Lecture Notes in ComputerScience, pages 558–578. Springer Verlag, July 2007.

[30] G. Salaun and W. Serwe. Translating hardware pro-cess algebras into standard process algebras — illus-tration with CHP and LOTOS. In J. van de Pol,J. Romijn, and G. Smith, editors, Proc. of the 5thInternational Conference on Integrated Formal Meth-ods IFM’2005 (Eindhoven, The Netherlands), LectureNotes in Computer Science. Springer Verlag, 2005.

[31] C. Stirling. Modal and Temporal Properties of Pro-cesses. Springer Verlag, 2001

[32] K. J. Turner. Representing and analysing composedweb services using CRESS. J. Netw. Comput. Appl.,30(2):541–562, 2007.

12