Formal Models for Programming and Composing Correct Distributed Systems

1. Formal Models for Programming and Composing Correct Distributed Systems Ludovic HenrioHabilitation thesis (HDR) Jury : Gordon Blair Fabienne Boyer Eric Madelaine Pascal Poizat Michel Riveill Davide Sangiorgi Alan Schmitt OASIS Team INRIA – UNS – I3S – CNRS Sophia Antipolis

2. Agenda Introduction: Formal Methods A Distributed Component Model Behavioural Specification Dynamicity A Few Hot Topics

3. My objective Help the programmer writecorrect distributed applications, and runthemsafely. • By designinglanguages and middlewares • By provingtheirproperties • By providingtools to support the development and proof of correct programs Programming easilycorrect concurrent programs is still a challenge - ERC Bertrand Meyer: “devise a powerful, efficient and secure concurrent solution to address the needs of the programming community” Distributed programming is even more difficult, and more and more useful (cloud computing, service oriented computing …)

4. What are Formal Methods (here)? • Mathematical techniques for developping computer-based systems: • Programs • Languages • Systems • What tools? • Pen and paper (PP) • Theorem proving (TP) = proof assistant • Model checking (MC) = check a formula on (an abstraction of) all possible executions • …

5. For what? For proving properties / correctness of • Languages (ASPTP+PP, algorithmic skeletonsPP) • Programs (work on behavioural specificationMC) • Algorithms (CANTP) • Middleware (future update strategiesTP, component platformTP, fault-tolerancePP) • … • Increase the confidence people have in the system • Help my colleagues implement correct (and efficient) middlewares • Help the programmer write, compose, and run correct and efficient distributed programs

6. My general approach Implementation Programmingmodel and definitions Optimizations Generic properties Verification and tools Optimizations

7. My general approach Implementation Programming model and definitions Optimizations Generic properties Verification tools Optimizations Definitions and Properties are easy to understand definitions properties check the proofs

8. My general approach Implementation Programming model and definitions Optimizations Generic properties Verification tools Optimizations Definitions and Properties are easy to understand definitions properties

9. Agenda • Introduction: Formal Methods • A Distributed Component Model • Behavioural Specification • Dynamicity • A Few Hot Topics

10. What are Components? Primitive component Business code Client/ output Server / input

11. What are Components? Composite component Primitive component Primitive component Business code Business code • Grid Component Model (GCM) • An extension of Fractal for Distributed computing

12. But what is a Good size for a (primitive) Component? Not a strict requirement, but somehowimposed by the model design • According to CCA or SCA, a service (a component contains a provided business function) • According to Fractal, a few objects • According to GCM, a process • In GCM/ProActive, • 1 Component (data/code unit) • = 1 Active object (1 thread = unit of concurrency) = 1 Location (unit of distribution) GCM: A Grid Extension to Fractal  for Autonomous Distributed Components - F. Baude, D. Caromel, C. Dalmasso, M. Danelutto, V. Getov, L. Henrio, C. Pérez - Annals of Telecom. - 2008

13. A Primitive GCM Component CI CI.foo(p) In ProActive/GCM a primitive component is an active object • Primitive components communicating by asynchronous requests on interfaces • Components abstract away distribution and concurrency

14. Futures for Components 1 2 f=CI.foo(p)………. 3 g=f+3 g=f+3 Component are independent entities (threads are isolated in a component) + Asynchronous requests with results  Futures are necessary

15. First-class Futures … … … f=CI.foo(p) CI.foo(f) CI.foo(f) Only strict operations are blocking (access to a future) Communicating a future is not a strict operation In ProActive and ASP, futures are created and accessed implicitly (no explicit type “future”) IN contrast with Creol, Jcobox, ...

16. First-class Futures and Hierarchy return C1.foo(x) … … … Without first-class futures, one thread is systematically blocked in the composite component. A lot of blocked threads In GCM/ProActivesystematicdeadlock

17. Back to Formal Methods:a Framework for Reasoning on Components • Formalise GCM in a theorem prover (Isabelle/HOL )Component hierarchical Structure • Bindings, etc… • Design Choices • Suitable abstraction level • Suitable representation (List / Finite Set, etc …) • Basic lemmas on component structure Composite component Primitive component Business code Primitive component Business code

18. A semantics of Primitive Components • Primitive components are defined by interfaces plus an internal behaviour, they can: • emit requests • serve requests • send results • receive results (at any time) • do internal actions some rules define a correct behaviour, e.g. one can only send result for a served request

19. Communication inside Composites • Composites only delegate calls between components • Use the bindings to know where to transmit requests • Component system behaviour is expressed as a small step semantics, and specified on paper and in Isabelle/HOL A Framework for Reasoning on Component CompositionLudovic Henrio, Florian Kammüller, and Muhammad Uzair Khan - FMCO 2009, Springer

20. Future Update Strategies (Muhammad Khan) • How to bring future values to components that need them? • A “naive” approach: Any component can receive a value for a future reference it holds. • More operational is the lazy approach: require future value

21. Eager home-based future update • avoids to store future values indefinitely • Relies on future registration register future Results sent as soon as available Every component with future reference is registered Un-necessary transfers Garbage collection of computed results possible Formalised in Isabelle register future First Class Futures: Specification and Implementation of Update Strategies L. Henrio, Muhammad U. Khan, Nadia Ranaldo, Eugenio Zimeo CoreGRID@Europar 2010.

22. Properties on Future updates • Future updates remove all references to a given future • All Future references are registered during reduction Garbage collectable Complete registration register future Ludovic Henrio and Muhammad Uzair Khan “Asynchronous Components  with Futures:  Semantics and Proofs in Isabelle/HOL” - FESCA 2010 - ENTCS

23. A refined GCM model in Isabelle/HOL • More precise than GCM, give a semantics to the model: • asynchronous communications: future / requests • request queues • no shared memory between components • notion of request service • More abstract than ProActive/GCM • can be multithreaded • no active object, not particularly object-oriented A guide for implementing and proving properties of component middlewares Similarities with: SCA and Fractal (structure), Creol (futures)

24. Agenda • Introduction: Formal Methods • A Distributed Component Model • Behavioural Specification • Dynamicity • A Few Hot Topics

25. How to ensure the correct behaviour of a given program? • Theorem proving too complicated for the ProActive programmer • Our approach: behavioural specification Service methods Service methods pNets: • Trust the implementation step • Or static analysis • Generate correct (skeletons of) components (+static and/or runtime checks) Behavioural Models for Distributed Fractal Components Antonio Cansado, Ludovic Henrio, and Eric Madelaine - Annals of Telecommunications - 2008

26. 1 composite component with 2 external services Read/Write. The service requests are delegated to the Master. Use-case: Fault-tolerant storage • 1 multicast interface sendingwrite/read/commit requests to all slaves. • the slaves replyasynchronously, the master onlyneedsenoughcoherentanswers to terminate Verifying Safety of Fault-Tolerant Distributed Components Rabéa Ameur-Boulifa, Raluca Halalai, Ludovic Henrio, and Eric Madelaine - FACS 2011

27. Full picture: a pNet ?Q_Write(x) !Q_Write(b)

28. Labelled transition systems, with: Value passing Local variables Guards…. Can be written as a UML diagram Basic pNets: parameterized LTS Eric MADELAINE

29. Properties proved • Reachability(*): 1- The Read service can terminate  fid:nat among {0...2}. ∃ b:bool. <true* . {!R_Read !fid !b}> true 2- Is the BFT hypothesis respected by the model ? < true* . 'Error (NotBFT)'> true • Termination: After receiving a Q_Write(f,x) request, it is (fairly) inevitable that the Write services terminates with a R_Write(f) answer, or an Error is raised. • Functional correctness: After receiving a ?Q_Write(f1,x), and before the next ?Q_Write, a ?Q_Read requests raises a !R_Read(y) response, with y=x (*) Model Checking Language (MCL), Mateescu et al, FM’08 • Prove • generic properties like absence of deadlock • or properties specific to the application logic

30. FACS’11: GCM & multicast interfacesApplication to BFT WCSI’10: group communication FACS’08: 1st class futures CoCoME: hier. & synch. pNets: 2004-2008 Recent advances in behavioural specification for GCM • Scaling-up : gained orders of magnitude by a combination of: • data abstraction, • compositional and contextual minimization, • distributed state-space generation. • Specified formally the whole generation process (in progress) More to come ? Reconfiguration...

31. Agenda • Introduction: Formal Methods • A Distributed Component Model • Behavioural Specification • Dynamicity • A Few Hot Topics

32. Adaptation in the GCM • Functional adaptation: adapt the architecture + behaviour of the application to new requirements/objectives • Non-functional adaptation(Paul Naoumenko): adapt the architecture of the container+middleware to changing environment/NF requirements (QoS …) Additional support for reconfiguration(Marcela Rivera): • A stopping algorithm for GCM components • A Scripting language for reconfiguring distributed components Both functional and non-functional adaptation are expressed as reconfigurations Language support for distributed reconfiguration: GCM-script A platform for designing and running autonomic components A Component Platform for Experimenting with Autonomic CompositionFrançoise Baude, Ludovic Henrio, and Paul Naoumenko. Autonomics 2007.

33. Formalising Reconfiguration (preliminary) • In our Isabelle/HOL model component structure known at runtime • Two reconfiguration primitives formalised (remove and replace) • Illustrates the flexibility of the approach • Basic proofs • In our pNets model • Old results (Tomas): start/stop/bind for Fractal components • Concerning GCM: formalisation and experiments in progress

34. Agenda • Introduction: Formal Methods • A Distributed Component Model • Behavioural Specification • Dynamicity • A Few Hot Topics

35. Correct component reconfigurationTowards safety and autonomicity • Verify reconfiguration procedures (Nuno Gaspar) • Safe adaptation procedures as a solid ground for autonomic applications • Some directions: • Parameterized topologies: ADL[N] ; behavioural specification (pNets) ; reconfiguration primitives (Alexandra Savu) • Use of theorem proving + prove equivalence between the Isabelle GCM model and the behavioural specification prove and use generic properties of reconfiguration procedures

36. Correct component reconfigurationTowards safety and autonomicity • Verify reconfiguration procedures (Nuno Gaspar) • Safe adaptation procedures as a solid ground for autonomic applications • Some directions: • Parameterized topologies: ADL[N] ; behavioural specification (pNets) ; reconfiguration primitives (Alexandra Savu) • Use of theorem proving + prove equivalence between the Isabelle GCM model and the behavioural specification prove and use generic properties of reconfiguration procedures [N]

37. Multi-active objects • Mono-threaded active objects have limitations: • Deadlocks • Inadapted to multicore architecture (no shared memory) • Solutions in the active-object community: • Jcobox: « cooperative multithreading », only one thread active at a time (release points) • JAC: Java annotations for Concurrency – real multithreading, not distributed • Our proposal, a programming model that mixes local parallelism and distribution with high-level programming constructs Adapting Active Objects to Multicore Architectures - Ludovic Henrio, Fabrice Huet, Zsolt István, and Gheorghen Sebestyén - ISPDC 2011

38. Primitive GCM Component foo() { … CI.foo(p) }

39. Primitive Multi-Active GCM Component join() Providedadd, add and monitor are compatible add() { … … } monitor(){… … } add() { CI.foo(p) }

40. Proposal – Annotation Example • Groups • (Collection of related methods) • Rules • (Compatibility relationships between groups) Memberships (To which group each method belongs)

41. Results / Status • Implemented multi-active objects above ProActive • Added dynamic compatibility rules • Used on case studies (NAS, CAN) • Specified the semantics of Multi-ASP • Proved first properties, i.e., the semantics guarantees that two requests executed in parallel are compatible • Next steps: • Publish the model • Formalisation in Isabelle/HOL • Use the new model • Prove stronger properties (confluence?)

42. CAN dissemination algorithm(Francesco Bongiovani) • CANs are P2P networks organised in a cartesianspace of N-dimensions (used for RDF data-storage) • Objective: disseminateefficiently information (no duplicate) • Designed an efficient algorithm (tested) • Proved the existence of anefficient broadcast in Isabelle Nextsteps: • Prove the designedalgorithmis efficient • Conduct large-scaleexperiments • Studychurns K K E E G G F C D D H H C F A B I I B J J Mechanical Support for Efficient Dissemination on the CAN Overlay Network - Francesco Bongiovanni, and Ludovic Henrio - CFSE 2011

43. What I could not fit in this talk • ASP: Active object calculus • ASPfun a functional variant formalised in Isabelle (typing) • Fault tolerance (Christian Delbé) and garbage collection (Guillame Chazarain) for active objects • Work on behavioural skeletons (typing and exceptions) (Mario Leyton) • JDC: a language for specifying behaviour of components (Antonio Cansado) • Details on the behavioural specification of components and active objects (first-class futures, …) And of course, a lot of inference rules and greek letters …

44. THANK YOU ! Special thanks to the people I worked with, mainly: Florian Kammueller Marcela Rivera ZsoltIstvan Boutheina Bannour Tomas Barros FabriceHuet Muhammad Khan Christian Delbé Francesco Bongiovani Françoise Baude Guillaume Chazarain Bernard Serpette Mario Leyton Denis Caromel Paul Naoumenko Antonio Cansado Eric Madelaine CoreGrid partners Rabéa Boulifa And others !!!

46. Primitive Components in Isabelle • Primitive components are defined by interfaces plus an internal behaviour, they can: • emit requests • serve requests • send results • receive results (at any time) • do internal actions some rules define a correct behaviour, e.g. one can only send result for a served request • We define the behaviour of the whole components as small-step operational semantics A Framework for Reasoning on Component CompositionLudovic Henrio, Florian Kammüller, and Muhammad Uzair Khan - FMCO 2009, Springer

47. Non-functional Component Structure • Non-functional aspects as a composition of components (inside a membrane) • A component structure for the membrane • New kind of interfaces and bindings • An API for reconfiguring the membrane • Non-functional code is • components or objects • distributed or not • Towards autonomiccomponents A Component Platform for Experimenting with Autonomic CompositionFrançoise Baude, Ludovic Henrio, and Paul Naoumenko. Autonomics 2007.

48. Triggering Distributed Reconfigurations in the Scripting Language • Fscript is a language to reconfigure Fractal components • A primitive for the distributed script interpretation • + other minor extensions remote_call(target_component, action_name, parameters, ...); Reconfiguration interface action(arguments) Interpreter target_component

49. Example Reconfiguration interface RC 2 definition action1 ... remote_call(C2,’action2’) remote_call(C11,’action11’) remote_call(C12,’action12’) ... Reconfiguration scripts C2 definition action12 ... remote_call(C121,’action121’) ... RC 1 Interpreter Membrane RC 12 RC 11 C11 RC 121

50. Example Reconfiguration interface RC 2 definition action1 ... remote_call(C2,’action2’) remote_call(C11,’action11’) remote_call(C12,’action12’) ... Reconfiguration scripts C2 action1( ) definition action12 ... remote_call(C121,’action121’) ... RC 1 Interpreter Membrane RC 12 RC 11 C11 RC 121 C121 C12