1. The Grid Component Model and its Implementation in ProActive CoreGrid Network of Excellence, Institute on Programming Models D.PM02 “Proposal for a Grid Component Model” D.PM.04 “Basic Features of the GCM (assessed)”

2. Context l CoreGrid NoE  Institute on Programming Model aims at defining a component model for the Grid l “By defining the GCM, the V.I. aims at the precise specification of an effective Grid Component Model.” l The features are discussed taking Fractal as the reference model. l The features are defined as extensions to the Fractal specification. l The PM institute expects several different implementations of the GCM, not necessarily relying on existing Fractal implementations.

3. Outline  A Summary of Fractal  Communication semantics  Dynamic Controllers, adaptativity and Autonomicity  Parallelism and Distribution  The GCM in ProActive

4. GCM is Based on Fractal Fractal provides: l Terminology, API (and ADL)  Interoperability l Hierarchical structure l Separation of concerns l Abstract component model  no constrain on implementation: several implementations exist l Multi-level specification: almost every object is a level 0 Fractal component We can imagine a multi-level specification of the GCM  We focus on the Grid specific extensions of Fractal general features

5. A Fractal Component

6. Outline  A Summary of Fractal  Communication semantics  Dynamic Controllers, adaptativity and Autonomicity  Parallelism and Distribution  The GCM in ProActive

7. Communications l Fractal:  somewhat “unspecified”, notion of “address space”  most implementations use synchronous primitive bindings, but not all of them,  Composite bindings allow for “other” communication semantics l In the GCM:  Communication semantics should be specified in the interfaces  Asynchronous method call is the default

8. Outline  A Summary of Fractal  Communication semantics  Dynamic Controllers, adaptativity and Autonomicity  Parallelism and Distribution  The GCM in ProActive

9. Dynamic Controllers (components in component’s membrane) l Interest for the GCM:  Reconfiguration and adaptativity of the membranes  For autonomic aspects: hierarchical composition of autonomic aspects (also multicast)  Fractal (GCM) Components in the menbrane l Apply Fractal specification to the non-functional aspect  Pluggable NF server interfaces (NF components)  NF client interfaces

10. Dynamic Controllers (2) l Adaptativity and autonomicity l Dynamic reconfiguration of the controllers l Called component controller l Better separation of concerns l Modification of the content controller (for the membrane) l Controller components should be lightweight components l Might have restriction on distribution or complexity of component controllers l Conformance levels: component controllers are optional

11. Autonomicity l Self-Configuring: handles reconfiguration inside itself l Self-Healing: provides its services in spite of failures l Self-Optimising: adapts its configuration and structure in order to achieve the best/required performance. l Self-Protecting: predicts, prevents, detects and identifies attacks, and to protect itself against them. l Open and extensible specification è Several levels of autonomicity depending on:  autonomic controllers implemented  autonomicity level implemented by each controller

12. Outline  A Summary of Fractal  Communication semantics  Dynamic Controllers, adaptativity and Autonomicity  Parallelism and Distribution  The GCM in ProActive

13. Parallel Components: Distribution l Notion of Virtual Nodes  distribution  Maps the virtual architecture to a physical one  One can envisage more sophisticated information such as, for instance, topology information, QoS requirements between the nodes, etc. l Parallel components can  Be distributed or not  Admit several implementation  adaptive implementations

14. Collective interfaces l Multicast l Gathercast l SPMD by assembly of components è Allow MxN communications.

15. Current situation (Fractal model) Simple type system Component type  types of its interfaces Interface type :  Name  Signature  Role  Contingency  Cardinality: single or collection (one-to-one)

16. Proposal 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 l Dedicated and customizable controllers l Data distribution strategy defines exposed types

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

19. 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 (e.g., into lists) Result: redistribution of results Redistribution function

20. Outline  A Summary of Fractal  Communication semantics  Dynamic Controllers, adaptativity and Autonomicity  Parallelism and Distribution  The GCM in ProActive

21. A Prototype GCM implementation in ProActive l Distributed Fractal implementation l Support for deployment l Asynchronous communication l “Each component is an Active Object” l Plus Multicast and gathercast

22. Configuration of Collective Interfaces Interface type = [name, signature, role, contingency, cardinality] Metadata in signature {class, method, parameter} @paramDispatch=BLOCK void foo(List l) Distribution strategies  Block, cyclic  Round-robin  User-defined

23. InterfaceType interface: string getFcItfCardinality(); TypeFactory interface: InterfaceType createFcItfType ( … string cardinality )… CollectiveInterfacesController  Collective interface policy  On a per-interface basis  Specified at instantiation-time  May be updated dynamically API: Dedicated Controllers

24. Summary / Conclusion l ProActive/Fractal: Fractal with distributed components and asynchronous method invocation l Multicast/Gathercast specification + implementation: collective communications l Deployment of components l « Component Oriented SPMD » l Experiments and validation  a prototype implementation of the GCM: ProActive/GCM

25. Current and Future Works l MxN as an optimization for the coupling of multicast and gathercast l Generalisation of the data distribution and gathering policies for multicast and gathercast (new conditions on typing) l Refinement of the specification and implementation of component controllers l …

27. Summary: Requirements and Concepts Hierarchical composition  Fractal Extensibility  From Fractal design  dynamic controllers (for non-functional)  open and extensible communication mechanisms Support for reflection  Fractal specification and API Lightweight  Conformance levels  No controller imposed ADL with support for deployment  Virtual Nodes Packaging  packaging being defined by the Fractal community Support for deployment  Notion of virtual nodes  ADL with support for deployment

29. Sequential and parallel implementation  XML component specifications, and Multicast-Gathercast interfaces allow plugging and unplugging several componentsto the same interface dynamically Asynchronous ports and Extended/Extensible port semantics  Asynchronous Method Invocation as default but can be defined via tags; + Possibility to support method calls / message oriented / streaming / … Group related communication on interfaces  Multicast / Gathercast interfaces Interoperability  Exportation and importation as web-services Language neutrality  API in various languages  Various interface specifications  exportation of a web-service port

30. Adaptivity:  Globally due to dynamic controllers Exploit Component Hierarchical abstraction for adaptivity  Dynamic controllers plug/unplug component  Fractal: content + binding controller Give a standard for adaptive behavior and unanticipated extension of the model  Dynamic controllers Give a standard for the autonomic management components  Autonomic controllers Plug/unplug non-functional interfaces  Dynamic controllers Parallel binding: Well-defined and verifiable composition  Multicast / Gathercast

31. Conclusion Future (technical) works: model has to be refined  Technical issues (dynamic controllers)  APIs  extended ADL (behaviour, dynamic controllers)  … Like in Fractal, we aim at a multi-level specification,  an implementation of the GCM can be level 1.1 Fractal compliant and level 1.2.1 GCM compliant. GCM levels to be specified Next steps: assessment, experiments, (reference) implementations (  GridCOMP)

32. Questions / Comments ?

33. Dynamic Controllers As suggested as an extension of Fractal, controllers can be components (they still belong to the membrane)

37. Multicast interfaces

38. Gathercast interfaces

39. Multicast interfaces Results as lists of results Invocation parameters may also be distributed from lists

40. Current situation in Fractal: 2 cardinalities SingleCollection