1. Asynchronous Distributed Components: Concurrency and Determinacy I. Context: Distributed Components and Active Objects II. Asynchronous Distributed Components III. Deterministic Distributed Components Denis CAROMEL Ludovic HENRIO TCS 2006 - 23/08/2006

2. I. Context: Distributed Components and Active Objects II. Asynchronous Distributed Components III. Deterministic Distributed Components Content

3. 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  Communication, hierarchy and deterministic components

4. 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, …

5. Services in ASP l Pending requests are stored in a queue. l 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}}

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

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

8. I. Context: Distributed Components and Active Objects II. Asynchronous Distributed Components III. Deterministic Distributed Components Content

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

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

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

12. Valid Compositions Input interfaces Output interfaces

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

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

15. ASP Components: Characteristics l Well defined interfaces: served methods (should correspond to potential services) l Structured communications: Requests = Asynchronous method calls l Concurrent and Distributed: Primitive components as an abstraction for activities (threads) l Inherit futures, data-driven synchronization and asynchrony from ASP

16. I. Context: Distributed Components and Active Objects II. Asynchronous Distributed Components III. Deterministic Distributed Components Content

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

18. Deterministic Composition Non-confluent Each SI is only used once, either bound or exported:

19. Summary and Results l A definition of components  Coarse grain components (activities)  Convenient abstraction for distribution and Concurrency  Structured asynchronous communications  Semantics as a translation to ASP  First class futures inherited from ASP l 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

20. A Few Perspectives l Behavioral specification of component composition (ongoing) l Specify and study non-functional aspects  in particular life-cycle and reconfiguration in a distributed environment l A Formal basis fo the Grid Component Model (GCM) -- together with the kell-calculus  Collective interfaces  Grid specifices (distribution and heterogeneity)  Put together hierarchy, structured communications and non-functional aspects

22.     f3 f1 Structure foo f2 Active(a)

23. foo   beta.foo(b) result=beta.foo(b) Sending Requests ( REQUEST )

24. foo   beta.foo(b) result result=beta.foo(b) Sending Requests ( REQUEST )

25. foo   Sending Results( REPLY )

26.   foo

27. delta.send(result) result.bar()    Future Update Strategies 

28. delta.send( result )    Future Update Strategies: No partial replies and request

29. delta.send(result)result.bar()    Future Update Strategies: Message-based  Future Forwarded Messages

30. delta.send(result)result.bar()    Future Update Strategies: Forward-based 

31. delta.send(result)result.bar()    Future Update Strategies: Lazy Future Updates 