ProActive GCM

1
ProActive GCM CCA Interoperability

• Maciej Malawski, Ludovic Henrio, Matthieu Morel,
  Francoise Baude, Denis Caromel, Marian Bubak

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
• http//www.icsr.agh.edu.pl/mambo/mocca

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

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

• 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 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 clusterand on small Grid testbed
• getMolecule() comm.Model
• Buffered ports
• GCM Wrapping
• Glue for Go and Moleculeports
• New output generatorimplemented 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!