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

A DISTRIBUTED COMPONENT MODEL

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

Business code

Business code

Server interfaces

ClientinterfacesPrimitive component

Primitive component

Composite component

NF (server) interfaces

GCM components are adaptable !!!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

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

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

• 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, …

BEHAVIOURAL SPECIFICATION AND VERIFICATION

First-class Futures and Hierarchy

Without first-class futures, one thread is systematically blocked in the composite component.

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

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

In ASP / ProActive, the result is insensitive to the order of replies (shown for ASP-calculus)

Ongoing experiments with different strategies