A Theory of Distributed ObjectsToward a Foundation for Component Grid Platforms

Ludovic HENRIO

A Theory of Distributed Objects

Components

Perspectives

University of Westminster

A Theory of Distributed Objects: Contents

I. ReviewII. ASP CalculusIII. Semantics and PropertiesIV. A Few More FeaturesV. Implementation StrategiesVI. Final Words

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)

Review (informal classification of calculi)

Part I

Contents

A Theory of Distributed Objects

1 - ASP

2 - Confluence and Determinacy

3 - More Features: Groups

4 – Implementation Strategies: Future Updates

Components Perspectives

Asynchronous and Deterministic Objects

ASP: Asynchronous Sequential Processes Distributed objects Asynchronous method calls Futures and Wait-by-necessity

Determinism properties

A Theory of Distributed ObjectsPart II

f3

f1

Structure

1- ASP

foo

foo

f2

Active(a)

Part II

foo

beta.foo(b)

result=beta.foo(b)

Sending Requests ( REQUEST )

1- ASPPart II, III

foo

beta.foo(b)result

Sending Requests ( REQUEST )

1- ASP

result=beta.foo(b)

Part II, III

foo

beta.foo(b)

Serve(foo);...

result

Serving Requests ( SERVE )

Serve(foo);...

bar

1- ASPPart II, III

beta.foo(b)result

Serving Requests ( SERVE )

Serve(foo)

barfoo ...foo

1- ASP

Serve(foo);...

Part II, III

foo

Sending Results ( REPLY )

1- ASPPart II, III

Sending Results ( REPLY )

foo

1- ASPPart II, III

ASP Syntax : Source Terms Imperative-calculus

ASP parallelism primitives

1- ASPPart II

Local

Creating anActivity

Sending aRequest

Sending aReply

Service

1- ASPPart III

delta.send(result)

Wait-by-necessity

1- ASPPart II, III

delta.send(result)result.bar()result.bar()

Wait-by-necessity

1- ASPPart II, III

delta.send(result)result.bar()result.bar()

Wait-by-necessity

1- ASPPart II, III

Wait-by-necessity

result.bar()Futures updates can

occur at any time

1- ASPPart II, III

Contents

A Theory of Distributed Objects

1 - ASP

2 - Confluence and Determinacy

3 - More Features: Groups

4 – Implementation Strategies: Future Updates

Components Perspectives

Equivalence Modulo Futures Updates

f1

f2

f3

f1

f2

2 - Confluence and DeterminacyPart III

Equivalence Modulo Future Updates

f2

f3

f1

f1

f2

f1

2 - Confluence and DeterminacyPart 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

Potential services:

2 - Confluence and Determinacy

P0

P Q

R

….Serve(foo,bar)

…Serve(foo,gee)

{foo,bar}, {foo,gee}

Part III

Confluence

Potential services:

2 - Confluence and Determinacy

RSL definition:foo, bar, bar, gee

P0

P Q

R

{foo,bar}, {foo,gee}

Part III

Confluence

Potential services:

2 - Confluence and Determinacy

RSL definition:

Configuration Compatibility:

P0

P Q

R

{foo,bar}, {foo,gee}

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:

2 - Confluence and Determinacy

RSL definition:

Compatibility Confluence

Configuration Compatibility:Execution characterized

by the order of request senders

P0

P Q

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

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}

2 - Confluence and Determinacy

g

Part III

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 sendersDeterminacy of programs communicating over trees, …

2 - Confluence and DeterminacyPart III

Contents

A Theory of Distributed Objects

1 - ASP

2 - Confluence and Determinacy

3 - More Features: Groups

4 – Implementation Strategies: Future Updates

Components Perspectives

ASP Extensions

Group communications Formalization, Atomicity and relations to determinacy.

Migration Optimization and confluence issues

Components

Others: non-blocking services, join patterns, delegation ...

3 – More FeaturesPart IV

Group.foo()

Groups of Active Objects

3 – More FeaturesPart IV

Group.foo()

Groups of Active Objects

foo

foo

foo

result

3 – More FeaturesPart IV

Group.foo()

Groups of Active Objects

foo

foo

foo

Group.bar()

bar

bar

bar

3 – More FeaturesPart IV

Group.foo()

Groups of Active Objects: Atomic Communications

foo

foo

foo

Group.bar()

bar

bar

bar

Some programs become deterministic with

atomic group communications

3 – More FeaturesPart IV

Contents

A Theory of Distributed Objects

1 - ASP

2 - Confluence and Determinacy

3 - More Features: Groups

4 – Implementation Strategies: Future Updates 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

Model: Remote Mobile Objects Asynchronous Communications with automatic Futures Group Communications, Migration, NF ExceptionsEnvironment: XML Deployment, dynamic class-loading Various protocols: rsh,ssh,LSF,Globus, BPS, ... Graphical Visualization and monitoring: IC2D

ProActive: A Java API + Tools for the GRID

Parallel, Distributed, Mobile, Activities, across the world !SMP ClustersLANDesktop

4 – Implementation StrategiesPart V

delta.send(result)

Future Update Strategies: No partial replies and request

4 – Implementation StrategiesPart V

delta.send(result)result.bar()result.bar()

Future Update Strategies

4 – Implementation StrategiesPart V

delta.send(result)result.bar()result.bar()

Future Update Strategies: Message-based

4 – Implementation Strategies

Futu

re F

orw

arde

dM

essa

ges

Part V

delta.send(result)result.bar()result.bar()

Future Update Strategies: Forward-based

4 – Implementation StrategiesPart V

delta.send(result)result.bar()result.bar()

Future Update Strategies: Lazy Future Updates

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

Part VI 4 – Implementation Strategies

Contents

A Theory of Distributed Objects

1 - ASP

2 - Confluence and Determinacy

3 - More Features: Groups

4 – Implementation Strategies: Future Updates

Components Perspectives

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

ComponentsPart IV

Components from ASP Terms: Primitive Components

Server Interface = potential service Client Interface = reference to an active object

ComponentsPart IV

Hierarchical Composition

Composite component

Primitive component

PC

PC PCCC

Inpu

t int

erfa

ces

Output interfaces

Asynchronousmethod calls

Exp

ort

Exp

ort

Binding

ComponentsPart IV

Invalid composition

Interface exported twice Output plugged twice

Components

Except with group communication …

Part IV

Valid Compositions

Non-confluent

Non-confluent

Components

Non-confluent

Inpu

t int

erfa

ces

Output interfaces

Part IV

A Deterministic Component

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

ComponentsPart IV

Component Model: Summary and Results

Specification of deterministic components: Deterministic primitive components Deterministic composition of components

Semantics as a translation to ASP

Components

Components provide a convenient abstraction

for statically ensuring determinism

Part IV

Contents

A Theory of Distributed Objects

1 - ASP

2 - Confluence and Determinacy

3 - More Features: Groups

4 – Implementation Strategies: Future Updates

Components Perspectives

Perspectives: Asynchronous and Distributed Objects

Generalize confluence properties Scheduling of requests Functional servers Join patterns

Strong migration and coherence Ojeblik for Obliq

PerspectivesPart VI

Perspectives: Distributed Components

Non-functional aspects

Behavioural specification: LTS for ASP / ASP components Interaction between confluence and behavioural

verification Hierarchical verification

Verification of component composition and reconfiguration

PerspectivesPart VI

Application: a Component Platform for Grid Computing

Reconfigurability: Fault tolerance Adaptativity: Heterogeneous environments Performance: scalability, optimizations

Foundation, Principles : A component model 

adaptability, reconfiguration, hierarchical Separation of functional / non-functional aspects

transparency help programming, adaptation Semantics specify and prove behavior, and optimizations

Design of a generic component platformfor the Grid

adaptativity, reconfiguration, transparency

PerspectivesPart VI

...foo

End of Service ( ENDSERVICE )

value

1- ASPPart II, III

foo

End of Service ( ENDSERVICE )

...

1- ASPPart II, III

Active(a,s)

newact=Active(a,s)

Activity Creation ( NEWACT )

1- ASPPart II, III

Active(a,s)

newact=Active(a,s)

newact

Activity Creation ( NEWACT )

ao.s()

1- ASPPart II, III

Static DON versus Process Networks

{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

gput

get

Part VI

Objects Topology

Part II

Related Work

Futures and Wait by Necessity: MultiLisp by Halstead Wait-By-Necessity by Caromel

Determinism: by JonesLinearized channels Process Networks by Kahn and MacQueen

Objects and concurrency: Obliq, Gordon-Hankin-Lassen Actors -calculus, blue calculus, join-calculus

Part I

Terms:

Configuration: Request queue: Futures list: Store:

Intermediate Structures

Part III

Store Partitioning

Part III

Equivalence Modulo Futures Updates

f1

f2

f3

Part III

Appendices