Available via license: CC BY-NC-ND
Content may be subject to copyright.
Jos´e Proenc¸a and Massimo Tivoli (Eds.):
14th International Workshop on Foundations of
Coordination Languages and Self-Adaptive Systems (FOCLASA15)
EPTCS 201, 2015, pp. 1–17, doi:10.4204/EPTCS.201.1
c
M. Bravetti
This work is licensed under the
Creative Commons Attribution License.
Towards Dynamic Updates in Service Composition
Mario Bravetti
University of Bologna, Italy / INRIA, France
mario.bravetti@unibo.it
We survey our results about verification of adaptable processes. We present adaptable processes as
a way of overcoming the limitations that process calculi have for describing patterns of dynamic
process evolution. Such patterns rely on direct ways of controlling the behavior and location of
running processes, and so they are at the heart of the adaptation capabilities present in many modern
concurrent systems. Adaptable processes have named scopes and are sensible to actions of dynamic
update at runtime; this allows to express dynamic and static topologies of adaptable processes as well
as different evolvability patterns for concurrent processes. We introduce a core calculus of adaptable
processes and consider verification problems for them: first based on specific properties related to
error occurrence, that we call bounded and eventual adaptation, and then by considering a simple
yet expressive temporal logic over adaptable processes. We provide (un)decidability results of such
verification problems over adaptable processes considering the spectrum of topologies/evolvability
patterns introduced. We then consider distributed adaptability, where a process can update part of
a protocol by performing dynamic distributed updates over a set of protocol participants. Dynamic
updates in this context are presented as an extension of our work on choreographies and behavioural
contracts in multiparty interactions. We show how update mechanisms considered for adaptable
processes can be used to extend the theory of choreography and orchestration/contracts, allowing
them to be modified at run-time by internal (self-adaptation) or external intervention.
1 Introduction
We survey our work about verification of adaptable processes [2, 3, 1] presenting theories that we pre-
viously introduced in different contexts and connecting them for the first time. We start from adaptation
mechanisms where updates take place on individual processes only and weclassify them according to up-
date patterns and adaptable process topologies. Within such classification we present separation results
based un(decidability) of verification of adaptation properties/sets of temporal logic formulae. Then,
we consider a more complex setting where we exploit our foundational study of adaptable processes
to devise update mechanisms that involve several participants of a distributed protocol, expressed, for
example, by a choreography.
In order to introduce adaptation mechanisms and present a spectrum of topologies/evolvability pat-
terns we consider simple extensions to process calculi. Process calculi aim at describing formally the
behavior of concurrent systems. A leading motivation in the development of process calculi has been
properly capturing the dynamic character of concurrent behavior. In fact, much of the success of the
π
-calculus [21] can be fairly attributed to the way it departs from CCS [20] so as to describe mobile
systems in which communication topologies can change dynamically. Subsequent developments can be
explained similarly. For instance, the Ambient calculus [18] builds on
π
-calculus mobility to describe the
dynamics of interaction within boundaries and hierarchies, as required in distributed systems. A com-
monality in these calculi is that the dynamic behavior of a system is realized through a number of local
changes, usually formalized by reduction steps. Indeed, while in the
π
-calculus mobility is enforced by
the reconfiguration of individual linkages in the communication topology, in the Ambient calculus spatial
2
Towards Dynamic Updates in Service Composition
mobility is obtained by individual modifications to the containment relations within the ambient hierar-
chy. This way, the combined effect of a series of changes at a local level (links, containment relations)
suffices to explain dynamic behavior at the global (system) level.
There are, however, interesting forms of dynamic behavior that cannot be satisfactorily described as
a combination of local changes, in the above sense. These are behavioral patterns which concern change
at the process level (i.e., the process as a whole), and describe process evolution along time. In general,
forms of process evolvability are characterized by an enhanced control/awareness over the current be-
havior and location of running processes. Crucially, this increased control is central to the adaptation
capabilities by which processes modify their behavior in response to exceptional circumstances in their
environment.
This survey reports about the attempt we did to address these shortcomings. In particular, here we
present the contents of [2, 3, 1] at a level of detail that allows us to connect them and to discuss the
consequences of relating their machinery (this will also lead to new ideas for future work). In partic-
ular, we present, in Section 2, a core calculus of adaptable processes expressing a variety of topolo-
gies/evolvability patterns and (un)decidability results of verification problems for them (the technical
machinery is taken from [2, 3]). We will then, in Section 3, introduce distributed adaptability of proto-
cols as an extension, with update mechanisms similar to those considered for adaptable processes, of the
theory of choreography and orchestration/contracts (the technical machinery is taken from [1]). Finally,
in Section 4 we discuss some related work and in Section 5 we provide concluding remarks.
2 A Core Calculus of Adaptable Processes: the E Calculus
We start by presenting adaptable processes and results about verification problems for them. The tech-
nical machinery presented in this section is taken from [2, 3] (to which the reader is referred for details).
We introduced in [2] the concept of adaptable processes that have a location and are sensible to
actions of dynamic update at runtime. While locations are useful to designate and structure processes into
hierarchies, dynamic update actions implement a sort of built-in adaptation mechanism. We illustrate this
novel concept by introducing E , a core process calculus of adaptable processes. The E calculus arises as
a variant of CCS without restriction and relabeling, and extended with primitive notions of location and
dynamic update. In E , a[P] denotes the adaptable process P located at a. Name a acts as a transparent
locality: P can evolve on its own but also interact freely with its environment. Localities can be nested,
and are sensible to interactions with update prefixes. An update prefix ea{U} decrees the update of the
adaptable process at a with the behavior defined by U, a context with zero or more holes, denoted by
•. The evolution of a[P] is realized by its interaction with the update prefix ea{U}, which leads to the
process obtained by replacing every hole • in U by P, denoted UhhPii.
We consider several variants of E , obtained via two orthogonal characterizations. The first one is
structural, and distinguishes between static and dynamic topologies of adaptable processes. The former
is enforced by constraining the latter so that the topology of adaptable processes a[P] not to vary along
the evolution of the system: they cannot be destroyed nor new ones can appear. The second charac-
terization is behavioral, and concerns update patterns—the context U in an update prefix ea{U}. As
hinted at above, update patterns determine the behavior of running processes after an update action. In
order to account for different evolvability patterns, we consider three kinds of update patterns, which
determine three families of E calculi—denoted by the superscripts 1, 2, and 3, respectively. In our view,
these variants capture a fairly ample spectrum of scenarios that arise in the joint analysis of correct-
ness and adaptation concerns in evolvable systems. They borrow inspiration from existing programming
M. Bravetti
3
languages, development frameworks, and component models.
We now present the E calculus, its different variants, and its operational semantics. We refer to [2]
for further details and discussions. The E calculus is a variant of CCS [20] without restriction and re-
labeling, and extended with constructs for evolvability. As in CCS, in E , processes can perform actions
or synchronize on them. We presuppose a countable set N of names, ranged over by a,b,. .., possibly
decorated as
a,b and ea,
e
b. As customary, we use a and a to denote atomic input and output actions, re-
spectively. The syntax of E processes extends that of CCS with primitive notions of adaptable processes
a[P] and update prefixes ea{U}.
Definition 2.1 The classes of E processes, prefixes, and update patterns are described by the following
grammars:
P ::= a[P] | P k P | !
π
.P |
∑
i∈I
π
i
.P
π
::= a | a | ea{U}
U ::= a[U] | U kU | !
π
.U |
∑
i∈I
π
i
.U | •
Intuitively, update patterns above represent a context, i.e., a process with zero or more holes. The in-
tention is that when an update prefix ea{U} is able to interact, the current state of an adaptable process
named a is used to fill the holes in the update pattern U. Given a process P, process a[P] denotes the
adaptable process P located at a. Notice that a acts as a transparent locality: process P can evolve on
its own, and interact freely with external processes. Localities can be nested, so as to form suitable hi-
erarchies of adaptable processes. The rest of the syntax follows standard lines. A process
π
.P performs
prefix
π
and then behaves as P. Parallel composition P k Q decrees the concurrent execution of P and
Q. We abbreviate P
1
k ··· k P
n
as
∏
n
i=1
P
i
, and use
∏
k
P to denote the parallel composition of k instances
of process P. Given an index set I = {1,..,n}, the guarded sum
∑
i∈I
π
i
.P
i
represents an exclusive choice
over
π
1
.P
1
,.. .,
π
n
.P
n
. As usual, we write
π
1
.P
1
+
π
2
.P
2
if |I|= 2, and 0 if I is empty. Process !
π
.P defines
guarded replication, i.e., unboundedly many occurrences of P in parallel, which are triggered by prefix
π
.
Given an update pattern U and a process Q, we write UhhQii for the process obtained by filling in
with Q those holes in U not occurring inside update prefixes (a formal definition can be found in [2]).
Hence, {·} can be seen as a scope delimiter for holes • in ea{U}.
We now move on to consider three concrete instances of update patterns U.
Definition 2.2 We shall consider the following three instances of update patterns for E :
1. Full E (E
1
). The first update pattern admits all kinds of contexts for update prefixes. This variant,
corresponding to the above E is denoted also with E
1
.
2. Unguarded E (E
2
). In the second update pattern, holes cannot occur in the scope of prefixes in
U:
U ::= P | a[U] | U kU | •
The variant of E that adopts this update pattern is denoted E
2
.
3. Preserving E (E
3
). In the third update pattern, the current state of the adaptable process is always
preserved (i.e. “•” must occur exactly once in U). Hence, it is only possible to add new adaptable
processes and/or behaviors in parallel or to relocate it:
U ::= a[U] | U k P | •
The variant of E that adopts this update pattern is denoted E
3
.
4
Towards Dynamic Updates in Service Composition
(SUM)
∑
i∈I
π
i
.P
i
π
j
−−→ P
j
( j ∈ I)
(REPL)
!
π
.P
π
−→ P k!
π
.P
(COMP)
a[P]
a[P]
−−−→⋆
(LOC)
P
α
−−→ P
′
a[P]
α
−−→ a[P
′
]
(ACT1)
P
1
α
−−→ P
′
1
P
1
k P
2
α
−−→ P
′
1
k P
2
(TAU1)
P
1
a
−→ P
′
1
P
2
a
−→ P
′
2
P
1
k P
2
τ
−→ P
′
1
k P
′
2
(TAU3)
P
1
a[Q]
−−−→ P
′
1
P
2
ea{U}
−−−−→P
′
2
P
1
k P
2
τ
−→ P
′
1
{
UhhQii
/⋆} kP
′
2
Figure 1: LTS for E . Rules (ACT2), (TAU2), and (TAU4)—the symmetric counterparts of (ACT1),
(TAU1), and (TAU3)—have been omitted.
The process semantics is given in terms of a Labeled Transition System (LTS). It is generated by
the set of rules in Figure 1. In addition to the standard CCS actions (input, output,
τ
), we consider two
complementary actions for process update: ea{U} and a[P]. The former represents the possibility to enact
an update pattern U for the adaptable process at a; the latter says that an adaptable process at a, with
current state P, can be updated. We define −→ as
τ
−→, and write P
α
−→ if P
α
−→ P
′
, for some P
′
.
Definition 2.3 The LTS for E , denoted
α
−−→, is defined by the rules in Figure 1, with transition labels
defined as:
α
::= a | a | a[P] | ea{U} |
τ
In Figure 1, rules (SUM), (REPL), (ACT1), and (TAU1) are standard. Rule (COMP) represents the
contribution of a process at a in an update operation; we use ⋆ to denote a unique placeholder. Rule
(LOC) formalizes transparency of localities. Rule (TAU3) formalizes process evolvability. To realize the
evolution of an adaptable process at a, it requires: (i) a process Q—which represents its current state; (ii)
an update action offering an update pattern U for updating the process at a—which is represented in P
′
1
by ⋆ (cf. rule (COMP)) As a result, ⋆ in P
′
1
is replaced with process UhhQii. Notice that this means that
the locality being updated is discarded unless it is re-created by UhhQii.
We introduce some definitions that will be useful in the following. We denote with →
∗
the reflexive
and transitive closure of the relation →. We define Pred(s) as the set {s
′
∈ S | s
′
→ s} of immediate
predecessors of s, while Pred
∗
(s) denotes the set {s ∈ S | s
′
→
∗
s} of predecessors of s. We will also
assume point-wise extensions of such definitions to sets, i.e. Pred(S) =
S
s∈S
Pred(s) and similarly for
Pred
∗
(S).
2.1 The static E Calculus
Static variants of E are defined in [2]. Informally speaking, the static characterization of E processes is
related to tree-like structures obtained by nesting of located processes. In dynamic adaptable processes,
the class here considered, update actions which modify the nesting structure are allowed; in contrast,
in static adaptable processes such actions are disallowed: this guarantees that no adaptable process is
created nor destroyed along computation. By adding such a static topology constraint we get three static
variants E
1
s
, E
2
s
and E
3
s
for the three kind of update patterns considered in the E
1
, E
2
and E
3
languages.
From now on we will denote the latter with E
1
d
, E
2
d
and E
3
d
to distinguish them from their static variants.
M. Bravetti
5
E
d
– Dynamic Topology E
s
– Static Topology
E
1
BA undec / EA undec BA undec / EA undec
E
2
BA dec / EA undec BA dec / EA undec
E
3
BA dec / EA undec BA dec / EA dec
Table 1: Summary of (un)decidability results for dialects of E .
2.2 Eventual and Bounded Adaptation
In [2], we study two verification problems associated to E processes and their (un)decidability. They
are defined in terms of standard observability predicates (barbs), which indicate the presence of a des-
ignated error signal. We thus distinguish between correct states (i.e., states in which no error barbs are
observable) and error states (i.e., states exhibiting error barbs). The first verification problem, bounded
adaptation (abbreviated BA) ensures that, given a finite k, at most k consecutive error states can arise in
computations of the system—including those reachable as a result of dynamic updates. In other words,
the number of consecutive erroneous states that can be traversed during a computation is bound by some
given number k. The second one, eventual adaptation (abbreviated EA), is similar but weaker: it ensures
that if the system enters into an error state then it will eventually reach a correct state (the system cannot
enter a sequence of consecutive erroneous states that lasts forever). We believe that BA and EA fit well
in the kind of correctness analysis that is required in a number of emerging applications. For instance,
on the provider side of a cloud computing application, these properties allow to check whether a client is
able to assemble faulty systems via the aggregation of the provided services and the possible subsequent
updates. On the client side, it is possible to carry out forms of traceability analysis, so as to prove that if
the system exhibits an incorrect behavior, then it follows from a bug in the provider’s infrastructure and
not from the initial aggregation and dynamic updates provided by the client.
The main technical results of the paper are summarized in Table 1. The calculus E
1
is shown to
be Turing complete, and both BA and EA are shown to be undecidable for E
1
processes. The Turing
completeness of E
1
says much on the expressive power of update actions. In fact, it is known that
fragments of CCS without restriction can be translated into finite Petri nets, so they are not Turing
complete. Update actions in E thus allow to “jump” from finite Petri nets to a Turing complete model. We
show that in E
2
BA is decidable, while EA remains undecidable. Interestingly, EA is already undecidable
in E
3
d
, while it is decidable in E
3
s
.
2.3 A Logic for Adaptable Processes
We also considered, in [3], a simple yet expressive temporal logic L over adaptable processes. Con-
cerning model-checking with formulas of the entire logic L we have the same decidability results as for
the eventual adaptation property, while for a fragment of the logic, denoted with L
r
, we have the same
decidability results as for the bounded adaptation property (see Table 1).
Definition 2.4 The set At of atomic predicates p is given by the following syntax:
p ::= a
a
T.
Predicates a and
a hold true for states/terms that may perform transitions a and a, respectively. The
intention is that the interpretation of atomic predicates should coincide with the notion of barb in the
process model. T is the true predicate that holds true for every state/term. In the following, we use
α
to
range over labels a,
a, for some name a.
6
Towards Dynamic Updates in Service Composition
Definition 2.5 The set L of logic formulae
φ
,
ψ
,.. . is given by the following syntax, where p ∈At:
φ
::= p
φ
∨
φ
φ
∧
φ
¬
φ
♦
φ
♦
∗
φ
The set of logical operators includes atomic predicates p ∈ At, the usual boolean connectives (∨, ∧,
and ¬), as well as dynamic connectives (the next and eventuality modalities, ♦ and ♦
∗
). The interpreta-
tion of L over LTSs is given below, where each formula is mapped into the set of states/terms satisfying
it.
[[
α
]] =
s ∈E |s
α
−−→
[[T]] = E [[♦
φ
]] = Pred([[
φ
]]) [[♦
∗
φ
]] = Pred
∗
([[
φ
]])
[[
φ
1
∨
φ
2
]] = [[
φ
1
]] ∪[[
φ
2
]] [[
φ
1
∧
φ
2
]] = [[
φ
1
]] ∩[[
φ
2
]] [[¬
φ
]] = E \[[
φ
]]
Connectives are interpreted as usual. We usually write s |=
φ
if s ∈[[
φ
]].
Definition 2.6 A formula
φ
is called monotone if it does not contain occurrences of ¬.
Restricted monotone formulae are those monotone formulae in which conjunctions are always of the
form p∧
φ
, for some p ∈ At and a monotone formula
φ
∈ L .
Definition 2.7 A formula
φ
is restricted monotone if it is monotone and, for any occurrence of
φ
1
∧
φ
2
inside
φ
, there exists i ∈ {1,2} such that
φ
i
is a predicate p ∈ At.
Restricted logic L
r
is the logic composed by, possibly negated, restricted monotone formulae.
Definition 2.8 The restricted logic is composed by the set L
r
of formulae of the form
φ
or ¬
φ
, where
φ
is a restricted monotone formula.
We now give some examples of formulas in L and L
r
. We take ♦
+
φ
def
= ♦♦
∗
φ
. Possibly the most
natural safety property one would like to ensure is the absence of k consecutive barbs (representing, e.g.,
errors, as for the bounded adaptation property):
CB
k
(e)
def
= ¬♦
∗
e∧♦(e∧♦(e∧... ∧♦e))
|
{z }
e appears k times
Observe how CB
k
(e) ∈ L
r
. Another example of a sensible property to ensure is monotone correctness:
once solved, errors do not reappear. In L this can be expressed as:
MC(e)
def
= ¬♦
∗
e∧♦
+
(¬e∧♦
+
e)
Assuming a designated barb ok, signaling a correct (error-less) state, the above can be captured in L
r
as
follows:
MC
r
(ok,e)
def
= ¬♦
∗
e∧♦
+
(ok∧♦
∗
e)
The extension of MC
r
(ok,e) to consider k different error phases (it cannot happen that an error re-appears
up to k times) is straightforward:
MC
r
k
(ok,e)
def
= ¬♦
∗
e∧♦
+
(ok∧♦
∗
(e∧♦
+
(ok∧... (ok∧♦
∗
e))))
|
{z }
ok appears k times
The latter is used in [3] to model-check a case study about effective scaling in cloud computing, modeled
with a E
2
d
process (thus model-checking is decidable).
In [3] we also conjecture that decidability results for L
r
can be extended to monotone formulae
(dropping the restricted monotone constraint) and we discuss extensions of the logic with a recursion
operator. In particular, we claim that for L
r
with recursion, that would allow us to express properties like
eventual adaptation, we have the same (un)decidability results as for formulae of L (without recursion).
M. Bravetti
7
3 Choreographies and Orchestrations with Dynamic Updates
We now discuss a possible approach for expressing distributed dynamic updates of protocol specifica-
tions. The technical machinery presented in this section is taken from [7, 1] (to which the reader is
referred for details).
Dynamic updates in this context are presented as an extension of our work on choreographies and
behavioural contracts in multiparty interactions [5, 7, 9]. We consider distributed adaptability, where
a process can update part of a protocol by performing dynamic distributed updates over a set of pro-
tocol participants (denoted by roles in the choreographical description of the protocol). In particular,
we show how update mechanisms considered for adaptable processes can be used to extend the the-
ory of choreography and orchestration/contracts, allowing them to be modified at run-time by internal
(self-adaptation) or external intervention. This entails both an extension of choreography and orches-
tration/contract languages with primitives for distributed updates and named adaptable parts similar to
operators ea{U} and a[P] considered in the previous section. Moreover also related theories must be
extended, such as choreography well-formedness (by, e.g., connectedness constraints) and derivation of
participant orchestrations from a choreography by projection.
We start by presenting the choreography and orchestration calculi (representing individual participant
behaviour) and then we relate them by projection. Finally, we will extend the the theory presented with
distributed dynamic update mechanisms starting from the operators introduced in the previous section.
3.1 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 3.1 (Choreographies) The set ofChoreographies, 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 2 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 2
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 col-
laborating services. To clarify this point, we present a simple example of a protocol described with our
choreography calculus.
Example 3.2 (Buyer/Seller/Bank) Let us consider the following choreography composed of three
roles: Buyer, Seller and Bank
Request
Buyer→Seller
;( Offer
Seller→Buyer
|PayDescr
Seller→Bank
);
Payment
Buyer→Bank
;( Confirm
Bank→Seller
|Receipt
Bank→Buyer
)
8
Towards Dynamic Updates in Service Composition
a
r→s
a
r→s
−→1 1
√
−→ 0 H
∗
√
−→ 0
H
η
−→ H
′
H+L
η
−→ H
′
H
η
−→ H
′
η
6=
√
H;L
η
−→ H
′
;L
H
√
−→ H
′
L
η
−→ L
′
H;L
η
−→ L
′
H
√
−→ H
′
L
√
−→ L
′
H|L
√
−→ H
′
|L
′
H
η
−→ H
′
η
6=
√
H|L
η
−→ H
′
|L
H
η
−→ H
′
η
6=
√
H
∗
η
−→ H
′
;H
∗
Table 2: Semantic rules for choreographies (symmetric rules omitted).
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 per-
forms the actual payment to the Bank. The latter in parallel replies with a receipt and sends a payment
confirmation to the Seller.
3.2 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 3.3 (Orchestrations and Systems) The syntax of orchestrations is defined by the following
grammar
C ::= 0 | 1 |
τ
| a | a
r
|
C;C | C+C | C|C | C
∗
The set of all orchestrations C is denoted by P
orc
. Differently from choreographies, orchestration syntax
makes it possible to specify orchestrations that fail 0 or successfully terminate 1. The reason of such
a difference is that, conceptually, choreographies represent the desired overall system behaviour, while
orchestrations can be used to reason about concrete (possibly failing) participant implementations.
The syntax of systems (parallel composition of orchestrations) is defined by the following grammar
P ::= [C]
r
| P||P
A system P is well-formed if: (i) every orchestration subterm [C]
r
occurs in P at a different role r and (ii)
no output action with destination r is syntactically included inside an orchestration subterm occurring
in P at the same role r, i.e. actions
a
r
cannot occur inside a subterm [C]
r
of P. The set of all well-
formed 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
r
| a ∈ N ∧r ∈ Roles}∪{
τ
}.
The operational semantics of orchestrations is defined by the rules in Table 3 (plus symmetric rules).
The operational semantics of systems is defined by the rules in Table 4 plus symmetric rules. We take
β
to range over the set Act of actions executable by orchestrations 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 Act ∪{
√
}, where
√
denotes successful termination.
M. Bravetti
9
1
√
−→ 0
α
α
−→ 1
C
λ
−→C
′
C+D
λ
−→C
′
C
λ
−→C
′
λ
6=
√
C;D
λ
−→C
′
;D
C
√
−→C
′
D
λ
−→ D
′
C;D
λ
−→ D
′
C
√
−→C
′
D
√
−→ D
′
C|D
√
−→C
′
|D
′
C
λ
−→C
′
λ
6=
√
C|D
λ
−→C
′
|D
C
∗
√
−→ 0
C
λ
−→C
′
λ
6=
√
C
∗
λ
−→C
′
;C
∗
Table 3: Semantic rules for orchestrations (symmetric rules omitted).
C
a
−→C
′
[C]
r
a
r
−→ [C
′
]
r
C
a
s
−→C
′
[C]
r
a
rs
−→ [C
′
]
r
P
λ
−→ P
′
λ
6=
√
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
′
Table 4: Semantic rules for systems (symmetric rules omitted).
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
−→ 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 [5].
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 com-
putation, but given any possible prefix of this infinite computation, it must be possible to extend it to
reach a successfully completed computation).
Definition 3.4 (Correct orchestration composition) System P ∈P is a correct orchestration compo-
sition, denoted P↓, if for every P
′
such that P
w
−→ P
′
there exists P
′′
such that P
′
w
′
−→ P
′′
√
−→ .
10
Towards Dynamic Updates in Service Composition
3.3 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 choreog-
raphy.
Definition 3.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.
Example 3.6 (Implementation of Buyer/Seller/Bank) As an example, we present a possible imple-
mentation of the choreography reported in the Example 3.2.
[
Request
Seller
;Offer;Payment
Bank
;Receipt]
Buyer
||
[Request;(Offer
Buyer
|PayDescr
Bank
);Confirm]
Seller
||
[PayDescr;Payment;(
Receipt
Buyer
|Confirm
Seller
)]
Bank
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 [7], of projecting
communication atoms and then applying homomorphism over all the algebra operators.
Definition 3.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 projec-
tions 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.
M. Bravetti
11
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 [7], can be obtained by considering only all those
choreographies for which the system obtained by projection is ensured to be a correct implementation.
Definition 3.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, syntactic versions of well formedness exist (see e.g. [14, 19, 4]). A sound charc-
terization of well-formedness is obtained, following [19, 4], by introducing 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 chore-
ography: connectedness for sequence, related to the H;H
′
operator and guaranteeing that an interaction
of H
′
cannot occur before an interaction of H; unique point of choice, related to the H + H
′
operator and
guaranteeing that all the roles involved in H and H
′
are aware of the selected branch; and no operation
interference, related to the H|H
′
operator and guaranteeing that a message sent within an interaction of
one of H or H
′
cannot be intercepted by a receive action in an interaction of the other one (see [19, 4] for
details).
Theorem 3.9 Let H be a choreography satisfying the connectedness for sequence, unique point of
choice and no operation interference conditions. Then H is well formed.
3.4 Behavioural Contracts and Contract Refinement
Behavioural contracts make it possible to reason about protocol participant correct composition indepen-
dently of the language (syntax and semantics) used for expressing the orchestration of a participant. A
behavioural contract is defined, basically, as a Labeled Transition System with the same set of labels we
considered for the semantics of an orchestration (see, e.g., [10] for a precise definition). An orchestration,
therefore, gives rise to a behavioral contract as the labeled transition system obtained by its semantics.
Behavioural contracts are important in the context of service oriented computing for dealing with the
problem of service retrieval. Assuming that services expose in their interface an abstract description of
their behaviour (a behavioural contract) it is desirable to define an automatic procedure that can be used to
check whether a service may correctly play a given role of a choreography. It is therefore crucial to define
an, as coarse as possible, notion of contract refinement that makes it possible to establish if a discovered
service can play a given role, based on the behavioural contract of the service and the behavioural contract
derived, by projection, from the choreography. We, thus, define contract refinement as the coarsest
preorder over behavioural contracts which preserves correct composition when applied to members of
a set of behavioural contracts (one for each role of a choreography). See [5, 6, 7, 8, 9, 10, 11, 12] for
formal definitions considering several form of communications/notions of correct composition.
12
Towards Dynamic Updates in Service Composition
3.5 Introducing Distributed Dynamic Updates
Dynamic updates are specified, similarly as in Section 2, by defining scopes X[H] (where X is a scope
name) 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 unsatisfactory interaction. 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.
Scopes X[H] are updated by means of
e
X{H
′
} operators similarly as described in Section 2. However,
for the sake of simplicity, here we just consider updates
e
X{H
′
} where H
′
does not have holes •, i.e. in
Section 2 this corresponds to the case in which an update pattern U is just a term P (without any •).
Moreover, we assume
e
X{H
′
} to just update the content of scope X[H], thus leading to X[H
′
]. Therefore,
in terms of the machinery in Section 2, this corresponds to having scopes a[Q], for some Q, to be updated
by ea{U} where U is a[P] for some P, thus a[Q] is replaced by a[P]hhQii = a[P]. According to the
classification introduced in Section 2, updates of this kind fall in the category of Unguarded update
patterns (those of E
2
d
language) but not in that of Preserving update patterns (those of E
3
d
language). This
because in the latter category update patterns are required to have one hole •. Moreover, the language
topology is not static in that, when a named scope X[H] is updated by means of
e
X{H
′
}, H
′
can have a
different set of named scopes with respect to H and, moreover, due to usage of the “;” operator, named
scopes can be created and destroyed at run-time.
Differently from process calculi considered in Section 2 (E family), here scope updates are not
applied by channel based communication (that would not make sense in the context of a choreography,
where communication is just a basic action a
r→s
), but by replacement. Thus
e
X{H
′
} updates all scopes
X[H] (with the same name X) occurring anywhere in the choreography. This also justifies the change of
notation from a[P]/ea{U} to X[H]/
e
X{H
′
}: in the former a represents a channel on which to communicate,
in the latter X represents a syntactic variable to replace. Moreover, notice that, now when a scope X[H]
is updated, we are actually performing a distributed update that encompasses all the roles involved in H:
at the orchestration level, as we will see, we have an X scope for each of such roles and an update on X
must update all of them in a distributed way.
Formally speaking, the Choreography Calculus is extended with scopes and updates as follows (with
respect to the notation above we add roles and we omit ˜ in updates):
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 only for a
proper subset of well defined choreographies.
1
First of all, type T related conditions are added in order
1
We refer the reader to [1] for a formal definition of this subset of well defined choreographies, here we simply informally
M. Bravetti
13
(COMMUPD)
X{r : H}
X{r: H}
−−−−→ 1
(SEQUPD)
H
1
X{r: H}
−−−−→ H
′
1
H
1
; H
2
X{r: H}
−−−−→ H
′
1
;(H
2
[H/X])
(PARUPD)
H
1
X{r: H}
−−−−→ H
′
1
H
1
| H
2
X{r: H}
−−−−→ H
′
1
| (H
2
[H/X])
(STARUPD)
H
1
X{r: H}
−−−−→ H
′
1
H
∗
1
X{r: H}
−−−−→ H
′
1
; (H
1
[H/X])
∗
(SCOPEUPD)
H
1
X{r: H}
−−−−→ H
′
1
X : T[H
1
]
X{r: H}
−−−−→ X : T[H]
(SCOPECOMM)
H
1
a
r
1
→r
2
−−−→ H
′
1
X : T[H
1
]
a
r
1
→r
2
−−−→ X : T[H
′
1
]
(SCOPE)
H
1
η
−→ H
′
1
X : T[H
1
]
η
−→ X : T[H
′
1
]
η
6= X{r : H}for any r,H
Table 5: Semantics of Choreographies with updates
to guarantee that: every scope X : T[H
′
] occurring in H has the same type T, denoted with type(X);
and every update X{r : H} injects a choreography H that considers only roles explicitly indicated in the
type T of the updated part(s) X : T[H
′
] (at least one scope X is required to occur in the choreography).
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 5. 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 5. 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 propa-
gating, 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.
Example 3.10 (Adaptable Buyer/Seller/Bank) Here, we consider a version of the Buyer/Seller/Bank
example discussed in the Example 3.2 where it is possible to update the payment interaction between
the buyer and the bank by using, for instance, a new version of the payment protocol according to which
the buyer sends its VISA code to the bank and the bank subsequently confirms its correctness. Let us
consider the following choreography composed of three roles: Buyer, Seller and Bank
Request
Buyer→Seller
;( Offer
Seller→Buyer
|PayDescr
Seller→Bank
);
X{Buyer,Bank}[Payment
Buyer→Bank
];( Confirm
Bank→Seller
|Receipt
Bank→Buyer
)
report the imposed limitations.
14
Towards Dynamic Updates in Service Composition
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 : VISAcode
Buyer→Bank
;VISAok
Bank→Buyer
}
and then becomes the following choreography:
( Offer
Seller→Buyer
|PayDescr
Seller→Bank
);
X{Buyer,Bank}[VISAcode
Buyer→Bank
;VISAok
Bank→Buyer
];( Confirm
Bank→Seller
|Receipt
Bank→Buyer
)
We are now ready to present the definition of our Orchestration Calculus extended with operators for
dynamic updates:
C ::= ...
| X[C]
F
(scope) | X{(r
1
,.. ., r
n
) : C
1
,.. .,C
n
} (update)
where F is a flag that is either A, standing for active (running) scope, or
ε
, denoting a scope still to
be started (
ε
is omitted in the following). X[C]
F
denotes a 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 for scopes to become active, orchestrations starting execution of scopes with the same
name X must synchronize. Also, when all participants in a scope X complete their respective execu-
tions, 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 C
i
.
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 parallel composition of orchestrations:
P ::= [C]
r
| P||P
In this presentation, we do not formally define a semantics for orchestrations: 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 that correspond to the same choreography scope evolve together: they are endowed with scope
start transitions (transforming a scope from inactive to active, setting its flag F to A) that are synchro-
nized; and with scope end transitions (syntactically removing the entire scope) that are synchronized
as well. 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 3.7 for the case
without updates.
Definition 3.11 (Projection for choreographies with updates) The projection of a choreography H on
a role r, denoted by [[H]]
r
, is defined as in Definition 3.7 plus the clauses below for scopes and updates:
[[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 otherwise
M. Bravetti
15
Example 3.12 We now present the projection of the choreography in the Example 3.10 (we omit
unnecessary 1 terms):
[
Request
Seller
;Offer;X[Payment
Bank
];Receipt]
Buyer
||
[Request;(
Offer
Buyer
|PayDescr
Bank
);Confirm]
Seller
||
[PayDescr;X[Payment];(
Receipt
Buyer
|Confirm
Seller
)]
Bank
It 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) :
VISAcode
Bank
;VISAok
,
VISAcode;VISAok
Buyer
} is
executed after the first Request interaction occurs, then the system becomes:
[Offer;X[
VISAcode
Bank
;VISAok];Receipt]
Buyer
||
[(Offer
Buyer
|PayDescr
Bank
);Confirm]
Seller
||
[PayDescr;X[VISAcode;VISAok
Buyer
];(Receipt
Buyer
|Confirm
Seller
)]
Bank
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 3.3. We finally point out two main aspects of the ex-
pected 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 projec-
tions. Second, orchestration traces should not consider unmatched input and output labels.
4 Related Work
The E calculus is related to higher-order process calculi such as, e.g., the higher-order
π
-calculus [22],
Kell [23], and Homer [13]. (Further comparisons between E and other calculi and languages can be
found in [2].) In such calculi, processes can be passed around, and so communication involves term
instantiation, as in the
λ
-calculus. Update actions in E are a form of term instantiation: they can be
seen as a streamlined version of the passivation operator of Kell and Homer, which allows to suspend
a running process. It would be interesting to investigate if the results and techniques developed in this
paper can apply to Kell and Homer (or to some interesting fragments of them).
Concerning theories related to choreographies and orchestrations/contracts, among our main contri-
butions we can mention: (i) The formalisation of the relationship between global choreographic descrip-
tions and systems obtained as parallel compositions of peers, (ii) The definition of suitable notions of
behavioural 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 chore-
ographies 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 ex-
ploiting homomorphism 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., [14], where it is defined in terms of
three connectedness constraints similar to those we have mentioned in Section 3.3. 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. [17] or
16
Towards Dynamic Updates in Service Composition
Padovani et al. [15], where the focus is on the success of one specific peer (usually, the so-called, client).
Concerning (iii), it is worth to mention that [16] 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.
5 Conclusion
We just present some observations about the reported results and remarks concerning current/future work.
Choreography and orchestration languages of Section 3 make use, as common in this context, of
Kleene-star instead of general recursion (or replication as for E calculi considered in Section 2). As a
consequence (see Section 3.3), they always give rise to finite-state transition systems, for which verifi-
cation problems are decidable. Given that update mechanisms we introduced in this context belong to
the class of those considered in the E
2
d
language of Section 2, verification of properties like bounded
adaptability or formulae of a restricted logic like L
r
could be still decidable even if we extend such
languages with some more expressive form of recursion. This, for instance, could introduce the possi-
bility, similarly as for the E family, to generate new participants (or participant instances) at run-time.
Notice that such a correspondence between decidability results for the E family and for choreography
and orchestration languages would be possible because, as common in the context of latter languages,
name binders (CCS restriction) are not considered, which would otherwise make them Turing complete.
We are currently 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 [5, 7, 9, 10, 12] to updatable choreographies/orchestrations would make it
possible to define a notion of semantic subtyping.
References
[1] Bravetti M., Carbone M., Hildebrandt T., Lanese I., Mauro J., Perez J.A., Zavattaro G.: Towards
Global and Local Types for Adaptation. Proc. of 2nd International Workshop on Behavioural Types
– SEFM’13 Colocated Workshops pages 1–12, volume 8378 of Lecture Notes in Computer Science,
Springer-Verlag, 2013. doi:10.1007/978-3-319-05032-4
1
[2] Bravetti, M., Di Giusto, C., P´erez, J. A., Zavattaro, G.: “Adaptable processes”, in Logical Methods in
Computer Science, 8(4), 2012. doi:10.2168/LMCS-8(4:13)2012
[3] Bravetti, M. , Di Giusto, C., P´erez, J. A., Zavattaro, G.: “Towards the Verification of Adaptable Pro-
cesses.”, in Proc. of 5th InternationalSymposium on Leveraging Applications of Formal Methods, Veri-
fication and Validation. Technologiesfor Mastering Change(ISoLA2012)Part I, LNCS7609: 269–283,
Springer 2012. doi:10.1007/978-3-642-34026-0
20
[4] Bravetti, M., Lanese, I., Zavattaro, G.: Contract-Driven Implementation of Choreographies. Proc. TGC
2008: LNCS 5474, Springer, 2009, 1–18. doi:10.1007/978-3-642-00945-7 1
[5] Bravetti, M., Zavattaro, G.: Contract based Multi-party Service Composition, Proc. FSEN’07, LNCS
4767, Springer, 2007, 207–222. doi:10.1007/978-3-540-75698-9
14
[6] Bravetti, M., Zavattaro, G.: A Theory for Strong Service Compliance, Proc. Coordination’07, LNCS
4467, Springer, 2007, 96–112. doi:10.1007/978-3-540-72794-1
6
M. Bravetti
17
[7] Bravetti, M., Zavattaro, G.: Towards a Unifying Theory for Choreography Conformance and Contract
Compliance, Proc. SC’07, LNCS 4829, Springer, 2007, 34–50. doi:10.1007/978-3-540-77351-1
4
[8] Bravetti, M., Zavattaro, G.: Contract Compliance and Choreography Conformance in the
Presence of Message Queues, Proc. WS-FM’08, volume to appear of LNCS, 2008.
doi:10.1007/978-3-642-01364-5
3
[9] Bravetti, M., Zavattaro, G.: A Foundational Theory of Contracts for Multi-party Service Composition,
Fundamenta Informaticae 89(4):451–478, IOS Press, 2008.
[10] Bravetti, M., Zavattaro, G.: Contract-Based Discovery and Composition of Web Services, 9th Interna-
tional School on Formal Methods for the Design of Computer, Communication and Software Systems:
Web Services (SFM-09:WS), LNCS 5569, Springer, 2009, 34–50. doi:10.1007/978-3-642-01918-0
7
[11] Bravetti, M., Zavattaro, G.: A Theory of Contracts for Strong Service Compliance, Math-
ematical Structure in Computer Science 19(3):601–638, Cambridge University Press, 2009.
doi:10.1017/S0960129509007658
[12] Bravetti, M., Zavattaro, G.: Service Discovery and Composition based on Contracts and Choreographic
Descriptions, Adaptive Web Services for Modular and Reusable Software Development: Tactics and
Solutions, IGI Global, 2012. doi:10.4018/978-1-4666-2089-6
[13] M. Bundgaard, J. C. Godskesen, and T. Hildebrandt. Bisimulation congruences for homer — a cal-
culus of higher order mobile embedded resources. Technical Report TR-2004-52, IT University of
Copenhagen, 2004.
[14] Carbone M., Honda K., Yoshida N.: Structured Communication-Centred Programming for Web Ser-
vices. In ESOP’07, volume to appear of LNCS, 2007. doi:10.1007/978-3-540-71316-6 2
[15] Carpineti S., Castagna G., Laneve C., Padovani L.: A Formal Account of Contracts for Web Services.
In WS-FM’06, volume 4184 of LNCS, pages 148-162, 2006. doi:10.1007/11841197
10
[16] Dalla Preda M., Giallorenzo S., Lanese I., Mauro J., Gabbrielli M.: AIOCJ: A Choreographic Frame-
work for Safe Adaptive Distributed Applications. Proc. SLE 2014: LNCS 8706, Springer, 2014, 161–
170. doi:10.1007/978-3-319-11245-9
9
[17] Fournet C., Hoare C.A.R, Rajamani S.K., Rehof J.: Stuck-Free Conformance. In Proc. CAV’04, volume
3114 of LNCS, pages 242–254, 2004. doi:10.1007/978-3-540-27813-9
19
[18] L. Cardelli and A. D. Gordon. Mobile ambients. Theor. Comput. Sci., 240(1):177–213, 2000.
doi:10.1016/S0304-3975(99)00231-5
[19] Lanese I., Guidi C., Montesi F., Zavattaro G.: Bridging the gap between Interaction- and
Process-Oriented Choreographies. Proc. of 6th IEEE International Conferences on Software En-
gineering and Formal Methods (SEFM’08), pages 323–332, IEEE Computer Society press, 2008.
doi:10.1109/SEFM.2008.11
[20] R. Milner. Comunication and Concurrency. Prentice Hall, 1989.
[21] R. Milner, J. Parrow, and D. Walker. A Calculus of Mobile Processes, I. Inf. Comput., 100(1):1–40,
1992. doi:10.1016/0890-5401(92)90008-4
[22] D. Sangiorgi. Expressing Mobility in Process Algebras: First-Order and Higher-Order Paradigms.
PhD thesis CST–99–93, University of Edinburgh, Dept. of Comp. Sci., 1992.
[23] A. Schmitt and J.-B. Stefani. The kell calculus: A family of higher-order distributed pro-
cess calculi. In Global Computing, volume 3267 of LNCS, pages 146–178. Springer, 2004.
doi:10.1007/978-3-540-31794-4
9
