Download presentation
Presentation is loading. Please wait.
1
Interoperability & Standards
Giuseppe Andronico – Chain Workshop – Lyon 2011/09/21
2
Middlewares in CHAIN Middleware Infrastructure UMD EGI Europe GOS
CNGrid China GARUDA India OurGrid The OurGrid Community Brazil
3
Status of middlewares UMD
Actually packaged by EGI, based on EMI and Globus Strong interaction with and standards compliance
4
Status of middle wares GOS
Actually at version 4.0, maintained from several institutions headed from Chinese Academy of Sciences This stage of the project is closing, they are considering to evolve in new directions Strongly based on GLOBUS, but actually completely rewritten in Java with a quite different layout
5
Status of middle wares GARUDA
Based on GLOBUS and the meta scheduler GridWay 5.7 the resources information system is based on GLOBUS MDS, not on BDII certificates of the euindia VO directly mapped on CEs’ gridmapfile without VOMS the data management is limited to gridftp in the head node of CE, without gridftp clients in the WNs.
6
Status of middle wares OurGrid
Is a peer-to-peer computational grid targeted to run Bag-of- Tasks applications on the idle cycles of corporations' desktops. It is based on three main elements: OurGrid Broker: is the scheduler, usually installed on the machine of the user that is submitting jobs to the grid; OurGrid Peer: is in charge of managing the desktops on a site, i.e. an administrative domain; it also allows the discovery and allocation of desktops that are available in remote sites; OurGrid Worker: runs in the desktops that are made available to the grid; is in charge of identifying when the desktop can be used by the grid, and protect the desktop from any harm that could be caused by the grid jobs it executes.
7
Basic point At least 2 interoperability levels: Services level
Interoperability between web services of different middlewares Applications level Solution to submit specific applications to several infrastructures; can be obtained, for example, using meta schedulers or scientific gateways Our choice is solution 1, using standards promoted from GIN
8
Referred standards AAI: shibboleth for translating authorization and authentication resources index: BDII Job submission and management: SAGA + OGSA-BES to abstract from middleware implementation Data access and management: SRM + LFC
9
Interoperability plan
Every middleware should integrate such technologies in their stacks In this way jobs should be able to go from one infrastructure to another gLite GOS Standards Standards Job GARUDA Standards OurGrid Standards
10
AAI AAI: every middleware should add a plugin able to convert authorization and authentication information forth and back from shibboleth MW2 AAI Shibboleth MW1 XML/SOAP
11
Job submission Abstraction from specific middleware implementations in: Sending job request Receiving and handle job request Returning job output Our trial solution is providing each middleware of software adapters based on SAGA and OGSA-BES
12
Job submission and management
SOAP MW1 OGSA-BES interface SAGA + OGSA-BES adapter MW2 Every middleware should provide two elements: An OGSA-BES interface that will act as a standardization layer between the infrastructure and the rest of the world An element collecting request to other middleware(s) and handling them in SAGA, to be abstracted from the middleware, and the BES adapter to be issued to the other infrastructure without any knowledge of remote middleware This should be working for most of the job related features
13
Detailed view BDII: every middleware should provide a tool to:
publish its computing resources to a BDII query BDII to publish other infrastructure resources in its own system SRM: every middleware should provide a SRM interface to its storage LFC: every middleware should be: publish its files to LFC, making reference to the SRM interface query LFC to retrieve other infrastructures files and publish them in its internal system
14
China In contact with people of BUAA to try to understand if better to rewrite EUChinaGRID gateway or to develop add-ons to GOS At the moment GOS development is stopped due to new plans for e-Infrastructure in China
15
India Discussion are going on to understand where present general ideas better fit in the Indian middleware Some functionalities could be allocated on GridWay reusing existing solutions We have to check yet for available resources
16
OurGrid On going discussion with OurGrid people
A possible solution is to adapt to present ideas the gateway developed for interoperability with gLite
17
Conclusions The present proposal is a starting point
The present proposal is currently used to develop in details a plan to implement interoperation between the middlewares
18
Resources What Link AAI
BDII SRM LFC OGSA-BES SAGA DRMAA
19
Thank you !
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.