1 / 16

Safe composition of distributed adaptable components

This paper presents a distributed component model focusing on the safe composition of adaptable components, inspired by the principles of active objects. It discusses the advantages of this approach, including simplicity in programming and strong guarantees regarding behavior and verification. By utilizing First-class Futures and a hierarchical structure, the model allows for effective management of distribution and concurrency, thereby reducing the risk of deadlocks. The specification is formalized in Isabelle/HOL, providing a foundation for correctness proofs and ongoing experimentation with update strategies.

jasia
Télécharger la présentation

Safe composition of distributed adaptable components

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  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 NF (server) interfaces Composite component Clientinterfaces Server interfaces Primitive component Business code Primitive component Business code 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() 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) 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

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

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

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

More Related