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

2 Outline Background: H2O and MOCCA Motivation CCA and Fractal – comparison Approach to interoperability Typing and ADL issues Technical approach Application example Next steps

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 and Ruby scripting for application asssembly

5 GCM (Current state) 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 Component Identity Binding Controller LifeCycle Controller Content Controller Content Controller

6 Motivation Framework interoperability is an important issue for GCM Existing component models and frameworks for Grids  CCA, CCM Already existing „legacy” components Web Services are not enough  Performance  Composition ProActive/Fractal and H2O/MOCCA – alternative Java-based frameworks for distributed computing: can they interoperate?

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 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 setServices() 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)

10 Technical approach – CCA controller Creates glue components for all ports (client and server) Connects glue to CCA system (using CCA builder) and to membrane (using BC)

11 Glue Components Server Glue:  Deployed as Fractal component  Uses MOCCA client code to delegate invocation to CCA interface  Can be also deployed on H2O kernel Client Glue:  Deployed as CCA component in H2O kernel  Launches ProActive runtime in H2O kernel  Creates Fractal component in this runtime Both:  Can be generated from the interface type (TODO)

12 ProActive + MOCCA MOCCA invocations are synchronous  Composite (membrane) should be synchronous to avoid deadlocks  Or, we may consider generating glue with wrapped types (IntWrapper, etc) – this changes types of interfaces Class loading issues  The classes generated by ProActive runtime must be visible to the code running in H2O kernel  The RMI class loading works fine if the codebase is set properly on ProActive side

13 Application Example: Modeling of Gold Clusters Clusters of atoms  Very interesting forms between isolated atoms or molecules and solid state  Important for the technology of constructing nanoscale devices. Modeling of clusters  Several energy minimization methods such as MDSA or L-BFGS,  Choosing an empirical potential  Highly compute-intensive  The optimal result depends on the number of possible iterations and initial configurations for each simulation run.

14 Case study: gold cluster simulation MOCCA version  Master-worker with additional feedback loop  Multiple (group) connections  Deployments on cluster and on small Grid testbed  getMolecule() comm. Model  Buffered ports  GCM Wrapping  Glue for Go and Molecule ports  New output generator implemented in ProActive  Active objects vs. Java threads

15 Roadmap Wrapping of a single CCA component as Fractal primitive: prototype working  Wrapper generation (not runtime)  ADL generation Next step: extend the solution into framework interoperability: proof of concept working  CCA controller  Glue components  ProActive Runtime deployed on H2O Kernel  Class loading issues solved To do:  Implementation work – make the solution usable  Test on real examples  Benchmarks

16 Thank you!