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 /08/2006

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

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

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

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

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

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

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

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

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

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

Valid Compositions Input interfaces Output interfaces

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

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

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

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

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

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

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

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

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

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

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

foo   Sending Results( REPLY )

  foo

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

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

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

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

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