2. CALCULUS: A S P

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

 -calculus

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

Review (informal classification of calculi)

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

ASP Syntax : Source Terms Imperative  -calculus l ASP parallelism primitives 1- ASP

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

    f3 f1 Structure 1- ASP foo f2 Active(a)

foo   beta.foo(b) result=beta.foo(b) Sending Requests( REQUEST ) 1- ASP

foo   beta.foo(b) result Sending Requests( REQUEST ) 1- ASP result=beta.foo(b)

delta.send(result)    Wait-by-necessity 1- ASP

delta.send(result) result.bar()    Wait-by-necessity 1- ASP

delta.send(result) result.bar()    Wait-by-necessity 1- ASP

   Wait-by-necessity result.bar() Futures updates can occur at any time Futures updates can occur at any time 1- ASP

Confluence and Determinacy

 Store Partitioning

Deterministic Object Networks    {foo,bar}, {foo,gee} delta.gee(a) gee delta.bar(a) bar {bar,gee}, {foo} gee barbar gee DON(P):

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, …

Static DON  {foo,bar}, {gee}   {gee}, {f,g}  {bar}, {gee}  {foo,bar}, {gee} foo bar f {foo}, {bar} {gee}, {f,g} {f,g} {gee}, {f,g} f g gee f g {gee}, {f,g} g The difficulty is to statically approximate activities, method calls and potential services The difficulty is to statically approximate activities, method calls and potential services

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

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

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

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

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

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

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

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

Invalid composition Interface exported twiceOutput plugged twice Except with group communication …  s is a function  C is a function  is a function

Valid Compositions Non-confluent Input interfaces Output interfaces

Valid Compositions Input interfaces Output interfaces

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

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

Deterministic Primitive Component Requirement on potential services: Each Potential service is entirely included in a single SI A Primitive Component Serve(M)

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

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 communications Requests = 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 abstraction for statically ensuring determinism Components provide a convenient abstraction for statically ensuring determinism

Towards Parallel and Deterministic Components Groups in ASP

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

 Group.foo() Groups of Active Objects    foo result 3 – More Features Part IV

 Group.foo() Groups of Active Objects    foo  Group.bar() bar 3 – More Features Part IV

 Group.foo() Groups of Active Objects: Atomic Communications    foo  Group.bar() bar Some programs become deterministic with Atomic Group Communications Non Det. Prog.  Det. Prog. with Groups

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

 GCM Being defined in the NoE CoreGRID (42 institutions)  Open Source ObjectWeb ProActive implements a preliminary version of GCM GridCOMP takes:  GCM as a first specification,  ProActive as a starting point, and Open Source reference implementation. GCM Components 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

Gathercast interfaces 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

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, …

Virtual Nodes in the ADL l Renames a VN l Exports a VN name è The final version of the GCM specification will precisely define the syntax for the virtual node definition, and their composition.

NEXT: Part 4. Middleware: ProActive

Services in ASP Pending requests are stored in a queue. Request service in ASP: Serve(foo,bar) serves the oldest request on the method foo or bar. Potential Service : an approximation of the set of services (set of methods M) that can appear in the Serve(M) instructions that an activity  may perform in the future. = {{foo,bar},{gee}}

Perspectives: Distributed Components Behavioral specification of component composition (ongoing) Specify and study non-functional aspects  in particular life-cycle and reconfiguration in a distributed environment A Formal basis fo the Grid Component Model (GCM) -- together with the kell-calculus  Collective interfaces  Grid specifics (distribution and heterogeneity)  Put together hierarchy, structured communications and non-functional aspects Perspectives Part VI

Equivalence Modulo Futures Updates  f1  f2  f3 Part III

Appendices

ASP Components: Characteristics Well defined interfaces: served methods (should correspond to potential services) Structured communications: Requests = Asynchronous method calls Concurrent and Distributed: Primitive components as an abstraction for activities (threads) Inherit futures, data-driven synchronization and asynchrony from ASP Components Part IV

A Deterministic Component l Based on deterministic primitive components. l One-to-one mapping from Server to client interface Components Part IV

Equivalence Modulo Futures Updates (1)   f3   2 - Confluence and Determinacy Part III

Equivalence Modulo Futures Updates (2)  f1  f2  f3  f1  f2  2 - Confluence and Determinacy Part III

Equivalence Modulo Future Updates (2)   f2  f3   f1  f2 f1 2 - Confluence and Determinacy Part III

Compatibility  delta.foo() foo  …. Serve(foo,bar) … Serve(foo,gee) bar gee   2 - Confluence and Determinacy Serves the oldest request on foo OR bar Part III

Confluence l Potential services: 2 - Confluence and Determinacy P0 PQ R …. Serve(foo,bar) … Serve(foo,gee) {foo,bar}, {foo,gee} Part III

Confluence l Potential services: 2 - Confluence and Determinacy l RSL definition:  foo,  bar,  bar,  gee P0 PQ R {foo,bar}, {foo,gee} Part III

Confluence l Potential services: 2 - Confluence and Determinacy l RSL definition: l Configuration Compatibility: P0 PQ R {foo,bar}, {foo,gee}  foo,  bar,  bar,  gee  foo,  bar,  gee,  bar  foo,  bar,  bar,  gee  foo,  bar,  gee,  bar  foo,  bar,  bar,  gee  foo,  bar,  gee,  bar Part III

Confluence l Potential services: 2 - Confluence and Determinacy l RSL definition: Compatibility  Confluence l Configuration Compatibility: Execution characterized by the order of request senders Execution characterized by the order of request senders P0 PQ R Part III

Deterministic Object Networks    {foo,bar}, {foo,gee} delta.gee(a) gee delta.bar(a) bar {bar,gee}, {foo} gee barbar gee 2 - Confluence and Determinacy DON(P): Part III

ASP Calculus Summary An Asynchronous Object Calculus:  Structured asynchronous activities  Communications are asynchronous method calls with futures (promised replies)  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, …

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

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

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

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

Services in ASP Pending requests are stored in a queue. Request service in ASP: Serve(foo,bar) serves the oldest request on the method foo or bar. Potential Service: an approximation of the set of services (set of methods M) that can appear in the Serve(M) instructions that an activity  may perform in the future. = {{foo,bar},{gee}}

Deterministic Object Networks    {foo,bar}, {foo,gee} delta.gee(a) gee delta.bar(a) bar {bar,gee}, {foo} gee barbar gee DON(P):