1. 2. CALCULUS: A S P

2. A Theory of Distributed Objects D. Caromel, L. Henrio, Springer 2005, Monograph A Calculus: ASP: Asynchronous Sequential Processes l Based on Sigma-Calculus (Abadi-Cardelli) l Formal Proofs of determinism l Releases a few important implementation constraints THEORY

3.  -calculus

4. Why calculi? Prove properties on languages, typing Programs (equivalence), execution strategies, … 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 l Distributed objects l Asynchronous method calls (  towards components) l Futures and Wait-by-necessity è Determinism properties A Theory of Distributed Objects

7. ASP Syntax : Source Terms Imperative  -calculus l ASP parallelism primitives 1- ASP

8. Local Creating an Activity Sending a Request Sending a Reply Service 1- ASP

9.     f3 f1 Structure 1- ASP foo f2 Active(a)

10. foo   beta.foo(b) result=beta.foo(b) Sending Requests( REQUEST ) 1- ASP

11. foo   beta.foo(b) result Sending Requests( REQUEST ) 1- ASP result=beta.foo(b)

12. delta.send(result)    Wait-by-necessity 1- ASP

13. delta.send(result) result.bar()    Wait-by-necessity 1- ASP

14. delta.send(result) result.bar()    Wait-by-necessity 1- ASP

15.    Wait-by-necessity result.bar() Futures updates can occur at any time Futures updates can occur at any time 1- ASP

16. Confluence and Determinacy

17.  Store Partitioning

18. Deterministic Object Networks    {foo,bar}, {foo,gee} delta.gee(a) gee delta.bar(a) bar {bar,gee}, {foo} gee barbar gee DON(P):

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  {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} g The difficulty is to statically approximate activities, method calls and potential services The difficulty is to statically approximate activities, method calls and potential services

21. From 2. to 3.: CALCLUS to COMPONENTS Components in ASP Objective: Deterministic Components

22. Content Controller Using the Fractal model: Hierarchical Component Defined by E. Bruneton, T. Coupaye, J.B. Stefani, INRIA & FT

23. Content Controller Hierarchical model : Composites encapsulate Primitives, Primitives encapsulate Code

24. Content Controller Binding = in an external file (XML ADL), Not in programs

25. Content Controller Binding = in an external file (XML ADL), Not in programs

26. Context and Challenge - Asynchronous, - Distributed components, yet  Deterministic Components

27. Primitive Components A Primitive Component Server Interfaces Client Interfaces Requests Method names Fields Requests

28. Hierarchical Composition Composite component Primitive component PC CC Input interfaces Output interfaces Asynchronous method calls Export Binding

29. Invalid composition Interface exported twiceOutput plugged twice Except with group communication …  s is a function  C is a function  is a function

30. Valid Compositions Non-confluent Input interfaces Output interfaces

31. Valid Compositions Input interfaces Output interfaces

32. Semantics: “Static” Translation to ASP Input interfaces Output interfaces

33. Semantics: “Dynamic” Translation to ASP Input interfaces Output interfaces

34. Deterministic Primitive Component Requirement on potential services: Each Potential service is entirely included in a single SI A Primitive Component Serve(M)

35. Deterministic Composition (SDON) Non-confluent Each SI is only used once, either bound or exported:

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 communications Requests = 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 abstraction for statically ensuring determinism Components provide a convenient abstraction for statically ensuring determinism

37. Towards Parallel and Deterministic Components Groups in ASP

38.  Group.foo() Groups of Active Objects 3 – More Features Part IV

39.  Group.foo() Groups of Active Objects    foo result 3 – More Features Part IV

40.  Group.foo() Groups of Active Objects    foo  Group.bar() bar 3 – More Features Part IV

41.  Group.foo() Groups of Active Objects: Atomic Communications    foo  Group.bar() bar Some programs become deterministic with Atomic Group Communications Non Det. Prog.  Det. Prog. with Groups

42. 3. Distributed Component Specification Cp. in Practice GCM: Grid Component Model

43.  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. GCM Components 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. 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

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 l Renames a VN l 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

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  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  f1  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 l Based on deterministic primitive components. l One-to-one mapping from Server to client interface Components Part IV

61. Equivalence Modulo Futures Updates (1)   f3   2 - Confluence and Determinacy Part III

62. Equivalence Modulo Futures Updates (2)  f1  f2  f3  f1  f2  2 - Confluence and Determinacy Part III

63. Equivalence Modulo Future Updates (2)   f2  f3   f1  f2 f1 2 - Confluence and Determinacy Part III

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

65. Confluence l Potential services: 2 - Confluence and Determinacy P0 PQ R …. Serve(foo,bar) … Serve(foo,gee) {foo,bar}, {foo,gee} Part III

66. Confluence l Potential services: 2 - Confluence and Determinacy l RSL definition:  foo,  bar,  bar,  gee P0 PQ R {foo,bar}, {foo,gee} Part III

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

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

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

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 l A Theory of Distributed Objects 1 - ASP 2 - Confluence and Determinacy 3 - More Features: Groups 4 – Implementation Strategies: Future Updates l ASP Components l Perspectives

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

73. Future Updates Summary l Mixed strategies are possible l 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 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  may perform in the future. = {{foo,bar},{gee}}

76. Deterministic Object Networks    {foo,bar}, {foo,gee} delta.gee(a) gee delta.bar(a) bar {bar,gee}, {foo} gee barbar gee DON(P):