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