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