Regulating data exchange in service orientedapplications ?

Alessandro Lapadula, Rosario Pugliese and Francesco Tiezzi

Dipartimento di Sistemi e Informatica Universita degli Studi di Firenze

Abstract. We define a type system for COWS, a formalism for specifying andcombining services, while modelling their dynamic behaviour. Our types permitto express policies constraining data exchanges in terms of sets of service part-ner names attachable to each single datum. Service programmers explicitly writeonly the annotations necessary to specify the wanted policies for communicabledata, while a type inference system (statically) derives the minimal additionalannotations that ensure consistency of services initial configuration. Then, thelanguage dynamic semantics only performs very simple checks to authorize orblock communication. We prove that the type system and the operational seman-tics are sound. As a consequence, we have the following data protection property:services always comply with the policies regulating the exchange of data amonginteracting services. We illustrate our approach through a simplified but realisticscenario for a service-based electronic marketplace, and an automotive scenariostudied in the SENSORIA project.

1 Introduction

Service-oriented computing (SOC) is an emerging paradigm for developing looselycoupled, interoperable, evolvable applications which exploits the pervasiveness of theInternet and its related technologies. SOC systems deliver application functionality asservices to either end-user applications or other services. Current software engineer-ing technologies for SOC, however, remain at the descriptive level and do not supportanalytical tools for checking that SOC applications enjoy desirable properties and donot manifest unexpected behaviors. To reason about and guarantee such properties, onemust also be able to specify and enforce some security policies. Indeed, programmingservice oriented middlewares and the applications running on them without puttingdata at risk or compromising robustness of the whole platform requires services to bechecked and their resource usage to be strictly put in relation to their capabilities.

Great efforts have been recently devoted to embed security mechanisms within stan-dard programming features (some of these techniques are surveyed in [28]). Language-based mechanisms are a scalable way to provide evidence that a large number of ap-plications enjoy some given properties. For example, by using type systems, one canprove the type soundness of the language as a whole, from which it follows that allwell-typed applications do comply with the policies stated by their types. To facilitatethe task of designing such a sound language for SOC, one can initially focus only on

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

the mechanisms at the basis of SOC. Afterwards, this core formalism could hopefullybe expanded into a full-fledged language by adding the high level, often redundant,constructs typical of effective programming languages.

Many researchers have hence put forward exploiting the studies on process calculi, acornerstone of current foundational research on specification and analysis of concurrent,distributed and mobile systems through mathematical — mainly algebraic and logical— tools. Indeed, due to their algebraic nature, process calculi convey in a distilled formthe compositional programming style of SOC. This is witnessed by the several processcalculi like formalisms for SOC proposed in the literature by now (see, e.g., [2, 29,11, 5, 18, 21, 13, 22]). However, although capable of describing complex systems andapplications, such proposals still lack those reasoning mechanisms and analytical tools,e.g. type systems and behavioural equivalences, that process calculi usually hand down.

In this paper, we tailor the type-based approach for protecting data in global comput-ing applications put forward in [9] to COWS, a formalism for specifying service-basedapplications that we introduce in [22]. We thus define a typed variant of COWS that per-mits expressing and forcing policies regulating the exchange of data among interactingservices. Programmers can indeed settle the partners usable to exchange any given da-tum (and, then, the services that can share it), thus avoiding the datum be accessed (byunwanted services) through unauthorized partners. The language (static and dynamic)semantics then guarantees that well-typed services always comply with the constraintsexpressed by the type associated to each single datum.

The rest of the paper is organized as follows. Section 2 introduces syntax, typeinference and operational semantics of (our typed variant of) COWS, while Section 3presents our main results. Section 4 demonstrates our approach through a simplified butrealistic scenario for a service-based electronic marketplace, and an automotive scenariostudied in the SENSORIA project. Finally, Section 5 touches upon comparisons withmore strictly related work and 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.We refer the interested reader to [22] for further motivations on the design of COWS,for many examples illustrating its peculiarities and expressiveness, and for comparisonswith other process-based and orchestration formalisms.

The design of COWS has been influenced by the principles underlying WS-BPEL [25], the de facto standard language for orchestration of web services. Similarlyto WS-BPEL, COWS supports service instances with shared states, 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 [20], Sect. 3). The design of COWS has also taken advantage of previouswork on process calculi. In fact, it combines in an original way constructs and fea-tures borrowed from well-known process calculi, e.g. asynchronous communication,

2

polyadic synchronization, pattern matching, protection, delimited receiving and killingactivities, while however resulting different from any of them.

The basic elements of COWS are partners and operations. They can be combinedto designate communication endpoints and can be exchanged in communication, butdynamically received names cannot form endpoints used to receive further invocations.Endpoints naming mechanism is very flexible, e.g. it permits identifying a same serviceby means of different logic names and separately dealing with the names composingan endpoint. This is, e.g., exploited in 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.

COWS computational entities are called services. Typically, a service creates onespecific instance to serve each received request. Instances may run concurrently. Eachinstance can be composed of concurrent threads that may offer a choice among alterna-tive receive activities. Services could be able to receive multiple messages in a staticallyunpredictable order and in such a way that the first incoming message triggers creationof a service instance which subsequent messages are routed to. Pattern matching is themechanism used for correlating messages logically forming a same interaction ‘ses-sion’ by means of their same contents. It permits locating those data that are importantto identify service instances and is flexible enough for allowing a single message to par-ticipate in multiple interaction sessions, each identified by separate correlation values.

Inter-service communication give rise to substitutions of variables with values.However, to enable concurrent instances or threads within an instance to share the state(or part of it), receive activities in COWS do not bind variables. The range of applicationof the substitution generated by a communication is then regulated by the delimitationoperator, that is the only binder of the calculus. Delimitation, additionally, can be usedto generate fresh private names (as the restriction operator of the π-calculus) and to de-limit the field of action of the kill activity, a powerful orchestration construct that canbe used to force termination of whole service instances. Sensitive code can however beprotected from the effect of a forced termination by using the protection operator.

The type system we present in this paper permits to express and enforce policies forregulating the exchange of data among services. To implement such policies, program-mers can annotate data with sets of partner names characterizing the services authorizedto use and exchange them; these sets are called regions. The language operational se-mantics uses these annotations to guarantee that computations proceed according tothem. This property, called soundness, can be stated as follows

A service s is sound if, for any datum v in s associated to region r and for allevolutions of s, it holds that v can be exchanged only by using partners in r.

To facilitate the task of decorating COWS terms with type annotations, we let the typesystem partially infer such annotations a la ML: service programmers explicitly writeonly the annotations necessary to specify the wanted policies for communicable data;then, a type inference system (statically) performs some coherence checks (e.g. the part-ner used by an invoke must belong to the regions of all data occurring in the argumentof the activity) and derives the minimal region annotations for variable declarations thatensure consistency of services initial configuration. This allows us to define an opera-tional semantics with types [12] which is simpler than a full-fledged typed operational

3

Table 1. COWS syntax

s ::= kill(k) | u • u′!{e(x)}r | g | s | s | {|s|} | [d] s | ∗ s (services)

g ::= 0 | p • o?w.s | g + g (receive-guarded choice)

semantics, because it only performs simple checks (i.e. subset inclusion) using regionannotations to authorize or block transitions. Our main results prove that the type sys-tem and the operational semantics are sound. As a consequence, we have that servicesalways comply with the constraints expressed by the type of each single datum.

Syntax. COWS syntax is parameterized by three countable and pairwise 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 isleft unspecified; however, we assume that it includes the set of names, ranged over by n,m, . . . , mainly used to represent partners and operations. COWS is also parameterizedby a set of expressions, ranged over by e, whose exact syntax is deliberately omitted;we just assume that expressions contain, at least, values and variables. Notably, killerlabels are not (communicable) values. Notationally, we prefer letters p, p′, . . . when wewant to stress the use of a name as a partner, o, o′, . . . when we want to stress the useof a name as an operation. We will use w to range over values and variables, u to rangeover names and variables, and d to range over killer labels, names and variables.

Regions can be either finite subsets of partners and variables or the distinct element> (denoting the universe of partners). The set of all regions, ranged over by r, is partiallyordered by the subset inclusion relation ⊆, and has > as top element.

Notation · stands for tuples of objects, e.g. x is a compact notation for denotingthe tuple of variables 〈x1, . . . , xn〉 (with n ≥ 0). We assume that variables in the sametuple are pairwise distinct. All notations shall extend to tuples component-wise. Anexpression e tagged with region r will be written as {e}r; an untagged e will stand for{e}>. We will write e(x) to make explicit all the variables x occurring in e (we stillwrite e when this information is not needed), and e (resp. r) to denote the tuple of theexpressions (resp. regions) occurring in {e}r.

We will call raw services those COWS services written according to the syntax inTable 1. Intuitively, raw services only contain those region annotations that implementthe policies for data exchange settled by the programmers. Services are structured ac-tivities built from basic activities, i.e. the empty activity 0, the kill activity kill( ) , theinvoke activity • ! and the receive activity • ? , by means of (receive) prefixing. , guarded choice + , parallel composition | , protection {| |} , delimitation [ ]

and replication ∗ . Notably, as in the Lπ [24], communication endpoints of receiveactivities are identified statically because their syntax only allows using names and notvariables. We adopt the following conventions about the operators precedence: monadicoperators bind more tightly than parallel composition, and prefixing more tightly thanchoice. We shall omit a trailing 0 and use [d1, . . . , dn] s to denote [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) (resp. bd(t)) the set of names, variables and killer labels that occur free (resp.

4

Table 2. Type inference system

Γ ` 0 � Γ ` 0 (t-nil) Γ ` kill(k) � Γ ` kill(k) (t-kill)

∀ r′ ∈ {ri}i∈{1,..,n} u1 ∈ r′(t-inv)

Γ ` u1 • u2!〈{e1(y1)}r1 , . . . , {en(yn)}rn 〉 �(Γ + {x : r1}x∈y1 + . . . + {x : rn}x∈yn ) ` u1 • u2!〈{e1(y1)}r1 , . . . , {en(yn)}rn 〉

Γ + {x : {p}}x∈fv(w) ` s � Γ′ ` s′(t-rec)

Γ ` p • o?w.s � Γ′ ` p • o?w.s′

Γ ` g1 � Γ1 ` g′1 Γ ` g2 � Γ2 ` g′2(t-sum)

Γ ` g1 + g2 � Γ1 + Γ2 ` g′1 + g′2

Γ ` s � Γ′ ` s′(t-prot)

Γ ` {|s|} � Γ′ ` {|s′|}Γ ` s � Γ′ ` s′

(t-repl)Γ ` ∗ s � Γ′ ` ∗ s′

Γ ` s � Γ′ ` s′ n < reg(Γ′)(t-delname)

Γ ` [n] s � Γ′ ` [n] s′

Γ ` s � Γ′ ` s′(t-dellab)

Γ ` [k] s � Γ′ ` [k] s′

Γ, {x : ∅} ` s � Γ′, {x : r} ` s′ x < reg(Γ′)(t-delvar)

Γ ` [x] s � Γ′ ` [{x}r−{x}] s′

Γ ` s1 � Γ1 ` s′1 Γ ` s2 � Γ2 ` s′2(t-par)

Γ ` s1 | s2 � Γ1 + Γ2 ` s′1 | s′2

bound) in a term t, by fv(t) (resp. bv(t)) the set of free (resp. bound) variables in t,and by fk(t) the set of free killer labels in t. Two terms are alpha-equivalent if one canbe obtained from the other by consistently renaming bound names/variables/labels. Asusual, we identify terms up to alpha-equivalence. For simplicity sake, in the sequel weassume that bound variables in services are pairwise distinct (of course, this conditionis not restrictive and can always be fulfilled by possibly using alpha-conversion).

A type inference system. The annotations put by the type inference are written as su-perscripts, to better distinguish them from those put by the programmers. Thus, thesyntax of variable delimitation becomes [{x}r] s, which means that the datum that dy-namically will replace x will be used at most by the partners in r. Typed COWS servicesare then generated by the syntax in Table 1 where, differently from the previous section,d ranges over killer labels, names and annotated variables as {x}r. Notably, types maydepend on partner variables, i.e. on parameters of receiving activities; during compu-tation, they are therefore affected by application of substitutions that replace partnervariables with partner names. We assume that the region of a partner name always con-tains, at least implicitly, such partner.

The type inference system is presented in Table 2. Typing judgements are writtenΓ ` s � Γ′ ` s′, where the type environment Γ is a finite function from variables

5

to regions such that fv(s) ⊆ dom(Γ) and bv(s) ∩ dom(Γ) = ∅ (the same holds for Γ′

and s′). Type environments are written as sets of pairs of the form x : r, where x is apartner variable and r is its assumed region annotation. The domain of an environmentis defined as usual: dom(∅) = ∅ and dom(Γ, {x : r}) = dom(Γ) ∪ {x}, where ‘,’ denotesunion between environments with disjoint domains. The region of Γ is the union of theregions in Γ, i.e. reg(∅) = ∅ and reg(Γ, {x : r}) = r ∪ reg(Γ). We will write Γ + Γ′ todenote the environment obtained by extending Γ with Γ′; + is inductively defined by

Γ + ∅ = Γ

Γ + {x : r} =

{Γ′, {x : r ∪ r′} if Γ = Γ′, {x : r′}Γ, {x : r} otherwise

Γ + ({x : r}, Γ′) = (Γ + {x : r}) + Γ′

Hence, the judgement ∅ ` s � ∅ ` s′ can be derived only if s is a closed rawservice (because the initial environment is empty); if it is derivable, then s′ is the typedservice obtained by decorating s with the region annotations describing the use of eachvariable of s in its scope. Type inference determines such regions by considering theinvoking and receiving partners where the variables occur.

We now comment on the most significant typing rules. Rule (t-inv) checks if theinvoked partner u1 belongs to the regions of the communicated data. If it succeeds,the type environment Γ is extended by associating a proper region to each variableused in the expressions argument of the invoke activity. Rule (t-rec) tries to type s inthe type environment Γ extended by adding the receiving partner to the regions of thevariables in w. Rules (t-sum) and (t-par) yield the same typing; this is due to the sharingof variables. For instance, service [x] (p • o?〈x〉 | p′ • o′!〈{x}r〉) with p′ ∈ r is annotatedas [{x}r′] (p • o?〈x〉 | p′ • o′!〈{x}r〉) with r′ = ({p} ∪ r − {x}). In rule (t-delname), premisen < reg(Γ′) prevents a new name n to escape from its binder [n] in the inference. As anexample, consider the closed raw service

[z] p • o?〈z〉 . [p′] p′′ • o′′!〈{z}{p′′,p′}〉 (∗)Without the premise n < reg(Γ′), the service resulting from the type inference wouldbe [{z}{p′′,p′,p}] p • o?〈z〉 . [p′] p′′ • o′′!〈{z}{p′′,p′}〉. The problem with this service is thatthe name p′ occurring in the annotation associated to z by the inference system escapesfrom the scope of its binder and, thus, represents a completely different name. Although,service (∗) is not typable, by a simple semantics preserving manipulation one can get atypable service as, e.g., the following one [p′] [z] p • o?〈z〉 . p′′ • o′′!〈{z}{p′′,p′}〉.

Similarly, in rule (t-delvar), premise x < reg(Γ′) prevents initially closed servicesto become open at the end of the inference. Otherwise, e.g., the type inference wouldtransform the closed raw service

[x] p • o?〈x〉 . [y] p′ • o′?〈y〉 . p′′ • o′′!〈{x}{p′′,y}〉 (∗∗)into the open service [{x}{p,p′′,y}] p • o?〈x〉 . [{y}{p′}] p′ • o′?〈y〉 . p′′ • o′′!〈{x}{p′′,y}〉. Also inthis case, we can easily modify the untypable service (∗∗) to get a typable one with asimilar semantics like, e.g., the service [y] [x] p • o?〈x〉 . p′ • o′?〈y〉 . p′′ • o′′!〈{x}{p′′,y}〉.

Furthermore, in (t-delvar), x is annotated with r − {x}, rather than with r, otherwiseinitially closed services could become open. E.g., the closed raw service [x] p • o?〈x〉 .

6

Table 3. Structural congruence

∗ 0 ≡ 0 ∗ s ≡ s | ∗ s {|0|} ≡ 0{| {|s|} |} ≡ {|s|} {|[d] s|} ≡ [d] {|s|} [d] 0 ≡ 0

[d1] [d2] s ≡ [d2] [d1] s if d1, {x}r1 and d2, {y}r2

[n] [{x}r] s ≡ [{x}r] [n] s if n<r[{x}r1 ] [{y}r2 ] s ≡ [{y}r2 ] [{x}r1 ] s if y<r1 and x<r2

s1 | [d] s2 ≡ [d] (s1 | s2) if d < fd(s1)∪fk(s2)

Table 4. Matching rules

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

M((w1, w2), ({v1}r1 , {v2}r2 )) = σ1 ] σ2

p′ • o′!〈{x}{p′,x}〉 would be transformed into the open service [{x}{p,p′,x}] p • o?〈x〉 .p′ • o′!〈{x}{p′,x}〉 (indeed, x occurs in the annotation associated to its declaration). Noticethat, although the region associated to x by the inference does never record that a ser-vice possibly transmits x with regions containing x, rule (t-delvar) is sound because weassumed that the region of a partner name, at least implicitly, contains the partner name.

Definition 1. A service s is well-typed if ∅ ` s′ � ∅ ` s for some raw service s′.

Operational semantics. COWS operational semantics is defined only for closed ser-vices, i.e. services without free variables/labels (similarly to many real compilers, weconsider terms with free variables/labels as programming errors), but of course the rulesalso involve non-closed services (see e.g. the premises of rules (del )). Formally, the se-mantics is given in 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 3 the laws for replication, pro-tection and delimitation, while omit the (standard) laws for the other operators statingthat parallel composition is commutative, associative and has 0 as identity element, andthat guarded choice enjoys the same properties and, additionally, is idempotent. All thepresented laws are straightforward. Only notice that the last law can be used to extendthe scope of names (like a similar law in the π-calculus), thus enabling communicationof restricted names, except when the argument d of the delimitation is a free killer labelof 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 4, we define the partial functionM( , ) that per-mits performing pattern-matching on semi-structured data thus determining if a receive

7

Table 5. Is there an active kill(k)? / Are there conflicting receives along p • o matching {v}r?

kill(k) ↓kill

s ↓kill ∨ s′ ↓kill

s | s′ ↓kill

s ↓kill

{|s|} ↓kill

s ↓kill

[d] s ↓kill

s ↓kill

∗ s ↓kill

|M(w, {v}r) |< `

p • o?w.s ↓`p • o,{v}r

s ↓`p • o,{v}r d < {p, o}

[d] s ↓`p • o,{v}r

s ↓`p • o,{v}r

{|s|} ↓`p • o,{v}r

g ↓`p • o,{v}r ∨ g′ ↓`

p • o,{v}rg + g′ ↓`

p • o,{v}r

s ↓`p • o,{v}r ∨ s′ ↓`

p • o,{v}rs | s′ ↓`

p • o,{v}r

s ↓`p • o,{v}r

∗ s ↓`p • o,{v}r

and 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 annotated value, and a value matches an anno-tated value only if, apart for the region annotation, they are identical. When tuples wand {v}r do match,M(w, {v}r) returns a substitution, that also records region annotationsof values exchanged in communication, for the variables in w; otherwise, it is undefined.Substitutions (ranged over by σ) are functions mapping variables to annotated valuesand are written as collections of pairs of the form x 7→ {v}r. Application of substitutionσ to s, written s ·σ, has the effect of replacing every free occurrence of x in s with v, foreach x 7→ {v}r ∈ σ, by possibly using alpha-conversion for avoiding v to be captured byname delimitations within s. We use |σ | to denote the number of pairs in σ and σ1]σ2to 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, delimitationand replication operators, for which it acts as an homomorphism.

Finally, in Table 5, we inductively define two predicates: s↓kill checks if s can imme-diately perform a kill(k); s↓`

p •o,{v}r, with ` natural number, checks existence of potential

communication conflicts, i.e. the ability of s of performing a receive activity matching{v}r over the endpoint p • o that generates a substitution with fewer pairs than `.

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

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

α ::= †k | (p •o) C {v}r | (p •o) B w | p •o bσc w {v}r | †In the sequel, we use d(α) to denote the set of names, variables and killer labels oc-curring in α, except for α = p •o bσc w {v}r for which we let d(p •o bσc w {v}r) = d(σ),where d({x 7→ {v}r}) = {x, v}∪ r and d(σ1]σ2) = d(σ1)∪d(σ2). The meaning of labelsis as follows: †k denotes execution of a request for terminating a term from within thedelimitation [k] , (p •o) C {v}r and (p •o) B w denote execution of invoke and receive

8

Table 6. Operational semantics

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

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

[[e]] = v fv(r) = ∅(inv)

p • o!{e}r(p • o)C{v}r−−−−−−−−→ 0

g1α−−→ s

(choice)g1 + g2

α−−→ s

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

(delsub)

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

s†k−−→ s′

(delkill)[k] s

†−→ [k] s′

sα−−→ s′ d , {x}r d<d(α) s ↓kill⇒ α=†, †k

(delpass)[d] s

α−−→ [d] s′

sα−−→ s′ x<d(α)

(xpass)[{x}r] s

α−−→ [{x}r] s′

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

(p • o)C{v}r−−−−−−−−→ s′2 M(w, {v}r) = σ ¬(s1 | s2 ↓|σ|p • o,{v}r)

(com)

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

s1p • o bσc w {v}r−−−−−−−−−−→ s′1 ¬(s2 ↓|M(w,{v}r ) |

p • o,{v}r)

(parcon f )

s1 | s2p • o bσc w {v}r−−−−−−−−−−→ s′1 | s2

s1†k−−→ s′1

(parkill)s1 | s2

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

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

(parpass)s1 | s2

α−−→ s′1 | s2

sα−−→ s′

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

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

(cong)s

α−−→ s′

activities over the endpoint p • o, respectively, p •o bσc w {v}r (if σ , ∅) denotes execu-tion of a communication over p • o with receive parameters w and matching values {v}rand with substitution σ to be still applied, † and p •o b∅c w {v}r denote computationalsteps corresponding to taking place of forced termination and communication (withoutpending substitutions), respectively. Hence, a computation from a closed service s0 is asequence of connected transitions of the form

s0α1−−→ s1

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

where, for each i, αi is either p •o b∅c w {v}r or †, and si is called reduct of s0.We comment on salient points. Activity kill(k) forces termination of all unprotected

parallel 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.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 transition

9

label α contains d or when a kill activity is active in s and α does not correspond to a killactivity (rules (delpass) and (xpass)): in such cases the transition should be derived by us-ing rules (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 andtheir regions do not contain variables (rule (inv)). A receive activity offers an invocableoperation along a given partner name (rule (rec)). The execution of a receive permitsto take a decision between alternative behaviours (rule (choice)). Communication cantake place when two parallel services perform matching receive and invoke activities(rules (com)). Communication generates a substitution that is recorded in the transitionlabel (for subsequent application), rather than a silent transition as in most process cal-culi. If more then one matching is possible the receive that needs fewer substitutionsis selected to progress (rules (com) and (parcon f )). This mechanism permits to correlatedifferent service communications thus implicitly creating interaction sessions and canbe exploited to model the precedence of a service instance over the corresponding ser-vice specification when both can process the same request. A substitution {x 7→ {v}r}for a variable x is applied to a term (rule (delsub)) when the delimitation for x is encoun-tered, i.e. the whole scope s of x is determined, provided that the region annotations ofthe variable declaration and of the substituent datum v do comply i.e. r′ · σ ⊆ r. Thiscondition also means that as a value is received it gets annotated with a smaller region.The substitution for x is then applied to s and x disappears from the term and cannotbe reassigned a value. Execution of parallel services is interleaved (rule (parpass)), butwhen a kill activity or a communication is performed. Indeed, the former must triggertermination of all parallel services (according to rule (parkill)), while the latter must en-sure that the receive activity with greater priority progresses (rule (com) and (parcon f )).The last rule states that structurally congruent services have the same transitions.

2.1 Examples

We end this section with a few examples aimed at clarifying the peculiarities of ourformalism. For simplicity sake, in the examples data have no attached policies, which,according to our convention, means that they are tagged with >.

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 permits

10

to easily model the delayed input of fusion calculus [26], 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).

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}

11

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

3 Main Results

Our main results are standard and state that well-typedness is preserved along compu-tations (subject reduction) and that well-typed services do respect region annotations(type safety). Together, these results imply the soundness of our theory, i.e. no violationof data regions will ever occur during the evolution of well-typed services. The formalaccount of these results follow.

For the proof of subject reduction, we need some standard lemmata concerningsubstitution and weakening. The substitution lemma handles the substitution of partnervariables by partner names. Application of a substitution σ to a type environment Γ,written Γ · σ, is defined only when dom(σ) ∩ dom(Γ) = ∅ and, for each x 7→ {v}r ∈ σ,has the effect of replacing every occurrence of x in the regions of Γ with v, i.e.

∅ · {x 7→ {v}r} = ∅ and (Γ, {y : r′}) · {x 7→ {v}r} = Γ · {x 7→ {v}r}, {y : (r′ · {x 7→ {v}r})}.Lemma 1 (Substitution Lemma). If Γ, {x : r} ` s � Γ′, {x : r′} ` s′ and σ = {x 7→{v}r′′ }, then Γ · σ ` s · σ � Γ′ · σ ` s′ · σ.

Proof. The proof proceeds by induction on the length of the inference used to derivethe typing judgement.

The base cases (t-nil) and (t-kill) are trivial to conclude. Let us consider the basecase (t-inv): by definition s = s′ = u1 • u2!〈{e1(y1)}r1 , . . . , {en(yn)}rn〉 where u1 ∈ ri foreach i ∈ {1, . . . , n}. Hence, we also have that u1 · σ ∈ ri · σ for any ri and σ. We nowdistinguish three cases:

1. y1 ∪ . . . ∪ yn = ∅. In this case, Γ′ = Γ and r′ = r; thus by using rule (t-inv), we canconclude that Γ·σ ` u1 • u2!〈{e1}r1 , . . . , {en}rn〉·σ � Γ′ ·σ ` u1 • u2!〈{e1}r1 , . . . , {en}rn〉·σ.

2. Let Ide f= { j ∈ {1, . . . , n} : x ∈ y j}. In this case, it must be r′ =

⋃i∈I ri ∪ r and

Γ′ = Γ + {z : r1}z,x,z∈y1 + . . . + {z : rn}z,x,z∈yn . Now, we can to conclude like in theprevious case.

3. x < y1 ∪ . . . ∪ yn. In this case r′ = r and, again, we can conclude like before.

Let us now consider the inductive case and reason by case analysis on the last rule usedto infer the judgement. We explicitly show the most significant cases, the remainingones are easier.

12

(t-rec): Let s = p • o?w.t and s′ = p • o?w.t′. Then, we can suppose that Γ′′, {x :r′′} ` t � Γ′, {x : r′} ` t′ for some Γ′′ and r′′. We distinguish three cases:1. fv(w) = ∅. In this case Γ′′ = Γ and r′′ = r. By induction, we have Γ · σ `

t · σ � Γ′ · σ ` t′ · σ. Now, by using rule (t-rec), we can conclude thatΓ · σ ` p • o?w.(t · σ) � Γ′ · σ ` p • o?w.(t′ · σ).

2. x ∈ fv(w). In this case Γ′′ = Γ + {z : {p}}z,x,z∈fv(w) and r′′ = r ∪ {p} and byinduction, Γ·σ+{z : {p}}z,x,z∈fv(w) ` t·σ � Γ′·σ ` t′·σ. Hence by using rule (t-rec), we can conclude the wanted Γ·σ ` (p • o?w.t)·σ � Γ′ ·σ ` (p • o?w.t′)·σ.

3. fv(w) , ∅ and x < fv(w). In this case Γ′′ = Γ + {z : {p}}z∈fv(w) and r′′ = r, andwe can conclude like before.

(t-delvar): Let s = [z] t and s′ = [{z}r′′−{z}] t′ for some r′′. Since z ∈ bv(s), by typeenvironment definition, we have z , x. Then, we can suppose that Γ, {x : r}, {z :∅} ` t � Γ′, {x : r′′′}, {z : r′′} ` t′ for some r′′′ such that z < (r′′′ ∪ reg(Γ′)). Thus,by induction Γ ·σ, {z : ∅} ` t ·σ � Γ′ ·σ, {z : r′′ ·σ} ` t′ ·σ. Hence, by using rule(t-delvar), we can conclude the wanted Γ ·σ ` [z] t ·σ � Γ′ ·σ ` [{z}r′′·σ−{z}] t′ ·σ.(t-par): Let s = s1 | s2 and s′ = s′1 | s′2. Then, we can suppose that Γ, {x : r} `s1 � Γ1, {x : r′1} ` s′1 and Γ, {x : r} ` s2 � Γ2, {x : r′2} ` s′2. By induction,Γ ·σ ` s1 ·σ � Γ1 ·σ ` s′1 ·σ and Γ ·σ ` s2 ·σ � Γ2 ·σ ` s′2 ·σ. Hence by lettingΓ′ = Γ1 +Γ2 we can conclude the wanted Γ ·σ ` (s1 | s2)·σ � Γ′ ·σ ` (s′1 | s′2)·σ.

�

Lemma 2 (Weakening Lemma). Let Γ′ ` s′ � Γ ` s and x < bd(s), then Γ′ + {x :r} ` s′ � Γ + {x : r} ` s.

Proof. By a straightforward induction on the length of the type derivation, with a caseanalysis on the last used rule, and by exploiting the fact that extending Γ by adding{x : r} does not affect the premise of rule (t-inv). �

We also need a few auxiliary results. The first one states that function halt( ) pre-serves well-typedness and can be easily proved by induction on the definition of halt( ).

Lemma 3. If s is well-typed then halt(s) is well-typed.

The other two auxiliary results establish well-typedness preservation by the struc-tural congruence and by the labelled transition relation, respectively. We will use thefollowing preorder v on type environments: we write Γ v Γ′ if there exists a typeenvironment Γ′′ such that Γ + Γ′′ = Γ′.

Lemma 4. If Γ′ ` s′1 � Γ ` s1 and s1 ≡ s2 then there exists a raw service s′2 suchthat Γ′ ` s′2 � Γ ` s2.

Proof. By a straightforward induction on the derivation of s1 ≡ s2. �

Theorem 1. If Γ′1 ` s′1 � Γ1 ` s1 and s1α−−→ s2 then there exist a raw service s′2 and

two type environments Γ2 and Γ′2 such that Γ2 v Γ1, Γ′1 v Γ′2 and Γ′2 ` s′2 � Γ2 ` s2.

Proof. The proof proceeds by induction on the length of the inference of s1α−−→ s2.

Base Step: We reason by case analysis on the axioms of the typed operational seman-tics.

13

(kill) By rule (t-kill), s1 = s′1 = kill(k) and Γ1 = Γ′1. Thus, since s2 = 0 and by rule(t-nil), it is trivial to conclude, by letting Γ2 = Γ′2 = Γ′1.

(inv) By rule (t-inv), s1 = s1 = p • o!{e}r. Thus, since s2 = 0 and by rule (t-nil), it is trivialto conclude, by letting Γ2 = Γ′2 = Γ′1.

(rec) By hypothesis, s1 = p • o?w.s2 and Γ′1 ` p • o?w.s′2 � Γ1 ` p • o?w.s2.By the premise of rule (t-rec), we can conclude that Γ′2 ` s′2 � Γ2 ` s2 withΓ′2 = Γ′1 + {x : {p}}x∈fv(w) and Γ2 = Γ1.

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

(com) By hypothesis, s1 = sl | sr, s′2 = s′l | s′r and there exist two raw services s′′l ands′′r , and two type environments Γl and Γr, such that Γ1 = Γl + Γr and Γ′1 ` s′′l |s′′r � Γl + Γr ` sl | sr. By the premises of rule (t-par), Γ′1 ` s′′l � Γl ` sl

and Γ′1 ` s′′r � Γr ` sr. By the premises of rule (com), sl(p •o)Bw−−−−−−−→ s′l and

sr(p •o)C{v}r−−−−−−−−→ s′r, then, by induction, there exist two raw services s′′′l and s′′′r , and

four type environment Γ′l , Γ′′l , Γ′r and Γ′′r , such that Γ′1 v Γ′′l , Γ′1 v Γ′′r , Γ′′l ` s′′′l �

Γ′l ` s′l and Γ′′r ` s′′′r � Γ′r ` s′r. By the definition of the preorder v, Γ′1 v Γ′′limplies that there exists Γ such that Γ′1 + Γ = Γ′′l , and, similarly, Γ′1 v Γ′′r impliesthat there exists Γ′ such that Γ′1 + Γ′ = Γ′′r . By repeated applications of Lemma 2,we obtain Γ′′l + Γ′ ` s′′′l � Γ′l + Γ′ ` s′l and Γ′′r + Γ ` s′′′r � Γ′r + Γ ` s′r. SinceΓ′′l + Γ′ = Γ′1 + Γ + Γ′ = Γ′′r + Γ, by applying rule (t-par), we can conclude.

(parcon f ) - (parpass) - (parkill) These cases are similar to the previous one; the latter caserelies on Lemma 3.

(choice) By hypothesis, s1 = g1 + g2 and there exist g′1 and g′2, and two type environ-ments Γ and Γ′, such that Γ1 = Γ + Γ′ and Γ′1 ` g′1 + g′2 � Γ + Γ′ ` g1 + g2. Bythe premise of rule (t-sum), Γ′1 ` g′1 � Γ ` g1. By the premises of rule (choice),

g1α−−→ s2 and, by induction, we can conclude.

(prot) By hypothesis, s1 = {|s|} and there exists a raw service s′ such that Γ′1 ` {|s′|} �Γ1 ` {|s|}. By the premise of rule (t-prot), Γ′1 ` s′ � Γ1 ` s. By the premise of rule

(prot), sα−−→ s′′ such that s2 = {|s′′|}. By induction, there exist s′′′, Γ and Γ′ such

that Γ′ ` s′′′ � Γ ` s′′. Then, by rule (t-prot), we can conclude.(delsub) By hypothesis, s1 = [{x}r] s and there exists a raw services s′′ such that Γ′1 `

[x] s′′ � Γ1 ` [{x}r] s. By the premise of rule (t-delvar), we obtain Γ′1, {x : ∅} `s′′ � Γ1, {x : r} ` s (for simplicity, we assume x < r). By the premise of rule

(delsub), sp •o bσ]{x 7→{v}r′ }c w {v′}r′′−−−−−−−−−−−−−−−−−−−−→ s′ with s2 = s′ · {x 7→ {v}r′ }. Hence, by Lemma 1,

Γ′1 · {x 7→ {v}r′ } ` s′′ · {x 7→ {v}r′ } � Γ1 · {x 7→ {v}r′ } ` s · {x 7→ {v}r′ }. Then, by

definition of function match and rule (com), s · {x 7→ {v}r′ }p •o bσc w {v′}r′′−−−−−−−−−−−−→ s′ · {x 7→

{v}r′ } and, by induction, we can conclude.(delkill) By hypothesis, s1 = [k] s and there exists a raw services s′′ such that Γ′1 `

[k] s′′ � Γ1 ` [k] s. By the premise of rule (t-dellab), Γ′1 ` s′′ � Γ1 ` s. By the

premises of rule (delkill), s†k−−→ s′ with s2 = [k] s′, then, by induction, there exist

s′′′, Γ and Γ′ such that Γ′ ` s′′′ � Γ ` s′. Thus, by applying rule (t-dellab), wecan conclude.

14

(delpass) This case is similar to the previous one.(xpass) By hypothesis, s1 = [{x}r] s and there exists a raw services s′′ such that Γ′1 `

[x] s′′ � Γ1 ` [{x}r] s. By the premise of rule (t-delvar), we obtain Γ′1, {x : ∅} `s′′ � Γ1, {x : r} ` s (for simplicity, we assume x < r). By the premise ofrule (delpass), s

α−−→ s′ with s2 = [{x}r] s′. By induction, there exist s′′′, Γ andΓ′ such that Γ′ ` s′′′ � Γ ` s′ and Γ v Γ1, {x : r}. Thus, we can obtainΓ′′, {x : ∅} ` s′′′ � Γ′′′, {x : r} ` s′ for some Γ′′ and Γ′′′, and, by applying rule(t-delvar), we can conclude.

(cong) By straightforward induction and by relying on Lemma 4.�

We can now easily prove that well-typedness is preserved along computations.

Corollary 1 (Subject Reduction). If s is well-typed and sα−−→ s′ with α ∈

{†, n b∅c w {v}r}, then s′ is well-typed.

To characterize the errors that our type system can capture we use predicate ⇑ :s ⇑ holds true when s can immediately generate a runtime error. This happens whenin an active context there is an invoke activity on a partner not included in the regionannotation of some of the expressions argument of the activity. Formally, ⇑ is definedas the least predicate closed under the following rules

∃ r′ ∈ r . p < r′

p • o!{e}r ⇑s ⇑

A[[s]] ⇑s ≡ s′ s ⇑

s′ ⇑We remark that the runtime errors that our type discipline can capture are related to

the policies for the exchange of data. We skip such runtime errors as ‘unproper use ofvariables’ (e.g. in x • o!v the variable x is not replaced by a partner name) that can beeasily dealt with standard type systems. We can now prove that well-typed services dorespect region annotations.

Theorem 2 (Type Safety). If s is a well-typed service then s ⇑ holds false.

Proof. The proof is straightforward. We prove, by rule induction, that if s ⇑ then s is notwell-typed. Looking at the rules in Table 6, we see that the only case to be considered iswhen there exists r′ ∈ r such that p < r′: in such a case, there is no way to infer a typefor p • o!{e}r using (t-inv). The other cases follow by induction. Suppose, for example,that [n] s ⇑ because s ⇑. By induction, s is not well-typed and therefore we can not use(t-delname), that is the only possible rule to infer that [n] s is well-typed. �

We can finally conclude by stating that the type system and the operational seman-tics are sound.

Corollary 2 (Type Soundness). Let s be a well-typed service. Then s′ ⇑ holds false forevery reduct s′ of s.

Proof. Corollary 1 can be repeatedly applied to prove that s′ is well-typed, then Theo-rem 2 permits to conclude. �

15

4 Examples

In this section we illustrate two applications of our framework. The former example is asimplified but realistic electronic marketplace scenario inspired by W3C [27], the latterone is inspired to an automotive scenario studied in the SENSORIA project [?].

As a matter of notation, we will write Z , s to assign a symbolic name Z to s.

4.1 An electronic marketplace

To show usefulness of our approach, we focus on the central part of the protocol wheresensitive data are exchanged, i.e. we omit the initial bartering and the concluding inter-actions, and expand the part relative to the payment process.

Suppose a service buyer invokes a service seller to purchase some goods. Onceseller has received an order request, it sends back the partner name of the servicecredit agency to be used for the payment. buyer can then check the information oncredit agency and, possibly, confirm the payment by sending its credit card data toseller. In this case, seller forwards the received data to credit agency and passes theorder to the service shipper. In the end, the whole system is

EMP , buyer | credit agency | [psh] (seller | shipper)

When fixing the policies for data exchange, services can (safely) assume that, atthe outset, partner names ps, pca and pb are publicly available for invoking seller,credit agency and buyer, respectively. Instead, the partner name psh for invokingshipper is private and only shared with seller. Of course, due to the syntactical restric-tions, the ‘locality’ condition for partner names is preserved by the semantics. Thus, theinitials assumptions remain true forever.

The buyer service is defined as

buyer , [id] ( ps • oord!〈{id}{ps,pb}, pb, order〉| [xca] pb • oca in f o?〈id, xca〉.

[p, o] ( p • o!〈〉 | p • o?〈〉.ps • opay!〈{id}{ps,pb}, {cc data}{ps,xca}〉+ p • o?〈〉.ps • ocanc!〈{id}{ps,pb}〉 ) )

The endpoint ps • oord is used for invoking the seller service and transmitting the ordertogether with the buyer’s partner name pb. The (restricted) name id represents the orderidentifier and is used for correlating all those service interactions that logically form asame session relative to the processing of order. For example, the specification of buyercould be slightly modified to allow the service to simultaneously make multiple orders:of course, although all such parallel threads must use the same partner ps to interactwith seller, they can exploit different order identifiers as a means to correlate messagesbelonging to different interaction sessions. The type attached to id only allows buyerand seller to exchange and use it, since they are the only services that can receive alongps and pb. Instead, pb comes without an attached policy, since it is publicly known (itis transmitted to indicate the service making the invocation for the call-back operation).For simplicity, also order has no attached policy; thus, it could be later on communi-cated to any other service. Variable xca is used to store the partner name of the credit

16

agency service to be used to possibly finalize the purchase and also to implement thepolicy for buyer’s credit card data. After the information on the credit agency serviceare verified, buyer sends a message to seller either to confirm or to cancel the order.This is simply modelled as an internal non-deterministic choice, by exploiting the pri-vate endpoint p • o (a more precise model can be obtained by exploiting the encodingsshown in [22]).

The seller service is defined as

seller , ∗ [xb, xid, xord, k] ps • oord?〈xid, xb, xord〉.( xb • oca in f o!〈{xid}{xb}, pca〉| [xcc] ps • opay?〈xid, xcc〉.( pca • ocr req!〈xord, {xcc}{pca}〉

| psh • osh req!〈xord〉 )| ps • ocanc?〈xid〉.kill(k) )

Once seller receives an order along ps • oord, it creates one specific instance that sendsback to buyer (via xb) the partner name pca of the credit agency service where the pay-ment will be made. Whenever the seller instance receives the credit card data correlatedto xid, it forwards them to credit agency and passes the order to the (internal) shipperservice. Instead, if buyer demands cancellation of the order, the corresponding instanceof seller is immediately terminated. Name k is used to delimit the effect of the killactivity only to the relevant instance.

The remaining two services are defined as

credit agency , ∗ [x, y] pca • ocr req?〈x, y〉.“execute the payment”

shipper , ∗ [z] psh • osh req?〈z〉.“process the order”

Let now consider the type inference phase. Service seller gets annotated as follows:

seller′ , ∗ [{xb}{ps}] [{xid}{ps,xb}, {xord}>, k] ps • oord?〈xid, xb, xord〉.( xb • oca in f o!〈{xid}{xb}, pca〉| [{xcc}{ps,pca}] ps • opay?〈xid, xcc〉.( pca • ocr req!〈xord, {xcc}{pca}〉

| psh • osh req!〈xord〉 )| ps • ocanc?〈xid〉.kill(k) )

The type inference has the task of checking consistency of region annotations ofthe arguments occurring within invoke activities and that of deriving the annotationsfor variable declarations. As regards consistency, there are only two explicitly typedexpressions used as arguments of invoke activities, i.e. xid and xcc, and their types {xb}and {pca} satisfy the consistency constraint (see rule (t-inv)). The remaining expressionsoccurring as arguments of invoke activities, i.e. the only xord, have implicitly assignedtype > (indeed, recall that we assumed that an untagged e stands for {e}>) and arethus trivially consistent. As regards type derivation, when a variable is put in the envi-ronment (rule (t-delvar)), it is assigned type ∅. Later on, when a variable is used as anargument of an invoke or receive, its type can possibly be enriched (rules (t-inv) and(t-rec)). Thus, at the end of the inference, declaration of variable xb, that is only usedin ps • oord?〈xid, xb, xord〉, will have assigned region {ps} (application of rule (t-rec)).Instead, declaration of xord has assigned type > (rule (t-inv) is used) while that of xcc

has assigned type {ps, pca} and, similarly, declaration of xid gets annotated with {ps, xb}

17

(in both cases rules (t-inv) and (t-rec) are used). Notably, in seller′, delimitation [{xb}ps ]does not commute any longer with delimitations [{xid}{ps,xb}, {xord}>, k] (otherwise theservice would become opened).

The variable declarations of the other services are annotated in a trivial way: xca with{pb}, x and y with {pca}, and z with {psh} (we assume that credit agency and shipper donot re-transmit the received data). Thus, if we call buyer′, credit agency′ and shipper′

the other typed services, then the system resulting from the type inference is

buyer′ | credit agency′ | [psh] (seller′ | shipper′)

After some computation steps, the system can become

[id] ( ps • opay!〈{id}{ps,pb}, {cc data}{ps,pca}〉 | [psh] ( seller′ |[k, {xcc}{ps,pca}] ( ps • opay?〈id, xcc〉.( pca • ocr req!〈order, {xcc}{pca}〉

| psh • osh req!〈order〉 )| ps • ocanc?〈id〉.kill(k) )

| ∗ [{x}{pca}, {y}{pca}] pca • ocr req?〈x, y〉.“execute the payment”| ∗ [{z}{psh}] psh • osh req?〈z〉.“process the order” ) )

Thus, after buyer′ sends the credit card data, we get

[id, psh] ( seller′

| [k] ( pca • ocr req!〈order, {cc data}{pca}〉 | psh • osh req!〈order〉| ps • ocanc?〈id〉.kill(k) )

| ∗ [{x}{pca}, {y}{pca}] pca • ocr req?〈x, y〉.“execute the payment”| ∗ [{z}{psh}] psh • osh req?〈z〉.“process the order” )

At this point, seller′ can safely communicate credit card data of buyer′ to credit agency′

and, then, forward the order to shipper′.Suppose now that seller′ also contains such a malicious invoke as

psh • o!〈. . . , {xcc}r, . . .〉. In order to successfully pass the type inference phase, itshould be that psh ∈ r (otherwise rule (t-inv) could not be applied). Therefore, in theresulting typed service we would have the variable declaration [{xcc}r′ ] , with r ⊆ r′.Now, communication with buyer′ would be blocked by the runtime checks because thedatum is tagged as {cc data}{ps,pca}, and psh ∈ r ⊆ r′ implies that r′ * {ps, pca}.

4.2 Automotive security

A car manufacturer offers an integrated infotainment system capable of forwarding theGPS coordinates of a car to relevant recipient services. We consider the case of a sys-tem designed to allow drivers to assist each other on deserted roads until professionalservice can arrive at the scene. The system is based on an automobile association mon-itoring the location of all trustworthy members’ cars and contacting the drivers nearestto an accident to ask them to provide first aid. The driver in trouble is assured that infor-mation about his location cannot become available to unauthorized users (e.g. paparazziphotographers). We suppose that customers of the automobile association service maynot be trustworthy members. Thus, a driver can play both helper and customer roles, oronly the latter one.

18

We consider the following (simplified) scenario

C | T1 | T2 | T3 | A

where C is the service installed in the customer’s car, T1, T2, and T3 are services in-stalled in the trustworthy members’ cars, and A is the service provided by the automo-bile association. For the sake of simplicity, we do not consider the customer servicesinstalled in the member’s cars.

The customer service is defined as

C , [psys] ( psys • oaccident!〈gps〉 | [y T] [ygps] psys • oaccident?〈ygps〉.CfindHelp )

CfindHelp , ( pA • ocarAccident!〈{pC}{pA}, {ygps}{pA}〉| [yid] ( pC • ohelpNotFound?〈〉

+

pC • ohelpFound?〈yid, y T〉.pA • oposition!〈yid, {ygps}{pA,y T}〉 ) )

When the diagnostic system of the customer’s car detects that an accident has happened,it activates the recovery service by sending the current GPS coordinates of the car alongthe private endpoint psys • oaccident. Then, it invokes the automobile association serviceA, by using the endpoint pA • ocarAccident, and transmits its partner name (i.e. pC, for thereply) and its coordinates. The type attached to those data only allows A to exchangeand use them, since A is the only service that can receive along pA. Afterwards, C waitsa reply from A. If no trustworthy helper has been found, then the driver has to wait untilprofessional service arrives at the scene. In case A has found a trustworthy helper Ti, Ctransmits its coordinates again, this time with region enlarged with the partner name ofTi. Deliberately we do not model C as a persistent service; instead, we assume that itwill be reinstalled at the end of the repairing activity.

A trustworthy member service is defined as

Ti , [m] (m!〈〉 | ∗ m?〈〉.[xid] pTi • ocheck?〈xid〉.[n] ( n!〈〉 | n?〈〉.( pA • ore f use!〈xid〉 | m!〈〉 )

+

n?〈〉.( pA • ook!〈xid〉| [xgps] pTi • o f wdPos?〈xgps〉.

“go to xgps and provide first aid”.m!〈〉 ) )

This is a persistent service that, however, can serve requests only sequentially (i.e. oneat time). When the automobile association contacts one of its members, firstly asks him(by invoking the operation ocheck) if he is willing to provide first aid to a near driver.Service Ti can accept or refuse by replying on the operations ook or ore f use, respectively.For the sake of simplicity, we model the above decision by means of an internal non-deterministic choice exploiting the private endpoint n. In case of negative reply, Ti isimmediately reactivated (by means of m!〈〉). Otherwise, i.e. in case of positive reply,the service waits for the position of the driver in trouble from A, goes to the accidentscene, provides first aid and, finally, reactivates itself.

19

The automobile association service is defined as

A , [o f ind, o f ound, onotFound]( ∗ [z C, zgps] pA • ocarAccident?〈z C, zgps〉. [id] Ainst| ∗ [zid, zpos] pA • o f ind?〈zid, zpos〉.

“find in DB and reply on o f ound or onotFound” )

Ainst , [n] ( n!〈〉 | ∗ n?〈〉. ( pA • o f ind!〈id, zgps〉| [z′T ] ( pA • onotFound?〈id〉. z C • ohelpNotFound!〈〉

+

pA • o f ound?〈id, z′T〉. ( z′T • ocheck!〈id〉| pA • ore f use?〈id〉. n!〈〉+

pA • ook?〈id〉. [z T, o] ( pA • o!〈z′T〉| pA • o?〈z T〉.( z C • ohelpFound!〈id, {z T}{z C}〉| [z′gps] pA • oposition?〈id, z′gps〉.

z T • o f wdPos!〈{z′gps}{z T}〉 ) ) ) ) ) )

This service is composed of two persistent subservices, both capable of receiving alongpA. Service A is publicly invocable and can interact with customers and members ser-vices, other than with the ‘internal’ service Ainst. This latter service, instead, can only beinvoked by A (indeed, all the operations used by the service, i.e. o f ind, o f ound, onotFound,are restricted and this prevents them to be invoked from the outside) and has the task oflooking up in a database the member nearest to given a location and replying accord-ingly.

Differently from C and Ti, A and Ainst can serve requests concurrently and, thus,exploit correlation mechanisms to route each received message to its right instance.Indeed, when a customer request is received along pA • ocarAccident, a new specific serviceinstance is created that is uniquely identified by a fresh correlation identifier id; thisidentifier is generated by the instance itself and is communicated to every other involvedservice. The instance then tries to find a helper member that is near to the accidentscene and is willing to provide first aid. This is done by repeatedly looking up thedatabase (pA • o f ind!〈id, zgps〉) and checking willingness of the returned trustworthymember (z′T • ocheck!〈id〉), until either one available member is found (i.e. the memberreplies on operation ook) or the looking up in the database fails (i.e. a reply on onotFound

is returned). Technically, the cycle is implemented by means of the replication operatorand the private endpoint n. If no available helper is found, the instance notifies this tothe customer (z C • ohelpNotFound!〈〉) and terminates; otherwise, it sends the partner nameof the found helper to the customer (z C • ohelpFound!〈id, {z T}{z C}〉), waits for the customerlocation (whose region now also include the partner name of the helper) and forwardsit to the helper (z T • o f wdPos!〈{z′gps}{z T}〉).

Notably, the only relevant types are that attached to the partner name of the foundhelper, which allows only C to receive this partner, and that attached to the customerlocation, which allows only the found helper to receive such location.

Let now consider the type inference phase. Service C gets annotated as follows:

20

C′ , [psys] ( psys • oaccident!〈gps〉| [{y T}{pC}] [{ygps}{psys,pA,y T}] psys • oaccident?〈ygps〉.C′findHelp )

C′findHelp , ( pA • ocarAccident!〈{pC}{pA}, {ygps}{pA}〉| [{yid}>] ( pC • ohelpNotFound?〈〉

+

pC • ohelpFound?〈yid, y T〉. pA • oposition!〈yid, {ygps}{pA,y T}〉 ) )

As regards consistency of region annotations, the only explicitly typed expressions usedas arguments of invoke activities are pC and ygps (this latter is used twice); in any case,their types ({pA}, {pA} and {pA, y T}, resp.) satisfy the consistency constraint (see rule(t-inv)). The remaining expressions occurring as arguments of invoke activities, i.e. gpsand yid, have implicitly assigned type > and, thus, the consistency constraint is triv-ially satisfied. As regards derivation of types for variable declarations, at the end ofthe inference, declaration of variable y T, that is only used in pC • ohelpFound?〈yid, y T〉and in the region of ygps, will have assigned region {pC} (application of rule (t-rec)).Instead, ygps will have assigned type {psys, pA, y T} (rules (t-inv) and (t-rec)), while yid

will have assigned type > (rule (t-inv)). Notably, in C′, delimitation [{y T}{pC}] does notcommute any longer with delimitation [{ygps}{psys,pA,y T}] (otherwise the service wouldbecome opened).

Services Ti get annotated as follows:

T′i , [m] (m!〈〉 | ∗ m?〈〉.[{xid}>] pTi • ocheck?〈xid〉.[n] ( n!〈〉 | n?〈〉.( pA • ore f use!〈xid〉 | m!〈〉 )

+

n?〈〉.( pA • ook!〈xid〉| [{xgps}{pTi}] pTi • o f wdPos?〈xgps〉.

“go to xgps and provide first aid”.m!〈〉 ) )

In this case, derivation of types for variables is trivial: xid has type > and xgps has type{pTi} (we assume that Ti does not re-transmit the GPS data store in xgps).

Service A and Ainst get annotated as follows:

A′ , [o f ind, o f ound, onotFound]( ∗ [{z C}{pA}, {zgps}{pA}] pA • ocarAccident?〈z C, zgps〉. [id] A′inst| ∗ [{zid}{pA}, {zpos}{pA}] pA • o f ind?〈zid, zpos〉.

“find in DB and reply on o f ound or onotFound” )

A′inst , [n] ( n!〈〉 | ∗ n?〈〉. ( pA • o f ind!〈id, zgps〉| [{z′T }{pA}] ( pA • onotFound?〈id〉. z C • ohelpNotFound!〈〉

+

pA • o f ound?〈id, z′T〉. (z′T • ocheck!〈id〉| pA • ore f use?〈id〉. n!〈〉+

pA • ook?〈id〉. [{z T}{pA,z C}, o] ( pA • o!〈z′T〉| pA • o?〈z T〉.( z C • ohelpFound!〈id, {z T}{z C}〉| [{z′gps}{pA,z T}] pA • oposition?〈id, z′gps〉.

z T • o f wdPos!〈{z′gps}{z T}〉 ) ) ) ) ) )

21

Fig. 1. Automotive security scenario

Variables z C, zgps, zid, zpos, z′T are trivially annotated with type {pA}, because A doesnot re-transmit the corresponding data, while variables z T and z′gps are annotated with{pA, z C} and {pA, z T}, respectively.

Therefore, the system resulting from the type inference is

C′ | T′1 | T′2 | T′3 | A′

Figure 1 shows a possible evolution of the scenario, where T′3 is too far from the acci-dent scene, T′2 is not available, and T′1 accepts to provide first aid to C′.

For example, after the computation steps 1–9 described in Figure 1, the systembecomes

pA • oposition!〈id, {gps}{pA,pT1}〉|

[o f ind, o f ound, onotFound]( ∗ [{z C}{pA}, {zgps}{pA}] pA • ocarAccident?〈z C, zgps〉. · · ·| ∗ [{zid}{pA}, {zpos}{pA}] pA • o f ind?〈zid, zpos〉. · · ·| [{z′gps}{pA,pT1}] pA • oposition?〈id, z′gps〉. pT1 • o f wdPos!〈{z′gps}{pT1}〉 )|[m] (∗ m?〈〉. · · ·

| [{xgps}{pT1}] pT1 • o f wdPos?〈xgps〉. “go to xgps and provide first aid”. m!〈〉 )|

T2 | T3

22

At this point, the customer can safely communicate its location to the automobile as-sociation (namely, rule (delsub) of the operational semantics can be applied because theregion annotations of gps and z′gps are both {pA, pT1} and, hence, do comply), and thesystem becomes

[o f ind, o f ound, onotFound]( ∗ [{z C}{pA}, {zgps}{pA}] pA • ocarAccident?〈z C, zgps〉. · · ·| ∗ [{zid}{pA}, {zpos}{pA}] pA • o f ind?〈zid, zpos〉. · · ·| pT1•o f wdPos!〈{gps}{pT1}〉 )|

[m] (∗ m?〈〉. · · ·| [{xgps}{pT1}] pT1 • o f wdPos?〈xgps〉. “go to xgps and provide first aid”. m!〈〉 )

|T2 | T3

Now, the automobile association can safely forward the customer location, because theregion annotations of gps and xgps do comply.

5 Concluding remarks

We have introduced a first analytical tool for checking that COWS specifications en-joy some desirable properties concerning the partners, and hence the services, that cansafely access any given datum and, in that respect, do not manifest unexpected be-haviors. Our type system is quite simple: types are just sets and operations on typesare union, intersection, subset inclusion, etc. The language operational semantics onlyinvolves types in efficiently implementable checks, i.e. subset inclusions. While im-plementation of our framework is currently in progress, we are also working on thedefinition of a completely static variant where all dynamic checks have been moved tothe static phase.

The types used in this paper are essentially inspired by the ‘region types’ forConfined-λ of [15] and for global computing calculi of [9]. There are however somenoticeable differences. In fact, COWS permits describing not necessarily distributedsystems and exchanging heterogeneous data along endpoints, which calls for a moredynamic typing mechanism than communication channels. Moreover, COWS permitsannotating only the relevant data while Confined-λ requires typing any constant, func-tion and channel. The group types, originally proposed for the Ambients calculus [8]and then recast to the π-calculus [7], have purposes similar to our region annotations,albeit they are only used for constraining the exchanges of ambient and channel names.Confinement has been also explored in the context of Java, and related calculi, for con-fining classes and objects within specific packages [30, 32].

More expressive type disciplines based, e.g., on session types and behavioural typesare emerging as powerful tools for taking into account behavioural and non-functionalproperties of computing systems. In the case of services, they could permit to expressand enforce many relevant policies for, e.g., regulating resources usage, constraining thesequences of messages accepted by services, ensuring service interoperability and com-positionality, guaranteeing absence of deadlock in service composition, checking that

23

interaction obeys a given protocol. Some of the studies developed for the π-calculus (seee.g. [6, 31, 16, 14, 17]) are promising starting points, but they need non trivial adapta-tions to deal with all COWS peculiar features. For example, one of the major problemswe envisage concerns the treatment of killing and protection activities, that are not com-monly used in process calculi.

Many efforts have been devoted to develop analytical tools for SOC foundationallanguages. Some works study mechanisms for comparing global descriptions (i.e.choreographies) and local descriptions (i.e. orchestrations) of a same system. Meansto check conformance of these different views have been defined in [5] and, by relyingon session types, in [6]. COWS, instead, only considers service orchestration and fo-cuses on modelling the dynamic behaviour of services without the limitations possiblyintroduced by a layer of choreography. Some other works [19, 23] have concentratedon modelling web transactions and on studying their properties in programming lan-guages based on the π-calculus, while [4, 3] formalize long running transactions withspecial care for the Sagas mechanism [10]. A type system specifying security policiesfor orchestration has been introduced in [1] for a very basic formalism based on theλ-calculus. Finally, a type system for checking compliance between (simplified) WS-BPEL terms and the associated WSDL documents has been defined in [21].

References

1. M. Bartoletti, P. Degano, and G. Ferrari. Security Issues in Service Composition. In Pro-ceedings of FMOODS 2006, 8th IFIP International Conference on Formal Methods forOpen Object-Based Distributed Systems, volume 4037 of Lecture Notes in Computer Sci-ence, pages 1–16, 2006.

2. A. Brogi, C. Canal, E. Pimentel, and A. Vallecillo. Formalizing web service choreographies.ENTCS, 105:73–94, 2004.

3. 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.

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

5. 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.

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

7. L. Cardelli, G. Ghelli, and A. D. Gordon. Secrecy and group creation. Inf. Comput.,196(2):127–155, 2005.

8. L. Cardelli, G. Ghelli, and A.D. Gordon. Types for the ambient calculus. Inf. Comput.,177(2):160–194, 2002.

9. R. De Nicola, D. Gorla, and R. Pugliese. Confining data and processes in global computingapplications. Science of Computer Programming, 63:57–87, 2006.

10. H. Garcia-Molina and K. Salem. Sagas. In SIGMOD, pages 249–259. ACM Press, 1987.11. P. Geguang, Z. Xiangpeng, W. Shuling, and Q. Zongyan. Towards the semantics and verifi-

cation of bpel4ws. In WLFM 2005. Elsevier, 2005.

24

12. H. Goguen. Typed operational semantics. In Mariangiola Dezani-Ciancaglini and Gordon D.Plotkin, editors, Typed Lambda Calculi and Applications, volume 902 of LNCS, pages 186–200. Springer, 1995.

13. C. Guidi, R. Lucchi, R. Gorrieri, N. Busi, and G. Zavattaro. SOCK: a calculus for serviceoriented computing. In ICSOC, volume 4294 of LNCS, pages 327–338. Springer, 2006.

14. A. Igarashi and N. Kobayashi. A generic type system for the pi-calculus. Theor. Comput.Sci., 311(1-3):121–163, 2004.

15. Z. D. Kirli. Confined mobile functions. In 14th IEEE Computer Security Foundations Work-shop (CSFW ’01), pages 283–294, Washington - Brussels - Tokyo, June 2001. IEEE Com-puter Society.

16. N. Kobayashi. Type systems for concurrent programs. In 10th Anniversary Colloquium ofUNU/IIST, volume 2757 of LNCS, pages 439–453. Springer, 2003.

17. N. Kobayashi, K. Suenaga, and L. Wischik. Resource usage analysis for the π-calculus. InVMCAI, volume 3855 of LNCS, pages 298–312. Springer, 2006.

18. C. Laneve and L. Padovani. Smooth orchestrators. In FoSSaCS, volume 3921 of LNCS,pages 32–46. Springer, 2006.

19. C. Laneve and G. Zavattaro. Foundations of web transactions. In FoSSaCS, volume 3441 ofLNCS, pages 282–298. Springer, 2005.

20. A. Lapadula, R. Pugliese, and F. Tiezzi. A Calculus for Orchestration of Web Services(full version). Technical report, Dipartimento di Sistemi e Informatica, Univ. Firenze, 2006.http://rap.dsi.unifi.it/cows.

21. 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.

22. A. Lapadula, R. Pugliese, and F. Tiezzi. A Calculus for Orchestration of Web Services. InESOP, volume 4421 of LNCS, pages 33–47. Springer, 2007.

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

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

25. OASIS. Web Services Business Process Execution Language Version 2.0. Technical report,WS-BPEL TC OASIS, August 2006. http://www.oasis-open.org/.

26. J. Parrow and B. Victor. The fusion calculus: Expressiveness and symmetry in mobile pro-cesses. In Logic in Computer Science, pages 176–185, 1998.

27. S. Ross-Talbot and T. Fletcher. Web services choreography description language: Primer(working draft). Technical report, W3C, June 2006.

28. F.B. Schneider, G. Morrisett, and R. Harper. A language-based approach to security. InInformatics: 10 Years Ahead, 10 Years Back. Conference on the Occasion of Dagstuhl’s 10thAnniversary, number 2000 in LNCS, pages 86–101. Springer, 2000.

29. M. Viroli. Towards a formal foundational to orchestration languages. ENTCS, 105:51–71,2004.

30. J. Vitek and B. Bokowski. Confined types in java. SPE, 31(6):507–532, 2001.31. 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.

32. T. Zhao, J. Palsber, and J. Vitek. Lightweight confinement for featherweight java. In Pro-ceedings of the 18th ACM SIGPLAN conference on Object-oriented programing, systems,languages, and applications, pages 135–148. ACM Press, 2003.

25