Download presentation
Presentation is loading. Please wait.
Published byAlban Tucker Modified over 9 years ago
1
A Theory of Distributed Objects Toward a Foundation for Component Grid Platforms Ludovic HENRIO l A Theory of Distributed Objects l Components l Perspectives University of Westminster
2
A Theory of Distributed Objects: Contents I.Review II.ASP Calculus III.Semantics and Properties IV.A Few More Features V.Implementation Strategies VI.Final Words
3
Contents l 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) l Components (IV) l Perspectives (VI and beyond)
4
Review (informal classification of calculi) Part I
5
Contents l A Theory of Distributed Objects 1 - ASP 2 - Confluence and Determinacy 3 - More Features: Groups 4 – Implementation Strategies: Future Updates l Components l Perspectives
6
Asynchronous and Deterministic Objects ASP: Asynchronous Sequential Processes l Distributed objects l Asynchronous method calls l Futures and Wait-by-necessity è Determinism properties A Theory of Distributed Objects Part II
7
f3 f1 Structure 1- ASP foo f2 Active(a) Part II
8
foo beta.foo(b) result=beta.foo(b) Sending Requests( REQUEST ) 1- ASP Part II, III
9
foo beta.foo(b) result Sending Requests( REQUEST ) 1- ASP result=beta.foo(b) Part II, III
10
foo beta.foo(b) Serve(foo);... result Serving Requests( SERVE ) Serve(foo);... bar 1- ASP Part II, III
11
beta.foo(b) result Serving Requests( SERVE ) Serve(foo) bar foo... foo 1- ASP Serve(foo);... Part II, III
12
foo Sending Results( REPLY ) 1- ASP Part II, III
13
Sending Results( REPLY ) foo 1- ASP Part II, III
14
ASP Syntax : Source Terms Imperative -calculus l ASP parallelism primitives 1- ASP Part II
15
Local Creating an Activity Sending a Request Sending a Reply Service 1- ASP Part III
16
delta.send(result) Wait-by-necessity 1- ASP Part II, III
17
delta.send(result) result.bar() Wait-by-necessity 1- ASP Part II, III
18
delta.send(result) result.bar() Wait-by-necessity 1- ASP Part II, III
19
Wait-by-necessity result.bar() Futures updates can occur at any time Futures updates can occur at any time 1- ASP Part II, III
20
Contents l A Theory of Distributed Objects 1 - ASP 2 - Confluence and Determinacy 3 - More Features: Groups 4 – Implementation Strategies: Future Updates l Components l Perspectives
21
Equivalence Modulo Futures Updates f1 f2 f3 f1 f2 2 - Confluence and Determinacy Part III
22
Equivalence Modulo Future Updates f2 f3 f1 f2 f1 2 - Confluence and Determinacy Part III
23
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
24
Confluence l Potential services: 2 - Confluence and Determinacy P0 PQ R …. Serve(foo,bar) … Serve(foo,gee) {foo,bar}, {foo,gee} Part III
25
Confluence l Potential services: 2 - Confluence and Determinacy l RSL definition: foo, bar, bar, gee P0 PQ R {foo,bar}, {foo,gee} Part III
26
Confluence l Potential services: 2 - Confluence and Determinacy l RSL definition: l Configuration Compatibility: P0 PQ R {foo,bar}, {foo,gee} foo, bar, bar, gee foo, bar, gee, bar foo, bar, bar, gee foo, bar, gee, bar foo, bar, bar, gee foo, bar, gee, bar Part III
27
Confluence l Potential services: 2 - Confluence and Determinacy l RSL definition: Compatibility Confluence l Configuration Compatibility: Execution characterized by the order of request senders Execution characterized by the order of request senders P0 PQ R Part III
28
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
29
Static DON {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
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 l A Theory of Distributed Objects 1 - ASP 2 - Confluence and Determinacy 3 - More Features: Groups 4 – Implementation Strategies: Future Updates l Components l Perspectives
32
ASP Extensions l Group communications Formalization, Atomicity and relations to determinacy. l Migration Optimization and confluence issues l Components l Others: non-blocking services, join patterns, delegation... 3 – More Features Part IV
33
Group.foo() Groups of Active Objects 3 – More Features Part IV
34
Group.foo() Groups of Active Objects foo result 3 – More Features Part IV
35
Group.foo() Groups of Active Objects foo Group.bar() bar 3 – More Features Part IV
36
Group.foo() Groups of Active Objects: Atomic Communications foo Group.bar() bar Some programs become deterministic with atomic group communications 3 – More Features Part IV
37
Contents l A Theory of Distributed Objects 1 - ASP 2 - Confluence and Determinacy 3 - More Features: Groups 4 – Implementation Strategies: Future Updates l Components l Perspectives
38
Implementation Strategies l ProActive l Future Update Strategies Futures are first class and can be returned at any time Lazy / Forward-based / Message-based. l Loosing Rendez-Vous Ensuring causal ordering with one-to-all FIFO ordering Comparison with other strategies, e.g. point-to-point FIFO l Controlling Pipelining 4 – Implementation Strategies Part V
39
Model: l Remote Mobile Objects l Asynchronous Communications with automatic Futures l Group Communications, Migration, NF Exceptions Environment: l XML Deployment, dynamic class-loading Various protocols: rsh,ssh,LSF,Globus, BPS,... l Graphical Visualization and monitoring: IC2D ProActive: A Java API + Tools for the GRID Parallel, Distributed, Mobile, Activities, across the world ! SMPClustersLAN Desktop 4 – Implementation Strategies Part V
40
delta.send( result ) Future Update Strategies: No partial replies and request 4 – Implementation Strategies Part V
41
delta.send(result) result.bar() Future Update Strategies 4 – Implementation Strategies Part V
42
delta.send(result)result.bar() Future Update Strategies: Message-based 4 – Implementation Strategies Future Forwarded Messages Part V
43
delta.send(result)result.bar() Future Update Strategies: Forward-based 4 – Implementation Strategies Part V
44
delta.send(result)result.bar() Future Update Strategies: Lazy Future Updates 4 – Implementation Strategies Part V
45
Future Updates Summary l Mixed strategies are possible l 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 Perspectives: Organize and synchronize implementation strategies Design a global adaptative evaluation strategy Part VI 4 – Implementation Strategies
47
Contents l A Theory of Distributed Objects 1 - ASP 2 - Confluence and Determinacy 3 - More Features: Groups 4 – Implementation Strategies: Future Updates l Components l Perspectives
48
Context l Fractal: a component model specification l An implementation in ProActive Hierarchical composition Asynchronous, distributed components Non-functional aspects and lifecycle l Formal aspects Kell calculus → component control (passivation) ASP components → Hierarchical aspects and deterministic components Components Part IV
49
Components from ASP Terms: Primitive Components l Server Interface = potential service l Client Interface = reference to an active object Components Part IV
50
Hierarchical Composition Composite component Primitive component PC CC Input interfaces Output interfaces Asynchronous method calls Export Binding Components Part IV
51
Invalid composition Interface exported twiceOutput plugged twice Components Except with group communication … Part IV
52
Valid Compositions Non-confluent Components Non-confluent Input interfaces Output interfaces Part IV
53
A Deterministic Component l Based on deterministic primitive components. l One-to-one mapping from Server to client interface Components Part IV
54
Component Model: Summary and Results l Specification of deterministic components: Deterministic primitive components Deterministic composition of components l Semantics as a translation to ASP Components Components provide a convenient abstraction for statically ensuring determinism Components provide a convenient abstraction for statically ensuring determinism Part IV
55
Contents l A Theory of Distributed Objects 1 - ASP 2 - Confluence and Determinacy 3 - More Features: Groups 4 – Implementation Strategies: Future Updates l Components l Perspectives
56
Perspectives: Asynchronous and Distributed Objects l Generalize confluence properties Scheduling of requests Functional servers Join patterns l Strong migration and coherence Ojeblik for Obliq Perspectives Part VI
57
Perspectives: Distributed Components l Non-functional aspects l 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 l Reconfigurability: Fault tolerance l Adaptativity: Heterogeneous environments l Performance: scalability, optimizations Foundation, Principles : l A component model adaptability, reconfiguration, hierarchical l Separation of functional / non-functional aspects transparency help programming, adaptation l Semantics specify and prove behavior, and optimizations Design of a generic component platform for the Grid èadaptativity, reconfiguration, transparency Design of a generic component platform for the Grid èadaptativity, reconfiguration, transparency Perspectives Part VI
60
...foo End of Service( ENDSERVICE ) value 1- ASP Part II, III
61
foo End of Service( ENDSERVICE )... 1- ASP Part II, III
62
Active(a,s) newact=Active(a,s) Activity Creation( NEWACT ) 1- ASP Part II, III
63
Active(a,s) newact=Active(a,s) newact Activity Creation( NEWACT ) ao.s() 1- ASP Part II, III
64
Static DON versus Process Networks {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 put get Part VI
65
Objects Topology Part II
66
Related Work l Futures and Wait by Necessity: MultiLisp by Halstead Wait-By-Necessity by Caromel l Determinism: by Jones Linearized channels Process Networks by Kahn and MacQueen l Objects and concurrency: Obliq, Gordon-Hankin-Lassen Actors -calculus, blue calculus, join-calculus Part I
67
l Terms: l Configuration: l Request queue: l Futures list: l Store: Intermediate Structures Part III
68
Store Partitioning Part III
69
Equivalence Modulo Futures Updates f1 f2 f3 Part III
70
Appendices
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.