Transcript Document 7708366

2. CALCULUS:
ASP
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
Releases a few important implementation constraints
-calculus
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 an
Activity
Sending a
Request
Service
Sending a
Reply
1- ASP
Structure
a
b
foo
f2
f1
foo
g
d
f3
Active(a)
1- ASP
Sending Requests
a
( REQUEST )
b
beta.foo(b)
foo
result=beta.foo(b)
1- ASP
Sending Requests
a
( REQUEST )
b
beta.foo(b)
result
foo
result=beta.foo(b)
1- ASP
Wait-by-necessity
a
b
delta.send(result)
d
1- ASP
Wait-by-necessity
a
b
delta.send(result)
result.bar()
result
.bar()
d
1- ASP
Wait-by-necessity
a
b
delta.send(result)
result.bar()
result
.bar()
d
1- ASP
Wait-by-necessity
a
b
Futures
updates
can
result.bar()
occur at any time
d
1- ASP
Confluence and Determinacy
Store Partitioning
b
Deterministic Object Networks
g
b
delta.gee(a)
bar
gee
d
{foo,bar}
{bar,gee}
, {foo,gee}
, {foo}
gee gee
bar
bar
DON(P):
delta.bar(a)
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
a
d
f
{foo,bar}
{gee}, {f,g}
, {gee}
{foo,bar}
{f,g}, {gee}
g
g
foo
g
f
{foo,bar}
{foo}, {bar}
, {gee}
bar
b
f
g
e
{bar}
{gee},, {gee}
{f,g}
The
difficulty
is to statically
gee
{gee}, {f,g}
approximate activities, method calls
and potential services
From 2. to 3.:
CALCLUS to COMPONENTS
Components in ASP
Objective: Deterministic Components
Using the Fractal model:
Hierarchical Component
Defined by E. Bruneton, T. Coupaye, J.B. Stefani, INRI
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
Controller
Content
Context and Challenge
- Asynchronous,
- Distributed components, yet
 Deterministic Components
Primitive Components
Requests
Server Interfaces
A Primitive
Component
Requests
Client Interfaces
Method
names
Fields
Hierarchical Composition
Input interfaces
Primitive
component
Export
PC
Binding
Asynchronous
method calls
CC
PC
PC
Output interfaces
Export
Composite component
Invalid composition
Interface exported twice
es is a function
Output plugged twice
eC is a function
y is a function
Except with group communication …
Non-confluent
Output interfaces
Input interfaces
Valid Compositions
Non-confluent
Non-confluent
Output interfaces
Input interfaces
Valid Compositions
Output interfaces
Input interfaces
Semantics: “Static” Translation to ASP
Output interfaces
Input interfaces
Semantics: “Dynamic” Translation to ASP
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)
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 communications
Components
provide
Requests
= Asynchronous method
calls
 Well a
defined
interfaces: served
methods
convenient
abstraction
 Semantics as translations to ASP
for
statically
ensuring
determinism
 First class futures inherited from ASP
Specification of deterministic components:
 Deterministic primitive components
 Deterministic composition of components
Towards
Parallel and Deterministic Components
Groups in ASP
Groups of Active Objects
a
Group.foo()
Part IV
3 – More Features
Groups of Active Objects
g1
a
foo
g2
Group.foo()
result
foo
g3
foo
Part IV
3 – More Features
Groups of Active Objects
g1
a
foo
bar
bar
foo
g2
Group.foo()
b
g3
Group.bar()
Part IV
bar
foo
3 – More Features
Groups of Active Objects:
Atomic Communications
g1
a
foo
bar
g2
Some programs become
deterministic foo
with
bar
Atomic Group Communications
Group.foo()
b
g3
Group.bar()
foo bar
Non Det. Prog.  Det. Prog.
with Groups
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 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.
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
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 a 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
Part VI
Perspectives
Equivalence Modulo Futures Updates
a
f1
b
g
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
Part IV
Components
A Deterministic Component


Based on deterministic primitive components.
One-to-one mapping from Server to client interface
Part IV
Components
Equivalence Modulo Futures Updates (1)
a
a
g
g
f3
Part III
2 - Confluence and Determinacy
Equivalence Modulo Futures Updates (2)
a
a
f1
f1
g
b
g
f2
b
f2
f3
Part III
2 - Confluence and Determinacy
Equivalence Modulo Future Updates (2)
a
a
f2
f1
f1
g
b
g
b
f1
f2
f3
Part III
2 - Confluence and Determinacy
Compatibility
b
bar
d
foo
a
Serves the oldest
request on
foo OR bar
….
Serve(foo,bar)
…
Serve(foo,gee)
g
delta.foo()
gee
Part III
2 - Confluence and Determinacy
P0
Confluence
P
Q
R

Potential services:
….
Serve(foo,bar)
…
Serve(foo,gee)
Part III
{foo,bar}, {foo,gee}
2 - Confluence and Determinacy
P0
Confluence
P
Q
R
Potential services:


{foo,bar}, {foo,gee}
RSL definition:
afoo, bbar, bbar, ggee
Part III
2 - Confluence and Determinacy
P0
Confluence
P
Q
R
Potential services:


RSL definition:

Configuration Compatibility:
afoo, bbar, bbar, ggee
Part III
{foo,bar}, {foo,gee}
afoo, bbar, bbar, ggee
afoo, bbar, ggee, bbar
2 - Confluence and Determinacy
P0
Confluence
P
Q
R
Potential services:



RSL definition:
Execution characterized
Configuration Compatibility:
by the order of request senders
Compatibility  Confluence
Part III
2 - Confluence and Determinacy
Deterministic Object Networks
g
b
delta.gee(a)
bar
gee
delta.bar(a)
d
{foo,bar}
{bar,gee}
, {foo,gee}
, {foo}
gee gee
bar
bar
DON(P):
Part III
2 - Confluence and Determinacy
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
2 - Confluence and Determinacy
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
Part V
4 – Implementation Strategies
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
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 a may
perform in the future.
= {{foo,bar},{gee}}
Deterministic Object Networks
g
b
delta.gee(a)
bar
gee
d
{foo,bar}
{bar,gee}
, {foo,gee}
, {foo}
gee gee
bar
bar
DON(P):
delta.bar(a)