A Calculus for Orchestration of Web Services ?

April 4, 2007

Alessandro Lapadula, Rosario Pugliese and Francesco Tiezzi

Dipartimento di Sistemi e Informatica Universita degli Studi di Firenze

{lapadula,pugliese,tiezzi}@dsi.unifi.it

Abstract. We introduce COWS (Calculus for Orchestration of Web Services),a new foundational language for SOC whose design has been influenced byWS-BPEL, the de facto standard language for orchestration of web services.COWS combines in an original way a number of ingredients borrowed from well-known process calculi, e.g. asynchronous communication, polyadic synchroniza-tion, pattern matching, protection, delimited receiving and killing activities, whileresulting different from any of them. Several examples illustrates COWS pecu-liarities and show its expressiveness both for modelling imperative and orchestra-tion constructs, e.g. web services, flow graphs, fault and compensation handlers,and for encoding other process and orchestration languages. We also present anextension of the basic language with timed constructs.

Table of Contents

1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 COWS: Calculus for Orchestration of Web Services . . . . . . . . . . . . . . . . . . . . . 3

2.1 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2 Operational semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3 Modelling imperative and orchestration constructs . . . . . . . . . . . . . . . . . . . . . . . 113.1 Imperative constructs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.2 Fault and compensation handlers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.3 Flow graphs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174.1 Rock/Paper/Scissors Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174.2 Shipping Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

5 Encoding other formal languages for orchestration . . . . . . . . . . . . . . . . . . . . . . . 215.1 Encoding Orc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215.2 Encoding - . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

6 Timed extension of COWS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287 Concluding remarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

? This work has been supported by the EU project SENSORIA, IST-2 005-016004.

1 Introduction

Service-oriented computing (SOC) is an emerging paradigm for developing looselycoupled, interoperable, evolvable systems which exploits the pervasiveness of the In-ternet and its related technologies. SOC systems deliver application functionality asservices to either end-user applications or other services. These very features fostera programming style based on service composition and reusability: new customizedservice-based applications can be developed on demand by appropriately assemblingother existing, possibly heterogeneous, services.

Service definitions are used as templates for creating service instances that deliverapplication functionality to either end-user applications or other instances. The looselycoupled nature of SOC implies that the connection between communicating instancescannot be assumed to persist for the duration of a whole business activity. Therefore,there is no intrinsic mechanism for associating messages exchanged under a commoncontext or as part of a common activity. Even the execution of a simple request-responsemessage exchange pattern provides no built-in means of automatically associating theresponse message with the original request. It is up to each single message to providea form of context thus enabling services to associate the message with others. Thisis achieved by embedding values in the message which, once located, can be used tocorrelate the message with others logically forming a same stateful interaction ‘session’.

Early examples of technologies that are at least partly service-oriented are CORBA,DCOM, J2EE and IBM WebSphere. A more recent successful instantiation of the SOCparadigm are web services. These are autonomous, stateless, platform-independent andcomposable computational entities that can be published, located and invoked throughthe Web via XML messages. To support the web service approach, many new lan-guages, most of which based on XML, have been designed, like e.g. business coor-dination languages (such as WS-BPEL, WSFL, WSCI, WS-CDL and XLANG), con-tract languages (such as WSDL and SWS), and query languages (such as XPath andXQuery). However, current software engineering technologies for development andcomposition of web services remain at the descriptive level and do not integrate suchtechniques as, e.g., those developed for component-based software development. For-mal reasoning mechanisms and analytical tools are still lacking for checking that theweb services resulting from a composition meet desirable correctness properties anddo not manifest unexpected behaviors. The task of developing such verification meth-ods is hindered also by the very nature of the languages used to program the services,which usually provide many redundant constructs and support quite liberal program-ming styles.

In the last few years, many researchers have exploited the studies on process calculias a starting point to define a clean semantic model and lay rigorous methodologi-cal foundations for service-based applications and their composition. Process calculi,being defined algebraically, are inherently compositional and, therefore, convey in adistilled form the paradigm at the heart of SOC. This trend is witnessed by the manyprocess calculi-like formalisms for orchestration and choreography, the two more com-mon forms of web services composition. Most of these formalisms, however, do notsuit for the analysis of currently available SOC technologies in their completeness be-cause they only consider a few specific features separately, possibly by embedding ad

2

hoc constructs within some well-studied process calculus (see, e.g., the variants of π-calculus with transactions [2, 20, 21] and of CSP with compensation [9]).

Here, we follow a different approach and exploit WS-BPEL [1], the de facto stan-dard language for orchestration of web services, to drive the design of a new processcalculus that we call COWS (Calculus for Orchestration of Web Services). Similarly toWS-BPEL, COWS supports shared states among service instances, allows a same pro-cess to play more than one partner role and permits programming stateful sessions bycorrelating different service interactions. However, COWS intends to be a foundationalmodel not specifically tight to web services’ current technology. Thus, some WS-BPELconstructs, such as e.g. fault and compensation handlers and flow graphs, do not havea precise counterpart in COWS, rather they are expressed in terms of more primitiveoperators (see Section 3). Of course, COWS has taken advantage of previous work onprocess calculi. Its design combines in an original way a number of constructs and fea-tures borrowed from well-known process calculi, e.g. asynchronous communication,polyadic synchronization, pattern matching, protection, delimited receiving and killingactivities, while however resulting different from any of them.

The rest of the paper is organized as follows. Syntax and operational semanticsof COWS are defined in Section 2 where we also show many illustrative examples.Section 3 presents the encodings of several imperative and orchestration constructs,while Section 4 illustrates two example applications of our framework to web services.Section 5 presents the encodings of two other orchestration languages, i.e. Orc [29] and- [22]. Section 6 introduces an extension of COWS with timed orchestrationconstructs. This turns out to be a very powerful language that also permits to express,e.g., choices among alternative activities constrained by the expiration of some giventimeout. Section 7 concludes the paper by touching upon comparisons with related workand directions for future work.

2 COWS: Calculus for Orchestration of Web Services

Before formally defining our language, we provide some insights on its main features.The basic elements of COWS are partners and operations. Alike channels in [11], acommunication endpoint is not atomic but results from the composition of a partnername p and of an operation name o, which can also be interpreted as a specific imple-mentation of o provided by p. This results in a very flexible naming mechanism thatallows a same service to be identified by means of different logic names (i.e. to playmore than one partner role as in WS-BPEL). For example, the following service

pslow • o?w.sslow + pfast • o?w.sfast

accepts requests for the same operation o through different partners with distinct accessmodalities: process sslow implements a slower service provided when the request is pro-cessed through the partner pslow, while sfast implements a faster service provided whenthe request arrives through pfast. Additionally, it allows the names composing an end-point to be dealt with separately, as in a request-response interaction, where usually theservice provider knows the name of the response operation, but not the partner name ofthe service it has to reply to. For example, the ping service p • oreq?〈x〉.x • ores!〈“I live”〉

3

will know at run-time the partner name for the reply activity. This mechanisms is alsosufficiently expressive to support implementation of explicit locations: a located servicecan be represented by using a same partner for all its receiving endpoints. Partner andoperation names can be exchanged in communication, thus enabling many different in-teraction patterns among service instances. However, as in [26], dynamically receivednames cannot form the communication endpoints used to receive further invocations.

COWS computational entities are called services. Typically, a service creates onespecific instance to serve each received request. An instance is composed of concurrentthreads that may offer a choice among alternative receive activities. Services could beable to receive multiple messages in a statically unpredictable order and in such a waythat the first incoming message triggers creation of a service instance which subsequentmessages are routed to. Pattern-matching is the mechanism for correlating messageslogically forming a same interaction ‘session’ by means of their same contents. It per-mits locating those data that are important to identify service instances for the routing ofmessages and is flexible enough for allowing a single message to participate in multipleinteraction sessions, each identified by separate correlation values.

To model and update the shared state of concurrent threads within each serviceinstance, receive activities in COWS bind neither names nor variables. This is differentfrom most process calculi and somewhat similar to [30, 31]. In COWS, however, inter-service communication give rise to substitutions of variables with values (alike [30]),rather than to fusions of names (as in [31]). The range of application of the substitutiongenerated by a communication is regulated by the delimitation operator, that is the onlybinder of the calculus. Additionally, this operator permits to generate fresh names (asthe restriction operator of the π-calculus [28]) and to delimit the field of action of thekill activity, that can be used to force termination of whole service instances. Sensitivecode can however be protected from the effect of a forced termination by using theprotection operator (inspired by [8]).

2.1 Syntax

The syntax of COWS, given in Table 1, is parameterized by three countable and pair-wise disjoint sets: the set of (killer) labels (ranged over by k, k′, . . .), the set of values(ranged over by v, v′, . . . ) and the set of ‘write once’ variables (ranged over by x, y,. . . ). The set of values is left unspecified; however, we assume that it includes the set ofnames, ranged over by n, m, . . . , mainly used to represent partners and operations. Thelanguage is also parameterized by a set of expressions, ranged over by e, whose exactsyntax is deliberately omitted; we just assume that expressions contain, at least, valuesand variables. Notably, killer labels are not (communicable) values. Notationally, weprefer letters p, p′, . . . when we want to stress the use of a name as a partner, o, o′, . . .when we want to stress the use of a name as an operation. We will use w to range overvalues and variables, u to range over names and variables, and d to range over killerlabels, names and variables.

Services are structured activities built from basic activities, i.e. the empty activity 0,the kill activity kill( ) , the invoke activity • ! and the receive activity • ? , by meansof prefixing . , choice + , parallel composition | , protection {| |} , delimitation[ ] and replication ∗ . Notably, as in the Lπ [26], communication endpoints of receive

4

s ::= (services)kill(k) (kill)

| u • u′!e (invoke)| g (input-guarded choice)| s | s (parallel composition)| {|s|} (protection)| [d] s (delimitation)| ∗ s (replication)

g ::= (input-guarded choice)0 (nil)

| p • o?w.s (request processing)| g + g (choice)

Table 1. COWS syntax

activities are identified statically because their syntax only allows using names andnot variables. The decreasing order of precedence among the operators is as follows:monadic operators, choice and parallel composition.

Notation · stands for tuples of objects, e.g. x is a compact notation for denoting thetuple of variables 〈x1, . . . , xn〉 (with n ≥ 0). We assume that variables in the same tupleare pairwise distinct. All notations shall extend to tuples component-wise. In the sequel,we shall omit trailing occurrences of 0, writing e.g. p • o?w instead of p • o?w.0, and use[d1, . . . , dn] s in place of [d1] . . . [dn] s.

The only binding construct is delimitation: [d] s binds d in the scope s. The occur-rence of a name/variable/label is free if it is not under the scope of a binder. We denoteby fd(t) the set of names, variables and killer labels that occur free in a term t, and byfk(t) the set of free killer labels in t. Two terms are alpha-equivalent if one can be ob-tained from the other by consistently renaming bound names/variables/labels. As usual,we identify terms up to alpha-equivalence.

2.2 Operational semantics

The operational semantics of COWS is defined only for closed services, i.e. serviceswithout free variables/labels (similarly to many real compilers, we consider terms withfree variables/labels as programming errors), but of course the rules also involve non-closed services (see e.g. the premises of rules (del∗)). Formally, the semantics is givenin terms of a structural congruence and of a labelled transition relation.

The structural congruence ≡ identifies syntactically different services that intuitivelyrepresent the same service. It is defined as the least congruence relation induced by agiven set of equational laws. We explicitly show in Table 2 the laws for replication,protection and delimitation, while omit the (standard) laws for the other operators stat-ing that parallel composition is commutative, associative and has 0 as identity element,and that guarded choice enjoys the same properties and, additionally, is idempotent.All the presented laws are straightforward. In particular, commutativity of consecutivedelimitations implies that the order among the di in [〈d1, . . . , dn〉] s is irrelevant, thus in

5

∗ 0 ≡ 0 (repl1)∗ s ≡ s | ∗ s (repl2){|0|} ≡ 0 (prot1)

{| {|s|} |} ≡ {|s|} (prot2){|[d] s|} ≡ [d] {|s|} (prot3)

[d] 0 ≡ 0 (delim1)[d1] [d2] s ≡ [d2] [d1] s (delim2)s1 | [d] s2 ≡ [d] (s1 | s2) if d < fd(s1)∪fk(s2) (delim3)

Table 2. COWS structural congruence (excerpt of laws)

M(x, v) = {x 7→ v} M(v, v) = ∅M(w1, v1) = σ1 M(w2, v2) = σ2

M((w1, w2), (v1, v2)) = σ1 ] σ2

Table 3. Matching rules

the sequel we may use the simpler notation [d1, . . . , dn] s. Notably, law (delim3) can beused to extend the scope of names (like a similar law in the π-calculus), thus enablingcommunication of restricted names, except when the argument d of the delimitation isa free killer label of s2 (this avoids involving s1 in the effect of a kill activity inside s2).

To define the labelled transition relation, we need a few auxiliary functions. First,we exploit a function [[ ]] for evaluating closed expressions (i.e. expressions withoutvariables): it takes a closed expression and returns a value. However, [[ ]] cannot beexplicitly defined because the exact syntax of expressions is deliberately not specified.

Then, through the rules in Table 3, we define the partial functionM( , ) that per-mits performing pattern-matching on semi-structured data thus determining if a receiveand an invoke over the same endpoint can synchronize. The rules state that two tuplesmatch if they have the same number of fields and corresponding fields have matchingvalues/variables. Variables match any value, and two values match only if they are iden-tical. When tuples w and v do match,M(w, v) returns a substitution for the variables inw; otherwise, it is undefined. Substitutions (ranged over by σ) are functions mappingvariables to values and are written as collections of pairs of the form x 7→ v. Applicationof substitution σ to s, written s · σ, has the effect of replacing every free occurrence ofx in s with v, for each x 7→ v ∈ σ, by possibly using alpha conversion for avoiding v tobe captured by name delimitations within s. We use |σ | to denote the number of pairsin σ and σ1 ] σ2 to denote the union of σ1 and σ2 when they have disjoint domains.

We also define a function, named halt( ), that takes a service s as an argument andreturns the service obtained by only retaining the protected activities inside s. halt( ) isdefined inductively on the syntax of services. The most significant case is halt({|s|}) =

{|s|}. In the other cases, halt( ) returns 0, except for parallel composition, delimitation

6

and replication operators, for which it acts as an homomorphism.

halt(kill(k)) = halt(u1 • u2!e) = halt(g) = 0

halt({|s|}) = {|s|} halt(s1 | s2) = halt(s1) | halt(s2)

halt([d] s) = [d] halt(s) halt(∗ s) = ∗ halt(s)

Finally, we define a predicate, noc( , , , ), that takes a service s, an endpoint p • o,a tuple of receive parameters w and a matching tuple of values v as arguments and holdstrue if either there are no conflicting receives within s (namely, s cannot immediatelyperform a receive activity matching v over the endpoint p • o), or p • o?w is the mostdefined conflicting receive. The predicate exploits the notion of active context, namelya service A with a ‘hole’ [[·]] such that, once the hole is filled with a service s, if theresulting term A[[s]] is a COWS service then it is capable of immediately performing anactivity of s. Formally, active contexts are generated by the grammar:

A ::= [[·]] | A + g | g + A | A | s | s | A | {|A|} | [d]A | ∗ ANow, predicate noc(s, p • o, w, v) can be defined as follows:

( s = A[[p • o?w′.s′]] ∧ M(w′, v) = σ ) ⇒ |M(w, v) |6 |σ |where s = A[[p • o?w′.s′]] means that s can be written as p • o?w′.s′ filling the hole ofsome active context A.

The labelled transition relationα−−→ is the least relation over services induced by the

rules in Table 4, where label α is generated by the following grammar:

α ::= †k | (p •o) C v | (p •o) B w | p •o bσc w v | †In the sequel, we use d(α) to denote the set of names, variables and killer labels occur-ring in α, except for α = p •o bσc w v for which we let d(p •o bσc w v) = d(σ), whered({x 7→ v}) = {x, v} and d(σ1]σ2) = d(σ1)∪d(σ2). The meaning of labels is as follows:†k denotes execution of a request for terminating a term from within the delimitation[k] , (p •o) C v and (p •o) B w denote execution of invoke and receive activities over theendpoint p • o, respectively, p •o bσc w v (if σ , ∅) denotes execution of a communica-tion over p • o with receive parameters w and matching values v and with substitutionσ to be still applied, † and p •o b∅c w v denote computational steps corresponding totaking place of forced termination and communication (without pending substitutions),respectively. Hence, a computation from a closed service s0 is a sequence of connectedtransitions of the form

s0α1−−→ s1

α2−−→ s2α3−−→ s3 . . .

where, for each i, αi is either † or p •o b∅c w v (for some p, o, w and v); services si, foreach i, will be called reducts of s0.

We comment on salient points. Activity kill(k) forces termination of all unprotectedparallel activities (rules (kill) and (parkill)) inside an enclosing [k] , that stops the killingeffect by turning the transition label †k into † (rule (delkill)). Existence of such delimita-tion is ensured by the assumption that the semantics is only defined for closed services.

7

kill(k)†k−−→ 0 (kill) p • o?w.s

(p • o)Bw−−−−−−−→ s (rec)

[[e]] = v(inv)

p • o!e(p • o)Cv−−−−−−→ 0

g1α−−→ s

(choice)g1 + g2

α−−→ s

sp • o bσ]{x 7→v′}c w v−−−−−−−−−−−−−−→ s′

(delsub)[x] s

p • o bσc w v−−−−−−−−→ s′ ·{x 7→ v′}

s†k−−→ s′

(delkill)[k] s

†−→ [k] s′

sα−−→ s′ d<d(α) s = A[[kill(d)]]⇒ α=†, †k

(delpass)[d] s

α−−→ [d] s′

sα−−→ s′

(prot){|s|} α−−→ {|s′|}

s1(p • o)Bw−−−−−−−→ s′1 s2

(p • o)Cv−−−−−−→ s′2 M(w, v) = σ noc(s1 | s2, p • o, w, v)(com)

s1 | s2p • o bσc w v−−−−−−−−→ s′1 | s′2

s1p • o bσc w v−−−−−−−−→ s′1 noc(s2, p • o, w, v)

(parcon f )s1 | s2

p • o bσc w v−−−−−−−−→ s′1 | s2

s1†k−−→ s′1

(parkill)s1 | s2

†k−−→ s′1 | halt(s2)

s1α−−→ s′1 α , (p •o bσc w v), †k

(parpass)s1 | s2

α−−→ s′1 | s2

s ≡ s1 s1α−−→ s2 s2 ≡ s′

(cong)s

α−−→ s′

Table 4. COWS operational semantics

Sensitive code can be protected from killing by putting it into a protection {| |}; this way,{|s|} behaves like s (rule (prot)). Similarly, [d] s behaves like s, except when the transitionlabel α contains d or when a kill activity for d is active in s and α does not correspondto a kill activity (rule (delpass)): in such cases the transition should be derived by usingrules (delkill) or (delsub). In other words, kill activities are executed eagerly. A serviceinvocation can proceed only if the expressions in the argument can be evaluated (rule(inv)). Receive activities can always proceed (rule (rec)) and can resolve choices (rule(choice)). Communication can take place when two parallel services perform matchingreceive and invoke activities (rule (com)). Communication generates a substitution thatis recorded in the transition label (for subsequent application), rather than a silent tran-sition as in most process calculi. If more than one matching receive activity is ready toprocess a given invoke, then only the more defined one (i.e. the receive that generatesthe ‘smaller’ substitution) progresses (rules (com) and (parcon f )). This mechanism per-mits to correlate different service communications thus implicitly creating interactionsessions and can be exploited to model the precedence of a service instance over thecorresponding service specification when both can process the same request. When thedelimitation of a variable x argument of a receive is encountered, i.e. the whole scope

8

of the variable is determined, the delimitation is removed and the substitution for x isapplied to the term (rule (delsub)). Variable x disappears from the term and cannot be re-assigned a value. Execution of parallel services is interleaved (rule (parpass)), but when akill activity or a communication is performed. Indeed, the former must trigger termina-tion of all parallel services (according to rule (parkill)), while the latter must ensure thatthe receive activity with greater priority progresses (rules (com) and (parcon f )). The lastrule states that structurally congruent services have the same transitions.

2.3 Examples

We end this section with a few observations and examples aimed at clarifying the pecu-liarities of our formalism.

Communication of private names. Communication of private names is standard andexploits scope extension as in π-calculus. Notably, receive and invoke activities can in-teract only if both are in the scopes of the delimitations that bind the variables argumentof the receive. Thus, to enable communication of private names, besides their scopes,we must possibly extend the scopes of some variables, as in the following example:

[x] (p • o?〈x〉.s | s′) | [n] p • o!〈n〉 ≡ (n fresh)[n] ([x] (p • o?〈x〉.s | s′) | p • o!〈n〉) ≡[n] [x] (p • o?〈x〉.s | s′ | p • o!〈n〉) p •o b∅c 〈x〉 〈n〉−−−−−−−−−−−→[n] (s | s′) · {x 7→ n}

Notice that the substitution {x 7→ n} is applied to all terms delimited by [x] , not onlyto the continuation s of the service performing the receive. This is different from mostprocess calculi and accounts for the global scope of variables. This very feature permitsto easily model the delayed input of fusion calculus [31], which is instead difficult toexpress in π-calculus.

Delimited killer labels. We require killer labels to be delimited to avoid a single ser-vice be capable to stop all the other parallel services which would be unreasonable ina service-oriented setting. Indeed, suppose a service s can perform a kill(k) with k un-delimited in s. The killing effect could not be stopped, thus, due to a transition labelledby †k, the whole service s would be terminated (but for protected activities). Moreover,the effect of kill(k) could not be confined to s, thus, if there are other parallel services,the whole service composition might be terminated by kill(k).

Protected kill activity. The following simple example illustrates the effect of executinga kill activity within a protection block:

[k] ({|s1 | {|s2|} | kill(k)|} | s3) | s4†−−→ [k] {| {|s2|} |} | s4

where, for simplicity, we assume that halt(s1) = halt(s3) = 0. In essence, kill(k) termi-nates all parallel services inside delimitation [k] (i.e. s1 and s3), except those that areprotected at the same nesting level of the kill activity (i.e. s2).

9

Interplay between communication and kill activity. Kill activities can break communi-cation, as the following example shows:

p • o!〈n〉 | [k] ([x] p • o?〈x〉.s | kill(k))†−−→ p • o!〈n〉 | [k] [x] 0

Communication can however be guaranteed by protecting the receive activity, as in

p • o!〈n〉 | [k] ([x] {|p • o?〈x〉.s|} | kill(k))†−−→

p • o!〈n〉 | [k] [x] {|p • o?〈x〉.s|} ≡[x] (p • o!〈n〉 | [k] {|p • o?〈x〉.s|}) p •o b∅c 〈x〉 〈n〉−−−−−−−−−−−→[k] {|s · {x 7→ n}|}

Conflicting receive activities. This example shows a persistent service (implementedby mean of replication), that, once instantiated, enables two conflicting receives:

∗ [x] ( p1 • o?〈x〉.s1 | p2 • o?〈x〉.s2 ) | p1 • o!〈v〉 | p2 • o!〈v〉 p1 •o b∅c 〈x〉 〈v〉−−−−−−−−−−−→∗ [x] ( p1 • o?〈x〉.s1 | p2 • o?〈x〉.s2 ) | s1 · {x 7→ v} | p2 • o?〈v〉.s2 · {x 7→ v} | p2 • o!〈v〉

Now, the persistent service and the created instance, being both able to receive thesame tuple 〈v〉 along the endpoint p2 • o, compete for the request p2 • o!〈v〉. However, our(prioritized) semantics, in particular rule (com) in combination with rule (parcon f ), allowsonly the existing instance to evolve (and, thus, prevents creation of a new instance):

∗ [x] ( p1 • o?〈x〉.s1 | p2 • o?〈x〉.s2 ) | s1 · {x 7→ v} | s2 · {x 7→ v}

Message correlation. Consider now uncorrelated receive activities executed by a sameinstance, like in the following service:

∗ [x] p1 • o1?〈x〉.[y] p2 • o2?〈y〉.sThe fact that the messages for operations o1 and o2 are uncorrelated implies that, e.g., ifthere are concurrent instances then successive invocations for a same instance can mixup and be delivered to different instances. If one thinks it right, this behaviour can beavoided simply by correlating successive messages by means of some correlation data,e.g. the first received value as in the following service:

∗ [x] p1 • o1?〈x〉.[y] p2 • o2?〈y, x〉.s

Similarities with Lπ (localised π-calculus [26]). Lπ is the variant of π-calculus closestto COWS. In fact, all Lπ constructs have a direct counterpart in COWS and is indeedpossible to define an encoding that enjoys operational correspondence. More precisely,the syntax of Lπ processes is

P ::= 0 | a(b).P | ab | P | P | (νa)P | !a(b).P

with the constraint that in processes a(b).P and !a(b).P name b may not occur free inP in input position. For simplicity sake, we define the encoding only for Lπ processessuch that their bound names are all distinct and different from the free ones (but it can

10

〈〈a〉〉S∪{a} = xa • ya 〈〈a〉〉S = pa • oa if a < S

〈〈0〉〉S = 0 〈〈a(b).P〉〉S = [〈〈b〉〉S ′ ] 〈〈a〉〉S ′?〈〈b〉〉S ′ .〈〈P〉〉S ′ S ′ = S ∪ {b}〈〈(νa)P〉〉S = [〈〈a〉〉S ] 〈〈P〉〉S 〈〈ab〉〉S = 〈〈a〉〉S !〈〈b〉〉S〈〈P1 | P2〉〉S = 〈〈P1〉〉S | 〈〈P2〉〉S 〈〈!a(b).P〉〉S = ∗ 〈〈a(b).P〉〉S

Table 5. Lπ encoding

be easily extended to deal with all processes). The crux of the encoding is mapping eachLπ channel name in a COWS communication endpoint, that is composed of variablesif the channel name is bound by an input prefix (because in Lπ the name is used asa placeholder and COWS distinguishes between names and variables), and of namesotherwise. The actual encoding function 〈〈·〉〉S , that is parameterized by a set of namesS , is defined by induction on the syntax of Lπ processes by the clauses in Table 5 (wherethe endpoint pa • oa is sometimes used in place of the tuple 〈pa, oa〉). The encoding ofprocess P is given by service 〈〈P〉〉S with S = ∅; as the encoding proceeds, S is used torecord the names that have been freed and were initially bound by an input prefix.

3 Modelling imperative and orchestration constructs

In this section, we present the encoding of some higher level imperative and orchestra-tion constructs (mainly inspired by WS-BPEL). The encodings illustrate flexibility ofCOWS and somehow demonstrate expressiveness of the chosen set of primitives.

In the sequel, we will write Zv , W to assign a symbolic name Zv to the term W andto indicate the values v occurring within W. Thus, Zv is a family of names, one for eachtuple of values v. We use n to stand for the endpoint np • no. Sometimes, we write n forthe tuple 〈np, no〉 and rely on the context to resolve any ambiguity.

3.1 Imperative constructs

Suppose to add a matching with assignment construct [w = e] to COWS basic activities.Hence, we can also write services of the form [w = e].s whose intended semantics isthat, if w and e do match, a substitution is returned that will eventually assign to thevariable in w the corresponding value of e, and service s can proceed. In COWS, thismeaning can be rendered through the following encoding

〈〈[w = e].s〉〉 = [m] (m!〈e〉 | m?〈w〉.〈〈s〉〉) (1)

for m fresh. The new construct generalizes standard assignment because it allows valuesto occur on the left of =, in which case it behaves as a matching mechanism. Similarly,we can encode conditional choice as follows:

〈〈if (e) then {s1} else {s2}〉〉 = [m] (m!〈e〉 | (m?〈true〉.〈〈s1〉〉 + m?〈false〉.〈〈s2〉〉) ) (2)

11

where true and false are the values that can result from evaluation of e.Like the receive activity, matching with assignment does not bind the variables on

the left of =, thus it cannot reassign a value to them if a value has already been assigned.Therefore, the behaviour of matching with assignment may differ from standard assign-ment, even when the former uses only variables on the left of = as the latter does. Forexample, activity [x = 1] will not necessarily generate substitution {x 7→ 1}. In fact,when it will be executed, x could have been previously replaced by a value v in whichcase execution of the activity corresponds to checking if v and 1 do match. For similarreasons, activity [x = x + 1] does not have the effect of increasing the value of x by 1,but that of checking if the value of x and that of x + 1 do match, which always fails.

Standard variables (that can be repeatedly assigned) can be rendered as servicesproviding ‘read’ and ‘write’ operations. When the service variable is initialized (i.e. thefirst time the ‘write’ operation is used), an instance is created that is able to providethe value currently stored. When this value must be updated, the current instance isterminated and a new instance is created which stores the new value (alike the memorycell service of [3]). Here is the specification:

Varx , [xv, xa] x • owrite?〈xv, xa〉.[m] (m!〈xv, xa〉 |

∗ [x, y] m?〈x, y〉.(y!〈〉 | [k] (∗ [y′] x • oread?〈y′〉.{|y′!〈x〉|}

| [x′, y′] x • owrite?〈x′, y′〉 .(kill(k) | {|m!〈x′, y′〉|} ) ) ) )

where x is a public partner name. Service Varx provides two operations: oread, for get-ting the current value; owrite, for replacing the current value with a new one. To accessthe service, a user must invoke these operations by providing a communication endpointfor the reply and, in case of owrite, the value to be stored. The owrite operation can beinvoked along the public partner x, which corresponds, the first time, to initializationof the variable. Thus, Varx uses the delimited endpoint m in which to store the currentvalue of the variable. This last feature is exploited to implement further owrite operationsin terms of forced termination and re-instantiation. Delimitation [k] is used to confinethe effect of the kill activity to the current instance, while protection {| |} avoids forcingtermination of pending replies and of the invocation that will trigger the new instance.

Now, suppose temporarily that standard variables, ranged over by X,Y, . . ., may oc-cur in the syntax of COWS anywhere a variable can. We can remove them by using thefollowing encodings. If e contains standard variables X1, . . . Xn, we can let

〈〈e〉〉m,n = [r1, . . . , rn] ( x1 • oread!r1 | · · · | xn • oread!rn |[x1, . . . , xn] (r1?〈x1〉. · · · .rn?〈xn〉.

m!〈e·{Xi 7→ xi}i∈{1,..,n}, n〉) )

where {Xi 7→ xi} denotes substitution of standard variable Xi with variable xi, endpointm returns the result of evaluating e, and endpoint n permits to receive an acknowl-edgment when the resulting value is assigned to a service variable (of course, we areassuming that m, n, ri and xi are fresh). With this encoding of expression evaluation, the

12

encoding of matching with assignment becomes

〈〈[w = e].s〉〉= [r, n] (〈〈e〉〉r,n | r?〈w, n〉.〈〈s〉〉)〈〈[X = e].s〉〉= [n] (〈〈e〉〉x•owrite,n | n?〈〉.〈〈s〉〉)

where w is a value v or a variable x, while X is a standard variable. In the sequel, wewill write [w = e], where w = 〈w1, . . . ,wn〉 and e = 〈e1, . . . , en〉, with w and e that maycontain standard variables, for the sequence of assignments [w1 = e1]. · · · .[wn = en].The encodings of the remaining constructs where standard variables may directly occurare

〈〈[X] s〉〉 = [x] (Varx | 〈〈s〉〉)〈〈X • u!e〉〉 = [x, r] (x • oread!r | r?〈x〉.〈〈x • u!e〉〉 )〈〈u • X!e〉〉 = [x, r] (x • oread!r | r?〈x〉.〈〈u • x!e〉〉 )

〈〈u • u′!〈e1, . . . , en〉〉〉 = [x1, r1, m1, . . . , xn, rn, mn] ( 〈〈e1〉〉r1,m1 | . . . | 〈〈en〉〉rn,mn |r1?〈x1, m1〉. · · · .rn?〈xn, mn〉.(u • u′!〈x1, . . . , xn〉) )

〈〈p • o?w.s〉〉 = [x1, . . . , xn] p • o?w·{Xi 7→ xi}i∈{1,..,n}.[r1, . . . , rn] ( x1 • owrite!〈x1, r1〉 | . . . | xn • owrite!〈xn, rn〉 |

r1?〈〉. · · · .rn?〈〉.〈〈s〉〉 )if w contains standard variables X1, . . . Xn

This way, occurrences of standard variables can be completely removed. Sequentialcomposition can be encoded alike in CCS [27, Chapter 8] however, due to the asyn-chrony of invoke and kill activities, the notion of well-termination must be relaxed wrtCCS. Firstly, we settle that services may indicate their termination by exploiting the in-voke activity xdone • odone!〈〉, where xdone is a distinguished variable and odone is a distin-guished name. Secondly, we say that a service s is well-terminating if, for every reduct

s′ of s and fresh partner p, s′ ·{xdone 7→ p} (p •odone)C〈〉−−−−−−−−−−→ implies that if s′ ·{xdone 7→ p} α−−→then α = (p′ •o)C v, for some p′, o and v. Notably, well-termination does not demand aservice to terminate, but only that whenever the service can perform activity p • odone!〈〉and cannot perform any kill activities, then it terminates except for, possibly, some par-allel pending invoke activities. As usual, the encoding relies on the assumption that allcalculus operators themselves (in particular, parallel composition) can be rendered as topreserve well-termination. Finally, if we only consider well-terminating services, then,for a fresh p, we can let:

〈〈s1; s2〉〉 = [p] (〈〈s1 · {xdone 7→ p}〉〉 | p • odone?〈〉.〈〈s2〉〉)Of course, iterative constructs can be encoded by exploiting the previous encodings.

In the sequel, we shall use the derived constructs with no more ado.

3.2 Fault and compensation handlers

In the SOC approach, fault handling is strictly related to the notion of compensation,namely the execution of specific activities (attempting) to reverse the effects of pre-viously executed activities. We consider here a minor variant of the WS-BPEL com-pensation protocol. To begin with, we extend COWS syntax as shown in Table 6. The

13

s ::= . . . (services)| throw(φ) (fault generator)| undo(ı) (compensate)| [s : catch(φ1){s1} : . . . : catch(φn){sn} : sc]ı (scope)

Table 6. COWS plus fault and compensation handlers

scope activity [s : catch(φ1){s1} : . . . : catch(φn){sn} : sc]ı permits explicitly groupingactivities together. The declaration of a scope activity contains a unique scope identifierı, a service s representing the normal behaviour, an optional list of fault handlers, anda compensation handler sc. The fault generator activity throw(φ) can be used by a ser-vice to rise a fault signal φ. This signal will trigger execution of activity s′, if a constructof the form catch(φ){s′} exists within the same scope. The compensate activity undo(ı)can be used to invoke a compensation handler of an inner scope named ı that has al-ready completed normally (i.e. without faulting). Compensation can only be invokedfrom within a fault or a compensation handler. As in WS-BPEL, we fix two syntacticconstraints: handlers do not contain scope activities and for each undo(ı) occurring ina service there exists at least an inner scope ı.

In fact, it is not necessary to extend COWS syntax because fault and compensationhandling can be easily encoded. The most interesting cases of the encoding are shownin the lower part of Table 7 (in the remaining cases, the encoding acts as an homomor-phism), where the killer labels used to identify scopes and the introduced partner namesare taken fresh for s, s1, . . . , sn and sc. The two distinguished names o f ault and ocomp

denote the operations for receiving fault and compensation signals, respectively. Weare assuming that for each scope identifier named ı, the partner used to activate scopecompensation is pı.

The encoding 〈〈·〉〉k is parameterized by the identifier k of the closest enclosing scope,if any. The parameter is used when encoding a fault generator, to launch a kill activitythat forces termination of all the remaining activities of the enclosing scope, and whenencoding a scope, to delimit the field of action of inner kill activities. The compensationhandler sc of scope ı is installed when the normal behaviour s successfully completes,but it is activated only when signal pı • ocomp!〈〉 occurs. Similarly, if during normalexecution a fault φ occurs, a signal p • o f ault!〈φ〉 triggers execution of the correspondingfault handler (if any). Installed compensation handlers are protected from killing bymeans of {| |}. Notably, both the compensate activity and the fault generator activity canimmediately terminate (thus enabling possible sequential compositions); this, of course,does not mean that the corresponding handler is terminated.

Other kinds of faults could be handled similarly. For example, an invoke activityinv(u1 • u2, e) that generates a fault φundef when its argument e is undefined, could beencoded as follows:

〈〈inv(u1 • u2, e)〉〉 = [k] (u1 • u2!e | [true = (e == undef )].〈〈throw(φundef )〉〉k) |〈〈catch(φundef ){sundef }〉〉

where k is fresh and, for simplicity, we assume that the fault handler for φundef is definedlocally to the invoke activity.

14

〈〈[s : catch(φ1){s1} : . . . : catch(φn){sn} : sc]ı〉〉k =

[p] ( 〈〈catch(φ1){s1}〉〉k | . . . | 〈〈catch(φn){sn}〉〉k |[kı] ( 〈〈s〉〉kı ; ( xdone • odone!〈〉 | [k′] {|pı • ocomp?〈〉.〈〈sc〉〉k′ |} ) ) )

〈〈catch(φ){s}〉〉k = p • o f ault?〈φ〉.[k′] 〈〈s〉〉k′

〈〈undo(ı)〉〉k = pı • ocomp!〈〉 | xdone • odone!〈〉

〈〈throw(φ)〉〉k = {|p • o f ault!〈φ〉|} | kill(k)

Table 7. Encoding of fault and compensation handling

s ::= . . . | [ f l] ls | ∑i∈I pi • oi?wi.si (services)

ls ::= ( jc)s j f⇒ s⇒ ( f l, e) | s⇒ ( f l, e) | ls | ls (linked services)

jc ::= true | false | f l | ¬ jc | jc ∨ jc | jc ∧ jc (join conditions)

s j f ::= yes | no (supp. join failure)

Table 8. COWS plus flow graphs

3.3 Flow graphs

In business process management, flow graphs1 provide a direct and intuitive way tostructure workflow processes, where activities executed in parallel can be synchronizedby settling dependencies, called (flow) links, among them. At the beginning of a parallelexecution, all involved links are inactive and only those activities with no synchroniza-tion dependencies can execute. Once all incoming links of an activity are active (i.e.,they have been assigned either a positive or negative state), a guard, called join condi-tion, is evaluated. When an activity terminates, the status of the outgoing links, whichcan be positive, negative or undefined, is determined through evaluation of a transitioncondition. When an activity in the flow graph cannot execute (i.e., the join conditionfails), a join failure fault is emitted to signal that some activities have not completed.An attribute called ‘suppress join failure’ can be set to yes to ensure that join conditionfailures do not throw the join failure fault (this way obtaining the so-called Dead-PathElimination effect [1]).

To express the constructs above, we extend the syntax of COWS as illustrated in theupper part of Table 8. A flow graph activity [ f l] ls is a delimited linked service, wherethe activities within ls can synchronize by means of the flow links in f l, rendered as(boolean) variables. A linked service is a service equipped with a set of incoming flow

1 Here, we refer to the corresponding notion of WS-BPEL rather than to similar synchronizationconstructs of some process calculi (see e.g. [19]) or to the homonymous graphical notationused for representing processes and their interconnection structure (see, e.g., [27, 28]).

15

〈〈[ f l] ls〉〉 = [ f l] 〈〈ls〉〉 〈〈ls1 | ls2〉〉 = 〈〈ls1〉〉 | 〈〈ls2〉〉 〈〈s⇒ ( f l, e)〉〉 = 〈〈s〉〉; [ f l = e]

〈〈( jc)yes⇒ s⇒ ( f l, e)〉〉 = if ( jc) then {〈〈s〉〉; [ f l = e]} else {[outLinkOf (s) = false]}

〈〈( jc)no⇒ s⇒ ( f l, e)〉〉 = if ( jc) then {〈〈s〉〉; [ f l = e]} else {throw(φ join f )}

〈〈∑i∈{1..n} pi • oi?wi.si〉〉 = p1 • o1?w1.[⋃

j∈{2..n} outLinkOf (s j) = false].〈〈s1〉〉+ . . . + pn • on?wn.[

⋃j∈{1..n−1} outLinkOf (s j) = false].〈〈sn〉〉

Table 9. Encoding of flow graphs

links that forms the join condition, and a set of outgoing flow links that represents the

transition condition. Incoming flow links and join condition are denoted by ( jc)s j f⇒.

Outgoing links are represented by ⇒ ( f li∈I , ei∈I) where each pair ( f li, ei) is composedof a flow link f li and the corresponding transition (boolean) condition ei. Attribute s j fpermits suppressing possible join failures. Input-guarded summation replaces binarychoice, because we want all the branches of a multiple choice to be considered at once.

Again, we show that in fact it is not necessary to extend the syntax because flowgraphs can be easily encoded by relying on the capability of COWS of modelling astate shared among a group of activities. The most interesting cases of the encodingare shown in Table 9. The encoding exploits the auxiliary function outLinkOf (s), thatreturns the tuple of outgoing links in s and is inductively defined as follows:

outLinkOf ([ f l] ls) = outLinkOf (ls)outLinkOf (

∑i∈{1..n} pi • oi?wi.si) = outLinkOf (s1), . . . , outLinkOf (sn)

outLinkOf (( jc)s j f⇒ s⇒ ( f l, e)) = outLinkOf (s) , f l

outLinkOf (s⇒ ( f l, e)) = outLinkOf (s) , f loutLinkOf (ls1 | ls2) = outLinkOf (ls1) , outLinkOf (ls2)outLinkOf (0) = outLinkOf (kill(k)) = outLinkOf (u1 • u2!e) = 〈〉outLinkOf (s1 | s2) = outLinkOf (s1) , outLinkOf (s2)outLinkOf ({|s|}) = outLinkOf ([d] s) = outLinkOf (∗ s) = outLinkOf (s)

Flow graphs are rendered as delimited services, while flow links are rendered as vari-ables. A join condition is encoded as a boolean condition within a conditional construct,where the transition conditions are rendered as the assignment [ f l = e]. In case attribute‘suppress join failure’ is set to no, a join condition failure produces a fault signal thatcan be caught by a proper fault handler. Choice among (linked) services is implementedin such a way that, when a branch is selected, the links outgoing from the activities ofthe discarded branches are set to f alse. The same rationale underlies the new encodingof conditional choice

〈〈if (e) then {s1} else {s2}〉〉 = if (e) then {[outLinkOf (s2) = false].〈〈s1〉〉}else {[outLinkOf (s1) = false].〈〈s2〉〉}

16

4 Examples

In this section we show two application of our framework. The former is an exampleof a web service inspired by the well-known game Rock/Paper/Scissors, the latter is anexample of a shipping service from WS-BPEL specification [1].

4.1 Rock/Paper/Scissors Service

Consider the following web service:

rps , ∗ [xchamp res, xchall res, xid, xthr 1, xthr 2, xwin](pchamp • othrow?〈xchamp res, xid, xthr 1〉.xchamp res • owin!〈xid, xwin〉 |pchall • othrow?〈xchall res, xid, xthr 2〉.xchall res • owin!〈xid, xwin〉 |Assign)

The task of service rps is to collect two throws, stored in xthr 1 and xthr 2, from twodifferent participants, the current champion and the challenger, assign the winner toxwin and then send the result back to the two players. The service receives throws fromthe players via two distinct endpoints, characterized by operation othrow and partnerspchamp and pchall. The service is of kind “request-response” and is able to serve chal-lenges coming from any pairs of participants. The players are required to provide thepartner names, stored in xchamp res and xchall res, which they will use to receive the result.A challenge is uniquely identified by a challenge-id, here stored in xid, that the partnersneed to provide when sending their throws. Partner throws arrive randomly. Thus, whena throw is processed, for instance the challenging one, it must be checked if a serviceinstance with the same challenge-id already exists or not. We assume that Assign imple-ments the rules of the game and thus, by comparing xthr 1 and xthr 2, assigns the winnerof the match by producing the assignment [xwin = xchamp res] or [xwin = xchall res]. Thus,we have

Assign , if (xthr 1 == “rock”&xthr 2 == “scissors”)then { [xwin = xchamp res] }else { if (xthr 1 == “rock”&xthr 2 == “paper”)

then { [xwin = xchall res] }else { . . .}

}

A partner may simultaneously play multiple challenges by using different challengeidentifiers as a means to correlate messages received from the server. E.g., the partner

(pchall • othrow!〈p′chall, 0, “rock”〉 | [x] p′chall• owin?〈0, x〉.s0) |

(pchall • othrow!〈p′chall, 1, “paper”〉 | [y] p′chall• owin?〈1, y〉.s1)

is guaranteed that the returned results will be correctly delivered to the correspondingcontinuations.

17

Fig. 1. Graphical representation of a Rock/Paper/Scissors service scenario

Let us now consider the following match of rock/paper/scissors identified by thecorrelation value 0:

s , rps | pchamp • othrow!〈p′champ, 0, “rock”〉 | [x] p′champ• owin?〈0, x〉.schamp

| pchall • othrow!〈p′chall, 0, “scissors”〉 | [y] p′chall• owin?〈0, y〉.schall

where p′champ and p′chall denote the players’ partner names. Figure 1 shows a customizedUML sequence diagram depicting the above scenario. The champion and a challengerparticipate to the match, play their throws (i.e. “rock” and “scissors”), wait for theresulting winner, and (possibly) use this result in their continuation processes (i.e. schamp

and schall). Here is a computation produced by selecting the champion’s throw:

spchamp •othrow b∅c 〈xchamp res,xid ,xthr 1〉 〈p′champ,0,“rock”〉−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−→

rps | [xchall res, xthr 2, xwin] ( p′champ• owin!〈0, xwin〉 |

pchall • othrow?〈xchall res, 0, xthr 2〉.xchall res • owin!〈0, xwin〉 |Assign · {xchamp res 7→ p′champ, xid 7→ 0, xthr 1 7→ “rock”} )

| [x] p′champ• owin?〈0, x〉.schamp

| pchall • othrow!〈p′chall, 0, “scissors”〉 | [y] p′chall• owin?〈0, y〉.schall , s′

Below, the challenger’s throw is consumed by the existing instance:

s′pchall •othrow b∅c 〈xchall res,0,xthr 2〉 〈p′chall,0,“scissors”〉−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−→

rps | [xwin] ( p′champ• owin!〈0, xwin〉 | p′chall

• owin!〈0, xwin〉 |Assign · {xchamp res 7→ p′champ, xid 7→ 0, xthr 1 7→ “rock”,

xchall res 7→ p′chall, xthr 2 7→ “scissors”} )| [x] p′champ

• owin?〈0, x〉.schamp

| [y] p′chall• owin?〈0, y〉.schall

18

In the computation above, rules (com) and (parcon f ) allow only the existing instance toevolve (thus, creation of a new conflicting instance is avoided). Once Assign determinesthat pchamp won, the substitutive effects of communication transforms the system asfollows:

s′′ , rps | p′champ• owin!〈0, pchamp〉 | p′chall

• owin!〈0, pchamp〉| [x] p′champ

• owin?〈0, x〉.schamp

| [y] p′chall• owin?〈0, y〉.schall

At the end, the name of the resulting winner is sent to both participants as shown by thefollowing computation:

s′′p′champ •owin b∅c 〈0,x〉 〈0,pchamp〉−−−−−−−−−−−−−−−−−−−−−−→ p′chall •owin b∅c 〈0,y〉 〈0,pchamp〉−−−−−−−−−−−−−−−−−−−−−→

rps | schamp · {x 7→ pchamp} | schall · {y 7→ pchamp}

4.2 Shipping Service

We consider an extended version of the shipping service described in the official spec-ification of WS-BPEL [1] (Section 15.1). This example covers most of the languagefeatures we are interested in, including correlation sets, variables, flow control struc-tures, fault and compensation handling. We assume that the reader is already familiarwith the main features of WS-BPEL. This service handles the shipment of orders. Fromthe service point of view, orders are composed of a number of items. The shipping ser-vice offers two types of shipment: shipments where the items are held and shippedtogether and shipments where the items are shipped piecemeal until all of the orderis fulfilled. Figure 2 illustrates a scenario where the shipping service interacts with acustomer service. The shipping service is specified in COWS as follows:

∗ [xid, xcomplete, xitemsTot]pshipS erv • oreq?〈xid, xcomplete, xitemsTot〉.if (xcomplete) then { pcust • onotice!〈xid, xitemsTot〉 }

else { [ s : catch(φnoItems){ undo(ıprice) | pcust • oerr!〈xid, “sorry”〉 } : 0 ]ı }

where the normal behaviour s is

[xratio] ( [ sshipPriceCalc : sshipPriceComp ]ıprice ;[owhile] ( pshipS erv • owhile!〈0〉 |

∗ [xc] pshipS erv • owhile?〈xc〉.if (xc < xitemsTot) then { [xitemsCount]

[xitemsCount = rand()].if (xitemsCount 6 0) then {

[xratio = xc / xitemsTot].throw(φnoItems) }else { pcust • onotice!〈xid, xitemsCount〉 |

pshipS erv • owhile!〈xc + xitemsCount〉 } }else {0}

))

19

Fig. 2. Graphical representation of a shipping service scenario

pshipS erv is the partner associated to the shipping service, oreq is the operation usedto receive the shipping request, and 〈xid, xcomplete, xitemsTot〉 is the tuple of variables usedfor the request shipping message: xid stores the order identifier, that is used to correlatethe ship notice(s) with the ship order, xcomplete stores a boolean indicating whether theorder is to be shipped complete or not, and xitemsTot stores the total number of items inthe order. Shipping notices and error messages to customers are sent using partner pcust

and operations onotice and oerr, respectively. A notice message is a tuple composed of theorder identifier and the number of items in the shipping notice. When partial shipmentis acceptable, xc is used to record the number of items already shipped. Replication andthe internal operation owhile are used to model iteration.

Our example extend that in [1] by allowing the service to generate a fault in casethe shipping company has ended the stock of items (this is modelled by function rand()returning an integer less or equal to 0). The fault is handled by sending an error messageto the customer and by compensating the inner scope ıprice, that has already completedsuccessfully. Function rand() returns a random integer number and represents an inter-nal interaction with a back-end system. For the sake of simplicity, we don’t describethis interaction. Moreover, we don’t show services sshipPriceCalc and sshipPriceComp. Basi-cally, the former calculates the shipping price according to the value assigned to xitemsTot

and sends the result to the accounts department. The latter is the corresponding com-pensation activity, that sends information about the non-shipped items to the accountsdepartment and sends a refund to the customer according to the ratio (stored in xratio)between the shipped items (stored in xc) and the required ones (stored in xitemsTot).

20

S (v)!v′↪→ 0 (SiteCall)

E(x) , f(Def)

E(w)τ↪→ f · {x 7→ w}

fl↪→ f ′

(Sym1)f | g l

↪→ f ′ | g

gl↪→ g′

(Sym2)f | g l

↪→ f | g′f

τ↪→ f ′

(Seq1)f > x > g

τ↪→ f ′ > x > g

f!v↪→ f ′

(Seq2)f > x > g

τ↪→ ( f ′ > x > g) | g · {x 7→ v}

gl↪→ g′

(Asym1)g where x :∈ f

l↪→ g′ where x :∈ f

fτ↪→ f ′

(Asym2)g where x :∈ f

τ↪→ g where x :∈ f ′

f!v↪→ f ′

(Asym3)g where x :∈ f

τ↪→ g · {x 7→ v}

Table 10. Orc asynchronous operational semantics

5 Encoding other formal languages for orchestration

We present here the encodings in COWS of two orchestration languages: Orc and -. The former language has already proved to be capable of expressing the mostcommon workflow patterns; the latter one turned out to be suitable to model in a quitedirect way the semantics of whole WS-BPEL [22, 23].

5.1 Encoding Orc

We present here the encoding of Orc [29], a recently proposed task orchestration lan-guage with applications in workflow, business process management, and web serviceorchestration. We will show that the encoding enjoys a property of operational corre-spondence. This is another sign of COWS expressiveness because it is known that Orccan express the most common workflow patterns identified in [32]. Orc syntax is:

(Expressions) f , g ::= 0 | S (w) | E(w) | f > x > g | f | g | g where x :∈ f

(Parameters) w ::= x | v

where S ranges over site names, E over expression names, x over variables, and v overvalues. Each expression name E has a unique declaration of the form E(x) , f . Ex-pressions can be composed by means of sequential composition · > x > ·, symmetricparallel composition · | ·, and asymmetric parallel composition · where x :∈ · start-ing from the elementary expressions 0, S (w) (site call) and E(w) (expression call). Thevariable x is bound in g for the expressions f > x > g and g where x :∈ f . Variable x isfree in f if it is not bound in f . We use f v( f ) to denote the set of variables which occurfree in f .

21

Evaluation of expressions may call a number of sites and returns a (possibly empty)stream of values. The asynchronous operational semantics of Orc is given by the la-

belled transition relationl↪→ defined in Table 10, where label τ indicates an internal

event while label !v indicates the value v resulting from evaluating an expression. A sitecall can progress only when the actual parameter is a value (rule (SiteCall)); it elicits oneresponse. While site calls use a call-by-value mechanism, expression calls use a call-by-name mechanism (rule (Def)), namely the actual parameter replaces the formal oneand then the corresponding expression is evaluated. Symmetric parallel compositionf | g consists of concurrent evaluations of f and g (rules (Sym1) and (Sym2)). Sequen-tial composition f > x > g activates a concurrent copy of g with x replaced by v, foreach value v returned by f (rules (Seq1) and (Seq2)). Asymmetric parallel compositiong where x :∈ f prunes threads selectively. It starts in parallel both f and the part ofg that does not need x (rules (Asym1) and (Asym2)). The first value returned by f is as-signed to x and the continuation of f and all its descendants are then terminated (rule(Asym3)).

Notably, the presented operational semantics slightly simplifies that described in[29], in a way that does not misrepresent the properties of the encoding. Indeed, in theoriginal semantics, a site call involves three steps: invocation of the site, response fromthe site, and publication of the result. Here, instead, a site call is performed in one step,that corresponds to the immediate publication of the result.

The encoding of Orc expressions in COWS exploits function 〈〈·〉〉r shown in Ta-ble 11. The function is defined by induction on the syntax of expressions and is pa-rameterized by the communication endpoint r used to return the result of expressionsevaluation. Thus, a site call is rendered as an invoke activity that sends a pair madeof the parameter of the invocation and the endpoint for the reply along the endpoint Scorresponding to site name S . Expression call is rendered similarly, but we need twoinvoke activities: E!〈r, r′〉 activates a new instance of the body of the declaration, whilez!〈w〉 sends the value of the actual parameter (when this value will be available) to thecreated instance, by means of a private endpoint stored in z received from the encodingof the corresponding expression declaration along the private endpoint r′ previouslysent. Sequential composition is encoded as the parallel composition of the two compo-nents sharing a delimited endpoint, where a new instance of the component on the rightis created every time that on the left returns a value along the shared endpoint. Symmet-ric parallel composition is encoded as parallel composition, where the values producedby the two components are sent along the same return endpoint. Finally, asymmetricparallel composition is encoded in terms of parallel composition in such a way that,whenever the encoding of f returns its first value, this is passed to the encoding of gand a kill activity is enabled. Due to its eager semantics, the kill will terminate whatremains of the term corresponding to the encoding of f .

Moreover, for each site S , we define the service:

∗ [x, y] S ?〈x, y〉.y!〈eSx 〉 (1)

that receives along the endpoint S a value (stored in x) and an endpoint (stored in y)to be used to send back the result, and returns the evaluation of eS

x , an unspecifiedexpression corresponding to S and depending on x.

22

〈〈0〉〉r = 0 〈〈S (w)〉〉r = S !〈w, r〉 〈〈E(w)〉〉r = [r′] (E!〈r, r′〉 | [z] r′?〈z〉.z!〈w〉)

〈〈 f > x > g〉〉r = [r f ] (〈〈 f 〉〉r f | ∗ [x] r f ?〈x〉.〈〈g〉〉r) 〈〈 f | g〉〉r = 〈〈 f 〉〉r | 〈〈g〉〉r

〈〈g where x :∈ f 〉〉r = [r f , x] ( 〈〈g〉〉r | [k] ( 〈〈 f 〉〉r f | r f ?〈x〉.kill(k) ) )

Table 11. Orc encoding

Similarly, for each expression declaration E(x) , f we define the service:

∗ [y, z] E?〈y, z〉.[r] (z!〈r〉 | [x] (r?〈x〉 | 〈〈 f 〉〉y) ) (2)

Here, the received value (stored in x) is processed by the encoding of the body of thedeclaration, that is activated as soon as the expression is called.

Finally, the encoding of an Orc expression f , written [[ f ]]r, is the parallel composi-tion of 〈〈 f 〉〉r, of a service of the form (1) or (2) for each site or expression called in f ,in any of the expressions called in f , and so on recursively.

We can prove that there is a formal correspondence, based on the operational seman-tics, between Orc expressions and the COWS services resulting from their encoding. Tosimplify the proof, we found it convenient to extend the syntax of Orc expressions withf · {x 7→ y}, that behaves as the expression obtained from f by replacing all free oc-currences of x with y. Correspondingly, we add the following rule to those defining theoperational semantics:

fl↪→ f ′

(Sub)

f · {x 7→ y} l↪→ f ′ · {x 7→ y}

Next proposition, that can be easily proved by induction on the syntax of expressions,states that there is an operational correspondence between the extended semantics andthe original one.

Proposition 1. If y < f v( f ), then fl↪→ f ′ iff f · {x 7→ y} l

↪→ f ′ · {x 7→ y}.

Expression f · {x 7→ y} is encoded as the parallel composition of the encoding of fwith a receive activity r′?〈x〉, that initializes the shared variable x, and with an invokeactivity r′!〈y〉, that forwards the value of variable y (when it will be available) along theprivate endpoint r′. Formally, it is defined as

〈〈 f · {x 7→ y}〉〉r = [r′] (r′!〈y〉 | [x] (r′?〈x〉 | 〈〈 f 〉〉r) )

The operational correspondence between Orc expressions and the COWS servicesresulting from their encoding can be characterized by two propositions, which we callcompleteness and soundness. The former states that all possible executions of an Orcexpression can be simulated by its encoding, while the latter states that the initial stepof a COWS term resulting from an encoding can be simulated by the corresponding Orc

23

expression so that the continuation of the encoding can evolve in the encoding of theexpression continuation. By letting s

α==⇒ s′ to mean that there exist two services, s1

and s2, such that s1 is a reduct of s, s1α−−→ s2 and s′ is a reduct of s2, the two properties

can be stated as follows.

Theorem 1 (Completeness). Given an Orc expression f and a communication end-

point r, fl↪→ f ′ implies [[ f ]]r ≡ 〈〈 f 〉〉r | s

α==⇒ 〈〈 f ′〉〉r | s, where α = r C 〈v〉 if l = !v, and

α = (p •o b∅c w v) if l = τ.

Proof: The proof proceeds by induction on the length of the inference of fl↪→ f ′.

Base Step: We reason by case analysis on the axioms of the operational semantics.

(SiteCall) In this case f = S (v), l =!v′ and f ′ = 0. By encoding definition, 〈〈S (v)〉〉r |s = S !〈v, r〉 | s, where s = ∗ [x, y] S ?〈x, y〉.y!〈v′〉. Thus, S !〈v, r〉 | s

S b∅c 〈x,y〉 〈v,r〉−−−−−−−−−−−→r!〈v′〉 | s rC〈v′〉−−−−−→ 0 | s. Since 〈〈0〉〉r = 0, we can conclude.

(Def) In this case f = E(w) with E(x) , g, l = τ and f ′ = g · {x 7→ w}. By en-coding definition, 〈〈E(w)〉〉r | s = [r′] (E!〈r, r′〉 | [z′] r′?〈z′〉.z′!〈w〉) | s, where s =

∗ [y, z] E?〈y, z〉.[r′′] (z!〈r′′〉 | [x] (r′′?〈x〉 | 〈〈g〉〉y) ). Thus, 〈〈E(w)〉〉r | sE b∅c 〈y,z〉 〈r,r′〉−−−−−−−−−−−→

[r′] ([z′] r′?〈z′〉.z′!〈w〉 | [r′′] (r′!〈r′′〉 | [x] (r′′?〈x〉 | 〈〈g〉〉r) ) ) | s , s′. Then,

s′r′ b∅c 〈z′〉 〈r′′〉−−−−−−−−−−→ [r′′] (r′′!〈w〉 | [x] (r′′?〈x〉 | 〈〈g〉〉r) ) | s , s′′. In case w = z′′,

since 〈〈g · {x 7→ z′′}〉〉r ≡ [r′′] (r′′!〈z′′〉 | [x] (r′′?〈x〉 | 〈〈g〉〉r) ), we can directly con-

clude. Instead, in case w = v′, we have s′′r′′ b∅c 〈x〉 〈v′〉−−−−−−−−−−→ 〈〈g〉〉r · {x 7→ v′} | s. Thus,

since 〈〈g〉〉r · {x 7→ v′} ≡ 〈〈g · {x 7→ v′}〉〉r, we can conclude.

Inductive Step: We reason by case analysis on the last applied inference rule of theoperational semantics.

(Sym1) In this case, f = f1 | f2, f ′ = f ′1 | f2. By the premise of the rule (Sym1),

f1l↪→ f ′1 . By encoding definition, 〈〈 f 〉〉r | s = 〈〈 f1〉〉r | 〈〈 f2〉〉r | s. By induction,

〈〈 f1〉〉r | s′α

==⇒ 〈〈 f ′1〉〉r | s′ where s ≡ s′ | s′′. By rules (parpass) or (parcon f ), we canconclude.

(Sym2) Similar to the previous case.(Seq1) In this case, f = f1 > x > f2, l = τ and f ′ = f ′1 > x > f2. By the premise

of the rule (Seq1), f1τ↪→ f ′1 . By encoding definition, 〈〈 f 〉〉r | s = [r′] (〈〈 f1〉〉r′ |

∗ [x] r′?〈x〉.〈〈 f2〉〉r) | s. By induction, 〈〈 f1〉〉r′ | s′p •o b∅c w v

========⇒ 〈〈 f ′1〉〉r′ | s′ where s ≡s′ | s′′. By rules (parcon f ) and (delpass), we can conclude that 〈〈 f 〉〉r | s

p •o b∅c w v========⇒

〈〈 f ′1 > x > f2〉〉r | s.(Seq2) In this case, f = f1 > x > f2, l =!v and f ′ = ( f ′1 > x > f2) | f2 · {x 7→ v}.

By the premise of the rule (Seq2), f1!v↪→ f ′1 . By encoding definition, 〈〈 f 〉〉r | s =

[r′] (〈〈 f1〉〉r′ | ∗ [x] r′?〈x〉.〈〈 f2〉〉r) | s. By induction, 〈〈 f1〉〉r′ | s′r′C〈v〉

=====⇒ 〈〈 f ′1〉〉r′ | s′

where s ≡ s′ | s′′. Thus, 〈〈 f 〉〉r | sr′ b∅c 〈x〉 〈v〉

=========⇒ [r′] (〈〈 f ′1〉〉r′ | ∗ [x] r′?〈x〉.〈〈 f2〉〉r |〈〈 f2 · {x 7→ v}〉〉r) | s ≡ 〈〈 f ′1 > x > f2〉〉r | 〈〈 f2 · {x 7→ v}〉〉r | s.

24

(Asym2) In this case, f = f1 where x :∈ f2, l = τ and f ′ = f1 where x :∈ f ′2 . By

the premise of the rule (Asym2), f2τ↪→ f ′2 . By encoding definition, 〈〈 f 〉〉r | s =

[r′, x] ( 〈〈 f1〉〉r | [k] ( 〈〈 f2〉〉r′ | r′?〈x〉.kill(k) ) ) | s. By induction, 〈〈 f2〉〉r′ | s′p •o b∅c w v

========⇒〈〈 f ′2〉〉r′ | s′ where s ≡ s′ | s′′. Thus, by rule (delpass), we can conclude that 〈〈 f 〉〉r |s

p •o b∅c w v========⇒ [r′, x] ( 〈〈 f1〉〉r | [k] ( 〈〈 f ′2〉〉r′ | r′?〈x〉.kill(k) ) ) | s ≡ 〈〈 f1 where x :∈

f ′2〉〉r | s.(Asym1) Similar to the previous case.(Asym3) In this case, f = f1 where x :∈ f2, l = τ and f ′ = f1 · {x 7→ v}. By the premise

of the rule (Asym3), f2!v↪→ f ′2 . By encoding definition, 〈〈 f 〉〉r | s = [r′, x] ( 〈〈 f1〉〉r |

[k] ( 〈〈 f2〉〉r′ | r′?〈x〉.kill(k) ) ) | s. By induction, 〈〈 f2〉〉r′ | s′r′C〈v〉

=====⇒ 〈〈 f ′2〉〉r′ | s′ wheres ≡ s′ | s′′. Then, by encoding definition and rule (delpass), s′′′ , [r′, x] ( 〈〈 f1〉〉r |[k] ( 〈〈 f ′2〉〉r′ | r′?〈x〉.kill(k) ) | r′!〈v〉 ) | s is a reduct of 〈〈 f 〉〉r | s. We can conclude that

s′′′r′ b∅c 〈x〉 〈v〉−−−−−−−−−→ [r′] ( 〈〈 f1 · {x 7→ v}〉〉r | [k] ( 〈〈 f ′2〉〉r′ | kill(k) ) ) | s †−−→ [r′] ( 〈〈 f1 · {x 7→

v}〉〉r | [k] 0 ) | s ≡ 〈〈 f1 · {x 7→ v}〉〉r | s.�

Lemma 1. Given an Orc expression f and a communication endpoint r, [[ f ]]rr!〈v〉−−−−9.

Proof: By a straightforward induction on the definition of the encoding.�

Theorem 2 (Soundness). Given an Orc expression f and a communication endpoint

r, [[ f ]]r ≡ 〈〈 f 〉〉r | sp •o b∅c w v−−−−−−−−→ s′ implies that there exists an Orc expression f ′ such that

fl↪→ f ′ and s′

α==⇒ 〈〈 f ′〉〉r | s, where α = r C 〈v〉 if l = !v, and α = (p′ •o′ b∅c w′ v′) if

l = τ.

Proof: The proof proceeds by induction on the definition of the encoding 〈〈 f 〉〉r.Base Step: We reason by case analysis on the non-inductive cases of the definition.

( f = 0) In this case 〈〈 f 〉〉r = 0 and s = 0. Since [[ f ]]r ≡ 0α−−9, we can trivially conculde.

( f = S (w)) In this case 〈〈 f 〉〉r = S !〈w, r〉 and s = ∗ [x, y] S ?〈x, y〉.y!〈v′〉. If w = zthen [[ f ]]r

α−−9, thus we can trivially conculde. If w = v then [[ f ]]r ≡ S !〈v, r〉 |s

S b∅c 〈x,y〉 〈v,r〉−−−−−−−−−−−→ r!〈v′〉 | s = s′. By rule (SiteCall) we have l =!v′ and f ′ = 0. Thus,

s′rC〈v′〉−−−−−→ 0 | s. Since 〈〈0〉〉r = 0, we can conclude.

( f = E(w)) Assuming E(x) , g, we have 〈〈E(w)〉〉r = [r′] (E!〈r, r′〉 | [z] r′?〈z〉.z!〈w〉)and s = ∗ [y′, z′] E?〈y′, z′〉.[r′′] (z′!〈r′′〉 | [x] (r′′?〈x〉 | 〈〈g〉〉y′ ) ). Then, [[ f ]]r

E b∅c 〈y′,z′〉 〈r,r′〉−−−−−−−−−−−−→ [r′] ([z] r′?〈z〉.z!〈w〉) | [r′′] (r′!r′′ | [x] (r′′?〈x〉 | 〈〈g〉〉r) ) | s = s′.

By rule (Def) we have l = τ and f ′ = g · {x 7→ w}. Moreover, s′r′ b∅c 〈z〉 〈r′′〉−−−−−−−−−−→

[r′′] (r′′!〈w〉 | [x] (r′′?〈x〉 | 〈〈g〉〉r) ) | s , s′′. If w = y, we directly conclude, since

s′′ = 〈〈g · {x 7→ y}〉〉r. If w = v, we can conclude by s′′r′′ b∅c 〈x〉 〈v〉−−−−−−−−−→ 〈〈g · {x 7→ v}〉〉r.

Inductive Step: We reason by case analysis on the inductive cases of the definition.

25

( f = f1 | f2) In this case 〈〈 f 〉〉r = 〈〈 f1〉〉r | 〈〈 f2〉〉r. By encoding definition, the transi-

tionp •o b∅c w v−−−−−−−−→ cannot be produced by a synchronization between 〈〈 f1〉〉r and 〈〈 f2〉〉r.

Then, we have only the following cases:

– 〈〈 f1〉〉r | sp •o b∅c w v−−−−−−−−→ s1.

By induction, f1l↪→ f ′1 and s1

α==⇒ 〈〈 f ′1〉〉r | s. By rule (Sym1), f

l↪→ f ′1 | f2 = f ′.

By rule (parpass) or (parcon f ), we can conclude that s′ ≡ s1 | 〈〈 f2〉〉rα

==⇒ 〈〈 f ′1〉〉r |s | 〈〈 f2〉〉r ≡ 〈〈 f ′〉〉r | s.

– 〈〈 f2〉〉r | sp •o b∅c w v−−−−−−−−→ s2.

Similar to the previous case.( f = f1 > x > f2) In this case 〈〈 f 〉〉r = [r′] (〈〈 f1〉〉r′ | ∗ [x] r′?〈x〉.〈〈 f2〉〉r). Lemma

1 implies that the inference of the transitionp •o b∅c w v−−−−−−−−→ derives from 〈〈 f1〉〉r′ |

sp •o b∅c w v−−−−−−−−→ s1. By induction, f1

l↪→ f ′1 and s1

α==⇒ 〈〈 f ′1〉〉r′ | s. We have two

cases:– l = τ.

By rule (Seq1), fτ↪→ f ′1 > x > f2. By rules (parcon f ) and (delpass), s′

p′ •o′ b∅c w′ v′===========⇒

[r′] (〈〈 f ′1〉〉r′ | ∗ [x] r′?〈x〉.〈〈 f2〉〉r) | s ≡ 〈〈 f ′1 > x > f2〉〉r | s.– l =!v.

By rule (Seq2), f!v↪→ ( f ′1 > x > f2) | f2 · {x 7→ v}. By rules (com) and (delpass),

s′r′ b∅c 〈x〉 〈v〉

=========⇒ [r′] (〈〈 f ′1〉〉r′ | ∗ [x] r′?〈x〉.〈〈 f2〉〉r) | 〈〈 f2 · {x 7→ v}〉〉r | s ≡ 〈〈( f ′1 >x > f2) | f2 · {x 7→ v}〉〉r | s.

( f = f1 where x :∈ f2) In this case 〈〈 f 〉〉r = [r′, x] (〈〈 f1〉〉r | [k] (〈〈 f2〉〉r′ | r′?〈x〉.kill(k) ) ).By Lemma 1, we have two cases:

– 〈〈 f1〉〉r | sp •o b∅c w v−−−−−−−−→ s1.

By induction, f1l↪→ f ′1 and s1

α==⇒ 〈〈 f ′1〉〉r′ | s. By rule (Asym1), f

l↪→

f ′1 where x :∈ f2. By rules (delpass) and (parcon f ), s′α

==⇒ [r′, x] ( 〈〈 f ′1〉〉r |[k] ( 〈〈 f2〉〉r′ | r′?〈x〉.kill(k) ) ) | s ≡ 〈〈 f ′1 where x :∈ f2〉〉r.

– 〈〈 f2〉〉r′ | sp •o b∅c w v−−−−−−−−→ s2.

By induction, f2l↪→ f ′2 and s2

α==⇒ 〈〈 f ′2〉〉r′ | s. We have two cases:

• α = p′ •o′ b∅c w′ v′.Similar to the previous case.

• α = r′!〈v〉.By rule (Asym3), f

τ↪→ f1 · {x 7→ v}. By rules (com), (parcon f ) and (delpass),

s′r′ b∅c 〈x〉 〈v〉

=========⇒ 〈〈 f1 · {x 7→ v}〉〉r | [k] ( 〈〈 f ′2 · {x 7→ v}〉〉r′ | kill(k) ) = s′′. Then,

by rules (kill), (parkill), (delkill) and (parpass), s′′†−−→ 〈〈 f1 · {x 7→ v}〉〉r.

( f = g · {x 7→ y}) In this case 〈〈 f 〉〉r = [r′] (r′!〈y〉 | [x] (r′?〈x〉 | 〈〈g〉〉r) ). Since

r′!〈y〉 α−−9, we have 〈〈g〉〉r | sp •o b∅c w v−−−−−−−−→ s′′. By induction, g

l↪→ g′ and s′′

α==⇒

〈〈g′〉〉r | s. By rules (parcon f ) and (delpass), we can conclude that s′α

==⇒ [r′] (r′!〈y〉 |[x] (r′?〈x〉 | 〈〈g′〉〉r) ) | s ≡ 〈〈g′ · {x 7→ y}〉〉r | s.

�

26

n ::= a :: C (nodes)C ::= ∗s | m � s (components)

| 〈a, o, u〉 | C | Cm ::= ∅ | {p = u} | m ∪ m (correl. const.)s ::= (services)

0 (null)| exit (exit)| ass (w, e) (assign)| inv (r, o, w) (invoke)| rec (r, o, w) (receive)| if (e) then {s} else {s} (switch)| s; s (sequence)| s | s (flow)| ∑

i∈I rec (ri, oi, wi) ; si (pick)| A(w) (call)

Table 12. - syntax

5.2 Encoding -

The syntax of (a simplified version of) -, given in Table 12, is parameterizedwith respect to the following syntactic sets: properties (sorts of late bound constantsstoring some relevant values within service instances, ranged over by p), values (basicvalues and addresses, ranged over by u), partner links (variables storing addresses usedto identify service partners within an interaction), operation parameters (basic vari-ables, partner links and properties, ranged over by w), and service identifiers (rangedover by A). Notationally, we will use a to range over addresses and r to range overaddresses and partner links.

- permits to model the interactions among web service instances in anetwork context. A network of services is a finite set of nodes. Nodes, written as a :: C,are uniquely identified by an address a and host components C. Components C may beservice specifications, instances or requests. The behavioural specification of a services is written ∗s, while m � s′ represents a service instance that behaves according tos′ and whose properties evaluate according to the (possibly empty) set m of correlationconstraints. A correlation constraint is a pair, written p = u, recording the value uassigned to the property p. Properties are used to store values that are important toidentify service instances. A service request 〈a, o, u〉 represents an operation invocationthat must still be processed and contains the invoker address a, the operation name oand the data u for operation execution.

Services are structured activities built from basic activities, i.e. instance forcedtermination exit, assignment ass ( , ), service invocation inv ( , , ) and ser-vice request processing rec ( , , ), by exploiting operators for conditional choiceif ( ) then { } else { } (switch), sequential composition ; (sequence), parallel com-position | (flow), external choice

∑i∈I rec ( , , ) ; (pick) and service call A(w) (of

course, we assume that every service identifier A has a unique definition of the formA(w) de f

= s).

27

〈〈a :: C〉〉 = 〈〈C〉〉a

〈〈∗s〉〉a = ∗ [ka,V(s)] 〈〈s〉〉a

〈〈{ p = u} � s〉〉a = [ka,V(s)] 〈〈s · { p 7→ u}〉〉a

〈〈〈a′, o, u〉〉〉a = {|a • o!〈a′, u〉|}

〈〈0〉〉a = 0

〈〈exit〉〉a = kill(ka)

〈〈ass (w, e)〉〉a = [w = e]

〈〈inv (r, o, w)〉〉a = r • o!〈a, w〉

〈〈rec (r, o, w)〉〉a = a • o?〈r, w〉

Table 13. - encoding

The encoding from - to COWS, denoted by 〈〈·〉〉, is shown in Table 13.We only show the relevant cases; for example, the encodings of structural activities arequite standard and, hence, omitted. Both variables and properties of - areencoded as COWS variables, while the encoding of a net, i.e. a finite set of nodes, isthe parallel composition of the encodings of its nodes. The encoding of a node is givenin term of the encoding of the hosted component parameterized by the address of thenode.

This auxiliary parameterized encoding 〈〈·〉〉a is defined inductively over the syntax ofservices. The parameter a is used, e.g., both as the partner name to which a given requestmust be sent and to refer the killer label ka used to identify each service instance. Servicespecifications are encoded as COWS persistent services, by exploiting the replicationoperator. The fact that variables are global to service instances is rendered through theoutermost delimitation [ka,V(s)] , where V(s) is the set of free variables and propertiesof s. Partner links used to identify service partners within an interaction are translatedby exploiting the address of the hosting node. Finally, the effect of executing exit insidea service instance hosted at a is achieved by forcing termination of the COWS termresulting from the encoding the instance and identified by the label ka.

Of course, as in Section 5.1, we could prove that there is a formal correspondence,based on the operational semantics, between - nets and the COWS servicesresulting from their encoding.

6 Timed extension of COWS

We present here an extension of COWS that permits modeling timed activities. Specif-ically, we consider the wait activity of WS-BPEL which allows a service to wait for a

28

M ::= 0 | {s}t | [n]M | M | M (machines)g ::= . . . | � δ.s (guarded choice)

Table 14. Timed COWS

given time slot. For the sake of simplicity, we don’t deal with attribute until, that permitsto delay the executing service until time reaches a given value.

The extended syntax of COWS, given in Table 14, is now parameterized also by aset of time values (ranged over by t, t′, . . . ) and a set of time slots (ranged over by δ,δ′,. . . ). The syntax includes a new category, that of machines (as in [20]). A machine {s}thas its own clock, that is not synchronized with the clock of other machines (namely,time progresses asynchronously between different machines). Guards are extended withthe timed activity� δ, that specifies the time slot δ the executing service has to wait for.Consequently, the choice construct can now be guarded both by reception of messagesand by expiration of timeouts, like WS-BPEL pick activity. We assume that evaluationof expressions and execution of basic activities, except for � δ, are instantaneous, i.e.they don’t consume time units.

To define the operational semantics of the extended language, firstly we extend thestructural congruence of Section 2 with the abelian monoid laws for parallel composi-tion over machines, and the following laws:

{[n] s}t ≡ [n] {s}t {s}t ≡ {s′}t if s ≡ s′

[n] 0 ≡ 0 [n] [m]M ≡ [m] [n]MM | [n]N ≡ [n] (M | N) if n < fd(M)

The first law is used to extrude a name outside a machine, while the second one lifts tomachines the structural congruence defined on services. The remaining laws are stan-dard.

Secondly, the labelled transition relationα−−→ over services now models also time

elapsing, i.e. α can be either α or δ, and is obtained by adding the rules shown in theupper part of Table 15 to those in Table 4. Indeed, due to our assumptions on the modelof time used, the rules for kill, invoke, receive, communication, parallel composition,protection and delimitation are those in Table 4; instead, in rule (cong), α must be re-placed by α to also consider time elapsing. Let us briefly comment on the new rules.Rule (waitelaps) permits updating the argument δ of � until the timeout expires, this isdenoted by label † of rule (waittout). Time can elapse while waiting on a receive activity,rule (recelaps), and cannot make a choice within a pick activity, rule (pickelaps). Instead, achoice can be done when a timeout occurs; in such a case rule (waittout) generates a †and rule (sum) in Table 4 permits to make the choice (thus ‘killing’ the discarded alter-native activities). Rule (parsync) says that time elapses equally for all services which runin parallel within the same machine The remaining rules permit time elapsing withininvoke, delimitation, protection and replication constructs.

Finally, we define a reduction relation −→ over machines through the rules shown inthe lower part of Table 15. Rules (locelaps) and (locact) model taking place of timed andcomputational activities, respectively, within a machine. Rule (parasync) says that timeelapses asynchronously between different machines (indeed, N and, then, its clocks,

29

� 0.s†−→ s (waittout)

p • o?w.sδ−→ p • o?w.s (recelaps) p • o!e

δ−→ p • o!e (invelaps)

0 < δ′ 6 δ

� δ.sδ′−−→� δ−δ′ .s

(waitelaps)s

δ−→ s′

{|s|} δ−→ {|s′|}(protelaps)

g1δ−→ g′1 g2

δ−→ g′2

g1 + g2δ−→ g′1 + g′2

(pickelaps)s

δ−→ s′

[d] sδ−→ [d] s′

(scopeelaps)

s1δ−→ s′1 s2

δ−→ s′2

s1 | s2δ−→ s′1 | s′2

(parsync)s

δ−→ s′

∗ sδ−→ ∗ s′

(replelaps)

sδ−→ s′

{s}t −→ {s′}t+δ(locelaps)

sα−−→ s′ α ∈ {†, p •o b∅c w v}

{s}t −→ {s′}t(locact)

M −→ M′

M | N −→ M′ | N(parasync)

M ≡ M′ M′ −→ N′ N′ ≡ N(congM)

M −→ N

M −→ M′

[n]M −→ [n]M′(res)

s1(p • o)Cv−−−−−−→ s′1 s2

(p • o)Bw−−−−−−−→ s′2 M(w, v) = σ

fv(w) = u noc(A[[[u] s2]], p • o, w, v)(comM)

{s1}t1 | {A[[[u] s2]]}t2 −→ {s′1}t1 | {A[[s′2 · σ]]}t2

Table 15. Timed COWS operational semantics (additional rules)

remains unchanged after the transition), while rule (congM) says that structurally con-gruent machines have the same behaviour. Rule (res) deals with restriction of names.Rule (comM), where fv(s) are the free variables of s, enables interaction between ser-vices executing over different machines. It combines the effects of rules (delsub) and(com) in Table 4. For the interaction to take place, it is necessary to single out on thereceiving machine the component performing the reception and its executing context,by also highlighting the delimitations for the input variables. This way, the communica-tion effect can be immediately applied to the continuation of the receiving service. Thelast premise ensures that, in case of multiple start activities, the message is routed to thecorrelated service instance rather than triggering a new instantiation. In order to com-municate a private name between machines, it is necessary to extrude the name outsidethe sending machine and to extend its scope to the receiving machine, by applying rule(congM), then the communication can take place, by applying rules (com) and (res).

Of course, in this new setting, computations are defined as sequences of (connected)reductions from a given parallel composition of machines.

30

We end this section with two simple examples. The first one provides a sort of clockservice that is set to send a message “tick” along m every 10 time units.

[n] ( n!〈〉 | ∗ n?〈〉 .� 10 . ( m!〈“tick”〉 | n!〈〉 ) )

Notice that, however, because invoke activities are executed lazily, it is only guaranteedthat at least 10 time units pass between two consecutive emissions of message “tick”.

The second example is a variant of the rps service of Section 4.1 that exploitsthe fact that the choice construct can now be guarded both by receive activities andby timed activities (like the pick activity of WS-BPEL). Essentially, an instance ofservice t rps created because of reception of the first throw of a challenge, waits forthe reception of the corresponding second throw for at most 30 time units. If this throwarrives within the deadline, the instance behaves as usual. Otherwise, when the timeoutexpires, the instance declares the sender of the first throw as the winner of the challengeand terminates.

t rps , ∗ [xchamp res, xchall res, xid, xthr 1, xthr 2, xwin, k]( ( pchamp • othrow?〈xchamp res, xid, xthr 1〉.

( pchall • othrow?〈xchall res, xid, xthr 2〉.( xchamp res • owin!〈xid, xwin〉 | xchall res • owin!〈xid, xwin〉 )

+

� 30 . ( {|xchamp res • owin!〈xid, xchamp res〉|} | kill(k) ) )+

pchall • othrow?〈xchall res, xid, xthr 2〉.( pchamp • othrow?〈xchamp res, xid, xthr 1〉.

( xchamp res • owin!〈xid, xwin〉 | xchall res • owin!〈xid, xwin〉 )+

� 30 . ( {|xchall res • owin!〈xid, xchall res〉|} | kill(k) ) ) )| Assign )

7 Concluding remarks

We have introduced COWS, a formalism for specifying and combining services, whilemodelling their dynamic behaviour (i.e. it deals with service orchestration rather thanchoreography). COWS borrows many constructs from well-known process calculi, e.g.π-calculus, update calculus, StACi, and Lπ, but combines them in an original way, thusbeing different from all existing calculi. COWS permits modelling different and typicalaspects of (web) services technologies, such as multiple start activities, receive con-flicts, routing of correlated messages, service instances and interactions among them.We have also presented an extension of the basic language with timed constructs.

The correlation mechanism was first exploited in [33], that, however, only considersinteraction among different instances of a single business process. Instead, to connectthe interaction protocols of clients and of the respective service instances, the calculus

31

introduced in [3], and called SCC, relies on explicit modelling of sessions and their dy-namic creation (that exploits the mechanism of private names of π-calculus). Interactionsessions are not explicitly modelled in COWS, instead they can be identified by tracingall those exchanged messages that are correlated each other through their same contents(as in [14]). We believe that the mechanism based on correlation sets (also used by WS-BPEL), that exploits business data and communication protocol headers to correlatedifferent interactions, is more robust and fits the loosely coupled world of Web Servicesbetter than that based on explicit session references. Another notable difference withSCC is that in COWS services are not necessarily persistent.

Many works put forward enrichments of some well-known process calculus withconstructs inspired by those of WS-BPEL. The most of them deal with issues of webtransactions such as interruptible processes, failure handlers and time. This is, for ex-ample, the case of [20, 21, 24, 25] that present timed and untimed extensions of theπ-calculus, called webπ and webπ∞, tailored to study a simplified version of the scopeconstruct of WS-BPEL. Other proposals on the formalization of flow compensation are[5, 4] that give a more compact and closer description of the Sagas mechanism [13] fordealing with long running transactions.

We have focused on service orchestration rather than on service choreography. In[6, 7] both aspects are studied. Other approaches are based on the use of schema lan-guages [12] and Petri nets [15]. In [19] a sort of distributed input-guarded choice ofjoin patterns, called smooth orchestrators, gives a simple and effective representationof synchronization constructs. The work closest to ours is [22], where - isintroduced to formalize the semantics of WS-BPEL. COWS represents a more founda-tional formalism than - in that it does not rely on explicit notions of locationand state, it is more manageable (e.g. has a simpler operational semantics) and, at least,equally expressive (as the encoding of - in COWS shows, Section 5.2).

As a future work, we plan to continue our programme to lay rigorous methodolog-ical foundations for specification and validation of service oriented computing mid-dlewares and applications by developing more powerful type systems. For example,session types and behavioural types are emerging as powerful tools for taking into ac-count behavioural and non-functional properties of computing systems and, in case ofservices, could permit to express and enforce policies for, e.g., disciplining resourcesusage, constraining the sequences of messages accepted by services, ensuring serviceinteroperability and compositionality, guaranteeing absence of deadlock in service com-position, checking that interaction obeys a given protocol. Some of the studies de-veloped for π-calculus and other standard process calculi (e.g. [10, 34, 17, 16, 18]) arepromising starting points, but they need non trivial adaptations to deal with all COWSpeculiar features. For example, one of the major problems we envisage concerns thetreatment of killing and protection activities, that are not commonly used in processcalculi.

Another promising approach that we plan to investigate is the definition of be-havioural equivalences that would provide a precise account of what ‘observable be-haviour’ means for a service. Pragmatically, they could provide a means to establishformal correspondences between different views (abstraction levels) of a service, e.g.the contract it has to honour and its true implementation.

32

References

1. A. Alves, A. Arkin, S. Askary, B. Bloch, F. Curbera, M. Ford, Y. Goland, A. Guızar,N. Kartha, C.K. Liu, R. Khalaf, D. Konig, M. Marin, V. Mehta, S. Thatte, D. van der Rijn,P. Yendluri, and A. Yiu. Web Services Business Process Execution Language Version 2.0.Technical report, WS-BPEL TC OASIS, August 2006. http://www.oasis-open.org/.

2. L. Bocchi, C. Laneve, and G. Zavattaro. A calculus for long-running transactions. InFMOODS, volume 2884 of LNCS, pages 124–138. Springer, 2003.

3. M. Boreale, R. Bruni, L. Caires, R. De Nicola, I. Lanese, M. Loreti, F. Martins, U. Montanari,A. Ravara, D. Sangiorgi, V. T. Vasconcelos, and G. Zavattaro. SCC: a Service CenteredCalculus. In WS-FM, volume 4184 of LNCS, pages 38–57. Springer, 2006.

4. R. Bruni, M. Butler, C. Ferreira, T. Hoare, H. Melgratti, and U. Montanari. Comparing twoapproaches to compensable flow composition. In CONCUR, volume 3653 of LNCS, pages383–397. Springer, 2005.

5. R. Bruni, H.C. Melgratti, and U. Montanari. Theoretical foundations for compensations inflow composition languages. In POPL, pages 209–220. ACM, 2005.

6. N. Busi, R. Gorrieri, C. Guidi, R. Lucchi, and G. Zavattaro. Choreography and orchestration:A synergic approach for system design. In ICSOC, volume 3826 of LNCS, pages 228–240.Springer, 2005.

7. N. Busi, R. Gorrieri, C. Guidi, R. Lucchi, and G. Zavattaro. Choreography and orchestrationconformance for system design. In COORDINATION, volume 4038 of LNCS, pages 63–81.Springer, 2006.

8. M.J. Butler and C. Ferreira. An operational semantics for StAC, a language for modellinglong-running business transactions. In COORDINATION, volume 2949 of LNCS, pages 87–104. Springer, 2004.

9. M.J. Butler, C.A.R. Hoare, and C. Ferreira. A trace semantics for long-running transactions.In 25 Years Communicating Sequential Processes, volume 3525 of LNCS, pages 133–150.Springer, 2005.

10. M. Carbone, K. Honda, and N. Yoshida. A calculus of global interaction based on sessiontypes. In DCM’06, 2006. To appear as ENTCS.

11. M. Carbone and S. Maffeis. On the expressive power of polyadic synchronisation in π-calculus. Nordic J. of Computing, 10(2):70–98, 2003.

12. S. Carpineti and C. Laneve. A basic contract language for web services. In ESOP, volume3924 of LNCS, pages 197–213. Springer, 2006.

13. H. Garcia-Molina and K. Salem. Sagas. In SIGMOD, pages 249–259. ACM Press, 1987.14. C. Guidi, R. Lucchi, R. Gorrieri, N. Busi, and G. Zavattaro. SOCK: a calculus for service

oriented computing. In ICSOC, volume 4294 of LNCS, pages 327–338. Springer, 2006.15. S. Hinz, K. Schmidt, and C. Stahl. Transforming BPEL to petri nets. In Business Process

Management, volume 3649, pages 220–235, 2005.16. A. Igarashi and N. Kobayashi. A generic type system for the pi-calculus. Theor. Comput.

Sci., 311(1-3):121–163, 2004.17. N. Kobayashi. Type systems for concurrent programs. In 10th Anniversary Colloquium of

UNU/IIST, volume 2757 of LNCS, pages 439–453. Springer, 2003.18. N. Kobayashi, K. Suenaga, and L. Wischik. Resource usage analysis for the π-calculus. In

VMCAI, volume 3855 of LNCS, pages 298–312. Springer, 2006.19. C. Laneve and L. Padovani. Smooth orchestrators. In FoSSaCS, volume 3921 of LNCS,

pages 32–46. Springer, 2006.20. C. Laneve and G. Zavattaro. Foundations of web transactions. In FoSSaCS, volume 3441 of

LNCS, pages 282–298. Springer, 2005.

33

21. C. Laneve and G. Zavattaro. web-pi at work. In TGC, volume 3705 of LNCS, pages 182–194.Springer, 2005.

22. A. Lapadula, R. Pugliese, and F. Tiezzi. A WSDL-based type system for WS-BPEL. InCOORDINATION, volume 4038 of LNCS, pages 145–163. Springer, 2006.

23. A. Lapadula, R. Pugliese, and F. Tiezzi. A WSDL-based type system for WS-BPEL (full ver-sion). Technical report, Dipartimento di Sistemi e Informatica, Univ. Firenze, 2006. Avail-able at: http://www.dsi.unifi.it/∼pugliese/ DOWNLOAD/wsc-full.ps.

24. M. Mazzara and I. Lanese. Towards a unifying theory for web services composition. InWS-FM, volume 4184 of LNCS, pages 257–272. Springer, 2006.

25. M. Mazzara and R. Lucchi. A pi-calculus based semantics for WS-BPEL. Journal of Logicand Algebraic Programming, 70(1):96–118, 2006.

26. M. Merro and D. Sangiorgi. On asynchrony in name-passing calculi. Mathematical Struc-tures in Computer Science, 14(5):715–767, 2004.

27. R. Milner. Communication and concurrency. Prentice-Hall, 1989.28. R. Milner, J. Parrow, and D. Walker. A calculus of mobile processes, I and II. Inf. Comput.,

100(1):1–40, 41–77, 1992.29. J. Misra and W. R. Cook. Computation orchestration: A basis for wide-area computing.

Journal of Software and Systems Modeling, May 2006. Published online.30. J. Parrow and B. Victor. The update calculus. In AMAST, volume 1349 of LNCS, pages

409–423. Springer, 1997.31. J. Parrow and B. Victor. The fusion calculus: Expressiveness and symmetry in mobile pro-

cesses. In Logic in Computer Science, pages 176–185, 1998.32. W.M.P. van der Aalst, A.H.M. ter Hofstede, B. Kiepuszewski, and A.P. Barros. Workflow

patterns. Distributed and Parallel Databases, 14(1):5–51, 2003.33. M. Viroli. Towards a formal foundational to orchestration languages. ENTCS, 105:51–71,

2004.34. N. Yoshida and V. T. Vasconcelos. Language primitives and type discipline for structured

communication-based programming revisited: Two systems for higher-order session com-munication. In 1st International Workshop on Security and Rewriting Techniques, ENTCS,2006.

34