A Theory of Contracts for Web Services Giuseppe Castagna CNRS PPS, Université Denis Diderot, Paris, France and Nils Gesbert University of Glasgow, Glasgow, Scotland and Luca Padovani ISTI, Università degli Studi di Urbino, Urbino, Italy Contracts are behavioral descriptions of Web services. We devise a theory of contracts that formalizes the compatibility of a client to a service, and the safe replacement of a service with another service. The use of contracts statically ensures the successful completion of every possible interaction between compatible clients and services. The technical device that underlies the theory is the filter, which is an explicit coercion preventing some possible behaviors of services and, in doing so, make services compatible with different usage scenarios. We show that filters can be seen as proofs of a sound and complete subcontracting deduction system which simultaneously refines and extends Hennessy’s classical axiomatization of the must testing preorder. The relation is decidable and the decision algorithm is obtained via a cut-elimination process that proves the coherence of subcontracting as a logical system. Despite the richness of the technical development, the resulting approach is based on simple ideas and basic intuitions. Remarkably, its application is mostly independent of the language used to program the services or the clients. We outline the practical aspects of our theory by studying two different concrete syntaxes for contracts and applying each of them to Web services languages. We also explore implementation issues of filters and discuss the perspectives of future research this work opens. Categories and Subject Descriptors: F.1.2 [Computation by Abstract Devices]: Modes of Computation—Parallelism and concurrency; F.3.3 [Logics and Meanings of Programs]: Studies of Program Constructs—Type structure; H.3.5 [Information Storage and Retrieval]: Online Information Services—Web-based services; H.5.3 [Information Interfaces and Presentation]: Group and Organization Interfaces—Theory and models, Web-based interaction General Terms: Languages, Standardization, Theory Additional Key Words and Phrases: Web services, contracts, concurrency theory, ccs, must testing, type theory, subtyping, explicit coercions. A preliminary version of this work appeared in the proceedings of POPL ’08, the ACM SIGPLANSIGACT Symposium on Principles of Programming Languages 2008. Nils Gesbert is supported by EPSRC grant EP/F065708/1 (Engineering Foundations of Web Services: Theories and Tool Support). Permission to make digital/hard copy of all or part of this material without fee for personal or classroom use provided that the copies are not made or distributed for profit or commercial advantage, the ACM copyright/server notice, the title of the publication, and its date appear, and notice is given that copying is by permission of the ACM, Inc. To copy otherwise, to republish, to post on servers, or to redistribute to lists requires prior specific permission and/or a fee. c 20YY ACM 0164-0925/20YY/0500-0001 $5.00 TO APPEAR IN ACM Transactions on Programming Languages and Systems 2 · Castagna, Gesbert, and Padovani 1. INTRODUCTION Web services are distributed components that clients can connect to and communicate with by means of standard communication protocols and platform-neutral message formats. Remarkably, Web services are equipped with machine-understandable descriptions of their interface. This aspect permits Web services to be discovered according to the information encoded in their interface, and provides very basic information for reusing and assembling existing software components. Among the capabilities that can be used as search keys are the operations provided by the service, the format or schema [Fallside and Walmsley 2004] of the exchanged messages, and the contract required to interact successfully with the service. By contract we mean the description of the external, observable behavior of a service. The Web Service Description Language (wsdl) [Chinnici et al. 2007; Chinnici et al. 2007] is a standard technology for describing the interface exposed by a service. In wsdl, contracts are basically limited to one-way (asynchronous) and request/response (synchronous) interactions. The Web Service Conversation Language (wscl) [Banerji et al. 2002] extends wsdl contracts by allowing the description of arbitrary, possibly cyclic sequences of exchanged messages between communicating parties. Other languages, such as the Web Service Business Execution Language (ws-bpel) [Alves et al. 2007], provide even more detailed descriptions of services by defining the subprocess structure and more specific details regarding the service’s internals. Such descriptions, which are excessively concrete and verbose to directly serve as interfaces, can be approximated and compared in terms of contracts. Standard technologies are also available for building repositories of Web service descriptions [Bellwood et al. 2005], making it possible to perform queries for services according to their contract. Searching immediately calls for a notion of contract equivalence to perform service discovery in the same way as, say, type isomorphisms are used to perform library searches [Rittri 1993; Di Cosmo 1995]. Without a formal characterization of contracts, however, one is left with excessively demanding equivalences such as syntactical or structural equality. In fact, clients will be equally satisfied to interact with services that provide more capabilities than those actually required, so that it makes sense to relax the equivalence into a subcontract preorder (denoted by  in this paper). Service discovery is not the only motivation for introducing a subcontract preorder. Another compelling reason is given by software maintenance and evolution. If clients will be satisfied to interact with services that provide more capabilities than those they require, then it is possible to use subcontracting to ensure that an upgrade of existing services (e.g., to add new capabilities or propose different interaction patterns) will not affect the existing clients. Similarly, the use of a subcontract preorder will benefit the development of Service Oriented Architectures where new applications are developed by reusing and assembling off-the-shelf software components: resorting to subcontracting enhances reuse while providing a formal framework to analyze compatibility of assemblages. In this work we develop a formal theory of contracts that defines a coarse subcontract preorder. Along the lines of [Carpineti et al. 2006] we describe contracts by simple ccs-like terms built with just three operators: prefixing, denoted by a TO APPEAR IN ACM Transactions on Programming Languages and Systems A Theory of Contracts for Web Services · 3 dot, and two infix choice operators + (external choice) and ⊕ (internal choice). The contract α.σ describes a service that is capable of performing an action α, and then continues as σ. The contract σ + τ describes a service that lets the client decide whether to continue as σ or as τ . The contract σ ⊕ τ describes a service that internally decides whether to continue as σ or as τ . Following ccs notation, actions are either write or read actions, the former ones being topped by a bar, and one being the co-action of the other. Actions can either represent operations or message types. As a matter of facts, contracts are behavioral types of processes that do not manifest internal moves and the parallel structure. Contracts are used to ensure that interactions between clients and services will always succeed. Intuitively, this happens if whenever a service offers some set of actions, the client either synchronizes with one of them (i.e., it performs the corresponding co-action) or it terminates. The service contract allows us to determine the set of clients that comply with it, that is to say that will successfully terminate any session of interaction with the service. As said before, the client will probably be satisfied to interact with services that offer more than what the current or searched contract specifies. Intuitively we want to define an order relation on contracts σ  τ such that every client complying with services implementing σ will also comply with services of contract τ . In particular, we would like the  preorder to enjoy some basic properties. The first one is that it should be safe to replace (the service exposing) a contract with a “more deterministic” one. For instance, we expect a ⊕ b.c  a, since every client that terminates with a service that may offer either a or b.c will also terminate with a service that systematically offers a. The second desirable property is that it should be safe to replace (the service exposing) a contract with another one that offers more capabilities. For instance, we expect a  a + b.d since a client that terminates with services that implement a will also terminate with services that leave the client the choice between a and b.d. If taken together, these two examples show the main problem of this intuition: it is easy to see that a client that complies with a ⊕ b.c does not necessarily comply with a+b.d: if client and service synchronize on b, then the client will try to write on c while the service expects to read from d. Therefore, under this interpretation,  looks as not being transitive: a ⊕ b.c  a ∧ a  a + b.d =⇒ Y a ⊕ b.c  a + b.d . (1) The problem can be solved by resorting to the theory of explicit coercions [Bruce and Longo 1990; Chen 2004; Soloviev et al. 1996]. The flawed assumption of the approach described so far, which is the one proposed in [Carpineti et al. 2006], is that services are used carelessly “as they are”. Note indeed that what we are doing here is to use a service of “type” a + b.d where a service of type a ⊕ b.c is expected. The knowledgeable reader will have recognized that we are using  as an inverse subtyping relation for services.1 If we denote by :> the subtyping 1 The inversion is due to the fact that we are considering the client perspective: a contract can be interpreted as the set of clients that comply with services implementing the contract. We decided to keep this notation rather than the inverse one for historical reasons, since it is the same sense as used by De Nicola and Hennessy for the may and must preorders [De Nicola and Hennessy 1984]. This inversion corresponds to the duality between simulation and subtyping, viz. between TO APPEAR IN ACM Transactions on Programming Languages and Systems 4 · Castagna, Gesbert, and Padovani relation for services, then a ⊕ b.c :> a + b.d and so what we implicitly did is to apply subsumption [Cardelli 1988] and consider that a service that has type a + b.d has also type a ⊕ b.c. The problem is not that  (or, equivalently, :>) is not transitive. It rather resides in the use of subsumption, since this corresponds to the use of implicit coercions. Coercions have many distinct characterizations in the literature, but they all share the same underlying intuition that coercions are functions that embed objects of a smaller type into a larger type “without adding new computation” [Chen 2004]. For instance it is well known that for record types one has {a:s} :> {a:s; b:t}. This is so because the coercion function c = λx{a:s;b:t} .{a = x.a} embeds values of the smaller type into the larger one.2 In order to use a term of type {a:s; b:t} where one of type {a:s} is expected, we first have to embed it in the right type by the coercion function c above, which erases (masks/shields) the b field so that it cannot interfere with the computation. Most programming languages do not require the programmer to write coercions, either because they do not have any actual effect (as in the case of the function c above since the type system already ensures that the b field will never be used) or because they are inserted by the compiler (as when converting an integer into the corresponding float). In this case we speak of implicit coercions. However some programming languages (e.g., OCaml [OCaml]) resort to explicit coercions because they have a visible effect and, for instance, they cannot be inferred by the compiler. Coercions for contracts have an observable effect, therefore we develop their metatheory in terms of explicit coercions. However, in the setting studied here, coercions can be inferred so they can be kept implicit in the language and automatically computed at static time. Coming back to our example, the embedding of a service of type a into a ⊕ b.c is the identity, since we do not have to mask/shield any action of a service of the former type in order to use it in a context where a service of the latter type is expected. On the contrary, to embed a service of type a + b.d into a we have to mask (at least) the b action of the service. In order to use it in a context that expects a a service we apply to it a filter that will block all b messages. Transitivity being a logical cut, the coercion from a + b.d to a ⊕ b.c is the composition of the two coercions, that is the filter that blocks b messages. So if we have a client that complies with a ⊕ b.c, then it can be used with a service that implements a + b.d by applying to this service the filter that blocks its b messages. This filter will make the previous problematic synchronization on b impossible, so the client can do nothing but terminate. Filters thus reconcile two requirements that were hitherto incompatible: On the one hand we wish to replace an old service by a new service that offers more choices (that is width subtyping, e.g. σ :> σ + τ ) and/or longer interaction patterns (that is depth subtyping, e.g. a :> a.σ) and/or is more deterministic (e.g. σ ⊕ τ :> σ). On the other hand we want clients of the old service to seamlessly work with the new one. The practical-oriented reader may better appreciate the relevance of the theobservers and observed behaviors. 2 In typed lambda calculus coercions are formally characterized by the fact that their type erasure is η-equivalent to the identity function, but in general coercions may be different from the identity function [Chen 2004]. TO APPEAR IN ACM Transactions on Programming Languages and Systems A Theory of Contracts for Web Services · 5 ory by giving a plausible interpretation to the actions a, b, and c in the above examples. Consider a client process looking for services that accept payments, be them with a credit card or with a bank transfer, without a specific preference for one or the other. Suppose that CreditCard and BankTransfer are the two messages indicating the kind of payment available. Assume also that σ is the protocol following a credit card payment (the exact definition of σ is unimportant). The client would use BankTransfer ⊕ CreditCard.σ as search key in the service repository. The point here is that the client is happy to use whichever payment method is available. Hence, services offering only bank transfers are acceptable (BankTransfer ⊕ CreditCard.σ  BankTransfer), services offering only credit card payments are acceptable (BankTransfer ⊕ CreditCard.σ  CreditCard.σ), and services offering both kinds of payments are acceptable as well (BankTransfer⊕ CreditCard.σ  BankTransfer + CreditCard.σ). As an aside, observe that, had the client searched with the BankTransfer + CreditCard.σ key, it would have found only services offering both payment methods. The question is now whether any service offering bank transfers and some other capabilities—i.e., implementing BankTransfer + ρ for some contract ρ—should be also returned by the query. The answer given by this article is a positive one, but this answer is not so straightforward as it may appear at first glance: consider a service whose contract is BankTransfer + CreditCard.τ where τ is incompatible with σ, in the sense that there are clients satisfied by σ but not by τ . The question is then whether we have BankTransfer ⊕ CreditCard.σ  BankTransfer + CreditCard.τ . Clearly there is one way to satisfy the client, namely by choosing payment by bank transfer. However, in principle client and service may also agree on credit card payment (perhaps because the client tries that kind of payment first), with the risk of the client getting stuck later on during the interaction since σ and τ are not related. The solution we propose by this work is to admit the relation BankTransfer ⊕ CreditCard.σ  BankTransfer + CreditCard.τ , because the service BankTransfer + CreditCard.τ (and, more generally, any service of the form BankTransfer + ρ) can be made comparable to (larger than) BankTransfer ⊕ CreditCard.σ by filtering out the CreditCard action. This filter acts as an explicit coercion that transforms every service that implements the contract BankTransfer + CreditCard.τ into a service that implements the (smaller) BankTransfer contract (this latter being comparable with BankTransfer ⊕ CreditCard.σ without the need of a filter), thus making it compatible with the issuer of the query. Two observations to conclude this overview. First, the fact that we apply filters to services rather than to clients is just a presentational convenience: the same effect can be obtained by applying to the client the filter that blocks the corresponding co-actions. Second, filters must be finer-grained in blocking actions than restriction operators as defined for ccs or π-calculus. Restrictions in these calculi are “permanent” blocks, while filters are required to be able to modulate blocks along the computation. For instance the filter that embeds (a.(a + b)) + b.c into a.b must block b only at the first step of the interaction and a only at the second step of the interaction. TO APPEAR IN ACM Transactions on Programming Languages and Systems 6 · 1.1 Outline of the presentation Castagna, Gesbert, and Padovani We start by presenting the syntax of our contracts (§2.1), by showing how to use them to express wsdl and wscl descriptions (§2.2), and by defining their semantics (§2.3). We then characterize the set of all clients that are strongly compliant with a service—that is, clients that successfully complete every direct interaction session with the service—and argue that subcontract relations whose definitions are naively based on strong compliance are either too strict or suffer the aforementioned problem of transitivity (§2.4). We argue that subcontracting should not be defined on all possible interactions, but focus only on interactions based on actions that a client expects from the services: all the other possible actions should not interfere with the interaction. We formalize this concept by giving a coinductive definition of a subcontract relation that focuses on this kind of actions, we study its properties and describe the relation with the must preorder (§3.1). This subcontract relation induces a notion of weak compliance suggesting that non-interference of unexpected actions can be ensured by coercion functions, which we dub filters (§3.2). By shielding the actions at issue, a filter embeds a service into the “world” of its expected clients. We prove that our subcontract relation can be expressed in terms of filters and of the must preorder and we provide a sound and complete deduction system for the subcontract relation where filters play the role of “proofs” (§3.3). The subcontract relation is shown to be decidable via the definition of a sound and complete algorithmic deduction system (§3.4). Next we show how our contracts are to be used to type Web services programming languages. In particular, we relate our contract language with a generic class of typed process languages and show the soundness of our theory of contracts: this is proved by showing that if a client process is weakly compliant with a service process via a given filter, then the filter ensures that the client will either synchronize infinitely many times with the service or it will successfully terminate (§4). The last part of the presentation is devoted to exploring the more practical aspects of this work. In particular, since our theory is stated for possibly infinite regular trees, we introduce two concrete syntaxes to finitely denote these trees and relate them with the preceding theoretical work (§5.1). Next we apply each syntax to one language proposed by the two major web standardization bodies (i.e., w3c and Oasis) (§5.2-5.3), we explore possible ways of implementing filters, and we outline how the theory can be directly implemented in ws-bpel without requiring any modification of the ws-bpel specification or of existing ws-bpel processes (§5.4). An extensive discussion of related work (§6) and a conclusion that recaps our work and hints at possible tracks of future research (§7) close our presentation. 2. CONTRACTS 2.1 Syntax Contracts are formally defined as possibly infinite trees that satisfy regularity (i.e., they have finitely many distinct subtrees: see, for instance, §4 of [Courcelle 1983]) and a contractivity condition. Definition 2.1 (contract). Let N be a countable set of names. The set of contracts Σ is the set of possibly infinite terms coinductively generated by the TO APPEAR IN ACM Transactions on Programming Languages and Systems A Theory of Contracts for Web Services · 7 following grammar: α ::= a | a σ ::= 0 | α.σ | σ ⊕ σ | σ + σ a∈N and satisfying the following conditions: (1 ) contract terms are regular trees, (2 ) on every infinite branch of a contract term there are infinitely many occurrences of the prefix constructor. In the definition 0 is the contract of services that do not perform any action while the other constructions were already explained in the Introduction (§1). We follow the standard convention of omitting trailing 0’s. We also work modulo associativity of each sum operator and by an P abuse of notation we will sometimes denote L them as n-ary operators. We then write i∈{1,...,n} σi for σ1 +σ2 +· · ·+σn and i∈{1,...,n} σi P for σ1 ⊕ σ2 ⊕ · · · ⊕ σn . By convention we have i∈∅ σi = 0. Infinite terms stand for recursive contracts. This kind of presentation is not customary in process calculi where finite representations of recursion (essentially, Kleene star, recursive equations, or rec-notations) are nearly always preferred. This is probably due to the fact that the intuition behind a finite representation can be more easily grasped. However working directly on infinite trees has two clear advantages. First and foremost, all results abstract away from the particular notation used to represent recursion: it is easy to transpose each result to each particular representation, while it is much more difficult to move from one representation to another. Second, working with infinite terms makes it quite straightforward to transpose the work to finite ones since it just suffices to forget that terms are infinite and no further modifications are needed; with finite representations of recursion, instead, definitions and results must be tailored to cope with infinite behavior and thus use constructions (such as environments for recursion variables, memoization environments in deductions) that are meaningless for finite terms. Of course not every infinite term constructed by applying “⊕”, “+”, and “.” is acceptable. We require the term (i) to be regular, so that it can be seen as the solution of some recursive definitions [Courcelle 1983], and (ii) to satisfy a fairly standard contractivity condition requiring that recursion must be guarded by an i/o operation, which rules out meaningless terms of the form rec x = x + x.3 As we explain in full details in the Conclusion (§7), regularity is the only real restriction that limits the expressive power of contracts with respect to fully-fledged variants of ccs: the inclusion of other constructs—such as parallel composition, restriction, relabeling—would not only bring no increase in expressive power, but 3 Contractivity was introduced by Courcelle [Courcelle 1983] to rule out e.g. rec x = x, which is syntactically meaningless because it is satisfied by every regular tree, but it was not meant to rule out expressions such as rec x = x + x. The latter is syntactically meaningful since it denotes a particular regular tree but, in our context, it is semantically meaningless, because of the peculiar semantics of the “+” operator. Here we use contractivity in stricter interpretation, that is as a means for ruling out also terms that are semantically meaningless. From a technical viewpoint, these two conditions state that the binary relation ⊲ defined by σi ⊲ σ1 + σ2 and σi ⊲ σ1 ⊕ σ2 (i = 1, 2) is Noetherian (that is, strongly normalizing). This gives an induction principle on terms, principle that we will use without any further explicit reference to the relation ⊲. TO APPEAR IN ACM Transactions on Programming Languages and Systems 8 · Castagna, Gesbert, and Padovani also result misplaced in our context since these constructs describe the internal service behavior in a framework in which only the external behavior matters. 2.2 Examples In this section we relate our contract language to existing technologies for specifying service protocols. 2.2.1 Message exchange patterns in wsdl. The Web Service Description Language [Chinnici et al. 2007; Chinnici et al. 2007] permits to describe and publish abstract and concrete descriptions of Web services. Such descriptions include the schema of messages exchanged between client and server, the name and type of operations that the service exposes, as well as the locations (urls) where the service can be contacted. In addition, it defines interaction patterns (called message exchange patterns or meps in version 2.0 of wsdl) determining the order and direction of the exchanged messages. In particular, wsdl 2.0 predefines four message exchange patterns for describing services where the interaction is initiated by clients. Let us shortly discuss how the informal plain English semantics of these patterns can be formally defined in our contract language. When the mep is inOnly or robustInOnly, communication is basically asynchronous: the client can only send an In message containing the request. If the pattern is robustInOnly the service may optionally send back a Fault message indicating that an error has occurred. When the mep is inOut or inOptOut, communication is basically synchronous: the client sends an In message containing the request and the service sends back either an Out message containing the response or a Fault message. If the pattern is inOptOut, then the Out message is optional. These four patterns can be encoded in our contract language as follows: inOnly robustInOnly inOut inOptOut = = = = In In.(0 ⊕ Fault) In.(Out ⊕ Fault) In.(0 ⊕ Out ⊕ Fault) Intuitively, a client that is capable of invoking a service whose mep is inOnly will also interact successfully with a service whose mep is robustInOnly (depth subtyping). Conversely, a client that is capable of invoking a service whose mep inOptOut will also interact successfully with services whose mep is either inOut, or robustInOnly (since they are more deterministic), or even inOnly. Indeed, such a client must be able to handle both a communication that terminates and a Fault or Out message. On the other hand, a client that interacts with a service whose mep is inOut will not (always) interact successfully with a service whose mep is inOptOut. The client assumes that it will always receive either an Out or a Fault message, but inOptOut does not give this guarantee. 2.2.2 Conversations in wscl. The wsdl message exchange patterns cover only the simplest forms of interaction between a client and a service. More involved forms of interactions, in particular stateful interactions, cannot be captured if not as informal annotations within the wsdl interface. The Web service conversation language wscl [Banerji et al. 2002] provides a more general specification language for describing complex conversations between two communicating parties, by means TO APPEAR IN ACM Transactions on Programming Languages and Systems A Theory of Contracts for Web Services in: Login out: ValidLogin out: InvalidLogin · 9 [InvalidLogin] [ValidLogin] in: Query out: Catalog in: Buy out: Valid out: Invalid in: AddToCart [Valid] [Invalid] in: in: CreditCard out: Valid out: Invalid [Valid] [Invalid] Fig. 1. Buy in: Logout in: BankTransfer out: Valid out: Invalid [Valid] [Invalid] Contract of an e-commerce service as a wscl diagram. of an activity diagram (Figure 1). The diagram is made of interactions which are connected with each other by means of transitions. An interaction is a basic one-way or two-way communication between the client and the server. Two-way communications are just a shorthand for two sequential one-way interactions. Each interaction has a name and a list of document types that can be exchanged during its execution. A transition connects a source interaction with a destination interaction. A transition may be labeled by a document type if it is active only when a message of that specific document type was exchanged during the previous interaction. Below we encode the contract of a simplified e-commerce service (Figure 1) where the client is required to login before it can select and buy items from the store. If the login is successful, the client can issue one or more queries and add items to the shopping cart. The client can buy the items in the shopping cart using one TO APPEAR IN ACM Transactions on Programming Languages and Systems · 10 Castagna, Gesbert, and Padovani of two payment methods, either with credit card or with a bank transfer. At any time, the client can choose to logout and leave the store. In case of purchase, the service reports whether the purchase was valid. We can represent the contract of Figure 1 (without the dashed part, which represents an extension discussed later), as the regular contract σ1 defined by the equations: def σ1 = Login.(InvalidLogin ⊕ ValidLogin.σ2 ) def σ2 = Query.Catalog.(σ2 + Logout + AddToCart.(σ2 + Buy.σ3 )) def σ3 = Logout + CreditCard.(Valid⊕Invalid) + BankTransfer.(Valid⊕Invalid) Unlabeled transitions in Figure 1 correspond to external choices in the contract, whereas labeled transitions correspond to internal choices. The use of recursion in the definition of σ2 , corresponds to the presence of (two) cycles in the wscl graph. Let us recast in this setting the three forms of subtyping we described in the Introduction (§1). First, it is clear that clients compliant with the service above will always be happy with more deterministic servers that, for instance, never deny the access (InvalidLogin ⊕ ValidLogin  ValidLogin) as well as with servers that offer longer interactions, such as the fact of proposing an invoice after the payment (Valid  Valid.Invoice). Now assume that the service is extended (by width subtyping) with “1-click ordering” capability, so that if the client has already bought items, perhaps in some previous sessions, then it is allowed to buy further items without adding them to the shopping cart and without the need to re-send the payment information (dashed part in Figure 1). The contract σ2 would change to σ2′ as follows: def σ2′ = Query.Catalog.(σ2′ + Logout + AddToCart.(σ2′ + Buy.σ3 ) + σ4 ) def σ4 = Buy.(Valid ⊕ Invalid) It would be desirable for clients that are compliant with the former service to be compliant with this service as well. After all, the extended service offers more than the old one. However, the transitivity problem we pointed out in the Introduction (§1) might arise. Indeed, assume that, before the extension, we have a client trying to send a Buy message right after receiving a catalog from the service (e.g., because it was written in a generic way so as to be able to interact with some different service in which the Buy operation is used) and that after sending such a message it behaves according to some contract ρB . Assume also that this client is compliant with the former service for the simple reason that, since the former service did not provide a “1-click ordering” capability, whatever contract ρB the client provided after the Buy action was irrelevant to establish compliance. If we extend the services by “1-click ordering” capability without using filters, then this client may result no longer compatible with the service, specifically if ρB is incompatible with the continuation of σ4 after Buy. In order to avoid that the extension of the service disrupts compatibility with existing clients, the “1-click ordering” extension must resort to a filter that will block any Buy message that immediately follows a Catalog message (see §3.2.1 for a precise definition of the filter and Remark 5.5 for a finer analysis of this example). TO APPEAR IN ACM Transactions on Programming Languages and Systems · A Theory of Contracts for Web Services 2.3 11 Semantics Contracts describe the behavior of the processes that implement them. This behavior is determined by the actions that are offered by a process and the way in which they are offered (note that both σ ⊕ τ and σ + τ offer the same actions). This is formally stated by the Definitions 2.2 and 2.4 given below. α Definition 2.2 (transition). Let σ 7−X → be the least relation such that: α 0 7−X → α 6= β α β.σ 7−X → α α α σ 7−X → τ 7−X → α σ ⊕ τ 7−X → α σ 7−X → τ 7−X → α σ + τ 7−X → α The transition relation of contracts, noted 7−→, is the least relation satisfying the rules: α α.σ 7−→ σ α α σ− 7 → σ ′ τ 7−X → α σ + τ 7−→ σ ′ α α σ− 7 → σ ′ τ 7−X → α σ ⊕ τ 7−→ σ ′ σ 7−→ σ ′ τ 7−→ τ ′ α σ + τ 7−→ σ ′ ⊕ τ ′ σ 7−→ σ ′ τ 7−→ τ ′ α σ ⊕ τ 7−→ σ ′ ⊕ τ ′ α α α σ 7−X → τ 7−→ τ ′ α σ + τ 7−→ τ ′ α α α α σ 7−X → τ 7−→ τ ′ α σ ⊕ τ 7−→ τ ′ α α α We write σ 7−→ if there exists σ ′ such that σ 7−→ σ ′ . α The relation 7−→ is different from standard transition relations for ccs processes [Milα ner 1982]. For example, there is always at most one contract σ ′ such that σ 7−→ σ ′ , while this is not the case in ccs (the process a.b + a.c has two different a-successor states: b and c). This mismatch is due to the fact that contract transitions define the evolution of conversation protocols from the perspective of an external coma municating party. Thus a.b + a.c 7−→ b ⊕ c because, once the action a has been performed, the communicating party is not aware of which branch has been chosen. On the contrary, ccs transitions define the evolution of processes from the perspective of the process itself (see the section about related work (§6) for a detailed discussion about this difference in perspective). Notation 2.3. We use init(σ) to denote the set of actions that can be immediα ately emitted by σ, that is init(σ) = {α | σ 7−→}. α Let σ 7−→. We write σ(α) for the unique continuation of σ after α, that is, the α contract σ ′ such that σ 7−→ σ ′ . We extend the notion of continuation to sequences of actions. Let ϕ denote a possibly empty, finite string of actions. If ϕ = ε, then ϕ ϕ α ϕ′ σ 7−→ σ and we have σ(ϕ) = σ; if ϕ = αϕ′ , then σ 7−→ σ ′ if σ 7−→ σ ′ 7−→ σ ′′ and we have σ(ϕ) = σ ′′ . The labeled transition system above describes the actions offered by (a service implementing) a contract, but does not show how these actions are offered. In particular the actions offered by an external choice are all available at once while the actions offered by different components of an internal choice are mutually exclusive. Such a description is given by the ready sets that are observable for a given contract: TO APPEAR IN ACM Transactions on Programming Languages and Systems 12 · Castagna, Gesbert, and Padovani Definition 2.4 (observable ready sets). Let Pf (N ∪ N ) be the set of finite subsets of N ∪ N , called ready sets. Let also σ ⇓ r be the least relation between contracts σ in Σ and ready sets r in Pf (N ∪ N ) such that: 0⇓∅ α.σ ⇓ {α} σ⇓r τ ⇓s σ+τ ⇓r∪s σ⇓r σ⊕τ ⇓r τ ⇓r σ⊕τ ⇓r Notation 2.5. We use the convention that the bar operation is an involution, a = a, and for a given ready set r we define its complementary ready set as co(r) = {α | α ∈ r}. 2.4 The problem We now possess all the technical instruments to formally state the problem we described in the Introduction (§1) and recalled at the end of §2.2. This first requires the precise definition of compliance. Recall that, intuitively, the behavior of a client complies with the behavior of a service if for every set of actions that the service may offer, the client either synchronizes with one of them, or it terminates successfully. The behavior of clients, as well as that of services, is described by contracts. Therefore we need to define when a contract ρ describing the behavior of a client complies with a contract σ describing the behavior of a service. For this we reserve a special action e (for “end”) that can occur in client contracts and that represents the ability of the client to successfully terminate. Then we require that, whenever no further interaction is possible between the client and the service, the client is in a state where this action is available. Definition 2.6 (strong compliance). C is a strong compliance relation if (ρ, σ) ∈ C implies that: (1 ) ρ ⇓ r and σ ⇓ s implies either e ∈ r or co(r) ∩ s 6= ∅, and α α (2 ) ρ 7−→ ρ′ and σ 7−→ σ ′ implies (ρ′ , σ ′ ) ∈ C . We use ⊣ to denote the largest strong compliance relation. In words the definition above states that a client of contract ρ is compliant with a service of contract σ if (1) for every possible combination s and r of the independent choices of the service and the client, either there is an action in the client choice that can synchronize with an action among those offered by the service (co(r) ∩ s 6= ∅) or the client terminates successfully (e ∈ r), and (2) whenever a synchronization happens, the continuation of the client after it is compliant with the continuation of the service ((ρ′ , σ ′ ) ∈ C ). Once we have such a definition it is natural to define the subcontract relation in terms of compliance. Intuitively, (client) contracts are seen as “tests” for comparing (service) contracts. Two (service) contracts are related if so are the sets of (client) contracts compliant with them [De Nicola and Hennessy 1984]. Definition 2.7 (strong subcontract). The contract σ is a strong subcontract of the contract τ , written σ ⊑ τ , if and only if for all ρ we have ρ ⊣ σ implies ρ ⊣ τ . We write σ ≃ τ if σ ⊑ τ and τ ⊑ σ. TO APPEAR IN ACM Transactions on Programming Languages and Systems A Theory of Contracts for Web Services · 13 This definition corresponds to giving a set theoretic semantics to service contracts which are thus interpreted as the set of their compliant clients. Thus ⊑ is interpreted as set-theoretic inclusion. As usual with testing semantics, it is hard to establish a relationship between two contracts because the set of clients that are strongly compliant is infinite. A direct definition of the preorder is therefore preferred: Definition 2.8 (coinductive strong subcontract). S is a coinductive strong subcontract relation if (σ, τ ) ∈ S implies that (1 ) τ ⇓ r implies that there exists s ⊆ r such that σ ⇓ s, and α α (2 ) τ 7−→ τ ′ implies σ 7−→ σ ′ and (σ ′ , τ ′ ) ∈ S . Theorem 2.9. ⊑ is the largest coinductive strong subcontract relation. Proof. First of all we prove that ⊑ is a coinductive subcontract relation. Assume σ ⊑ τ . As regards condition (1) in the definition of coinductive strong subcontract relation, let r1 , . . . , rn be the ready sets of σ. By contradiction, assume that there exists r′ such that τ ⇓ r′ and for every 1 ≤ i ≤ n there exists αi ∈ ri def P such that αi 6∈ r′ . Let ρ = 1≤i≤n αi .e. Then ρ ⊣ σ but ρ 6⊣ τ , which is not possible. Hence condition (1) is satisfied. As regards condition (2) in the definiα tion of coinductive strong subcontract relation, assume τ 7−→. By contradiction, α α assume σ 7−X →. Then e + α ⊣ σ but e + α 6⊣ τ , which is not possible. Hence σ 7−→. Now we have to prove that σ(α) ⊑ τ (α). Let ρ′ be such that ρ′ ⊣ σ(α). Then e + α.ρ′ ⊣ σ hence e + α.ρ′ ⊣ τ , thus ρ′ ⊣ τ (α) by definition of strong compliance. Hence σ(α) ⊑ τ (α) because ρ′ is arbitrary. Now we prove that ⊑ is indeed the largest coinductive subcontract relation, namely that every coinductive subcontract relation is included in ⊑. Let S be a coinductive strong subcontract relation and let (σ, τ ) ∈ S . Let ρ ⊣ σ, then there exists a strong compliance relation C such that (ρ, σ) ∈ C . To get ρ ⊣ τ it is sufficient to prove that def C ′ = {(ρ′ , τ ′ ) | ∃σ ′ , (ρ′ , σ ′ ) ∈ C ∧ (σ ′ , τ ′ ) ∈ S } is a strong compliance relation, since (ρ, τ ) ∈ C ′ . Let (ρ′ , τ ′ ) ∈ C ′ and let σ ′ be the corresponding contract given by the definition of C ′ . As regards condition (1) in Definition 2.6, let ρ′ ⇓ r and τ ′ ⇓ s. If e ∈ r there is nothing to prove. Assume e 6∈ r. From (σ ′ , τ ′ ) ∈ S there exists s′ ⊆ s such that σ ′ ⇓ s′ . From (ρ′ , σ ′ ) ∈ C we know co(r) ∩ s′ 6= ∅, hence we conclude co(r) ∩ s 6= ∅. As regards condition (2) in α α α Definition 2.6, assume ρ′ 7−→ and τ ′ 7−→. From (σ ′ , τ ′ ) ∈ S we know that σ ′ 7−→ ′ ′ ′ ′ ′ ′ and (σ (α), τ (α)) ∈ S . From (ρ , σ ) ∈ C we know that (ρ (α), σ (α)) ∈ C , hence we conclude (ρ′ (α), τ ′ (α)) ∈ C ′ by definition of C ′ . It turns out that the relation ⊑ is the must testing preorder as defined in [De Nicola and Hennessy 1984; 1987]. This relation is well studied and it enjoys interesting properties. In particular it is a precongruence with respect to prefixing, internal and external choices, and also a ⊕ b ⊑ a, which is one of the desirable properties for the relation  that we informally defined in the Introduction (§1), holds. However ⊑ is stronger than  since, for example, a 6⊑ a + b. Indeed a.e + b ⊣ a TO APPEAR IN ACM Transactions on Programming Languages and Systems 14 · Castagna, Gesbert, and Padovani but a.e + b 6⊣ a + b. In general, the must preorder allows neither width nor depth extensions of contracts. It should also be noted that, while ⊑ coincides with the must testing preorder, the notion of compliance that we use differs significantly from the notion of “passing a test” in the classical testing framework. For example, on the one hand we have e + b.c.e 6⊣ b.d because the client e + b.c.e gets stuck if it synchronizes on b. On the other hand, the process b.d “passes the test” e + b.c.e because, at some point during the interaction, the test/client can emit e. In the context of Web services, the fact that a client may successfully terminate at some stage of the interaction does not automatically imply that the client will eventually terminate successfully regardless of the synchronizations occurring on later stages. In summary, the fact that ⊑ coincides with the must testing preorder may seem obvious as both relations deal with reduction of nondeterminism, but this coincidence is not at all obvious a priori. A more detailed discussion of these aspect, also taking into account diverging behaviors, can be found in [Laneve and Padovani 2007]. In previous work [Carpineti et al. 2006] an attempt was made to directly relate two contracts σ and τ depending on their form, rather than on the sets of their clients. Let dual(σ) denote the dual contract of σ which, roughly, is obtained by replacing in σ every action by its coaction, 0 by e, every internal choice by an external one, and viceversa (the formal definition is slightly more involved and requires first to transform σ into the normal form of Definition 3.14 and then apply the transformation described above; see [Carpineti et al. 2006] for details). Intuitively dual(σ) denotes the contract of a “canonical” client complying with σ services. Then using this intuition one can informally define a new relation on service contracts as: def σ ⋉ τ ⇐⇒ dual(σ) ⊣ τ (2) In words, a contract σ is a subcontract of τ if and only if its canonical client complies with τ (see the proof of Theorem 3.4 for a formal definition of ⋉ and a more precise characterization of dual). This relation is nearly what we are looking for. For instance now we have a⊕b.c ⋉ a and a ⋉ a + b.d, since dual(a ⊕ b.c) = a.e + b.c.e ⊣ a and dual(a) = a.e ⊣ a + b.d. Unfortunately, ⋉ is not a preorder since transitivity does not hold: a.e + b.c.e 6⊣ a + b.d implies that a ⊕ b.c 6⋉ a + b.d. The reason for such a failure is essentially due to the fact that in establishing a ⊕ b.c ⋉ a and a ⋉ a + b.d we are restricting compliance to conversations in which no synchronization on the name b happens. While contracts deal with non-determinism that is internal to each process—be it a client or a service—, they cannot handle the “system” non-determinism that springs from process synchronization. In the example above, the failure results from the interaction of two external choices, a.e + b.c.e and a + b.d, which yields nondeterminism at system level and which does not prevent a priori a synchronization on the name b. By preventing the synchronization on the name b, the client a.e + b.c.e can terminate successfully. In summary, the strong subcontract relation implements a safe substitutability relation for services that are compatible, but is excessively demanding because it takes into account every possible synchronization. Our theory of contracts will define a safe substitutability relation for services that can be made compatible. TO APPEAR IN ACM Transactions on Programming Languages and Systems A Theory of Contracts for Web Services · 15 3. THEORY OF CONTRACTS At the end of the previous section we said that we wanted a subcontract relation σ  τ such that a service with contract τ can be made compatible with a service with contract σ. The keypoint of the discussion is the “can be made”. Of course we do not want to consider arbitrary transformations of the service, e.g. transformations that alter the semantics of the service. In fact, we cannot hope to affect in any way the internal non-determinism of a service as the service is typically considered as an unmodifiable black box. Instead we look for transformations that embed a τ service in a world of clients of σ servers so that such clients will perceive their interaction as being carried over a service with contract σ (or possibly a more deterministic one). Roughly speaking we want to filter out all behaviors of the τ contract that do not belong to the possible behaviors of σ world, and leave the others unchanged. This is, precisely, the characterization of an explicit coercion from τ to σ (recall that the subcontract relation is the inverse of a service subtyping relation; cf. Footnote 1 page 4): an embedding function that maps possible behaviors of τ into the same behaviors of σ (thus, it does not add new computation). 3.1 Weak subcontract relation The idea is that σ  τ if there exists some (possibly empty) set of actions belonging to the world of τ that, if shielded, can make a τ service appear as a σ service. This is formalized by the following definition: Definition 3.1 (weak subcontract). W is a weak subcontract relation if (σ, τ ) ∈ W implies that if τ ⇓ r, then there exists sr ⊆ r such that (1) σ ⇓ sr and (2) for all α ∈ sr we have (σ(α), τ (α)) ∈ W . We denote by  the largest weak subcontract relation. The basic intuition about the weak subcontract relation is that a client that interacts successfully with a service with contract σ must be able to complete whatever ready set is chosen from σ. If we want to replace the service with another one whose contract is τ , we require that whatever ready set r is chosen from τ there is a smaller one sr ⊆ r in σ such that all of the continuations with respect to the actions in sr are in the weak subcontract relation. However, in order to avoid interferences we might need to filter out the actions in r \ sr . First of all notice that the weak subcontract relation includes the strong one (condition (1) is essentially the same and condition (2) is weaker), so that, for example, a ⊕ b.c  a holds. Additionally, we also have a  a + b.d since a service with contract a + b.d can be made to behave as a service with contract a by filtering out the b action. On the other hand, a 6 a⊕b.c since there is no way to make a⊕b.c behave as a by simply filtering out actions (filtering out the b action from a ⊕ b.c yields a ⊕ 0, not a). Finally, we also have a ⊕ b.c  a + b.d, again by filtering out the b action. In this case, the filtered service (a + b.d) is not made equivalent to the smaller service (a ⊕ b.c) but rather to one of its more deterministic behaviors (a). 3.1.1 Weak compliance. In contrast with the “strong” case, for the weak subcontract relation it was more intuitive to provide its coinductive characterization first. We now face the problem of understanding which notion of compliance induces the weak subcontract relation. As we will see, this is an essential intermediate TO APPEAR IN ACM Transactions on Programming Languages and Systems 16 · Castagna, Gesbert, and Padovani step as it provides the necessary insight for devising the practical solution to the problems described in §2.4. Definition 3.2 (weak compliance). D is a weak compliance relation if (ρ, σ) ∈ D implies that there exists a finite set of actions a ⊆ N ∪ N such that: (1 ) ρ ⇓ r and σ ⇓ s implies e ∈ r or co(r) ∩ a ∩ s 6= ∅, and α α (2 ) α ∈ a, ρ 7−→ ρ′ and σ 7−→ σ ′ implies (ρ′ , σ ′ ) ∈ D. We denote by ⊣⊣ the largest weak compliance relation. The existence of the set a in the above definition is independent of the ready sets of the client and of the service. This reflects the fact that the internal non-determinism of the interacting parties cannot be affected. The following theorem proves that ⊣⊣ is the compliance relation inducing . Theorem 3.3. σ  τ if and only if for all ρ, ρ ⊣⊣ σ implies ρ ⊣⊣ τ . Proof. (⇒) Let W be a weak subcontract relation such that (σ, τ ) ∈ W and assume ρ ⊣⊣ σ. Let D be a weak compliance relation such that (ρ, σ) ∈ D. To get ρ ⊣⊣ τ it suffices to prove that def D ′ = {(ρ′ , τ ′ ) | ∃σ ′ , (ρ′ , σ ′ ) ∈ D ∧ (σ ′ , τ ′ ) ∈ W } is a weak compliance relation since (ρ, τ ) ∈ D ′ . Let (ρ′ , τ ′ ) ∈ D ′ , and let σ ′ be the corresponding contract given by the definition of D ′ . Let a′ be the set of actions given by (ρ′ , σ ′ ) ∈ D. Let s1 , . . . , sn be the ready sets of τ ′ . Because (σ ′ , τ ′ ) ∈ W , for each si there exists a ready set s′i ⊆ si of σ ′ which satisfies the conditions Sn def of Definition 3.1. Let a = a′ ∩ i=1 s′i . We now prove that this a satisfies the conditions of Definition 3.2 for (ρ′ , τ ′ ). As regards condition (1), assume ρ′ ⇓ r and τ ′ ⇓ s. Then s = si for some i. If e ∈ r there is nothing to prove. Assume e 6∈ r. Then from (ρ′ , σ ′ ) ∈ D we know that co(r) ∩ a′ ∩ s′i 6= ∅. We have a′ ∩ s′i = a ∩ s′i ⊆ a ∩ si , hence we conclude co(r) ∩ a ∩ si 6= ∅. As regards α α α condition (2), assume α ∈ a and ρ′ 7−→ and τ ′ 7−→. Then σ ′ 7−→, because α is ′ ′ ′ ′ in some si ; and α is also in a , thus (ρ (α), σ (α)) ∈ D by definition of a′ . From α ∈ s′i we also have that (σ ′ (α), τ ′ (α)) ∈ W . We conclude (ρ′ (α), τ ′ (α)) ∈ D ′ by definition of D ′ . (⇐) We prove that def W = {(σ, τ ) | ∀ρ, ρ ⊣⊣ σ ⇒ ρ ⊣⊣ τ } is a weak subcontract relation. Let (σ, τ ) ∈ W . As regards condition (1) in Definition 3.1, let r1 , . . . , rn be all the (distinct) ready sets of σ. By contradiction, suppose that there exists a ready set r′ such that τ ⇓ r′ and for every 1 ≤ i ≤ n def P we have ri 6⊆ r′ , namely there exists αi ∈ ri \ r′ . Let ρ = 1≤i≤n αi .e. By construction we have ρ ⊣⊣ σ but ρ 6⊣⊣ τ , which is not possible. As regards condition (2) in Definition 3.1, let τ ⇓ r′ and k ∈ {1, . . . , n} be such that rk ⊆ r′ and rk is minimal among the ri ’s. We take rk as the ready set sr′ in the definition of weak subcontract relation. If rk = ∅, then condition (2) trivially holds. Assume rk 6= ∅. For every α ∈ rk , let ρα be a client contract such that ρα ⊣⊣ σ(α). Notice that for TO APPEAR IN ACM Transactions on Programming Languages and Systems A Theory of Contracts for Web Services · 17 every i ∈ {1, . . . , n} \ {k}, we have ri \ rk 6= ∅ because the ri ’s are all distinct and rk is minimal. Let L def P ρ = i∈{1,...,n}\{k},β∈ri \rk β.e + α∈rk α.ρα . By construction ρ ⊣⊣ σ, hence ρ ⊣⊣ τ by definition of W . Furthermore, the set a in ρ ⊣⊣ σ must be at least as large as rk because, by construction of ρ, ρ cannot be (weakly) compliant with σ if any of the actions in rk is filtered out. Thus, for every α ∈ rk , from ρ ⊣⊣ σ we derive ρα ⊣⊣ σ(α), hence ρα ⊣⊣ τ (α). Because the ρα ’s are arbitrary, we conclude (σ(α), τ (α)) ∈ W by definition of W . 3.1.2 Comparison with other relations. In §2.4 we said that the relation ⋉ defined by equation (2) was nearly what we sought for, but for the lack of transitivity it was not a preorder. The following theorem shows that  obviates this problem. Theorem 3.4. The subcontract relation  is the transitive closure of ⋉. Proof. We did not define dual(σ) formally here, so we will give an equivalent definition of ⋉ not based on the notion of dual contract, which was also the definition used in [Carpineti et al. 2006], and just give the intuition of how we obtain it using dual(σ). The important property about dual(σ) is that its ready sets are defined as all the possible sets obtained by picking one action in each ready set of σ, and taking their co-actions. This can be seen by looking at the definition of observable ready sets and thinking that we just exchange internal and external choices. Now if we look at Definition 2.6 and assume (dual(σ), τ ) ∈ C where C is a strong compliance relation, then the first condition says that any ready set of τ contains at least one action from each ready set of dual(σ), which is equivalent to the fact that it contains a ready set of σ. Translation of condition (2) is straightforward, so we get that ⋉ is the largest relation R such that (σ, τ ) ∈ R implies: (1) τ ⇓ r implies σ ⇓ s for some s ⊆ r, and α α (2) σ 7−→ and τ 7−→ implies (σ(α), τ (α)) ∈ R. Now let us prove that  is the transitive closure of the relation thus defined. Note that the condition (1) is the same in both relations, and that condition (2) in Definition 3.1 is a weakened version of condition (1) for R, so obviously ⋉ ⊆  and so does the transitive closure of ⋉,  being itself transitive. So what we have to show is that two contracts related by  are also related by the transitive closure of ⋉. Let W be a weak subcontract relation such that (σ, τ ) ∈ W . Let L P def R1 = {(σ, τ ⇓r α∈sr α.σ(α)) | (σ, τ ) ∈ W } L P def R2 = {( τ ⇓r α∈sr α.σ(α), τ ) | (σ, τ ) ∈ W } where, for each ready set r of τ , we write sr for the ready set of σ such that sr ⊆ r that satisfies condition (2) in Definition 3.1. It is trivial to verify that R1 ∪R2 ⊆ ⋉, from which we conclude that W is included in the transitive closure of ⋉. For what concerns the inclusion of the strong relation in the weak one note that if we compare Definition 3.1 with Definition 2.8, we see that they differ on the set of α’s considered in condition (2). The latter requires that whatever interaction may happen between a client and a server, the relation must be satisfied by the TO APPEAR IN ACM Transactions on Programming Languages and Systems · 18 Castagna, Gesbert, and Padovani continuations. The former instead requires this to happen only for interactions on actions that are expected for the smaller contract. This means that with the weak subcontract relation all the actions that are not expected by the smaller contract must not take part in the client-server interaction. If we want to replace a server by a different server with a (weak) super-contract, then we must ensure that the client is shielded from these unexpected actions. The technical instrument to ensure it are the filters we define next. 3.2 Filters A filter is the specification of a (possibly infinite) prefix-closed regular set of traces: Definition 3.5 (filters). A filter is a possibly infinite term coinductively generated by the following grammar. f ::= 0 | α.f | f ∨ f | f ∧ f and satisfying the following conditions: (1 ) filter terms are regular trees, (2 ) on every infinite branch of a filter term there are infinitely many occurrences of the prefix constructor. The filter 0 is the one that allows no actions; the filter α.f allows those traces beginning with action α and followed by the traces allowed by f ; the filter f ∨ g represents the disjunction of f and g and it allows those traces that are allowed either by f or by g; finally, the filter f ∧ g represents the conjunction of f and g and it allows those traces that are allowed by both f and g. The conditions of regularity and contractivity are standard. The latter also provides a well-founded order for the induction (cf. Footnote 3) used in the next definitions. α α Much like contracts, filters too are equipped with the relations 7−X → and 7−→. α Definition 3.6 (filter transition). Let f 7−X → be the least relation such that: α 0 7−X → α 6= β α β.f 7−X → α α f 7−X → g 7−X → α f ∨ g 7−X → α α f 7−X → α f ∧ g 7−X → g 7−X → α f ∧ g 7−X → α The transition relation of filters, noted 7−→, is the least relation satisfying the rules: α α α.f 7−→ f α f 7−→ f ′ g 7−→ g ′ α f ∨ g 7−→ f ′ ∨ g ′ α α f 7−→ f ′ g 7−X → α f ∨ g 7−→ f ′ α α f 7−→ f ′ g 7−→ g ′ α f ∧ g 7−→ f ′ ∧ g ′ α and closed under mirror cases for the disjunction. We write f 7−→ if there exists α f ′ such that f 7−→ f ′ . This transition relation allows us to state more formally what we said above about sets of traces: the semantics of a filter is the prefix-closed regular language defined def α on the alphabet of actions by Jf K = {ε} ∪ {αϕ | f 7−→ f ′ , ϕ ∈ Jf ′ K}. Then it can be easily checked that Jf ∨ gK = Jf K ∪ JgK and Jf ∧ gK = Jf K ∩ JgK (notice that the intersection and the union of prefix-closed sets is again prefix-closed). We consider two filters to be equal if they have W the same semantics and adopt a notation similar to the one for contracts: we write i∈{1,...,n} fi for f1 ∨ f2 ∨ · · · ∨ fn TO APPEAR IN ACM Transactions on Programming Languages and Systems A Theory of Contracts for Web Services · 19 W V and i∈{1,...,n} fi for f1 ∧ f2 ∧ · · · ∧ fn . By convention we have i∈∅ fi = 0. The application of a filter f to a contract σ, written f (σ), produces another contract where only the allowed actions are visible: Definition 3.7 (filter application). The application of a filter f to a contract σ, written f (σ), is inductively defined as follows: f (0) f (α.σ) f (α.σ) f (σ + τ ) f (σ ⊕ τ ) = = = = = 0 α 0 if f − 7X→ α α.f ′ (σ) if f 7−→ f ′ f (σ) + f (τ ) f (σ) ⊕ f (τ ) Filter application is monotone with respect to the strong subcontract preorder. This property, which is fundamental in proving most of the results that follow, guarantees that equivalent contracts remain equivalent if filtered in the same way. Proposition 3.8. σ ⊑ τ implies f (σ) ⊑ f (τ ). Proof. It is sufficient to show that def S = {(f (σ), f (τ )) | σ ⊑ τ } is a strong subcontract relation. Let (f (σ), f (τ )) ∈ S . As regards condition (1) in the definition of strong subcontract relation, assume f (τ ) ⇓ s. Then there exists s′ such that τ ⇓ s′ and s = f (s′ ). From σ ⊑ τ we derive that there exists r such that σ ⇓ r and r ⊆ s′ . We observe f (r) ⊆ f (s′ ) = s and we conclude by observing α α that f (σ) ⇓ f (r). As regards condition (2), assume f (τ ) 7−→. Then f 7−→ f ′ α α and τ 7−→. From the hypothesis σ ⊑ τ we derive σ 7−→ and σ(α) ⊑ τ (α). We α conclude f (σ) 7−→ and (f (σ)(α), f (τ )(α)) ∈ S because f (σ)(α) = f ′ (σ(α)) and f (τ )(α) = f ′ (τ (α)). Filters allow us to express the weak subcontract relation in terms of the strong one: Theorem 3.9. σ  τ if and only if there exists a filter f such that σ ⊑ f (τ ). Proof. With an abuse of notation we write f (r), the application of a filter f α to a set of actions r, for the set {α ∈ r | f 7−→}. (⇐) Let S be a coinductive strong subcontract relation. We show that def W = {(σ, τ ) | ∃f, (σ, f (τ )) ∈ S } is a weak subcontract relation. Let (σ, τ ) ∈ W and let f be the corresponding filter. Regarding condition (1) in Definition 3.1, assume τ ⇓ r. From (σ, f (τ )) ∈ S we know that there exists s ⊆ f (r) such that σ ⇓ s and we conclude s ⊆ f (r) ⊆ r. Regarding condition (2) in Definition 3.1, take α ∈ s. From (σ, f (τ )) ∈ S we know α (σ(α), fα (τ (α))) ∈ S where f 7−→ fα . Hence we conclude (σ(α), τ (α)) ∈ W . (⇒) Let W be a weak subcontract relation. For every (σ, τ ) ∈ W , let def S a(σ, τ ) = τ ⇓r sr TO APPEAR IN ACM Transactions on Programming Languages and Systems 20 · Castagna, Gesbert, and Padovani where sr ⊆ r is such that σ ⇓ sr and sr satisfies condition (2) in Definition 3.1. Basically a(σ, τ ) is the set of actions that need not be shielded for proving that α α σ  τ . Notice that α ∈ a(σ, τ ) implies σ 7−→ and τ 7−→. For every (σ, τ ) ∈ W , let def W f(σ,τ ) = α∈a(σ,τ ) α.f(σ(α),τ (α)) . ϕ Notice that, for every contract σ, the set {σ(ϕ) | σ 7−→} is finite because σ is ϕ ϕ regular. Hence, for every (σ, τ ) ∈ W , the set of pairs {(σ(ϕ), τ (ϕ)) | σ 7−→, τ 7−→} is also finite, hence each f(σ,τ ) is well defined, regular, and, by construction, also contractive. Now we prove that def S = {(σ, f(σ,τ ) (τ )) | (σ, τ ) ∈ W } is a strong subcontract relation. Let (σ, f(σ,τ ) (τ )) ∈ S . As regards condition (1) in the definition of coinductive strong subcontract relation, assume τ ⇓ r. By definition of a(σ, τ ) there exists sr ⊆ r such that σ ⇓ sr and also sr ⊆ a(σ, τ ), so we conclude sr ⊆ f(σ,τ ) (r). As regards condition (2) in the definition of coinductive α α strong subcontract relation, assume f(σ,τ ) (τ ) 7−→. Then τ 7−→ and there exists sr α such that σ ⇓ sr and α ∈ sr , hence we obtain σ 7−→ and a(σ, τ ) 6= ∅. From (σ, τ ) ∈ W we derive (σ(α), τ (α)) ∈ W so we conclude (σ(α), f(σ(α),τ (α)) (τ (α))) ∈ S by definition of S . In terms of compliance this theorem yields the following corollary: Corollary 3.10. ρ ⊣⊣ σ if and only if there exists a filter f such that ρ ⊣ f (σ) Since ⊣ ensures that a client will either continuously interact or successfully terminate with a strongly compliant service, this corollary tells us that filters are the operational device that ensures the same property in case of weak compliance. Properties of client/service interactions are formally stated in §4. 3.2.1 Examples of filters. Let us consider again our example of a ⊕ b.c and a + b.d. These contracts are not related by the strong subcontract relation, but any client complying with the first one has to be ready to read on a and then terminate. Then, we see that the second one can be made compliant with any such client, because it is ready to write on a: so we are sure that synchronization on a is possible, and that if it occurs the client will terminate. The point is then to ensure that this synchronization will indeed occur and that the channel b will not be selected instead, which would lead to a deadlock. This is done by applying to a + b.d the filter f = a, which lets the sole action a pass. Formally, we have that f (a + b.d) = a, and a ⊕ b.c ⊑ a holds. We have already hinted in the introduction that to prove an inclusion such as a.b  (a.(a+b))+b.c filters must be able to selectively block along the computation, as b must be blocked only at the first step of the interaction and a only at the second step of the interaction. In this case the sought behavior is obtained by the singlethreaded filter f = a.b which when applied to the contract on the right yields the one on the left. Such fine-grainedness of filters is useful also in practice. Consider again the last example of §2.2.2, where we extended the service by a “1-click ordering” TO APPEAR IN ACM Transactions on Programming Languages and Systems A Theory of Contracts for Web Services Table I. · Deduction system for the weak subcontract relation. (weak) f : σ ≤ τ g ∧ I(τ ) 6 f f ∨g :σ ≤τ (trans) f : σ ≤ σ ′ g : σ ′ ≤ σ ′′ f ∧ g : σ ≤ σ ′′ (Prefix) f :σ≤τ α.f : α.σ ≤ α.τ σ + (σ ′ ⊕ σ ′′ ) = (σ + σ ′ ) ⊕ (σ + σ ′′ ) σ ⊕ (σ ′ + σ ′′ ) = (σ ⊕ σ ′ ) + (σ ⊕ σ ′′ ) α.σ + α.τ = α.(σ ⊕ τ ) α.σ ⊕ α.τ = α.(σ ⊕ τ ) (IChoice) f : σ ≤ σ′ f : τ ≤ τ ′ f : σ ⊕ τ ≤ σ′ ⊕ τ ′ (Must) I(σ) : σ ⊕ τ ≤ σ (EChoice) f : σ ≤ σ′ f : τ ≤ τ ′ f : σ + τ ≤ σ′ + τ ′ (Depth) 0:0≤σ σ+σ =σ σ+τ =τ +σ σ + (σ ′ + σ ′′ ) = (σ + σ ′ ) + σ ′′ σ+0=σ (e1) (e2) (e3) (e4) σ⊕σ =σ σ⊕τ =τ ⊕σ σ ⊕ (σ ′ ⊕ σ ′′ ) = (σ ⊕ σ ′ ) ⊕ σ ′′ (i1) (i2) (i3) (d1) (d2) (d3) (d4) 21 capability. We said that backward compatibility can be obtained by filtering out the newly added Buy action. But if we slightly expand the contract σ2′ . . . Catalog.(σ2′ + Logout + AddToCart.(σ2′ + Buy.σ3 ) + Buy.(· · · )) we observe that there are two distinct occurrences of the Buy action. In order to make a service with contract σ2′ implement the contract σ2 defined in §2.2.2, one must block the Buy action offered right after the Catalog action, but allow the old Buy action in the continuation of AddToCart to pass through. This is performed by the filter obtained from σ1 by replacing ∨ for every sum (either internal or external) occurring in it. 3.3 Deduction system for the weak subcontract relation Filters can also be used as proofs (in the sense of the Curry-Howard isomorphism) for the weak subcontract relation. More specifically, the idea is to devise a deduction system within which a derivable judgment of the form f : σ ≤ τ implies that σ  τ , and f is a filter that embeds services with contract τ into the world of σ-compliant clients. The definition of such a deduction system requires a few auxiliary notions. First we have to define the “identity” filter, that is the one that proves isomorphic (with respect to an interpretation of filters as morphisms) contracts. Definition 3.11. The identity filter for a contract σ, denoted by I(σ), is defined as def I(σ) = It is easy to see that I(σ)(σ) ≃ σ. W α σ 7−→σ ′ α.I(σ ′ ) TO APPEAR IN ACM Transactions on Programming Languages and Systems 22 · Castagna, Gesbert, and Padovani Then, we need a way for comparing filters. Filters can be compared according to the actions that they let pass. In the deduction system the need for comparing filters arises naturally in the weakening rule, where we want to replace a filter with a “larger” one (a filter that allows more actions). This can be done safely only if the larger filter does not thwart the functionality of the original filter by re-introducing actions that must be kept hidden. The filter pre-order will also be fundamental in §3.4, in order to define the “best” filter that proves σ  τ . Definition 3.12 (filter order). The ordering relation on filters 6 is the α α largest relation such that f 6 g and f 7−→ f ′ implies g 7−→ g ′ and f ′ 6 g ′ . We write f = g for f 6 g and g 6 f . In terms of filter semantics we have that f 6 g if and only if Jf K ⊆ JgK. This set-theoretic interpretation gives us the relation between operators ∨ and ∧ and filter ordering: the conjunction of two filters is their greatest lower bound, and their disjunction is their least upper bound. Table I defines the deduction system for . In the table we use a single axiom σ = τ as a shorthand for two axioms I(τ ) : σ ≤ τ and I(σ) : τ ≤ σ. The equalities and rule (Must) are well known since they fully characterize the strong subcontract relation, which coincides with the must preorder [De Nicola and Hennessy 1984; Hennessy 1988]. Notice that in the rule (Must) no action needs to be actually filtered out and the filter I(σ) ∨ I(τ ) would work as well. In fact, this is the only axiom for safely enlarging a contract without the intervention of any filter (which is expected since this axiom characterizes strong compliance, where filters are not needed). Rule (Depth) formalizes depth extension of contracts, where a contract can be prolonged if no action is made visible from the continuation. Rule (Weak) shows how to safely enlarge a filter f to f ∨ g: the premise g ∧ I(τ ) 6 f states that g may allow actions not allowed by f , provided that such actions are not those that have been hidden for the purposes of proving f : σ ≤ τ . Rule (Trans) is standard and the resulting filter is the composition filter. Three forms of (limited) pre-congruence follow. Rule (Prefix) is standard and poses no constraints. Rules (IChoice) and (EChoice) state the limited precongruence property for internal and external choices, respectively. The fundamental constraint is that two contracts combined by means of ⊕ or + can be enlarged, provided that they can be filtered in the same way. This requirement has an intuitive explanation: the filter that mediates the interaction of a client with a service is unaware of the internal choices that have been taken by the parties at a branching point. So, it must be possible to use the same filter that works equally well in all branches in order for the branches to be enlarged. 3.3.1 Properties. First of all notice that the deductions of the system we devised in the previous section may be infinite. However valid deductions are regular and contractive. This is a direct consequence of the regularity and contractivity of both contracts and filters. This is easily seen by observing that every deduction rule on the right hand side of Table I deconstructs in its premises either the filter or the contracts that occur in its consequence. This implies that infinite valid derivations are regular and that on every infinite branch of the derivation there are infinitely many applications of the rule (Prefix). TO APPEAR IN ACM Transactions on Programming Languages and Systems A Theory of Contracts for Web Services · 23 The deduction system is sound and complete with respect to  and the set of filters, in the sense that it proves all and only the pairs of contracts that are related according to Definition 3.1, and for any such pair it deduces all and only the filters that validate the pair according to Theorem 3.9. Theorem 3.13 (soundness). If f : σ ≤ τ , then σ ⊑ f (τ ). Proof. Let S be the least relation such that if f : σ ≤ τ is derivable, then (σ, f (τ )) ∈ S . It is sufficient to prove that S is a coinductive strong subcontract relation. Suppose f : σ ≤ τ is derivable, then (σ, f (τ )) ∈ S . We have to prove α α that f (τ ) ⇓ r implies σ ⇓ r′ and r′ ⊆ r and that f (τ ) 7−→ implies σ 7−→ and (σ(α), f (α)(τ (α))) ∈ S . We do so by induction on the maximum depth of an axiom or of an unnested instance of rule (Prefix) in the derivation tree of f : σ ≤ τ and by cases on the last rule applied. Such depth is always finite because contracts are contractive (hence, any infinite branch of the derivation tree must contain infinitely many instances of rule (Prefix)). In the following we only show the nontrivial cases. Assume the last rule was (Prefix). Then σ ≡ α.σ ′ , f ≡ α.f ′ , τ ≡ α.τ ′ , and ′ f : σ ′ ≤ τ ′ is derivable (we use ≡ to denote syntactic equality). Suppose f (τ ) ⇓ r. α α Then r = {α} and we notice that σ ⇓ {α}. We also notice that τ 7−→ and σ 7−→ and that this is the only possible transition for σ and τ . Furthermore, σ(α) ≡ σ ′ , f (α) ≡ f ′ , and τ (α) ≡ τ ′ , and we conclude because f ′ : σ ′ ≤ τ ′ is derivable by hypothesis, hence (σ(α), f (α)(τ (α))) ∈ S by definition of S . Assume the last rule was (Must). Then σ ≡ σ ′ ⊕τ and f ≡ I(τ ). Suppose f (τ ) ⇓ α α r. Then τ ⇓ r and σ ⇓ r. Suppose f (τ ) 7−→. We have two subcases: if σ ′ 7−→, then ′ ′ σ(α) ≡ σ (α) ⊕ τ (α) and we conclude f (α) : σ (α) ⊕ τ (α) ≤ τ (α) by (Must). If α σ ′ 7−X →, then σ(α) ≡ τ (α), hence we conclude by reflexivity of ≤ (indeed σ = σ ⊕ σ and I(σ) : σ ⊕ σ ≤ σ). Assume the last rule was (Depth). Then σ ≡ 0 and f ≡ 0. The condition on α ready sets of f (τ ) trivially holds because σ ⇓ ∅. Furthermore f (τ ) 7−X → for every α. Assume the last rule was (Weak). Then f ≡ f ′ ∨g, f ′ : σ ≤ τ , and g ∧I(τ ) 6 f ′ . Suppose f (τ ) ⇓ r. Since by definition f is less restrictive than f ′ , there is a r′ ⊆ r such that f ′ (τ ) ⇓ r′ . By induction hypothesis, σ has a ready set r′′ such that α r′′ ⊆ r′ , hence we conclude r′′ ⊆ r. Suppose f (τ ) 7−→. We have two subcases. If α g 7−→, then f (α) ≡ f ′ (α)∨g(α) and g(α)∧I(τ (α)) 6 f ′ (α). By induction hypothesis α σ 7−→ and f ′ (α) : σ(α) ≤ τ (α) is derivable, hence we derive f (α) : σ(α) ≤ τ (α) α by (Weak), so we conclude (σ(α), f (α)(τ (α))) ∈ S by definition of S . If g 7−X →, α then f (α) ≡ f ′ (α). By induction hypothesis σ 7−→ and f ′ (α) : σ(α) ≤ τ (α), hence (σ(α), f (α)(τ (α))) ∈ S by definition of S . Assume the last rule was (Trans). Then f ≡ f ′ ∧ g, f ′ : σ ≤ σ ′ , g : σ ′ ≤ τ . Suppose τ ⇓ r. By induction hypothesis σ ′ has a ready set r′ such that r′ ⊆ g(r). By induction hypothesis σ has a ready set r′′ such that r′′ ⊆ f ′ (r′ ) ⊆ f ′ (g(r)) = α α α f (r). Suppose f (τ ) 7−→. Then g(τ ) 7−→. By induction hypothesis σ ′ 7−→ and α α g(α) : σ ′ (α) ≤ τ (α) is derivable. From f (τ ) 7−→ we also derive f ′ 7−→, hence α α f ′ (σ ′ ) 7−→. Again by induction hypothesis, σ 7−→ and f ′ (α) : σ(α) ≤ σ ′ (α) is derivable. By (Trans) we conclude that f (α) : σ(α) ≤ τ (α) is derivable. Assume the last rule was (IChoice). Then σ ≡ σ ′ ⊕ τ ′ , τ ≡ σ ′′ ⊕ τ ′′ , f : σ ′ ≤ σ ′′ , TO APPEAR IN ACM Transactions on Programming Languages and Systems 24 · Castagna, Gesbert, and Padovani and f : τ ′ ≤ τ ′′ . Suppose f (τ ) ⇓ r and assume, without loss of generality, that f (τ ′′ ) ⇓ r. By induction hypothesis we obtain r′ such that τ ′ ⇓ r′ and r′ ⊆ α r. We conclude by observing that σ ⇓ r′ . Suppose f (τ ) 7−→. We have three subcases, depending on which contracts between σ ′′ and τ ′′ admit α-successors. α α α α Assume σ ′′ 7−→ and τ ′′ 7−→. By induction hypothesis σ ′ 7−→ and τ ′ 7−→ and f (α) : σ ′ (α) ≤ σ ′′ (α) is derivable and f (α) : τ ′ (α) ≤ τ ′′ (α) is derivable. Then we conclude f (α) : σ(α) ≤ τ (α) is also derivable because σ(α) ≡ σ ′ (α) ⊕ τ ′ (α) α α and τ (α) ≡ σ ′′ (α) ⊕ τ ′′ (α). On the other hand, suppose σ ′′ 7−→ but τ ′′ 7−X →. By ′ α ′ ′′ induction hypothesis σ 7−→ and f (α) : σ (α) ≤ σ (α) is derivable. We distinguish α α two further subcases. Either (i) τ ′ 7−→ or (ii) τ ′ 7−X →. In subcase (i) we have σ(α) ≡ σ ′ (α) ⊕ τ ′ (α). By (Must) we derive I(σ ′ (α)) : σ(α) ≤ σ ′ (α), from f (α) ∧ I(σ ′ (α)) 6 I(σ ′ (α)) and (weak) we obtain f (α) : σ(α) ≤ σ ′ (α) and now we conclude f (α) : σ(α) ≤ τ (α) by (trans) and noticing that τ (α) ≡ σ ′′ (α). In subcase (ii) we have σ(α) ≡ σ ′ (α) and now f (α) : σ(α) ≤ τ (α) is derivable by hypothesis. Assume the last rule was (EChoice). Then we can proceed as for the previous case, the only thing that changes being the reasoning on ready sets. The details are left to the reader. While the soundness of the deduction system can be easily established, its completeness is less immediate, but the proof of this fact follows a standard pattern: completeness is proved for a restricted class of contracts which are said to be in some normal form and then it is shown that it is always possible to rewrite an arbitrary contract to an equivalent one which is in normal form by using the axioms. As regards the actual definition of the normal form, we notice that it is always possible to add new ready sets to a given contract σ without altering its semantics (according to ≃), so long as I(σ) does not change and the new ready sets contain older ones: for example, σ ⊕ τ ≃ σ ⊕ τ ⊕ (σ + τ ). If we saturate the set of ready sets of a contract by adding to it every possible ready set meeting the conditions above, we can build a unique (up to commutativity and associativity) normal form for each equivalence class. This normal form is defined as follows: Definition 3.14 (normal form [Hennessy 1988]). For any contract σ, we define its saturated set of ready sets: def R(σ) = {r ⊆ init(σ) | ∃s, σ ⇓ s ∧ s ⊆ r} The normal form of σ is then defined up to associativity and commutativity of the choices by the following recursive expression: P def L nf(σ) = r∈R(σ) α∈r α.nf(σ(α)) the empty external choice being defined as 0 (it is not necessary to define the empty internal choice, because any contract has at least one ready set). Notice that nf(σ) ϕ is well defined because σ is regular, hence {σ(ϕ) | σ 7−→} is finite. The normal form enjoys the following properties: (1) In a given mix of internal and external choices (either at top-level or under a given sequence of prefixes), a prefix α is always followed by the exact same continuation. (2) If σ and τ are two TO APPEAR IN ACM Transactions on Programming Languages and Systems · A Theory of Contracts for Web Services Table II. (s1) (s2) Derived rules. σ ⊕ τ = σ ⊕ τ ⊕ (σ + τ ) (C-Prefix) σ ⊕ (σ + τ + ρ) = σ ⊕ (σ + τ ) ⊕ (σ + τ + ρ) (α.σ ′ + τ ′ ) ⊕ (α.σ ′′ + τ ′′ ) = (co) (α.(σ ′ ⊕ σ ′′ ) + τ ′ ) ⊕ (α.(σ ′ ⊕ σ ′′ ) + τ ′′ ) I(σ) ∧ I(τ ) 6 0 (Width) I(σ) : σ ≤ σ + τ 25 (C-EChoice) (C-IChoice) σ = σ′ α.σ = α.σ ′ σ = σ′ τ = τ′ σ + τ = σ′ + τ ′ σ = σ′ τ = τ′ σ ⊕ τ = σ′ ⊕ τ ′ normal form contracts such that σ ⊑ τ , condition (1) of the strong subcontract relation holds if and only if every ready set of τ is also a ready set of σ. These two properties lead to the fact that two equivalent normal forms are syntactically equal up to commutativity and associativity of the choice operators. To prove that every contract can be rewritten to an equivalent one in normal form it is useful to derive a handful of auxiliary axioms and rules (Table II) that will be fundamental in the following. Axioms (s1) and (s2) will be used for saturating ready sets as required by the definition of normal form. Axiom (co) shows that it is possible to rewrite a contract so that all the continuations under the same prefix α are equal. Rules (C-Prefix), (C-IChoice), and (C-EChoice) are strengthened versions of rules (Prefix), (IChoice), and (EChoice) showing the congruence properties of = with respect to the prefix and the two choices. Such rules will allow us to replace equivalent contracts in arbitrary contexts. Finally, rule (Width) states that a service can be extended with additional capabilities, provided that such capabilities are disjoint from those that were available before the extension. Lemma 3.15. The axioms and rules in Table II are derivable from those in Table I. Proof. In the rewritings that follow we indicate only the most relevant laws that are applied. As regards (s1): σ ⊕ τ = (σ ⊕ τ ) + (σ ⊕ τ ) (1) = σ ⊕ τ ⊕ (σ + τ ) (2) where (1) is justified by (e1) and (2) is justified by (d1). As regards (s2): σ ⊕ (σ + τ + ρ) = = = = = σ + (σ ⊕ τ ) + (σ ⊕ ρ) σ + (σ ⊕ (σ + τ ) ⊕ (σ + ρ) ⊕ (τ + ρ)) σ ⊕ (σ + τ ) ⊕ (σ + ρ) ⊕ (σ + τ + ρ) σ ⊕ (σ + τ ) ⊕ (σ + τ ) ⊕ (σ + ρ) ⊕ (σ + τ + ρ) σ ⊕ (σ + τ ) ⊕ (σ + τ + ρ) (1) (2) (3) (4) (5) where (1) is justified by (d2), (2) is justified by (d1), (3) is justified by (d2), (4) is justified by (i1) and finally (5) is justified by rewriting the subterm of step (3) with the original one. TO APPEAR IN ACM Transactions on Programming Languages and Systems 26 · Castagna, Gesbert, and Padovani As regards (co): (α.σ + τ ) ⊕ (α.σ ′ + τ ′ ) = (α.σ + τ ) ⊕ (α.σ ′ + τ ′ ) ⊕ (α.σ + α.σ ′ + τ + τ ′ ) = (α.σ + τ ) ⊕ (α.σ ′ + τ ′ ) ⊕ (α.σ + α.σ ′ + τ + τ ′ ) ⊕ (α.σ + α.σ ′ + τ ) ⊕ (α.σ + α.σ ′ + τ ′ ) = (α.σ + τ ) ⊕ (α.σ ′ + τ ′ ) ⊕ (α.σ + α.σ ′ + τ + τ ′ ) ⊕ (α.(σ ⊕ σ ′ ) + τ ) ⊕ (α.(σ ⊕ σ ′ ) + τ ′ ) = (α.σ + τ ) ⊕ (α.σ ′ + τ ′ ) ⊕ (α.(σ ⊕ σ ′ ) + τ ) ⊕ (α.(σ ⊕ σ ′ ) + τ ′ ) = ((α.σ ⊕ α.(σ ⊕ σ ′ )) + τ ) ⊕ ((α.σ ′ ⊕ α.(σ ⊕ σ ′ )) + τ ′ ) = (α.(σ ⊕ σ ′ ) + τ ) ⊕ (α.(σ ⊕ σ ′ ) + τ ′ ) (1) (2) (3) (4) (5) (6) where (1) is justified by (s1), (2) is justified by (s2), (3) is justified by (d3), (4) is justified by (s1), (5) is justified by (d1), and (6) is justified by (d4) and (i1). Proving (C-Prefix) is trivial. As regards (C-EChoice), observe that from I(σ ′ ) : σ ≤ σ ′ and I(τ ′ ) ∧ I(σ ′ ) 6 I(σ ′ ) we derive I(σ ′ ) ∨ I(τ ′ ) : σ ≤ σ ′ by an application of (Weak). Similarly we can derive I(σ ′ ) ∨ I(τ ′ ) : τ ≤ τ ′ , hence we can apply (EChoice) and derive I(σ ′ ) ∨ I(τ ′ ) : σ + τ ≤ σ ′ + τ ′ . By a similar argument we can also derive I(σ) ∨ I(τ ) : σ ′ + τ ′ ≤ σ + τ , hence σ + τ = σ ′ + τ ′ . Rule (C-IChoice) is analogous. As regards (Width), from the axiom 0 : 0 ≤ τ and the hypothesis I(σ)∧I(τ ) 6 0 we derive I(σ) : 0 ≤ τ . From I(σ) : σ ≤ σ and applying (EChoice) we conclude I(σ) : σ + 0 ≤ σ + τ , hence I(σ) : σ ≤ σ + τ . We are now ready to prove that every contract can be rewritten into its own normal form. Lemma 3.16 (normal form). The judgment σ = nf(σ) is derivable. P def L Proof. We define the head normal form of σ as hnf(σ) = r∈R(σ) α∈r α.σ(α). It is sufficient to prove that σ = hnf(σ) is derivable because then what remains to prove is σ(α) = hnf(σ(α)), but since σ is regular the number of these proofs is ϕ the same as the cardinality of {σ(ϕ) | σ 7−→}, which is finite, hence the (possibly infinite) proof of σ = nf(σ) is regular. We prove σ = hnf(σ) by induction on the maximum depth of a topmost prefix in σ and by cases on the structure of σ. If σ ≡ 0, then σ is already in head normal form. If σ ≡ α.σ ′ , then σ is already in head normal form because σ(α) is σ ′ . If σ ≡ σ1 + σ2 , then L P L P (1) σ = ( r1 ∈R(σ1 ) α∈r1 α.σ1 (α)) + ( r2 ∈R(σ2 ) β∈r2 β.σ2 (β)) P P L (2) α.σ1 (α) + β∈r2 β.σ2 (β)) ( = Lr1 ∈R(σ1 ),r2 ∈R(σ2 ) P α∈r1 α.σ(α) (3) = ),r2 ∈R(σ2 ) α∈r1 ∪r2 Lr1 ∈R(σ1P (4) = r∈R(σ) α∈r α.σ(α) where (1) is justified by the induction hypothesis and congruence rules, (2) is justified by the repeated use of (d1), (3) is justified by (co), and (4) follows from R(σ) = {r1 ∪ r2 | r1 ∈ R(σ1 ), r2 ∈ R(σ2 )}. Indeed, if r ∈ R(σ), then there exist r′1 and r′2 such that σ1 ⇓ r′1 and σ2 ⇓ r′2 and r′1 ∪ r′2 ⊆ r. Now r′1 ⊆ r ∩ init(σ1 ) ⊆ init(σ1 ) and r′2 ⊆ r ∩ init(σ2 ) ⊆ init(σ2 ), hence TO APPEAR IN ACM Transactions on Programming Languages and Systems A Theory of Contracts for Web Services · 27 r ∩ init(σ1 ) ∈ R(σ1 ) and r ∩ init(σ2 ) ∈ R(σ2 ). We conclude by observing that (r ∩ init(σ1 )) ∪ (r ∩ init(σ2 )) = r because r ⊆ init(σ1 ) ∪ init(σ2 ). On the other hand, let r1 ∈ R(σ1 ) and r2 ∈ R(σ2 ). Then there exist ready sets r′1 and r′2 of respectively σ1 and σ2 such that r′1 ⊆ r1 ⊆ init(σ1 ) and r′2 ⊆ r2 ⊆ init(σ2 ). Hence r′1 ∪ r′2 ⊆ r1 ∪ r2 ⊆ init(σ1 ) ∪ init(σ2 ) and we conclude r1 ∪ r2 ∈ R(σ) by observing that σ ⇓ r′1 ∪ r′2 and init(σ) = init(σ1 ) ∪ init(σ2 ). Finally, if σ ≡ σ1 ⊕ σ2 , then L P L P (1) σ = ( r1 ∈R(σ1 ) α∈r1 α.σ1 (α)) ⊕ ( r2 ∈R(σ2 ) β∈r2 β.σ2 (β)) L P L P (2) = ( r1 ∈R(σ1 ) α∈r1 α.σ(α)) ⊕ ( r2 ∈R(σ2 ) β∈r2 β.σ(β)) L P (3) = r∈R(σ) α∈r α.σ(α) where (1) is justified by the induction hypothesis and congruence rules, (2) is justified by (co), and (3) is justified by the repeated use of (s1) and (s2). We now possess all the technical tools to prove that the deduction system shown in Table I is complete for  and the sets of filters that prove it. Theorem 3.17 (completeness). If σ ⊑ f (τ ), then f : σ ≤ τ . Proof. By Lemma 3.16 we can assume that σ and τ are in normal form. Additionally, for the sake of simplicity we identify σ(α), τ (α), and f (τ ) with their corresponding normal forms (indeed nf(σ(α)), nf(τ (α)), and nf(f (τ (α))) can be obtained from σ(α), τ (α), and f (τ ) by repeated use of (i1)). Let P (f, σ, τ ) stand for the proof tree whose conclusion is f : σ ≤ τ . Below we will show that P (f, σ, τ ) can be built provided that proof trees P (f (α), σ(α), τ (α)) are α α available for all α such that σ 7−→ and f (τ ) 7−→. However, the set {(f (ϕ), σ(ϕ), τ (ϕ)) | ϕ ϕ ϕ f 7−→, σ 7−→, τ 7−→} is finite because f , σ, and τ are regular. Hence, we overall need to show how to build a finite number of proofs P (f (ϕ), σ(ϕ), τ (ϕ)) and so the possibly infinite proof of P (f, σ, τ ) is also regular. If τ ≡ 0, then σ must have an empty ready set hence by (Must) we have 0 : σ ≤ 0 and we conclude f : σ ≤ τ by (Weak) because f ∧ I(0) 6 0. For the remaining cases, assume L P L P and τ ≡ s∈R(τ ) α∈s α.τ (α) σ ≡ r∈R(σ) α∈r α.σ(α) α α and assume f (τ ) 7−→. From σ ⊑ f (τ ) we have σ 7−→ and from the proof P (f (α), σ(α), τ (α)) we derive f (α) : σ(α) ≤ τ (α) then, by (Prefix), α.f (α) : α.σ(α) ≤ α.τ (α) . Now assume τ ⇓ r. From σ ⊑ f (τ ) and the fact that σ and τ are in head normal def W α∈f (r) α.f (α) and notice that fr ∧ α.I(τ (α)) 6 form we have σ ⇓ f (r). Let fr = α.f (α). Hence, by (Weak), fr : α.σ(α) ≤ α.τ (α) and, by (EChoice), fr : P α∈f (r) α.σ(α) ≤ P α∈f (r) α.τ (α) . TO APPEAR IN ACM Transactions on Programming Languages and Systems · 28 Castagna, Gesbert, and Padovani From f (r) ⊆ r and by applying (Width), P P fr : α∈f (r) α.σ(α) ≤ α∈r α.τ (α) . S S def W Let f ′ W = τ ⇓r′ fr′ . From τ ⇓r′ f (r′ ) ∩ r = f ( τ ⇓r′ r′ ) ∩ r ⊆ f (r) we observe that f ′ ∧ α∈r α.I(τ (α)) 6 fr . Hence, by (Weak), by iterating over all the ready sets of τ , and by (IChoice), we obtain L P f ′ : τ ⇓r α∈f (r) α.σ(α) ≤ τ . Now f′ : σ ≤ L τ ⇓r P α∈f (r) α.σ(α) by possibly applying (Must) for removing all the ready sets of σ that have disappeared in f (τ ) hence, by (Trans), we conclude f ′ : σ ≤ τ . In order to prove f : σ ≤ τ it is sufficient to apply (Weak). This is possible because f ∧ I(τ ) 6 f ′ . α Indeed, assume f (τ ) 7−→. Then α ∈ r for some τ ⇓ r, hence σ ⇓ f (r) and now α α α ∈ f (r). So, it must be fr 7−→ from which we conclude f ′ 7−→. 3.4 Algorithmic deduction system We introduced a device, filters, that allows us to transform a weak subcontract or compliance relation into a strong one by shielding the incompatible actions. The next step is to infer filters algorithmically, so that the weak relations can be used in practice. As usual, finding a decision algorithm for a containment relation corresponds to a cut-elimination process (the cut here being the (trans) rule in Table I), which amounts to finding a canonical proof for each provable relation. In other terms, we have to associate every provable weak subcontracting relation with a canonical filter that represents all other possible proofs. In order to choose a canonical filter, we have to solve two potential problems. First, there usually are several filters that work with a given relation. For example, to show that a ⊕ b  a + b, we can either let pass only a, only b, or both. The best solution here is to let pass both, because we do not want to shield out actions that cannot cause any harm. This example suggests the definition of a notion of “better filter”, that is, of a partial order on filters that determines which filter is better to use, and such partial order is exactly 6 (Definition 3.12). The second problem is that in the example above a filter that lets a, b, and, say, c pass will work as well. The intuition here is that the filter that lets just a and b pass is better since the fact of allowing any action besides a and b is useless. This suggests the definitions of a notion of “filter relevance”, to single out filters that do not contain useless actions. The subcontracting algorithm will pick up, among all the possible filters for a given relation, the “best relevant” filter that proves it. 3.4.1 Filter relevance. In order to determine the property of “relevance” we have to better understand the role played by the identity filters we introduced in Definition 3.11. It may be noted that the identity filter of a given contract is exactly the tree (prefix-closed set of traces) of all possible sequences of actions that the contract can do before reducing to 0, without distinguishing between internal and external choices. This is embodied by the ∨ operator on filters which is a TO APPEAR IN ACM Transactions on Programming Languages and Systems A Theory of Contracts for Web Services · 29 unique choice operator representing both kinds of choice, as the following relation shows: I(σ ⊕ τ ) = I(σ + τ ) = I(σ) ∨ I(τ ) (3) Note that if σ and τ share common actions in their outermost prefixes, the continuations of both filters after this action are correctly merged by the semantics of the disjunction operator. The tree of an identity filter accurately represents the idea we mentioned in the Introduction (§1) of a contract’s “world”: the sets of actions the contract knows of at each step of an interaction. Filter application can be seen as a projection of the contract onto the “world” represented by the filter. In the case of a relation f : σ ≤ τ , f is used to restrict the “world” of τ : then the intuition is that in order to be relevant, f should be defined (only) on that world, which is represented by I(τ ). Indeed, applying to τ the filter f or the filter f ∧ I(τ ) gives the same result, thus the part of f that is not in f ∧ I(τ ) is irrelevant (and this is why there is no greatest filter corresponding to a given relation in the absolute). Thus we will say that a filter f is relevant with respect to a relation σ  τ if it is smaller than I(τ ) according to 6. Now if we restrict ourselves to relevant filters we can have another interesting upper bound: by looking at condition (2) of the coinductive strong subcontract relation we see that, at each step, every action available in the greater contract has to be available also in the smaller one. This exactly means that the greater contract has a smaller tree, and thus we have (by noticing that I(f (σ)) = (f ∧ I(σ))(σ)): if σ ⊑ f (τ ) and f 6 I(τ ) then f 6 I(σ) (4) Thus relevant filters that prove a relation have to be smaller than the identity filters of both contracts. This corresponds to the intuition that f embeds τ services into the “world” of σ: it projects them on something that is included in that world. We now would like to find the greatest relevant filter that proves a given relation. Note that projecting on I(σ) ∧ I(τ ) itself is not necessarily enough to make the relation work, because of ready sets: it might be necessary to project on something smaller to prevent a wrong branch to be taken. For example in a ⊕ b.(a + b)  a+b.(a⊕b), the initial b has to be filtered out even if the trees are the same, because its continuation in the right contract has incompatible ready sets. However, the following important relation holds: if σ ⊑ f (τ ) and σ ⊑ g(τ ) then σ ⊑ (f ∨ g)(τ ) (5) meaning that if we can make the relation work either by selecting some branches or by selecting some other branches, then it will still work if we take all these branches at once. This shows that, if σ  τ holds, there will be a greatest subtree of τ that makes the relation work: even if there is no greatest filter in the absolute, we can take the disjunction of all filters less than I(τ ) that work (there are a finitely many). This filter, which is the least upper bound of all relevant filters that prove σ  τ , is the one we choose as canonical. 3.4.2 Algorithm. The last step is to define an algorithm for building the canonical filter of a relation. In this respect we have to solve two technical problems: the TO APPEAR IN ACM Transactions on Programming Languages and Systems 30 · Castagna, Gesbert, and Padovani Table III. Algorithmic deduction system for the weak subcontract relation. (σ, τ ) ∈ Γ (a1) (a2) Γ⊢∅:σPτ ∀s ∈ R(τ ) : s ∩ a ∈ R(σ) a = {α ∈ init(σ) ∩ init(τ ) | ∃Fα : Γ ∪ {(σ, τ )} ⊢ Fα : σ(α) P τ (α)} S Γ ⊢ α∈a Fα ∪ {(σ, τ ) 7→ a} : σ P τ first problem is due to the fact that, although the algorithm works on infinite terms, it must always be able to report success or failure in finite time. Since contracts are assumed to be regular, we use the well-known technique of memoization for recording pairs of contracts that we deem related, so that they are not processed if found again. To this end we equip judgments with a context Γ storing pairs of contracts already examined. The second problem regards the computation of the canonical filter that proves a relation: it is clear that, in general, such a filter will not be finite and nonetheless we currently have no finite representation for filters. However, a filter is nothing but the specification, at any given time during an interaction, of a (finite) set of actions that are not shielded, namely the set a in Definition 3.1. In particular, because of the regularity of the contracts being related, the set of such a’s is necessarily finite. From this set of a’s it is trivial to produce a possibly infinite, regular filter. We use F to range over (finite) maps from pairs of contracts to finite sets of actions. For any given contracts σ and τ such that σ  τ , the algorithm infers a map F , defined on every pair (σ ′ , τ ′ ) reachable from (σ, τ ) after some sequence of interactions, which associates with such a pair the finite set of actions a that are not shielded at that point. Definition 3.18. We define the relation Γ ⊢ F : σ P τ by the inference rules in Table III. We write F : σ P τ for ∅ ⊢ F : σ P τ . Rule (a1) applies when the contracts being processed have already been encountered and assumed to be related. In this case the inferred map F is empty, because the set a of actions that need not be shielded for relating σ and τ is already computed by the instance of the rule where σ and τ occurred for the first time. In rule (a2), the set a represents the largest set of actions leading to continuations which are in the relation, namely a is the largest set of (relevant) actions that need not be shielded for two contracts to be related. The condition on the first line requires a to be large enough, so that when τ is restricted to the actions in a, τ manifests a behavior that is (more deterministic than) that of σ. It is trivial to see that if F is synthesized by the algorithm and {(σ ′ , τ ′ ) 7→ a, (σ ′ , τ ′ ) 7→ a′ } ⊆ F , then we have a = a′ . Hence F is indeed a map and from now on we will write F (σ, τ ) for the set a associated with (σ, τ ) in F . Additionally, F : σ P τ implies the following properties (1) (σ, τ ) ∈ dom(F ); (2) (σ ′ , τ ′ ) ∈ dom(F ) and α ∈ F (σ ′ , τ ′ ) implies (σ ′ (α), τ ′ (α)) ∈ dom(F ). TO APPEAR IN ACM Transactions on Programming Languages and Systems · A Theory of Contracts for Web Services 31 Overall if F : σ P τ , then the map F represents the (possibly infinite) filter F [σ, τ ] defined by the equation W F [σ, τ ] = α∈F (σ,τ ) α.F [σ(α), τ (α)] . The regularity of such filter is a direct consequence of the regularity of σ and τ while contractivity stems from the finiteness of the init(σ) and init(τ ) sets (thus of the α’s) and from the construction of F [σ, τ ]. Remark 3.19. The rule (a2) in Table III is more an algorithmic specification than a deduction rule, insofar as it describes how to compute the set a, rather than how to build a proof tree. The following rule (a2) ∀α ∈ a Γ ∪ {(σ, τ )} ⊢ Fα : σ(α) P τ (α) ∀β ∈ (init(σ) ∩ init(τ )) \ a S Γ ∪ {(σ, τ )} 6⊢ F : σ(β) P τ (β) Γ ⊢ α∈a Fα ∪ {(σ, τ ) 7→ a} : σ P τ ∀s ∈ R(τ ) : s ∩ a ∈ R(σ) is its proof theoretic counterpart. 3.4.3 Properties. The algorithm described in Definition 3.18 enjoys fundamental properties, namely (i) it proves only (soundness) and all (completeness) weak subcontract relations, (ii) in case of success it returns the largest relevant filter that proves the relation and (iii) it always terminates, which implies the decidability of the weak subcontract relation. Lemma 3.20 (filter relevance). If F : σ P τ , then F [σ, τ ] 6 I(τ ). ϕ Proof. By definition of F [σ, τ ] it is trivial to verify that F [σ, τ ] 7−→ implies ϕ τ 7−→, from which relevance follows immediately. Before proving soundness, we need an auxiliary (cut-elimination) result stating that an hypothesis σ  τ that is necessary for proving σ ′  τ ′ can be discharged if σ  τ is itself provable. Proposition 3.21. If (1) Γ ⊢ F : σ P τ and (2) Γ ∪ {(σ, τ )} ⊢ F ′ : σ ′ P τ ′ , then there exists F ′′ such that F ′ ⊆ F ′′ and Γ ⊢ F ′′ : σ ′ P τ ′ . Proof. We reason by induction on the derivation tree of (2) and by cases on the last rule applied. Assume the last rule was (a1). Then (σ ′ , τ ′ ) ∈ Γ ∪ {(σ, τ )} and F ′ = ∅. We distinguish two subcases: if (σ ′ , τ ′ ) ∈ Γ, then we conclude immediately by (a1) and by taking F ′′ = ∅; if σ ′ ≡ σ and τ ′ ≡ τ , then we conclude by hypothesis (1) and by taking F ′′ = F . Assume the last rule was (a2) and let a be the set determined in the premises of the rule. For every α ∈ a we have that there existsSFα such that Γ′ ∪ {(σ, τ )} ⊢ Fα : σ ′ (α) P τ ′ (α) where Γ′ = Γ ∪ {(σ ′ , τ ′ )} and F ′ = α∈a Fα ∪ {(σ ′ , τ ′ ) 7→ a}. From (1) and Γ ⊆ Γ′ we derive Γ′ ⊢ F : σ P τ . By induction hypothesis there exists Fα′ such that Fα ⊆ Fα′ and Γ′ ⊢ Fα′ : σ ′ (α) P τ ′ (α) for every α ∈Sa. Hence we can apply rule (a2) and conclude that Γ ⊢ F ′′ : σ ′ P τ ′ where F ′′ = α∈a Fα′ ∪ {(σ ′ , τ ′ ) 7→ a}, observing that F ′ ⊆ F ′′ . Theorem 3.22 (soundness). If F : σ P τ then σ ⊑ F [σ, τ ](τ ). def Proof. We prove that S = {(σ, F [σ, τ ](τ )) | F : σ P τ } is a coinductive strong subcontract relation. Let (σ, τ ′ ) ∈ S , then there exist F and τ such that F : σ P τ and τ ′ ≡ F [σ, τ ](τ ). As regards condition 1 in the definition of coinductive strong TO APPEAR IN ACM Transactions on Programming Languages and Systems 32 · Castagna, Gesbert, and Padovani subcontract relation, let τ ⇓ s. Then F [σ, τ ](τ ) ⇓ s ∩ F (σ, τ ) and from s ∩ F (σ, τ ) ∈ R(σ) we conclude that there exists r such that σ ⇓ r and r ⊆ s∩F (σ, τ ). As regards α α condition 2, assume F [σ, τ ](τ ) 7−→. By definition of F [σ, τ ] we also have σ 7−→ and, for every α ∈ F (σ, τ ), there exists Fα such that {(σ, τ )} ⊢ Fα : σ(α) P τ (α). By Proposition 3.21 there exists Fα′ such that Fα ⊆ Fα′ and Fα′ : σ(α) P τ (α). Notice also that Fα′ ⊆ F since the former proves σ(α) P τ (α), the latter σ P τ , and by the uniqueness of the filters derived by the algorithm Fα′ must correspond to the α-continuation of F . Hence we conclude (σ(α), τ ′ (α)) ∈ S by observing that τ ′ (α) ≡ F [σ, τ ](τ )(α) ≡ Fα′ [σ(α), τ (α)](τ (α)) and by definition of S . Theorem 3.23 (completeness). If σ ⊑ g(τ ), then there exists F such that F : σ P τ , and F [σ, τ ] > g ∧ I(τ ). Proof. First note that if σ ⊑ g(τ ), then also σ ⊑ (g ∧ I(τ ))(τ ) (applying the conjunction of two filters is like applying one then the other, it projects on the part of the tree common to both), thus we can assume g 6 I(τ ) without loss of generality. The theorem is stated for a memoization environment Γ = ∅ (recall that F : σ P τ stands for ∅ ⊢ F : σ P τ and that a memoization environment is a finite set of pairs of contracts). To integrate memoization environments in our proof we generalize the statement and prove that if σ ⊑ g(τ ) and g 6 Iτ , then for all Γ: (1) there exists F such that Γ ⊢ F : σ P τ ; (2) (σ, τ ) 6∈ Γ ⇒ init(g) ⊆ F (σ, τ ); Completeness then follows immediately from (1) by taking Γ = ∅, and maximality of the inferred filter is easily deduced from (2). def ϕ ϕ Let R(Γ, σ, τ ) = {(σ(ϕ), τ (ϕ)) | σ 7−→, τ 7−→} \ Γ, and note that by regularity of σ and τ , the set is finite. We can thus reason by induction on R(Γ, σ, τ ) to show the more general property. Assume (σ, τ ) ∈ Γ. Note that if R(Γ, σ, τ ) = ∅ this is the only possible case. Then we conclude immediately by rule (a1) and by taking F = ∅. Assume (σ, τ ) 6∈ Γ and def α let Γ′ = Γ ∪ {(σ, τ )}. Suppose g(τ ) 7−→. From the hypothesis σ ⊑ g(τ ) we derive α σ 7−→ and σ(α) ⊑ g(α)(τ (α)). We have R(Γ′ , σ(α), τ (α)) ( R(Γ, σ, τ ) because (σ, τ ) is in the latter and not in the former, hence by induction hypothesis there exists Fα such that Γ′ ⊢ Fα : σ(α) P τ (α). We can do this for any α such that α g(τ ) 7−→, thus because of the hypothesis that g 6 Iτ we have that the set a in the premises of rule (a2) is such that init(g) ⊆ a. Therefore the F appearing in the conclusion of that rule satisfies property (2) and we just have to check that the condition on the first line of the premises is satisfied. Let s ∈ R(τ ). It contains a ready set s′ of τ . Since σ ⊑ g(τ ), there exists r ⊆ s′ ∩ init(g) such that σ ⇓ r. As init(g) is included in a and s′ in s, we also have r ⊆ s ∩ a. Then s ∩ a ∈ R(σ), because a is included in init(σ) by definition. Corollary 3.24. If σ and τ are two contracts, there exists at most one F such that F : σ P τ . Furthermore, if F : σ P τ , then F [σ, τ ] = max{g 6 I(τ ) | σ ⊑ g(τ )} = max{g 6 I(τ ) | g : σ ≤ τ } . TO APPEAR IN ACM Transactions on Programming Languages and Systems A Theory of Contracts for Web Services · 33 The corollary above describes the logical interpretation of the algorithm as the result of a cut-elimination process. The “cut” in the system of Table I is given by the rule (trans). This rule intersects filters, that is it minimizes the proofs: therefore in order to eliminate cuts we have to find a proof with a maximum filter. However we have also to avoid useless applications of the (weak) rule, which instead maximizes proofs: therefore we have to set an upper bound to filter maximization, which is embodied by the definition of relevance (therefore it would be more precise to speak of a cut-weakening-elimination process). Proposition 3.25 (decidability). Given two contracts σ and τ , we can decide whether there exists F such that F : σ P τ . Proof. Trivial consequence of the regularity of σ and τ . 4. PROCESSES In this section we relate contracts (which are behavioral types) with processes that implement clients and services. We do not consider any particular process language, nor do we require clients and services to be implemented using the same language. We just require that the observable behavior of processes is described by a labeled transition system and abstracted by a static type system. More precisely we assume that a process language is equipped with a labeled transition system so that µ P −→ P ′ describes the evolution of a process P that performs a µ action thus becoming the process P ′ . Here, µ can either be a visible action of the form a or a, which is meant to synchronize with the corresponding co-action in the process P is interacting with, or it can be the special action e, by which the client process P signals that it can successfully terminate, or it can be an internal, invisible action τ (not to be confused with τ that we used to range over contracts) that the process P µ executes autonomously. It is understood that the relation −→ is not necessarily µ deterministic. As usual, we let α range over visible actions and we write P −→ µ if P −→ P ′ for some process P ′ . Also, we say that P diverges if there exists an τ τ infinite sequence P0 , P1 , . . . , such that P = P0 −→ P1 −→ · · · . Definition 4.1 (strong process compliance). Let P k Q −→ P ′ k Q′ be the least relation defined by the rules: τ P −→ P ′ P k Q −→ P ′ k Q τ Q −→ Q′ P k Q −→ P k Q′ α α P −→ P ′ Q −→ Q′ P k Q −→ P ′ k Q′ We write =⇒ for the reflexive, transitive closure of −→; we write P k Q −→ if P k Q −→ P ′ k Q′ for some P ′ and Q′ ; we write P k Q −→ X if not P k Q −→. A computation of P k Q is a sequence P k Q = P0 k Q0 −→ P1 k Q1 −→ · · · . A computation of P k Q is maximal if either it is infinite or there exists Pn k Qn such that P k Q =⇒ Pn k Qn −→. X The client P is strongly compliant with the service Q, written P ⊣ Q, if for every configuration Pi k Qi of every maximal computation there exists j ≥ i such α τ e that either Pj −→ Pj+1 for some α or Pj −→ X and Pj −→. TO APPEAR IN ACM Transactions on Programming Languages and Systems 34 · Castagna, Gesbert, and Padovani The intuition of this definition is that P k Q represents a client P and a service Q interacting with each other. When P ⊣ Q every interaction between P and Q is such that either P and Q interact infinitely often, or the client invariably reaches a state in which it is able to emit e, denoting the successful completion of P ’s task. We also assume that a type system is given to check that a process P implements the contract σ. This is expressed by the judgment ⊢P :σ While we do not give details on the particular typing rules, we require typing and the reduction relation to satisfy some basic properties: essentially, contracts must describe the observational behavior of processes and reduction must decrease nondeterminism (entropy must always increase). In this respect, it makes sense to be able to apply the strong subcontract relation to client contracts too, where the action e is treated like any other action (recall that, according to Theorem 2.9, the relation ⊑ can be defined without any notion of “successful action” e). Definition 4.2. The type system is consistent if and only if, for every process P and contract σ, if ⊢ P : σ, then all the following properties hold: τ (1 ) P −→ P ′ implies ⊢ P ′ : σ ′ and σ ⊑ σ ′ ; α α (2 ) P −→ P ′ implies ⊢ P ′ : σ ′ , σ −→, and σ(α) ⊑ σ ′ ; (3 ) P diverges implies σ ⇓ ∅; α τ (4 ) P −→ X implies σ ⇓ r and r ⊆ {α | P −→}. Intuitively, condition (1) states that a process performing internal actions can only make its contract more deterministic. Condition (2) states that if a process performs a visible action α, then its contract must provide that action and the contract of the resulting process P ′ be (more deterministic than) the contract σ(α), which represents all the possible behaviors of P after α. Condition (3) states that a divergent process may be observationally invisible, namely its contract must provide an empty ready set (the process may never be “ready” to perform any action). Finally, condition (4) states that the contract of a stable process should have at least one ready set that provides no more capabilities than those of the process. The following lemma states that it is possible to replace a client contract ρ with another one which is more deterministic, still preserving the compliance property. The lemma is fundamental in proving the soundness of the type system. Lemma 4.3. If ρ ⊣ σ and ρ ⊑ ρ′ then ρ′ ⊣ σ. Proof. Let C be a compliance relation such that (ρ, σ) ∈ C and let S be a strong subcontract relation such that (ρ, ρ′ ) ∈ S . It is sufficient to prove that def C ′ = {(ρ′ , σ) | ∃ρ : (ρ, σ) ∈ C ∧ (ρ, ρ′ ) ∈ S } is a strong compliance relation. Assume (ρ′ , σ) ∈ C ′ . Then there exists ρ such that (ρ, σ) ∈ C and (ρ, ρ′ ) ∈ S . As regards condition (1) in Definition 2.6, assume ρ′ ⇓ r and σ ⇓ s. If e ∈ r, then the condition is satisfied. Assume e 6∈ r. From (ρ, ρ′ ) ∈ S there exists r′ ⊆ r such that ρ ⇓ r′ . In particular, e 6∈ r′ . From (ρ, σ) ∈ C we have co(r′ ) ∩ s 6= ∅, hence co(r) ∩ s 6= ∅. TO APPEAR IN ACM Transactions on Programming Languages and Systems · A Theory of Contracts for Web Services α 35 α As regards condition (2) in Definition 2.6, assume ρ′ 7−→ and σ 7−→. From α (ρ, ρ′ ) ∈ S we derive ρ 7−→ and (ρ(α), ρ′ (α)) ∈ S . From (ρ, σ) ∈ C we derive (ρ(α), σ(α)) ∈ C . Hence we conclude (ρ′ (α), σ(α)) ∈ C ′ by definition of C ′ . Given a consistent type system, the following result states that, given a pair of processes P k Q whose respective contracts comply, and given any two residual processes P ′ k Q′ resulting from P k Q, the respective contracts of P ′ and Q′ comply as well. Lemma 4.4 (subject reduction). If ⊢ P : ρ and ⊢ Q : σ and ρ ⊣ σ and P k Q −→ P ′ k Q′ , then ⊢ P ′ : ρ′ and ⊢ Q′ : σ ′ and ρ′ ⊣ σ ′ . Proof. We need to consider all the possibilities by which P k Q reduces to τ P ′ k Q′ , namely P k Q −→ P ′ k Q′ . If P −→ P ′ , then from consistency condition (1) we have ⊢ P ′ : ρ′ and ρ ⊑ ρ′ and by Lemma 4.3 we conclude ρ′ ⊣ σ. If τ Q −→ Q′ , then from consistency condition (1) we have ⊢ Q′ : σ ′ and σ ⊑ σ ′ and by α α definition of ⊑ we conclude ρ ⊣ σ ′ . Finally, if P −→ P ′ and Q −→ Q′ , then from consistency condition (2) we have that ⊢ P ′ : ρ′ and ⊢ Q′ : σ ′ and ρ(α) ⊑ ρ′ and σ(α) ⊑ σ ′ . By Lemma 4.3 and by definition of ⊑ we conclude ρ′ ⊣ σ ′ . The soundness of a consistent type system is ensured by the following result, stating that if the contracts of two processes comply, the corresponding processes comply as well, guaranteeing that either the two processes synchronize infinitely many times or the client successfully terminates. Theorem 4.5. If ⊢ P : ρ and ⊢ Q : σ and ρ ⊣ σ then P ⊣ Q. Proof. Because of Lemma 4.4 we only need to consider the cases when P k Q −→ X or P −→ X and Q diverges. Indeed, from ρ ⊣ σ we derive that ρ ⇓ r implies r 6= ∅, hence P cannot diverge, for otherwise we would have ρ ⇓ ∅ by consistency condie tion (3). Let P k Q −→ X and assume, by contradiction, that P −→. X From P k Q −→ X α α we have that whenever P −→ we have Q −→. X From consistency condition (4) there exist r and s such that ρ ⇓ r and σ ⇓ s and co(r) ∩ s = ∅ and e 6∈ r, but this is e absurd from the hypothesis that ρ ⊣ σ. Hence P −→. Assume that P −→ X and Q diverges. By consistency condition (3) we derive σ ⇓ ∅, hence ρ ⇓ r implies e ∈ r. e From consistency condition (4) we conclude P −→. The soundness theorem holds when the client’s contract and the service’s contract are strongly compliant. To be able to use a service for which we only have a weakly compliant client, we need to shield potentially dangerous service actions by means of a filter. Thus, we enrich the process language with an operator f [P ] that applies a filter f to a process P , the idea being that the filter constraints the set of visible actions of P , that is its capabilities to interact with the environment, still not altering its ability to evolve autonomously. The labeled transition system TO APPEAR IN ACM Transactions on Programming Languages and Systems 36 · Castagna, Gesbert, and Padovani of the language is consequently enriched with the following two inference rules: (Filter1) α ′ α P −→ P f 7−→ f ′ α f [P ] −→ f ′ [P ′ ] (Filter2) τ P −→ P ′ τ f [P ] −→ f [P ′ ] The introduction of filters into the process language has consequences on the type system as well. Since our discussion is parametric in the process language and in the type system, we only need to show that the typing rule (TypeFilter) ⊢P :σ ⊢ f [P ] : f (σ) preserves the consistency of the type system. Proposition 4.6. A consistent type system enriched with rule (TypeFilter) results in another consistent type system. τ Proof. Let ⊢ P : σ. As regards consistency condition (1), assume P −→ P ′ and ⊢ P : σ ′ . Then σ ⊑ σ ′ implies f (σ) ⊑ f (σ ′ ) by Proposition 3.8. As regards α consistency condition (2), assume that P −→ P ′ and ⊢ P ′ : σ ′ . There are two α α α possibilities: if f 7−X →, then f [P ] −→ X and there is nothing to prove. If f 7−→ f ′ , then σ(α) ⊑ σ ′ . Now we conclude f (σ)(α) = f ′ (σ(α)) ⊑ f ′ (σ ′ ). As regards consistency condition (3), assume that f [P ] diverges. Then P diverges and we must have σ ⇓ ∅. We immediately conclude f (σ) ⇓ ∅. Finally, as regards consistency condition (4), τ τ α assume that f [P ] −→. X Then P −→. X We derive σ ⇓ r where r ⊆ {α | P −→}, α hence f (σ) ⇓ f (r) and we conclude by observing that f (r) ⊆ {α | f [P ] −→}. The following result summarizes the contribution of our work: the adoption of filters enlarges the number of services that satisfy a client. Corollary 4.7. If ⊢ P : ρ, ⊢ Q : σ, and ρ ⊣ f (σ), then P ⊣ f [Q]. 5. PRACTICE OF CONTRACTS Hitherto we developed our theory by working on infinite trees, for both types and filters. The main advantage of this approach is that the resulting theory does not depend on a particular concrete syntax used to finitely denote infinite trees. Of course, the use of infinite trees is infeasible in practice, and as soon as one wants to devise typing systems and algorithms for actual languages (or just process calculi) it is necessary to introduce a concrete finite syntax to denote possibly infinite trees. Remarkably, the results stated for infinite trees easily carry over to whatever (reasonable) concrete syntax we choose to denote them, by using classic techniques dating back to Bruno Courcelle’s seminal work [Courcelle 1983]. This contrasts with the fact that transposing the results stated for one syntax onto another can be quite hard, since one has to sieve the properties that hold for infinite trees from those that are meaningful only for the particular syntax at issue, whence the interest of our approach. Choosing a particular concrete syntax neither is without consequences nor is it just a matter of taste. Two concrete syntaxes are quite popular in the process TO APPEAR IN ACM Transactions on Programming Languages and Systems A Theory of Contracts for Web Services · 37 algebras literature: the first one uses explicit recursion variables while the second uses the Kleene star to denote an unbound number of occurrences of some subtree. Each of them fits different applications. In the rest of this section we first introduce these two concrete syntaxes and we show how the main properties we studied in the previous sections for infinite trees (compliance, subcontracting, . . . ) transpose to them. Next we apply each concrete syntax to a Web service description language: we show that wscl diagrams (§2.2) can be straightforwardly encoded by resorting to recursion variables and that ws-bpel so-called activities can be naturally typed using Kleene notation. In this latter case, we define a contract based type system and, above all, show how to use filters to trim down the case explosion introduced by the use of parallel compositions of activities. Terminology. In the rest of this section we introduce the two concrete syntaxes for contracts and filters we hinted above: the one based on recursive variables and the other on Kleene’s stars. In order not to clutter the notation, in the concrete syntax we will use the same metavariables for contracts and filters that we used for the corresponding possibly infinite terms of the previous sections. To avoid any ambiguity we will use the terminology unfolded contract/filter when referring to the possibly infinite terms used so far, recursive contract/filter for terms generated by using explicit recursion variables, and regular contract/filter for terms using the Kleene star. We will omit the qualifying adjectives only when no confusion can arise. 5.1 Concrete syntax for contracts The first concrete syntax for regular contracts is the same as given in §2.1 for unfolded contracts/terms, extended with the well-known recursion operator rec x = σ which binds the recursion variable x in σ. The idea is that an occurrence of x in σ stands for the whole rec x = σ term. A recursive contract is a finite term inductively generated by the following grammar: σ ::= 0 | α.σ | σ + σ | σ ⊕ σ | rec x = σ | x Similarly a recursive filter is a finite term inductively generated by the grammar f ::= 0 | α.f | f ∨ f | f ∧ f | rec x = f | x As usual we write fv(σ) and bv(σ) for denoting the free and the bound variables occurring in σ, respectively (their definition is standard); we say that σ is closed if fv(σ) = ∅; we write σ{τ /x} for the contract obtained from σ by replacing every free occurrence of x with τ ; we proceed similarly for filters. Using this syntax, contractivity corresponds to requiring that in a subterm rec x = σ (respectively, rec x = f ) every free occurrence of x in σ (respectively, in f ) be guarded by at least one prefix. Thus we rule out terms such as e.g. rec x = x + x or rec x = x ∨ x. Intuitively, every recursive contract corresponds to the (possibly infinite) unfolded contract obtained by repeatedly unfolding every rec x = σ to σ{rec x = σ/x} (and similarly for filters). Consequently, the semantics of a term above is equal to the semantics of the infinite tree it denotes. More rigorously, let a system of regular equations be a finite set {x1 = σ1 , . . . , xn = σn } of equations where x1 , . . . , xn are TO APPEAR IN ACM Transactions on Programming Languages and Systems 38 · Castagna, Gesbert, and Padovani the unknowns and σ1 , . . . , σn are recursive contracts such that fv(σi ) ⊆ {x1 , . . . , xn } for every 1 ≤ i ≤ n. We associate each closed recursive contract with a pair (E, x) where E is a system of regular equations and x one of its unknowns called the initial unknown. If the σi ’s of E are such that every free occurrence of a variable is guarded by at least a prefix, then the system of equations satisfies the so-called Greibach condition [Courcelle 1983] and, by Theorem 4.3.1 of [Courcelle 1983], the system admits a unique solution of unfolded contracts (τ1 , . . . , τn ) such that τi = σi {τ1 /x1 } · · · {τn /xn } for every 1 ≤ i ≤ n. Then, we define the semantics of a closed recursive contract as the τi component corresponding to the initial unknown associated with it. Let σ be a closed recursive contract such that bv(σ) = {x1 , . . . , xn }. Without loss of generality, assume that every xi is bound exactly once in σ. Let E (σ) be the function inductively defined by the rules: E (0) = 0 : ∅ E (x) = x : ∅ E (σ) = σ ′ : E E (τ ) = τ ′ : E ′ E (σ + τ ) = σ ′ + τ ′ : E ∪ E ′ E (σ) = σ ′ : E x 6∈ fv(σ) E (rec x = σ) = σ ′ : E E (σ) = σ ′ : E E (α.σ) = α.σ ′ : E E (σ) = σ ′ : E E (τ ) = τ ′ : E ′ E (σ ⊕ τ ) = σ ′ ⊕ τ ′ : E ∪ E ′ E (σ) = σ ′ : E x ∈ fv(σ) E (rec x = σ) = x : E ∪ {x = σ ′ } The pair composed of the system of regular equations and the initial unknown associated with σ, denoted by R(σ), is defined as follows: ( (E, xi ) if E (σ) = xi : E def R(σ) = (E ∪ {x0 = σ ′ }, x0 ) otherwise The semantics JσK of the recursive contract σ is the unfolded contract τi , where (τ0 , τ1 , . . . , τn ) is the unique solution of the system E such that R(σ) = (E, xi ). The following proposition formalizes the fact that a recursive contract rec x = σ and its unfolding σ{rec x = σ/x} are equivalent, namely that they are associated with the same regular system and hence they denote the same regular contract. Proposition 5.1. Let E (rec x = σ) = x : E ∪ {x = σ ′ }. Then E (σ{rec x = σ/x}) = σ ′ : E ∪ {x = σ ′ }. Proof. We prove a more general statement. Let dom(E) be the set of unknowns def in a regular system E; let E{τ /x} = {y = σ{τ /x} | x = σ ∈ E}, where we assume that dom(E) ∩ fv(τ ) = ∅; let σ and τ be two contracts such that bv(σ) ∩ fv(τ ) = ∅. We prove that if x ∈ fv(σ), then E (σ{τ /x}) = σ ′ {τ ′ /x} : E{τ ′ /x} ∪ F , where E (σ) = σ ′ : E and E (τ ) = τ ′ : F . If this holds, the proposition follows immediately by posing τ = rec x = σ. Indeed, if x 6∈ fv(σ), then E (τ ) = E (σ) = E (σ{τ /x}). On the other hand, if x ∈ fv(σ), then E (σ{τ /x}) = σ ′ {x/x} : E{x/x} ∪ E ∪ {x = σ ′ } and we conclude immediately since σ ′ {x/x} ≡ σ ′ and E{x/x} = E. As regards the more general statement, we prove it by induction on σ (recall that σ is a recursive contract, hence it is finite). TO APPEAR IN ACM Transactions on Programming Languages and Systems A Theory of Contracts for Web Services · 39 (σ ≡ 0). Trivial since x 6∈ fv(σ). (σ ≡ x). We have σ ′ ≡ x and E = ∅. Now E (σ{τ /x}) = E (τ ) = τ ′ : F and we conclude by observing that σ ′ {τ ′ /x} ≡ τ ′ and E{τ ′ /x} = ∅. (σ ≡ y, y 6= x). Trivial since x 6∈ fv(σ). (σ ≡ α.σ1 ). We have σ ′ ≡ α.σ1′ , where E (σ1 ) = σ1′ : E. From x ∈ fv(σ) we deduce x ∈ fv(σ1 ), hence by induction hypothesis we derive E (σ1 {τ /x}) = σ1′ {τ ′ /x} : E{τ ′ /x} ∪ F . Now E (σ{τ /x}) = E (α.σ1 {τ /x}) = α.σ1′ {τ ′ /x} : E{τ ′ /x} ∪ F and we conclude by observing that σ ′ {τ ′ /x} ≡ α.σ1′ {τ ′ /x}. (σ ≡ σ1 + σ2 ). We have σ ′ ≡ σ1′ +σ2′ and E = E1 ∪E2 , where E (σ1 ) = σ1′ : E1 and E (σ2 ) = σ2′ : E2 . We examine only one interesting case, when x ∈ fv(σ1 ) \ fv(σ2 ). By induction hypothesis we derive E (σ1 {τ /x}) = σ1′ {τ ′ /x} : E1 {τ ′ /x} ∪ F . Now E (σ{τ /x}) = E (σ1 {τ /x}+σ2 ) = σ1′ {τ ′ /x}+σ2′ : E1 {τ ′ /x}∪E2 ∪F and we conclude by observing that σ ′ {τ ′ /x} ≡ σ1′ {τ ′ /x} + σ2′ and E{τ ′ /x} = E1 {τ ′ /x} ∪ E2 . (σ ≡ σ1 ⊕ σ2 ). Similar to the previous case. (σ ≡ rec x = σ1 ). Trivial since x 6∈ fv(σ). (σ ≡ rec y = σ1 , y 6= x). If x ∈ fv(σ), then x ∈ fv(σ1 ) because x 6= y. We distinguish two subcases. Assume y 6∈ fv(σ1 ). Then E (σ) = E (σ1 ) = σ ′ : E. By induction hypothesis we derive E (σ1 {τ /x}) = σ ′ {τ ′ /x} : E{τ ′ /x} ∪ F . From bv(σ) ∩ fv(τ ) = ∅ we obtain y 6∈ fv(τ ), hence we conclude E (σ{τ /x}) = E (rec y = σ1 {τ /x}) = σ ′ {τ ′ /x} : E{τ ′ /x} ∪ F . Assume y ∈ fv(σ1 ). Then σ ′ ≡ y and E = E ′ ∪ {y = σ1′ } where E (σ1 ) = σ1′ : E ′ . By induction hypothesis we derive E (σ1 {τ /x}) = σ1′ {τ ′ /x} : E ′ {τ ′ /x} ∪ F . Now E (σ{τ /x}) = E (rec y = σ1 {τ /x}) = y : E ′ {τ ′ /x} ∪ F ∪ {y = σ1′ {τ ′ /x}} and we conclude by observing that σ ′ {τ ′ /x} ≡ y and E{τ ′ /x} = E ′ {τ ′ /x} ∪ {y = σ1′ {τ ′ /x}}. Now that we have defined the semantics of a recursive contract in terms of unfolded contracts, we can straightforwardly extend to recursive contracts all the definitions introduced for recursive contracts. For example, if σ is a recursive contract, then σ ⇓ r if and only if JσK ⇓ r. By Theorem 4.2.1 of [Courcelle 1983] we also know that the syntax of recursive contracts is complete with respect to the set of unfolded contracts. In particular, every unfolded contract is a component of the unique solution of some regular system. A regular system is nothing but a flattened recursive contract, in which every recursion has been turned into an equation. The second syntax we consider is reminiscent of regular expressions, with the remarkable difference that we have two different sum operators + and ⊕ for external and internal choice, respectively. Correspondingly we also have two different Kleene star operators ∗ and ⊛. This yields to the definition of regular contracts and filters as the finite terms inductively generated by the following grammars σ ::= 0 | α | σ; σ | σ + σ | σ ⊕ σ | σ ∗ | σ ⊛ f ::= 0 | α | f ; f | f ∨ f | f ∧ f | f ∗ The semantics of a regular contract τ can be indirectly given by translating it into a recursive contract. The main issue of this translation is handling sequential composition, which must be reduced to action prefixes. We parametrize the translation with a continuation on which we accumulate actions while scanning TO APPEAR IN ACM Transactions on Programming Languages and Systems 40 · Castagna, Gesbert, and Padovani the regular contract from right to left. We write Jτ Kσ for the recursive contract resulting from the encoding of the regular contract τ , when the continuation is the recursive contract σ. We must ensure that the translation does not yield degenerate recursive contracts in which some bound variable occurs unguarded, since such terms do not have a proper semantics. To this purpose we inductively define a guardedness predicate G(σ) guaranteeing that in the recursive contract JσKx the variable x always occurs under a prefix. The G(σ) predicate is inductively defined as follows: —G(0) and G(α); —if G(σ) or G(τ ), then G(σ; τ ); —if G(σ) and G(τ ), then G(σ + τ ) and G(σ ⊕ τ ). and Jτ Kσ is inductively defined thus: J0Kσ JαKσ Jτ ; τ ′ Kσ Jτ + τ ′ Kσ Jτ ⊕ τ ′ Kσ Jτ ∗ Kσ Jτ ⊛ Kσ = = = = = = = 0 α.σ Jτ KJτ ′ Kσ Jτ Kσ + Jτ ′ Kσ Jτ Kσ ⊕ Jτ ′ Kσ rec x = σ + Jτ Kx rec x = σ ⊕ Jτ Kx (x fresh and G(τ )) (x fresh and G(τ )) We write Jτ K for Jτ K0 . Note that neither Jτ ∗ Kσ nor Jτ ⊛ Kσ are defined if x occurs unguarded in Jτ Kx . Similarly to what happens to the external choice operator +, the external Kleene star may hide an internal Kleene star if the contract being iterated shares an action with the continuation. For instance, Jα∗ Kα = rec x = α + α.x ≃ rec x = α ⊕ α.x = Jα⊛ Kα It is well known that if one relies on a nondeterministic interpretation of regular expressions (which leads to dropping the left distributivity law: X · (Y + Z) = (X · Y ) + (X · Z)), then these are not complete with respect to nondeterministic finite state automata, in the sense that there are languages recognized by nondeterministic finite state automata that cannot be generated by regular expressions [De Nicola and Labella 2003]. In our context this means that there are recursive contracts for which there exists no regular contract having an equivalent unfolding. For instance, there is no regular contract whose translation is the recursive contract rec x = (a.x + b) ⊕ (c.x + d). Roughly speaking, the reason lies in the fact that the same recursion variable x is shared among two different “loops” in the recursive contract. Characterizations of recursive contracts admitting equivalent regular contracts can be found in [De Nicola and Labella 2003; Baeten et al. 2007]. 5.2 Encoding wscl activity diagrams A wscl activity diagram [Banerji et al. 2002] is a tuple (Q, a, δ, x1 , xn ) where Q = {x1 , . . . , xn } is a finite set of interactions, a = {α1 , . . . , αm } is a finite set of actions representing ingoing and outgoing document types, δ ⊆ Q × a × Q is the transition relation, x1 ∈ Q is the initial interaction and xn ∈ Q is the final α α interaction. We write x −→ y if (x, α, y) ∈ δ; we write x −→ if there exists y ∈ Q α α α such that x −→ y; we write x −→ X if not x −→. TO APPEAR IN ACM Transactions on Programming Languages and Systems A Theory of Contracts for Web Services · 41 According to the wscl specification, the following well-formedness conditions must hold: (1) every interaction must be reachable from x1 , namely for every y ∈ Q and y 6= x1 αk α1 there exist α1 , . . . , αk such that x1 −→ · · · −→ y; a (2) for every x ∈ Q, if there exists a ∈ a such that x −→, then for every b ∈ a we b have that x −→; X α (3) xn must not have any outgoing transition, that is xn −→ X for every α ∈ a. The encoding of an interaction x in a wscl activity diagram when the interactions Q have not been encoded yet is denoted by E(x, Q) and is defined as follows:  x if x 6∈ Q    L L  rec x = a∈a,δ(x,a)6=∅ y∈δ(x,a) a.E(y, Q \ {x}) def E(x, Q) = a  if x ∈ Q and x −→ for some a ∈ a    P P  otherwise rec x = a∈a,δ(x,a)6=∅ y∈δ(x,a) a.E(y, Q \ {x}) Because of well-formedness condition (1), the whole activity diagram is encoded; because of well-formedness condition (2), the last two cases in the definition of E(x, Q) are mutually exclusive; because of well-formedness condition (3), we have E(xn , Q) ≃ 0. The encoding of a wscl activity diagram is now defined as E(x1 , Q). Checking that the wscl activity diagram of Figure 1 yields the recursive definitions given in §2.2 is an exercise as straightforward as tedious. Equally straightforward is to deduce the encoding of the “1-click ordering” extension and of the corresponding filter defined at the end of §3.2.1. That example shows that filters are needed even when service behavior is described by wscl diagrams, which restrict external choices to output actions and internal choices to input actions (see Remark 5.5 for a thorough analysis). 5.3 Typing ws-bpel activities ws-bpel [Alves et al. 2007] is an Oasis standard language for the description of business processes. It builds on top of standard Web service technologies, such as wsdl, for providing a detailed, structured description of Web services behavior, including exception and compensation handlers. Being a concrete Web service specification language, ws-bpel is hard to formalize thoroughly. In our setting, however, we are merely concerned with the observable behavior of a Web service, hence we can disregard any detail that is not directly related with the interactions of the Web service with the external world. Furthermore, we gain in clarity by getting rid of the heavyweight xml syntax used in ws-bpel and by preferring a streamlined algebraic presentation, which the reader will easily match with the original language. A ::= | | | | | actionhαi pickha1 .A1 , . . . , an .An i sequencehA1 , . . . , An i ifhA1 , . . . , An i flowhA1 , . . . , An i whilehAi n≥0 n≥0 n≥1 n≥0 TO APPEAR IN ACM Transactions on Programming Languages and Systems 42 · Castagna, Gesbert, and Padovani Table IV. Type system for ws-bpel activities. (pick) (action) ⊢ actionhαi : α ⊢ A1 : σ1 (sequence) ⊢ A1 : σ1 ··· ⊢ An : σn ⊢ pickha1 .A1 , . . . , an .An i : a1 ; σi + · · · + an ; σn (if) ··· ⊢ An : σn ⊢ sequencehA1 , . . . , An i : σ1 ; . . . ; σn ⊢ A1 : σ1 ··· ⊢ An : σn ⊢ ifhA1 , . . . , An i : σ1 ⊕ · · · ⊕ σn (flow) ⊢ A1 : σ1 (while) ··· ⊢ An : σn actions(σi ) ∩ co(actions(σj )) = ∅ i,j∈1..n ⊢ flowhA1 , . . . , An i : σ1 k · · · k σn ⊢A:σ ⊢ whilehAi : σ ⊛ The above grammar describes a substantial fragment of ws-bpel so-called activities (i.e., processes).4 The activity actionhai denotes the invocation of operation a or, more generally, the act of sending a message on a channel identified by a; it can be used for representing both invoke and reply activities in ws-bpel. The activity actionhai denotes the act of waiting for an interaction on a channel identified by a; it can be used for representing receive activities. The pick activity allows the service to provide multiple operations, among which the client can choose which one to execute. Each action ai denotes an operation that, when invoked, causes the corresponding activity Ai to be executed; the sequence activity sequentially activates the specified sub-activities, Ai+1 starting only when Ai is completed; the if activity performs an internal choice among the specified sub-activities according to the result of some Boolean conditions that we leave unspecified in the syntax; the while activity sequentially executes the specified sub-activity as long as some Boolean condition (once more left unspecified) is verified; the flow denotes the parallel composition of the specified sub-activities; it completes when all the subactivities have completed. We write empty for sequencehi, for pickhi, and for flowhi. Table IV shows the type system for ws-bpel activities, where a judgment ⊢ A : σ associates an activity A with its contract σ. Most rules are completely straightforward as ws-bpel activities map very naturally to the contract operators described in §5.1. The only rules that deserve some explanation are (flow) and (while). Regarding (while), the choice as to whether the sub-activity A must be executed once more or the repetition has ended is made internally, by evaluating some unspecified condition. Hence the use of the internal Kleene star ⊛ in the resulting contract. Because of the side-condition in the semantics of σ ⊛ , not every while activity is well typed. For instance, whilehifhempty, actionhaiii is not well typed because the contract of the repeated activity has an empty ready set. Regard4 We did not considered (i) activities, such as throw or rethrow, for signalling exceptions and handle them; (ii) activities, such as repeatUntil or forEach, that can be encoded in the given fragment; (iii) activities, such as wait or assign, whose effects are not directly observable outside the process. The ws-bpel standard also defines a number of so-called static analysis requirements to constrain the form of activities. We disregard them since they mostly deal with aspects, such as scope and link declarations, that we want to abstract from. TO APPEAR IN ACM Transactions on Programming Languages and Systems A Theory of Contracts for Web Services · 43 ing (flow), the sub-activities are allowed to run concurrently and independently of each other. Thus, the contract of a flow activity is given by all the possible interleaving of actions in the contracts of the sub-activities. This interleaving is computed by the k operator, which is defined as follows: P P def L σkτ = β∈s β; (σ k τ (β))) α∈r α; (σ(α) k τ ) + σ⇓r,τ ⇓s ( It is easy to verify that σ k τ is well defined (it is a regular contract, viz., it satisfies guardedness conditions) and that k is a commutative, associative operator whose neutral element is 0. The premise actions(σi ) ∩ co(actions(σj )) = ∅ (we use actions(σ) to denote the set of all actions occurring in σ) imposes that no message exchange is allowed within the same ws-bpel business process.5 This allows us to express k as a simplified form of the expansion law as it is found in [De Nicola and Hennessy 1987; Hennessy 1988]. Briefly, the interleaving of σ and τ is equivalent to an internal choice of all possible combinations of an internal choice of σ with an internal choice of τ ; for every such combination the interleaving contract gives the client the choice to synchronize either with an α action of σ (in which case it then continues with the interleaving of the continuation of α and τ ) or with a β action of τ (in which case it then continues with the interleaving of the continuation of β and σ). We do not define any operational semantics for the activities. As a matter of fact this is already given by the type system of Table IV: contracts being behavioral types, they faithfully describe the operational semantics of activities. More importantly, our theory of contracts provides us with a formal tool for reasoning about safe replacement and upgrade of ws-bpel activities, by comparing the corresponding contracts. For instance, the depth and width subtyping properties enjoyed by  tell us that it is safe to replace an activity A with an activity sequencehA, A′ i and also that it is safe to replace pickha1 .A1 , . . . , am .Am i with pickha1 .A1 , . . . , an .An i where n ≥ m. In the first case, we are appending additional functionalities to some business process; in the second case, we are providing additional alternative functionalities to a business process. The following result shows that we can also derive interesting substitution properties for sequence and flow: Proposition 5.2. Let actions(σ) ∩ actions(τ ) = ∅. Then σ; τ  σ k τ . def Proof. It is sufficient to prove that W = {(σ, σ k τ ) | actions(σ) ∩ actions(τ ) = ∅} ∪ {(σ; τ, σ k τ ) | actions(σ) ∩ actions(τ ) = ∅} is a weak subcontract relation. Let (σ, σ k τ ) ∈ W and assume σ k τ ⇓ r. By definition of σ k τ there exist r′ and s such that σ ⇓ r′ and τ ⇓ s and r = r′ ∪s, from which we derive r′ ⊆ r. Let α ∈ r′ . Then (σ k τ )(α) ≡ σ(α) k τ by definition of σ k τ and we conclude (σ(α), σ(α) k τ ) ∈ W by definition of W . Let (σ; τ, σ k τ ) ∈ W and assume σ k τ ⇓ r. Then there exist r′ and s such that σ ⇓ r′ and τ ⇓ s and r = r′ ∪ s. We have two cases: (1) if r′ 6= ∅, then σ; τ ⇓ r′ and we derive r′ ⊆ r; (2) if r′ = ∅, then σ; τ ⇓ s and we derive s ⊆ r. In case (1), assume α ∈ r′ . From the encoding of σ; τ and from the hypothesis actions(σ) ∩ actions(τ ) = ∅ we have (σ; τ )(α) ≡ σ(α); τ and by definition of k we 5 In ws-bpel, actions used for synchronizing activities of a flow must be invisible outside the flow. TO APPEAR IN ACM Transactions on Programming Languages and Systems 44 · Castagna, Gesbert, and Padovani have (σ k τ )(α) ≡ σ(α) k τ and we conclude (σ(α); τ, σ(α) k τ ) ∈ W by definition of W . In case (2), assume α ∈ s. From the encoding of σ; τ and from the hypothesis actions(σ) ∩ actions(τ ) = ∅ we obtain (σ; τ )(α) ≡ τ (α) and by definition of k we have (σ k τ )(α) ≡ σ k τ (α) so we conclude (τ (α), σ k τ (α)) ∈ W again by definition of W . As a corollary of Proposition 5.2 observe that σ  σ k τ when σ and τ share no common action. Let f : σ; τ ≤ σ k τ and let ⊢ A : σ and ⊢ B : τ . Proposition 5.2 can be interpreted in two different ways: when reading σ; τ  σ k τ from left to right, the proposition gives us sufficient conditions by which we can replace sequencehA, Bi with flowhA, Bi when A and B are independent activities and we want to increase the service throughput by taking advantage of parallelism (for instance, because the machine hosting the Web service has been upgraded and is now multiprocessor). In this case the clients of the old, sequential Web service can still interact successfully with the upgraded, parallel one, provided that the interaction is shielded by f . On the other hand, when reading σ; τ  σ k τ from right to left, the proposition gives us sufficient conditions by which we can approximate the behavior of flowhA, Bi with that of sequencehA, Bi. Indeed, the size of contract σ k τ may grow exponentially with respect to the size of σ and τ because of the use of continuations σ(α) and τ (α) and of the interleaving semantics in the definition of k. For instance, we have a.b k c.d = a.(b.c.d + c.(b.d + d.b)) + c.(a.(b.d + d.b) + d.a.b) and it might be desirable to approximate a.b k c.d with a.c.b.d. However, doing so without filters can be dangerous, as the following example shows. Consider def the client contract ρ = a.(b.b.e + c.b.d.e). Then ρ ⊣ a.c.b.d, hence a client having contract ρ would be declared compliant with the service whose approximate contract is a.c.b.d. However, by inspecting the expansion of a.b k c.d we realize that the contract of the service does actually provides some behaviour for the case for a b action right after the action a, so the client (process) might get stuck trying to read a second b after the first one. By applying the filter a.c.b.d, we prevent any synchronization on b to happen during the second interaction, thus guaranteeing that the client successfully terminates. We conclude this section with some observations on one of the characteristics that distinguish our approach from the current literature on service contracts and session types and that make it more general. While in all work on contracts and sessions we are aware of external choices take place on input actions and internal ones emit output actions, in our formalism we have no such restrictions and therefore we allow input actions to guard internal choices and output actions to guard external choices. The type system in Table IV shows that both these features are necessary to type ws-bpel processes. In particular, as regards internal choices observe that there is no constraint on the actions that can be used in an if activity. Thus, for instance, one can write ifhactionhai, actionhbii whose type, a ⊕ b, performs an internal choice that may issue an input on b. As regards external choices, the activities in a flow activity can be of any form. Thus, for instance, the contract of the activity flowhactionhāi, actionhbii turns out to be a.b + b.a which guards one branch of an external choice with an output action a. TO APPEAR IN ACM Transactions on Programming Languages and Systems A Theory of Contracts for Web Services · 45 External choices on outputs may also directly stem out from more advanced wsbpel usages. Indeed, consider the contract a ⊕ b above corresponding to an if activity. A client of a service with this behavior must necessarily offer, by means of an external choice, both an input on a and an output on b. The simplified abstract syntax for ws-bpel we have provided does not permit the specification of a process with this behavior, as we have imposed the restriction that all activities in a pick activity are guarded by the input actions. This is the most common usage for pick activities, since in ws-bpel pick elements usually contain a list of several onMessage events. For instance the following streamlined ws-bpel syntax <pick ... > <onMessage operation="a1 " ... > A1 </onMessage> . . . <onMessage operation="an " ... > An </onMessage> </pick> denotes the term pickha1 .A1 , . . . , an .An i. However ws-bpel allows the programmer to enrich pick activities with an onAlarm event. This event specifies a timeout and an activity that will be executed if no onMessage event is received within the timeout. From the behavioural point of view, onAlarm events are indistinguishable from onMessage ones. In particular, it would be wrong to model timeouts with internal choices, as this would make the process incompatible with those parties that do readily send a message targeted to one of the onMessage events. Since there is no restriction on the activity of an onAlarm event, then this can be an output activity. For instance, the activity <pick> <onMessage operation="Invoice"> A1 </onMessage> <onAlarm> <for>’P3DT10H’</for> <!-- timeout interval of 3 days and 10 hours --> <sequence> <invoke operation="RequestInvoice" ... > A2 </sequence> </onAlarm> </pick> would be typed as Invoice.A1 + RequestInvoice.A2 , thus mixing once more input and output actions in an external choice. 5.4 On implementing filters We have presented filters as behavioral coercions that enlarge the set of Web services a client is compliant with. Basically, the filter mediates the interaction between client and service by forbidding actions that can potentially lead the client to a deadlock. The filter, however, has no power over the internal choices made independently by client and service. In our theory, this latter fact is remarkably rendered by rules (IChoice) and (EChoice) (see Table I on page 21), in which the same filter must be applicable for all the branches of internal and external choices, in order to work correctly. Do filters actually play a role in real-world Web services? If so, do they admit effective, and hopefully efficient, implementations? As regards the first question, we notice that a filter is actually a well known actor in the Web service scenario: it is an example of Web service orchestrator. An orchestrator is TO APPEAR IN ACM Transactions on Programming Languages and Systems 46 · Castagna, Gesbert, and Padovani simply a process whose task is to coordinate other processes in such a way so as to guarantee that their interaction eventually leads to the achievement of a goal (in our setting, the goal being client satisfaction). As regards the implementation of filters, we discuss it in the rest of this section. Before moving on, let us stress that the purpose of what follows is not to show the use, importance, and/or expressiveness of filters but, rather, what their implementation could possibly look like in some well-known frameworks and reasonable usage scenarios. In other terms we show that given an existing set of clients and services, it is possible to use well-known distributed abstractions (such as join patterns) and/or current technology (such as ws-bpel processes) to implement filters that enhance compatibility in this set. 5.4.1 Implementing filters as join patterns. A first observation is that filters can be rendered by means of binary join patterns (in the style of the Join calculus [Fournet and Gonthier 1996; Fournet et al. 1996]) of the form α & β, which can be thought of as an atomic action that can be executed provided that α and β are simultaneously available in the execution environment. Then, a filter f may be implemented as a (finite-state) process CJf K as follows P CJf K = f 7−α→f ′ α & α′ .CJf ′ K where we use α′ to distinguish the action α performed by the filtered service, so that it is not confused with the action α as it is seen by the client. Then a client P and a service Q safely interact with each other under the supervision of the filter/orchestrator: P k CJf K k Q{α1′ /α1 , . . . , αn′ /αn } where α1 , . . . , αn are the actions occurring in Q and k denotes the usual parallel composition of processes. The problem then reduces to the effective implementation of join patterns. It is well known that implementations of the Join calculus all pose strong requirements over the channels being joined together, namely that they must all be created simultaneously with the patterns in which they are involved, and that they must all be local to the host that created them. However, it has also been shown in [Laneve and Padovani 2006] how to partly relax these constraints so that only locality is actually required in order to avoid a global consensus problem, and that join patterns can be dynamically attached to the site hosting the channels being joined. 5.4.2 Filters as one-position buffers. The second observation is that, for an interesting subclass of processes, join patterns are not necessary at all. If we assume that, at any time, the service can only (internally) decide to send messages, or can only (externally) wait for messages, then the compilation scheme sketched above reduces to the straightforward process P P a′ .a.CJf ′ K CJf K = f 7−a→f ′ a.a′ .CJf ′ K + a ′ f 7−→f in which, for every f , at most one of the two sums is nonempty. This subclass is interesting because it exactly characterizes processes behaving according to session types [Honda 1993; Takeuchi et al. 1994; Honda et al. 1998] (as well as to other theories of contracts proposed in literature: cf. §6 on related work) where at any TO APPEAR IN ACM Transactions on Programming Languages and Systems A Theory of Contracts for Web Services · 47 time only one process, either the client or the service, decides the next action to be executed. In this respect, the generality of our contract language might at first appear excessive, since it allows a mixture of input and output actions irrespective of the choice operators with which they are combined. In particular, at first glance it might seem reasonable—and even natural—to restrict output actions to internal choices, and input actions to external choices. However, it is not so: as it is clearly shown by Table IV, by the definition of the “k” operator given earlier, and by the examples that close §5.3 such a generality is necessary in practice, since input and output actions can occur as guards in both internal and external choices of real world Web services contracts. 5.4.3 Implementing filters in ws-bpel. The language of filters we have adopted is very simple. Given f : σ ≤ τ , the structure of f tells us very little about the actual behavior of σ and τ . It is reasonable to expect that, by enriching the language of filters with constructs that more faithfully describe the structure of the proof that relates σ and τ , one is able to provide efficient implementations in a wider range of situations. Nevertheless even if we want to implement just these “simple” filters by means of ws-bpel processes, we cannot hope to obtain much more than what we did with one-position buffers. The point of the encoding in §5.4.1 is to exploit join patterns for detecting the simultaneous presence, on the server and on its client, of an action and its coaction. This cannot be expressed (at least not straightforwardly) in a ccs-like formalism nor in ws-bpel, which solely relies on low-level communication primitives. Consequently we must restrict our attempt of encoding filters as ws-bpel processes to staged computations in which just one of the partners has the floor (i.e., it has the exclusive right to fire a write action / to send a message). This, combined with the fact that the syntax of pick forces external choices to be performed on inputs, yields to a subcontracting hierarchy very close to the one relating session types [Gay and Hole 2005]. In what follows we outline a formalization of this hierarchy and its benefits in ws-bpel. The point is not to study the expressiveness of ws-bpel but to show that the theory presented in this paper can be applied to ws-bpel and to wsbpel processes in the current form. In a nutshell, if we want to check whether two ws-bpel processes are or can be made compliant, then what we have to do is (i) to extract their contracts by means of the type system in Table IV, (ii) to check whether the extracted contracts are compatible with a staged computation (that is, whether the filter that makes them compatible is an input filter : see Definitions 5.3 and 5.4 below), and (iii) to automatically synthesize the ws-bpel process implementing the filter that makes the client compliant with the service. Thus the theory is immediately applicable to a class of existing ws-bpel processes to combine them more flexibly (thanks to the width subtyping that allows us to update services with new features) without the need of adding new primitives or constructors (such as session types labels and labeled selections) to ws-bpel nor of modifying the code of existing processes. More precisely, the filters that we can reasonably encode in ws-bpel are those that never filter out output messages and that relate staged contracts, having the following form. Definition 5.3 (staged contract). We say that the (service) contract σ is TO APPEAR IN ACM Transactions on Programming Languages and Systems 48 · Castagna, Gesbert, and Padovani P every i, j ∈ I such that i 6= j we have staged if either (1) σ ≃ i∈I ai ; σi and for L ai 6= aj and each σi is staged or (2) σ ≃ i∈I (ai1 k · · · k aini ); σi and for every i, j ∈ I such that i 6= j we have ai1 6= aj1 and each σi is staged. In case (1) we say that σ is staged if it describes a service that lets the client decide which message to send. In case (2) we say that σ is staged if it describes a service that can be in one of |I| different states and in each state i ∈ I the service sends a message ai1 that distinguishes that state from all the others, along with possibly more messages ai2 , . . . , aini (observe that |I| > 1 implies ni > 0 for every i ∈ I). Then, the service continues behaving as a staged contract σi . A filter that never filters out output messages is called input filter and is formally defined below. Definition 5.4 (input filter). We say that f is an input filter for the (serϕa ϕ a vice) contract σ if σ 7−→ and f 7−→ f ′ implies f ′ 7−→. Namely, an input filter never filters out any output action, unless this is guarded by an input action that has been filtered out. Given an input filter f for a staged (service) contract σ, the ws-bpel process that implements f , denoted by F (f, σ), can be defined as follows:  ai P  if σ ≃ i∈I ai .σi pickhai .actionha′i i; F (f (ai ), σi ), . . . i(i∈I,f 7−→)       pickha′i1 .sequencehactionha′i2 i, . . . , actionha′ini i, def F (f, σ) = flowhactionhai1 i, . . . , actionhaini ii,      F (f (ai1 · · · aini ), σi )i, . . . i(i∈I)   L  if σ ≃ i∈I (ai1 k · · · k aini ); σi If σ is an external choice of input actions, then the filter simply waits for a ai message on one of those input actions ai that have not been filtered out (f 7−→). Once such a message is received, the filter delivers it to the service. If σ is an internal choice of (possibly concurrent) output actions, then the filter waits for a message ai1 from the service. Since σ is staged, all the ai1 ’s are distinct hence the pick activity is well formed. When a message is received, the filter unambiguously knows the state the service is in, hence it collects all the other messages produced by the service in that state. Then, all the collected messages are delivered to the client, because f is an input filter. Remark 5.5. The reader may wonder whether one still needs filters, given that we are now considering only services that implement staged contracts. Indeed the reader may legitimately suspect that by forcing services to behave according to staged contracts we are falling back to a scenario similar to the one of sessions types, where filters are not needed. The point is that, while we assume services to implement staged contracts, we do not impose the same requirement for clients, which are free to implement any behavior that can be expressed with our contract language, including those for which filters are needed. The example described at the end of §2.2.2, showing that filters are necessary to make wscl-specified services compatible, applies here as well. Indeed, notice that every contract described by a wscl activity is trivially staged (for all i ∈ I we have ni = 1, in Definition 5.3) which TO APPEAR IN ACM Transactions on Programming Languages and Systems A Theory of Contracts for Web Services · 49 means that the filter for “1-click ordering” extension can be implemented by a wsbpel process and that the same problematic client that disrupts compatibility there, does the same here. It is not a coincidence that such client is not staged since it performs an external choice on the output of Buy. Conversely, had we considered a scenario that, besides staged services, included only clients with staged contracts (e.g., clients whose behavior is described by wscl diagrams), then filters would have been unnecessary, as it is the case for session types. 6. RELATED WORK The contracts used in this presentation draw their inspiration from De Nicola and Hennessy’s seminal work “ccs without τ’s” [De Nicola and Hennessy 1987], as well as from acceptance trees [Hennessy 1985; 1988] of which they can be considered an alternative representation. The works that are most closely related to ours are by Carpineti et al. [2006], Derrick et al. [1996], and those on session types, especially the one by Gay and Hole [2005]. In [Carpineti et al. 2006] the subcontract relation exhibits all the desirable properties we illustrated in the Introduction (§1) till equation (1), but subcontracting stops there at the problem of transitivity. In that work compliance was a syntactic notion and contracts lacked a semantic characterization. Derrick et al. [1996] provide a thorough overview of refinement relations in the testing framework that date back to the LOTOS system [Brinksma et al. 1995]. According to the terminology of [Derrick et al. 1996], the relation a ⊕ b.c  a is an instance of so-called reduction refinement, in which a ⊕ b.c is replaced by a thus reducing nondeterminism. On the other hand, a  a + b.d is an instance of so-called extension refinement, in which a a is replaced by a + b.d which provides further functionalities. The combination of these two refinement relations yields the so-called implementation refinement, which basically coincides both with the subcontract relation defined in [Carpineti et al. 2006] and with the ⋉ relation we introduced in this work (see equation (2) in §2.3 and the proof of Theorem 3.4). It is known that extension refinement is not a precongruence with respect to the contract operators and that implementation refinement lacks transitivity [Derrick et al. 1996]. As already anticipated in the Introduction (§1) and formally shown in §3.3, the present paper addresses and solves both problems: precongruence can be regained under minimal conditions, namely when filtering does not depend on the internal choices of client and service and transitivity stems directly from the ability of composing filters. Session types were introduced in the context of the π-calculus [Honda 1993; Takeuchi et al. 1994; Honda et al. 1998]. These are used to type special channels through which several messages of different types may be exchanged in sequence according to a given protocol. Such a session channel can be seen as a client-service connection, and the session type is the analogous of our contract as it describes which actions the processes may perform through this channel. With respect to our work there are two fundamental differences: the first difference is conceptual, in that session types are used for typing channels, whereas contracts are used for typing processes. Clearly a contract can be used for describing the communications occurring on the channels owned by a process, but it also describes the temporal dependencies between these communications. On the other hand, session types TO APPEAR IN ACM Transactions on Programming Languages and Systems 50 · Castagna, Gesbert, and Padovani describe the communications occurring on the channels in isolation. Encodings between the two formalisms are possible under some conditions as described in [Laneve and Padovani 2008]. The second difference is that session types have the important restriction, if compared with contracts, that only one part has the floor at a given time: whenever a process performs an internal choice it has to indicate explicitly which path of interaction it has chosen, and the other process has to be waiting for this indication. Thus there is no way of mixing internal and external choices, and two processes like a + b and a + b do not interact successfully (because nobody has the floor, so no communication can happen). Subtyping for session types has been studied by Gay and Hole [2005], but because of the aforementioned restriction, the transitivity problem we address in this paper does not exist for them: internal and external choices can never be related, hence a ⊕ b  a + b does not hold. However, this looks like a reasonable relation, inasmuch as a ⊕ b models a scenario where exactly one of two resources a and b is available (and the client does not know which one), which can be safely related with (and replaced by) a scenario where both a and b are available and the client can choose whether to use a or b. The example given in the Introduction (§1) right before the outline of the presentation (§1.1) is just an instance of this scenario. Carbone et al. [Carbone et al. 2007a; 2007b] describe choreographies of Web services by means of a global calculus, and descriptions of individual processes are obtained as projections of the global description. Both the global description and the projections are based on session types. In our approach, the typical application is searching for a service compatible with a given protocol from the client’s point of view : in particular, we want depth subtyping (a service that tries to pursue the interaction after the client has successfully terminated is compatible with this client), which does not hold for session types. In summary, we believe that our theory is more abstract than that of session types, basically because in contracts there is a neat separation of control (which is expressed as a combination of internal and external choices) and communication (which is expressed by means of actions). This allows us to type arbitrary processes, as opposed to communications in which the end-points follow a rigid discipline, and to describe more abstract synchronization patterns, such as those arising when two external choices interact with each other. Therefore, not only, as described in [Laneve and Padovani 2008], session types can be seen as a low-level implementation of the communications described by a contract, but also it is possible to draw inspiration from out theory of contracts to generalize current presentations of session types as shown by Castagna et al. [2008]. Although the work presented here considers dyadic interactions between a single client and a single server, the theory can be smoothly extended to multi-party interactions. This is proved by Bernardi et al. [2008] who extend our work (more precisely the version in [Castagna et al. 2008]) for dealing with choreographies of Web services. Apart from a few technical differences—Bernardi et al. disallow different summands of an external choice guarded by the same action and uses a fair variant of compliance—[Bernardi et al. 2008] shows how filters provide a new interesting solution to the problem of Web service composition [Traverso and Pistore 2004; Berardi et al. 2003; Hull et al. 2003; Pistore et al. 2005; De Giacomo and Sardiña TO APPEAR IN ACM Transactions on Programming Languages and Systems A Theory of Contracts for Web Services · 51 2007] in particular for what concerns the automatic synthesis of adapters [Berardi et al. 2003; De Giacomo and Sardiña 2007]. In [Bernardi et al. 2008] both contracts and filters are associated with locations and can be composed for describing and constraining the participants interacting in a choreography. The notion of compliance is extended to compositions of located contracts and an algorithm is defined that infers the greatest relevant composite filter (cf. §3.4.1 in this work) that makes a composition of located contracts satisfy compliance (which corresponds to our Corollary 3.24). Additionally Bernardi et al. [2008] propose a new usage of filters, which can be seen as a specification of the roles occupied by the participants of a choreography. Since our work is about characterizing processes whose composition always successfully terminates, there is an obvious connection with the research work on termination and deadlock in process algebras. Among the vast literature on these topics, we want to single out and discuss the work by Fournet et al. [2004], as it allows us to identify the points in common but, above all, the different perspective that distinguishes the two researches. Fournet et al. [2004] define a conformance preorder on ccs processes with the property that a process is stuck-free (i.e., it successfully terminates) in every context in which smaller processes are stuck-free. The conformance relation of [Fournet et al. 2004] differs from our subcontract relation in some technical aspects. For example, in [Fournet et al. 2004] a ⊕ 0  0, but a ⊕ 0 6 a. This essentially derives from the fact that stuck-free conformance is defined without using an explicit action (denoted by e in our work) expressing in an observationally visible way the successful termination of a party, but instead by requiring that the party must eventually reduce to the idle process 0. Doing so prevents the specification of clients of the form e+a.e, that attempt to do an action, but that can succeed even if the action is not available. The lack of the explicit action e has overall important consequences on the precongruence properties of . A more substantial difference between our work and [Fournet et al. 2004] is the viewpoint from which processes/contracts are observed. We insist on characterizing the externally observable behavior of a service (we consider services as black boxes whose internal details do not transpire) and this has important consequences at three different levels: (1) At the contract language level, we may disregard the internal implementation of the service, provided that the contract language is expressive enough to fully capture its behavior. Thus, Fournet et al. [2004] take into account restriction and parallel composition, while we do not since, as we explain in detail in the Conclusion (§7), these describe some internal structure of the service that we want to abstract from in its contract. (2) At the operational semantics level, we define an “objective” transition relation of service contracts that takes into account the point of view of clients of the service. On the contrary, Fournet et al. [2004] work with the standard, “subjective” transition relation where the visible behavior of processes is given from the perspective of the process itself. A paradigmatic example that sheds light on this difference is the reduction of the process/contract a.σ + a.τ . In our apa proach we have a single reduction a.σ + a.τ 7−→ σ ⊕ τ (cf. Definition 2.2), since an external observer that has just observed the a action cannot tell whether TO APPEAR IN ACM Transactions on Programming Languages and Systems 52 · Castagna, Gesbert, and Padovani the observed process has taken the right or the left branch: it must consider both possibilities as an internal choice of the observed process. In standard ccs semantics instead, since the process knows the choice it has made, then two a a different reductions are possible, namely a.σ + a.τ −→ σ and a.σ + a.τ −→ τ , each corresponding to a different choice. (3) At the containment relation level, we adopt a testing approach [De Nicola and Hennessy 1984; Hennessy 1988]. As a consequence, two processes are related by the subcontract relation  if all the clients compliant with the smaller process are also compliant with the larger one. Contrariwise, the conformance relation in [Fournet et al. 2004] is defined as the largest simulation relation that is consistent with stuck-freedom. As a result, the conformance relation of Fournet et al. is not complete with respect to stuck-freedom, in the sense that there are processes that are stuck-free exactly in the same contexts but are not related by conformance. For example, a.(b ⊕ c) and a.b + a.c are stuck-free equivalent but are not conformance equivalent: since they are not bisimilar, then in the setting of Fournet et al.—which is a “subjective” one—it would be wrong to replace one for the other. In our context instead we want to be able to replace services as long as their external observable behaviours are compatible, which is why in our theory the two processes above are equivalent. For the same reason, while in [Fournet et al. 2004] completeness with respect to stuck-freedom is not sought and conformance does not allow either width or depth subtyping, in our setting completeness is a key property since it ensures maximal substitutability for equivalent external behaviour and width or depth subtyping are key mechanisms for a modular application of substitutability. This change of perspective—objective external observer vs. subjective internal observer—explains why, mutatis mutandis (cf. actions for successful termination, parallel composition, restrictions, etc.), one can roughly see our work as a complete characterization of stuck-freedom and, reciprocally, consider conformance as a stricter subcontracting relation that takes into account subjective aspects such as internal implementation. Bravetti and Zavattaro [2007] propose a contract language equipped with a refinement relation. The language includes all the classical operators found in common process algebras (parallel composition, restriction, etc.), but is constrained so that output actions occur can only occur in the context of an internal choice. This restriction somehow resembles the design choice of session types and, not surprisingly, the refinement relation for this language allows width extensions without any intervening filtering. However, while the presence of parallel composition in the contract language suffices for modelling processes that offer output messages in such a way that the interacting party can externally choose the order in which they are consumed, the modelling of timeouts (cf. §5.3) would require an extension to the language of Bravetti and Zavattaro. We remark two further differences regarding the refinement relation in [Bravetti and Zavattaro 2007] and our subcontract relation: the first is that the refinement relation depends on (is indexed by) a set of (output) actions that may occur in the environment, and width subtyping is determined by this dependency in the sense that it is possible to extend behaviors with additional, input-guarded branches if one knows that no output message will TO APPEAR IN ACM Transactions on Programming Languages and Systems A Theory of Contracts for Web Services · 53 ever be able to trigger such branches. This roughly corresponds to a static form of action filtering in our setting and in that respect they adopt a solution similar to the one proposed in the work by Laneve and Padovani [2007] we discuss at the end of this section. Moreover, the refinement relation is determined in a symmetric way for all the participants of a system, whereas our notion of compliance is asymmetric (in favor of the client). This makes their refinement relation more demanding than ours. In particular, all the participants must successfully terminate, meaning that depth extensions are not entailed by refinement. A very preliminary version of this work was presented at Plan-X 2007 workshop [Castagna et al. 2007] and largely improved in the version presented one year later at Popl ’08 [Castagna et al. 2008]. Although the Plan-X workshop has just informal proceedings, these are available on the web. Therefore it seems worth discussing the differences of the present article both with the Plan-X version and with the improved Popl version. While the overall presentation and structure of the three papers is the same, both this and the Popl versions improve over the Plan-X one in several points. Here and in [Castagna et al. 2008] we consider a slightly different version of strong compliance relation which now coincides with the must testing preorder, while in Plan-X strong compliance differed from must testing for some (uninteresting) pathological cases that involved the empty contract. The deduction system of Plan-X was reworked in favor of elegance and simplicity. The resulting algebraic theory of filters is also cleaner. We present better results for language neutrality. Finally, the study of the algorithmic version of the deduction system, of its logical interpretation, and of the decidability of the containment relation, was absent from the Plan-X version and introduced in the Popl one. The article presented here improves the work in Popl in several regards. Foremost, while in the work presented at Popl contracts (and filters) were finite, here the theory is defined for recursive contracts (and filters) by working directly with infinite recursive trees and by proposing two different finite representations for them (we believe that the in-depth treatment of infinite terms and of the relation with their finite representations constitutes a nice contribution of our work). This implied a complete reworking of most of the definitions and of the proofs (even though the latter were not included in the Popl proceedings for space reasons). The finite representations we introduce here are then used to study wscl and ws-bpel and possible implementations of filters are explored; in particular we outline how our theory can be used and implemented in the current specification of ws-bpel without requiring any modification to the language or to existing ws-bpel processes. All these practical aspects are completely absent in the work presented at Popl. Finally, the deduction system for filters is here further improved and we also use a different and (we hope) more elegant syntax for filters, by relying only on the underlying algebraic operators. Starting from the Plan-X work the third author and Cosimo Laneve proposed a simplification where contracts are “statically” filtered [Laneve and Padovani 2007]: each contract is associated with a static interface (in the sense that it does not change over time) declaring the only visible actions of the contract and blocking all the other ones whenever they happen. As stated in [Laneve and Padovani 2007], the resulting approach is less general than ours and, consequently, yields a stricter TO APPEAR IN ACM Transactions on Programming Languages and Systems 54 · Castagna, Gesbert, and Padovani subcontract relation. For instance, the relation a.b  (a.(a + b)) + b.c, which we commented on just before §1.1, does not hold in the interface approach (for a practical example of relation that does not hold for interfaces see the contracts σ2 and σ2′ in §2.2.2 and the explanation given at the end of §3.2.1). On the other hand, interfaces allow for simpler algorithmic treatment and implementation. More recently Padovani [2008] has extended the framework in the present work by equipping filters with finite buffers. This extension allows filters to intercept messages exchanged between client and service, to temporarily save them in internal buffers, and to deliver them at a later stage, when client and service actually need them. As a consequence, the weak subcontract relation identifies larger classes of contracts. For example, it becomes possible to prove a.b.σ  b.a.σ as well as a.b.σ  b.a.σ. More generally, input actions can be delayed and output actions can be anticipated (a.b.σ  b.a.σ) but the converse is not true: b.a.σ 6 a.b.σ. Intuitively this is because the client of b.a.σ may need the information contained in the received message b before it sends the message a back to the service. The extension of filters with buffering also allows one to enlarge the class of filters that can be efficiently and effectively implemented as pure ccs processes (§5.4). 7. CONCLUSION AND FUTURE WORK This paper provides a foundation for behavioral typing of Web services by means of contracts and it promotes service reuse and/or redefinition by the introduction of a subcontract relation. Our contract language is the sequential fragment of ccs without parallelism, without explicit internal moves, without relabelling, and without restriction [De Nicola and Hennessy 1987]. The fact that we focus on this simple language may at first appear overly restrictive, especially because of the lack of parallel composition. However, recall that we are only interested in describing the external, observable behavior of Web services, not their internal implementation. So, while it is reasonable to expect that a Web service is internally implemented with parallel processes and private communications, we take the point of view that the contract language should be kept as simple as possible, as long as it can faithfully describe the service behavior. As we have pointed out in the related work section, our contract language is just a concrete representation for Hennessy’s acceptance trees [Hennessy 1985]. Well-known works [Hennessy 1988] show that—possibly infinite, but not necessarily regular—acceptance trees are a fully abstract model for fully-fledged variants of ccs. So, the only real restriction imposed by our contract language is regularity, which basically “limits” the application of the contract language to finite-state processes. In this respect, we observe first of all that working with finite-state processes/contracts clearly makes the whole theory decidable, and thus practically relevant. Second, it is a fact that concrete languages for Web service description and implementation (including wsdl, wscl, and ws-bpel itself) only deal with finite-state processes, at least as far as the observable, external behavior is concerned. As regards the subcontract relation, we reconcile two hitherto apparently incompatible requirements. On the one hand a subcontract relation must allow a service to be replaced or upgraded by offering more operations (width subtyping), TO APPEAR IN ACM Transactions on Programming Languages and Systems A Theory of Contracts for Web Services · 55 longer interaction patterns (depth subtyping) and/or more deterministic ones. On the other hand this must be done without disrupting the behavior of clients. In summary, we tackle and solve the lack of transitivity that arises when combining reduction and extension refinements as defined by Derrick et al. [1996]. Filters provide the technical device that makes it possible. Although we initially defined filters essentially as technical mechanism for coupling clients and services, filters turn out to have an elegant logical justification: they are explicit coercions between related contracts. Following the Curry-Howard isomorphism filters can be interpreted as proofs of a sound and complete deduction system for the subcontract relation. Such deduction system simultaneously refines and extends Hennessy’s classical axiomatization of the must testing preorder. Its algorithmic counterpart is obtained as a cut elimination process, which proves the coherence of subcontracting as a logical system. The canonical proof, the one produced by the algorithmic deduction system, is characterized in terms of an order relation on filters, and the algorithmic presentation allows us to show the decidability both of the subcontracting relation and of filter inference. The theory of subcontracting is independent of the language used to implement services and clients. We do not rely on a particular language nor on a particular paradigm (objects, process algebras, functions, . . . ). By defining some minimal requirements on the language (in a nut-shell, the observable behavior of its programs must be faithfully captured by contracts), we establish the soundness of our contract system: clients always terminate interactions with any, possibly filtered, compliant service. We have also shown that we do not need either to extend ws-bpel syntax or to reprogram existing ws-bpel processes in order to apply to them the theory presented in this paper and thus reuse them in more contexts. Filters thus play the double role of a proof tool and of programming glue between clients and services. As an aside it is nice to notice that filters can encode ccs and π-calculus restrictions: (νa)P = faP [P ] where W faP = α∈(fn(P )∪co(fn(P ))\{a,a} α.faP . That is, a restriction is nothing but a recursive filter that allows all actions apart from the restricted one. Even if in this presentation we applied filters to services, in practice it is the client’s responsibility to apply them. A client searching for a service with a given contract will receive as answer to its query the reference of a service together with a filter that allows the client to use the service. Thus the filter must be computed by the query engine, which is why the algorithmic inference of filters is crucial for a practical application. Actually, it is more realistic to imagine that a query will be answered with several different contracts requiring filters that may be unrelated to each other. Therefore a second use of filters could be that of refining the search space, by specifying in a query a minimum acceptable filter. In this way the client could specify which of the possible behaviors of its “canonical” service are considered mandatory and not to be filtered out. For instance, when searching for services implementing the behavior described in Figure 1 we could specify, along with the query, the filter Login.ValidLogin.Query.Catalog.AddToCart. Buy.(CreditCard.Valid ∨ BankTransfer.Valid) thus obtaining only services that may complete a sale, avoidTO APPEAR IN ACM Transactions on Programming Languages and Systems 56 · Castagna, Gesbert, and Padovani ing useless services such as those with contract Login.InvalidLogin. This use of filters is similar to that proposed in [Bernardi et al. 2008] (cf. §6) where filters also define “roles” of a choreography, that is specifications of the minimal behaviour each component of the choreography must provide. From a technical viewpoint this work introduces some novelties. An original aspect of this line of research is the use of a non-standard labeled semantics for ccs terms— which we first introduced in [Carpineti et al. 2006]—that captures the evolution of a process from the perspective of an external observer rather than, as for standard ccs semantics, from the perspective of the process itself. We believe this to be the right perspective for analyzing observable behaviour of web-services even though, as a matter of fact, this feature is not strictly necessary (one could equivalently use standard ccs semantics as done by Laneve and Padovani [2007], Padovani [2008], and Bernardi et al. [2008]). Another technical novelty introduced here is the use of infinite trees to represent recursive terms: although this technique is recurrently used in functional programming context, in our ken this is the first usage in the setting of concurrency theory where systems always rely upon some particular concrete syntax for recursive definitions. Similarly, while in a functional setting coercions and their interpretation via Curry-Howard isomorphism as proofs of some containment relation are not surprising, we never met them before in the realm of concurrency. Several future research directions stem from this work. The following is a nonexhaustive list: —Higher-order contracts: In the current formalism synchronization does not carry any information. Thus a natural next step is the introduction of higher order channels à la π-calculus. —Asymmetric choices: The choice operators are commutative. We could try to relax this property in order to give the summands different priorities, which is impossible with the current definitions. For instance, there is no way for a client that has to use a service with contract (a + b) ⊕ a to specify that it wants to connect with b if this action is available, and with a otherwise (in order to be compliant it must accept a possible synchronization with a). It is unclear to which extent such constructs would affect the  preorder over contracts. —Contract morphisms: The only morphisms between contracts we have considered are filters. Since filters are coercions, then by definition they essentially do not alter the semantics of objects. One could try to consider more expressive morphisms (e.g. renaming or reordering of actions) and to perform service discovery modulo such morphisms: when searching for services of a given contract a client could be returned a service and a conversion function that adapts the interaction pattern of the client to the service at issue (somewhat similar to, but less stringent than, libraries searches modulo type isomorphisms [Rittri 1993; Di Cosmo 1995]). This could set the basis of a new theory of orchestration where light and highly distributed orchestrators would be implemented by filters and contract morphisms. TO APPEAR IN ACM Transactions on Programming Languages and Systems A Theory of Contracts for Web Services · 57 As explained in the section on related work (§6), a step in this direction has already been done in [Padovani 2008]. This approach could later be extended to richer query/discovery languages obtained by adding union, intersection and negation types on the basis of the set-theoretic interpretation presented here and of the work on semantic subtyping [Castagna and Frisch 2005; Frisch et al. 2008]. —Relation with other formalisms: Finally, connection with other formalisms such as linear logic, session types, and game semantics must surely be deeply investigated. In particular, as regards the semantic aspects, it is interesting to notice that clients and services introduce a notion of orthogonality which suggests that a realizability semantics for contracts is worth exploring. REFERENCES Alves, A., Arkin, A., Askary, S., Barreto, C., et al. 2007. Web Services Business Process Execution Language Version 2.0. OASIS Standard, http://docs.oasis-open.org/wsbpel/2. 0/OS/wsbpel-v2.0-OS.html. Baeten, J. C. M., Corradini, F., and Grabmayer, C. A. 2007. A characterization of regular expressions under bisimulation. J. ACM 54, 2, 6. Banerji, A., Bartolini, C., Beringer, D., Chopella, V., et al. 2002. Web Services Conversation Language (wscl) 1.0. W3C Note, http://www.w3.org/TR/2002/NOTE-wscl10-20020314. Bellwood, T., Capell, S., Clement, L., Colgrave, J., et al. 2005. uddi Version 3.0.2. OASIS Standard, http://uddi.org/pubs/uddi-v3.0.2-20041019.htm. Berardi, D., Calvanese, D., De Giacomo, G., Lenzerini, M., and Mecella, M. 2003. Automatic composition of e-services that export their behavior. In In Proc. 1st Int. Conf. on Service Oriented Computing (ICSOC), volume 2910 of LNCS. Springer, 43–58. Bernardi, G., Bugliesi, M., Macedonio, D., and Rossi, S. 2008. A theory of adaptable contractbased service composition. In Proc. of Workshop on Global Computing Models and Technologies (GlobalComp’08). IEEE Computer Society Press. To appear. Bravetti, M. and Zavattaro, G. 2007. Towards a unifying theory for choreography conformance and contract compliance. In Proc. of the 6th Intl. Symposium on Software Composition. Springer. Brinksma, E., Scollo, G., and Steenbergen, C. 1995. Lotos specifications, their implementations and their tests. 468–479. Bruce, K. and Longo, G. 1990. A modest model of records, inheritance and bounded quantification. Information and Computation 87, 1/2, 196–240. Carbone, M., Honda, K., and Yoshida, N. 2007a. A calculus of global interaction based on session types. Electronic Notes in Theoretical Computer Science 171, 3, 127–151. Carbone, M., Honda, K., and Yoshida, N. 2007b. Structured communication-centred programming for web services. In ESOP ’07, 16th European Symposium on Programming. LNCS 4421. Springer. Cardelli, L. 1988. A semantics of multiple inheritance. Information and Computation 76, 138–164. Carpineti, S., Castagna, G., Laneve, C., and Padovani, L. 2006. A formal account of contracts for Web Services. In 3rd Int. Workshop on Web Services and Formal Methods. LNCS 4184. Springer. Castagna, G., Dezani-Ciancaglini, M., Giachino, E., and Padovani, L. 2008. General session types. Technical Report id.: hal-00334435, CNRS - PPS, University Paris 7. http://hal. archives-ouvertes.fr/hal-00334435. Castagna, G. and Frisch, A. 2005. A gentle introduction to semantic subtyping. In PPDP ’05 ACM Press (full version) and ICALP ’05, LNCS 3580, Springer (summary) (July). Joint ICALP-PPDP keynote talk. TO APPEAR IN ACM Transactions on Programming Languages and Systems 58 · Castagna, Gesbert, and Padovani Castagna, G., Gesbert, N., and Padovani, L. 2007. A theory of contracts for web services. In PLAN-X ’07, 5th ACM-SIGPLAN Workshop on Programming Language Technologies for XML. Castagna, G., Gesbert, N., and Padovani, L. 2008. A theory of contracts for web services. In POPL ’08, 35th ACM Symposium on Principles of Programming Languages. 261–272. Chen, G. 2004. Soundness of coercion in the calculus of constructions. Journal of Logic and Computation 14, 3, 405–427. Chinnici, R., Haas, H., Lewis, A.-A., Moreau, J.-J., Orchard, D., and Weerawarana, S. 2007. Web Services Description Language (wsdl) Version 2.0 Part 2: Adjuncts. W3C Recommendation, http://www.w3.org/TR/wsdl20-adjuncts/. Chinnici, R., Moreau, J.-J., Ryman, A., and Weerawarana, S. 2007. Web Services Description Language (wsdl) Version 2.0 Part 1: Core Language. W3C Recommendation, http://www. w3.org/TR/wsdl20/. Courcelle, B. 1983. Fundamental properties of infinite trees. Theoretical Computer Science 25, 95–169. De Giacomo, G. and Sardiña, S. 2007. Automatic synthesis of new behaviors from a library of available behaviors. In IJCAI. 1866–1871. De Nicola, R. and Hennessy, M. 1984. Testing equivalences for processes. Theoretical Computer Science 34, 83–133. De Nicola, R. and Hennessy, M. 1987. CCS without τ ’s. In TAPSOFT/CAAP’87. LNCS 249. Springer, 138–152. De Nicola, R. and Labella, A. 2003. Nondeterministic regular expressions as solutions of equational systems. Theor. Comput. Sci. 302, 1-3, 179–189. Derrick, J., Bowman, H., Boiten, E., and Steen, M. 1996. Comparing LOTOS and Z refinement relations. In FORTE/PSTV’96. Chapman & Hall, Kaiserslautern, Germany, 501–516. Di Cosmo, R. 1995. Isomorphisms of Types: from Lambda Calculus to Information Retrieval and Language Design. Birkhäuser. Fallside, D. C. and Walmsley, P. 2004. XML Schema Part 0: Primer Second Edition. W3C Recommendation, http://www.w3.org/TR/xmlschema-0/. Fournet, C. and Gonthier, G. 1996. The reflexive chemical abstract machine and the joincalculus. In Proceedings of the 23rd ACM Symposium on Principles of Programming Languages. ACM, St. Petersburg Beach, Florida, 372–385. Fournet, C., Gonthier, G., Lévy, J.-J., Maranget, L., and Rémy, D. 1996. A calculus of mobile agents. In CONCUR. Lecture Notes in Computer Science, vol. 1119. Springer, 406–421. Fournet, C., Hoare, C. A. R., Rajamani, S. K., and Rehof, J. 2004. Stuck-free conformance. In CAV’04. LNCS 3114. Springer. Frisch, A., Castagna, G., and Benzaken, V. 2008. Semantic subtyping: dealing set-theoretically with function, union, intersection, and negation types. Journal of the ACM 55, 4, 1–64. Gay, S. and Hole, M. 2005. Subtyping for session types in the π-calculus. Acta Informatica 42, 23, 191–225. Hennessy, M. 1985. Acceptance trees. Journal of the ACM 32, 4, 896–928. Hennessy, M. 1988. Algebraic Theory of Processes. Foundation of Computing. MIT Press. Honda, K. 1993. Types for dyadic interaction. In CONCUR ’93. LNCS 715. Springer, 509–523. Honda, K., Vasconcelos, V. T., and Kubo, M. 1998. Language primitives and type discipline for structured communication-based programming. In European Symposium on Programming. LNCS 1381. Springer. Hull, R., Benedikt, M., Christophides, V., and Su, J. 2003. E-services: a look behind the curtain. In PODS ’03: Proceedings of the twenty-second ACM SIGMOD-SIGACT-SIGART symposium on Principles of database systems. ACM, New York, NY, USA, 1–14. Laneve, C. and Padovani, L. 2006. Smooth orchestrators. In FoSSaCS (2006-04-05), L. Aceto and A. Ingólfsdóttir, Eds. LNCS, vol. 3921. Springer, 32–46. TO APPEAR IN ACM Transactions on Programming Languages and Systems A Theory of Contracts for Web Services · 59 Laneve, C. and Padovani, L. 2007. The must preorder revisited – An algebraic theory for web services contracts. In 18th International Conference on Concurrency Theory. LNCS 4703, Springer. Laneve, C. and Padovani, L. 2008. The pairing of contracts and session types. LNCS, vol. 5065. Springer, 681–700. Milner, R. 1982. A Calculus of Communicating Systems. Springer. OCaml. Objective Caml. http://caml.inria.fr/ocaml/. Padovani, L. 2008. Contract-directed synthesis of simple orchestrators. LNCS, vol. 5201. Springer, 131–146. Pistore, M., Traverso, P., Bertoli, P., and Marconi, A. 2005. Automated synthesis of composite bpel4ws web services. In ICWS ’05: Proceedings of the IEEE International Conference on Web Services. IEEE Computer Society, Washington, DC, USA, 293–301. Rittri, M. 1993. Retrieving library functions by unifying types modulo linear isomorphism. RAIRO Theoretical Informatics and Applications 27, 6, 523–540. Soloviev, S., Jones, A., and Luo, Z. 1996. Some Algorithmic and Proof-Theoretical Aspects of Coercive Subtyping. In TYPES’96. LNCS 1512, 173–196, Springer. Takeuchi, K., Honda, K., and Kubo, M. 1994. An interaction-based language and its typing system. In Parallel Architectures and Languages Europe. 398–413. Traverso, P. and Pistore, M. 2004. Automated composition of semantic web services into executable processes. In International Semantic Web Conference. 380–394. TO APPEAR IN ACM Transactions on Programming Languages and Systems