Specification and Verification of Contract-based Applications
1 like162 views
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.
![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)](https://image.slidesharecdn.com/slides-161005141155/85/Specification-and-Verification-of-Contract-based-Applications-64-320.jpg)
Specification and Verification of Contract-based Applications
- 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
- 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.