Describing and Reasoning on Web Services using Process Algebra

Describing and Reasoning on Web Servicesusing Process AlgebraGwen Salaun, Lucas Bordeaux, Marco Schaerf

DIS - Universita di Roma “La Sapienza”Via Salaria 113, 00198 Roma, Italia

Email:�salaun,bordeaux,schaerf�@dis.uniroma1.it

Abstract— We argue that essential facets of web services, andespecially those useful to understand their interaction, are bestdescribed using process-algebraic notations. Web servicedescrip-tion and execution languages such asBPEL are essentiallyprocessdescription languages; they are based on primitives for behaviourdescription and message exchange which can also be found inmore abstract languages such as process algebras. One legitimatequestion is therefore whether the web services community canbenefit from the sophisticated languages and tools developed inthe process algebra area. Our investigations suggest a positiveanswer, and we claim that process algebras provide solutionsto a number of challenges raised by the web services paradigm,among which are central issues oforchestration and choreography.We show on a case study that readily available tools based onprocess algebra are effective at verifying that compositions ofservices obtained by choreography and orchestration conformtheir requirements and respect properties. We suggest a generalframework based on a mapping between process algebra andweb services written inBPEL, and illustrate both the modellingof services by process algebra and the use of reasoning tools.

I. I NTRODUCTION

Web services (WSs) are software applications which can beused through a network (intranet or Internet) via the exchangeof messages based onXML standards. They are aimed atwild reusability and they are typically designed to interactwith other services in order to build larger applications. Thisinteraction can, depending on the situation, last for a shortor longer duration. An example of a temporary and dynamicinteraction occurs when one service contacts another one inresponse to an instantaneous need, like a car renting or aflight ticket (this, of course, presupposes the use of advancedsearch tools to enable the automatic discovery of a servicematching the need). On the other extreme, interactions whichinvolve a fixed number of services can arise when developping the information system of, say, a transportation company(one service for each stock and possibly each vehicle) orwhen a service is built by the orchestration of a well-definednumber of existing services, provided an added value to theircumulated independent values (a search engine service whichcontacts a translation service,etc.).

From a software engineering viewpoint, the constructionof new services by the static or dynamic composition of

This article is a revised, extended version of our homonymous paperpublished in the proceedings of the 2ndInternational Conference on WebServices, held in 2004, which were published by the IEEE. The researchreported here was partially supported by Project ASTRO funded by the ItalianMinistry for Research under the FIRB framework (funds for basic research).

existing services raises exciting new perspectives which cansignificantly impact the way industrial applications will bedeveloped in the future — but they also raise a number ofchallenges. Among them is the essential problem of guaran-teeing the correct interaction of independent, communicatingsoftware pieces. Due to the message-passing nature of webservices interaction, many subtle errors can occur (messagenot received, deadlocks, incompatible behaviours1) when weput several of them together. These problems are well-knownand recurrent in distributed applications, but they becomeevenmore critical in the open-end world of web services, which isruled by the longer-term vision of “services used by services”more than by human users, and where this interaction should,ideally, be as transparent and automated as possible.

This paper addresses the problems raised by the interactionof web services when they are composed together, be it ina dynamic or static way. Our proposal is, specifically, to useprocess algebra(PA) [5], [25] as a family of languages for for-mally describing the behaviour of web services. It has indeedalready been argued by other authors (e.g.,[24]) thatWSs andtheir interaction are best described usingprocess descriptionlanguages, and it is clear that most emerging standards fordescribing and composingWSs are actually such languages —one example isBPEL4WS [1], hereafter shortened toBPEL.Being simple, abstract and formally defined,PAs make iteasier to formallyspecifythe message exchange betweenWSs,and toreasonon the specified systems. Advanced automatedtools have been developed to support both of these tasks, andwe advocate their use to prevent significant errors.

The two main classes of problems where process algebracan be helpful are in our opinion the following:

� The development of web servicesraises a number ofproblems, much alike those encountered during the devel-opment of classical distributed systems. Process algebracan help:

– During the design stage, PA can be used to de-scribe an abstract specification of the system tobe developed (a graphical front-end similar to theone described in [28] can ease this task), giving apreliminary model which can be validated by thereasoning tools, and then be used as a reference forthe implementation. One can then imagine to use

1A set of services is said to becompatiblewhen they can interact togetherproperly, see Section III.

a translation from the algebra into the executablelanguage to automatically generate code skeletons.

– For reverse engineering purposes,a translation inthe other direction is needed to extract an algebraicdescription from existing web services. This allowsthe use of reasoning techniques to analyse runningservices.

As a particular case, a promising way of developing anew service is through theorchestrationof existing webservices. In this context, the role of the new service is es-sentially to be a central process which sends and receivesmessages to/from each of the selected partners. One mustguarantee that this interaction will work properly, whichPA can help doing.� Choreography issues concern the interaction of webservices with the other services which will use them.Choreography is a challenging problem, especially whena service establishes a dynamic, temporary transactionwith a new service whose behaviour is not exactly knownin advance. In this case, an abstract, process-algebraicrepresentation of the behaviours of all participants canbe used to perform the needed reasoning in an automatedway.

Common to orchestration and choreography problems arestrong assumptions regarding theinterfaceof the web services.When a service is published on the web, its implementationdetails are, of course, hidden to its users. If the interfaceis reduced to a list of message declarations and types, asin a WSDL file, then no information is given on the se-quence of messages sent and received by the service. Suchan interface allows a number ofstatic verifications to beperformed (notably type-checking), but makes it impossibleto know how to interact with it and to check thedynamicsof the system. As made explicit by the W3C choreographyworking group [37] it is now accepted that, in a near future,the interface ofWSs should evolve and that a descriptionof their observable behavioursimilar to those described inthe component software engineering literature [11] shouldbe provided in addition to their soleWSDL interface. Thisdescription will be based on anXML-based standard similarto the former proposalWSCI [36] or the more recentWS-CDL [35] and abstractBPEL [1]. Our proposal is thus basedon the assumption that, even for existing services developed byothers or found through the web, one has at hand an abstractdescription of their behaviour, from which a process-algebraicdescription can be extracted.

A global picture of the framework we envision for the useof PA in a WS setting is shown in Fig. 1. Central to ourapproach is the need for sound, two-way mappings bridgingthe concrete layer (implementation level), the interface layer(published,XML description of the behaviour of the service)and to the most abstract one (algebraic representations usedfor reasoning).

� It is clear that the interface layer must provide an abstract,yet faithful representation of the concrete behaviour ofa service. This low-levelconformancewill be assumedin the paper since it goes beyond its scope. Let us

IDEsgraphical front−ends

edition tools

Concrete BPEL...

Abstract BPEL...

WSDL, WS−CDL,

Pi−calculus...

CCS, LOTOS,

Java, C# , DB,

mapping mapping

pro

cess

alg

ebra

public level

(interface)

private level

(implementation)

XM

L a

bst

ract

des

crip

tions

exec

uta

ble

code

interface

synthesis

theorem proversmodel checkers

verification tools

Ab

stra

ct l

ayer

Con

cret

e la

yer

refinement

Fig. 1. Our framework for the use of Process Algebra

just mention that conformance checking is an importantproblem which can be partially assisted by automatedtools. An exciting perspective is to automatically extractinterfaces from executable code (interface synthesis). Another approach is to start from the high-level specificationprovided by the interface and to progressively obtain animplementation of this interface byrefinement[11].� The correspondence between the concrete layer (runningcode together with itsXML-based, publicly availabledescription) and the abstract one (process-algebraic no-tation), must be guaranteed by a formal mapping, whichwe briefly outline in the paper.

This paper is structured as follows. In Section II, weintroduce PA and the way we use them to describe andreason on web services. Section III investigates the use ofprocess algebra for choreography issues on a case study, whileSection IV discusses their interest for orchestration. Section Vgives some guidelines to map process-algebraic descriptionsfrom/into more concrete ones; we especially illustrate thispoint with CCS andWSDL/BPEL. Related work is discussedin Section VI and concluding remarks are drawn up in SectionVII.

II. PROCESSALGEBRA FORDESCRIBING AND REASONING

ON WEB SERVICES

PAs [5] are formal description techniques to specify soft-ware systems, particularly those constituted of concurrentand communicating components. NumerousPAs have beenproposed; well-known calculi areCCS [25], ACP [3], CSP[16] and all their extension like the� -calculus [29],LOTOS[6], Promela [17] or Timed CSP [32]. These languages sharethe same ingredients: simple constructs to describe dynamicbehaviours, compositional modelling, operational (and/or ax-iomatic, denotational) semantics, behavioural reasoningviamodel checking and process equivalences.

A. What is a Process Algebra?

In this subsection, our purpose is to give a flavour of whata PA is made up of. The algebra chosen in this paper isCCS[25] whose set of operators is small yet sufficiently expressivefor the presentation of our approach.

1) Basic operators:Defining processes inCCS requiresto first agree on a set ofaction nameswhich represent themessages used in the system, for instance

�askProductInfo,

buy, cancel�, or�� � � � � �. The basicactions in CCS are to

receivea message (this is noted by simply writing its name)or to emit a message (this is written by its name prefixed bythe quote symbol,e.g., ��).

Processesare constructed as follows. A process which isterminated is written�: “do nothing”. A process can executea sequenceof the form

� �, where

�is an action and

a process: “execute�

then

”. A process can performa nondeterministic choice(

�: “execute

or execute�

”). The coexistence of several processes � � � � � �

whoseexecution is interleaved is written

� � � � � � (“run

� � � � � � in parallel”). The “

�” symbol, called parallel composition,

is therefore used to define a global process made up ofseveral subprocesses. Last2, the restriction operator, noted �� �

where

is a process and� �

is a set of names, imposesthat an emission of� (� � � �

) by one subprocess of

can occur only if another subprocess does a reception of thesame message name (synchronisation). In practice, it is usedto declare all the names on which synchronisations occur inthe whole system. Here is an example ofCCS process:

� ��� � � ��� �� �� � �� ��� ��� ��� �� ���� �This process is the parallel composition of two simple

behaviours. The first subprocess can evolve either throughthe sequence of input messages

� ��(“receive

�then receive�

”) or through the sequence� ��

. The second can performthe sequence of output messages�� �� �. The restriction (

��� �)means that all exchanges of message

�must be internal to the

system: message�

cannot leave the system or be received fromoutside the system. On the contrary,

�and

�are not restricted,

which means that one can interact with the system by sendingit or receiving from it any of these messages.

2) Hidden actions:In some cases we need an additionalsymbol� denotinghidden actions. � actions allow some levelof abstractionin the description of the processes, since theycan hide an arbitrarily complex sequence of actions whosedetails are kept private. A specification, or an interface, willtypically describe part of the behaviour of the concrete process,but will allow itself to specify at some points that “here,some computation is done”, without further details. The useof � actions can in many cases be avoided, but they areneeded when one process exhibits “internal non-determinism”,i.e., when its state can change due to computations executedsecretly, in a non-observable way.

An example of a service whose modelling requires� actionsis the following:

� � �� � � �request

��� ��confirmation�� � ��refusal

�� �2Let us mention that two other primitives exist - thesummation� ��� and

the renaming ! - but they are not used in the paper.

This process first receives a request. Then two different thingscan happen, reflecting the two possible outcomes of a hiddenquery to a local database or a hidden communication withother processes aimed at checking whether the request can besatisfied. Either the process checks that the request can indeedbe satisfied and it moves to a state where it is ready to senda confirmation, or it finds out that there is a problem andmoves to a state in which it will send a refusal. Between thepreceding process and the same process where the� actionswould not be explictly written, a subtle difference appearsafterthe request has been received. If we do not write the� actions,then another process can synchronise with

� � and impose itschoice between the two alternatives, which hardly conformsrealistic situations. With the� actions, we express the factthat the process willinternally perform a computation whichcan give different results, and this result will determine whichbranch of the choice is effectively chosen.

Making the � actions explicit in the description of thisprocess is therefore needed whenever a choice (

) occurs,

because we chose a calculus which does not make thedistinction between the two types of non-determinism, oneinternal (the process determines which branch the computationtakes) andexternal(the choice depends on a message sent byanother process). Some process algebras define two operatorsinstead of the unique

, but we favouredCCS because of its

simplicity, and of the ability of� actions to model abstraction.3) Operational semantics:CCS is formalised using ax-

iomatic and operational semantics [25]. The operational se-mantics describes the possible evolutions of a process; moreprecisely, it defines a transition relation

"# � meaningintuitively that “

can evolve to

� in one step through action$” (where $ is the emission of a message, the reception ofa message or a� action). This relation is defined by theset of rules presented below3, which give a precise meaningto each operator. Note that� actions can occur when twoprocesses communicate (rule

% &). This reflects that fact that

both processes will change state, but that the action they haveperformed is not observable by a third party.

' () *+ ) , - .) *+ ) /' 01 2

) 32 *+ ) /32 4 - ,

) *+ ) /) 5 6 *+ ) / 7 8 9) *+ ) /) :6 *+ ) / :6 ; 9 <

) =+ ) / 6 >=+ 6/) :6 ?+ ) / :6 / ; 9 @For instance, the

� A �rule states that a process$ �B

canevolve to a process

Bby performing$, and theC D %

rulestates that a process involving a choice can evolve followingone of the processes of the choice — this discards the otheralternative. Let us illustrate how these rules can be used tofigure out a possible trace starting from the behaviour

�introduced before. A possible trace is the following:

� EF# �� �� ��� ��� ������ � GF# ��� ������ � > HF# �3Both “ :” and 5 are commutative, the symmetrical rules are omitted here.

In other words, one way for the system to evolve is througha visible

�action, followed by an unobservable evolution (cor-

responding to an internal synchronisation of the two processesof the system on action

�), and ending with the emission of a

message�. To understand, for instance, why the second step

of this evolution is possible, let us show formally that it canbe obtained by a legal application of theCCS rules:

� �� �F# � SEQ �� ��� �� >�F# �� �� SEQ

�� �� ��� �� � �� � GF# ��� ��� PC2

�� �� ��� �� � ������ � GF# ��� ���� �� � RES

B. Specifying Web Services as Processes

We already claimed thatWSs are essentially processes andthat any meaningful representation of services should takeintoaccount behavioural information (this need has already beenpointed out by several people in the community [24], [4],[18], [1]). An essential reason behind this need is that theinteraction betweenWSs is typically more complex than, forinstance, simple(Remote) Procedure Calls, which do a job andterminate, possibly returning a value. Knowing the signatureof the parameters expected by aRPC is essentially sufficientto use it, and aWSDL file would in this case be sufficient.On the contrary, a web service is very much alike an objectin OO-programming in that it has an internalstatewhich isaffected by the messages it sends and receives. Some actionsare possible in some states and not possible in some others,and reasoning on stateful interaction needs to keep track ofthe transitions performed by the system.

1) Modelling simple services:Even a simplistic service,like the basic hotel booking service shown on Fig. 2 involvescomplex interactions, since the service can dialogue with thecaller, for instance to ask for complementary information.

askInforequest

refusal

recInfo

confirmation acceptance

Fig. 2. A WS for a hotel

Clearly, it is not sufficient to know that this service receivesthree types of messages (booking requests, confirmation andextra information) to understand the way it interacts withother services, because its behaviour may follow differentscenarii depending whether free rooms are available, whetherthe reservation form was filled correctly, etc. One needs toknow that the booking request comes first, and that it can befollowed by a number of requests for more information, by arefusal or by a confirmation.

PAs are an effective and unambiguous way to represent suchbehaviours. In fact, the graphical notation used in the previousexample is easily translated into the followingCCS expression(the following syntax is directly accepted by theCWB-NCtool [10] and is also used in sections III and IV):

proc Hotel = request.InteractionLoop

proc InteractionLoop =’askInfo.recInfo.InteractionLoop+ ( ’refusal.Hotel

+’acceptance.confirmation.Hotel))

The textual syntax is more adapted to proof-writing andformal reasoning, as well as to the description of large-scalesystems. Graphical notations are anyway complementary andcan be used by user-friendly front-ends [28]. We use them inthis section for illustration purposes.

2) Using expressive process algebra:When describingsoftware, the question of the level of details reflected by theabstract description always arises, andWSs are no exception.Behavioural aspects are unavoidable, they are thestrict mini-mumof what needs be represented. In our opinion, there is usu-ally little need to model implementation or networking issues(e.g.,server location, URL or URI) because these concepts aretoo low-level and do not add to the global understanding of asystem. But in some cases, other features like data or mobilityallow to have a more faithful representation of a service. Inallcases where messages and action names are enough, simplealgebras likeCCS can be recommended. Richer languagesexist which can be used, for instance, to address the followingneeds:

� Abstract data can be manipulated by algebras likeLOTOS [6] or, to some extent,Promela [17]. They are used ifthere is a need to describe values of message parameters, localdata (attached to a specificWS), or predicates guarding a pieceof behaviour. In the case of a business trip, we can imagine aWS whose task is to book a hotel (among several ones) whilerespecting a limit price which guards the application of someof the actions (Fig. 3).

recPrice

[p>lp] askPricerecLimit

[p<=lp] confirmation

Fig. 3. Booking a hotel respecting a limit price

� Timed PAs like Timed CSP [32] allow the descriptionof temporal constraints. As an illustration, it is easy to specifya waiting time for a specific event, and to verify afterwardsthat the concerned web service will never wait for a responsefor longer than the specified duration. This could be useful,for instance, for a hotel which does not wish to wait for morethan one day for a confirmation (Fig. 4).

askInforequest

refusal

recInfoconfirmation

t<=24h acceptancet>24hrefusal t:=0

Fig. 4. A WS for a hotel with a confirmation delay

� Mobility arises when processes can establish commu-nications with dynamically-changing partners. An important

feature of mobile processes is the ability to send and receiveaddresses, and to send messages to these addresses in forth-coming communications. Mobility can be needed in theWSworld, for instance, when a service is ready to communicatewith arbitrary clients whose address is not specified at designtime but are, on the contrary, discovered and constantly chang-ing at runtime. An example is a server which receives requestsfrom clients, as well as the address of the requester, andwhich then engages an interaction by exchanging messageswith the client in question. Depending, once again, on thelevel of details needed in the modelling, one may, or may notwish to reflect this address exchange in the process-algebraicdescription. The best-known algebra for mobile processes isthe� -calculus [29]. Some tools based on other process algebra,like SPIN [17], allow to express and check a number ofsituations involving mobility.

� Asynchronous communicationsare notoriously hard toreason about and debug. For this reason, it is often assumedthat WS developers restrict themselves to synchronous com-munications, implementing explicit handshaking to force syn-chronisation whenever needed. In cases where asynchronicitycannot be avoided, a number of languages and tools can beused to perform automated reasoning, the most popular ofwhich is probably theSPIN model-checker for thePromelaprocess algebra.

We last mention briefly that otherPAs have been proposedfor specifying many other aspects like stochastic behaviour,fault tolerance,etc. Thereby,PA offers a great set of possiblelanguages suitable to specify basicWSs, as well as moreadvanced ones involving different constructs depending onthe application domain. The last reason, and not the least,to consider the use ofPA is their well-foundedness, theirformality, the experience acquired in this domain through some25 research years, and therefore the existence of powerfulreasoning tools issued from this theoretical and practicaleffort.

C. Automated Reasoning on Web Services

A major interest of using abstract languages grounded ona clear semantics is that automated tools can be used tocheck that a system matches its requirements and worksproperly. Specifically, these tools can help 1) checking that twoprocesses are in some precise senseequivalent– one processis typically a very abstract one expressing the specification ofthe problem, while the other is closer to the implementationlevel; 2) checking that a process verifies desirableproperties– e.g., the property that the system will never reach someunexpected state. Revealing that the composition of a numberof existing services does not match an abstract specificationof what is desired, or that it violates a property which isabsolutely needed can be helpful to correct a design or todiagnose bugs in an existing service. We introduce the twogeneral classes of techniques used for verifying processes; thecase study we provide in Section III will illustrate their use totackle choreography issues.

1) Verifying Equivalences:Intuitively, two processes or ser-vices are considered to be equivalent if they areindistinguish-able from the viewpoint of an external observer interacting

with them. This notion has been formally defined in thePAcommunity, and several notions of equivalence have beenproposed. Here we briefly illustrate them in order for thereader to be aware of some of their subtleties relevant to thecontext ofWSs; more on the subject can be found in [25].

A first approach is to consider two processes to be equiva-lent if the set oftraces they can produce is the same (trace-equivalence). For instance, the possible executions of the pro-cesses

� ��� �� � ��� and�� �� �� � �� ��� are shown in Fig. 5 part

(A), where messages�,

�and

�can be respectively understood

as requests for reservation, editing data and cancellation. Bothof these two processes will have

� ��and

� ��as possible traces:

they will either receive the messages�

then�, or

�then

�.

Nevertheless, it is not fully satisfactory to consider these twoprocesses equivalent since they exhibit the following subtledifference. After receiving message

�, the first process will

accept either message�

or�. The second process behaves

differently: on receiving message�, it will either choose to

move to a state where it expects message�, or to a state where

it expects message�. Depending on the choice it makes, it will

not accept one of the messages whereas the first process leavesboth possibilities open. The second process does not guaranteethat a request for reservation (

�) followed bye.g.,cancellation

(�) will be handled correctly (

�might not be received if the

process has chosen the left-hand side branch). The notion ofequivalence calledbisimulation [25] is a refinement of traceequivalence which takes these differences into account.

a a

b c

a

b c

tau(B)(A)

bc

b c

Fig. 5. Classical examples of processes not observationally equivalent. Forinstance,� represents a request for hotel reservation,

�asks for the information

regarding the booking, while� represents cancellation.

Further subtleties arise when one has a partial knowledge ofthe behaviour of a process. This may happen for two reasons:1) during the design stage, where the specification which isbeing defined is necessarily abstract and incomplete; 2) whenone finds or reuses an existingWS, and only an interface ora partial description hiding private details is available.This isexpressed inCCS using the� symbol, which states that hiddenactions take place.� actions must be taken into account whenreasoning on the equivalence of two processes, as evidencedby Fig. 5 part (B). Both of the processes depicted here canreceive

�(edition of reservation data) or

�(cancellation). But

whereas the first one can receive any of the two, the secondone can choose to first execute some unobservable actionswhich will lead it to a state where it can only receive message�. Once again it cannot be guaranteed that the second service

will accept cancellation requests, and this depends on somedecisions it takes secretly.

Weak4 bisimulation (a.k.a. observational equivalence) is

4Another notion calledstrong bisimulationexists. It is nevertheless toorestrictive in our context because it imposes a strict matching of the �actions. Also note the notion ofcongruence, an observational equivalencewhich should be preferred when one wants processes to be equivalent in anycontext, i.e., in all possible systems using them.

therefore widely acknowledged as the finest and most appro-priate notion of process equivalence, and is implemented intools like CWB-NC, which can automatically check that twoalgebraic expressions denote the same observational behaviour.

2) Verifying Properties:The properties of interest in con-current systems typically involve reasoning on the possiblescenarii that the system can go through. An established formal-ism for expressing such properties is given bytemporal logics5

like CTL� [21]. These logics present constructs allowing tostate in a formal way that, for instance, all scenarii will respectsome property at every step, or that some particular event willeventually happen, and so on.

An introduction to temporal logic goes beyond the aims ofthis paper, but it suffices to say that a number of classicalproperties typically appear as patterns in many applications.Reusing them diminishes the need to learn all subtleties of anew formalism. The most noticeable examples are:

� Safety properties, which state that an undesirable situa-tion will never arise. For instance, the requirements can forbidthat the system reserves a room without having received thecredit information from the bank;

� Liveness properties, which state that some actions willalways be followed by some reactions; a typical example is tocheck that every request for a room will be acknowledged.

The techniques used to check whether a system described inprocess-algebraic notations respects temporal logic propertiesare referred to asmodel checkingmethods [9].

III. PROCESS ALGEBRA FOR CHOREOGRAPHY

Choreography is the problem of guaranteeing that webservices which have to cooperate to solve a specific task arecompatible,i.e., that they can interact properly. This problemis especially tricky when we put together services whichhave been designed in an open-end fashion by independentproviders. In this case, automated tools are needed to performon-the-fly compatibility checks. We claim that process algebraprovide algorithms and tools to address this problem, andwe investigate the benefits of automated tools on a case-study. Software which automatically translatesXML behaviourdescriptions into and fromPA is not available yet, and we di-rectly modelled a choreography situation in the input languageof the CWB-NC software [10], which is an ASCII notationfor CCS.

It may be helpful to the reader to position our proposal forchoreography in the framework sketched in Fig. 1. Choreog-raphy typically involves situations where the design of theservices at hand is fixed and their implementation private.Only the rich interface, including the public description oftheir behaviour, is available. Compatibility checking consistsin translating this behaviour into a process-algebraic language,which allows the automated tools to analyse the system and,possibly, detect flaws.

5This name should not give the impression that these logics introduce aquantitative notion of time, they are indeed used to expressconstraints on thepossible executions of a system.

A. The client service

This case study is related to the field of public welfare andextracted from a larger domain analysis concerning the localgovernment of Trentino (Italy). It was first dealt with in [30].This software system aims at supporting elderly citizens inreceiving sanitary assistance from the public administration.This problem involves several actors. First, we formalise theservice to be worked out as a citizen behaviour. A citizen postsa request, exchanges information with the agency, waits foraresponse, and if accepted receives a service and pays fees.

proc Citizen =’request.askInf.’provInf.

( refusal.Citizen+ acceptance.

( provT.’paymentPrivateFee.Citizen+ provM.’paymentPrivateFee.Citizen))

This service is seen as a “client” of the other servicesinvolved in the choreography, which we describe next, and wewant these other services to be compatible with it. Intuitively,this means that this set of services has to match the behaviourof the client.

B. The rest of the system

The whole system is composed of services involved whenelderly people apply for a sanitary assistance: the sanitaryagency satisfying requests, the transportation service, the mealdelivery, the bank managing funds. We start with a view of allthe processes (boxes in Fig. 6) involved in this system as wellas the synchronisations between these entities. Synchronisa-tions are denoted using lines joining the involved agents withactions and their direction (prefixed by a quote for emissions).

Cooprequest

provInf

’req req

’provT

’provM

’paymentPublicFee

paymentPublicFee ’done

done’recMoneyPossT

recMoneyPossT’recMoneyPossM

recMoneyPossM

paymentT

’paymentT

paymentM

’paymentM

’askInf

paymentPrivateFee

’refusal’acceptance

SanitaryAgency

Bank

TranspCoop

MealCoop

Fig. 6. Synchronisations in the sanitary agency

The sanitary agency manages requests submitted by elderlycitizens. First, it asks some information to the citizen whohas posted the request. Depending on that, it sends either arefusal and waits for a new request (as reflected by a recursivedefinition), or the request is accepted. In the latter case, asynchronisation is performed with the cooperative controller (itcontrols in some way both cooperatives) to order the deliveryof concrete (transportation or meal) services. Then, the agencypays some public fees to the bank and waits from the bank

component for a signal indicating that the transaction6 iscompleted.

proc SanitaryAgency =request.’askInf.provInf.

( ’refusal.SanitaryAgency+ (’acceptance.’req.’paymentPublicFee.

done.SanitaryAgency ))

Now, we introduce the behaviour of the cooperative. Thetransportation (resp. meal) cooperative provides its service,warns the bank to start the payment, and waits for the receptionof its fees. A controller, calledCoop, receives a notification ofthe agency and launches one of the possible services.

proc TranspCoop =’provT.’recMoneyPossT.paymentT.Coop

proc Coop =req.(TranspCoop+MealCoop)

The bank receives a firing message from the cooperative in-volved in the current request. The different payments are thenperformed: payment of public fees by the agency, paymentof private fees by the citizen, payment of the cooperative bythe bank. Each of them is confirmed by a message sent to theprocess which will receive or spend the money to inform it thatthe transaction has been done. Note that the specified strategyfor this service is to collect the money first and afterwardsonly then to pay for the delivered service.

proc Bank =recMoneyPossT.(

(paymentPrivateFee.paymentPublicFee.’paymentT.’done.Bank)

+ (paymentPublicFee.paymentPrivateFee.’paymentT.’done.Bank ))

+ recMoneyPossM.( ...

In this experimentation, it is worth noting thatCCS isenough to describe the main requirements of the case studywhile remaining at an abstract level. As mentioned previouslyand if needed, we could use a more expressive language.Otherwise, the binary and synchronous communication modelturns out to be enough to specify communications in thisexample. In the current specification, the modelling of a citizenas a process could be criticised because his/her behaviour doesnot belong to the system but to the environment. Nevertheless,its representation is necessary in case of simulation (closedsystem). Finally, the solution at hand is sequential (treatmentof one request after the other) and not concurrent (severalrequests could be posted and treated at the same time). Such amodel is usual inWSs where a precise task has to be workedout by composing together different distributed instancesofcomputational components (notion of transaction).

C. Reasoning

We now illustrate how reasoning tools (CWB-NC here)can help practitioners to reason on choreography issues.Basic checks like syntactical parsing and type-checking ofthe file containing the processes definitions enabled us toobtain descriptions which are free of typing error and missing

6A transaction could be defined as a complete execution of all ourinteractingWSs to solve a precise task.

declarations. These early checks were useful because wedirectly modelled our case-study in thePA language, but theywould not be needed if automated tools could directly producea trustworthy translation of theXML interfaces of runningservices into correctCCS. We then did experimentations tocheck the choreography of a system involving one citizen. Wemodelled a close system (all actions appear in the restrictionset) obtained by the following composition:

set closedRestSet4S ={ req, done, request, askInf, provInf, provM,

provT, paymentT, paymentM, paymentPublicFee,paymentPrivateFee, recMoneyPossT,recMoneyPossM, refusal, acceptance }

proc ClosedSystem =(SanitaryAgency | Coop| Bank | Citizen) \ closedRestSet4S

We experimented on a number of different versions ofeach service and used the basic verification tools providedby CWB-NC to find deadlocks, missing synchronisations andincomplete behaviours of a number of incompatible versionsof the services we experimented with. Let us insist that, ifthese services were put together, these bugs could appear atruntime during their interaction, leading to message emissionsnot received by the partner, or to services unable to terminatetheir interaction successfully, among other problems. Alltheseflaws were detected by the tool, which confirms our beliefthat automated choreography checking could be used to revealincompatibilities before engaging an interaction. In all caseswhere a problem occurs, the system gives an explanation of itsdiagnostic, which provides helpful indications on the causesof the problem. An interactive simulator can also help tracingthe possible executions, and understanding the problems thatcan arise.

But verification tools can do more than finding out bugs;because of their ability to perform exhaustive checking ofall possible behaviours, they can also be used tocertify,given compatible services, that their choreography will workfine (unless, of course, some unpredictable technical mistakearises like a network problem or a system crash somewhere).To prove this, we have to show that the composition ofthe sanitary agency, the bank and the cooperativesmatchthe client. The behaviour of the system therefore has tomirror the requester, performing receptions where the clientdoes emissions and emissions wherever it does emissions.Consequently, we want the system to be compatible withthe following process, obtained by reversing emissions andreceptions in the description of the client:

proc RCitizen =request.’askInf.provInf.(

’refusal.RCitizen+ ’acceptance.(

’provT.paymentPrivateFee.RCitizen+ ’provM.paymentPrivateFee.RCitizen))

Hence, our aim is to prove usingCWB-NC that bothRCitizen and System are equivalent, that iseq -S obseq

RCitizen System.

set restSet4S ={ req, done, paymentPublicFee, paymentT,

paymentM, recMoneyPossT, recMoneyPossM }

proc System =(SanitaryAgency | Coop | Bank) \ restSet4S

Here again, several versions of the global system wereexperimented. Let us summarise some of the incompatibilitiesthat the use of an automated system revealed. A first versiondid not consider the notion of transaction. It is necessary totake into account the fact that a task needs a sole execution ofeach process to be carried out. This kind of behaviour can bespecified using non recursive processes, or by enhancing theirbehaviour so that they agree at the end of a transaction. Thisisthe option we chose, and we used an internal synchronisationbetween theSanitaryAgency and theBank, which notify theend of their transaction using an action calleddone. A secondversion of our services was erroneous because of an overlygeneral definition of the bank service. The initial behaviourdefined different payments without more constraints (e.g., itcould accept several successive payments from a citizen atany moment). We then runCWB-NC on a system whichperformed a synchronisation between the cooperatives and thebank so that payments be performed only after the delivery ofthe service. At this level, trace equivalence is verified butnotthe observational one. Indeed, a prior modelling proposed twopossible synchronisations onreqT or reqM to fire respectivelythe transportation or meal services. Then, a single synchronisa-tion between the sanitary agency and the cooperative controllerled to the obtainment of the observational equivalence (seeFig.7 for a capture of the latter problem).CWB-NC proved thatthese services are fully compatible, and that they free of basicerrors like undesired deadlocks.

provMprovT provM

acceptance

provT

RCitizen

acceptance

SystemRCitizen

provT provM

tau (reqT) tau (reqM)

acceptance

System

provMprovT

acceptance

tau (req)

Fig. 7. Processes not observational-equivalent (left) andthe solution (right)

The last reasoning we used was to prove some temporalproperties of the system. Due to the simplicity of the casestudy, there are no critical properties to be satisfied. Weillustrate below theCWB-NC automatic capability with acouple of properties also guaranteed in [30]. They are writtenout in CTL� . The first one attests that a request can be donein one possible scenario. The second formula expresses thatthe firing of the output actionacceptance is followed eitherby a meal delivery or by a transportation assistance.

prop can_request_ctl = EF <request>tt

prop MorTafterAcceptance =AG ( (not [’acceptance]tt) \/

(AF ([’provT]tt \/ [’provM]tt)) )

IV. PROCESSALGEBRA FORORCHESTRATION

In this section, our goal is to show howPA may be usedto describe orchestration which is the problem of solvingcomplex tasks using simple services, by developing a newservice, which we refer to as theorchestratorin the following,

whose role is to manage the existing services by exchangingmessages with them. Our purpose is to reason on the inter-acting processes and in particular to validate the orchestratorservice. We assume that the otherWSs have at their disposalbehavioural interfaces from which abstract descriptions canbe extracted. Having in mind our general framework (Fig. 1),the use ofPA can be considered in two ways: i) specifyingabstractly the orchestrator and its interactions with the otherparticipants, and then encoding this new service using anexecutable language, ii) extracting an abstract representationfrom the XML-based implementation (or from a classicalprogramming language) of an orchestration service to validateits behaviour with respect to its mates. In this section, wedo not privilege one direction or the other, and focus on theabstract description level.

Some orchestration cases are now presented using our run-ning example (the sanitary agency). To make the understandingeasier, we simplify the case at hand considering: the restrictionto one cooperative therefore supplying only one service, astrict ordering of the payment (resp. public fees, private feesand payment of the cooperative), the use of non recursiveprocesses (description of a single transaction).

At first, let us present a possible description of services witha central orchestrator managing all the interactions with thecitizen (reception of requests), the bank and the cooperative.We give a glimpse of all the interacting processes in Figure 8.

’refusal’acceptance

SanitaryAgency CoopBank

paymentPrivateFee

request provInf’askInf

’prov

’req req

’recMoneyPoss1’recMoneyPoss2

’payment1 ’payment2payment1 payment2

payPF

recMP2 recMP1

’paymentPublicFee

Fig. 8. Sanitary agency: an orchestration example

The behaviour of theCoop process is simpler than the oneintroduced in Section III: it receives a request from the sanitaryagency, it delivers the effective service, it alerts the agency thatthe service has been delivered and therefore it can be paid. Wewill explain further the presence of indexes into some actionnames (e.g.,recMoneyPoss1).

proc Coop = req.’prov.’recMoneyPoss1.payment2.nil

The bank initiates its behaviour after the delivery of theservice. Hence, it receives first public fees from the agency,private fees from the citizen, and finally can proceed to thepayment of the cooperative for the delivered service.

proc Bank =recMoneyPoss2.paymentPublicFee.

paymentPrivateFee.’payment1.nil

The central part (the orchestrator) is the sanitary agency.Itsrole is to make all the participants work together in order tosolve a posted request. The agency receives requests from acitizen, exchanges information, accepts or refuses, and alertsthe cooperative in case of acceptance. This latter part of thebehaviour should be emphasized because it illustrates the useof a completely centralized manager. When the cooperativehas delivered the service and is waiting for the payment,

an interaction occurs on the messagerecMoneyPossible1

between the agency and the cooperative; this message isforwarded to the bank (recMoneyPossible2). Similarly, thepayment from the bank to the cooperative is transfered throughthe agency using messagespayment1 andpayment2.

proc SanitaryAgency =request.’askInf.provInf.

( ’refusal.nil+ ’acceptance.’req.recMoneyPoss1.

’recMoneyPoss2.’paymentPublicFee.payment1.’payment2.nil )

However, this solution could be defined differently depend-ing on the way pre-existing services are encoded. Indeed, inthe problem at hand, the bank for example may be defined aspaying directly the cooperative avoiding an intermediate relaythrough the agency. The result is overviewed in Figure 9. Insuch a situation, the orchestrator is not fully centralized, andother participants can directly interact together.

CoopBank

paymentPrivateFee ’prov

’payment

req

payment

SanitaryAgency

’refusal

’acceptancerequest

’askInf provInf

’paymentPublicFee

payPF

’req

’recMoneyPoss1

recMP1

recMP2

’recMoneyPoss2

Fig. 9. Sanitary agency: loose orchestration

Accordingly, behaviours of processes are slightly different.For illustration purposes, the agency is reported below, andthe reader may observe that the part concerning the paymentfrom the bank to the cooperative has been removed.

proc SanitaryAgency =request.’askInf.provInf.

( ’refusal.nil+ ’acceptance.’req.recMoneyPoss1.

’recMoneyPoss2.’paymentPublicFee.nil )

Finally, we stress that formal reasoning (simulation, proofproperties, equivalence checking) is helpful in the orches-tration case as well. For instance, observational equivalencebetween the (reversed) behaviour of a citizen and the bunchof processes collaborating to satisfy a request is ensured inboth orchestration descriptions introduced above.

V. CORRESPONDENCE BETWEENABSTRACT PROCESSES

AND EXECUTABLE APPLICATIONS

WSs are usually black-box components, and only theirpublic interfaces are available. By now, the current technologydoes not allow to describe behavioural interfaces, even ifprospectively, we can suppose that interfaces will be describedas behaviours and therefore abstract processes will be derivedfrom them. This question is above all of interest for chore-ography issue, but for development ofWSs (and particularlyorchestration) as well. In the orchestration case, one (or more)new WS is developed from an abstract description or directlyencoded into executable code (reverse engineering techniquesmay be used in the latter case to extract an abstract descriptionof the service and then reason on it and its mates). To sum up,

it is essential to have well-defined links (ideally, a semantic-compatible equivalence) between abstract specifications andconcrete implementations (executable code and its associatedinterface). However, this formal two-way mapping is difficultto guarantee (especially due to the absence of a well-admittedsemantics forBPEL here).

In this section, we give some guidelines for the mappingbetweenCCS processes andBPEL code built on top ofWSDL interfaces. This goal is achieved by identifying similarconcepts at both abstraction levels. We illustrate these links byshowing a piece of theBPEL implementation for the sanitaryagency system. We emphasize that, at the implementationlevel, we do not focus only on interfaces (it would be thecase for the choreography issue) since behaviour-based oneshave not emerged yet. At this level, the current technology isWSDL which defines only input and output messages. In theremainder of this section, with regards to the existing tech-nologies (especiallyWSDL), we tackle theWSs developmentissue and not the choreography one.

BPEL is an XML-based notation for specifying businessprocess behaviours.BPEL is layered on top of the servicemodel defined byWSDL. A business process defines how tocoordinate the interactions between a process instance anditspartners (described inWSDL). In this sense, aBPEL processdefinition provides and/or uses one or moreWSDL interfaces,and provides the description of the behaviour and interactionsof a process instance relative to its partners. The reader isreferred to [1] for a comprehensive description ofBPEL.

First of all, some basic notions are defined inWSDL. Thebasic brick of behaviour inPA, the so-called action or message(denoting emissions or receptions), finds its equivalent inmes-sages described inWSDL which are completely characterizedusing themessage, portType, operationand partnerLinkTypeattributes. Synchronized actions are equivalent toBPEL in-teractions, especially in our case in which we deal only withbinary communication (the core of theBPEL process modelbeing the notion of peer-to-peer interaction between partners).An abstract action accompanied with a reception may beexpressed as a reception of a message using thereceiveactivityin BPEL. On the other side, an emission corresponds inBPELto the asynchronous invokeactivity. At the abstract level,an emission followed immediately by a reception matchesthe BPEL synchronous invoke, performing two interactions(sending a request and receiving a response). On the oppositeside, the complementary reception/emission is equivalentto areceiveactivity followed by areply one.

BPEL services and abstract processes correspond to eachother. A global abstract system is described using a mainbehaviour made up of instantiated processes composed inparallel and synchronizing together (the restriction set is usedin CCS to make explicit these synchronizations). Let usobserve that the main specification (

� � � ����� ,

�denoting

a parallel composition) does not match with aBPEL process.The correspondence is that each abstract instantiated process( �

), pertaining to the global system mentioned previously,matches aBPEL service. Accordingly, the architecture of thespecification is preserved.

Regarding the dynamic constructs, firstly an overall activityis completed when the end of its behaviour (0 inCCSand end of the main sequence inBPEL) is reached. TheterminateBPEL activity may be used in case of abnormaltermination. Agent recursion (corresponding to the repetitionof their behaviour) may be represented using awhile activity.However, we emphasize that a specific abstract agent worksout a precise task required by a more complex transaction,and consequently does not need this notion of recursivity atthe implementation level. Such a call of a specific piece ofcode is often encoded as a creation of a new instance.

Thesequenceactivity in BPEL matches the abstract prefix-ing construct. Intuitively, the abstract choice (possiblymul-tiple) corresponds either to theswitch activity defining anordered list ofcase(a casecorresponds to a possible activitywhich may be executed) or to thepick (in case of multiplereceptions). An hidden action is equivalent inBPEL to a localevolution of aWS which is not visible from an external pointof view. Accordingly, it corresponds to one (or more)assignstatement. We summarize in Table I, the guidelines connectingeither description level.

CCS WSDL/BPELactions message, portType, operation,(emissions/receptions) partnerLinkType(WSDL),

and receive, reply, invoke (BPEL)sequence ’.’ sequencechoice ’+’ pick andswitchparallel composition ’:’ interactingWSsrestriction set ’3’ interactions andassigntermination ’0’ end of the mainsequenceor terminaterecursive call new instantiation orwhile� actions (internal) assign, (external) interactions

TABLE I

MAPPING BETWEENCCS AND WSDL/BPEL

Now, we show an excerpt of theBPEL code correspondingto the sanitary agencyWS as written out before inCCS inSection III. Below, the behaviour of theSanitaryAgency isbriefly introduced (someXML details have been removed forlack of space). We can emphasize the reception of a request(initiating from a customer), the exchange of information,therefusal or acceptance of the service. It is obvious that lessdetails appear at the abstract level (respectively more detailsat the executable level). As an example, see the conditionexpressed in theBPEL code below determining whether therequest is accepted or not. Experimentations have been carriedout usingCollaxa BPEL Server,BPEL Console, andCollaxaBPEL Designer7.

<process name="SanitaryAgencyProcess"...

<sequence><receive name="receiveRequest"

partnerLink="Citizen"portType="cit:requestPT"operation="requestO"variable="request"createInstance="yes">

</receive>

7http://www.collaxa.com/

<invoke name="invokeCitizen"...

</invoke><switch><case condition="cit:getContainerData(

’provInfC’, ’aCondition’) = true()"><sequence>

<reply name="replyAcceptance"...

</reply>...

</sequence></case><otherwise>

<reply name="replyRefusal"...

</reply></otherwise></switch>

</sequence></process>

VI. RELATED WORK

In this paper, we advocate the use ofPA to describe andcomposeWSs at an abstract level. As previously motivated,this abstract specification level is connected to the executablelevel (system development or reverse engineering). The ap-plication layer is made up of all the existing standards. Ontop of theWSDL andSOAP well-known standards, differentXML-based languages forWS description and compositionhave already been proposed, likeXLANG [33] or DAML-S[2] (recently renamedOWL-S). An agreement is emergingto favour theBPEL execution language at this level. At amore abstract level, works originally tended to describeWSsand their composition using semi-formal notations (no formalmeaning), especially workflows [20], and are therefore error-prone and not supported by tools other than editors. Morerecently some more formal proposals grounded for most ofthem on transition system models (LTS, Mealy automata, Petrinets) have been suggested [18], [27], [15], [4], [19].PAs areadequate to describeWSs, because they allow to formallydescribe dynamic processes. Compared to the automata-basedapproaches, its main benefit is its expressiveness, particularlydue to a large number of existing calculi enabling one tochoose the most adequate formalism depending on its final use.Additionally, another interest ofPA is that their constructs areadequate to specify composition due to their compositionality8

property (not the case of the Petri net notation for instance).At last, textual notations (even if sometimes criticized tobeless readable than transition systems) are more adequate todescribe real-size problems, as well as to reason on them.

Regarding the reasoning question, works have been dedi-cated to verifyingWS descriptions to ensure some propertiesof systems [14], [12], [27], [13], [26]. These works usemodel checking to verify some properties of cooperatingWSsdescribed usingXML-based languages (DAML-S, WSFL,BPEL, WSCI). Accordingly, they abstract their representationand ensure some properties using ad-hoc or existing tools.As far as the composition is concerned, different techniqueshave emerged which ensure a correct composition such as

8Compositionalitycorresponds to the possibility to build bigger behavioursfrom small ones.

automatic composition [4], [23], planning [22], [19] or modeldeduction [27]. However, most of the other proposals do notensure this composition correctness [13], [18], [15]. The useof powerful proof theory accompanyingPA helps to readilycheck equivalences between possible requests and compositeWSs, and then to ensure a correct composition. On a widerscale,PA are equipped with state-of-the-art reasoning tools,such as theSPIN model checker or theCADP toolbox, andhence are adequate to any kind of press-button reasoning.

Last but not least are works connecting abstract represen-tations of WSs with XML-based standards [14], [30], [13],[27], [34]. Let us emphasize that we have already proposedsome guidelines to map process algebra andBPEL in relatedpapers [31], [8]. So far, we cannot argue to achieve a betterresult than works quoted previously, but we already proposeprecise guidelines in the context of our proposal (use ofPA). Inour opinion, a formal correspondence is essential at this levelto preserve properties proved on the abstract specification,and to extract automatically a semantic-compatible abstractdescription from an executable implementation.

In comparison to all these existing works, the strength ofour approach is to work out all these issues (description,composition, reasoning) at an abstract description level,basedon the use of existing approaches and tools, while keeping atwo-way connection with the application layer. Furthermore,we advocate a general approach which is not restricted to asingle description technique or reasoning tool.

VII. C ONCLUDING REMARKS

WSs are an emerging and promising area involving impor-tant technological challenges. Some of the main challengesare to correctly describeWSs, to compose them adequatelyand/or automatically, and to discover suitableWSs workingout a given problem. In this paper, we proposed a frameworkto develop and reason aboutWSs at an abstract level. Theusefulness of such a representation is manifold: (i) designingan application based onWSs, (ii) applying reverse engineeringto reason on deployedWSs, (iii) considering such abstractprocesses asWS public interfaces and therefore dealing withthem for issues like composition. We advocate the use ofPA as an abstract representation means to describe, composeand reason (simulation, property verification, correctness ofcomposition) onWSs. We especially illustrated our approachwith examples of abstract descriptions and proofs for thechoreography and orchestration issues. In addition, linkshavebeen defined between abstract and concrete descriptions. Ona wider scale, we claim that our approach is general becausewe do not focus on a specific language, but on a whole familyof formal description techniques. Furthermore, all the theoret-ical foundations underlyingPA are adequate to describe andreason on services, especially to ensure correct compositionas illustrated through the sanitary agency case study.

A first continuation of this work is to experiment the use ofPAs involving more advanced constructs likeLOTOS or the� -calculus. Indeed, it sounds realistic to represent less abstractprocesses,e.g.,in case ofWSs development (data descriptionfor negotiation concerns as an example [31]), or to specify

mobility or reconfiguration (one process may receive a nameattached to an action that it uses afterwards dynamically asa new communication port). Another direction is the auto-matic composition ofWSs. In this paper, equivalence wasused to ensure a correct composition. A possible idea couldbe to complement the bisimulation theory to add automaticcapabilities to the current framework. A related perspective isthe study of the compatibility notion (compatibleWSs are ableto communicate correctly and therefore can be composed). Inthe proposal at hand, we advocated a notion of compositionbased on bisimulations. Looser notions might be envisagedand need to be studied [7]. A last perspective is to work onthe formalisation of connections between abstract and concretedescriptions. Some ideas in this direction have been sketchedand should be experimented thoroughly.

REFERENCES

[1] T. Andrews, F. Curbera, H. Dholakia, Y. Goland, J. Klein,F. Leymann,K. Liu, D. Roller, D. Smith, S. Thatte, I. Trickovic, and S. Weerawarana.Specification: Business Process Execution Language for WebServicesVersion 1.1. 2003. Available athttp://www-106.ibm.com/developerworks/library/ws-bpel/.

[2] DAML-S Coalition: A. Ankolekar, M. Burstein, J. R. Hobbs, O. Lassila,D. Martin, D. McDermott, S. A. McIlraith, S. Narayanan, M. Paolucci,T. Payne, and K. Sycara. DAML-S: Web Service Description fortheSemantic Web. InProc. of ISWC’02, volume 2342 ofLNCS, pages348–363, Italy, 2002. Springer-Verlag.

[3] J. C. M. Baeten and W. P. Weijand.Process Algebra, volume 18of Cambridge Tracts in Theoretical Computer Science. CambridgeUniversity Press, Cambridge, England, 1990.

[4] D. Berardi, D. Calvanese, G. De Giacomo, M. Lenzerini, and M. Me-cella. Automatic Composition of E-services That Export Their Behavior.In Proc. of ICSOC’03, volume 2910 ofLNCS, pages 43–58, Italy, 2003.Springer-Verlag.

[5] J. A. Bergstra, A. Ponse, and S. A. Smolka, editors.Handbook ofProcess Algebra. Elsevier, 2001.

[6] T. Bolognesi and E. Brinksma. Introduction to the ISO SpecificationLanguage LOTOS. InThe Formal Description Technique LOTOS, pages23–73. Elsevier Science Publishers North-Holland, 1989.

[7] L. Bordeaux, G. Salaun, D. Berardi, and M. Mecella. Whenare twoWeb Services Compatible? InProc. of TES’04. To appear.

[8] A. Chirichiello and G. Salaun. Designing Executable and Certified WebServices from Abstract Descriptions. Submitted.

[9] E. M. Clarke, O. Grumberg, and D. Peled.Model Checking. The MITPress, 2000.

[10] R. Cleaveland, T. Li, and S. Sims.The Concurrency Workbench of theNew Century (Version 1.2). Department of Computer Science, NorthCarolina State University, 2000.

[11] L. de Alfaro and T. A. Henzinger. Interface Automata. InProc. jointESEC/FSE’01, pages 109–120, Austria, 2001. ACM Press.

[12] A. Deutsch, L. Sui, and V. Vianu. Specification and Verification ofData-driven Web Services. InProc. of PODS’04, USA, 2004. ACMPress.

[13] H. Foster, S. Uchitel, J. Magee, and J. Kramer. Model-based Verificationof Web Service Compositions. InProc. of ASE’03, pages 152–163,Canada, 2003. IEEE Computer Society Press.

[14] X. Fu, T. Bultan, and J. Su. Analysis of Interacting BPELWeb Services.In Proc. of WWW’04, pages 621–630, USA, 2004. ACM Press.

[15] R. Hamadi and B. Benatallah. A Petri Net-based Model forWeb ServiceComposition. InProc. of ADC’03, volume 17 ofCRPIT, Australia, 2003.Australian Computer Society.

[16] C. A. R. Hoare. Communicating Sequential Processes. Prentice-Hall,1984.

[17] G. Holzmann.The SPIN Model-Checker: Primer and Reference Manual.Addison-Wesley, 2003.

[18] R. Hull, M. Benedikt, V. Christophides, and J. Su. E-Services: a LookBehind the Curtain. InProc. of PODS’03, pages 1–14, USA, 2003.ACM Press.

[19] A. Lazovik, M. Aiello, and M. P. Papazoglou. Planning and Monitoringthe Execution of Web Service Requests. InProc. of ICSOC’03, volume2910 ofLNCS, pages 335–350, Italy, 2003. Springer-Verlag.

[20] F. Leymann. Managing Business Processes via Workflow Technology.Tutorial at VLDB’01, Italy, 2001.

[21] Z. Manna and A. Pnueli.Temporal Verification of Reactive Systems:Safety. Springer, 1995.

[22] S. A. McIlraith and T. C. Son. Adapting Golog for Composition ofSemantic Web Services. InProc. of KR’02, pages 482–496, France,2002. Morgan Kaufmann Publishers.

[23] B. Medjahed, A. Bouguettaya, and A. K. Elmagarmid. Composing WebServices on the Semantic Web.The VLDB Journal, 12(4):333–351,2003.

[24] G. Meredith and S. Bjorg. Contracts and Types.Communications of theACM, 46(10):41–47, 2003.

[25] R. Milner. Communication and Concurrency. International Series inComputer Science. Prentice Hall, 1989.

[26] S. Nakajima. Model-checking Verification for ReliableWeb Service. InProc. of OOWS’02, satellite event of OOPSLA’02, USA, 2002.

[27] S. Narayanan and S. McIlraith. Analysis and Simulationof WebServices.Computer Networks, 42(5):675–693, 2003.

[28] M. Y. Ng and M. Butler. Tool Support for Visualizing CSP in UML.In Proc. of ICFEM’02, volume 2495 ofLNCS, pages 287–298, China,2002. Springer-Verlag.

[29] J. Parrow. An Introduction to the� -Calculus. In[5] , chapter 8, pages479–543. Elsevier, 2001.

[30] M. Pistore, M. Roveri, and P. Busetta. Requirements-Driven Verificationof Web Services. InProc. of WS-FM’04, Italy, 2004. To appear inENTCS.

[31] G. Salaun, A. Ferrara, and A. Chirichiello. Negotiation among WebServices using LOTOS/CADP. In M. Jeckle and L.-J. Zhang, editors,Proc. of ECOWS’04, volume 3250 ofLNCS, Germany, 2004. Springer-Verlag. To appear.

[32] S. Schneider, J. Davies, D. M. Jackson, G. M. Reed, J. N. Reed, andA. W. Roscoe. Timed CSP: Theory and Practice. InProc. of REXWorkshop on Real-Time: Theory in Practice, volume 600 ofLNCS, pages640–675, Germany, 1992. Springer.

[33] S. Thatte. XLANG: Web Services for Business Process Design. 2001.[34] M. Viroli. Towards a Formal Foundation to Orchestration Languages.

In Proc. of WS-FM’04, Italy, 2004. To appear in ENTCS.[35] W3C. Web Services Choreography Description Language 1.0.

Available athttp://www.w3.org/TR/ws-cdl-10/.[36] W3C. Web Services Choreography Interface 1.0.

Available athttp:www.w3.org/TR/wsci.[37] W3C. Web Services Choreography Requirements 1.0 (draft).

Available athttp:www.w3.org/TR/ws-chor-reqs.