2. CALCULUS:

1

• 2. CALCULUS

A S P
2
A Theory of Distributed ObjectsD. Caromel, L.
Henrio, Springer 2005, Monograph
THEORY

• A Calculus
• ASP Asynchronous Sequential Processes
• Based on Sigma-Calculus (Abadi-Cardelli)
• Formal Proofs of determinism
• Releases a few important implementation
  constraints

3
?-calculus
4
Why calculi? Prove properties on languages,
typing Programs (equivalence), execution
strategies,
5
Review (informal classification of calculi)
6
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
7
ASP Syntax Source Terms

• Imperative V-calculus
• ASP parallelism primitives

1- ASP
8
Local
Creating an Activity
Sending a Request
Sending a Reply
1- ASP
9
Structure
Active(a)
1- ASP
10
Sending Requests ( REQUEST )
a
b
foo
beta.foo(b)
resultbeta.foo(b)
1- ASP
11
Sending Requests ( REQUEST )
a
b
foo
beta.foo(b)
resultbeta.foo(b)
1- ASP
12
Wait-by-necessity
a
b
delta.send(result)
d
1- ASP
13
Wait-by-necessity
a
b
delta.send(result)
result.bar()
d
1- ASP
14
Wait-by-necessity
a
b
delta.send(result)
result.bar()
d
1- ASP
15
Wait-by-necessity
a
b
Futures updates can occur at any time
result.bar()
d
1- ASP
16

• Confluence and Determinacy

17
Store Partitioning
18
Deterministic Object Networks
g
b
d
foo,bar , foo,gee
bar,gee , foo
gee bar
bar gee
19
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,

20
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
e
f
b
The difficulty is to staticallyapproximate
activities, method calls and potential services
bar , gee
gee, f,g
gee, f,g
gee
21
From 2. to 3.CALCLUS to COMPONENTS
Components in ASP
Objective Deterministic Components
22
Using the Fractal modelHierarchical Component
Defined by E. Bruneton, T. Coupaye, J.B. Stefani,
INRIA FT
23
Hierarchical model Composites encapsulate
Primitives, Primitives encapsulate Code
24
Binding in an external file (XML ADL), Not in
programs
25
Binding in an external file (XML ADL), Not in
programs
26
Context and Challenge

• - Asynchronous,
• - Distributed components, yet
• ? Deterministic Components

27
Primitive Components
Requests
A Primitive Component
Requests
Server Interfaces
Client Interfaces
28
Hierarchical Composition
Composite component
Primitive component
PC
Export
Export
Output interfaces
Binding
Asynchronous method calls
Input interfaces
CC
PC
PC
29
Invalid composition
Interface exported twice
Output plugged twice
es is a function
Except with group communication
30
Valid Compositions
Output interfaces
Non-confluent
Input interfaces
Non-confluent
Non-confluent
31
Valid Compositions
Output interfaces
Input interfaces
32
Semantics Static Translation to ASP
Output interfaces
Input interfaces
33
Semantics Dynamic Translation to ASP
Output interfaces
Input interfaces
34
Deterministic Primitive Component

• Requirement on potential services
• Each Potential service isentirely included in a
  single SI

A Primitive Component
Serve(M)
35
Deterministic Composition (SDON)
Each SI is only used once, either bound or
exported
Non-confluent
Non-confluent
Non-confluent
36
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
37
Towards Parallel and Deterministic Components

• Groups in ASP

38
Groups of Active Objects
3 More Features
Part IV
39
Groups of Active Objects
g1
foo
g2
result
foo
g3
foo
3 More Features
Part IV
40
Groups of Active Objects
g1
foo
bar
g2
foo
bar
b
g3
Group.bar()
foo
bar
3 More Features
Part IV
41
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
42
3. Distributed Component Specification Cp. in
Practice
GCM Grid Component Model
43
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
44
Collective Interfaces
45
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

46
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

47
(No Transcript)
48
Multicast interfaces

• Results as lists of results
• Invocation parameters may also be distributed
  from lists

49
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

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

51
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.

52

• NEXT Part 4. Middleware ProActive

53
(No Transcript)
54
(No Transcript)
55
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

56
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
57
Equivalence Modulo Futures Updates
a
f1
b
g
f2
f3
Part III
58
Appendices
59
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
60
A Deterministic Component

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

Components
Part IV
61
Equivalence Modulo Futures Updates (1)
a
a
g
g
f3
2 - Confluence and Determinacy
Part III
62
Equivalence Modulo Futures Updates (2)
a
f1
b
g
f2
f3
2 - Confluence and Determinacy
Part III
63
Equivalence Modulo Future Updates (2)
a
a
f2
f1
b
g
b
g
f2
f3
2 - Confluence and Determinacy
Part III
64
Compatibility
Serves the oldest request on foo OR bar
bar
d
. Serve(foo,bar) Serve(foo,gee)
foo
gee
2 - Confluence and Determinacy
Part III
65
Confluence

• Potential services

. Serve(foo,bar) Serve(foo,gee)
foo,bar, foo,gee
2 - Confluence and Determinacy
Part III
66
Confluence

• Potential services

foo,bar, foo,gee

• RSL definition

?foo, ?bar, ?bar, ?gee
2 - Confluence and Determinacy
Part III
67
Confluence

• Potential services

foo,bar, foo,gee
?foo, ?bar, ?bar, ?gee

• Configuration Compatibility

?foo, ?bar, ?bar, ?gee
?foo, ?bar, ?gee, ?bar
?foo, ?bar, ?bar, ?gee
?foo, ?bar, ?gee, ?bar
?foo, ?bar, ?bar, ?gee
?foo, ?bar, ?gee, ?bar
2 - Confluence and Determinacy
Part III
68
Confluence

• Potential services

Execution characterized by the order of request
senders
Compatibility ? Confluence
2 - Confluence and Determinacy
Part III
69
Deterministic Object Networks
g
b
d
foo,bar , foo,gee
bar,gee , foo
gee bar
bar gee
2 - Confluence and Determinacy
Part III
70
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,
71
Contents

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

72
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 Strategies
Part V
73
Future Updates Summary

• Mixed strategies are possible
• All strategies are equivalent(modulo
  dead-locks)

Part V, VI
4 Implementation Strategies
74
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
75
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

76
Deterministic Object Networks
g
b
d
foo,bar , foo,gee
bar,gee , foo
gee bar
bar gee