160 likes | 256 Views
Safe composition of distributed adaptable components. Ludovic Henrio and Eric Madelaine. A distributed component model Behavioural specification and verification. Journée Composition Logicielle – Avril 2009. A DISTRIBUTED COMPONENT MODEL. Motivation.
E N D
Safe composition of distributed adaptable components Ludovic Henrio and Eric Madelaine A distributed component model Behavioural specification and verification Journée Composition Logicielle – Avril 2009
Motivation • A component model for distributed systems (GCM) • Following active objects (actors) principles • Simple to program • Verification of safe composition • Strong guarantees from • the programming model point of view (on middleware / execution) • behavioural point of view (on program instances, e.g. no dead lock) • A component model “derived” from GCM (≈ ProActive/GCM)+ A verification environment for ProActive/GCM
What are (GCM) Components? Bindings NF (server) interfaces Composite component Clientinterfaces Server interfaces Primitive component Business code Primitive component Business code GCM components are adaptable !!!
A Primitive GCM Component CI.foo(p) • Primitive components communicating by asynchronous remote method invocations on interfaces (requests) • Components abstract away distribution and concurrency • in ProActive components are mono-threaded simplifies concurrency but can create deadlocks
Composition in GCM Bindings:Requests = Asynchronous method invocations
Futures for Components f=CI.foo(p)………. f.bar() f.bar() Component are independent entities (threads are isolated in a component) + Asynchronous method invocations with results Futures are necessary
Replies … … … f=CI.foo(p) f.bar()
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
Advantages of our approach • Primitive components contain the business code • Primitive components act as the unit of distribution and concurrency (each thread is isolated in a component) • Communications follow component bindings • Hierarchy for building complex applications • Adaptable: Fractal’s introspection and reconfiguration • Futures allow communication to be asynchronous requests • Easy to program (no shared memory) • Same behaviour whatever the order of future replies • Behaviour easy to study (actor like)
One Ongoing / future work • Specification of this component model in Isabelle/HOL • Isabelle/HOL is a theorem prover • To prove properties on the component model + on protocols for managing components and execution • A first prototype specification + small proofs Next steps • Basic correctness proofs • Specification of future update strategies + proofs • More properties on dead locks, on component stop, …
First-class Futures and Hierarchy Without first-class futures, one thread is systematically blocked in the composite component.
First-class Futures and Hierarchy … … … Almost systematic dead-lock in ProActive A lot of blocked threads otherwise
Reply Strategies In ASP / ProActive, the result is insensitive to the order of replies (shown for ASP-calculus) Ongoing experiments with different strategies