1. Eric MADELAINE1 T. Barros, L. Henrio, E. Madelaine OASIS Team, INRIA -- CNRS - I3S -- Univ. of Nice Sophia-Antipolis (FACS’05), Fractal workshop, Grenoble 29 nov 2005 Verification of Distributed Hierarchical Components

2. Eric MADELAINE2 Context Components and safe composition Fractive Building Behaviour models Formal Model Configuration and Introspection Asynchrony Checking Properties Conclusion & Perspectives Agenda

3. Eric MADELAINE3 Definition : Software modules, composable, with well-defined interfaces, and well-defined black box behaviour Our interests : 1. Encapsulation Black boxes, offered and required services 2. Composition Design of complex systems, hierarchical organization into sub-systems 3. Separate administration Architecture Description Language (ADL), administration components 4. Distribution (e.g. Computational Grid) Interaction at interfaces through asynchronous method calls Software Components

4. Eric MADELAINE4 Applications : Build complex systems from off-the-shelf components Check behavioural compatibility between sub-components Check correctness of component deployment and behaviour Check correctness of the transformation inside a running application. Behaviour specification and Safe composition Aim : Build reliable components from the composition of smaller pieces, using their formal specification. Component paradigm : only observe activity at interfaces. Behavioural properties: Deadlock freeness, progress/termination, safety and liveness.

5. Eric MADELAINE5 Fractive’s components FRACTAL : Component model specification + ProActive : Java library for distributed applications = Fractive Features: Hierarchical Component Model ADL description (Fractal’s XML Schema/DTD) Separation of functionality / management Distributed components (from distributed objects) Asynchronous computation (non-blocking method calls) Strong Formal Semantics (ASP) => properties and guarantees

6. Eric MADELAINE6 ATTRIBUTEBINDINGLIFE CYCLECONTENT Content Fractal Components

7. Eric MADELAINE7 A Fractive : Active objects Proxy Java Object A ag = newActive (“A”, […], VirtualNode) V v1 = ag.foo (param); V v2 = ag.bar (param);... v1.bar(); //Wait-By-Necessity V Wait-By-Necessity is a Dataflow Synchronization A Active Object Future Object Request Req. Queue Thread v1 v2 ag WBN!

8. Eric MADELAINE8 Wait-By-Necessity: First Class Futures ba Futures are Global Single-Assignment Variables V= b.bar () c c c.gee (V) v v b

9. Eric MADELAINE9 getA() getB() getAandB()getA() getB() getAandB() getB() getA()getAandB() First-Class Futures and Components Asynchronous method calls with full-fledge Wait-By-Necessity Non-blocking method calls value of A value of B Compositions are not blocked with Asynchrony + WbN

10. Eric MADELAINE10 Fractive example <interface name="alarm" role="server" signature="components.AlarmInterface"/> <behaviour file="AlarmBehav" format="FC2Param"/> <binding client="BufferSystem.alarm" server="Alarm.alarm"/> <interface name="alarm" role="server" signature="components.AlarmInterface"/> <behaviour file="AlarmBehav" format="FC2Param"/> <binding client="BufferSystem.alarm" server="Alarm.alarm"/>

11. Eric MADELAINE11 Context & Motivation Building Behaviour Models Formal Model Configuration and Introspection Asynchrony Checking Properties Conclusion & Perspectives Agenda

12. Eric MADELAINE12 Parameterized LTS (pLTS) & Synchronisation Network (pNet) Parameters for value passing and indexed processes Extension of Lin’s symbolic graphs with assignments and Arnold’s synchronisation networks. Simple Types : Integers, Intervals, Enumerations, Records. Behaviour: Parameterized Networks of synchronised Transitions Systems T. Barros, R. Boulifa, E. Madelaine: Parameterized Models for Distributed Java Objects, Forte'2004 Conference, Madrid, Sep. 2004, LNCS 3235, © Springer-Verlag

13. Eric MADELAINE13 (1) Program semantics ==> Behaviour Model (parameterized) user-specified abstract interpretation (2) Behaviour Model ==> Finite Model Value Passing case : d efine an abstract representation from a finite partition of the value domains, on a per-formula basis  Preservation of safety and liveness properties [Cleaveland & Riely 93] Families of Processes : no similar generic result (but many results for specific topologies). Counter-example : on parameterized topologies of processes, reachability properties require induction reasoning. Practical approach : explore small finite configurations in a “bug search” fashion, use “infinite systems” techniques for decidable domains when available Abstractions and Correctness

14. Eric MADELAINE14 Fractive Behavioural Models : Principles Compositionality Reasonning at each separate composition level Functional behaviour is known Given by the user Obtained by static analysis (primitive components, e.g. ProActive active objects) Computed from lower level Non functional behaviour automatically added from the component’s ADL Automata within a synchronisation network Incorporate controllers for management interfaces, and for asynchronous communication management Build the product, Hide, Minimize….

15. Eric MADELAINE15 Building Fractive Behavioural Models 1)Assemble sub- components, Buffer(Max,S) !B.Q_get() !B.R_get(v) Consumer(c) … … … S Q_get() R_get(v) Alarm(m) BufferSubSystem

16. Eric MADELAINE16 Building Fractive Behavioural Models 1)Assemble sub- components 2)add non-functional controls: 1)Bindings C(c) B Q_get() R_get(v) ?bind(B,IA) ?unbind(B,IA) !Err(unbound,B,IA) P(p) Q_put(x) B.Alarm() BSS.Alarm() ?bind(B,IF) ?unbind(B,IF) unbound bound

17. Eric MADELAINE17 Building Fractive Behavioural Models 1)Assemble sub- components 2)add non-functional controls: 1)Bindings B ?bind(…) ?unbind(…) !Err(unbound,…) B.Alarm() P(p) C(c)

18. Eric MADELAINE18 Building Fractive Behavioural Models 1)Assemble sub- components 2)add non-functional controls: 1)Bindings 2)Start/Stop B ?bind(…) ?unbind(…) !Err(unbound,…) B.Alarm() P(p) C(c) !start() !stop()

19. Eric MADELAINE19 Building Fractive Behavioural Models 1)Assemble sub- components 2)add non-functional controls: 1)Bindings 2)Start/Stop 3)Add Interceptor : 1)Body C(c) B !Err(unbound,…) P(p) !start() !stop() Body ?Serve start/stop ?Serve bind/unbind ?Serve(M,fut,args) !fut.call(M,args) !bind/unbind !start/stop ?bind(…) ?unbind(…)

20. Eric MADELAINE20 Building Fractive Behavioural Models 1)Assemble sub- components 2)add non-functional controls: 1)Bindings 2)Start/Stop 3)Add Interceptor : 1)Body 2)Queue, LF and proxies = Controller Body Proxy (fut) Queue ?Serve(M,…) Call(M,…) LF Response… Request… C(c) B !Err(unbound,…) P(p) !start() !stop() ?bind(…) ?unbind(…)

21. Eric MADELAINE21 Result : The Static Automaton Deployment Automaton : Static Automaton = ( Controller || Deployment ) + hiding & minimisation Fine Tuning = Specify different hiding sets, depending on the properties we want to prove: deployment phase functional phase topology-preserving transformations

22. Eric MADELAINE22 Context & Motivation Behaviour models Checking Properties Functional and management interactions Conclusion & Perspectives Agenda

23. Eric MADELAINE23 Behaviour correctness (from the user point of view) Initial Composition Generic properties : successful deployment, absence of errors, deadlock freeness User Requirements expressed as temporal formulas Reconfiguration preserving the network structure Preservation of properties (aka service interaction) New features Compositionality The Static Automaton, after hiding/minimization, is the functional behaviour used at next level of composition

24. Eric MADELAINE24 Deployment (on the Static Automaton with successful synchronisation visible) The deployment is always successful [ (not √ )* ] true No Error during deployment [ (not √ ) *. O E ] false Verification of Properties regular μ-calculus (Mateescu’2004) e.g. start Buffer without linking the alarm interface

25. Eric MADELAINE25 Functional behaviour (on the Static Automaton) Get from the buffer eventually gives an answer Verification of Properties [ true*.Req_Get () ]  X. ( true  [  Resp_Get() ] X )

26. Eric MADELAINE26 Functional properties under reconfiguration (respecting the topology) Future update (asynchronous result messages) independent of life-cycle or binding reconfigurations E.g: Proved on an Extended Static Automaton allowing the following control operations: Verification of Properties [ true*.Req_Get() ]  X. ( true  [  Resp_Get() ] X )

27. Eric MADELAINE27 Structural Transformations (ongoing work) Scenario : Running application, Need to Replace/Update one sub-component Check the protocol compatibility before replacement Principle : Use the formal Behaviour Specification Identify states of the application behaviour model in which the transformation is possible, … compute the corresponding states after transformation. Use the merged automaton to check properties. Benefits : Identifies prerequisite and rules for safe transformation.

28. Eric MADELAINE28 Context & Motivation Behaviour models Checking Properties Related Work, Conclusion & Perspectives Agenda

29. Eric MADELAINE29 Related Work From Process Algebras to Components Semantics : LTSs, congruences, refinement Processes, Connectors, and CSP refinement : Wright Hierarchical components, weak bisimulation, Buchi automata : Darwin Semantics of encapsulation : Kell calculus Sofa Frame (spec) vs. Architecture (implementation) compliance relation based on traces Hierarchical construction through parallel composition, with error detection Behavioural Contracts (e.g. Carrez et al.) Interface behavioural-type compatibility (decidable) Component contract compliance (non decidable) No other work to our knowledge dealing with functionality + management (even in the synchronous case)

30. Eric MADELAINE30 Vercors Platform Tool set : Code analysis(prototype, partial) Model generation (prototype, soon available) Interactions with model-checking and verification tools (available) Supported by FIACRE An ACI-Security action of the French research ministry

31. Eric MADELAINE31 Ongoing work Expression of Properties : Pattern language specific to Grid Application Extensions : Group communication Perspectives New verification tools (infinite state classes) “Safe by construction” programming style

32. Eric MADELAINE32 Conclusions Model for the behaviour of distributed hierarchical components Automatic Construction of the control parts Verification of properties in different phases Implementation of a prototype tool for model construction, using standard model- checking tools Asynchrony is essential for large scale grid applications (hide the latency, fewer deadlocks), but brings in new difficulties (at developer level). Papers, Use-cases and Tools at : http://www-sop.inria.fr/oasis/Vercors

33. Eric MADELAINE33 October 2005

34. Eric MADELAINE34 Portals - PSEs Programming environments Schedulers Networking OS Information Monitoring Super-schedulers Security P2P Cactus SciRun Triana MPICH-G GridLab GAT XCAT Ccaffeine NetSolve Ninf ICENI Internet protocols PBS LSF OAR GRAM GSI MDS JXTA Linux Windows JVMs Legion GRACE Nimrod-G Condor GridCCM Grid fabric Services – Core Middleware Application toolkit Federated hardware resources Globus Iceni Unicore glite PROACTIVEPROACTIVE

35. Eric MADELAINE35 Fractive’s implementation choices Hierarchical start/stop While stopped only non-functional request are served. No path between functional and non-functional interfaces

36. Eric MADELAINE36 ProActive and (De Facto) Standards RMI, RMI-Ibis, Jini, HTTP rsh, ssh, scp Globus GTx, sshGSI, Unicore, EGEE gLite LSF, PBS, OAR, Sun Grid Engine Fractal Components Web Services OSGi

37. Eric MADELAINE37 Fractive Behavioural Models

38. Eric MADELAINE38 Fractive implementation Primitive component => Active object Composite membrane => Active object

39. Eric MADELAINE39 Previous work: ProActive behavioural models (presented at Forte 2004) T. Barros, R. Boulifa, E. Madelaine: Parameterized Models for Distributed Java Objects, Forte'2004 Conference, Madrid, Sep. 2004, LNCS 3235, © Springer-Verlag

40. Eric MADELAINE40 Fractive composites

41. Eric MADELAINE41 3) Membrane for primitive Asynchronous components = request queues, future proxies 4) … and also for composites components

42. Eric MADELAINE42 Functional Properties under reconfiguration reconfiguration actions are allowed after deployment Properties Verification (regular  -calculus)

43. Eric MADELAINE43 Structural Transformations Controller of the new structure Action mapping Identify states in the original controller where transformation is possible (set T ) “Connect” both controllers from T through the transformation  ( T’ is the image of  ) The new behaviour is the reachable parts from T’ (using the action mapping)

44. Eric MADELAINE44 Structural transformations No errors during functional phase Synchronous former example B2