760 likes | 922 Views
2. CALCULUS:. A S P. THEORY. A Theory of Distributed Objects D. Caromel, L. Henrio, Springer 2005, Monograph. A Calculus: ASP: Asynchronous Sequential Processes Based on Sigma-Calculus ( Abadi-Cardelli ) Formal Proofs of determinism
E N D
2. CALCULUS: • A S P
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
Why calculi? Prove properties on languages, typing Programs (equivalence), execution strategies, …
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
ASP Syntax : Source Terms • Imperative V-calculus • ASP parallelism primitives 1- ASP
Service Local Creating an Activity Sending a Request Sending a Reply 1- ASP
a b foo f2 f1 foo g d f3 Structure Active(a) 1- ASP
Sending Requests ( REQUEST ) a b beta.foo(b) foo result=beta.foo(b) 1- ASP
result Sending Requests ( REQUEST ) a b beta.foo(b) foo result=beta.foo(b) 1- ASP
Wait-by-necessity a b delta.send(result) d 1- ASP
result.bar() Wait-by-necessity a b delta.send(result) result.bar() d 1- ASP
result.bar() Wait-by-necessity a b delta.send(result) result.bar() d 1- ASP
Wait-by-necessity a b Futures updates can occur at any time result.bar() d 1- ASP
b Store Partitioning
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
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, …
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
From 2. to 3.:CALCLUS to COMPONENTS Components in ASP • Objective: Deterministic Components
Controller Content Using the Fractal model:Hierarchical Component Defined by E. Bruneton, T. Coupaye, J.B. Stefani, INRIA & FT
Controller Content Hierarchical model : Composites encapsulate Primitives, Primitives encapsulate Code
Controller Content Binding = in an external file (XML ADL), Not in programs
Controller Content Binding = in an external file (XML ADL), Not in programs
Context and Challenge - Asynchronous, - Distributed components, yet Deterministic Components
Method names Fields Primitive Components Requests A Primitive Component Requests Server Interfaces Client Interfaces
Hierarchical Composition Composite component Primitive component PC Export Export Output interfaces Binding Asynchronous method calls Input interfaces CC PC PC
eC is a function yis a function Invalid composition Interface exported twice Output plugged twice es is a function Except with group communication …
Valid Compositions Output interfaces Non-confluent Input interfaces Non-confluent Non-confluent
Valid Compositions Output interfaces Input interfaces
Semantics: “Static” Translation to ASP Output interfaces Input interfaces
Semantics: “Dynamic” Translation to ASP Output interfaces Input interfaces
Deterministic Primitive Component • Requirement on potential services: Each Potential service isentirely included in a single SI A Primitive Component Serve(M)
Deterministic Composition (SDON) Each SI is only used once, either bound or exported: Non-confluent Non-confluent Non-confluent
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
Towards Parallel and Deterministic Components Groups in ASP
a Group.foo() Groups of Active Objects Part IV 3 – More Features
a Group.foo() Groups of Active Objects g1 foo g2 result foo g3 foo Part IV 3 – More Features
a Group.foo() Groups of Active Objects g1 foo bar g2 bar foo b g3 Group.bar() bar foo Part IV 3 – More Features
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
3. Distributed Component Specification Cp. in Practice GCM: Grid Component Model
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
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
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
Multicast interfaces Results as lists of results Invocation parameters may also be distributed from lists
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
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, …