GCM and CCA Towards Interoperability between Component Models

GCM and CCA – Towards Interoperability between Component Models 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 – I 3 S – CNRS – UNSA, Sophia-Antipolis, France 1

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

Background: CCA and H 2 O • 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 • H 2 O § Distributed resource sharing platform § Providers setup H 2 O kernel (container) § Allowed parties can deploy pluglets (components) § Separation of roles: decoupling • Providers from deployers • Providers from each other § RMIX: efficient multiprotocol RMI extension 3

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

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

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

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 § Binding. Controller in Fractal vs. Builder. Service in CCA § No Content. Controller in CCA (and no hierarchy) § Factory interface in Fractal vs. Builder. Service in CCA § Attribute. Controller in Fractal vs. Parameter. Port in CCA § No ADL in CCA 7

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 8

Solutions to typing issues 1. 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 set. Services() call) 2. Manual description of a CCA component in ADL format § § Pros: Generic solution Cons: Require additional task from developer 3. (Semi)automatic generation of ADL • May combine approach 1. and 2. 4. Reuse existing CCA type specifications (SIDL, CCAFFEINE scripting, others – not standardized) 9

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

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

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