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 !