J Grid Computing (2009) 7:319–333DOI 10.1007/s10723-009-9134-3

An Interoperable Grid Information System for IntegratedResource Monitoring Based on Virtual Organizations

Timo Baur · Rebecca Breu · Tibor Kálmán · Tobias Lindinger · Anne Milbert ·Gevorg Poghosyan · Helmut Reiser · Mathilde Romberg

Received: 4 November 2008 / Accepted: 17 August 2009 / Published online: 3 September 2009© Springer Science + Business Media B.V. 2009

Abstract In many Grid infrastructures differentkinds of information services are in use, whichutilize different incompatible data structures andinterfaces to encode and provide their data. Homo-

This work has been partly funded by the D-GridInitiative of the German Federal Ministry ofEducation and Research (FKZ01IG07010A).

T. Baur · H. ReiserLeibniz Supercomputing Centre, Boltzmannstr. 1,85748 Garching, Germany

R. Breu · M. Romberg (B)Jülich Supercomputing Centre,Forschungszentrum Jülich GmbH,52425 Jülich, Germanye-mail: m.romberg@fz-juelich.de

T. KálmánGesellschaft fuer wissenschaftliche DatenverarbeitungmbH, Am Fassberg 11, 37077 Göttingen, Germany

T. LindingerLudwig-Maximilians-Universität München,Oettingenstr. 67, 80538 München, Germany

A. MilbertMax Planck Institute for Gravitational Physics,Am Mühlenberg 1, 14476 Golm, Germany

G. PoghosyanSteinbuch Centre for Computing,Forschungszentrum Karlsruhe GmbH,Hermann-von-Helmholtz-Platz 1,76344 Eggenstein-Leopoldshafen, Germany

geneous monitoring of these infrastructures withthe monitoring data being accessible everywhereindependently of the middleware which providedit, is the basis for a consistent status reportingon the Grids’ resources and services. Thus, inter-operability or interoperation between the differ-ent information services in a heterogeneous Gridinfrastructure is required. Monitoring data mustcontain the identity of the affected Virtual Orga-nization (VO) so that it can be related to theresources and services the VO has allocated toenable VO-specific information provision. Thispaper describes a distributed architecture for aninteroperable information service, which com-bines data unification and categorization withpolicies for VO membership, VO resource man-agement and data transformations. This servicebuilds the basis for an integrated and interoperat-ing monitoring of Grids, which provide their datato more than one VO and utilize heterogeneousinformation services.

Keywords Grid monitoring · VirtualOrganizations · Grid interoperability ·Grid information system · VO-specificinformation provisioning

1 Introduction

With Grid computing becoming mature and beingused in large production infrastructures [1–5], the

320 T. Baur et. al.

role of monitoring is of growing importance fortheir successful operation and usage. Grid moni-toring observes the status of a Grid infrastructure,in particular its resources, services and processesincluding user jobs, and thereby facilitates a Grid’sreliable operation and a high availability of itscomponents. It also builds the basis for checkingand controlling the compliance of a Grid’s servicequality with the service level agreements (SLAs)made between providers and Virtual Organiza-tions (VOs). It enables service benchmarking, cor-rect accounting and billing as well as scheduling ofresource and service usage.

To fulfill such assignments, Grid monitoringrelies on data provided by information services.In spite of the importance of monitoring, largeinfrastructures with stakeholders from differentorganizations often use incompatible technical re-alizations, apply heterogeneous data structures toencode their data, and offer different interfaces toprovide it. This is caused either by the absence ofstandardization, or, where standards exist, by de-signs and best-practice approaches neglecting theexisting standards. The situation is further com-plicated by the fact that many standards are stillevolving and that, repeatedly, transitions to newversions must be incorporated into the infrastruc-tures. As a result, the provisioning of high-qualityGrid operations requires solutions for interopera-tion and integration of Grid information servicesand data. Monitoring data needs to be accessiblein the Grid independently of the organization orthe technical platform which provides the access.

VO-specific access control thereby plays animportant role. Consumers of monitoring data—respectively VOs—need the data specifically re-lated to the resources and services they operateor which have been allocated to them. Thedata gathered by the Grid’s information servicesshould therefore be provisioned to a user accord-ing to his organizational context, that is the VOshe is a member of. We call such a mechanismVO-awareness.

In the following, we describe a distributedmonitoring architecture for an interoperableand integrated information service as developedwithin the German e-Science monitoring projectD-MON [6] as well as its implementation withinthe D-Grid infrastructure set up by the German

e-Science initiative [7]. The developed servicecombines data unification and categorization withpolicies for VO membership, VO resource man-agement, and data transformations between dif-ferent data models. It realizes VO-aware access tomonitoring data gathered from multiple resourceproviding organizations as well as different Gridmiddlewares.

The remainder of this paper is structured inthe following way: Section 2 outlines relatedwork by introducing architectures, standards andinterfaces used for Grid monitoring as well asapproaches to the integration problem and VO-based data provisioning. Section 3 then illustratesthe practical relevance of the problem using theexample of the D-Grid infrastructure, a hetero-geneous Grid infrastructure which utilizes multi-ple middlewares and their respective monitoringservices. Motivated and guided by this scenario,Section 4 presents requirements for a homoge-neous Grid monitoring system which is capableof overcoming the identified issues. The designof the D-MON monitoring system is the topic ofSection 5 and the details about the implementa-tion are covered in Section 6. Results, first experi-ences as well as an outlook are given in Section 7.

2 Related Work

There are a multitude of concepts in the Gridcommunity which handle the problem of monitor-ing Grid resources and services. As a basic blue-print, the Open Grid Forum has defined the GridMonitoring Architecture (GMA, [8]), which de-scribes major components for a Grid monitoringsystem as well as their essential interactions. TheGMA is a producer/consumer-based architectureseparating data discovery from data transfer. Ituses directory services to support discovery andinformation delivery between information pro-ducers and consumers. A producer first contactsthe directory services and registers its existenceand the type of information it wants to publishto the Grid. A consumer uses the directory ser-vices to discover information of interest and lo-cate the respective producers. The consumer thenmay initiate direct interaction with the discoveredproducer, and the producer in turn sends the

Interoperable Grid Information System 321

requested data to the consumer without furtherinvolvement of the directory service. GMA is scal-able and avoids single points of failure.

Based on the GMA architecture, sophisticatedarchitectures have been developed, such as theAggregator Framework of the Monitoring andDiscovering System (MDS4, [9]) or the Rela-tional Grid Monitoring Architecture (R-GMA,[10]). MDS4 can be queried using the Web Ser-vices Resource Framework (WS-RF, [11]), whileR-GMA acts like one large relational databaseutilizing standard SQL commands. Both archi-tectures have their advantages and their imple-mentations are important parts of the middlewareimplementations of the Globus Toolkit [12] andgLite [13].

To achieve interoperability, using the methodof defining and adopting common open standards[14] and architectures is a common approach,which relies heavily on standardization and im-plementation processes. Because comprehensiveimplementations and roll-outs spanning differentGrid communities are difficult, costly and oftenpolitically charged, in certain scenarios a couplingof the architectures is a reasonable alternative.

In such scenarios, where it is favorable to op-erate multiple different implementations, e.g. dif-ferent middlewares, in parallel or where thereis no agreement on or knowledge of a commonstandard, non-intrusive components, e.g. bridges,become necessary to enable an integration.System integration has been a topic for a longtime. For example, [15] describes three kindsof architectural bridges which can be applied: amulti-architectural platform, management gate-ways and multi-architectural agents. In our work,we concentrated on realizing a management gate-way which may act as a bridge between differentmonitoring services.

Hegering et al. [15] also point out that integra-tion can be realized by bridging communication(e.g. interfaces), information (e.g. data descriptionschema), organization (e.g. roles), and functionalmodels (e.g. queries). For achieving successfuldata exchange, we concentrated on building abridge which realizes compatibility of informationand communication models in an agile way. Thisbridge furthermore enables the retrieval of moni-toring data according to roles and organizations.

In the area of information models the GridLaboratory for a Uniform Environment (GLUE)information schema [16] is an example of an ab-stract data model for describing Grid services andresources. The GLUE project originally was ajoint effort by the European DataGrid (EDG,[17]) and DataTAG [18] projects and the interna-tional Virtual Data Grid Laboratory [19] project.Today many major Grid projects such as EnablingGrids for E-sciencE [2], Worldwide Large HadronCollider (LHC) Computing Grid [20] and theOpen Science Grid [21] have adopted the GLUEschema. The GLUE Working Group in the OpenGrid Forum (OGF, [22]) is working on improv-ing the schema. It proposed a major revision ofthe GLUE schema, version 2.0. Thus there is ahigh possibility that it will be deployed in manyinfrastructures in parallel with other schemata.GLUE 2.0 is the only model for Grid resourcesthat supports Virtual Organizations, called User-Domains in the schema. Other information mod-els are for example Usage Record (UR, [23]) fromOGF and the D-Grid Resource Description Lan-guage (D-GRDL, [24]). OGF’s UR model withits interface Resource Usage Service (RUS, [25])focuses on job accounting information and doesnot provide general resource information whichare essential for Grid Monitoring. D-GRDL hasbeen developed within the German e-Science ini-tiative for describing arbitrary sets of resources.D-GRDL offers a flexible but very abstract frame-work for the description of monitoring data. Anadditional disadvantage of a data schema based onD-GRDL is that it would be specific to D-Grid.

A standardized interface for the exchange ofstate data between Grid components was pro-posed by the OGF, the Web Services ResourceFramework (WS-RF, [11]), which is alreadywidely used. Nevertheless, there are different ver-sions in use and many popular monitoring servicesjust ignore that standard. Other methods to ex-change Grid monitoring data are using XML orREST (Representational State Transfer, cf. [26]).

As opposed to past approaches to integration ofdistributed systems, Grid computing incorporatesthe concept of Virtual Organizations. For this rea-son, the necessity of VO-aware Grid services hasbeen described in [27], and functional mechanismsas well as an architecture for interoperable and

322 T. Baur et. al.

VO-aware monitoring of dynamic Virtual Organi-zations have been discussed in [28]. In the work athand, we apply and extend these ideas and detailthe design and concrete implementation of anintegrated, VO-aware service that provides Gridmonitoring data.

3 Scenario

The D-Grid infrastructure set up by the Germane-Science initiative [7] enables users from manyscientific fields, grouped into communities real-ized as VOs, to exploit Grid computing for theirspecific applications. It is a large and complexGrid infrastructure with stakeholders from dif-ferent organizations. In this environment incom-patible technical realizations with heterogeneousdata structures and interfaces emerge easily. Thehighly diverse sets of applications coming fromthe scientific communities are differently suitedfor the various available middleware solutions.Therefore, the infrastructure combines the threemiddleware installations of Globus Toolkit [12],gLite [13], and UNICORE [29] as well as dCache[30] and OGSA-DAI [31] for data management.In the D-Grid scenario, compute resources areoffered through all three middleware solutions orthrough either of them. The communities use themiddleware they are familiar with and which arebest suited for their applications.

The communities constitute Virtual Organiza-tions (VOs) which get access to the subset ofresources contributed to that VO. In that sensea VO is not just a group of users but also con-sists of virtual resources and services, those whichare available for use by the specific community.As a consequence, all Grid services have to beVO-aware to allow different contexts of resourceand service allocation with respect to communityspecific requirements and technology.

Monitoring such a complex infrastructure is anambitious task as each of the middleware imple-mentations has its own notion of, and tools formonitoring. Up to now, monitoring for the dif-ferent middleware solutions is often done in amiddleware specific way: Globus sites use theMDS4 [32] information service with a GridCSMWeb interface [27]; gLite resources are monitored

by Site Functional Test (SFT) [33] which baseson information from the BDII information ser-vice. The reports are displayed through a Webinterface; UNICORE 5 sites are not monitoredbut UNICORE 6 sites are monitored throughthe Common Information Service (CIS) [34] thatcomes with a Google-maps user interface.

The result is a multitude of sources each pro-viding only a fraction of the desired information.This complicates the operation of comprehensiveGrid information services, which should be usablefrom everywhere in the Grid. Obviously, in thatsituation a more homogeneous and comprehen-sive approach is desirable.

Most of the Grid information services in usehave the disadvantage of being focused on phys-ical entities thus ignoring the actual mapping ofresources and services onto VOs. A VO-centricapproach would simplify a user’s life as only infor-mation belonging to their VO would be extractedand presented to them, whereas all informationthey have no use of (such as the providers’ clusterstatus) would be filtered. In addition, a VO-basedprivacy protection is possible. Analyses of the D-Grid scenario and concepts with respect to mon-itoring (cf. [35–37]) revealed several issues: Oneof the major shortcomings of a big infrastructureis that building several autonomous (monitoring)service components may result in several logicalGrids without data interchange. To tackle thisissue for the monitoring service, the German e-Science initiative established the research projectD-MON [6].

The loss of interoperability in a Grid of mid-dlewares may lead to problems in the Grid’s op-eration, as the following use-case illustrates. Forexample, a scheduler used in one middleware isunaware of resource allocation mappings and jobsthat belong to foreign middleware components.Parts of a Grid job may rely on resources availablein a gLite based infrastructure such as EGEE [2],while other parts need resources available in aUNICORE based infrastructure such as DEISA[1]. Besides interoperation of authorization sys-tems, job submission, data transfer, and schedul-ing services, also the monitoring systems have tointeroperate in order to allow a smooth overalljob scheduling as well as resource and serviceoperation and maintenance.

Interoperable Grid Information System 323

Integrated monitoring services, which dynam-ically provide exhaustive information about theactual state of components from multiple moni-toring systems, are a step towards integrated andinteroperating Grids.

4 Requirements

The D-Grid scenario as described in Section 3provides heterogeneous middleware installationsin an infrastructure used by a large number ofcommunities or Virtual Organizations. The mon-itoring of such an infrastructure must serve dif-ferent purposes. In general, it should provide theinformation for Grid operation, for schedulingand accounting, for users searching and keepingtrack of resources, and for job monitoring. WithinD-Grid these functions must integrate the de-ployed middleware solutions to provide the over-all information. Thus an integrated gateway musthave the ability to extract and transform monitor-ing data from different Grid information servicesin a non-intrusive way. In addition it must providea VO-aware Grid service in a standardized way.

Since Globus Toolkit, gLite and UNICOREare installed on almost every compute resourcein the Grid, a union of the monitoring data maygenerate duplicate as well as diverging datasets belonging to the same resource. An inte-grated monitoring system must augment data setswith provenance information. Amongst others thesource and the time of retrieval of the data mustbe supplied. In this paper, provenance informa-tion is used to refer to the information that canhelp trace back the derivation history of the mon-itoring data. A detailed view of data provenanceresearch in the scientific and business domains anda taxonomy of data provenance techniques hasbeen surveyed in [38].

Access to monitoring data should be providedon a need-to-know basis and the different rolesof the requesters have to be accounted for. Forexample, a Grid operator needs to know whethera system and its services are fully functional whilea user in search of a resource must be suppliedwith resource characteristics like number of CPUsand available applications. As the collected in-formation from all resources within an infrastruc-

ture spans all Virtual Organizations using theinfrastructure and providing resources to it, theinformation sent to a requester must be VO-specific. Therefore the integration of VO manage-ment systems into Grid monitoring architecturesis essential to obtain VO-specific information. Ex-amples for VO-specific information are generalinformation about a VO, the users belonging tothe VO, the resources and services allocated to it,and which resources can be accessed by VO mem-bers. In order to implement VO-based monitoringproper access control has to be offered with it.

Other requirements are related to more gen-eral aspects. A common goal for all developmentswithin the D-Grid environment is their scalabil-ity and extensibility. The monitoring system mustbe capable of providing information about themonitored items close to real time even whenthe numbers of sites, resources, users, roles, andVOs are increasing. Important for sustainabilityof the system is also the support of standardsfor protocols and data structures. The systemto be developed should therefore be compliantwith the Grid Monitoring Architecture (GMA)[8], the Web Services Resource Framework(WS-RF) [11], OGSA Data Architecture [39],and the emerging GLUE 2.0 schema [16] whilesecurity aspects such as authentication and autho-rization have to be taken into account. It is nec-essary to be able to pass monitoring informationfrom the integrated monitoring platform back tomiddleware specific implementations, which is ex-tremely important for Grid scheduling systems inmulti-middleware Grids. They have to be capableto distribute jobs within the whole Grid basedon information about the workload generated byall available middleware installations, not only asingle one.

5 System Design

This section discusses design options for an in-tegrated monitoring system fulfilling the require-ments given in Section 4. An architecture for theintegration of several heterogeneous monitoringsystems builds the core of the system to be de-signed. On top of it interfaces to monitoring dataand VO management information are modeled.

324 T. Baur et. al.

5.1 Basic Architecture

Several approaches to realize a monitoring sys-tem with the characteristics given above havebeen considered and their individual characteris-tics evaluated (see also [40]). To realize a dataexchange between different monitoring systems,one option is building multiple bidirectional gate-ways between each pair of monitoring systems.This solution is hardly scalable as the overallnumber of gateways needed equals the squaredamount of monitoring systems. Besides, prevent-ing data duplication, which results from differentnaming and conventions, is a major challenge andthe provision of all data in real-time can hardlybe guaranteed.

An alternative would be defining one of themonitoring systems as the privileged system tocollect all monitoring information. Then for eachmonitoring system only one gateway is neededwhich transfers data to and from the privilegedsystem. While this solution reduces the amount ofgateways needed to the linear amount of existingmonitoring systems, it is limited to the capabilitiesof the privileged system and strongly depends onthe future development of the privileged middle-ware; it furthermore contradicts the demand ofstrong interoperability. Additionally, it does notsolve the problem of real-time data provision andduplicated data either.

The disadvantages of these options lead toconsider another approach: An autonomous,middleware-independent service which utilizes astorage component, e.g. a database, with gate-ways connected to the underlying native moni-toring services. This method would scale with thenumber of supported information providers, whilebeing independent of a privileged middleware.

The comparison of the three design optionsidentifies the third one as the preferable basearchitecture. The following subsections build ontop of it.

5.2 Transformation of Monitoring Information

The interoperable Grid information system tobe developed must gather and incorporate datafrom heterogeneous Grid monitoring systems.To transform the complex monitoring data into

an integrated data structure efficiently, an auto-mated ETL-process (Extract–Transform–Load) isdefined. ETL is a data integration technique whichwas first described in [41].

The monitoring information is collected asyn-chronously by Grid middleware specific extractors(E), using different protocols and data models.The extracted Grid monitoring data is parsed,checked and transformed (T) in a flexible wayinto a common data structure, e.g. the GLUE 2.0schema. Finally the Grid monitoring data will bestored (L) in the target repository.

5.3 VO-aware Monitoring

In this subsection the design depicted so far isextended to cover the VO aspect described inSection 4. A VO-aware monitoring service can berealized by using external policy decision points(PDP) or policy engines which have knowledgeabout the actual mapping of resources and mem-bers onto VOs [27]. The term PDP has two fla-vors, organizational and technical. A political ororganizational PDP denotes a committee whichaggregates and coordinates the multilateral rela-tionships of the different contractors in a Gridsuch as resource and service providers or cus-tomers organized as VOs. The organizationalPDP may be hidden so that the contractual orpolitical mappings are not explicitly known. Atechnical PDP defines the mappings in a techni-cally and deterministically processable represen-tation. Unlike the organizational PDP it must notbe hidden. The representation can then be used asa template to compose the VOs as well as relatedmonitoring data according to the VO’s actual allo-cations of resources and services. In current Gridinfrastructures, amongst others, services like theVO Membership Services (VOMS) and Grid Re-source Repository Service (GRRS) [7] may serveas PDPs.

Figure 1 shows the functional components andtransactions of the system described above. Onthe left hand side the components necessary forthe integration of VO management layers intoGrid monitoring architectures are shown. Theseare policy decision points and information bases,which define the rules for VO memberships, theresource composition of a VO, and the rules

Interoperable Grid Information System 325

Fig. 1 Layout of theintegrated and VO-awareGrid monitoring service

VO-aware

Integrated

Service

AuthorizationPolicy

CompositionPolicy

VO Resource Management

PDP

VO Membership Management

PDP

VOViewVO1

VOViewVO2

VOViewVO3

TransformationRepository

PDP

IntegrationPolicy

homogenous data model

for data transformations. The components at thebottom represent the various Grid monitoringservices which provide the monitoring data.Transformation/ETL denotes the adaptors, whichtranslate the data using the integration policy. Thetransformed data is then integrated into the ho-mogeneous data model located in the storage atthe VO-aware integrated service. At the center ofthe VO-aware integrated service the View Genera-tion component is shown. It generates VO-relatedviews of the data directed by the compositionpolicy. Access to these views is granted by theservice only to members of the corresponding VO,according to the authorization policy defined by aVO Membership Management system.

5.3.1 VO-aware View Generation

The View Generation component shown in Fig. 1has to group the integrated monitoring data ac-cording to VOs. The data usually consists of in-formation about resources, services, and jobs thatexist within the Grid infrastructure. The VO re-

source management PDP provides the relationbetween resources or services and VOs. Convert-ing this mapping into syntactically and semanti-cally fitting data structures and integrating it withthe homogeneous data model lays the basis forVO-based monitoring of resources and services.The identifier of resources and services recordedin the resource management system as well as inthe source monitoring services must be uniqueand identical in order to allow a deterministicmapping of data sets to VO views. Updates inthe VO resource management system must fur-thermore trigger new view generation cycles tokeep the views consistent. For example the cre-ation of a new VO must trigger the creation ofan adapted access policy containing the new VO’spermissions.

5.3.2 Access Authorization and Authentication

In order to regulate access to the monitoring datain a VO-aware way, authentication and authoriza-tion methods are necessary. For each query the

326 T. Baur et. al.

monitoring system needs to know the identity ofthe querying entity (user or service) that wantsto retrieve the data. With this information, theVO membership management PDP can be askedfor the entity’s authorization. The authorizationinformation contains the querying entity’s VOsand thus the VOs’ views can be determined whichit is allowed to see. By using additional para-meters, the user can constrain the query to spe-cific VO views and a corresponding result can begenerated.

Authentication and authorization methods canbe based on VO management systems suchas VOMS (Virtual Organization ManagementService). They define the membership of accessingentities to specific VOs, information which can beused to find out which VO’s data an accessingentity is authorized to retrieve. Newer methodsuse a combination of VOMS services and SAML(Security Assertion Markup Language) [42] to getthe credentials of an accessing entity. As soon ascredentials of a querying entity are known, thequery can be filtered and the corresponding datasets can be provided.

5.3.3 Standardized Access Interface, CommandLine Client and Web Client

For the client side a standardized access interfacecan simplify the addition of higher level inter-faces like Web clients or command line clients.According to the requirements given in Section 4the standardized database access interface mustbe compliant with the OGSA-DAI specification.For the web client a packet of portlets based onthe GridSphere framework is chosen.

5.4 Distributed Setup

An overall architecture should account for scal-ability and efficiency, which includes minimal re-source requirements and short access time tocurrent information. The selected core architec-ture is an autonomous, middleware-independentservice which utilizes a storage component withgateways connected to the underlying native mon-itoring services. There are three options to setup the storage component: central, clustered orfederated.

A monitoring service with a central storage hasto contain the integrated data from all connectedsite information services. This setup will not scalein large-scale scenarios, because a frequent updaterate induced by a large number of gateways andsites as well as many client queries will cause highload in the central component.

An alternative is to use clustered storage sys-tems distributed among the connected sites. Thisarchitecture is well known from database clustersbut it has the disadvantage of being too unstablewhen distributed over the Internet.

A federated setup connects multiple autono-mous services as federated services. The autono-mous services are located directly at the resourceproviders’ sites and query only the monitoringsystems of the local provider. The federated ser-vices realize an overlay network which distrib-utes the data and allows a further optimizationby using aligned data distribution algorithms andprotocols.

6 Implementation

The integrated monitoring system designed inSection 5 consists of an initially central storageincorporating a homogeneous data model, gate-ways to transform data models, policies to guidedecisions, and a standardized access interface. Inthe following the implementation details of thesecomponents are given.

6.1 Integrated System

As discussed in Section 5, an autonomous compo-nent for storing all the monitoring data extractedby the gateways is needed. A database seems to fitthe requirements best; it provides advanced filter-ing mechanisms and, based on relational databaseviews, VO-specific monitoring views are easy torealize. Furthermore all modern database imple-mentations can be operated in clustered or feder-ated setups in a transparent way. Since in D-Gridall the information of VO management systemsis stored in databases as well, using a databasefor the autonomous component has the advantageof being able to join the existing VO informationwith the data of the monitoring services. As a data

Interoperable Grid Information System 327

Fig. 2 Implementationof the integrated serviceD-MON

SAML

Database Coupling

GRRS

VOMS

DBViewVO1

DBViewVO2

DBViewVO3

XSLTRepository

XSLT

GLUE 2.0Reference Realization

model the latest draft of the GLUE 2.0 schemais used together with the already existing SQLreference implementation [43]. Figure 2 depictsthe system as implemented.

6.2 XSL Transformations for SchemaInteroperability

The interface between middleware-specific in-formation services and the D-MON informa-tion database is implemented as a three stepprocess: extract, transform, and load. This processof extracting data from BDII, CIS, and MDS4,the three existing monitoring systems in D-Grid,transforming this data to the GLUE 2.0 schema,and loading it into the target database is realizedby middleware-specific gateways, one per middle-ware. The extractor components of the gatewaysoperate with the standard client APIs of the mid-dlewares. The data transformation is implementedusing Extensible Stylesheet Language Transfor-mations (XSLT), which is a popular language for

processing XML data or transforming XML doc-uments into other formats. This choice presenteditself as most of the information services providetheir data in XML format. The data is augmentedwith the identifiers of the information providercomponent to keep track of data provenance. Inthe following key aspects of the individual gate-ways’ implementations are highlighted.

CIS, the information system of the UNICORE6 middleware, already uses the GLUE 2.0 schemainternally. Thus the XSL Transformations for theUNICORE gateway merely checks the XML re-trieved from the CIS and maps it to the respectiveSQL-Commands. No special rearrangement orinterpretation of the data is needed.

The information system of the gLite middle-ware, BDII, is based on the Lightweight DirectoryAccess Protocol (LDAP) and provides output inLDAP Data Interchange Format (LDIF). TheBDII gateway extracts the monitoring informa-tion using the Directory Services Markup Lan-guage (DSML), which is an XML representation

328 T. Baur et. al.

of the directory service information and can beeasily transformed using XSL Transformations.Listing 1 illustrates an example of the XSL Trans-formations of the BDII gateway: The lines upto 30 parse the XML file. In the subsequentlines the respective SQL query is formed forthe AdminDomain component of the GLUE 2.0schema. For the integration of data provenance

information special labels are defined in lines 10–12 to identify the data source. An XSL template isdefined in line 20 and it is applied to the matchingDSML elements and their child nodes. Whenevernew monitoring information is inserted into thedatabase, a unique identifier is used. The lines 27–43 show how the identifier for the AdminDomaincomponent is parsed. If monitoring data with the

Listing 1 AdminDomain.xslt

Interoperable Grid Information System 329

same identifier is already stored in the database,the information is updated (lines 44–50) insteadof inserted.

The monitoring system of the Globus Toolkit 4middleware, MDS4, can be queried using aWS-RF interface which provides output in XMLformat. As MDS4 is based on GLUE 1.1 and ad-ditional information providers like GeoMaint [44]provide site related information in GLUE 1.3, theXSLTs of the MDS4 gateway are implemented toparse, check and map the fields with respect to thedifferent versions of GLUE.

The loader components of the implementedgateways store the transformed, homogeneousmonitoring information in the D-MON integrateddatabase.

6.3 VO-aware Monitoring

The VO-specific monitoring components extendthe core D-MON system. This subsection coversits implementation details.

6.3.1 Serving VO-specific Views

In order to provide VO-based monitoring, infor-mation about the VOs has to be obtained fromthe VO resource management system. In D-Grid,the Grid Resource Registration Service (GRRS)holds the mappings between resources and VOs

and information about all available resources inthe Grid. Whenever a gateway inserts new infor-mation into the D-MON database, a trigger is ac-tivated and generates information for the GLUE2.0 AccessPolicy table from the GRRS tables.An extract of this trigger handling MDS4 specificmappings is shown in Listing 2.

In a second step VO-specific database viewsare generated. To keep this step as flexible aspossible a dynamic view is set up, which can beparameterized. This avoids manual interventionwhenever a new VO is created or an existing oneis deleted. An SQL session parameter containingthe VO has to be set when querying the data-base to retrieve the VO-specific data. Listing 3shows how such views are realized for the GLUE2.0 tables Endpoint, ComputingEndpoint andComputingService. In line 4 the tables Endpointand AccessPolicy are joined on the attribute ser-viceID. Afterwards the joined data is filtered tocontain the data of the specified VO only. There-fore the session parameter is read by the data-base function getVO(). This function had to beimplemented as MySQL does not offer it. Thesame procedure is realized in line 8 using theComputingEndpoint table instead of Endpoint.The third view (lines 10 to 16) containing VO-aware information about ComputingServices iscreated by a join with the VO-aware view ofthe ComputingEndpoint instead of AccessPolicybecause a direct join is impossible.

Listing 2 setAccessPolicy.sql

330 T. Baur et. al.

Listing 3 voView.sql

6.3.2 Standardized OGSA-DAI Service AccessPoints for Secure VO-aware Queries

The standardized service access interface is im-plemented based on OGSA-DAI since SQL itselfis not a Grid standard and is not able to han-dle Grid specific authentication and authorizationprotocols. OGSA-DAI is a standard to query SQLdatabases in a WS-RF-compatible way. The de-veloped interface first sets the session parameterbefore VO-specific queries to the database are

performed. Future versions of OGSA-DAI will becapable of dealing with SAML. Then it will bepossible to set the VO parameter in an automatedmanner as described in Section 5.3.2.

6.3.3 Standardized User Interface

Based on the standardized access client, a com-mand line client has been developed. It copes withthe requirement of being VO-aware by settinga SQL environment variable as a parameter to

Table 1 Test results with the OGSA-DAI client

Interoperable Grid Information System 331

process VO-specific information. A VO view iscreated by the database according to the parame-ter and the SQL query which has been sent tothe OGSA-DAI Server. The outcome is a view,which only contains data sets that are assigned tothe specific VO and to the local user or service.Table 1 shows the output of the OGSA-DAIclient, monitoring computing services for two dif-ferent VOs in three middlewares.

GridSphere was chosen as the portal frame-work as it complies with the needs of theGrid Community. GridSphere provides a sophisti-cated Portlet Service Mode that encapsulates thereusable portlet logic into services that may beshared between many portlets.

Various portlets are used to visualize the datain different views. This includes views like theclassic table view, drill down or Google Maps.They are implemented dynamically using AJAX(Asynchronous JavaScript and XML) and Inter-Portlet Communication (IPC) to provide a moreintuitive user experience whenever possible. Theuser’s role is taken into account when buildingthe view.

A SAML-VOMS authentication module, whichautomatically extracts the user information fromthe user’s certificate and sends it to the SAML-VOMS server, will be added to the GridSphereClient in a next step. For this purpose the SAML-VOMS module of the Vine Toolkit [45] will beconverted into an authentication module.

7 Summary and Outlook

In this paper we described a distributed architec-ture for an interoperable Grid monitoring system.It bases on unifying data from different middle-ware solutions into a standardized format and usesVOMS to support VO-centric, role-based viewsfor data access from clients. All components se-lected for the system are standards either from theOpen Grid Forum (OGF) or the Organization forthe Advancement of Structured Information Stan-dards (OASIS). The chosen approach enables theinteroperation of existing Grid monitoring sys-tems and proved to be viable.

The D-MON monitoring system has been de-ployed in the D-Grid environment. A testbed col-

lects the data from the three central informationservices of all Globus, Glite and UNICORE 6sites (in total 115 sites with about 700 users).Upload of the monitoring data from the sites tothe D-MON data base is done in five minute inter-vals. Currently we are in the process of furtherevaluating the performance of the different com-ponents of the D-MON monitoring system. As canbe seen in Table 1 data from all three middle-ware installations is integrated into the GLUE 2.0-based database. The standardized data schema isa key to the unified provision of monitoring infor-mation from the different middleware solutions.

The data integration process revealed data in-consistencies which mostly resulted from data du-plication through inconsistent naming of sites andresources. This is an administrative issue that mustbe solved by a naming and configuration author-ity, e.g. a Grid Operation Center. It can hardly besolved on a technical level. The data provided bythe different information services is not sufficientto be used for accounting resource usage. Sched-ulers including middleware-specific schedulers canbase their decisions on the data gathered in the theD-MON database. As a prove of concept the col-lected data is being fed back into the middleware-specific information system CIS for being used bylocal schedulers. Another experience gained sofar is that with significant changes in the GLUEschema the database has to be set up from scratchand the old data is lost. Minor changes to theschema require only the adaptation of the ETLprocedures for the different middlewares.

The system is still under development and thefull integration of a SAML-VOMS server forauthentication and authorization of data accessis work in progress. We are currently extendingthe available database to include storage elementsand evaluate federated setups, as well as differenttechniques regarding performance and stability.

Overall, the developed system is a good exam-ple for a non-intrusive, interoperable monitoringsolution for heterogeneous Grid infrastructures.It enables monitoring systems of different middle-wares to easily exchange data.

Acknowledgements The authors wish to thank the Gridcommunities and the members of the working groupsrelated to OGF GLUE, OGSA-DAI, OMII, GLOBUSand UNICORE for helpful advice and support.

332 T. Baur et. al.

References

1. Värttö, S. (ed.): DEISA Advancing Science inEurope. www.deisa.eu, http://www.deisa.eu/press/Media (2008)

2. Appleton, O., Cook, A., Hämmerle, H.: EGEE in 2007.www.eu-egee.org, http://press.eu-egee.org/fileadmin/documents/publications/ EGEEin2007-final.pdf (2008)

3. TeraGrid: Open scientific discovery infrastructure.http://www.teragrid.org/. Accessed September 2008

4. Neuroth, A., Kerzel, M., Gentzsch, W. (eds.): GermanGrid Initiative D-Grid. Universitätsverlag Göttingen(2007)

5. Ellert, M., Gronager, M., Konstantinov, A., Konya, B.,Lindemann, J., Livenson, I., Nielsen, J., Niinimaki,M., Smirnova, O., Waananen, A.: Advanced ResourceConnector middleware for lightweight computationalGrids. Future Gener. Comput. Syst. 23(2), 219–240(2007)

6. D-MON Project: Horizontal integration of resource-and service monitoring in d-Grid. http://www.d-grid.de/index.php?id=401&L=1. Accessed September 2008

7. Alef, M., Fieseler, T., Freitag, S., Garcia, A., Grimm,C., Gürich, W., Mehammed, H., Schley, L., Schneider,O., Volpato, G.: Integration of Multiple Middlewareson a Single Computing Resource. Future GenerationComputer Systems (2008). Accessed May 2008

8. Tierney, B., Aydt, R., Gunter, D., Smith, W., Swany,M., Taylor, V., Wolski, R.: A Grid Monitoring Archi-tecture. Tech. Rep. GDF.7, Global Grid Forum (2002)

9. Schopf, J., Raicu, I., Perlman, L., Miller, N., Kesselman,C., Foster, I., D’Arcy, M.: Monitoring and discoveryin a web services framework: functionality and per-formance of Globus Toolkit MDS4. In: Proceedingsof the 15th IEEE International Symposium on HighPerformance Distributed Computing. IEEE ComputerSociety, Los Alamitos (2006)

10. Cooke, A., Gray, A.J.G., Ma, L., Nutt, W., Magowan,J., Oevers, M., Taylor, P., Byrom, R., Field, L., Hicks,S., Leake, J., Soni, M., Wilson, A., Cordenonsi, R.,Cornwall, L., Djaoui, A., Fisher, S., Podhorszki, N.,Coghlan, B., Kenny, S., OrsquoCallaghan, D.: R-GMA: An information integration system for Gridmonitoring. In: On The Move to Meaningful InternetSystems 2003: CoopIS, DOA, and ODBASE. LNCS,vol. 2888, pp. 462–481. Springer, New York (2003)

11. Foster, I., Maguire, T., Snelling, D.: OGSA WSRFBasic Profile 1.0. Tech. Rep. GDF.72, Global GridForum (2006)

12. Foster, I.: Globus Toolkit Version 4: software forservice-oriented systems. In: IFIP International Con-ference on Network and Parallel Computing. LNCS,no. 3779, pp. 2–13. Springer, New York (2006)

13. gLite: Lightweight Middleware for Grid Computing.http://glite.web.cern.ch/glite/. Accessed September 2008

14. Marzolla, M., Andreetto, P., Venturi, V., Ferraro,A., Memon, A.S., Memon, M.S., Twedell, B., Riedel,M., Mallmann, D., Streit, A., van de Berghe, S., Li,V., Snelling, D., Stamou, K., Shah, Z.A., Hedman,F.: Open standards-based interoperability of job

submission and management interfaces across theGrid middleware platforms gLite and UNICORE.In: E-SCIENCE ’07: Proceedings of the Third IEEEInternational Conference on e-Science and GridComputing, pp. 592–601. IEEE Computer Society,Washington, DC (2007). doi:10.1109/E-SCIENCE.2007.54

15. Hegering, H.G., Abeck, S., Neumair, B.: IntegratedManagement of Networked Systems: Concepts, Archi-tectures, and Their Operational Application. MorganKaufmann, San Francisco (1999)

16. Adreozzi, S., Burke, S., Ehm, F., Field, L., Galang, G.,Konya, B., Litmaath, M., Millar, P., Navarro, J. (ed.):GLUE 2.0 Specification V2.0. Tech. rep., Global GridForum (2008)

17. EDG: European Data Grid Project. http://eu-datagrid.web.cern.ch/. Accessed October 2008

18. DataTAG: Research & Technological Developmentfor a Data TransAtlantic Grid. http://datatag.web.cern.ch/. Accessed October 2008

19. iVDGL: International Virtual Data Grid Laboratory.http://igoc.ivdgl.indiana.edu/. Accessed October 2008

20. LCG: Worldwide LHC Computing Grid. http://lcg.web.cern.ch/LCG/. Accessed October 2008

21. OSG: Open Science Grid. http://www.opensciencegrid.org/. Accessed October 2008

22. OGF: Open Grid Forum. http://www.ogf.org. AccessedOctober 2008

23. Mach, R., Lepro-Metz, R., Jackson, S.: Usage RecordFormat Recommendation. Tech. rep., Open GridForum (2006)

24. Wolf, A.: Spezifikation der D-Grid-Ressourcenbeschreibungssprache DGRDL. Tech.rep., Fraunhofer FIRST (2007)

25. Chem, X., Khan, A., Ainsworth, J., Newhouse, S.,MacLaren, J.: WSI Resource Usage Service (RUS) CoreSpecification. Tech. rep., Open Grid Forum (2007)

26. Fielding, R.: Architectural styles and the design ofnetwork-based software architectures. Ph.D. Thesis,University of California, IRVINE (2000)

27. Baur, T., Saad, S.: Customer service management forgrid monitoring and accounting data. In: Proceed-ings of the 18th IFIP/IEEE International Workshopon Distributed Systems: Operations and Management(DSOM 2007). Springer, New York (2007)

28. Baur, T.: Functional analysis and architecture forinteroperable and DVO-̈specific Grid monitoring ser-vices. In: Proceedings of the Fourth IEEE Interna-tional Conference on eScience (eScience 2008). IEEEComputer Society, Los Alamitos (2008)

29. UNICORE: Uniform Interface to Computer Re-sources. http://www.unicore.eu/. Accessed September2008

30. Fuhrmann, P.: dCache, the Overview. http://www.dcache.org/manuals/dcache-whitepaper-light.pdf. Ac-cessed September 2008. White Paper

31. Antonioletti, M., Atkinson, M.P., Baxter, R., Borley,A., Hong, N.C., Collins, B., Hardman, N., Hume, A.,Knox, A., Jackson, M., Krause, A., Laws, S., Magowan,J., Paton, N., Pearson, D., Sugden, T., Watson, P.,

Interoperable Grid Information System 333

Westhead, M.: The Design and Implementation ofGrid Database Services in OGSA-DAI. Concurrencyand Computation: Practice and Experience 17(2–4),357–376 (2005)

32. Schopf, J.M., Pearlman, L., Miller, N., Kesselman,C., Foster, I., D’Arcy, M., Chervenak, A.: Monitor-ing the grid with the Globus Toolkit MDS4. Journalof Physics Conference Series 46, 521–525 (2006).doi:10.1088/1742-6596/46/1/072

33. Duarte, A., Nyczyk, P., Retico, A., Vicinanza, D.:Monitoring the EGEE/WLCG grid services. Journalof Physics: Conference Series 119(5), 052,014 (10pp)(2008). http://stacks.iop.org/1742-6596/119/052014

34. Memon, A.S., Memon, M.S., Wieder, P., Schuller, B.:CIS: An Information Service based on the CommonInformation Model. In: Proceedings of 3rd IEEEInternational Conference on e-Science and GridComputing, pp. 465–472. IEEE Computer Society,Los Alamitos (2007)

35. Felde, V.D.G.O., Baur, T., Garschhammer, M.,Reiser, H.: Anforderungen an das monitoring,ergebnisse aus der erhebung bei den communties undressourcenanbietern im D-Grid. In: Rückemann, C.-P.(ed.) Ergebnisse der Studie und Anforde- rungsanalysein den Fachgebieten Monitoring, Accounting, Billingbei den Communities und Ressourcenanbietern im D-Grid (D-Grid Report). http://www.d-grid.de/fileadmin/dgi_document /FG2/koordination_mab/mab_studie_ergebnisse.pdf (2006). Accessed October 2008

36. Baur, T., Felde, V.D.G.O., Reiser, H.: Konzepte zumMonitoring im D-Grid (D-Grid Report). http://www.d-grid.de/uploads/media/mab_monitoring_konzepte.pdf(2007). Accessed October 2008

37. Kunze, M., Pogoshyan, G.: Monitoring for multi-middleware grid. In: IEEE International Symposiumon Parallel and Distributed Processing, 2008. IPDPS2008. IEEE Computer Society, Los Alamitos (2008)

38. Simmhan, Y.L., Plale, B., Gannon, D.: A Survey ofData Provenance Techniques. Tech. Rep. TR-618,Computer Science Department, Indiana University,Bloomington (2005)

39. Berry, D., Luniewski, A., Antonioletti, M.: OGSAData Architecture. Tech. Rep. GDF.121, Global GridForum (2007)

40. Baur, T., Kalman, T., Lindinger, T., Milbert,A., Poghosyan, G., Romberg, M.: Middleware-übergreifendes Monitoring: Evaluierung und Auswahlvon Komponenten (D-Grid Report). http://www.d-grid.de/fileadmin/user_upload/documents/D-MON/Komponenten-AP2.1-final.pdf. Accessed September2008

41. Chaudhuri, S., Dayal, U.: Data warehousing andOLAP for decision support. In: SIGMOD ’97: Pro-ceedings of the 1997 ACM SIGMOD internationalconference on Management of data, pp. 507–508.ACM, New York (1997). doi:10.1145/253260.253373

42. Venturi, V., Riedel, M., Memon, A.S., Memon, M.S.,Stagni, F., Schuller, B., Mallmann, D., Tweddell, B.,Gianoli, A., Ciaschini, V., van de Berghe, S., Snelling,D., Streit, A.: Using SAML-based VOMS for Autho-rization within Web Services-based UNICORE Grids.In: Bougé, L., Forsell, M., Träff, J.L., Streit, A.,Ziegler, W., Alexander, M., Childs, S. (eds.) Euro-Par2007 Workshops: Parallel Processing. LNCS, no. 4854,pp. 112–120. Springer, New York (2008)

43. Adreozzi, S., Burke, S., Ehm, F., Field, L., Galang, G.,Konya, B., Litmaath, M., Millar, P., Navarro, J. (ed.):GLUE v. 2.0—Reference to Concrete Data Models.Tech. Rep., Global Grid Forum (2008)

44. GeoMaint Project: Informationprovider (Sensor) forGeolocation and Maintenance Data. http://geomaint.sourceforge.net/. Accessed September 2008

45. TheVineToolkit:http://www.gridsphere.org/gridsphere/gridsphere/guest/vine/r/. Accessed September 2008