This document summarizes Davide Basile's PhD thesis on specifying and verifying contract-based applications. The thesis introduces contract automata as a novel model for specifying service contracts. Contract automata are finite state automata enhanced to model multiparty service interactions. The thesis defines three key properties for analyzing service agreements - strong agreement, agreement, and weak agreement - and presents techniques for model checking contract automata against these properties using control theory and linear programming. It also explores relating contract automata to logical models and using them for choreographic modeling in service-oriented computing.

1. Specication and Verication
of Contract-Based Applications
Ph.D. candidate: Davide Basile
Supervisors: Pierpaolo Degano Gian-Luigi Ferrari
Department of Computer Science, University of Pisa
21/06/2016

2. Overline of the presentation
1 Research eld, Challenges, Goal of the thesis
2 PhD thesis contributions Questions
3 Conclusions

3. Introduction: SOC paradigm, Motivations, Challenges
ICT infrastructures depend on heterogeneous inter-organizational
digital systems that cooperate through the Internet;
Service Oriented Computing: a recent paradigm for building
applications by composing loosely coupled, ne grained distributed
computational units called services. Services are provided by mutually
distrusted organizations, and have to compete to reach their goals;
Challenges: Provide new methodologies for designing distributed
systems and verifying that their composite behaviour agree to
specied safety requirements, even in a malicious environment;
Formal models play an important role in providing models and tools
for these purposes.

4. Introduction: Contracts
Goal of the thesis
The goal of the thesis is to provide techniques for specifying and verifying
properties of service-based distributed systems
Service contracts have been introduced to:
1 describe the behaviour of services: requirements and obligations;
2 characterize service assemblies;
3 guarantee safety properties: behavioural conformance, agreement;

5. Introduction: Contracts, SOA
Service contracts: published in a trusted repository, accessed through
service discovery;
Coordinator: nds and proposes an agreement to the interacting
parties, all the requirements and duties are satised;
Eventually if any involved service violates its contract agreement, it
will be blamed.

6. Service Coordination: Orchestration and Choreography
Orchestration
Services interact via mediation of a distinguished participants, the
orchestrator, that regulates the control ow.
Choreography
Distributed participants interact autonomously, by conforming to a given
global description.

7. PhD thesis contributions
1 Contract Compliance as a Safety Property
multi-party contracts, ecient model checking techniques
2 Contract Automata: a novel automata-based model of contracts
compositional, several notions of agreement, liable principals, Control
Theory and Linear Programming techniques
3 Contract Automata have been related to
Two Intuitionistic Logics for Contracts
logical characterization of contract agreement
an Automata-based Choreographic Model for SOC
decentralization, reducing the communication overhead
4 A Tool for Contract Automata
fully automatize our proposal

8. Publications
International Journals:
1 Basile, D., Degano, P., Ferrari, G.L.: A formal framework for secure and complying services. The
Journal of Supercomputing 69(1), 4352 (2014);
2 Basile D. , Degano P. , Ferrari G.L. , Tuosto E.: Relating two automata-based models of
orchestration and choreography, Journal of Logical and Algebraic Methods in Programming, Volume
85, Issue 3, April 2016, Pages 425-446, ISSN 2352-2208;
3 Basile, D., Degano, P., Ferrari, G.L.: Automata for specifying and orchestrating service contracts. To
appear in Journal of Logical Methods in Computer Science (2016), ISSN: 1860-5974;
International Conferences and Workshops:
1 Basile, D.: Service interaction contracts as security policies. In: ICTCS 2012, Varese, Italy, available
online at http://ictcs.di.unimi.it/papers/paper_28.pdf;
2 Basile, D., Degano, P., Ferrari, G.L.: Secure and unfailing services. In: Malyshkin, V. (ed.) PaCT.
LNCS, vol. 7979, pp. 167181. Springer (2013);
3 Basile, D., Degano, P., Ferrari, G.L.: Automata for service contracts. In: Hot Issues in Security
Principles and Trust - 2nd Workshop, HOTSPOT 2014, Grenoble, France;
4 Basile, D., Degano, P., Ferrari, G.L.: Automata for analysing service contracts. In: Trustworthy
Global Computing - 9th International Symposium, TGC 2014. Revised Selected Papers, LNCS, vol.
8902, pp. 3450. Springer (2014);
5 Basile, D., Degano, P., Ferrari, G.L., Tuosto, E.: From orchestration to choreography through
contract automata. In: Lanese, I., Lluch-Lafuente, A., Sokolova, A., Vieira, H.T. (eds.) Proceedings
7th Interaction and Concurrency Experience 2014, Berlin, Germany. EPTCS, vol. 166,;
6 Basile, D., Degano, P., Ferrari, G.L., Tuosto, E.: Playing with our CAT and Communication-Centric
Applications. To appear in Formal Techniques for Networked and Distributed Systems (FORTE)
2016, LNCS, volume 9688, 2016.

9. Contract Compliance as a Safety Property
Section 1
Contract Compliance as a Safety Property

10. Contract Compliance as a Safety Property
Compliance as a Safety Property: Contributions
a SOC formal model combining:
Contracts σ: Server-Client interactions
Security ϕ: Resource Access Control
Novelties
naturally deals with σ, ϕ and multi-party
model checking techniques for ensuring compliance of σ and ϕ
compliance=safety property

11. Contract Compliance as a Safety Property
Behavioural contracts
A CCS-like process algebra characterising bi-party interactions:
prex a.σ perform an I/O action a and then σ
internal choice σ1 ⊕ σ2 internally decide the branch
external choice σ1 + σ2 the other party decides the branch
Compliance
σ ρ : the client σ successfully terminates all its interactions with the
server ρ
Example
a ⊕ b a + b + c a ⊕ b ⊕ c a + b

12. Contract Compliance as a Safety Property
Behavioural contracts
A CCS-like process algebra characterising bi-party interactions:
prex a.σ perform an I/O action a and then σ
internal choice σ1 ⊕ σ2 internally decide the branch
external choice σ1 + σ2 the other party decides the branch
Compliance
σ ρ : the client σ successfully terminates all its interactions with the
server ρ
Example
a ⊕ b a + b + c a ⊕ b ⊕ c a + b

13. Contract Compliance as a Safety Property
Behavioural contracts
A CCS-like process algebra characterising bi-party interactions:
prex a.σ perform an I/O action a and then σ
internal choice σ1 ⊕ σ2 internally decide the branch
external choice σ1 + σ2 the other party decides the branch
Compliance
σ ρ : the client σ successfully terminates all its interactions with the
server ρ
Example
a ⊕ b a + b + c a ⊕ b ⊕ c a + b

14. Contract Compliance as a Safety Property
History Expression, Security Policies
Access events α security critical operations logged into history η
History Expressions: abstract descriptions of services α
Security policies ϕ: regular properties of η,
Orchestrator: binds requests to services satisfying ϕ
Model-Checking techniques: H π
R ∩ ϕ
Example
ϕ : never perform αwrite after αread
η = αread ϕαwrite ϕ η |=

15. Contract Compliance as a Safety Property
History Expression, Security Policies
Access events α security critical operations logged into history η
History Expressions: abstract descriptions of services α
Security policies ϕ: regular properties of η,
Orchestrator: binds requests to services satisfying ϕ
Model-Checking techniques: H π
R ∩ ϕ
Example
ϕ : never perform αwrite after αread
η = αread ϕαwrite ϕ η |=

16. Contract Compliance as a Safety Property
The proposed calculus
the proposed calculus = H + σ + multi-party session primitives
Theorem (Compliance)
Let (H1)!
= H1 and (H2)!
= H2
H1 H2 if and only if L (H1 ⊗ H2) = ∅
(H1)!
extract from a service description all σ and H, to check them
separately (modularity);
synchronous product of a client and a server contracts: nal states represent
violation of compliance.

17. Contract Compliance as a Safety Property
The proposed calculus
the proposed calculus = H + σ + multi-party session primitives
Theorem (Compliance)
Let (H1)!
= H1 and (H2)!
= H2
H1 H2 if and only if L (H1 ⊗ H2) = ∅
(H1)!
extract from a service description all σ and H, to check them
separately (modularity);
synchronous product of a client and a server contracts: nal states represent
violation of compliance.

18. Contract Compliance as a Safety Property
Question
Question
What we gain by incorporating σ and ϕ?
Compliance of behavioural contracts is a safety property, and can be
eciently veried through automata-based model checking techniques;
A calculus with primitives for multi-party contract interactions;
Security properties over behavioural contracts.

19. Contract Automata
Section 2
Contract Automata

20. Contract Automata
Contract Automata for SOC
An original automata-based model called contract automata:
Compositional, describes both principals and composite services,
Automata compositions: ⊗, ,
Safety checks: A; Z, W - agreement; strong and weak agreement,
Synthesise the orchestrator via Control Theory, when possible,
otherwise Linear programming techniques;
Detect liable principals,
Decentralization: remove the orchestrator,

21. Contract Automata
Contract Automata (CA)
Contract Automata: FSA enhanced with:
Partitioned alphabet:
Ar
request actions
Ao
oer actions
rank the number of principals in the contract
principal rank=1 and Ar
∩ co(Ao
) = ∅
the labels are vectors of three types:
request: ( , a, , )
oer: ( , , , a)
match: ( , a, , a)

22. Contract Automata
Contract Automata: 2-Buyers Protocol
qB10
qB11
qB12
qB13
price
quote1
contrib
Buyer B1
qS 0
qS 1
qS 2
qS 3
qS 4
qS 5
price
quote1
quote2
ok
nop delivery
Seller S
qB20
qB21
qB22
qB23
qB24
quote2 contrib
ok
nop
delivery
Buyer Good_B2
qB20
qB21
contrib
Buyer Bad_B2

23. Contract Automata
Contract Automata: 2-Buyers Protocol
qB10
qB11
qB12
qB13
price
quote1
contrib
Buyer B1
qS 0
qS 1
qS 2
qS 3
qS 4
qS 5
price
quote1
quote2
ok
nop delivery
Seller S
qB20
qB21
qB22
qB23
qB24
quote2 contrib
ok
nop
delivery
Buyer Good_B2
qB20
qB21
contrib
Buyer Bad_B2

24. Contract Automata
Product Example: B1 ⊗ Bad_B2 1
qB10
qB11
qB12
qB13
price quote1 contrib qB20
qB21
contrib
Firstly compute all the interleavings
q0 q1 q2
q4 q5 q6
q3
q7
(price, )
( , contrib)
(quote1, )
( , contrib) ( , contrib)
(contrib, )
( , contrib)
(contrib, )(price, ) (quote1, )
Figure: B1 ⊗ Bad_B2

25. Contract Automata
Product Example: B1 ⊗ Bad_B2 2
qB10
qB11
qB12
qB13
price quote1 contrib qB20
qB21
contrib
Then remove interleavings and add a match where it is possible
q0 q1 q2
q4 q5 q6
q3
q7
(price, )
( , contrib)
(quote1, )
( , contrib)
(contrib, )
( , contrib)
(contrib, contrib)
( , contrib)
(contrib, )(price, ) (quote1, )
Figure: B1 ⊗ Bad_B2

26. Contract Automata
Product Example:(B1 ⊗ Bad_B2) ⊗ Bad_B2
The product ⊗ models a static orchestration policy: matches are not
rearranged, Bad_B2
never receives contrib
q1
qi0
qi2
qi1
qi3
( , , contrib)
(contrib, contrib, )
( , , contrib)
(contrib, contrib, )
Figure: (B1 ⊗ Bad_B2) ⊗ Bad_B2

27. Contract Automata
Product Example:(B1 Bad_B2) Bad_B2
The a-product models a dynamic orchestration policy: matches are
rearranged, Bad_B2
could receive contrib
q
qi0
qi2
qi1
qi3
(contrib, , contrib)
(contrib, contrib, )
( , , contrib)
( , contrib, )
Figure: (B1 Bad_B2) Bad_B2
= Π; ⊗ (Π recovers principals from a CA)

28. Contract Automata
Three properties of agreement
Z Strong Agreement : all requests and oers matched synchronously;
A Agreement: all requests matched synchronously, free oers
(environment);
W Weak Agreement: all requests matched asynchronously (debits).
A admits P ↔ L (A) ∩ P = ∅, P ∈ {Z, A, W}
A is P safe ↔ L (A) ⊆ P
if A admits P but it is not P safe, then someone is liable,
i.e. good executions exist together with bad computations Question
Control Theory ⇒ regular properties
Mixed Integer Linear Programming ⇒ context-sensitive property

29. Contract Automata
Three properties of agreement
Z Strong Agreement : all requests and oers matched synchronously;
A Agreement: all requests matched synchronously, free oers
(environment);
W Weak Agreement: all requests matched asynchronously (debits).
A admits P ↔ L (A) ∩ P = ∅, P ∈ {Z, A, W}
A is P safe ↔ L (A) ⊆ P
if A admits P but it is not P safe, then someone is liable,
i.e. good executions exist together with bad computations Question
Control Theory ⇒ regular properties
Mixed Integer Linear Programming ⇒ context-sensitive property

30. Contract Automata
Three properties of agreement
Z Strong Agreement : all requests and oers matched synchronously;
A Agreement: all requests matched synchronously, free oers
(environment);
W Weak Agreement: all requests matched asynchronously (debits).
A admits P ↔ L (A) ∩ P = ∅, P ∈ {Z, A, W}
A is P safe ↔ L (A) ⊆ P
if A admits P but it is not P safe, then someone is liable,
i.e. good executions exist together with bad computations Question
Control Theory ⇒ regular properties
Mixed Integer Linear Programming ⇒ context-sensitive property

31. Contract Automata
Strong Agreement, Agreement, Weak Agreement
Strong Agreement Z
(a, a)(b, b) ∈ Z
(a, a)(b, b)(c, ) ∈ Z
Agreement A
(a, a)(b, b)(c, ) ∈ A
(a, )(b, b)( , a)(c, ) ∈ A
Weak Agreement W
(a, )(b, b)( , a)(c, ) ∈ W
(a, )(a, )(b, b)( , a)(c, ) ∈ W

32. Contract Automata
Strong Agreement, Agreement, Weak Agreement
Strong Agreement Z
(a, a)(b, b) ∈ Z
(a, a)(b, b)(c, ) ∈ Z
Agreement A
(a, a)(b, b)(c, ) ∈ A
(a, )(b, b)( , a)(c, ) ∈ A
Weak Agreement W
(a, )(b, b)( , a)(c, ) ∈ W
(a, )(a, )(b, b)( , a)(c, ) ∈ W

33. Contract Automata
Strong Agreement, Agreement, Weak Agreement
Strong Agreement Z
(a, a)(b, b) ∈ Z
(a, a)(b, b)(c, ) ∈ Z
Agreement A
(a, a)(b, b)(c, ) ∈ A
(a, )(b, b)( , a)(c, ) ∈ A
Weak Agreement W
(a, )(b, b)( , a)(c, ) ∈ W
(a, )(a, )(b, b)( , a)(c, ) ∈ W

34. Contract Automata
Synthesising the orchestrator
Orchestrator = Most Permissive Controller (MPC), Control Theory;
all actions controllable: the MPC exists;
predicates to be enforced: properties of agreement (Z, A);
liable transitions: those denitively compromising the agreement, i.e.
source state ∈ MPC, target state ∈ MPC;
The orchestrator only allows good behaviour while blocking bad
ones.

35. Contract Automata
Contract Automata: example
A B C
q0start
q1
a
q0start
q1 q3
q2
a
b
a
b
q0start
q1
ba

36. Contract Automata
Product
A ⊗ B ⊗ C
q0start q1 q2
q6 q3
q7 q8 q4
(a, a, )
(
,b,b)
(a, , a)
( , , a)
(,b,b)
( , b, )
(a,a,
)
( , a, )
(
,b,
)
( , b, )
( , a, )

37. Contract Automata
1 - Remove requests and oers
q0start q1 q2
q6 q3
q7 q8 q4
(a, a, )
(
,b,b)
(a, , a)
( , , a)
(,b,b)
( , b, )
(a,a,
)
( , a, )
(
,b,
)
( , b, )
( , a, )

38. Contract Automata
1 - Remove requests and oers
q0start q1 q2
q6 q3
q7 q8 q4
(a, a, )
(
,b,b)
(a, , a)
(,b,b)
(a,a,
)

39. Contract Automata
2 - Remove redundant states
q0start q1
q3
q4
(a, a, )
(
,b,b)
(,b,b)
(a,a,
)

40. Contract Automata
Controller
q0start q1
q3
q4
(a, a, )
(
,b,b)
(,b,b)
(a,a,
)
The controller KSA⊗B⊗C is strongly safe

41. Contract Automata
Liable principals
q0start q1 q2
q6 q3
q7 q8 q4
(a, a, )
(
,b,b)
(a, , a)
( , , a)
(,b,b)
( , b, )
(a,a,
)
( , a, )
(
,b,
)
( , b, )
( , a, )

42. Contract Automata
Most-Permissive Controller for Z: 2BP Example
qB10
qB11
qB12
qB13
price
quote1
contrib
Buyer B1
qB20
qB21
qB22
qB23
qB24
quote2 contrib
ok
nop
delivery
Buyer Good_B2
qS 0
qS 1
qS 2
qS 3
qS 4
qS 5
price
quote1
quote2
ok
nop delivery
Seller S
q0
q1 q2
q3 q4
q5 q6
q7
(price, , price)
(quote1
, , quote1
)
( , quote2
, quote2
)
(contrib, , )
(contrib, contrib, )
( , ok, ok)
( , nop, nop)
( , delivery, delivery)
KSB1⊗Good_B2⊗S
L (KSB1⊗Bad_B2⊗S) = ∅

43. Contract Automata
Most-Permissive Controller for Z: 2BP Example
qB10
qB11
qB12
qB13
price
quote1
contrib
Buyer B1
qB20
qB21
qB22
qB23
qB24
quote2 contrib
ok
nop
delivery
Buyer Good_B2
qS 0
qS 1
qS 2
qS 3
qS 4
qS 5
price
quote1
quote2
ok
nop delivery
Seller S
q0
q1 q2
q3 q4
q5 q6
q7
(price, , price)
(quote1
, , quote1
)
( , quote2
, quote2
)
(contrib, , )
(contrib, contrib, )
( , ok, ok)
( , nop, nop)
( , delivery, delivery)
KSB1⊗Good_B2⊗S
L (KSB1⊗Bad_B2⊗S) = ∅

44. Contract Automata
Weak-Agreement
We consider a dierent type of agreement, where actions are taken on
credit if in the future the obligations will be honoured.
Addressed in literature with formalisms as logic, event structures, petri
nets, process algebra etc..
Example
Alice and Bob do not trust each other
Alice = toy.bike, Bob = bike.toy
Alice ⊗Bob = (toy, )(bike, bike)( , toy)+( , bike)(toy, toy)(bike, )
L (Alice ⊗ Bob) ∩ A = ∅ L (Alice ⊗ Bob) ∩ W = ∅

45. Contract Automata
Weak agreement example
qB10
qB11
qB12
qB13
price
quote1
contrib
Buyer B1
qB20
qB21
qB22
qB23
qB24
contrib quote2
ok
nop
delivery
Buyer NotSoBad_B2
qS 0
qS 1
qS 2
qS 3
qS 4
qS 5
price
quote2
quote1
ok
nop delivery
Seller S
L (KB1⊗NotSoBadB2⊗S) = ∅ w ∈ W ∩ L (B1 ⊗ NotSoBadB2 ⊗ S)
detected circular dependency
w = (price, , price)( , contrib, )( , quote2, quote2)
( , quote1, quote1)(contrib, , )( , nop, nop)

46. Contract Automata
Weak agreement example
qB10
qB11
qB12
qB13
price
quote1
contrib
Buyer B1
qB20
qB21
qB22
qB23
qB24
contrib quote2
ok
nop
delivery
Buyer NotSoBad_B2
qS 0
qS 1
qS 2
qS 3
qS 4
qS 5
price
quote2
quote1
ok
nop delivery
Seller S
L (KB1⊗NotSoBadB2⊗S) = ∅ w ∈ W ∩ L (B1 ⊗ NotSoBadB2 ⊗ S)
detected circular dependency
w = (price, , price)( , contrib, )( , quote2, quote2)
( , quote1, quote1)(contrib, , )( , nop, nop)

47. Contract Automata
Weak agreement example
qB10
qB11
qB12
qB13
price
quote1
contrib
Buyer B1
qB20
qB21
qB22
qB23
qB24
contrib quote2
ok
nop
delivery
Buyer NotSoBad_B2
qS 0
qS 1
qS 2
qS 3
qS 4
qS 5
price
quote2
quote1
ok
nop delivery
Seller S
L (KB1⊗NotSoBadB2⊗S) = ∅ w ∈ W ∩ L (B1 ⊗ NotSoBadB2 ⊗ S)
detected circular dependency
w = (price, , price)( , contrib, )( , quote2, quote2)
( , quote1, quote1)(contrib, , )( , nop, nop)

48. Contract Automata
Checking Weak Safety and Weak Agreement
Theorem
W is a context-sensitive property, but not context-free.
Not decidable in general, W is decidable
novel technique based on network ow problems to check W
optimization techniques can be exploited to verify properties of service
composition.
Automata ⇒ Networks
Traces ⇒ Flows
Labels ⇒ Weights (Oers +1, Requests -1)
P holds ⇒ objective function 0

49. Contract Automata
Checking Weak Safety and Weak Agreement
Theorem
W is a context-sensitive property, but not context-free.
Not decidable in general, W is decidable
novel technique based on network ow problems to check W
optimization techniques can be exploited to verify properties of service
composition.
Automata ⇒ Networks
Traces ⇒ Flows
Labels ⇒ Weights (Oers +1, Requests -1)
P holds ⇒ objective function 0

50. Contract Automata
Weak Safety
the objective function min γ selects the trace and action with
minimum n = |O| − |R|.
min γ ≥ 0 i A is weakly safe
Theorem
Let v be a binary vector. Then a CA A is weakly safe i min γ ≥ 0 where:
i∈Il
vi
tj ∈T
ai
tj
xtj ≤ γ
i∈Il
vi = 1 ∀i ∈ Il .vi ∈ {0, 1}
(xt1 . . . xtn ) ∈ Fx γ ∈ R

51. Contract Automata
Weak Safety
the objective function min γ selects the trace and action with
minimum n = |O| − |R|.
min γ ≥ 0 i A is weakly safe
Theorem
Let v be a binary vector. Then a CA A is weakly safe i min γ ≥ 0 where:
i∈Il
vi
tj ∈T
ai
tj
xtj ≤ γ
i∈Il
vi = 1 ∀i ∈ Il .vi ∈ {0, 1}
(xt1 . . . xtn ) ∈ Fx γ ∈ R

52. Contract Automata
Weak Agreement
the objective function max γ selects the trace and action with
maximum n = |O| − |R|.
max γ 0 i A does not admit W
Theorem
The CA A admits weak agreement i :
max γ ≥ 0 and ∀i ∈ Il .
tj ∈T
ai
tj
xtj ≥ γ
(xt1 . . . xtn ) ∈ Fx γ ∈ R

53. Contract Automata
Weak Agreement
the objective function max γ selects the trace and action with
maximum n = |O| − |R|.
max γ 0 i A does not admit W
Theorem
The CA A admits weak agreement i :
max γ ≥ 0 and ∀i ∈ Il .
tj ∈T
ai
tj
xtj ≥ γ
(xt1 . . . xtn ) ∈ Fx γ ∈ R

54. Contract Automata
Weak Liability
q0start qs
qd
qf
x y
t u
the bilevel problem checks if ∃ (min) x · y ∈ W such that ∀ (max) u
we have x · t · u ∈ W
Theorem
The participant Πi (A) of a CA A is weakly liable if and only if there exists
a transition t = (qs, a, qt), ai = , and γt 0, where
γt = min {f (x) | x ∈ Fq0,qs
, y ∈ Fqs ,qf
, ∀i ∈ Il . tj ∈T ai
tj
(xtj + ytj ) ≥ 0}
f (x) = max {γ | u ∈ Fqt ,qf
∀i ∈ Il . tj ∈T ai
tj
(xtj + utj ) + ai
t
≥ γ, γ ∈ R}

55. Contract Automata
Weak Liability
q0start qs
qd
qf
x y
t u
the bilevel problem checks if ∃ (min) x · y ∈ W such that ∀ (max) u
we have x · t · u ∈ W
Theorem
The participant Πi (A) of a CA A is weakly liable if and only if there exists
a transition t = (qs, a, qt), ai = , and γt 0, where
γt = min {f (x) | x ∈ Fq0,qs
, y ∈ Fqs ,qf
, ∀i ∈ Il . tj ∈T ai
tj
(xtj + ytj ) ≥ 0}
f (x) = max {γ | u ∈ Fqt ,qf
∀i ∈ Il . tj ∈T ai
tj
(xtj + utj ) + ai
t
≥ γ, γ ∈ R}

56. Contract Automata
Properties of composition under agreement
Competitive Ao
1
∩ Ao
2
∩ co(Ar
1
∪ Ar
2
) = ∅
Collaborative (Ao
1
∩ co(Ar
2
)) ∪ (co(Ar
1
) ∩ Ao
2
) = ∅
Theorem (Competitive, Collaborative and Agreement)
A1, A2 safe ⇒ A1 ⊗ A2 is safe but A1 A2 no.
A1, A2 safe and non-competitive ⇒ A1 A2 is safe.
Modular verication: eciency

57. Contract Automata
Properties of composition under agreement
Competitive Ao
1
∩ Ao
2
∩ co(Ar
1
∪ Ar
2
) = ∅
Collaborative (Ao
1
∩ co(Ar
2
)) ∪ (co(Ar
1
) ∩ Ao
2
) = ∅
Theorem (Competitive, Collaborative and Agreement)
A1, A2 safe ⇒ A1 ⊗ A2 is safe but A1 A2 no.
A1, A2 safe and non-competitive ⇒ A1 A2 is safe.
Modular verication: eciency

58. Relating Contract Automata and Choreographies
Section 3
Relating Contract Automata and Choreographies

59. Relating Contract Automata and Choreographies
Decentralization
Orchestrator KSA
−
⇒ System of CFSMs Choreography
synchronous CFSMs one-buer
convergence ⇒ branching condition
asynchronous CFSMs unbounded-buers
convergence ⇒ no mixed choices
branching condition = indipendent moves
no mixed choices = single point of choice
Intended benets: dismissing the orchestrator, so reducing the
communication overhead.

60. Relating Contract Automata and Choreographies
Decentralization
Orchestrator KSA
−
⇒ System of CFSMs Choreography
synchronous CFSMs one-buer
convergence ⇒ branching condition
asynchronous CFSMs unbounded-buers
convergence ⇒ no mixed choices
branching condition = indipendent moves
no mixed choices = single point of choice
Intended benets: dismissing the orchestrator, so reducing the
communication overhead.

61. Relating Contract Automata and Choreographies
Decentralization
Orchestrator KSA
−
⇒ System of CFSMs Choreography
synchronous CFSMs one-buer
convergence ⇒ branching condition
asynchronous CFSMs unbounded-buers
convergence ⇒ no mixed choices
branching condition = indipendent moves
no mixed choices = single point of choice
Intended benets: dismissing the orchestrator, so reducing the
communication overhead.

62. Relating Contract Automata and Choreographies
Decentralization
Orchestrator KSA
−
⇒ System of CFSMs Choreography
synchronous CFSMs one-buer
convergence ⇒ branching condition
asynchronous CFSMs unbounded-buers
convergence ⇒ no mixed choices
branching condition = indipendent moves
no mixed choices = single point of choice
Intended benets: dismissing the orchestrator, so reducing the
communication overhead.

63. Relating Contract Automata and Choreographies
Translation
q0start q1
q3 q4
(a, a, )
( , b, b) ( , b, b)
(a, a, )
KSA⊗B⊗C A KSA⊗B⊗C B KSA⊗B⊗C C
q0start
q1
a@AB
q0start
q1 q3
q2
a@AB
b@BC
a@AB
b@BC
q0start
q1
b@BC

64. Relating Contract Automata and Choreographies
Decentralization
qB10
qB11
qB12
qB13
price
quote1
contrib
Buyer B1
qB20
qB21
qB22
qB23
qB24
quote2 contrib
ok
nop
delivery
Buyer Good_B2
qS 0
qS 1
qS 2
qS 3
qS 4
qS 5
price
quote1
quote2
ok
nop delivery
Seller S
q0
q1 q2
q3 q4
q5 q6
q7
(price, , price)
(quote1
, , quote1
)
( , quote2
, quote2
)
(contrib, , )
(contrib, contrib, )
( , ok, ok)
( , nop, nop)
( , delivery, delivery)
KSB1⊗Good_B2⊗S
State [2,0,2] (q2) violates the branching condition because it
has no transition labelled [contrib!,contrib?,0] which is instead
enabled in state [2,1,3] (q3)

65. Relating Contract Automata and Choreographies
Decentralization Fix
qB10
qB11
qB12
qB13
price
quote1
contrib
Buyer B1
qB20
qB21
qB22
qB23
qB24
quote2 contrib
ok
nop
delivery
Buyer Good_B2
qS 0
qS 1
qS 2
qS 3
qS 4
qS 5
price
quote2
quote1
ok
nop delivery
Seller Good_S
q0
q1 q2
q3 q4
q5 q6
q7
(price, , price)
( , quote2
, quote2
)
(quote1
, , quote1
)
(contrib, , )
(contrib, contrib, )
( , ok, ok)
( , nop, nop)
( , delivery, delivery)
KSB1⊗Good_B2⊗Good_S
The CA enjoys the branching condition
The CA has no mixed choice states

66. Relating Contract Automata and Choreographies
Question 1
Question
What is the impact of the assumptions for removing the orchestrator?
One-buer semantics: necessary and sucient conditions;
Unbounded semantics: false positives convergent systems with
mixed choices.
In this case, there are trace equivalent systems (up to dummy
transitions) that are not rejected by our analysis (i.e. with no mixed
choices).

67. Relating Contract Automata and Choreographies
Example: removing mixed choices
q0start q1
q2 q3
(a, a)
(b, b) (b, b)
(a, a)
(a) A ⊗ B (A = a.b + b.a, B = b.a + a.b)
q0start
q1
q2 q3
q4 q5
(d1, , d1)
( , d2, d2)
(a, a, )
(b, b, )
(b, b, )
(a, a, )
(b) KA⊗B⊗D (A = d1.a.b + b.a, B = d2.b.a + a.b, D = d1 + d2)

68. Relating Contract Automata and Choreographies
Question 2
Question
Dierences between product of CA and choreography extraction
CFSMs know their partners (FIFO buers);
our assumptions: CA are oblivious of their partners;
automatic synthesis of the orchestrator enforcing agreement;
dierent policies of orchestration;
compositionality;
liable detection.

69. Relating Contract Automata and Logics
Section 4
Relating Contract Automata and Logics

70. Relating Contract Automata and Logics
Propositional Contract Logic
Intuitionistic logic extended with contractual implication for solving
circular dependencies
Example
Alice says I will lend you my aeroplane provided that you lend me
your bike = b → a.
Bob says I will lend you my bike on credit that in the future you will
lend me your aeroplane and your car=(a ∧ c) b
Charlie I will lend you my car= c
Agreement: (b → a) ∧ ((a ∧ c) b) ∧ c a ∧ c ∧ b.

71. Relating Contract Automata and Logics
H-PCL to CA
q11start q21
b
a
(a) Alice
q12start q22
q32
q42
a
c
b
b
c
a
b b
(b) Bob
q13start
c
(c) Charlie
q1start q2 q3
q4 q5 q6
(b, b, )
( , c, c)
( , b, )
(a, a, )
( , c, c) ( , c, c)
(a, , ), ( , b, )
( , , c)
(b, b, )
( , b, ), ( , , c)
(a, a, )
(a, , ), ( , b, ), ( , , c)
(d) K Alice ⊗ Bob ⊗ Charlie

72. Relating Contract Automata and Logics
H-PCL to CA: results
Theorem (PCL agreement)
p λ(p) if and only if p admits agreement.
Theorem (PCL Weak Agreement)
p(→) λ(p(→)) if and only if p(→) admits weak agreement.
Logic interpretation of W: → lifted to ;
Intended Benets:
deduction trees of PCL formulae through CA algorithms;
p ⊗ A admits Z, A, W?

73. Relating Contract Automata and Logics
H-PCL to CA: results
Theorem (PCL agreement)
p λ(p) if and only if p admits agreement.
Theorem (PCL Weak Agreement)
p(→) λ(p(→)) if and only if p(→) admits weak agreement.
Logic interpretation of W: → lifted to ;
Intended Benets:
deduction trees of PCL formulae through CA algorithms;
p ⊗ A admits Z, A, W?

74. Relating Contract Automata and Logics
Intuitionistic Linear Logic with mix
Resource cannot always be duplicated or contracted at will;
Possibility of recording debts a⊥.
Annihilation principle, a ⊗ a⊥ 1: a credit and a debit of the same
resource can be cancelled out;
Useful for modelling circular dependencies:
Alice: b a
Bob: a⊥
⊗ c⊥
⊗ b
Charlie: c
Agreement: Alice ⊗ Bob ⊗ Charlie , all resources are consumed

75. Relating Contract Automata and Logics
H-ILLmix
to CA
q11start q21
q31
b a
(a) Alice
q12start q22
q32
q42
q52
q62
q72
q82
a
c
b
b
c
a
b
b
a
c c
a
(b) Bob
q13start q23
c
(c) Charlie
q1start q2 q3
q4 q5 q6
(b, b, )
( , c, c)
(a, a, )
( , c, c) ( , c, c)
(b, b, −) (a, a, )
(d) K Alice Bob Charlie

76. Relating Contract Automata and Logics
H-ILLmix
to CA: Results
Theorem (ILLmix Agreement)
Γ Z i Γ admits agreement on Z
Intended Benets:
Characterization of A through ILLmix ;
Γ ⊗ A admits Z, A, W?
Γ, Γ Z i Γ Γ admits A

77. Relating Contract Automata and Logics
H-ILLmix
to CA: Results
Theorem (ILLmix Agreement)
Γ Z i Γ admits agreement on Z
Intended Benets:
Characterization of A through ILLmix ;
Γ ⊗ A admits Z, A, W?
Γ, Γ Z i Γ Γ admits A

78. A Tool for Contract Automata
Section 5
A Tool for Contract Automata

79. A Tool for Contract Automata
Contract Automata Tool
AMPL models CAT API JAMATAuses extends
fully automatize our proposal;
uses ecient linear programming techniques for checking the
properties of a CA;
has been adopted for verifying service-based applications;
CAT is available at
https://github.com/davidebasile/workspace.

80. A Tool for Contract Automata
CAT screenshot

81. A Tool for Contract Automata
Summarizing Verifying 2BP with CAT
B1 ⊗ GoodB2 ⊗ GoodS Z A W @@@@@@@hhhhhhhOrchestrator
B1 ⊗ GoodB2 ⊗ S Z A W Orchestrator
B1 ⊗ NotSoBadB2 ⊗ S ƒƒZ dA W Orchestrator
B1 ⊗ BadB2 ⊗ S ƒƒZ dA W Orchestrator
NotSoBadB2 x circularity GoodB2
S x branching condition GoodS

82. Conclusions
Section 6
Conclusions

83. Conclusions
Conclusions
The problem of specifying and verifying service-based applications has been
tackled in the thesis, with the following outcomes:
ecient model checking techniques for contract compliance;
a novel compositional formal model of service contracts with
algorithms for ensuring safety while assuming a malicious environment;
Control Theory and Linear Programming verication techniques for
distributed applications;
a linear and a non linear intuitionistic logical interpretation of
contracts;
conditions for relating two coordination mechanism: orchestration and
choreography, so reducing the communication overhead;
turn the developed theory into a prototypical tool.

84. Conclusions
Future work
Future work:
using the controller for amending detected errors;
deepening the formal verication of services through linear
programming techniques;
improving the proposed tool with a user-friendly interface, integration
with other existing tools.

85. Conclusions
Publications
International Journals:
1 Basile, D., Degano, P., Ferrari, G.L.: A formal framework for secure and complying services. The
Journal of Supercomputing 69(1), 4352 (2014);
2 Basile D. , Degano P. , Ferrari G.L. , Tuosto E.: Relating two automata-based models of
orchestration and choreography, Journal of Logical and Algebraic Methods in Programming, Volume
85, Issue 3, April 2016, Pages 425-446, ISSN 2352-2208;
3 Basile, D., Degano, P., Ferrari, G.L.: Automata for specifying and orchestrating service contracts. To
appear in Journal of Logical Methods in Computer Science (2016), ISSN: 1860-5974;
International Conferences and Workshops:
1 Basile, D.: Service interaction contracts as security policies. In: ICTCS 2012, Varese, Italy, available
online at http://ictcs.di.unimi.it/papers/paper_28.pdf;
2 Basile, D., Degano, P., Ferrari, G.L.: Secure and unfailing services. In: Malyshkin, V. (ed.) PaCT.
LNCS, vol. 7979, pp. 167181. Springer (2013);
3 Basile, D., Degano, P., Ferrari, G.L.: Automata for service contracts. In: Hot Issues in Security
Principles and Trust - 2nd Workshop, HOTSPOT 2014, Grenoble, France;
4 Basile, D., Degano, P., Ferrari, G.L.: Automata for analysing service contracts. In: Trustworthy
Global Computing - 9th International Symposium, TGC 2014. Revised Selected Papers, LNCS, vol.
8902, pp. 3450. Springer (2014);
5 Basile, D., Degano, P., Ferrari, G.L., Tuosto, E.: From orchestration to choreography through
contract automata. In: Lanese, I., Lluch-Lafuente, A., Sokolova, A., Vieira, H.T. (eds.) Proceedings
7th Interaction and Concurrency Experience 2014, Berlin, Germany. EPTCS, vol. 166,;
6 Basile, D., Degano, P., Ferrari, G.L., Tuosto, E.: Playing with our CAT and Communication-Centric
Applications. To appear in Formal Techniques for Networked and Distributed Systems (FORTE)
2016, LNCS, volume 9688, 2016.