Upload
jasia
View
40
Download
1
Embed Size (px)
DESCRIPTION
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. - PowerPoint PPT Presentation
Citation preview
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