Verification of Distributed Hierarchical Components T Barros L

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

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

Software Components 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 Eric MADELAINE 3

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. 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. Eric MADELAINE 4

Fractive’s components FRACTAL : Component model specification + Pro. Active : 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 Eric MADELAINE 5

Fractal Components LIFE CYCLE BINDING CONTENT ATTRIBUTE Content Eric MADELAINE 6

Fractive : Active objects A ag = new. Active (“A”, […], Virtual. Node) V v 1 = ag. foo (param); V v 2 = ag. bar (param); . . . v 1. bar(); //Wait-By-Necessity A v 2 v 1 ag A WBN! V Java Object Active Object Future Object Proxy Eric MADELAINE Request Req. Queue Thread Wait-By-Necessity is a Dataflow Synchronization 7

Fractive example <? xml version="1. 0" encoding="ISO-8859 -1" ? > <!DOCTYPE. . > <definition name="components. System"> <component. . . </component> <component name="Alarm"> <interface name="alarm" role="server" signature="components. Alarm. Interface"/> <content class="components. Alarm"> </content> <behaviour file="Alarm. Behav" format="FC 2 Param"/> </component> <binding client="Buffer. System. alarm" server="Alarm. alarm"/> </definition> Eric MADELAINE 10

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

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 Parameterized LTS (p. LTS) & Synchronisation Network (p. Net) • 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. Eric MADELAINE 12

Abstractions and Correctness (1) Program semantics ==> Behaviour Model (parameterized) user-specified abstract interpretation (2) Behaviour Model ==> Finite Model Value Passing case : define 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 Eric MADELAINE 13

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. Pro. Active 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…. Eric MADELAINE 14

Building Fractive Behavioural Models 1) Assemble subcomponents, Buffer. Sub. System Buffer(Max, S) … Consumer(c) Alarm(m) Q_get() !B. R_get(v) Eric MADELAINE S … … R_get(v) 15

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

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

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

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

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

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 Eric MADELAINE 21

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

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 Eric MADELAINE 23

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

Verification of Properties Functional behaviour (on the Static Automaton) • Get from the buffer eventually gives an answer [ true*. Req_Get () ] X. (< true > true [ Resp_Get() ] X ) Eric MADELAINE 25

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

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. Eric MADELAINE 27

Agenda • • Context & Motivation Behaviour models Checking Properties Related Work, Conclusion & Perspectives Eric MADELAINE 28

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) Eric MADELAINE 29

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 Eric MADELAINE 30

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 Eric MADELAINE 31

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 modelchecking 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 Eric MADELAINE 32

October 2005 Eric MADELAINE 33

Portals - PSEs Application toolkit Programming environments P i R n ICENI e Cactus Sci. Run Triana Grid. CCM Ic re o XCAT Ccaffeine ic O n Net. Solve Ninf U Legion MPICH-G Grid. Lab GAT te A i l g C Services – Core Middleware T Information Monitoring us Super-schedulers b lo Legion G I MDS GRACE GRAM Nimrod-G Condor V GSI P 2 P JXTA Security E Schedulers PBS LSF OAR Grid fabric Networking OS Internet protocols Linux Windows JVMs Federated hardware resources Eric MADELAINE 34

Fractive Behavioural Models Eric MADELAINE 37

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

Previous work: Pro. Active 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 Eric MADELAINE 39

Fractive composites Eric MADELAINE 40

Properties Verification (regular -calculus) Functional Properties under reconfiguration • reconfiguration actions are allowed after deployment Eric MADELAINE 42