2. CALCULUS:

2. CALCULUS:

A S P

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

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

Distributed objects

Asynchronous method calls ( towards components)

Futures and Wait-by-necessity

Determinism properties

A Theory of Distributed Objects

ASP Syntax : Source Terms Imperative-calculus

ASP parallelism primitives

1- ASP

Local

Creating anActivity

Sending aRequest

Sending aReply

Service

1- ASP

f3

f1

Structure

1- ASP

foo

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()result.bar()

Wait-by-necessity

1- ASP

delta.send(result)result.bar()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}

{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 staticallyapproximate activities, method calls

and potential services

The difficulty is to staticallyapproximate 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 PrimitiveComponent

Server InterfacesClient Interfaces

Requests

Method names

Fields

Requests

Hierarchical Composition

Composite component

Primitive component

PC

PC PCCC

Inp

ut

inte

rfac

esO

utp

ut in

terfaces

Asynchronousmethod calls

Exp

ort

Exp

ort

Binding

Invalid composition

Interface exported twice Output plugged twice

Except with group communication …

s is a functionC is a function

is a function

Valid Compositions

Non-confluent

Non-confluent

Non-confluent

Inp

ut

inte

rfac

esO

utp

ut in

terfaces

Valid CompositionsIn

pu

t in

terf

aces

Ou

tpu

t interfaces

Semantics: “Static” Translation to ASPIn

pu

t in

terf

aces

Ou

tpu

t interfaces

Semantics: “Dynamic” Translation to ASPIn

pu

t in

terf

aces

Ou

tpu

t interfaces

Deterministic Primitive Component

Requirement on potential services:

Each Potential service isentirely included in a single SI

A PrimitiveComponent

Serve(M)

Deterministic Composition (SDON)

Non-confluent

Non-confluent

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 FeaturesPart IV

Group.foo()


foo

foo

foo

result


Group.foo()


foo

foo

foo

Group.bar()

bar

bar

bar


Group.foo()

Groups of Active Objects: Atomic Communications

foo

foo

foo

Group.bar()

bar

bar

bar

Some programs become deterministic with

Atomic Group Communications

Some programs become deterministic with

Atomic Group Communications

Non Det. Prog. Det. Prog. with GroupsNon Det. Prog. Det. Prog. with Groups

3. Distributed Component Specification Cp. in Practice

GCM: Grid Component Model

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: The vision: GCMGCM to be the GRID to be the GRID GSMGSM for Europe for Europe

Collective Interfaces

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

Renames a VN 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

PerspectivesPart 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

ComponentsPart IV

A Deterministic Component

Based on deterministic primitive components. One-to-one mapping from Server to client interface

ComponentsPart IV

Equivalence Modulo Futures Updates (1)

f3

2 - Confluence and DeterminacyPart III

Equivalence Modulo Futures Updates (2)

f1

f2

f3

f1

f2


Equivalence Modulo Future Updates (2)

f2

f3

f1

f1

f2

f1


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

Potential services:


P0

P Q

R

….Serve(foo,bar)

…Serve(foo,gee)

{foo,bar}, {foo,gee}

Part III

Confluence

Potential services:


RSL definition:

foo, bar, bar, gee

P0

P Q

R


Part III

Confluence

Potential services:


RSL definition:

Configuration Compatibility:

P0

P Q

R


foo, bar, bar, gee

foo, bar, bar, gee foo, bar, gee, barfoo, bar, bar, gee foo, bar, gee, barfoo, bar, bar, gee foo, bar, gee, bar

Part III

Confluence

Potential services:


RSL definition:

Compatibility Confluence

Configuration Compatibility:Execution characterized

by the order of request sendersExecution characterized

by the order of request senders

P0

P Q

R

Part III



delta.gee(a)

gee

delta.bar(a)bar

{bar,gee} , {foo}

gee barbar gee


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

A Theory of Distributed Objects

1 - ASP


3 - More Features: Groups

4 – Implementation Strategies: Future Updates

ASP Components

Perspectives

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

4 – Implementation StrategiesPart V

Future Updates Summary

Mixed strategies are

possible

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}}



delta.gee(a)

gee

delta.bar(a)bar

{bar,gee} , {foo}

gee barbar gee

DON(P):

Documents

2. CALCULUS: