GCM and CCA – Towards Interoperability between Component Models

1. Maciej Malawski, Marian Bubak, Ludovic Henrio, Matthieu Morel, Francoise Baude, Denis Caromel Institute of Computer Science AGH, Kraków, Poland Academic Computer Centre CYFRONET-AGH, Kraków, Poland INRIA – I3S – CNRS – UNSA, Sophia-Antipolis, France GCM and CCA – Towards Interoperability between Component Models

2. Outline • Background: H2O and MOCCA • Motivation • CCA and Fractal – comparison • Approach to interoperability • Typing and ADL issues • Next Steps: Roadmap

3. Background: CCA and H2O • Common Component Architecture (CCA) • Component standard for HPC • Uses and provides ports described in SIDL • Support for scientific data types • Existing tightly coupled (CCAFFEINE) and loosely coupled, distributed (XCAT) frameworks • H2O • Distributed resource sharing platform • Providers setup H2O kernel (container) • Allowed parties can deploy pluglets (components) • Separation of roles: decoupling • Providers from deployers • Providers from each other • RMIX: efficient multiprotocol RMI extension

4. MOCCA – a Distributed CCA Framework Based on H2O • Each component is a separate pluglet • Dynamic remote deployment of components • Components packaged as JAR files • Security: Java sandboxing, detailed access policy • Using RMIX for communication – efficiency, multiprotocol interoperability • Flexibility and multiple scenarios – as in H2O • MOCCA_Light: pure Java implementation • Java API or Jython scripting for application asssembly • http://www.icsr.agh.edu.pl/mambo/mocca

5. Based on Fractal Model Deployment Functionalities Asynchronous and extensible port semantics Collective Interfaces Autonomicity and adaptivity thanks to “autonomic” and “dynamic” controllers Support for language neutrality and interoperability Content Controller Component Identity Binding Controller LifeCycle Controller Controller Content GCM (Current state)

6. Motivation • Framework interoperability is an important issue for GCM • Existing component models and frameworks for Grids • CCA, CCM • Already existing „legacy” components

7. Fractal vs. CCA • Similarities: general for most component models • Separation of interface from implementation • Composition by connecting interfaces • Differences • Fractal components are reflective (introspection) vs. the CCA components are given initiative to add/remove ports at runtime • BindingController in Fractal vs. BuilderService in CCA • No ContentController in CCA (and no hierarchy) • Factory interface in Fractal vs. BuilderService in CCA • AttributeController in Fractal vs. ParameterPort in CCA • No ADL in CCA

8. Approaches Discussed • Single component integration • Wrapping a CCA component into a primitive GCM one • Allow to use a CCA component in a GCM framework • Framework interoperability • Ability for two component frameworks to interoperate • Allow to connect a CCA component assembly (running in a CCA framework) to a GCM component application

9. Solutions to typing issues • Generate the type of a wrapped CCA component at runtime (at initialization) • Pros: fully automated • Cons: restricts to usage of ports which are declared by CCA component during initialization (at setServices() call) • Manual description of a CCA component in ADL format • Pros: Generic solution • Cons: Require additional task from developer • (Semi)automatic generation of ADL • May combine approach 1. and 2. • Reuse existing CCA type specifications (SIDL, CCAFFEINE scripting, others – not standardized)

10. Technical approach • The Fractal framework creates the Wrapper. • The BuilderService is returned by a bootstrap method. • From the type of Wrapper Component in the ADL the GluePorts it has to create. • Each GluePort should expose a CCA port and a Fractal interface • The wrapper uses the BuilderService to connect the exported CCA uses ports to corresponding GluePorts. Then: • Fractal BindingController may be used to connect exported ports to other interfaces of the Fractal application. • LifecycleController can be used to start/stop the wrapper.

11. Next Steps: Roadmap • Start with wrapping of a single CCA component as Fractal primitive • Use Java-based ProActive and MOCCA implementations • Next step: extend the solution into framework interoperability • CoreGRID REP accepted 

12. Technical approach • The Fractal framework requests the creation of Wrapper Component. • The BuilderService is returned by a bootstrap method. • Knowing the type of Wrapper Component from an ADL the wrapper knows how many GluePorts it has to create. • Each GluePort should expose a CCA interface • The Wrapper using BuilderService creates GluePort for each exported Uses port, as a CCA component • Together with a previous step, the Wrapper creates a Fractal GlueInterface for each of the GluePorts. • In case of wrapping a CCA uses ports, the Wrapper passes the reference of the GlueInterface to the GluePort. • In case of wrapping a CCA provides port, the created Fractal GlueInterface has to obtain the ComponentID and the port name, in order to connect to the provides port of exported component. • The wrapper uses the BuilderService to connect the exported CCA uses ports to corresponding GluePorts. • Fractal BindingController may be used to connect exported ports to other interfaces of the Fractal application. • LifecycleController can be used to start/stop the wrapper.