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, PolandINRIA – 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

ContainerProvider host

Deploy Lookup& use

Provider Client

<<create>>

B

A

Provider

<<create>>A

B

Container

Lookup& use

Client

Deploy Provider,Client,

or Reseller

Provider host

Traditional model

Proposed model

ContainerProvider host

Deploy Lookup& use

Provider Client

<<create>>

BB

AA

Provider

<<create>>AA

BB

Container

Lookup& use

Client

Deploy Provider,Client,

or Reseller

Provider host

Traditional model

Proposed model

• 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

ComponentPlugletComponent

Pluglet

CCAComponent

ComponentPluglet

CCAComponent

BuilderPluglet

H2O Kernel

BuilderService

Invoke

Manage

Builder

CCACCAPluglet Pluglet

Builder Builder

CCACCA

Pluglet Pluglet

BuilderBuilder

CCACCA

Pluglet Pluglet

Builder

MoccaMainBuilder

MoccaMainBuilder

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

ComponentIdentity

BindingController

LifeCycleController

ContentController

ContentController

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

Wrapper

CCA Component

C BC

cca.Services

Wrapper

CCA Component

C BC

CCA Component

CCA Component

BuilderService

GlueGlue

CCA Framework

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)

CCAController

CCA Component

C

CCA Component

CCA Component

BuilderService

Server Glue A

CCA Framework

ClientGlue B

BC

BC

WA

CCA

A AA A

B B B BB

H2O Kernel

H2O Kernel

H2O Kernel

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)

CCA Component Client

Glue B

BC

B B B B

H2O Kernel

CCA Component

Server Glue A

WA

AA A

H2O Kernel

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

generatorimplemented in ProActive

Active objects vs. Java threads

Generator Control

Starter

Simulated Annealing Gather

MoleculeMolecule

...

Molecule

Annealing Control

Outputgenerator

Molecule

Configuration Generator

Simulated Annealing

Storeroom

Simulated Annealing

Control

CCAController

C BCCCA

GoPortglue

Moleculeglue

GoPort

MoleculeProActive

OutputGenerator

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!