Translating bp-calculus specifications to verified bpel
code : A proof of correctness
Faisal Abouzaid and John Mullins CRAC Laboratory, Ecole Polytechnique de Montreal,
P.O. Box 6079, Station Centre-ville, Montreal (Quebec), Canada, H3C 3P8
Abstract. Orchestration allows the construction of more and more complex Web Services (WS) by featuring interoperability between highly distributed and het-erogeneous web-based services. While Business Process Execution Language for Web Services (WS-BPEL) is the widely accepted standard for designing Web Ser-vice compositions, it is critical to formally analyze WS-BPEL specifications in order to increase their reliability and consistency and to automatically generate correct WS-BPEL code whose behavior has been formally verified. In this pa-per we present a verification framework for checking the equivalence between a formal specification expressed in the service specification language BP-calculus and its implementation expressed in WS-BPEL. To realize this checking, we pro-vide a two-way mapping between BP-calculus and WS-BPEL and we formally prove the correctness of this mapping by using an observational equivalence. This allows checking functional properties of service-oriented applications formally specified using the BP-calculus. The properties are described by means of the
π-logic, that is well suited to capture peculiar aspects of services formalized in
π-like languages. In order to show the feasability and efficiency on a large-scale of this approach, we present the BP-calculus specification and the verification of a trade market service scenario.
1
Introduction
Web services are autonomous, stateless, platformindependent and composable compu-tational entities that can be published, located and invoked through the Web via XML messages. They represent a well accepted implementation of service-oriented comput-ing (SOC), a new paradigm for developcomput-ing loosely coupled, scalable and interoperable applications over the Internet.
Composition of such web services, allows for the creation of customized complex applications based on reutilization and composition of existing services. Orchestrations describe the way in which separate Web Services can be brought together in a consistent manner to provide a higher value service and includes the management of the transac-tions between the individual services, including any necessary error handling, as well as describing the overall process.
Business Process Execution Language for Web Services (WS-BPEL) [1] is the widely accepted standard that permits to define the business logic between processes interacting in an orchestration. A WS-BPEL process defines how multiple service in-teractions between partners can be coordinated internally, that is their orchestration, in order to achieve a business goal.
Fig. 1.Verification Framework
Since bad orchestration will result in bad and unprofitable services, it is important to have tools and means to ensure the correctness of such compositions. Current software engineering technologies for SOC, do not support verification tools.
Formal methods and associated logics allow a design time verification of the model behavior and strengthen the correctness of service compositions [2] because they are based on solid theoretical concepts. One of the most relevant method is the rich theory of the π-calculus [3] because of its capacity to model mobility, by passing channel names, as data, through channels.
As well, logic-based languages are used to formally and unambiguously specify the behavior of a system. Several logics have proved their ability to analyze upon complex structures such as SOC applications. However, it is convenient to exploit a logic with modalities indexed byπ-calculus actions such as theπ-logic introduced by Ferrari & al. [4].
This article focuses on the translation from aπ-like language (BP-calculus) into executable code specified in WS-BPEL. Therefore, the main feature of our approach is the definition of a two-way mapping between BPEL and the BP-calculus as it is shown in Figure 1.
The formal specification is useful as a first description and analysis step. It enables to clarify the problem with focus on its essential aspects. It also enables use of verifi-cation tools to validate the correct behavior of specified services and to verify relevant properties expressed in theπ-logic. The formal specification is useful as a first descrip-tion and analysis step.
Moreover the same approach is used to verify and correct existing BPEL specifica-tion by extracting abstract representaspecifica-tion from existing implementaspecifica-tions.
In order to increase reliability and consistency in a WS-BPEL design process, we have designed a π-calculus based framework that allows the integration of a well-established general purpose model-checker toolkit (the HAL Toolkit [4]) and the gen-eration, from the model-checkers’s modeling language, of a WS-BPEL process that has the same behavior as the verified abstract model.
However a central question is how to prove the correctness and the soundness of the two-way mapping. The formal proof is based on the equivalence notion and on the presumption that we provide a semantics of WS-BPEL. For this purpose, we base our
work on the one of Lucchi and Mazzarra that have provided a formal semantics of the a subset of BPEL language. The semantics is based on the pi-calculus. In this paper we complete this semantics by specifying some missing operators. Then we present an attempt to formally prove the semantics preservation between the BP-calculus and this subset of BPEL. details of the discussion are presented in Section 3.2.
We use an observational equivalence to certify the correctness of the translation (see Section 2.5). The abstract modeling language reflects, as close to possible, the intentions of orchestration conductors and workflow constructs. The HAL Toolkit is used to check both the equivalence between the implementation in WS-BPEL and the formal specification in BP-calculus, by checking that they satisfy the same set of logic formulas expressed in theπ-logic.
This framework has been presented in details in [5] and [6]. In short, in order to achieve an iterative verification/refinement process between the BP-calculus spec-ification and its corresponding WS-BPEL code, the BP-calculus semantics has been designed as the converse mapping of the Lucchi-Mazzara’sπ-based semantics for WS-BPEL [7] in such a way that bothπ-processes involved are equivalent (see Section 3.3). Together with extensions to cope with complex structures such as handlers and cor-relation sets in the specification, the framework appears well-suited for verification of temporal properties upon real-life processes.
Many properties of interest for services and SOC applications have been defined so far (see [2] and [8]): Availability, reliability , responsiveness, fairness, fault-tolerance, non-ambiguity, synchrony or asynchrony, persistence and sequentiality (see Section 5.4 for examples).
Tools and methods exist that allows for the verification of such properties. We chose to use the HAL (HD-Automata Laboratory) Toolkit [4], an integrated tool set for the specification, verification and analysis of finite representationπ-calculus agents using history automata. This choice is motivated by the fact that the environment supports verification of required behavioral properties ofπ-calculus agents expressed as formula of theπ-logic [4].
Once the a formal specification of system verified and assessed to be correct, one can automatically generate the corresponding WS-BPEL code. This code is complete and includes complex constructs, such as compensation sets and event and fault han-dlers. The correctness of the generated code is based on the following notion of behav-ioral equivalence: if two processes verify the same set of properties, expressed in the same given logic, then they are declared to be equivalent.
As an illustration of the ability of our approach to facilitate the design of correct and well-formed WS-BPEL specifications, we present a case study about a capital market service that analyses and proceeds to the selling of large amount of shares. We first for-malize the process using the BP-calculus. We then express the desired properties using formulas expressed inπ-logic [4] before verifying them with the HAL Toolkit. When the specification is assessed to be correct in relation to the desired properties, we pro-ceed to the automatic generation of the corresponding BPEL code. The generated code is mapped again into a formal specification that is verified for the desired properties. If the generated specification is validated, then we can assume that the BPEL code is correct.
Related works: Numerous works have been devoted to the formal specification of busi-ness process languages, especially WS-BPEL, using different formalisms such as Petri Nets ([9], [10]) , Abstract State Machines [11], FSM [12]. But the more promising approaches use process algebras and several formalisms based on PA have been pro-posed: SOCK [13], COWS [14] or SSCC [15], each one handling a particular features of the problem. The framework we present is based on PA, and more precisely on the
π-calculus, and differ from previously cited approaches since it focuses on a lower level of abstraction and is closer to WS-BPEL.
In [16] authors present a two-way mapping between WS-BPEL and LOTOS [17] that is limited to some basic constructs of WS-BPEL and no formal proof of the cor-rectness of the mapping is provided, arguing the lack of a semantics for WS-BPEL.
Lucchi and Mazzara [7] provided the firstπ-calculus based semantics to WS-BPEL and that present timed and non-timed extensions of theπ-calculus, called webπ, tailored to study a simplified version of the scope construct of WS-BPEL. We aim to complete this work since we provided a generalization of the semantics to the whole language including new features provided by the version 2.0 and a two-way mapping between our formalization we called BP-calculus and WS-BPEL (see [5] for details). We also use this semantics to formally prove the correctness of the mapping we present. Structure of the paper: The rest of the paper is organized as follows. Section 2 in-troduces some preliminaries e.g. the syntax of the BP-calculus (Section 2.2) and the pi-logic (Section 2.6), while Section 3.2 briefly presents a WS-BPEL semantics of BP terms. The mapping process is illustrated in a step-by-step way while modeling a trad-ing market service scenario. Section 4 presents the verification framework that is used in Section 5 to verify the illustrating example and to present the results of the verification. In Section 6 we conclude and provide and some directions for future works.
2
Preliminaries
2.1 WS-BPELWS-BPEL [1] is an XML-based specification language for describing business pro-cesses orchestrating the interaction of different, existing and possibly dynamically em-erging Web Services. As such, it builds on top of the WSDL language for describing the interface of Web Services. This is specified in terms of port types, actions, and mes-sages. BPEL supports the definition of two types of processes: executable and abstract processes. An abstract, (not executable) process is a business protocol, specifying the message exchange behavior between different parties. An executable process, speci-fies the execution order between a number of activities. However, in this paper we will mainly refer to executable BPEL processes.
Activities describe the precise behavior of the business process. Basic activities in-clude activities such as sending (invoke), receiving (receive) requests and replies ( re-ply), which can specify one or more existing correlation sets they must adhere to, or new correlation sets to be initialized. Among other basic activities, there are variable assignment (assign), synchronization of internal concurrent activities through private source and target links (links), waiting for a timeout (wait), and raising faults (throw).
Structured activities realize sequential composition (sequence), guarded choice (pick), parallel composition (flow), iteration cycles (while,foreachandrepeat), and conditional (if then else).
2.2 The BP-calculus
The π-calculus is sufficient to reason on orchestrated services. However, this could be very difficult and confusing. This the reason why we introduce other orchestration primitives in a variant of theπ-calculus we call the BP-calculus.
We present in this section the syntax of this language. The operational semantics and the general guidelines that led to the design of the BP-calculus have been presented in previous papers ([5], [6]).
Syntax of the BP-calculus
Terms. The set of termsT consists of variablesV, namesN and values (U) (integers, booleans, strings, ...). For each termt,f v(t)is the set of variables int. A message is a closed term (i.e. not containing variables). The set of messages is denotedM.
Functions. Primitives that manipulate messages, are modeled by functions in F ⊆ [Mk → Mn].
Syntax. We letx˜= (x1, ..., xn), (resp.˜a= (a1, ..., am),u˜= (u1, ..., um)) range over the infinite set of n-tuples of variable (resp. name, value) identifiers. We denotex˜←u˜ the assignment of valuesu˜to variablesx˜.
Table 1 introduces the syntax of the BP-calculus.
The intended interpretation of the processes is as follows: Interpretation
– athMi(t ∈ {invoke, reply, throw}) is the usual output which can be an invo-cation, or a reply to a solicitation, or the throw of a fault, and are translated by a<reply>, an<invoke>or a<throw>. The annotations on input or output operations are used to ease the translation into WS-BPEL.
– P|Qis the parallel composition of processesP andQ. However a condition holds in this case, since we impose that the processA =P|Qterminates when bothP
andQterminate.
– A restriction(ν x)Pbehaves asPbutxis local toP.
– IGis an input guarded process andIG + IG0behaves like a guarded choice and is intended to be translated by a<pick>.
– P .c(M)Qexpresses a sequential composition from processP passingM toQ
(Qcan perform actions whenP has terminated). This is a generalisation of the action prefix operator and is useful for action refinement that allows for the step-wise construction of reactive systems. This construct allows to easily mimic the
Table 1.Extended BP-calculus Syntax Terms t::=x (metavariables) | a (names) | u (value) | (t1, . . . tk) (tuple)
C::=null| C[˜x←u˜] (correlation set) Processes : P, Q::=IG (input guard ) | cthMi.P (annotated output) | P|Q (parallel composition) | P .c(M)Q (sequential composition) | (ν n)P (restriction) | if M=N then P else Q(conditional) | [˜x←f(M1, ..., Mn)]P (function evaluation) | A(x1, . . . , xn) (service definition) | [C:P]c(˜x).A(˜y) (instance spawn) Guarded choice : IG::=0 (empty process) | cs(u).P (annotated input) | IG+IG0 (guarded choice) Scopes : S::={x, P, H˜ } (scope) H ::=Q iWi(Pi1,· · ·, Pini) (handlers) E ::=S | P | S|P (global system)
<sequence>construct of WS-BPEL. Note that it is not a necessary one, for it can be expressed by action prefix and parallel operator. This operator with in-formation passing is needed since sequentially may combine two activities which include some name input on common names. This requires to pass additional infor-mation to bind the free names of the second activity. We let sequence have higher priority (i.e. bind more tightly) than parallel composition and external choice, i.e.
a1 .c(M) a2 | a3 .c(M) a4 stands (a1 .c(M) a2) | (a3 .c(M) a4) and a1 .c(M) a2 +a3stands for(a1 .c(M) a2) +a3.
– if then elseexpresses a classical choice based on messages identity is intended to be translated by anif then elseconstruct in WS-BPEL 2.0.
– Cis a correlation set, i.e a set of specific valued variables within a scope acting as properties and transported by dedicated parts of a message. Its values, once initi-ated, can be thought of as an identity of the business process instance. Intuitively, [C:P]cA(˜x).A(˜y)represents an orchestration service running a process defined as
cA(˜x).A(˜y). A reception of a messageM over the dedicated channelcAcauses a new service instance (defined asA(˜y)) to be spawned. The processP represents the parallel composition of service instances already spawned,Cthe correlation set
characterizing instances andy˜the correlation part ofM. See tha next paragraph for a detailed discussion of this specific operator.
– [x←f(M1, ..., Mn)]P assigns the valuef(M1, ..., Mn)to variablexbefore ex-ecuting processP. For instance,[x← build(M1, ..., Mn)]chximeans that the n-tupleM is built from componentsM1, ..., Mnbefore being sent over the channel
c.
– A scope is a wrapper for variables, a primary activity and handlers represented as contexts.
LetS ::= {x, P, H˜ }be a scope, with handlersH ::= Q
iWi(Pi1,· · ·, Pini). Then,
• x˜are the local variables of the scope, andP its primary activity,
• H is the scope’s execution environment that is modeled as the parallel com-position of handlersWi. Each handler is a wrapper for a tuple of processes
b
P = (P1, . . . , Pn)that correspond to the activities the handler has to run when invoked. Not all handlers are mandatory.
• Wi(Pi1,· · ·, Pini)is the process obtained from the multi-hole context
Wi[·]1· · ·[·]ni by replacing each occurrence of[·]jwithPij.
• The case where the variablexis restricted to a simple processP that is not within a scope, is the usual restriction of theπ-calculus(νx)P. In this case,
chνniwherec, nare nouns will denote a bound output action.
The handlers’ syntax is out of the scope of this paper.Also, structural congruence and reduction rules of the language are omitted here (see [5], [6] for details).
However, process creation and sequentiality introduces non trivial questions of vari-able scopes and this feature have been widely discussed in [18].
Instance spawn Informal semantics of a spawn process is as follows: A process, call it the serverSexecutes an output on a channelcwith information that is received by a processCcall it the client. When receiving on channelc, the client create an instance of itself that runs in parallel with existing instances. This procedure may be repeated at will. Thus the spwan operator is implemented using theπ-calculus replication and the restriction operators, like in the following example.
LetP rovider(respClient) a process representing a provider (resp. a client). The client invokes the provider by providing a Purchase order number (P onum); both use a correlation setCto communicate. The provider may accept the order or reject it. In case of acceptation, an instance of the client is created, and none otherwise. The provider is thus :
P rovider::= [C:provider]c(ponumA˜ (˜y) . Q
The client is :
Client(c, y) := ¯chC, ponumi . D
The implementation of such processes and thus their semantics, usingπ-calculus notion of definition, replication and restriction, are given by the following process defi-nitions:
Client(c, y) := ¯chyi.y(z).Session(z)
”The provider is an infinite replication of processes receiving at the main portc
an addressyspecifying the client location. As a message is received a new process is conceptually spawned. It creates a fresh namezwhich is communicated to the client; from then on, agentInstance(z)will communicate with the client along that private channel z. Dually, the client first sends a request to the business process specifying its addressy, and receives fromy a new private channelz, which is actually used by
Session(z)to realise the rest of the conversation. This mechanism guarantees each client to have a private conversation with an instance of the server.” (see [19])
Finally, we do not need anymore to use a definition operator, since the spawn op-erator realises the desired replicated behaviour. This is the reason why the definition operation does not appear anymore in the BP-calculus syntax.
2.3 Operational Semantics
The structural congruence is the smallest equivalence relation closed under the rules in Table 2. The first six rules are standard rules of theπ-calculus. All the other rules but the last are about the sequence and scopes and we refer the reader to [5] for detailed comments. The last rule is closely related to the semantics of correlation set update (rule C-SPFin Table 3) which guarantees uniqueness of each running instance by a recursive search of the current correlation set to make sure that the new instance parameters are consistent by comparing them with the running instances’ ones before updating. Also, the last rule ensures that the correlation setsCandnull,Cwill be considered as equal along this recursive process.
P|0≡P P|Q≡Q|P P|(Q|R)≡(P|Q)|R (νu˜)0≡0 (ν u)(ν v)P ≡(ν v)(ν u)P (νu˜)P|Q≡(νu˜)(P |Q) (∀iui 6∈f n(Q)) {x, P, H˜ } | {x, Q, H˜ 0} ≡ {x, Q, H˜ 0} | {x, P, H˜ } {x, P, H˜ } |0≡ {x, P, H˜ } {x, P, H˜ } | {˜x, Q, H0} | {x, R, H˜ 00} ≡ {˜x, P, H} |({x, Q, H˜ 0} | {x, R, H˜ 00} P Bc(M) 0≡P 0 Bc(M) P ≡P P Bc(M) (Q Bc(M0) R)≡(P Bc(M) Q) Bc(M0) R (IG1 + IG2)Bc(M) P ≡IG1 Bc(M) P + IG2 Bc(M) P [C:P]cA(˜x).A(˜y)≡[null,C:P]cA(˜x).A(˜y)
Table 2.Structural Congruence.
The operational semantics of the BP-calculus is a labeled transition system gener-ated by inference rules given in Table 3.
RES P α →P0n6∈f n(α)∪bn(α) (νn)P→α(νn)P0 OPEN Pc→(n)P0c6=n (νn)Pc(→νn)(νn)P0 CLOSE P c(n) →P0Qch→νniQ0n6∈f n(P) (νn)P|Q→τ(νn)P0|Q0 TAU τ.Pτ →P OUT cthMi.Pch→MiP IN c(x).Pc(→M)P{M/x} PAR P α →P0bn(α)∩f n(Q)=∅ P|Q→αP0|Q SYNC P→αP0Q→αQ0 P|Q→τP0|Q0 STRUCT P≡P0 P0 α →Q0 Q≡Q0 P→αQ CHOICE Pi→αPi0i∈{1,2} P1+P2→αPi0 DEF P{y/˜ ˜x} α →P0A(˜x)=P A(˜x)→αP0 SEQ1 P→αP0 PBc(M)Q α →P0B c(M)Q SEQ2 Q α →Q0P≡0 PBc(M)Q α →PBc(M)Q0 SEQ3 P c(M) → P0Qc(→M)Q0P0≡0 PBc(M)Q τ →P0Bc (M)Q0 SCO P→αP0 {x,P,H}→{α x,P0,H} HAN H→αH0 {x,P,H}→{α x,P,H0} SPAR P α →P0 Q→αQ0 {x,P,H1}|{x,Q,H2}→{τ x,P0,H1}|{x,Q0,H2} IFT-M P α →P0M=N
if(M=N)then P else Q→αP0 IFF-M
Q→αQ0M6=N if(M=N)then P else Q→αQ0 EVAL M˜=f(M1,...,Mn)P{M /˜ ˜x}→αP0 [x←f(M1,...,Mn)]P→αP0 C-SP1 P α →P0 [C:P]cA(˜x).A( ˜y)→α[C:P0]cA(˜x).A( ˜y)
c-SPT createInstance(M)=true [˜z←u˜]=correlationP art(M)
[null:0]cA(˜x).A( ˜y)cA
(M)
→ [[˜z←˜u]:A( ˜u)]cA(˜x).A( ˜y)
c-SPF createInstance(M)=true [˜z←u˜]=correlationP art(M) [˜z←u˜]6∈C
[C:P]cA(˜x).A( ˜y)cA
(M)
→ [C,[˜z←u˜]:P|A( ˜u)]cA(˜x).A( ˜y) Table 3.Operational semantics of extended BP-calculus.
The first eleven rules are the standard late semantics’ ones inπ-calculus without replication. Actually, the construct [C : P]c(˜x).A(˜y)may be viewed as an indexing replication. Semantics of the sequential operator (Bc(M)) is given by rulesSEQ1,SEQ2
andSEQ3. RulesSCO,HANandS-PARdefine the behavior of scopes and handlers. These constructs are defined as multihole contexts. Thus, they can be derived from pre-vious rules for handlers are processes. Semantics for message handling is defined by rulesIFT-MandIFF-M. We refer the reader to [5] for detailed comments on these rules. RuleEVALhandles function evaluation. The last three rules cope with the corre-lation’s semantics.
Correlation’s semantics
RuleC-SP1allows a spawned serviceP to carry on in isolation.
RuleC-SPThandles the initial spawning of an instance and the initialization of a correlation set after receiving a message containing a request to create an instance. The process[null: 0]cA(˜x).A(˜y)indicates that no instance is running and the correlation set is empty. After creation of the instanceA(˜u), the correlation part of the message [˜z←u˜]is extracted from the correlation part of the requestMreceived over the channel
cAand the correlation set is updated.
RuleC-SPFmanages the subsequent instance creations. In this case, before creat-ing a new instance, an inspection of the current correlation set is performed (by mean of the recursive test[˜z ←u˜]6∈ C) in order to guarantee that the correlation of the new instanceA(˜u)is fresh i.e. is different from all service instances running in parallel and resulting in the processP.
As an example, letC= [p←null]be the correlation set with propertypset initially tonull, and R the processca(p).cbhv, pi. Basically,R receives a message from ca carrying the new value of a propertyp, which is then sent along withvto channelcb. The initial process is then :[null: 0]R
Using ruleC-SPT, it evolves as :
[null: 0]R ca→(1) [ [p←1] :cbhv, pi]R and then by ruleC-SPF:
ca(2)
→ [ [p←1] :cbhv, pi |[p←2] :cbhv, pi]R
2.4 Process Creation and Sequentiality
These two operations need a special attention since they induce nontrivial questions of variable scope.
The problems of scope and binding are aggravated by the introduction of syntac-tic substitution, because in combination with restriction and sequential composition it influences the notion of scope extrusion ( see [18] for details).
The termination predicate induces a new behaviour since terminated terms may at the same time still perform actions if they are spawned off as parallel processes. Thus, operational rules for sequential composition become as follows:
P →α P0 P . Q→α P0 . Q
PX Q→α Q0 P . Q→α Q0
The second rule is the desired behaviour, sincePX means that P terminates and thusP ≡ 0.
As seen in [6], correlation mechanisms imposes that variables are bound only once (unique binding of variables) and this brings us to formulate the following well-formedness properties that restrict the set of allowable terms.
Definition 1. A restricted BP-process is such that: – No variable is bound sequentially after it occurs free.
– Variables bound within a spawn or process definition should be restricted to that scope, This condition ensures the locality of binding.
– Restricted variables may not occur outside their scope.
We will add other rules in Section 3.3 to complete this definition.
Introducing a termination predicate allows a specific definition of bisimulation.
2.5 Bisimulation and congruence
Since we are interested in assessing the correctness of WS-BPEL specifications ex-pressed by means of BP-calculus processes, a standard approach is the use of a bisimu-lation equivalence.
Several bisimulation equivalences have been introduced for theπ-calculus [San-giorgi and Walker 2002]; they are based on direct comparison of the observable ac-tions π-agents can perform. They can be strong or weak, early [Milner et al. 1993], late [Milner et al. 1992] or open [Sangiorgi 1993]. Here, we consider only strong early bisimulation.
Definition 2. A binary relationBover a set of BP-processes is a strong early simula-tion if, whenever PBQ, we have that :
– ifP →µ P0andf n(P, Q) ∩ bn(µ) =∅, then there exists Q’ such thatQ→µ Q0
and P’BQ’. – ifPXthenQX
The side condition (f n(P, Q) ∩ bn(µ) = ∅) ensures that there is no free name capture in both processes.
RelationB is a strong early bisimulation denoted∼BP if both B and B−1 are simulations. Two BP-processes are strongly bisimilar (P ∼BP Q)if there exists a bisimulationBsuch asP B Q.
Two agents P and Q areearly bisimilar, writtenP ∼BP Q(or simplyP ∼Qif it is clear from the context that we are talking about BP-calculus bisimilarity) ifP RQ
The condition on process termination is added to ensure congruence. Indeed, let
R = ¯xhi, then, without this condition, we would have[C : P]R ∼BP R. But these terms have different behaviours in regard with sequential composition, sinceR termi-nates after an emission, while[C:P]Rdoes not. The reader is referred to [18] for more details.
The standard approach to capturing correctness ofπ-calculus specification is through the use of a bisimulation equivalence. However, in some cases, it could be more useful to check whether crucial properties (such as a variety of safety and liveness properties) hold. We need thus to introduce a logic that is adequate with the calculus. We also need to study the question of how the logic behaves with respect to a bisimulation equiva-lence. Usually, the logic behaves well, provided that it is adequate with respect to the bisimulation equivalence: two processes are bisimilar if they satisfy exactly the same set of logical formulae.
2.6 Theπ-logic
In order to formally and unambiguously specify the behavior of a system written in the π-calculus, we use the π-logic. This logic has been introduced by Ferrari & al. [4] in order to express temporal properties ofπ-processes. It adds the possible future modalities EF φ andEF{χ}φ modalities to the modalities for strong nextEX and weak next< µ >modalities defined by Milner [20]. Syntax of theπ-formulas is:
φ::=true| ∼φ|φ&φ0|EX{µ}φ|EF φ|EF{χ}φ
whereµis a pi-calculus action andχcould beµ,∼µ, orW
i∈Iµiand where I is a finite set.
The semantics of theπ-formulae is given below: – P|=truefor any processP;
– P|=∼φiffP6|=φ;
– P|=φ&φ0iffP |=φandP |=φ0;
– P|=EX{µ}φiff there existsP0such asP −→µ P0andP0 |=φ(strong next); – P |= EF φiff there exists P0, ..., Pn andµ1, ..., µn, withn ≥ 0, such as P =
P0 −→µ1 P1... −→µn PnandPn |=φ. The meaning ofEF φis thatφmust be true sometimes in a possible future.
– P |= EF{χ}φif and only if there exists P0, ..., Pn andν1, ..., νn , withn ≥ 0, such thatP =P0 ν1 −→ P1... νn −→ PnandPn|=φwith: • χ=µfor all1≤j≤n, νj=µ or νj =τ; • χ=∼µfor all1≤j≤n, νj 6=µ or νj=τ; • χ=W
i∈Iµi: for all1≤j≤n, νj =µifor somei∈I or νj=τ.
The meaning ofEF{χ}φis that the truth ofφmust be preceded by the occurrence of a sequence of actionsχ.
Some useful dual operators are defined as usual:
– φ ∨ φ0 ≡∼(∼φ& ∼φ0). – AX{µ}φ ≡ ∼EX{µ} ∼φ.
– < µ > φ ≡ EF{τ}EX{µ}φ(weak next). The weak next modality< µ > φ, means that a number of unobservableτactions can be executed before actionµ. – [µ]φ ≡ ∼< µ >∼φ(Dual of weak next).
– AGφ ≡ ∼EF ∼φ. The always operatorsAGφ, means thatφis true now and always in the future.
– AG{χ}φ ≡ ∼EF{χ} ∼φ(always) whose meaning is thatφis true now and in all future states reachable performing sequences of actionsχ.
π-logic formulae are expressive enough to naturally specify and verify liveness and safety properties and others.
3
Equivalence and mapping
In this section, we present the two-way mapping between the BP-calculus and WS-BPEL. To as-sert the correctness of the mapping we first introduce a definition of an equivalence that allows to decide that a processP and a processP0obtained by translatingPinto BPEL and then recover-ing a BP-ProcessP0by translation to BP-calculus, satisfy the same set of behavioural properties or not.
3.1 Adequacy
In the verification process, we are interested in stating that two processes satisfy a same set of properties expressed in a given logic. In particular, this is useful to prove the two-way mapping of Section 3.2.
Definition 3. [Adequacy] A logicLis adequate with respect to, a relation (R) defined on a given process languageP, if
(∀φ∈ L,∀P, Q∈ P, P |=φ⇔Q|=φ) ⇔ P RQ
that is,PRQif and only ifPandQsatisfy the same formulae.
LetT h(P) ={φ:P |=φ}, and the relation be the bisimulation (∼BP), thus the previous
requirement is written:
P∼BP Q ⇔ T h(P) =T h(Q)
that is astrong requirement; whileweak adequacyis defined by :
P∼BP Q ⇒ T h(P) =T h(Q)
It has been proved [21] that theπ-logic is adequate with respect to the strong early bisimula-tion equivalence [20] of theπ-calculus. This means that twoπ-calculus agents are early bisimilar, provided that they satisfy the same properties that can be expressed in theπ-logic.
This result is important in the context of our framework, since we aim to check that the same properties are validated for a BP-calculus specification and its BPEL implementation, and, thus, this result might be deduced from the bisimulation. As a result, we only need to prove the bisimilarity between a BP-calculus specification and its BPEL implementation, to prove the correctness of the mapping we present in the next section.
At this stage, we need to assert the adequacy of thepi-logic w.r.t∼BP, since the BP-calculus
differs from thepi-calculus by some operators, e.g the sequential composition and process spawn operators. Because all other operators are common withπ-calculus, we only need to study the effect of these two on the bisimulation.
Theorem 1. Theπ-logic is adequate w.r.t bisimulation (∼BP).
The proof is based on the result of [21] that states the adequacy of theπ-logic w.r.t the strong early bisimulation of theπ-calculus. In fact, we only need to examine the sequential operator and the instance spawn. We also need to analyze the effect of the termination predicate on the adequacy.
IfPandP0are two BP-processes not containing sequential operator nor instance spawn, one can apply the results of [21]. Now, let’s see what happens with these two operators:
– Sequential operator:
LetPandP0such asP ∼BP P0andP |=φ, thereforeP0|=φ(induction hypothesis).
ButP ∼BP P0 ⇒ P .MQ∼BP P0.M Qby structural congruence of first operand of
the sequential operator.
Finally,P∼BP P0andP .MQ|=φ ⇒ P0.MQ|=φ.
The result for the second operand is more problematic.
– Instance spawn:
LetP=cA(˜x).A(˜y)andP |=φandCa correlation set related toP.
IfC=∅, then[null: 0]cA(˜x).A(˜y) cA(M)
→ [˜z←u˜] :A(˜u)]cA(˜x).A(˜y). In this case, the
resulting process isP, that obviously satisfiesφ. IfC 6=∅then[C :P]cA(˜x).A(˜y)
cA(M)
→ [C,[˜z←˜u] :P|A(˜u)]cA(˜x).A(˜y). In this case,
the resulting process isP|P|...|P, that satisfiesφby construction.
Finally, the bisimulation contains a constraint on the termination of involved processes (both bisimilar processes must terminate). Since this is a restrictive constraint, and since the adequacy holds for a larger set of processes, it holds for terminating processes.
3.2 WS-BPEL Semantics for BP-calculus: The two-way mapping
The verification/refinement process is supported by the two-way mapping summarized in Tables 4, 6 and 5. The reader is referred to [5] for details.
The two-way mapping is useful for two reasons: first one needs to verify existing BPEL processes (re-engineering) or to generate new BPEL processes from a verified BP-specification. In the first case, we need to translate the BPEL code to BP-code. Then we verify and possibly correct this code. When done, we generate a new BPEL code from its verified specification. In the second case, the first step is not needed.
While the mapping from WS-BPEL to BP-calculus is similar to the one of Lucchi and Maz-zara, the converse uses the annotations on primitive activities introduced in the syntax of the language. Since compositionality is the main interesting characteristic of PAs, each component is easily recognized, using annotations if necessary. This feature eases the translation by replacing each component by the corresponding WS-BPEL’s construct.
Note that the functionJ.K : PBP−calculus −→ ABP EL maps BP-processes into BPEL
activities and that the mapping is to be read in both directions.
3.3 Correctness of the mapping
The algorithm is straightforward since the transformation is supported by the grammar of the BP-calculus. And that is the main advantage of using PAs. At the opposite, Van Der Aaalst & al [22], when mapping WF-nets to BPEL, need to develop a complex algorithm that recognizes first
Table 4.Two-way mapping between BP-calculus and WS-BPEL
BP-calculus WS-BPEL
Jxs(˜i).PK <receive partner="i1" operation="xs" input
variable="i2, .., in" />JPK
Jxs
invh˜ii.P
K <invoke partner="i1" operation="xs" asynchronous
variable="i2, .., in" />JPK output
J(xs
sinvhr,˜ii <invoke partner="i
1" operation="xs" synchronous . r(˜o)).PK inputvariable="i2, .., in" output outputvariable="o2, .., on" />JPK Jxs reph ˜
oi.PK <reply partner="o1" operation ="xs" reply variable="o2, .., on"/>JPK
JQ1|Q2K <flow> JQ1KJQ2K </flow> parallel
JQ1 .c(M) Q2K <sequence> sequence JQ1K <assign><copy> <from variable="M" /> < to variable="v" /> < /copy></assign> JQ2K </sequence> Jx1(˜i).Q1 + x2(˜j).Q2K<pick> choice <onMessage partnerLink="i1" operation="x1" variable="i2, .., in" > JQ1K </onMessage> <onMessage partnerLink="j1" operation="x2" variable="j2, .., jn" > JQ2K </onMessage> </pick>
Jif cond then Q1 <if name = "ConditionName"> Conditional
else Q2K <condition > getVariableProperty("VarName","x")= getVariableProperty("VarName","y") </condition> JQ1K<else>JQ2K</else> </if>
Table 5.Two-way mapping (scopes and instance spawn) J{x, P, H˜ }K <scope> Scope H=WF H|WEH|WCH|WT H <variables> <variable name="x"/> </variables> <faultHandlers> JWF H(Abf h)K </faultHandlers> <eventHandlers> JWEH(Abeh)K </eventHandlers> <compensationHandler> JWCH(Ach, C)K </compensationHandler> <terminationHandlers> JWT HK </terminationHandlers> JP K </scope> J[C:P]c(˜x).A(˜y)K <correlationSets> Instance
<correlationSet name="C" spawn
properties="cor:x2 cor:x3" initiate = ’yes’ /> </correlationSets> ... <receive partnerLink="x1" operation="c" createInstance="yes"> </receive> JPK
each component of the Petri Net separately, then annotates it and finally maps each component to its equivalent WS-BPEL component. This process is much more complex than the one for PAs! Moreover, the authors do not give a formal proof of the correctness of the algorithm, because they lack of a ’manageable’ semantics for WS-BPEL and they restrict to a simple subset of BPEL.
Since we base our study on the BPEL’s semantics provided in [7], we need only to prove that the converse mapping - from a subset of BP-calculus to WS-BPEL - is correct. Indeed, we need to introduce some restrictions on BP-calculus processes. These restrictions are inherent to the structure of the targeted language, WS-BPEL.
Some of these restrictions are included in the definition of BP-syntax (prefixed sum, for instance).
Other restrictions must be explicitly expressed. We only consider restricted processes as de-fined in Section 2.4 and we add a well-formedness property as follows:
Definition 4. [Well-formedness] A restricted BP-process is well-formed when the two following conditions hold:
- Name mobility: since BPEL can deal with name mobility, and so do well-formed processes. - Output capability of input names: Received names cannot be used as subjects of inputs or of replicated inputs, in order to avoid a situation where different Web Services support the same operation.
The following theorem states the correctness of the mapping described in Tables 4, 6 and 5.
Theorem 2. Let Lbe the π-logic,TBP be the translation from BP to BPEL using the
two-way mapping of Section 3.2,TBP ELthe converse application based on Lucchi’s semantics with
enhancements of Section 3.2 and finally,Pbe a well-formed BP-process. Then,
∀φ∈ L, P |=φ ⇒ TBP(TBP EL(P))|=φ
That is:TBP o TBP ELpreserves the bisimulation∼BP.
The adequacy of theπ-logic for the BP-calculus have been established in Section 3.1 and we also stated that we only need to prove the bisimulation between a BP-process and its implemen-tation to prove their equivalence and then, to establish the correctness of the mapping.
The proof of the bisimulation is obtained by induction on all the constructs of the BP-calculus.
A BP-processPis translated to a BPEL processTBP(P)by means of our mapping.TBP(P)
is then mapped to a BP-calculus processP0 = TBP EL(TBP(P)), using the semantics we
de-duced from Lucchi and Mazzara’s one and that we completed by providing a semantics for miss-ing operators. For the need of the proof we introduce the followmiss-ing abstract syntax of BPEL’s main constructs:
A:=invoke(x,˜i,o˜) (synchronous invoke) | invoke(x,˜i) (asynchronous invoke) | receive(x,˜i) (receive)
| reply(x,o˜) (reply)
| sequence(P, Q, M) (sequence) | f low(P, Q) (parallel)
| Conditional(cond, P, Q) (conditional) | pick((x1,i˜1, P),(x2,i˜2, Q)) (alternative)
| while(Cond, P) (while loop)
| repeatuntil(Cond, P) (repeat until loop)
| f oreach(scope(˜x, P, H), start, end) (f oreach loop) | scope(˜x, P, H) (scope)
| spawn(C, P) (instance spawn)
In the following and in order to enhance the readability of the text we denote byP0 the processTBP EL(TBP(P)).
Basic constructs
– Reception: LetP =x(˜i),TBP(P)is thenreceive(x,˜i), andP0 =x(˜i). The bisimulation
is obvious, since we assume thati1 holds the name of the partner link and the transmitted
information is hold byi2, ... , in. Note that this case does not take into account correlation
mechanisms that are studied separately, later in this proof, when discussing the instance spawn operator.
– Output: Its worth noting that WS-BPEL distinguish between asynchronous invoke and syn-chronous invoke that need to be followed by a reply construct. The BP-calculus takes into account this feature by adding annotations on the output operator.
• Asynchronous invoke:
LetP =xinvh˜oi,TBP(P)is theninvoke(x,o˜), andP0=xinvho˜i
Here, the partnerLink name isi1. Other informations such as partner links, partner role,
or correlation informations are hold byi2, ... , inand are extracted by adequate
func-tions (see [6]).
• Synchronous invoke: To differentiate this construct from the asynchronous invoke, we introduce thesinvannotation.
LetP =xsinv˜ i,˜o
,T r(P)is theninvoke(x,˜i,o˜), andPT r(P)=xsinv
˜ i,˜o
. – Reply: This construct behaves exactly like an asynchronous invoke.
– Parallel composition: Consider the processP =Q1|Q2.TBP(P)is thenf low(Q1, Q2),
andP0=Q1|Q2. Note that in this casePX ⇔ Q1XandQ2Xthat is the desired behavior
of the<flow>construct.
– Sequential composition: Consider the processP =Q1 .c(M) Q2.
The BPELsequenceconstruct (sequence(Q1, Q2, M)) expresses thatQ2is run afterQ1
has finished andQ2may receive a messageMfromQ1that might hold binding information
for the free names ofQ2.
Its semantics is given by(νx)(P.xhMi |x(M).Q). This behavior is identical to the behav-ior of the.M construct of the BP-calculus (see congruence rules of Table 2).
– Selective event processing (Choice): LetP=x1(˜i1)Q1+x2(˜i2)Q2.
TBP(P)ispick((x1,˜i1, Q1),(x2,˜i2, Q2)andP0=x1(˜i1)Q1+x2(˜i2)Q2.
The input guarded choice operator of the BP-calculus has been built to fit the<Pick> con-struct. They have the same semantics. Events are represented by inputs on channelsxi.
– Conditional: The behavior ofif(x = y)then P else Q is identical to the conditional construct of the BP-calculus based on name equality (Conditional(cond, P, Q)).
Instance spawn and scopes Instance spawn and scopes are complex features that need more attention.
– Instance spawning: LetP = [C:P]c(˜x).A(˜y). Then,TBP(P)is a reception with crea-teInstanceattribute set totrue.TBP(P) =receive(x,˜i)with a specific parameter, say i2set to ’yes’. Two cases are to be considered on reception of a value on channelx:
• Cis uninitiated and an instance is to be created that runs in parallel with existing in-stances.
[C:P]c(˜x).A(˜y) c→(˜x) [C,[˜z←u˜] :P|A(˜u)]c(˜x).A(˜y)
By construction, we have:P = [C:P]c(˜x).A(˜y)∼BP ATBP(A)sinceP ∼BP PTBP(P) for any well-formed processPthat does not (yet?) include a spawning operator. Adding a new instance ofAto existing instances preserves the equivalence.
• The correlation set is already initiated and thus no new instance is created, but only the referenced existing instance will react to the invocation. Thus the equivalence holds obviously.
– Scopes and restriction: LetS={x, P, H˜ }. ThenTBP(S) =scope(˜x, P, H)andTBP(TBP EL(S)) =
(νx˜)(P|Q
iWi(Pi1,· · ·, Pini)).
We refer the reader to [5] for the detailed syntax of each handler. However we assume the following:
• the fault handler is a triggered by an input on specific channelsfi,
• the event handler is a triggered by an input on specific channelsei,
• channelsfi(respei) are restricted to the fault (resp event) handler.
We prove thatS ∼BP TBP(TBP EL(S)).S is the parallel composition ofP and each
handler inH. Three cases are considered here:
• no fault nor event occurs (no output is performed on channelsfiandei) thenSbehaves
as its primary activity followed by the termination handler (P . T H). Assuming that neitherPnorP0contains a scope,P ∼BP P0and thenS ∼BP TBP(TBP EL(S))
by induction.
• an error occurs (a receipt is performed on a channelfi) andSbehaves as the associated
activity of the fault handlerF H. In this case and by induction,F H ∼BP TBP(TBP EL(F H))
and thenS ∼BP TBP(TBP EL(S)).
• an event occurs (a receipt is performed on a channelei) andSbehaves as the
corespond-ing activity associated with the event, followed by the termination handlerEH . T H. This case is similar to the previous one.
Completeness Our encoding is complete since all the BP-calculus operators introduced in Section 2.2 have an equivalent into BPEL as presented in Tables 4, 6 and 5.
3.4 Loops
An important feature of WS-BPEL is its ability to execute repetitive activity using loops. For this purpose, WS-BPEL 2.0 introduces 3 kind of loops we study in the following:while,foreach
andrepeatuntilloops.
The mapping between of these constructs is presented in Table 6.
Table 6.Two-way mapping (loops)
Jwhile(cond, P)K <while > while
<condition > bool-expr </condition>
JPK
</while>
Jrepeatuntil(cond, P)K <repeatUntil standard-attributes> repeat
JPK until
<condition >bool-expr</condition> </repeatUntil>
Jf oreach(S, start, end)K<forEach parallel="yes/no" foreach
S={˜x, P, H} countername="n"> <startCounterValue> start </startCounterValue> <finalCounterValue> end </finalCounterValue> <completionCondition>
<branches> integer </branches> </completionCondition>
JSK
</forEach>
The proof of the correctness of this mapping is conducted like in Section 3.3.
– while: LetP = if cond then P else0. Since it is a recursive definition, P is a looping process. Then,
T r(P) =while(cond, P)andPT r(P) = if cond then P else0.
– repeat until: This case is similar to the previous one. IfT r(P) =repeatuntil(cond, A), thenPT r(P)=P . if cond then P else0.
– Processing multiple branches (foreach): The<forEach>activity executes its contained
<scope>activity exactly N+1 times where N equals the difference between two given inte-gers,startandend. The contained activity is a scope and the execution of its N+1 iterations is parallel or sequential depending on theparallelattribute. Thus, it is formalized as follows:
-Parallel foreach: IfT r(P) =f oreachparallel(scope(˜x, P, H), start, end),
thenPT r(P)=Jscope(˜x, P, H)K|...|Jscope(˜x, P, H)K
| {z }
n+1times
, n=end - start.
In another hand, ifP =S|S ...|SN+1 times andSis{x, P, H˜ }, thenT r(P) =f oreachparallel(scope(˜x, P, H), 1, N).
IfPXandSXthenPandPT r(P)have the same behavior given that start=1 and end=N.
-Sequential foreach: IfT r(P) =f oreachsequential(scope(˜x, P, H), start, end),
thenPT r(P)=Jscope(˜x, P, H)K. ... .Jscope(˜x, P, H)K
| {z }
n+1times
, n=end - start. Reasoning on this
construct is similar to the parallel case.
4
Verification framework
The definition of the BP-calculus presented in Section 2.2 indicates the possible use of functions and equations exactly as it is done in the appliedπ-calculus [23]. However, since the choice was made to use first the HAL Toolkit associated with theπ-logic, this feature of the BP language is not used here. That means that the specification and the verification stay at a lower level than it could be. In the following, we briefly present some of the main features of the HAL Toolkit.
4.1 The HAL environment
This tool integrates three kinds of formal verification techniques, including open bisimulation, properties checking and the compatibility checking of composite web services based onπ -calcu-lus. With the combination checking techniques, the properties that service composition orches-tration holds at abstract control flow level are checked, which achieve more completely validity checking about the orchestration.
The HAL Toolkit is based on a translation into an ordinary automaton, thn, can be used to determine the equivalence ofπ-calculus agents or to verify logical formulae expressed in terms ofπ-logic.
4.2 The verification/refinement process
The HAL formulae checker is used to verify and refine a specification written in BP-calculus. WS-BPEL programs are automatically translated into BP-calculus processes or directly specified in the BP-calculus language. We also specify the desired properties by means of theπ-logic. We then check if the formulas hold for the defined processes. If they are invalidated by the tool, we iteratively correct the processes and/or the formulas and we repeat the verification process until the system is validated. At this time, a version of the WS-BPEL process is automatically generated.
The correctness of the generated BPEL code is asserted by the Theorem 2.
We can also need to minimize any of the initial or the final formal specification and then we can use the HAL bisimulation checker to verify correctness of this minimization. Note also that we might use the bisimulation checker to verify the bisimulation between the initial and the final specifications.
Before verifying a BP-process, we first need to translate the specification from BP-calculus notation to HAL’s one. The translation is obvious and details are omitted here.
Annotations on inputs and output are not translated to HAL syntax since they have no ef-fect on their semantic and thus do not interfere in the verification process. Note also that we do not directly express handlers constructs since their semantics is expressed in terms of basic constructs.
5
Modelling and Verifying the Trading Service
The example presented here is intended to illustrate our approach. This meaningful example is adapted from [24].
5.1 The trading market service
As typical use scenario for a composite Web service, consider the following example: A customer places an order to sell a quantity of shares by contacting a Broker service. The broker invokes other composite services to check the feasability of the transaction and to perform it. This scenario is well-suited to our study because it involves several composite services.
The case study scenario is informally described as follows:
The Customer contacts the Broker composite service intending to sell the shares. The Bro-ker invokes the Analytic service with the request parameters. The trend information is calculated and a trading plan is generated and returned by the Analytic service to the Customer for con-firmation. The Customer checks the plan and approves it or rejects it. In case of approval, the Broker service submits order according to the plan to the Exchange service. Each order that is placed on the Exchange service successfully generates a receipt which is returned to the Cus-tomer. The Surveillance service monitors each order and the generated trades to detect possible illegal actions.
5.2 Formal description without handlers
In this section, we model the scenario described in Section 5.1 using the BP-calculus. Note that we do not use the correlation mechanism in this example and thus the processes do not contain the spawn construct introduced in the extended version of the calculus. However the example is relevant since it includes handlers.
Letu˜= (a, b, decision, o, p, q, r, s, t), then the whole BP-process is:
CapitalM arket(qty, plan, receipt, ok) := (νu˜)(Customer(s, p, qty, a, ok, nok, r) | Broker(s, p, plan, q, qty, a, r, receipt) | Analytic(q, p, plan)
| Exchange(o, t, b, ok, r, receipt) | Surveillance(b, t, decision))
where each process is defined as:
Customer(s, p, qty, a, ok, nok, r) :=sinvhqtyi.p(plan).(ainvhoki.r(receipt) +ainvhnoki)
. Customer(s, p, qty, a, ok, r)
The Customer service invokes the Broker service by sending a sell order and waits for a plan. He then sends an approval, or a rejection of the plan and waits for receipts from the Exchange service.
Broker(s, p, plan, q, qty, a, r, receipt) :=s(qty).qinvhqtyi.a(decision)
. if(decision=ok)oinvhorderielse0
. Broker(s, p, plan, q, qty, a, r, receipt)
The broker service waits for sell orders from the Customer and then transmits them to the Analytic service. Once the plan is approved by the Customer, the broker invokes the Exchange service by sending orders to be controlled and sold.
Analytic(q, p, plan) := q(qty).pinvhplani. Analytic(q, p, plan)
The Analytic service receives a request from the Broker, analyzes it, and sends a plan to the Customer.
Exchange(o, t, b, ok, r, receipt) :=o(order, plan).tinvhorderi.b(decision) (if(decision=ok)rinvhreceiptielse0) . Exchange(o, t, b, ok, r, receipt)
The Exchange services receives orders from the Broker. It invokes the Surveillance service and waits for a reply. Finally it sends the receipts to the Customer.
Surveillance(b, t, decision) := t(order).brephdecisioni. Surveillance(b, t, decision) The Surveillance service waits for orders, checks them and sends a reply to the Exchange service.
In order to complete this specification, one needs to add mechanisms to handle events, such as timeouts, and faults. For this purpose we introduce event and fault handler to the specification.
5.3 Introducing a scope
In this section, we pay a peculiar attention to the Broker service and we introduce a scope within it. This scope is a wrapper for local variables and event and fault handlers.
The event handler manages the occurrence of timeout event. Each service has a finite period of time for providing a response to a request. If this time is elapsed, the calling service triggers a timeout event caught by the event handler.
The fault handler manages faults occurring while invoking the Broker service. We consider the three following faults for this service : the Broker is busy (fbb), the Analytic service is down
or busy (fasd), the Exchange service is down or busy (fesd),
This scenario is illustrated by the diagram in Figure 2. We now formalize the Broker service and its handlers.
Letu˜= (eneh, enf h, diseh, disf h, t, timeout, p, receipt, fbb, fesd, fasd, yeh, yf h)
andw˜= (a, ok, s, qty, order, q, o, plan, eneh, enf h, diseh, disf h, r, x, bb, esd, asd)
The Broker is defined by:Broker:={u, B, H˜ }where B is its main activity and H the set of handlers (event and fault handlers, here):
Fig. 2.Broker’s Scope Interaction Diagram.
B( ˜w) := s(qty).qinvhqtyi.a(decision).if(decision=ok)oinvhorderi +timeoutinvhi+Error()
where Error() :=fbb throw hi + fesd throw hi + fasd throw hi
When receiving a plan approval, the Broker may send the order to the Exchange service, or trigger a timeout event; In the latter case, the event handler runs the timeout event handling action (AT imeout). Finally, it may trigger a fault; in this case the fault handler is invoked that runs the
corresponding action (Fbb,FasdorFesd).
H={EH(eeh, yeh, deh, timeout, t), F H(fbb, fesd, fasd, ef h, yf h, bb, esd, asd, r)}
TheEvent handleris as follows:
EH(eeh, yeh, deh, timeout, t) := (νet) eneh().
timeout().etinvhi + diseh().yehinv
|et().AT imeout
whereAT imeout:=pinvhtimeouti
Theevent handleris enabled using the eneh channel and waits for a unique event (the
timeout) on channelet. Then, it processes an activity (AT imeout) associated with this event. It is
TheFault handleris expressed by :
F H(fbb, fesd, fasd, ef h, yf h, bb, esd, asd, r) :=enf h(). fbb(p,u˜). throw inv hi |Fbb(p) +fesd(p,u˜). throw inv hi |Fesd(p) +fasd(p,u˜). throw inv hi |Fasd(p) . rinvhi |yinvf hhi +disf h() !
where each process associated with a fault defined as:
Fbb(p, brokerbusy) :=phbrokerbusyi (to handle ”broker service busy” fault) Fesd(p, esd) :=phesdi (to handle ”exchange service down” fault) Fasd(p, asd) :=phasdi (to handle ”analytic service down” fault)
Thefault handlerdeals with three kinds of faults :Sf ={fbb, fesd, fasd}together with
their associated activities :F ={Fbb, Fesd, Fasd}. It is enabled using theef hchannel and then
the activity associated with the triggered fault is processed. Finally it signals its termination to the calling scope and the activating throw using theyf hand the channelr. It is finally disabled
using the channeldisf h. The same model is applicable to other composite services which may
also contain scopes.
It is worth noting that introducing a scope in the model has involved of a big amount of com-plexity. The generation of the History Dependent automaton using the HAL Toolkit for the model without scope has been made within one half second and has resulted in a six-state automaton. While the Broker’s model with scopes, which is only a part of the whole model, has generated an automaton with more than a 1000 states in more than 600 seconds. This illustrates the fact that the WS-BPEL language is very powerful but its formal verification is not an easy task applied to weighty cases.
Once the system is formally specified, on needs to proceed to the formal verification of de-sired properties.
5.4 Requirements specification
In this section, we present the formal specification and verification of some interesting properties in the context of services and service-oriented computing applications.
Responsiveness A service isresponsiveif it guarantees a response to every received request in finite time. The property stating that whenever the customer sends a sell order, he will obtain a plan after a finite time, and whenever a customer agrees a selling plan, and the order is approved by the surveillance service, he will receive a receipt, is a responsiveness property. This property can be formalized by the followingπ-formula:φ1&φ2 where:
φ1 =AG([s?qty]EF(< p![plan]> true))
φ2 =AG(([a?(ok)][b?(ok)])EF([r!receipt]true))
Availability A service is said available when it is available at any time. The property stating that in every state the broker service may accept a request is an availability property. This can be expressed as aπ-formula as follows:
AG([s?qty]true)
This property has also been validated on the model with the HAL toolkit.
Reliability Reliability is the capability to deliver response continuously in time (service reliabil-ity) and the capability to correctly deliver messages between two endpoints (message reliabilreliabil-ity). The property stating that the reception of a plan delivery is guaranteed whenever a sell order has been sent is a reliability property. This can be expressed as aπ-formula as follows :
AG([s?qty]EF < p!plan > true)
This property has also been validated on the model with the HAL toolkit.
Fairness Fairness stipulates that if a process is continuously enable to communicate on a chan-nel, then it must eventually proceed. The property stating that if a customer sends an infinite number of sell orders, then he will receive an infinite number of plans and receipts, is a fairness property. This can be expressed as aπ-formula as follows:
φ1 ∨ AG(ψ1 & ψ2) where φ1=¬AG(EF < s?∗> true)
ψ2=EF < r!receipt > true
ψ2=EF < p!plan > true
This property has also been validated on the model with the HAL toolkit.
Safety This properties assert that some bad event never happens in the course of a computation. For instance, the property that states that a receipt should never be sent before it has been approved by the surveillance service is a safety property. This can be expressed as aπ-formula as follows:
∼EF(∼< b!ok > true & < r?∗> true)
This property has been invalidated and that is acceptable since a receipt is sent only if the decision is ok.
Liveness Liveness properties assert that some event does eventually happen. An example of a liveness property relevant to the capital market use case is the following: the system will even-tually execute the actiont!order(order’s checking) whenever it has executed the actiona!ok
(plan’s approval). This can be expressed as aπ-formula as follows:
AG(< a!ok > EF < t!order > true) This property has been validated on the model with the HAL toolkit.
Fault tolerance properties Faults are modeled directly by actions of the processes them-selves. More precisely, a fault is thrown on channelthrowand caught by thefault handler. Occurrence of faults are included in the specification by defining ad hoc fault assumption pro-cesses. This allows the behavior of the fault tolerant system to be studied under different fault scenarios. Below, some examples of such properties relevant to the behavior of the capital market system:
1. The Broker, after emitting a fault signal on channelfi, i∈ {bb, ed, asd}, will invoke the
fault handler and will be warned on channelrthat the handler has finished:
AG([fbb!∗]f alse & [fesd!∗]f alse & [fasd!∗]f alse ∨ E[r!∗]true)
2. After being activated through channelef h the Fault Handler will eventually be disabled
through channeldisf h:
AG([enh?∗]f alse|EF[deh?∗]true)
Reachability
An interesting property of an interaction in an orchestration is whether it is reachable (i.e. it may execute successfully) or if it is unreachable (i.e. it never executes successfully). This criterion can be checked using a bisimulation verification.
The reachability analysis can be performed by comparison to the pi-process0. If the orches-tration is weak open bi-simulation related to0the activity in question is not-reachable otherwise the interaction must be reachable.
Example of non-reachable activity:
if5<7thenA1elseA2
During the execution of the process, either A1 or A2 will be skipped for these two activities in a switch. But it obvious thatA2is unreachable).
5.5 Discussion
In this model all the desired properties have been validated (except one safety property that is accepted anyway). In the case where some properties are invalidated, one must modify the spec-ification in such a way that all the properties are accepted. The verspec-ification process is re-iterated until all the desired properties are validated. At this time, we can proceed to the automatic gener-ation of the WS-BPEL code.
5.6 Automatic Generation of WS-BPEL Code
Since the system has been proven to satisfy some desirable property, we can proceed to the auto-matic translation to WS-BPEL. As an illustration of the use of the WS-BPEL-based semantics in the code generation process, we present the sketch of the generated code for the Broker service. By sake of completeness, the reader is referred to [1] for the details of the WS-BPEL constructs.
From the definition:Broker:={u, B, H˜ }one get the following structure of the scope: <process name="Broker"><scope>
<faultHandlers/> <eventHandlers/>
</scope></process>
The generated code for the fault handler is as follows:
<faultHandlers>
<catch faultName="BrokerBusy" faultVariable="Fault"> <sequence> <assign> <copy> <from exp="string(’BrokerBusy’)"/> <to variable="Fault" part="error"/> </copy></assign> <invoke partnerLink="Market" operation="SellingFault" inputVariable="Fault"/> </sequence> </catch> <catch faultName="ExchangeServiceDown"> .... <catch faultName="AnalyticServiceDown"> ... <faultHandlers>
The code of the event handler is:
<eventHandlers><onAlarm for="Timeout"
<throw faultName="Timeout" faultVariable="Fault" /> </onAlarm></eventHandlers>
Finally, a sketch of the generated code for the scope’s primary activity is:
<sequence>
<receive partner="Customer" operation ="s" variable = "qty" />
<invoke partner="AS" operation ="q" InputVariable = "qty" />
<if><condition decision = "ok" />
<invoke partner="ES" operation ="o" InputVariable = "order" /> </if>
</sequence>
6
Conclusion
In this paper we have presented a two-way mapping between aπ-like calculus, the BP-calculus, and we have sketched a formal proof of its correctness. The BP-calculus is designed for formal specification of Web Service orchestrations and allows verification and automatic generation of readable, easy to support and correct WS-BPEL code including compensation, fault and event handlers. As an illustration of the applicability of the the calculus, we presented a meaningful case study (the Capital Market process): we first specified the case study, including complex constructs such as handlers, then we used theπ-logic to assert an verify some desirable properties of the system. Using an iterative process, we verified the correctness of the system and then proceeded to its automatic translation to WS-BPEL.
While some previous works have been done on integrating model-checker toolkits and gener-ating WS-BPEL code that has the same behavior as the model ([22, 25]), our proposal is, as far as we know, the first to take into account as many significant structured activities, including scopes and handlers and to offer integration to a verification/refinement framework for the design.
We are developing a tool integrating the BP-calculus to the the HAL toolkit. Our tool will also be used to generate the correct WS-BPEL code of the business process from the formally verified specification. Our tool will also be used to generate the correct WS-BPEL code of the business process from the formally verified specification.
References
1. Oasis: Web service business process execution language version 2.0 specification, oasis standard.http://docs.oasis−open.org/wsbpel/2.0/wsbpel−v2.0.pdf(april 2007) 2. ter Beek, M., Bucchiarone, A., Gnesi, S.: Formal methods for service composition. In: In
Proceedings of the 3rd South-East European Workshop on Formal Methods (SEEFM’07). (2007) 365 – 78
3. Milner, R.: Communicating and Mobile Systems: The Pi-Calculus. Cambridge University Press, Cambridge, UK (1999)
4. Ferrari, G., Gnesi, S., Montanari, U., Pistore, M.: A model-checking verification environ-ment for mobile processes. ACM Trans. Softw. Eng. Methodol.12(4) (2003) 440–473 5. Abouzaid, F., Mullins, J.: A calculus for generation, verification and refinement of bpel
specifications. Electronic Notes in Theoretical Computer Science200(3) (2008) 43–65 6. Abouzaid, F., Mullins, J.: Formal specification of correlation sets in ws orchestrations
us-ing bp-calculus. In: proceedus-ings of the 5th International Workshop on Formal Aspects of Component Software (FACS’2008), Malaga, Spain (2008)
7. Lucchi, R., Mazzara, M.: A pi-calculus based semantics for ws-bpel. Journal of Logic and Algebraic Programming (2007)
8. Fantechi, A., Gnesi, S., Lapadula, A., Mazzanti, F., Pugliese, R., Tiezzi, F.: A model check-ing approach for verifycheck-ing cows specifications. In: Proc. of Fundamental Approaches to Software Engineering (FASE’08). Volume 4961 of Lecture Notes in Computer Science., Springer (2008) 230–245
9. Verbeek, H., van der Aalst, W.: Analyzing bpel processes using petri nets. In Marinescu, D., ed.: Proceedings of the Second International Workshop on Applications of Petri Nets to Coordination, Workflow and Business Process Management, Miami, Florida, USA, Florida International University (2005) 59–78.
10. Hinz, S., Schmidt, K., Stahl, C.: Transforming BPEL to Petri Nets. In van der Aalst, W., Be-natallah, B., Casati, F., Curbera, F., eds.: Proceedings of the Third International Conference on Business Process Management (BPM 2005). Volume 3649 of Lecture Notes in Computer Science., Nancy, France, Springer-Verlag (Sep 2005) 220–235
11. Fahland, D., Reisig, W.: ASM-based semantics for BPEL: The negative Control Flow. In Beauquier, D., Biger, E., Slissenko, A., eds.: Proceedings of the 12th International Workshop on Abstract State Machines (ASM’05), Paris XII (March 2005) 131–151
12. Fu, X., Bultan, T., Su, J.: Analysis of interacting bpel web services. In: Proceedings of the WWW2004, New-York, NY, USA (May 2004)
13. Guidi, C., Lucchi, R., Gorrieri, R., Busi, N., Zavattaro, G.: Sock : A calculus for service oriented computing. In Heidelberg, S.B.., ed.: Service-Oriented Computing ICSOC 2006. Volume 4294/2006 of Lecture Notes in Computer Science. (2006) 327–338
14. Lapadula, A., Pugliese, R., Tiezzi, F.: A Calculus for Orchestration of Web Services. In: Proc. of 16th European Symposium on Programming (ESOP’07). Volume 4421 of Lecture Notes in Computer Science., Springer (2007) 33–47
15. Lanese, I., Vasconcelos, V., Martins, F., Ravara, A.: Disciplining orchestration and conver-sation in service-oriented computing. In: 5th IEEE International Conference on Software Engineering and Formal Methods, IEEE (2007) 305–314
16. Chirichiello, A., G. Sala¨un, G.: Encoding process algebraic descriptions of web services into bpel. Web Intelli. and Agent Sys.5(4) (2007) 419–434
17. Bolognesi, T., Brinksma, E.: Introduction to the iso specification language lotos. Comput. Netw. ISDN Syst.14(1) (1987) 25–59
18. Gehrke, T., Rensink, A.: Process creation and full sequential composition in a name-passing calculus. In: EXPRESS’97. Volume 7 of Electronic Notes in Theoretical Computer Science. (1997) 141–160
19. Viroli, M.: A core calculus for correlation in orchestration languages. Journal of Logic and Algebraic Programming70(1) (January 2007) 74–95
20. Milner, R., Parrow, J., Walker, D.: Modal logics for mobile processes. Theoretical Computer Science (1993)
21. Gnesi, S., Ristori, G.: A model checking algorithm for pi-calculus agents. In: Applied Logic Series. Volume 16. Kluwer (2000) 339–358
22. van der Aalst, W.M.P., Lassen, K.B.: Translating unstructured workflow processes to read-able bpel: Theory and implementation. the International Journal of Information and Software Technology (INFSOF) (December 2006)
23. Abadi, M., Fournet, C.: Mobile values, new names, and secure communication. In: 28th Symposium on Principles of Programming Languages, ACM Press (2001) 104115
24. Rabhi, F.A., Dabous, F.T., Yu, H., Benatallah, B., Lee, Y.K.: A case study in developing web services for capital markets. In: Proc. of the 2004 IEEE International Conference on e-Technology, e-Commerce and e-Service (EEE 04). (2004)
25. Ferrara, A.: Web services: a process algebra approach,. In: Proceedings of the 2nd interna-tional conference on Service oriented computing, New York, NY, USA (2004) 242–251
