Mario Bravetti
email: mario.bravetti@unibo.it

Gianluigi Zavattaro
email: gianluigi.zavattaro@unibo.it

Choreographies and Behavioural Contracts on the Way to Dynamic Updates

We survey our work on choreographies and behavioural contracts in multiparty interactions. In particular theories of behavioural contracts are presented which enable reasoning about correct service composition (contract compliance) and service substitutability (contract refinement preorder) under different assumptions concerning service communication: synchronous address or name based communication with patient non-preemptable or impatient invocations, or asynchronous communication. Correspondingly relations between behavioural contracts and choreographic descriptions are considered, where a contract for each communicating party is, e.g., derived by projection. The considered relations are induced as the maximal preoders which preserve contract compliance and global traces: we show maximality to hold (permitting services to be discovered/substituted independently for each party) when contract refinement preorders with all the above asymmetric communication means are considered and, instead, not to hold if the standard symmetric CCS/pi-calculus communication is considered (or when directly relating choreographies to behavioral contracts via a preorder, no matter the communication mean). The obtained maximal preorders are then characterized in terms of a new form of testing, called compliance testing, where not only tests must succeed but also the system under test (thus relating to controllability theory), and compared with classical preorders such as may/must testing, trace inclusion, etc. Finally, recent work about adaptable choreographies and behavioural contracts is presented, where the theory above is extended to update mechanisms allowing choreographies/contracts to be modified at run-time by internal (self-adaptation) or external intervention.

Introduction

We survey our theoretical studies about coordination and design of service oriented systems based on the notion of behavioural contract, which describes the interactive behaviour of a service as, e.g., obtained via session/behavioural types [START_REF] Bravetti | Towards a Unifying Theory for Choreography Conformance and Contract Compliance[END_REF] or expressed in orchestration languages like WS-BPEL [START_REF]Web Services Business Process Execution Language Version 2[END_REF].

Two main approaches are commonly considered for the composition of services: service orchestration and service choreography. In an orchestration language, e.g. WS-BPEL [START_REF]Web Services Business Process Execution Language Version 2[END_REF], the activities of the composed services are expressed from the viewpoint of a specific component, called the orchestrator, that is responsible for invoking the composed services and collect their responses. Choreographies languages, e.g. WS-CDL [START_REF]Web Services Choreography Description Language[END_REF], instead, support a high level description of peer-to-peer interactions among several services playing different roles (multi-party interaction), from a top-level abstract viewpoint.

When implementing an interaction-oriented choreography by assembling already available services, several mechanisms and notions need to be introduced. Often the possibility is considered of extracting, from the global specification, the orchestrational behaviour of each of the communicating parties in the form of a behavioural contract or of an abstract workflow, as expressed e.g. in abstract WS-BPEL [START_REF]Web Services Business Process Execution Language Version 2[END_REF]. One of the first articles that relates Choreography to Orchestrational descriptions is [START_REF] Bravetti | Supporting e-commerce systems formalization with choreography languages[END_REF]. It introduces ideas concerning several technical aspects of such a relation using e-commerce as a case study. The extraction of choreographical behaviours is often called "projection of the choreography on the roles", see, e.g. [START_REF] Bravetti | Towards a Unifying Theory for Choreography Conformance and Contract Compliance[END_REF]. The idea is that, based on the contracts derived with such a projection, services are retrieved that expose a behaviour which is compatible with the extracted behaviours.

It is worth noticing that despite choreography projection is a powerful tool for relating global choreographic descriptions with local peer behaviours, it is not always guaranteed to be applicable. For instance, suppose a choreography requires an interaction to occur before another one. If the two interactions involve distinct roles (that do not have other synchronisations) they could occur in any order. For this reason, choreography projections are usually applied to the so-called connected choreographies, where such misbehaviours cannot be expressed.

Another difficulty encountered when choreography languages are used to describe the message exchange among services, is that it is not trivial to relate the high level choreography description with the actual implementation of the specified system realized as composition of services (orchestrations): they are usually loosely coupled, independently developed by different companies, and autonomous. More precisely, the difficult task is, given a choreography, to lookup available services that, once combined, are ensured to behave according to the given choreography.

To this aim a foundational study about coarsest refinement preorders between behavioural contracts made it possible to decide whether a service discovered on the internet can be used to play the role of a service with a given desired contract in the context of a multi-party coordination (independently of the service discovered for the other roles) [START_REF] Boreale | Advanced Mechanisms for Service Composition, Query and Discovery. Rigorous Software Engineering for Service-Oriented Systems[END_REF][START_REF] Bravetti | A Theory of Contracts for Strong Service Compliance[END_REF][START_REF] Bravetti | Contract-Based Discovery and Composition of Web Services, 9th International School on Formal Methods for the Design of Computer[END_REF][START_REF] Bravetti | A Foundational Theory of Contracts for Multi-party Service Composition[END_REF][START_REF] Bravetti | A Theory for Strong Service Compliance[END_REF][START_REF] Bravetti | Contract based Multi-party Service Composition[END_REF], or to play a certain role in a given choreography [START_REF] Bravetti | Service Discovery and Composition based on Contracts and Choreographic Descriptions, Adaptive Web Services for Modular and Reusable Software Development: Tactics and Solutions[END_REF][START_REF] Bravetti | Contract Compliance and Choreography Conformance in the Presence of Message Queues[END_REF][START_REF] Bravetti | Towards a Unifying Theory for Choreography Conformance and Contract Compliance[END_REF], without incurring in deadlocks (and furthermore guaranteeing termination under fairness assumption). More precisely, theories of behavioural contracts have been introduced which enable reasoning about correct service composition (contract compliance) and service substitutability (contract refinement preorder) under different assumptions concerning service communication: synchronous address [START_REF] Bravetti | Service Discovery and Composition based on Contracts and Choreographic Descriptions, Adaptive Web Services for Modular and Reusable Software Development: Tactics and Solutions[END_REF][START_REF] Boreale | Advanced Mechanisms for Service Composition, Query and Discovery. Rigorous Software Engineering for Service-Oriented Systems[END_REF][START_REF] Bravetti | Towards a Unifying Theory for Choreography Conformance and Contract Compliance[END_REF] or name based [START_REF] Bravetti | Contract-Based Discovery and Composition of Web Services, 9th International School on Formal Methods for the Design of Computer[END_REF][START_REF] Bravetti | A Foundational Theory of Contracts for Multi-party Service Composition[END_REF][START_REF] Bravetti | Contract based Multi-party Service Composition[END_REF] communication (invocations are directed to a certain role or just based on channel names as in CCS) with patient non-preemptable or impatient invocations (waiting admitted when invoking services, as in CCS communication, or not admitted, as for the ready-send primitive of the Message Passing Interface) [START_REF] Bravetti | A Theory of Contracts for Strong Service Compliance[END_REF][START_REF] Bravetti | A Theory for Strong Service Compliance[END_REF], or asynchronous communication with queues [START_REF] Bravetti | Service Discovery and Composition based on Contracts and Choreographic Descriptions, Adaptive Web Services for Modular and Reusable Software Development: Tactics and Solutions[END_REF][START_REF] Bravetti | Contract Compliance and Choreography Conformance in the Presence of Message Queues[END_REF].

Concerning contract compliance, we consider a service (contract) composition to be correct if any possible execution leads to successful termination under fairness assumption, i.e. for any finite behavioural path of the system there exists a finite path from the reached state that leads all services to successful termination. This means that there can be an infinite computation, but given any possible prefix of this infinite computation, it must be possible to extend it to reach a successfully terminated computation. This guarantees that the system is both deadlock and, under the fairness assumption (i.e. whenever a choice is traversed infinitely often every possible outcome is chosen infinitely often), livelock free.

The considered refinement relations are, then, induced as the maximal preoders which preserve contract compliance: we show maximality to hold (permitting services to be discovered/substituted independently for each party) when contract refinement preorders with all the above asymmetric communication means are considered and, instead, not to hold if the standard symmetric CCS/pi-calculus communication is considered (or when directly relating choreographies to behavioral contracts via a preorder, no matter the communication mean).

The obtained maximal preorders are then characterized in terms of a new form of testing, called compliance testing, where not only tests must succeed but also the system under test. The structure of this new form of testing directly relates contract refinement theory with controllability theory, in that an uncontrollable contract (i.e. a contract that cannot be led to success by any test) is equivalent to any other contract.

Moreover, in the synchronous case, the obtained preorders have been classified with respect to standard preoreders, turning out to be coarser than standard (fair) testing preorder [START_REF] Rensink | Fair testing[END_REF] and incomparable with respect to trace inclusion due to uncontrollable contracts [START_REF] Bravetti | A Foundational Theory of Contracts for Multi-party Service Composition[END_REF][START_REF] Bravetti | Contract based Multi-party Service Composition[END_REF]. In the synchronous case, we also provide sound characterizations of the maximal contract refinement preorder that are decidable, by resorting to an encoding into fair testing preorder [START_REF] Rensink | Fair testing[END_REF].

We also consider the problem of directly relating discovered behavioral contracts with choreographies: choreography conformance relation. In this case we show that a maximal relation does not exist and we present a notion of choreography conformance, called consonance base on combining choreography projection and the testing characterization.

Finally, we discuss a recent approach [START_REF] Bravetti | Towards Global and Local Types for Adaptation[END_REF] for extending the presented choreography and orchestration languages with mechanisms for dynamic updates. The idea is to support both internal self-adaptations and external modifications. The former mechanism is used to specify systems able to detect events that require to modify the usual behaviour; the latter allows for system's modifications that are statically unpredictable. In both cases choreographies are extended with a scope construct used to delimit those parts of the choreographies that can be modified at run-time; an additional update primitive injects new code inside scopes. Scope projections are used to control which parts of the peers should be modified when an update is executed at run-time.

The paper is structured as follows. In Section 2 we introduce our formalization of choreographies and orchestrations and we relate them via the notions of choreography implementation, projection and well-formedness. Moreover we present the notion of Connected Choreographies. In Section 3 we present contract-based service discovery and we report about the theory of behavioural contracts and refinement and its characterization in terms of testing. We also deal with the problem of directly relating discovered behavioral contracts with choreographies. Such a theory is presented for the case of synchronous address based communication (where invocations are directed to a certain role) with patient non-preemptable invocations [START_REF] Bravetti | Service Discovery and Composition based on Contracts and Choreographic Descriptions, Adaptive Web Services for Modular and Reusable Software Development: Tactics and Solutions[END_REF][START_REF] Boreale | Advanced Mechanisms for Service Composition, Query and Discovery. Rigorous Software Engineering for Service-Oriented Systems[END_REF]. The results for other forms of communications are just summarized here. In Section 4 recent work about adaptable choreographies and behavioural contracts is presented [START_REF] Bravetti | Towards Global and Local Types for Adaptation[END_REF], where the theory above is extended to update mechanisms allowing choreographies/contracts to be modified at runtime. Finally, Section 5 reports some conclusive remarks about comparison with related literature and future work.

Choreographies and Orchestrations

We start by presenting the choreography and orchestration calculi (representing individual service behaviour) and then we relate them by projection.

The Choreography Calculus

We assume a denumerable set of action names N , ranged over by a, b, c, . . . and a set of roles Roles ranged over by r, s, l.

Definition 2.1 (Choreographies)

The set of Choreographies, ranged over by H, L, • • • is defined by the following grammar:

H ::= a r→s | H + H | H; H | H|H | H *
The invocations a r→s means that role r invokes the operation a provided by the role s. The other operators are choice + , sequential ; , parallel | , and repetition * .

The operational semantics of choreographies considers two auxiliary terms 1 and 0. They are used to model the completion of a choreography, which is relevant in the operational modeling of sequential composition. The formal definition is given in Table 1 where we take η to range over the set of labels {a r→s | a ∈ N , r, s ∈ Roles} ∪ { √ } (the label √ denotes successful completion). The rules in Table 1 are rather standard for process calculi with sequential composition and without synchronization; in fact, parallel composition simply allows for the interleaving of the actions executed by the operands (apart from completion labels √ that are required to synchronize). Choreographies are especially useful to describe the protocols of interactions within a group of collaborating services. To clarify this point, we present a simple example of a protocol described with our choreography calculus. According to this choreography, the Buyer initially sends an item request to the Seller that subsequently, in parallel, replies with an offer and sends a payment description to the Bank. Then the Buyer performs the actual payment to the Bank. The latter in parallel replies with a receipt and sends a payment confirmation to the Seller.

a r→s a r→s -→ 1 1 √ -→ 0 H * √ -→ 0 H η -→ H ′ H +L η -→ H ′ H η -→ H ′ η = √ H;L η -→ H ′ ;L H √ -→ H ′ L η -→ L ′ H;L η -→ L ′ H √ -→ H ′ L √ -→ L ′ H|L √ -→ H ′ |L ′ H η -→ H ′ η = √ H|L η -→ H ′ |L H η -→ H ′ η = √ H * η -→ H ′ ; H *

The Orchestration Calculus

As for choreographies, we assume a denumerable set of action names N , ranged over by a, b, c, . . . . We use τ / ∈ N to denote an internal (unsynchronizable) computation.

Definition 2.3 (Orchestrations and Systems)

The syntax of orchestrations is defined by the following grammar

C ::= 0 | 1 | τ | a | a l | C;C | C+C | C|C | C *
The set of all orchestrations C is denoted by P orc . The syntax of systems (orchestration compositions) is defined by the following grammar

P ::= [C] l | P||P
A system P is well-formed if: (i) every orchestration subterm [C] l occurs in P at a different role l and (ii) no output action with destination l is syntactically included inside an orchestration subterm occurring in P at the same role l, i.e. actions a l cannot occur inside a subterm [C] l of P. The set of all wellformed systems P is denoted by P. In the following we will just consider well-formed systems and, for simplicity, we will call them just systems.

We take α to range over the set of syntactical actions

SAct = N ∪ {a l | a ∈ N ∧ l ∈ Roles} ∪ {τ}.
The operational semantics of contracts is defined by the rules in Table 2 (plus symmetric rules). The operational semantics of systems is defined by the rules in Table 3 plus symmetric rules. We take β to range over the set Act of actions executable by contracts and systems, i.e.

Act = SAct ∪ {a l | a ∈ N ∧ l ∈ Roles} ∪ {a r→s | a ∈ N ∧ r, s ∈ Roles} ∪ {a rs | a ∈ N ∧ r, s ∈ Roles}.
We take λ to range over the set of transition labels L = Act ∪ { √ }, where √ denotes successful termination. Here and in the remainder of the paper we use the following notations: P λ -→ to mean that there exists P ′ such that P λ -→ P ′ and, given a sequence of labels w = λ 1 λ 2 • • • λ n-1 λ n (possibly empty, i.e., w = ε), we use P w -→ P ′ to denote the sequence of transitions P

1 √ -→ 0 α α -→ 1 C λ -→ C ′ C+D λ -→ C ′ C λ -→ C ′ λ = √ C;D λ -→ C ′ ;D C √ -→ C ′ D λ -→ D ′ C;D λ -→ D ′ C √ -→ C ′ D √ -→ D ′ C|D √ -→ C ′ |D ′ C λ -→ C ′ λ = √ C|D λ -→ C ′ |D C * √ -→ 0 C λ -→ C ′ λ = √ C * λ -→ C ′ ;C *
C a -→ C ′ [C] r a r -→ [C ′ ] r C a s -→ C ′ [C] r a rs -→ [C ′ ] r P λ -→ P ′ λ = √ P||Q λ -→ P ′ ||Q P a s -→ P ′ Q a rs -→ Q ′ P||Q a r→s -→ P ′ ||Q ′ P √ -→ P ′ Q √ -→ Q ′ P||Q √ -→ P ′ ||Q ′
λ 1 -→ P 1 λ 2 -→ • • • λ n-1 -→ P n-1
λ n -→ P ′ (in case of w = ε we have P ′ = P, i.e., P ε -→ P). Moreover, for completely specified systems P (i.e. terms P not included as subterms in a larger term P ′ ), we do not consider transitions corresponding to unmatched input and output actions: namely, we consider only transitions labeled with τ (local internal actions), √

(global successful termination) and a r→s (completed interactions).

We now define the notion of correct composition of orchestrations. This notion is the same as in [START_REF] Bravetti | Contract based Multi-party Service Composition[END_REF]. Intuitively, a system composed of orchestrations is correct if all possible computations may guarantee completion; this means that the system is both deadlock and livelock free (there can be an infinite computation, but given any possible prefix of this infinite computation, it must be possible to extend it to reach a successfully completed computation).

Definition 2.4 (Correct orchestration composition)

System P ∈ P is a correct orchestration composition, denoted P ↓, if for every P ′ such that P w -→ P ′ there exists P ′′ such that P ′ w ′ -→ P ′′ √ -→ .

Choreography Implementation, Projection and Well-Formedness

We are now ready to formalize the notion of correct implementation of a choreography. With P τ * -→ P ′ we denote the existence of a (possibly empty) sequence of τ-labeled transitions starting from the system P and leading to P ′ . Given the sequence of labels

w = λ 1 • • • λ n , we write P w =⇒ P ′ if there exist P 1 , • • • , P m such that P τ * -→ P 1 λ 1 -→ P 2 τ * -→ • • • τ * -→ P m-1 λ n -→ P m τ * -→ P ′ .
Intuitively, a system implements a choreography if it is a correct composition of orchestrations and all of its conversations (i.e. the possible sequences of message exchanges), are admitted by the choreography.

Definition 2.5 (Choreography implementation)

Given the choreography H and the system P, we say that P implements H (written P ∝ H) if

• P is a correct orchestration composition and

• given a sequence w of labels of the kind a r→s , if

P w √ =⇒ P ′ then there exists H ′ such that H w √ -→ H ′ .
Note that it is not necessary for an implementation to include all possible conversations admitted by a choreography. We now present the notion of choreography projection, which yields an orchestration C for each role of a choreography H. The definition is very simple thanks to the idea, we introduced in [START_REF] Bravetti | Towards a Unifying Theory for Choreography Conformance and Contract Compliance[END_REF], of projecting communication atoms and then applying homomorphism over all the algebra operators.

Definition 2.7 (Choreography projection) Given a choreography H, the projection H on the role r, denoted with [[H]]

r , is defined inductively on the syntax of H in such a way that

[[a r→s ]] t =    a s if t = r a if t = s 1 otherwise
and that it is a homomorphism with respect to all operators.

It is interesting to observe that given a choreography H, the system obtained composing its projections is not ensured to be an implementation of H. For instance, consider the choreography a r→s ; b t→u . The system obtained by projection is

[a s ] r || [a] s || [b u ] t || [b] u .
Even if this is a correct composition of orchestrations, it is not an implementation of H because it comprises the conversation b t→u a r→s which is not admitted by H.

The problem is not in the definition of the projection, but in the fact that the above choreography cannot be implemented preserving the message exchanges specified by the choreography. In fact, in order to guarantee that the communication between t and u is executed after the communication between r and s, it is necessary to add a further message exchange (for instance between s and r) which is not considered in the choreography.

In order to have the guarantee that the system obtained by projection is consistent with the initial choreography, it is reasonable to consider a subset of well formed choreographies. The most general and intuitive notion of well formedness, we introduced in [START_REF] Bravetti | Towards a Unifying Theory for Choreography Conformance and Contract Compliance[END_REF], can be obtained by considering only all those choreographies for which the system obtained by projection is ensured to be a correct implementation.

Definition 2.8 (Well formed choreography) A choreography H, defined on the roles r

1 , • • • , r n , is well formed if [ [[H]] r 1 ] r 1 || • • • || [ [[H]] r n ] r n ∝ H
It is worthwhile to note that well formedness is decidable. In fact, given a choreography H, it is sufficient to take the corresponding system P obtained by projection, then consider P and H as finite state automata, and finally check whether the language of the first automaton is included in the language of the second one. Note that the terms P and H can be seen as finite state automata thanks to the fact that their infinite behaviours are defined using Kleene-star repetitions instead of general recursion. This decidability result clearly follows from the fact that we restrict to finite state choreographies. In the literature, more general syntactic versions of well formedness exist (see e.g. [START_REF] Carbone | Structured Communication-Centred Programming for Web Services[END_REF]). In the next section we report a syntactic characterisation of well formedness.

Connected Choreographies

In this section, following [START_REF] Lanese | Bridging the gap between Interaction-and Process-Oriented Choreographies[END_REF][START_REF] Bravetti | Contract-Driven Implementation of Choreographies[END_REF], we introduce a notion of connectedness for our choreography calculus. The idea is to impose syntactic restrictions in order to avoid the three possible ways in which a system obtained by projection can have a different behaviour w.r.t. its choreography.

The first of these ways is concerned with sequential composition: given the choreography H 1 ; H 2 , if in the projected system there is no synchronisation between the roles involved in H 1 and those in H 2 , an interaction in the latter could occur before an interaction in the former. This first problem can be avoided by imposing that for every initial interaction in H 2 there is at least one role involved in every possible final interaction of H 1 . To formalise this syntactic restriction we use two auxiliary functions transI(•) and transF (•) that computes respectively the set of pair of roles involved in initial and final interactions in a choreography:

transI(a r 1 →r 2 ) = transF (a r 1 →r 2 ) = {r 1 , r 2 } transI(1) = transI(0) = transF (1) = transF (0) = / 0 transI(H|H ′ ) = transI(H + H ′ ) = transI(H) ∪ transI(H ′ ) transF (H|H ′ ) = transF (H) ∪ transF(H ′ ) transF (H + H ′ ) = transF (H) ∪ transF(H ′ ) transI(H; H ′ ) = transI(H) ∪ transI(H ′ )if H √ -→, transI(H) otherwise transF (H; H ′ ) = transF (H) ∪ transF(H ′ )if H ′ √ -→, transF (H ′ ) otherwise transI(H * ) = transI(H) transF (H * ) = transF (H)
The following syntactic condition on choreographies guarantees that the above problem does not occur. Definition 2.9 (Connectedness for sequence) A choreography is connected for sequences if for each subterm of the form H; H ′ we have that ∀R ∈ transF (H),

∀R ′ ∈ transI(H ′ ) then R ∩ R ′ = / 0.
The second way a projected system can differ from its choreography is concerned with the choice operator: in a choreography H + H ′ it is necessary that all the involved roles are aware of the selected branch. This can be ensured by imposing that at least one of the roles involved in initial interactions in one of the two branches is involved in every initial interaction in the other one. Moreover, it is also necessary to impose that the two choreographies consider the same set of roles: this guarantees that precisely the same set of roles are involved in the two branches thus, even if not initiator, they are eventually informed of the selected branch.

Definition 2.10 (Unique point of choice)

A choreography has unique points of choice if for each subterm of the form H + H ′ we have that ∀R ∈ transI(H), ∀R ′ ∈ transI(H ′ ) then R ∩ R ′ = / 0 and moreover roles(H) = roles(H ′ ).

Finally, the last way projections can differ from choreographies is concerned with parallel composition. In the projection of a choreography H|H ′ , it could happen that a message sent within an interaction in one choreography is intercepted by a receive action in an interaction of the other one. We can avoid this by imposing that the interactions in H uses names different from those used in H ′ .

Definition 2.11 (No operation interference)

A choreography has no operation interferences if for every pair of interactions a r 1 →r 2 and a ′ r ′ 1 →r ′ 2 occurring in parallel in the same scope, we have a = a ′ .

The first two conditions have been borrowed from [START_REF] Lanese | Bridging the gap between Interaction-and Process-Oriented Choreographies[END_REF], while the last one is a simpler and stronger condition w.r.t. the (more complex but less restrictive) causality safety condition considered in that paper. One of the main results in [START_REF] Lanese | Bridging the gap between Interaction-and Process-Oriented Choreographies[END_REF] is that when choreographies respect the three connectedness conditions, then they are bisimilar to their projections. We can then conclude what follows.

Theorem 2.12 Let H be a choreography satisfying the conditions in the Definitions 2.9, 2.10, and 2.11. Then H is well formed.

Contract-based Service Discovery

We now define the notion of behavioural contract which will allow us to reason about service compliance and retrieval independently of the language used for implementing service behaviour.

Contracts are defined as labeled transition systems, where transition labels are the typical internal τ action and the input/output actions a, a l , where the outputs (as for the orchestration calculus) are directed to a destination address denoted by a role r ∈ Roles. We first define the class of labeled transition systems of interest for defining contracts. Definition 3.1 (Finite Connected LTS with Termination Transitions) A finite connected labeled transition system (LTS) with termination transitions is a tuple ⊔ = (S, L , -→, s h , s 0 ) where S is a finite set of states, L is a set of labels, the transition relation -→ is a finite subset of (S -{s h })× (L ∪ { √ })× S such that (s, √ , s ′ ) ∈-→ implies s ′ = s h , s h ∈ S represents a halt state, s 0 ∈ S represents the initial state, and it holds that every state in S is reachable (according to -→) from s 0 .

As in orchestrations, in a finite connected LTS with termination transitions we use √ transitions (leading to the halt state s h ) to represent successful termination. On the contrary, if we get (via a transition different from √ ) into a state with no outgoing transitions (like, e.g., s h ) then we represent an internal failure or a deadlock.

Definition 3.2 (Behavioural Contract)

A behavioural contract is a finite connected LTS with termination transitions, that is a tuple (S, L , -→, s h , s 0 ), where L = {a, a l , τ | a ∈ N ∧ l ∈ Roles}, i.e. labels are either a receive (input) on some operation a ∈ N or an invoke (output) directed to some operation a ∈ N at some role l or internal τ actions.

Orchestrations C ∈ P orc give rise to a behavioral contract as the labeled transition system obtained by their semantics (where the initial state s 0 is C, the halt state s h is 0 and the other states in S are terms C ′ reachable by C). We can, therefore, use C ∈ P orc as a way to denote such a behavioral contract.

In the following we will present the theory of behavioral contracts by abstracting from the particular process algebra used to denote them: contracts represent orchestration behavior in a language independent way. We will therefore take terms C belonging to a generic set P con being any set of terms (generated by the syntax of a process algebra) that give rise to all possible behavioral contracts as their semantics (in the form of finite connected LTSes as in Definition 3.2). For instance P con can be basic CCS (with recursion) over L prefixes and extended with successful termination 1, see [START_REF] Bravetti | Service Discovery and Composition based on Contracts and Choreographic Descriptions, Adaptive Web Services for Modular and Reusable Software Development: Tactics and Solutions[END_REF][START_REF] Boreale | Advanced Mechanisms for Service Composition, Query and Discovery. Rigorous Software Engineering for Service-Oriented Systems[END_REF].

Contract Compositions and Contract Compliance

Similarly as for orchestrations, we consider contract compositions P as parallel compositions of contracts C, where the syntax and semantics of P is defined as for the syntax (Definition 2.3) and semantics (Table 3) of systems, where we now take C belonging to the arbitrary set P con , instead of C ∈ P orc . With a little abuse of notation in this section we will use P to denote the set of such contract compositions P (the same notation used for set of systems in the previous section).

When reasoning about contract compositions P, it will be fundamental to consider (as we did for the particular orchestration language of the previous section) correct contract compositions, denoted by P ↓. The notion of correct contract composition (also called contract compliance) P is defined exactly as for correct orchestration composition, see Definition 2.4 (the only difference now being that P is composed of terms C belonging to the arbitrary set P con , instead of C ∈ P orc ).

Independent Subcontracts

We are now ready to define the notion of independent subcontract pre-order. Given a contract C ∈ P con , we use oroles(C) to denote the subset of Roles of the roles of the destinations of all the output actions occurring inside C. Definition 3.3 (Independent Subcontract pre-order) A pre-order ≤ over P con is an independent subcontract pre-order if, for any n ≥ 1, contracts C 1 , . . . ,C n ∈ P con and C ′ 1 , . . . ,C ′ n ∈ P con such that ∀i.C ′ i ≤ C i , and distinguished role names l 1 , . . . , l n ∈ Roles such that ∀i.

l i / ∈ oroles(C i ) ∪ oroles(C ′ i ), we have ([C 1 ] l 1 || . . . || [C n ] l n ) ↓ ⇒ ([C ′ 1 ] l 1 || . . . || [C ′ n ] l n ) ↓
It is easy to see that, if we do not introduce any asymmetry in the behaviour of invokes and receives, there is no maximal independent subcontract pre-order, i.e. there is no optimal solution to the problem of locally retrieving services based on their contracts.

This can be easily seen by considering, e.g., the trivially correct system No pre-order ≤ could have both a + c; 0 ≤ a and a l + c l ; 0 ≤ a l because if we refine C 1 with a + c; 0 and C 2 with a l + c l ; 0 we achieve the incorrect system a + c.0||a l + c l ; 0 that can deadlock after synchronization on channel c. We now show that, by assuming a more practical form of communication, where invokes and receives have an asymmetric behaviour, there exists a maximal independent subcontract pre-order. This con be achieved in several ways: (i) constraining the structure of behavioural contracts by considering only output persistent ones (a contract chooses internally to perform an output/invoke: it must execute it to reach successful termination) as in WS-BPEL [START_REF]Web Services Business Process Execution Language Version 2[END_REF] or in session types [START_REF] Carbone | Structured Communication-Centred Programming for Web Services[END_REF]; (ii) strengthening the notion of compliance (yielding so-called strong compliance [START_REF] Bravetti | A Theory of Contracts for Strong Service Compliance[END_REF][START_REF] Bravetti | A Theory for Strong Service Compliance[END_REF]): when an output is performed a corresponding input is required to be already enabled, like in ready-send of Message Passing Interface (iii) moving to asynchronous communication, e.g. via message queues [START_REF] Bravetti | Service Discovery and Composition based on Contracts and Choreographic Descriptions, Adaptive Web Services for Modular and Reusable Software Development: Tactics and Solutions[END_REF][START_REF] Bravetti | Contract Compliance and Choreography Conformance in the Presence of Message Queues[END_REF].

[C 1 ] l ||[C 2 ] l ′ with C 1 =
In the following we will detail the first of the above approaches. In Section 3.7 we will survay other approaches.

Output Persistence

The main results reported in this paper are consequences of a property of systems that we call output persistence.

Definition 3.4 (Output persistence)

Let C ∈ P con be a behavioural contract. It is output persistent if given C w -→ C ′ with C ′ a l -→ then: C ′ √ -→ / and if C ′ α -→ C ′′ with α = a then also C ′′ a l -→.
The output persistence property states that once a contract decides to execute an output, its actual execution is mandatory in order to successfully complete the execution of the contract. This property typically hold in languages for the description of service behaviours or for service orchestrations (WS-BPEL [START_REF]Web Services Business Process Execution Language Version 2[END_REF] or session types [START_REF] Carbone | Structured Communication-Centred Programming for Web Services[END_REF]) in which output actions cannot be used as guards in external choices (see e.g. the pick operator of WS-BPEL which is an external choice guarded on input actions). In these languages, a process instance always decides internally to execute an output action (output action cannot be involved in an external choice). In fact, if we consider potential outputs that can disappear without being actually executed (as in an external choice among outputs a + b or in a mixed choice a + b in which, e.g., the possible b is no longer executable after the output or input on a) we have that there exists no maximal subcontract pre-order family, as we have shown with the above counterexample.

Notice that, if we instead assume output persistence of contracts, as we do in this paper, subcontracts cannot add reachable outputs on new types. For instance an output persistent contract a + τ.c l adding a new output on c l with respect to a, similarly to the pre-order ≤ 2 in the counterexample above, would not be a correct subcontract because when composed in parallel with the other initial contract a l would lead to a deadlock.

In the context of process algebra with parallel composition as that of P orc , a syntactical characterization that guarantees output persistence has been introduced in [START_REF] Bravetti | Contract based Multi-party Service Composition[END_REF]. The idea is to require that every output prefix (i.e. the term a l ) is preceded by an internal τ prefix, i.e. the syntax of Definition 2.3 includes τ; a l instead of a l . Choreography projection must be also modified in order to produce, for each role, an output persistent contract that can be then used for discovering services via refinement (see following Section 3.6). In particular, we have to modify the rule concerning generation of output in orchestrations as follows:

[[a r→s ]] t = τ; a s if t = r
In the following we will take P opcon to be any set of terms (generated by the syntax of a process algebra) that give rise to all possible output persistent behavioral contracts as their semantics (in the form of finite connected LTSes as in Definition 3.2). Moreover we will consider systems P to be compositions of contracts in P opcon .

Compliance Testing is the Maximal Preorder

We will show that the maximal independent subcontract pre-order can be achieved defining a more coarse form of refinement in which, given any system composed of a set of contracts, refinement is applied to one contract only (thus leaving the others unchanged). This form of refinement, that we call compliance testing, is a form of testing where both the test and the system under test must reach success.

Given a system P ∈ P, we use roles(P) to denote the subset of Roles of the roles of contracts syntactically occurring inside P: e.g. roles(

[C] l 1 ||[C ′ ] l 2 ) = {l 1 , l 2 }.

Definition 3.5 (Subcontract Relation)

A contract C ′ ∈ P opcon is a subcontract of a contract C ∈ P opcon denoted C ′ C, if and only if for all l ∈ Roles such that l / ∈ oroles(C i ) ∪ oroles(C ′ i ) and P ∈ P such that l / ∈ roles(P) we have

([C] l ||P) ↓ implies ([C ′ ] l ||P) ↓ Theorem 3.6
There exists a maximal independent subcontract pre-order and it corresponds to the (compliance testing based) subcontract relation " ". Formally, for any pre-order ≤ over P opcon that is an independent subcontract pre-order, we have that ≤ is included in .

Properties of the Maximal Preorder and I/O Knowledge

We now discuss some properties of the maximal independent subcontract pre-order (compliance testing), comparing it with other approaches and other classical preorders. We also show a sound characterization that is decidable.

In the following we will use I(C) to stand for the subset of N of the input actions a syntactically occurring in C and "C\\M", with M ⊆ N , to stand for "C{0/a|a ∈ M}". Proposition 3.7 Let C,C ′ ∈ P opcon be contracts. We have

C ′ \\(I(C ′ ) -I(C)) C ⇔ C ′ C
The proposition above is a direct consequence of the fact that, due to output persistence of contracts, compliant tests P of a contract [C] l cannot perform reachable outputs directed to l that C cannot receive. For instance [a] l ||[τ; a l + τ; b l ] l ′ is not a correct contract composition.

From the proposition above we can derive two fundamental properties of the maximal independent subcontract pre-order:

• External choices on inputs can be extended, for instance: a + b a by directly applying the above proposition.

• Internal choices on outputs can be reduced, for instance: τ; a l τ; a l + τ; b l because the lefthand term is more deterministic (typical property in testing).

These two properties are assumed when considering subtyping in the theory of session types [START_REF] Carbone | Structured Communication-Centred Programming for Web Services[END_REF], in our setting they were instead obtained as a consequence of considering the maximal independent subcontract preorder over output persistent contracts.

Notice that, when considering behavioural contracts that communicate just with standard CCS channel name based communication [START_REF] Bravetti | Contract-Based Discovery and Composition of Web Services, 9th International School on Formal Methods for the Design of Computer[END_REF][START_REF] Bravetti | A Foundational Theory of Contracts for Multi-party Service Composition[END_REF][START_REF] Bravetti | Contract based Multi-party Service Composition[END_REF], i.e. where outputs are just written as a instead of being directed to a certain role l as in a l , the proposition above does not hold. This is due to "capturing" behaviour. For instance it does not hold that a + b a, as can be seen by considering the correct contract composition where the leftmost contract can "capture" the b that was received by the middle contract in the correct composition. This problem can be faced by resorting to knowledge about the input and output actions syntactically occurring in the initial contracts (e.g. those obtained by projection from a choreography) when defining the notion of independent subcontract preorder ≤, see [START_REF] Bravetti | Contract-Based Discovery and Composition of Web Services, 9th International School on Formal Methods for the Design of Computer[END_REF][START_REF] Bravetti | A Foundational Theory of Contracts for Multi-party Service Composition[END_REF][START_REF] Bravetti | Contract based Multi-party Service Composition[END_REF]. In this way C ′ I,O C denotes that C ′ is a subcontract of C assuming that the other contracts (the test) can only perform input on I and output on O. Therefore, exploiting knowledge we can recover the above proposition and we have:

a + b N ,N -{b} a

Resorting to Fair Testing

This section is devoted to the definition of an actual procedure for determining that two contracts are in subcontract relation. This is achieved resorting to the theory of fair testing, called should-testing [START_REF] Rensink | Fair testing[END_REF]. As a side effect we will also show that subcontract relation is coarser than fair testing preorder.

In the following we denote with test the should-testing pre-order defined in [START_REF] Rensink | Fair testing[END_REF] where we consider the set of actions used by terms as being L ∪ {a | a ∈ N } (i.e. we consider located and unlocated input and output actions and √ is included in the set of actions of terms under testing as any other action). We denote here with √ ′ the special action for the success of the test (denoted by √ in [START_REF] Rensink | Fair testing[END_REF]). In the following we consider λ to range over L ∪ {a | a ∈ N }.

In order to resort to the theory defined in [START_REF] Rensink | Fair testing[END_REF], we define a normal form for contracts of our calculus that corresponds to terms of the language in [START_REF] Rensink | Fair testing[END_REF]. The normal form of the contract C (denoted with N F (C)) is defined as follows, by using the operator rec X θ (defined in [START_REF] Rensink | Fair testing[END_REF]) that represents the value of X in the solution of the minimum fixpoint of the finite set of equations θ ,

N F (C) = rec X 1 θ
where θ is the set of equations

X i = ∑ j λ i, j ; X der(i, j)
where, assuming to enumerate the states in the labeled transition system of P starting from X 1 , each variable X i corresponds to the i-th state of the labeled transition system of P, λ i, j is the label of the j-th outgoing transition from X i , and der(i, j) is the index of the state reached with the j-th outgoing transition from X i . We assume empty sums to be equal to 0, i.e. if there are no outgoing transitions from X i , we have X i = 0. Theorem 3.8 Let C,C ′ ∈ P opcon be two contracts. We have

N F (C ′ \\I(C ′ )-I(C)) test N F (C) ⇒ C ′ C The opposite implication C ′ C ⇒ N F (C ′ \\I(C ′ )-I(C)) test N F (C) does not hold in general.
This can be easly seen by considering uncontrollable contracts, i.e. contracts for which there is no compliant test. For instance the contract 0, any other contract a; b; 0 or c; d; 0 or more complex examples like a.1 + a.b.1. These contracts are all equivalent according to our subcontract relation, but of course not according to fair testing.

Comparison with Traditional Testing and Trace Preorders

Notice that Theorem 3.8 says that the subcontract relation is coarser than fair testing preorder (where tests are assumed to be capable of observing √ actions of the system under test). The equivalent uncontrollable contracts that we have shown in the previous section show that this inclusion is strict: this is due to the fact that, besides requiring the success of the test, we impose also that the tested process should successfully complete its execution.

Another significant difference of compliance testing respect to traditional one proposed by De Nicola-Hennessy [START_REF] Nicola | Testing Equivalences for Processes[END_REF] is in the treatment of divergence: we do not follow the traditional catastrophic approach, but the fair approach as in the theory of should-testing of Rensink-Vogler [START_REF] Rensink | Fair testing[END_REF]. In fact, we do not impose that all computations must succeed, but that all computations can always be extended in order to reach success.

Concerning trace preorder, it is not coarser than subcontract relation (compliance testing) due to the possible presence in the system under test of traces not leading to success: these traces are not observable by (compliant) tests. For instance the equivalent uncontrollable contracts that we have shown in the previous section have completely different traces. In this respect compliance testing differs from standard testing theories which imply trace inclusion.

Contract-based Choreography Conformance

We are now in place for the definition of relations C ⊳ r H indicating whether the contract C can play the role r in the choreography H. Definition 3.9 (Conformance relation) Given a well-formed choreography H with roles r 1 , • • • , r n , a relation among contracts, roles r of H and H, denoted with C ⊳ r H, is a conformance relation if, for every r i , with 1 ≤ i ≤ n, there exists at least a contract C i such that C i ⊳ r i H, and it holds that: if

C 1 ⊳ r 1 H, • • • ,C n ⊳ r n H then [C 1 ] r 1 || • • • ||[C n ] r n ∝ H.
It is interesting to observe that, differently from subcontract relation defined on contracts in the previous Section 3.4, there exists no maximal conformance relation. For instance, consider the choreography H = a r→s |b r→s . We could have two different conformance relations ⊳ 1 and ⊳ 2 , the first one such that

(τ; a s |τ; b s ) ⊳ 1 r H (τ; a; b + τ; b; a) ⊳ 1 s H
and the second one such that

(τ; a s ; τ; b s + τ; b s ; τ; a s ) ⊳ 2 r H (a|b) ⊳ 2 s H
It is easy to see that it is not possible to have a conformance family that comprises the union of the two relations ⊳ 1 and ⊳ 2 . In fact, the system

[τ; a s ; τ; b s + τ; b s ; τ; a s ] r || [τ; a; b + τ; b; a] s
is not a correct composition because the two contracts may internally select two incompatible orderings for the execution of the two message exchanges (and in this case they stuck).

In the remainder of this section we define a mechanism that, exploiting the notion of subcontract relation defined in the previous section and, in particular, its sound characterization based on fair testing, permits to effectively characterize an interesting conformance relation.

We now present the notion of testing consonance (see [START_REF] Bravetti | Service Discovery and Composition based on Contracts and Choreographic Descriptions, Adaptive Web Services for Modular and Reusable Software Development: Tactics and Solutions[END_REF]) between contracts and roles of a given choreography, and we prove that it is a conformance family.

Definition 3.10 (Testing Consonance)

We say that the contract C is testing consonant with the role r of the well formed choreography H (written

C ⊗ r test H) if N F C\\I(C) -I([[H]] r ) test N F [[H]] r
Theorem 3.11 Given a well-formed choreography H, we have that the testing consonance relation C ⊗ r test H is a conformance relation.

Summary of Results

We now summarize the results that we have obtained about contract refinement and choreography conformance for different forms of communication.

The first mean of classification of possible scenarios is based on the amount of knowledge about the (initial) behavioural description of the other roles the conformance relation may depend on. We considered: knowledge about the whole choreography (full knowledge about the behaviour of other roles) or knowledge restricted to input types (receive operations) and/or output types (invoke operations) that the other roles may use. The second mean of classification of possible scenarios is based on the kind of service compliance assumed (i.e. of the principle assumed for assessing when multiple services work well together and form a correct system). We considered: (i) "normal" compliance, as reported in this paper, where service interaction via invoke and receive primitives is based on synchronous handshake communication and both receive and invoke primitives may wait indefinitely (with no exception occurring) for a communication to happen, see [START_REF] Bravetti | Contract-Based Discovery and Composition of Web Services, 9th International School on Formal Methods for the Design of Computer[END_REF][START_REF] Bravetti | A Foundational Theory of Contracts for Multi-party Service Composition[END_REF][START_REF] Bravetti | Contract based Multi-party Service Composition[END_REF] and [START_REF] Bravetti | Service Discovery and Composition based on Contracts and Choreographic Descriptions, Adaptive Web Services for Modular and Reusable Software Development: Tactics and Solutions[END_REF][START_REF] Boreale | Advanced Mechanisms for Service Composition, Query and Discovery. Rigorous Software Engineering for Service-Oriented Systems[END_REF][START_REF] Bravetti | Towards a Unifying Theory for Choreography Conformance and Contract Compliance[END_REF] where, in addition to the standard CCS synchronization, locations expressing a unique address for every system contract are introduced and outputs are directed to a location (as in the thoery presented in this paper); (ii) "strong compliance", where we additionally require that, whenever a service may perform an invoke on some operation, the invoked service must be already in the receive state for that operation as for the ready-send primitive of the Message Passing Interface [START_REF] Bravetti | A Theory of Contracts for Strong Service Compliance[END_REF][START_REF] Bravetti | A Theory for Strong Service Compliance[END_REF]; (iii) "queue-based compliance", where service interaction via invoke and receive primitives is based on asynchronous communication: the receiving service puts invoke requests in an unbounded queue [START_REF] Bravetti | Service Discovery and Composition based on Contracts and Choreographic Descriptions, Adaptive Web Services for Modular and Reusable Software Development: Tactics and Solutions[END_REF][START_REF] Bravetti | Contract Compliance and Choreography Conformance in the Presence of Message Queues[END_REF].

Concerning service compliance we considered in all cases the fair termination property presented in this paper. Our results are summarized in the following.

• Knowledge about the whole choreography (direct conformance relation with respect to a choreography for a certain role): the maximal independent conformance relation does not exist, no matter which kind of service compliance (among those mentioned above) is considered.

• Knowledge about other initial contracts limited to input/output types they use (conformance by means of refinement of a single contract parameterized on the I/O knowledge about the others, as in this paper):

-In the case of "normal compliance" we have that: for unconstrained contracts the maximal independent conformance relation does not exist; for contracts such that the output persistence property holds the maximal independent conformance relation exists and knowledge about input types is not significant; for output persistent contracts where locations expressing a unique address for every system contract are introduced and outputs are directed to a location, as for the theory in this paper, the maximal relation exists and knowledge about both input and output types is not significant.

-In the case of "strong compliance" we have that: for unconstrained contracts (where outputs are directed to a location identifying a unique system contract) the maximal relation exists and knowledge about both input and output types is not significant.

-In the case of "queue-based compliance" we have that: for unconstrained contracts (where outputs are directed to a location identifying a unique system contract) the maximal relation exists and knowledge about both input and output types is not significant.

For every maximal refinement relation above (apart from the queue-based one), we provide a sound characterization that is decidable, by resorting to an encoding into should-testing [START_REF] Rensink | Fair testing[END_REF]. As a consequence we obtain:

• An algorithm (based on that in [START_REF] Rensink | Fair testing[END_REF]) to check refinement.

• A classification of the maximal refinement relations with respect to existing pre-orders as, e.g., (half) bisimulation, (fair/must) testing, trace inclusion.

In particular we show that the maximal refinement relations are coarser with respect to bisimulation and must testing preorders (up to some adequate encoding and treatment of fairness) in that, e.g., they allow external non-determinism on inputs to be added in refinements.

Towards Choreographies and Orchestrations with Dynamic Updates

In this section we discuss, following the approach discussed in [START_REF] Bravetti | Towards Global and Local Types for Adaptation[END_REF], a possible approach for extending the Choreography Calculus with dynamic updates. Dynamic updates can be specified by defining scopes that delimit parts of choreographies that, at runtime, may be replaced by a new choreography, coming from either inside or outside the system. Updates coming from outside may be decided by the user through some adaptation interface, by some manager module, or by the environment. In contrast, updates coming from inside represent self-adaptations, decided by a part of the system towards itself or towards another part of the system, usually as a result of some interaction producing unexpected values. Updates from outside and from inside are indeed quite similar, e.g., an update decided by a manager module may be from inside if the manager behavior is part of the choreography term, from outside if it is not. Formally speaking, the Choreography Calculus is extended with scopes and updates as follows:

H ::= ... | X : T [H] (scope) | X {r : H} (update)
where X is used to range over a set of scope names and T is a set of roles. Construct X : T [H] defines a scope named X currently executing choreography H -the name is needed to designate it as a target for a particular adaptation. Type T is the set of roles (possibly) occurring in the scope. This is needed since a given update can be applied to a scope only if it specifies how all the involved roles are adapted. Operator X {r : H} defines internal updates, i.e., updates offered by a participant of the choreography. Here r denotes the role offering the update, X is the name of the target scope, and H is the new choreography.

The operational semantics for the new Choreography Calculus with updates is defined in [START_REF] Bravetti | Towards Global and Local Types for Adaptation[END_REF] only for a proper subset of well defined choreographies. 1 For instance, conditions are added in order to guarantee that every update X {r : H} injects a choreography H that considers only roles explicitly indicated in the type T of the updated part X : T [H ′ ]. Moreover, also syntactic restrictions are imposed in order to guarantee that it will never occur that two distinct scopes with the same name are contemporaneously active. This is necessary for the following reason: when a scope is projected, it is distributed among several independent roles running in parallel, and in order to avoid interferences between two distinct scopes with the same name X we assume that only one scope X can be active at a time.

The operational semantics is defined by adding the rules dealing with scopes and updates reported in Table 4. The transition labels η now include the label X {r : H} indicating the execution of an update action. In the rules, we use H[H ′ /X ] to denote the substitution that replaces all scopes X : T [H ′′ ] with name X occurring in H (not inside update prefixes) with X : T [H ′ ].

We briefly comment the rules in Table 4. Rule (COMMUPD) makes an internal update available, moving the information to the label. Updates propagate through sequence, parallel composition, and Kleene star using rules (SEQUPD), (PARUPD), and (STARUPD), respectively. Note that, while propagating, the update is applied to the continuation of the sequential composition, to parallel terms, and to the body of Kleene star. Notably, the update is applied to both enabled and non enabled occurrences of the desired scope. Rule (SCOPEUPD) allows a scope to update itself (provided that the names coincide), while propagating the update to the rest of the choreography. Rule (SCOPE) allows a scope to compute. As in the previous sections, systems are of the form [C] r , where r is the name of the role and C its behaviour. Systems, denoted P, are obtained by composition of parallel endpoints:

P ::= [C] r (endpoint) | P||P (parallel system)
In this presentation, we do not formally define a semantics for endpoints: we just point out that it should include labels corresponding to all the labels of the semantics of choreographies, plus some additional labels corresponding to partial activities, such as an input. We also highlight the fact that all scopes which correspond to the same choreography scope evolve together: their scope start transitions (transforming a scope from inactive to active) are synchronized, as well as their scope end transitions (removing it). The fact that choreographies feature at most one scope with a given name is instrumental in ensuring this property.

We now discuss how to extend the notion of projection presented in Definition 2.7 for the case without updates. Definition 4.2 (Projection for choreographies with updates) The projection of a choreography H on a role r, denoted by [[H]] r , is defined as in Definition 2.7 plus the clauses below for scopes and updates: where the projections of the new protocol are precisely injected in the behaviour of the affected roles. Ideally, traces of the projected system should correspond to the traces of the original choreography. Actually, we conjecture that this occurs for choreographies satisfying connectedness conditions obtained by extending those already discussed in Section 2.4. For instance it is necessary to consider also the new scope and update operators; this can be done by adding to the auxiliary functions transI and transF rules to deal with the novel constructs X : T [C] and X {r : C} (in the first case both functions should return the roles in T , in the second case the unique role involved is r).

[[X {r ′ : H}]] r = X {(r 1 , . . . , r n ) : [[H]] r 1 , . . . , [[H]] r n }with {r 1 , . . . , r n } = type(X ) if r = r ′ 1 otherwise [[X : T [H]]] r = X [[[H]] r ] if r ∈ type(X ) 1
We finally point out two main aspects of the expected correspondence result between choreographies and their projections in the case of the calculi extended with dynamic updates. First, labels X {r : H} of transitions of the choreography should be mapped to labels of the transitions of the Orchestration Calculus obtained by appropriate label projections. Second, endpoint traces should not consider unmatched input and output labels.

Related Work and Conclusion

Among our main contributions we can mention (i) the formalisation of the relationship between global choreographic descriptions and systems obtained as parallel compositions of peers, (ii) the definition of suitable notions of contract refinement, and (iii) the proposal of mechanisms for dynamic updates for both the choreography and the orchestration calculi. Concerning (i), we have defined well-formedness for choreographies based on natural projection and the notion of implementation. We have introduced the simple technique of obtaining orchestrations by projection, defining it for communication actions and then exploiting omomorphism over all the process algebraic operators. Moreover our approach leads to a more general notion of well-formedness w.r.t. other approaches like, e.g., [START_REF] Carbone | Structured Communication-Centred Programming for Web Services[END_REF], where it is defined in terms of three connectedness constraints similar to those we have defined in Section 2.4. Concerning (ii), our main contribution is related to the idea of refining all peers guaranteeing that all of them continue to reach local success. This differs from other popular approaches, like those initiated by Fournet et al. [START_REF] Fournet | Stuck-Free Conformance[END_REF] or Padovani et al. [START_REF] Carpineti | A Formal Account of Contracts for Web Services[END_REF], where the focus is on the success of one specific peer (usually, the so-called, client). Concerning (iii), it is worth to mention that [START_REF] Preda | AIOCJ: A Choreographic Framework for Safe Adaptive Distributed Applications[END_REF] has been a source of inspiration for the present work: the main difference is our choice of expressing adaptation in terms of scopes and code update constructs, rather than using rules. This approach appears more adequate for the definition of a general theory of behavioural typing to be used on more general languages where multiple protocols/choreographies can interleave inside the same program. Now some remarks concerning future work. We are working on applying the theory of updatable choreographies/orchestrations in the context of session types for typing a concrete language with session spawning, where choreographies play the role of global types attached to sessions and we use orchestrations for checking, via typing rules, that the code actually conforms with the specified global types. In this context, extending our contract refinement theory to updatable choreographies/orchestrations (thus getting updatable behavioural contracts) would make it possible to define a notion of semantic subtyping. We also plan to work on the complete characterization of compliance testing: work in this direction has been done in [START_REF] Bernardi | Mutually Testing Processes -(Extended Abstract)[END_REF] where however testing is characterized only for controllable processes (i.e. processes for which there exists a compliant test) and fairness is not considered (a testing notion similar to our compliance testing is considered, where both the test and the system under test must succeed, but in the flavour of traditional testing of [START_REF] Nicola | Testing Equivalences for Processes[END_REF] without assuming fairness).

Example 2 . 2 (

 22 Buyer/Seller/Bank) Let us consider the following choreography composed of three roles: Buyer, Seller and Bank Request Buyer→Seller ; ( O f f er Seller→Buyer | PayDescr Seller→Bank ); Payment Buyer→Bank ; ( Con f irm Bank→Seller | Receipt Bank→Buyer )

Example 2 . 6 (

 26 Implementation of Buyer/Seller/Bank) As an example, we present a possible implementation of the choreography reported in the Example 2.2. [Request Seller ; O f f er; Payment Bank ; Receipt] Buyer || [Request; (O f f er Buyer | PayDescr Bank );Con f irm] Seller || [PayDescr; Payment; (Receipt Buyer |Con f irm Seller )] Bank

a and C 2 =

 2 a l . Consider the two independent subcontract pre-orders ≤ 1 and ≤ 2 such that the unique pairs they possess besides the identity on all contracts C are a + c; 0 ≤ 1 a and a l + c l ; 0 ≤ 2 a l

  [a]||[τ; a; b]||[τ; b] and the incorrect one [a + b]||[τ; a; b]||[τ; b]

Example 4 . 1 (

 41 Adaptable Buyer/Seller/Bank) Here, we consider a version of the Buyer/Seller/Bank example discussed in the Example 2.2 where it is possible to update the payment interaction between

Table 1 :

 1 Semantic rules for contracts (symmetric rules omitted).

Table 2 :

 2 Semantic rules for orchestrations (symmetric rules omitted).

Table 3 :

 3 Semantic rules for orchestration compositions (symmetric rules omitted).

  BankIt is interesting to note that the projection clearly identifies where a possible update of the payment should have an effect; namely, only the roles Buyer and Bank are affected by the update in precise parts of their behaviour. For instance, if X {(Buyer, Bank) : V ISAcode Bank ;V ISAok , V ISAcode;V ISAok Buyer } is executed after the first Request interaction occurs, then the system becomes:

otherwise Example 4.3 We now present the projection of the choreography in the Example 4.1 (we omit unnecessary 1 terms): [Request Seller ; O f f er; X [Payment Bank ]; Receipt] Buyer || [Request; (O f f er Buyer | PayDescr Bank );Con f irm] Seller || [PayDescr; X [Payment]; (Receipt Buyer |Con f irm Seller )] [O f f er; X [V ISAcode Bank ;V ISAok]; Receipt] Buyer || [(O f f er Buyer | PayDescr Bank );Con f irm] Seller || [PayDescr; X [V ISAcode;V ISAok Buyer ]; (Receipt Buyer |Con f irm Seller )] Bank

We refer the reader to[START_REF] Bravetti | Towards Global and Local Types for Adaptation[END_REF] for a formal definition of this subset of well defined choreographies, here we simply informally report the imposed limitations.

(COMMUPD)

X {r : H} X{r: H} ----→ 1

η = X {r : H} for any r, H According to the operational semantics defined above, this choreography could, for instance, perform the initial Request interaction and then receives an external update:

X {r : V ISAcode Buyer→Bank ;V ISAok Bank→Buyer } and then becomes the following choreography:

We are now ready to present the definition of our Orchestration Calculus extended with operators for dynamic updates:

where F is either A, denoting an active (running) scope, or ε, denoting a scope still to be started (ε is omitted in the following). X [C] F denotes an endpoint scope named X executing C. F is a flag distinguishing scopes whose execution has already begun (A) from scopes which have not started yet (ε). In order to become active, the endpoints involved in a scope, must synchronize. Also when all participants in a scope completes their respective executions, a synchronisation is needed in order to synchronously remove the scope. The update operator X {(r 1 , . . . , r n ) : C 1 , . . . ,C n } provides an update for scope named X , involving roles r 1 , . . . , r n . The new behaviour for role r i is P i .