1 / 70

A Theory of Distributed Objects Toward a Foundation for Component Grid Platforms Ludovic HENRIO

A Theory of Distributed Objects Toward a Foundation for Component Grid Platforms Ludovic HENRIO. University of Westminster. A Theory of Distributed Objects Components Perspectives. A Theory of Distributed Objects: Contents. Review ASP Calculus Semantics and Properties

braima
Télécharger la présentation

A Theory of Distributed Objects Toward a Foundation for Component Grid Platforms Ludovic HENRIO

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. A Theory of Distributed ObjectsToward a Foundation for Component Grid PlatformsLudovic HENRIO University of Westminster A Theory of Distributed Objects Components Perspectives

  2. A Theory of Distributed Objects: Contents • Review • ASP Calculus • Semantics and Properties • A Few More Features • Implementation Strategies • Final Words

  3. Contents • A Theory of Distributed Objects (I) • 1 – ASP (II, III) • 2 - Confluence and Determinacy (III) • 3 - More Features: Groups (IV) • 4 – Implementation Strategies: Future Updates (V, VI) • Components (IV) • Perspectives (VI and beyond)

  4. Review (informal classification of calculi) Part I

  5. Contents • A Theory of Distributed Objects • 1 - ASP • 2 - Confluence and Determinacy • 3 - More Features: Groups • 4 – Implementation Strategies: Future Updates • Components • Perspectives

  6. Asynchronous and Deterministic Objects • ASP: Asynchronous Sequential Processes • Distributed objects • Asynchronous method calls • Futures and Wait-by-necessity • Determinism properties Part II A Theory of Distributed Objects

  7. a b foo f2 f1 foo g d f3 Structure Active(a) Part II 1- ASP

  8. Sending Requests ( REQUEST ) a b beta.foo(b) foo result=beta.foo(b) Part II, III 1- ASP

  9. result Sending Requests ( REQUEST ) a b beta.foo(b) foo result=beta.foo(b) Part II, III 1- ASP

  10. result Serving Requests ( SERVE ) a b Serve(foo);... beta.foo(b) bar foo Serve(foo);... Part II, III 1- ASP

  11. result foo ... foo Serving Requests ( SERVE ) a b Serve(foo) beta.foo(b) bar Serve(foo);... Part II, III 1- ASP

  12. Sending Results ( REPLY ) a b foo Part II, III 1- ASP

  13. Sending Results ( REPLY ) a b foo Part II, III 1- ASP

  14. ASP Syntax : Source Terms • Imperative V-calculus • ASP parallelism primitives Part II 1- ASP

  15. Service Local Creating an Activity Sending a Request Sending a Reply Part III 1- ASP

  16. Wait-by-necessity a b delta.send(result) d Part II, III 1- ASP

  17. result.bar() Wait-by-necessity a b delta.send(result) result.bar() d Part II, III 1- ASP

  18. result.bar() Wait-by-necessity a b delta.send(result) result.bar() d Part II, III 1- ASP

  19. Wait-by-necessity a b Futures updates can occur at any time result.bar() d Part II, III 1- ASP

  20. Contents • A Theory of Distributed Objects • 1 - ASP • 2 - Confluence and Determinacy • 3 - More Features: Groups • 4 – Implementation Strategies: Future Updates • Components • Perspectives

  21. a f1 b g f2 Equivalence Modulo Futures Updates a f1 b g f2 f3 Part III 2 - Confluence and Determinacy

  22. f1 f1 Equivalence Modulo Future Updates a a f2 f1 b g b g f2 f3 Part III 2 - Confluence and Determinacy

  23. g b a delta.foo() Compatibility Serves the oldest request on foo OR bar bar d …. Serve(foo,bar) … Serve(foo,gee) foo gee Part III 2 - Confluence and Determinacy

  24. P0 P Q R Confluence • Potential services: …. Serve(foo,bar) … Serve(foo,gee) {foo,bar}, {foo,gee} Part III 2 - Confluence and Determinacy

  25. P0 P Q R Confluence • Potential services: {foo,bar}, {foo,gee} • RSL definition: foo, bar, bar, gee Part III 2 - Confluence and Determinacy

  26. P0 P Q R • RSL definition: Confluence • Potential services: {foo,bar}, {foo,gee} foo, bar, bar, gee • Configuration Compatibility: foo, bar, bar, gee foo, bar, bar, gee foo, bar, bar, gee foo, bar,gee, bar foo, bar, gee, bar foo, bar, gee, bar Part III 2 - Confluence and Determinacy

  27. P0 P Q R • RSL definition: • Configuration Compatibility: Confluence • Potential services: Execution characterized by the order of request senders Compatibility  Confluence Part III 2 - Confluence and Determinacy

  28. delta.gee(a) bar delta.bar(a) gee DON(P): Deterministic Object Networks g b d {foo,bar} , {foo,gee} {bar,gee} , {foo} gee bar bar gee Part III 2 - Confluence and Determinacy

  29. g {gee}, {f,g} Static DON a d f {foo,bar} , {gee} {gee}, {f,g} {foo,bar} , {gee} {f,g} g g g foo f {foo,bar} , {gee} {foo}, {bar} bar f e b {gee}, {f,g} {bar} , {gee} {gee}, {f,g} gee Part III 2 - Confluence and Determinacy

  30. ASP: Summary and Results • An Asynchronous Object Calculus: • Structured asynchronous activities • Structured communications with futures • Data-driven synchronization • ASP Confluence and Determinacy • Future updates can occur at any time • Execution characterized by the order of request senders • Determinacy of programs communicating over trees, … Part III 2 - Confluence and Determinacy

  31. Contents • A Theory of Distributed Objects • 1 - ASP • 2 - Confluence and Determinacy • 3 - More Features: Groups • 4 – Implementation Strategies: Future Updates • Components • Perspectives

  32. ASP Extensions • Group communications • Formalization, • Atomicity and relations to determinacy. • Migration • Optimization and confluence issues • Components • Others: non-blocking services, join patterns, delegation ... Part IV 3 – More Features

  33. a Group.foo() Groups of Active Objects Part IV 3 – More Features

  34. a Group.foo() Groups of Active Objects g1 foo g2 result foo g3 foo Part IV 3 – More Features

  35. a Group.foo() Groups of Active Objects g1 foo bar g2 bar foo b g3 Group.bar() bar foo Part IV 3 – More Features

  36. a Group.foo() Groups of Active Objects: Atomic Communications g1 foo bar Some programs become deterministic with atomic group communications g2 foo bar b g3 Group.bar() foo bar Part IV 3 – More Features

  37. Contents • A Theory of Distributed Objects • 1 - ASP • 2 - Confluence and Determinacy • 3 - More Features: Groups • 4 – Implementation Strategies: Future Updates • Components • Perspectives

  38. Implementation Strategies • ProActive • Future Update Strategies • Futures are first class and can be returned at any time • Lazy / Forward-based / Message-based. • Loosing Rendez-Vous • Ensuring causal ordering with one-to-all FIFO ordering • Comparison with other strategies, e.g. point-to-point FIFO • Controlling Pipelining Part V 4 – Implementation Strategies

  39. SMP LAN Clusters ProActive:A Java API + Tools for the GRID Parallel, Distributed, Mobile, Activities, across the world ! Desktop • Model: • Remote Mobile Objects • Asynchronous Communications with automatic Futures • Group Communications, Migration, NF Exceptions • Environment: • XML Deployment, dynamic class-loading • Various protocols: rsh,ssh,LSF,Globus, BPS, ... • Graphical Visualization and monitoring: IC2D Part V 4 – Implementation Strategies

  40. Future Update Strategies: No partial replies and request a b delta.send(result) d Part V 4 – Implementation Strategies

  41. result.bar() Future Update Strategies a b delta.send(result) result.bar() d g Part V 4 – Implementation Strategies

  42. Future Update Strategies: Message-based a b delta.send(result) result.bar() result.bar() d Future Forwarded Messages g Part V 4 – Implementation Strategies

  43. Future Update Strategies: Forward-based a b delta.send(result) result.bar() result.bar() d g Part V 4 – Implementation Strategies

  44. Future Update Strategies: Lazy Future Updates a b delta.send(result) result.bar() result.bar() d g Part V 4 – Implementation Strategies

  45. Future Updates Summary • Mixed strategies are possible • All strategies are equivalent(modulo dead-locks) Part V, VI 4 – Implementation Strategies

  46. Overview of Implementation Strategies: Queues, Buffering, Pipelining, and Strategies • Perspectives: • Organize and synchronize implementation strategies • Design a global adaptative evaluation strategy Part VI 4 – Implementation Strategies

  47. Contents • A Theory of Distributed Objects • 1 - ASP • 2 - Confluence and Determinacy • 3 - More Features: Groups • 4 – Implementation Strategies: Future Updates • Components • Perspectives

  48. Context • Fractal: a component model specification • An implementation in ProActive • Hierarchical composition • Asynchronous, distributed components • Non-functional aspects and lifecycle • Formal aspects • Kell calculus → component control (passivation) • ASP components→ Hierarchical aspects and deterministic components Part IV Components

  49. Components from ASP Terms: Primitive Components • Server Interface = potential service • Client Interface = reference to an active object Part IV Components

  50. Hierarchical Composition Composite component Primitive component PC Export Export Output interfaces Binding Asynchronous method calls Input interfaces CC PC PC Part IV Components

More Related