Maciej malawski marian bubak ludovic henrio matthieu morel francoise baude denis caromel
Download
1 / 12

GCM and CCA – Towards Interoperability between Component Models - PowerPoint PPT Presentation


  • 138 Views
  • Uploaded on

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, Polan d INRIA – I3S – CNRS – UNSA, Sophia-Antipolis, France.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' GCM and CCA – Towards Interoperability between Component Models' - casey


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Maciej malawski marian bubak ludovic henrio matthieu morel francoise baude denis caromel

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


Outline
Outline Morel, Francoise Baude, Denis Caromel

  • Background: H2O and MOCCA

  • Motivation

  • CCA and Fractal – comparison

  • Approach to interoperability

  • Typing and ADL issues

  • Next Steps: Roadmap


Background cca and h2o
Background: CCA and H2O Morel, Francoise Baude, Denis Caromel

  • 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


Mocca a distributed cca framework based on h2o
MOCCA – a Distributed CCA Framework Based on H2O Morel, Francoise Baude, Denis Caromel

  • 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


Gcm current state

Based on Morel, Francoise Baude, Denis CaromelFractal 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)


Motivation
Motivation Morel, Francoise Baude, Denis Caromel

  • Framework interoperability is an important issue for GCM

  • Existing component models and frameworks for Grids

    • CCA, CCM

  • Already existing „legacy” components


Fractal vs cca
Fractal vs. CCA Morel, Francoise Baude, Denis Caromel

  • 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


Approaches discussed
Approaches Discussed Morel, Francoise Baude, Denis Caromel

  • 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


Solutions to typing issues
Solutions to typing issues Morel, Francoise Baude, Denis Caromel

  • 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)


Technical approach
Technical approach Morel, Francoise Baude, Denis Caromel

  • 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.


Next steps roadmap
Next Steps: Roadmap Morel, Francoise Baude, Denis Caromel

  • 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 


Technical approach1
Technical approach Morel, Francoise Baude, Denis Caromel

  • 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.


ad