1. Safe composition of distributed adaptable components A distributed component model Behavioural specification and verification Ludovic Henrio and Eric Madelaine Journée Composition Logicielle – Avril 2009

2. A DISTRIBUTED COMPONENT MODEL

3. 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

4. What are (GCM) Components? Bindings Business code Server interfaces Client interfaces Primitive component Composite component NF (server) interfaces GCM components are adaptable !!!

5. 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

6. Composition in GCM Bindings: Requests = Asynchronous method invocations

7. Futures for Components f=CI.foo(p) ………. f.bar() Component are independent entities (threads are isolated in a component) + Asynchronous method invocations with results  Futures are necessary

8. Replies f=CI.foo(p) ……………… f.bar()

9. First-class Futures f=CI.foo(p) ……………… CI.foo(f) Only strict operations are blocking (access to a future) Communicating a future is not a strict operation

10. 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)

11. 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, …

12. BEHAVIOURAL SPECIFICATION AND VERIFICATION

14. First-class Futures and Hierarchy Without first-class futures, one thread is systematically blocked in the composite component.

15. First-class Futures and Hierarchy … … … Almost systematic dead-lock in ProActive A lot of blocked threads otherwise

16. Reply Strategies In ASP / ProActive, the result is insensitive to the order of replies (shown for ASP-calculus) Ongoing experiments with different strategies