A%20Theory%20of%20Distributed%20Objects%20Toward%20a%20Foundation%20for%20Component%20Grid%20Platforms%20Ludovic%20HENRIO - PowerPoint PPT Presentation

About This Presentation
Title:

A%20Theory%20of%20Distributed%20Objects%20Toward%20a%20Foundation%20for%20Component%20Grid%20Platforms%20Ludovic%20HENRIO

Description:

foo. b. a. Sending Results ( REPLY ) 1- ASP. Part II, III. b. a. Sending Results ( REPLY ) foo. 1- ASP. Part II, III. ASP Syntax : Source Terms. Imperative V-calculus ... – PowerPoint PPT presentation

Number of Views:84
Avg rating:3.0/5.0
Slides: 71
Provided by: hen48
Category:

less

Transcript and Presenter's Notes

Title: A%20Theory%20of%20Distributed%20Objects%20Toward%20a%20Foundation%20for%20Component%20Grid%20Platforms%20Ludovic%20HENRIO


1
A Theory of Distributed ObjectsToward a
Foundation for Component Grid PlatformsLudovic
HENRIO
University of Westminster
  • A Theory of Distributed Objects
  • Components
  • Perspectives

2
A Theory of Distributed Objects Contents
  1. Review
  2. ASP Calculus
  3. Semantics and Properties
  4. A Few More Features
  5. Implementation Strategies
  6. Final Words

3
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)

4
Review (informal classification of calculi)
Part I
5
Contents
  • A Theory of Distributed Objects
  • 1 - ASP
  • 2 - Confluence and Determinacy
  • 3 - More Features Groups
  • 4 Implementation Strategies Future Updates
  • Components
  • Perspectives

6
Asynchronous and Deterministic Objects
  • ASP Asynchronous Sequential Processes
  • Distributed objects
  • Asynchronous method calls
  • Futures and Wait-by-necessity
  • Determinism properties

A Theory of Distributed Objects
Part II
7
Structure
Active(a)
1- ASP
Part II
8
Sending Requests ( REQUEST )
a
b
foo
beta.foo(b)
resultbeta.foo(b)
1- ASP
Part II, III
9
Sending Requests ( REQUEST )
a
b
foo
beta.foo(b)
resultbeta.foo(b)
1- ASP
Part II, III
10
Serving Requests ( SERVE )
a
b
Serve(foo)...
foo
beta.foo(b)
bar
Serve(foo)...
1- ASP
Part II, III
11
Serving Requests ( SERVE )
a
b
Serve(foo)
beta.foo(b)
bar
Serve(foo)...
1- ASP
Part II, III
12
Sending Results ( REPLY )
a
b
foo
1- ASP
Part II, III
13
Sending Results ( REPLY )
a
b
foo
1- ASP
Part II, III
14
ASP Syntax Source Terms
  • Imperative V-calculus
  • ASP parallelism primitives

1- ASP
Part II
15
Local
Creating an Activity
Sending a Request
Sending a Reply
1- ASP
Part III
16
Wait-by-necessity
a
b
delta.send(result)
d
1- ASP
Part II, III
17
Wait-by-necessity
a
b
delta.send(result)
result.bar()
d
1- ASP
Part II, III
18
Wait-by-necessity
a
b
delta.send(result)
result.bar()
d
1- ASP
Part II, III
19
Wait-by-necessity
a
b
Futures updates can occur at any time
result.bar()
d
1- ASP
Part II, III
20
Contents
  • A Theory of Distributed Objects
  • 1 - ASP
  • 2 - Confluence and Determinacy
  • 3 - More Features Groups
  • 4 Implementation Strategies Future Updates
  • Components
  • Perspectives

21
Equivalence Modulo Futures Updates
a
f1
b
g
f2
f3
2 - Confluence and Determinacy
Part III
22
Equivalence Modulo Future Updates
a
a
f2
f1
b
g
b
g
f2
f3
2 - Confluence and Determinacy
Part III
23
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
24
Confluence
  • Potential services

. Serve(foo,bar) Serve(foo,gee)
foo,bar, foo,gee
2 - Confluence and Determinacy
Part III
25
Confluence
  • Potential services

foo,bar, foo,gee
  • RSL definition

?foo, ?bar, ?bar, ?gee
2 - Confluence and Determinacy
Part III
26
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
27
Confluence
  • Potential services

Execution characterized by the order of request
senders
Compatibility ? Confluence
2 - Confluence and Determinacy
Part III
28
Deterministic Object Networks
g
b
d
foo,bar , foo,gee
bar,gee , foo
gee bar
bar gee
2 - Confluence and Determinacy
Part III
29
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
bar , gee
gee, f,g
gee, f,g
gee
2 - Confluence and Determinacy
Part III
30
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
    senders
  • Determinacy of programs communicating over trees,

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

32
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 Features
Part IV
33
Groups of Active Objects
3 More Features
Part IV
34
Groups of Active Objects
g1
foo
g2
result
foo
g3
foo
3 More Features
Part IV
35
Groups of Active Objects
g1
foo
bar
g2
foo
bar
b
g3
Group.bar()
foo
bar
3 More Features
Part IV
36
Groups of Active Objects Atomic Communications
g1
foo
bar
Some programs become deterministic with atomic
group communications
g2
foo
bar
b
g3
Group.bar()
foo
bar
3 More Features
Part IV
37
Contents
  • A Theory of Distributed Objects
  • 1 - ASP
  • 2 - Confluence and Determinacy
  • 3 - More Features Groups
  • 4 Implementation Strategies Future Updates
  • Components
  • Perspectives

38
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
39
ProActive A Java API Tools for the GRID
Parallel, Distributed, Mobile, Activities,
across the world !
Desktop
  • Model
  • Remote Mobile Objects
  • Asynchronous Communications with automatic
    Futures
  • Group Communications, Migration, NF Exceptions
  • Environment
  • XML Deployment, dynamic class-loading
  • Various protocols rsh,ssh,LSF,Globus, BPS, ...
  • Graphical Visualization and monitoring IC2D

4 Implementation Strategies
Part V
40
Future Update Strategies No partial replies and
request
a
b
delta.send(result)
d
4 Implementation Strategies
Part V
41
Future Update Strategies
a
b
delta.send(result)
result.bar()
d
g
4 Implementation Strategies
Part V
42
Future Update Strategies Message-based
a
b
delta.send(result)
result.bar()
result.bar()
d
Future Forwarded Messages
g
4 Implementation Strategies
Part V
43
Future Update Strategies Forward-based
a
b
delta.send(result)
result.bar()
result.bar()
d
g
4 Implementation Strategies
Part V
44
Future Update Strategies Lazy Future Updates
a
b
delta.send(result)
result.bar()
result.bar()
d
g
4 Implementation Strategies
Part V
45
Future Updates Summary
  • Mixed strategies are possible
  • All strategies are equivalent(modulo
    dead-locks)

Part V, VI
4 Implementation Strategies
46
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
47
Contents
  • A Theory of Distributed Objects
  • 1 - ASP
  • 2 - Confluence and Determinacy
  • 3 - More Features Groups
  • 4 Implementation Strategies Future Updates
  • Components
  • Perspectives

48
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

Components
Part IV
49
Components from ASP Terms Primitive Components
  • Server Interface potential service
  • Client Interface reference to an active object

Components
Part IV
50
Hierarchical Composition
Composite component
Primitive component
PC
Export
Export
Output interfaces
Binding
Asynchronous method calls
Input interfaces
CC
PC
PC
Components
Part IV
51
Invalid composition
Interface exported twice
Output plugged twice
Except with group communication
Components
Part IV
52
Valid Compositions
Output interfaces
Non-confluent
Input interfaces
Non-confluent
Non-confluent
Components
Part IV
53
A Deterministic Component
  • Based on deterministic primitive components.
  • One-to-one mapping from Server to client interface

Components
Part IV
54
Component Model Summary and Results
  • Specification of deterministic components
  • Deterministic primitive components
  • Deterministic composition of components
  • Semantics as a translation to ASP

Components provide a convenient abstractionfor
statically ensuring determinism
Components
Part IV
55
Contents
  • A Theory of Distributed Objects
  • 1 - ASP
  • 2 - Confluence and Determinacy
  • 3 - More Features Groups
  • 4 Implementation Strategies Future Updates
  • Components
  • Perspectives

56
Perspectives Asynchronous and Distributed
Objects
  • Generalize confluence properties
  • Scheduling of requests
  • Functional servers
  • Join patterns
  • Strong migration and coherence
  • Ojeblik for Obliq

Perspectives
Part VI
57
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

Perspectives
Part VI
58
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

Perspectives
Part VI
59
(No Transcript)
60
End of Service ( ENDSERVICE )
a
b
value
...
foo
1- ASP
Part II, III
61
End of Service ( ENDSERVICE )
a
b
...
foo
1- ASP
Part II, III
62
Activity Creation ( NEWACT )
a
g
Active(a,s)
newactActive(a,s)
1- ASP
Part II, III
63
Activity Creation ( NEWACT )
a
Active(a,s)
newactActive(a,s)
1- ASP
Part II, III
64
Static DON versus Process Networks
a
d
f
foo,bar , gee
gee, f,g
foo,bar , gee
f,g
g
put
g
g
foo
f
foo,bar , gee
foo, bar
bar
e
f
b
get
bar , gee
gee, f,g
gee, f,g
gee
Part VI
65
Objects Topology
b
a
g
d
Part II
66
Related Work
  • Futures and Wait by Necessity
  • MultiLisp by Halstead
  • Wait-By-Necessity by Caromel
  • Determinism
  • pobl by Jones, Linearized channels
  • Process Networks by Kahn and MacQueen
  • Objects and concurrency
  • Obliq, Gordon-Hankin-Lassen
  • Actors
  • ?-calculus, blue calculus, join-calculus

Part I
67
Intermediate Structures
  • Terms
  • Configuration
  • Request queue
  • Futures list
  • Store

Part III
68
Store Partitioning
Part III
69
Equivalence Modulo Futures Updates
a
f1
b
g
f2
f3
Part III
70
Appendices
Write a Comment
User Comments (0)
About PowerShow.com