Maciej malawski marian bubak ludovic henrio matthieu morel francoise baude denis caromel
This presentation is the property of its rightful owner.
Sponsored Links
1 / 12

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


  • 82 Views
  • Uploaded on
  • Presentation posted in: General

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.

Download Presentation

GCM and CCA – Towards Interoperability between Component Models

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

  • 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

  • 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

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

Content

Controller

Component

Identity

Binding

Controller

LifeCycle

Controller

Controller

Content

GCM (Current state)


Motivation

Motivation

  • 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

  • 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

  • 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

  • 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

  • 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

  • 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

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


  • Login