1 / 76

ASP Theory of Distributed Objects: Calculus and Components

Explore the theory of distributed objects through ASP calculus and components, covering asynchronous processes, determinism, and implementation constraints. Learn about confluence, determinacy, and deterministic components.

aharrell
Télécharger la présentation

ASP Theory of Distributed Objects: Calculus and 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. 2. CALCULUS: • A S P

  2. THEORY A Theory of Distributed ObjectsD. Caromel, L. Henrio, Springer 2005, Monograph A Calculus: ASP: Asynchronous Sequential Processes Based on Sigma-Calculus (Abadi-Cardelli) Formal Proofs of determinism Releases a few important implementation constraints

  3. -calculus

  4. Why calculi? Prove properties on languages, typing Programs (equivalence), execution strategies, …

  5. Review (informal classification of calculi)

  6. Asynchronous and Deterministic Objects • ASP: Asynchronous Sequential Processes • Distributed objects • Asynchronous method calls ( towards components) • Futures and Wait-by-necessity • Determinism properties A Theory of Distributed Objects

  7. ASP Syntax : Source Terms • Imperative V-calculus • ASP parallelism primitives 1- ASP

  8. Service Local Creating an Activity Sending a Request Sending a Reply 1- ASP

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

  10. Sending Requests ( REQUEST ) a b beta.foo(b) foo result=beta.foo(b) 1- ASP

  11. result Sending Requests ( REQUEST ) a b beta.foo(b) foo result=beta.foo(b) 1- ASP

  12. Wait-by-necessity a b delta.send(result) d 1- ASP

  13. result.bar() Wait-by-necessity a b delta.send(result) result.bar() d 1- ASP

  14. result.bar() Wait-by-necessity a b delta.send(result) result.bar() d 1- ASP

  15. Wait-by-necessity a b Futures updates can occur at any time result.bar() d 1- ASP

  16. Confluence and Determinacy

  17. b Store Partitioning

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

  19. ASP theory: Summary and Results • ASP Confluence and Determinacy • Proved Properties: • Future updates can occur at any time, in any order • Asynchronous FIFO point-to-point is enough for Requests • Execution characterized by the order of request senders • Applications: • Determinacy of programs based on a dynamic property: DON • Determinacy of programs communicating over Trees, • SDON, and Deterministic Components, …

  20. 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 The difficulty is to staticallyapproximate activities, method calls and potential services {bar} , {gee} {gee}, {f,g} {gee}, {f,g} gee

  21. From 2. to 3.:CALCLUS to COMPONENTS Components in ASP • Objective: Deterministic Components

  22. Controller Content Using the Fractal model:Hierarchical Component Defined by E. Bruneton, T. Coupaye, J.B. Stefani, INRIA & FT

  23. Controller Content Hierarchical model : Composites encapsulate Primitives, Primitives encapsulate Code

  24. Controller Content Binding = in an external file (XML ADL), Not in programs

  25. Controller Content Binding = in an external file (XML ADL), Not in programs

  26. Context and Challenge - Asynchronous, - Distributed components, yet  Deterministic Components

  27. Method names Fields Primitive Components Requests A Primitive Component Requests Server Interfaces Client Interfaces

  28. Hierarchical Composition Composite component Primitive component PC Export Export Output interfaces Binding Asynchronous method calls Input interfaces CC PC PC

  29. eC is a function yis a function Invalid composition Interface exported twice Output plugged twice es is a function Except with group communication …

  30. Valid Compositions Output interfaces Non-confluent Input interfaces Non-confluent Non-confluent

  31. Valid Compositions Output interfaces Input interfaces

  32. Semantics: “Static” Translation to ASP Output interfaces Input interfaces

  33. Semantics: “Dynamic” Translation to ASP Output interfaces Input interfaces

  34. Deterministic Primitive Component • Requirement on potential services: Each Potential service isentirely included in a single SI A Primitive Component Serve(M)

  35. Deterministic Composition (SDON) Each SI is only used once, either bound or exported: Non-confluent Non-confluent Non-confluent

  36. Component Model: Summary and Results • A definition of components • Coarse grain components (activities) • Convenient abstraction for distribution and Concurrency: Primitive components as an abstraction for activities • Structured asynchronous communicationsRequests = Asynchronous method calls • Well defined interfaces: served methods • Semantics as translations to ASP • First class futures inherited from ASP • Specification of deterministic components: • Deterministic primitive components • Deterministic composition of components Components provide a convenient abstractionfor statically ensuring determinism

  37. Towards Parallel and Deterministic Components Groups in ASP

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

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

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

  41. 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 Non Det. Prog.  Det. Prog. with Groups Group.bar() foo bar

  42. 3. Distributed Component Specification Cp. in Practice GCM: Grid Component Model

  43. GCM Components • GCM: Grid Component Model • GCM Being defined in the NoE CoreGRID • (42 institutions) • Open Source ObjectWebProActive implements a preliminary version of GCM • GridCOMP takes: • GCM as a first specification, • ProActive as a starting point, and Open Source reference implementation. Scopes and Objectives: - Grid Codes that Compose and Deploy - No programming, No Scripting, … No Pain The vision: GCM to be the GRID GSM for Europe

  44. Collective Interfaces

  45. Collective Interfaces • Simplify the design and configuration of component systems • Expose the collective nature of interfaces • Cardinality attribute • Multicast, Gathercast, gather-multicast • The framework handles collective behaviour • at the level of the interface • Based on Fractal API : • Dedicated controller • Interface typing  Verifications

  46. Multicast interfaces • Transform a single invocation into a list of invocations • Multiple invocations • Parallelism • Asynchronism • Dispatch • Data redistribution (invocation parameters) • Parameterisable distribution function • Broadcast, scattering • Dynamic redistribution (dynamic dispatch) • Result = list of results

  47. Multicast interfaces Results as lists of results Invocation parameters may also be distributed from lists

  48. Transform a list of invocations into a single invocation Synchronization of incoming invocations ~ “join” invocations Timeout / Drop policy Bidirectional Bindings (callers  callee) Data gathering Aggregation of parameters into lists Result: redistribution of results Redistribution function Gathercast interfaces

  49. Virtual Nodes • Permits a program to generate automatically a deployment plan: find the appropriate nodes on which processes should be launched. • In the future, we envisage the adjunction of more sophisticated descriptions of the application needs with respect to the execution platform: topology, QoS, …

More Related