Interoperation of world-wide production e-Science infrastructures

Abstract

Many production Grid and e-Science infrastructures have begun to offer services to end-users during the past several years with an increasing number of scientific applications that require access to a wide variety of resources and services in multiple Grids. Therefore, the Grid Interoperation Now—Community Group of the Open Grid Forum—organizes and manages interoperation efforts among those production Grid infrastructures to reach the goal of a world-wide Grid vision on a technical level in the near future. This contribution highlights fundamental approaches of the group and discusses open standards in the context of production e-Science infrastructures. Copyright © 2009 John Wiley & Sons, Ltd.

Full text

CONCURRENCY AND COMPUTATION: PRACTICE AND EXPERIENCE
Concurrency Computat.: Pract. Exper. 2008; 00:1–7 Prepared using cpeauth.cls [Version: 2002/09/19 v2.02]
Interoperation of
World-Wide Production
e-Science Infrastructures
M. Riedel∗,†, E. Laure, Th. Soddemann, L. Field, J.
Casey, M. Litmaath, J.Ph.Baud, B. Koblitz, C.
Catlett, D. Skow, JP Navarro, C. Zheng, P.M.
Papadopoulos, M. Katz, N. Sharma, O. Smirnova,
B. K´onya, P. Arzberger, F. W¨urthwein, A.S. Rana,
T. Martin, M. Wan, V. Welch, T. Rimovsky, S.
Newhouse, A. Vanni, Y. Tanaka, Y. Tanimura, T.
Ikegami, D. Abramson, C. Enticott, G. Jenkins, R.
Pordes, N. Sharma, S. Timm, N. Sharma, G. Moont,
M. Aggarwal, D. Colling, O. van der Aa, A. Sim, V.
Natarajan, A. Shoshani, J. Gu, S. Chen, G. Galang,
R. Zappi, L. Magnoni, V.Ciaschini, M. Pace, V.
Venturi, M. Marzolla, P. Andreetto, B. Cowles, S.
Wang, Y. Saeki, H. Sato, S. Matsuoka, P.
Uthayopas, S. Sriprayoonsakul, O. Koeroo, M.
Viljoen, L. Pearlman, S. Pickles, M. Jones, G.
Moloney, J. Lauret, J. Marsteller, P. Sheldon, S.
Pathak, S. De Witt, J. Menc´ak, J. Jensen, M.
Hodges, D. Ross, S. Phatanapherom, G. Netzer,
A.R. Gregersen, M.Jones, S. Chen, P. Kacsuk, A.
Streit, D.Mallmann, F. Wolf, Th. Lippert
Open Grid Forum - Grid Interoperation Now (GIN) - Community Group (CG)
∗Correspondence to: Morris Riedel, Forschungszentrum Juelich (FZJ), Juelich Supercomputing Centre (JSC),
Distributed Systems and Grid Computing Division, Wilhelm-Johnen-Str. 1, D-52425 Juelich, Germany
†E-Mail: m.riedel@fz-juelich.de
Received 15 March 2008
Copyright c
2008 John Wiley & Sons, Ltd. Revised

2OGF GRID INTEROPERATION NOW COMMUNITY GROUP
SUMMARY
Many production Grid and e-Science infrastructures have begun to offer services to end-
users during the past several years with an increasing number of scientific applications
that require access to a wide variety of resources and services in multiple Grids.
Therefore, the Grid Interoperation Now (GIN) - Community Group (CG) of the Open
Grid Forum (OGF) organizes and manages interoperation efforts among those production
Grid infrastructures to reach the goal of a world-wide Grid vision on a technical level in
the near future. This contribution highlights fundamental approaches of the group and
discusses open standards in the context of production e-Science infrastructures.
key words: Interoperation, Interoperability, Grid Infrastructures, Open Standards, GIN
1. INTRODUCTION
Many Grid projects have begun to offer production services to end-users during the past several
years. While many end-users are satisfied with the resources and technology provided within
these infrastructures there are also an increasing number of application projects that require
access to a wide variety of resources and services in multiple Grids. The requirements for such a
wide variety of resources starts from small PC pools over medium-sized clusters to large-scale
High Performance Computing (HPC) resources. One well-known reason for these different
requirements, among others, is an increasing complexity of Grid applications that embrace
multiple physical models (i.e. multi-physics) that consider a larger range of scales (i.e. multi-
scale). Implementations of such models creating a steadily growing demand for compute power
as well as storage capacities. Hence, collaboration across typical physical knowledge boundaries
leads to totally new complex scientific physical models that have to be simulated on different
Grid resources within those infrastructures, which will thus face new challenges during the
coming years.
Also, more and more world-wide scientific domain-specific Grid infrastructures emerge
orthogonal to national Grid initiatives. While both Grids have experts in the respective
scientific communities, the technology used in those Grids is typically not interoperable
with each other due to their historic evolutions or funding models. Hence, the collaboration
between these Grids is difficult and could be significantly improved. Other requirements for
interoperability are based on the demand for usage models of different services that are
available in different Grid infrastructures. Apart from scientific domain-specific services, there
are even more general diverse services available in Grids. To provide one example, while some
Grids provide brokering mechanisms to automatically choose available Grid resources, other
Grids fundamentally require that Grid resources have to be manually chosen from e-Scientists
to satisfy their unique requirements.
All in all, there are more and more requirements and demands for interoperation of
production Grid and e-Science infrastructures emerging today. Even if many scientific
Copyright c
2008 John Wiley & Sons, Ltd. Concurrency Computat.: Pract. Exper. 2008; 00:1–7
Prepared using cpeauth.cls

INTEROPERATION OF PRODUCTION E-SCIENCE INFRASTRUCTURES 3
applications from various domains have already taken advantage of these infrastructures in
the past, the new possibilities based on a real interoperation of Grids will lead to even more
new insights during scientific scenarios. Therefore, the purpose of the Grid Interoperation Now
(GIN) Community Group (CG) [1] of the Open Grid Forum (OGF) is to organize, manage
and demonstrate a set of interoperation efforts among such production infrastructures. The
members of the GIN-CG are representatives of world-wide Grid and e-Science infrastructures
and national Grid initiatives all working on a technical level to achieve the true vision of a
true global Grid.
Within this contribution, we define the difference between interoperation and interoperability
as follows. Interoperation is specifically defined as what needs to be done to get production
Grids to work together as a fast short-term achievement using as much existing technologies as
available today. Hence, this is not the perfect solution and relies on workarounds or tweaks of
technologies that only last as long as there is no fundamentally new version of the technology
available. Thus, interoperation is much different than interoperability, which is herein defined
as the native ability of Grids and Grid technologies to interact directly via common open
standards in the future. We will discuss within the contribution why this is a rather long-term
achievement and why early interoperation success stories have to use short-term achievements.
The contribution of this paper to the overall work in the field of interoperability and
interoperation within the e-Science and Grid communities is that GIN provides newly
developed components and adapters that work today and include efforts within the most known
production Grid and e-Science infrastructures. Hence, this paper basically describes various
approaches that enable e-Scientists to work in more than one production Grid tomorrow if
they want to. The efforts to achieve this is an outcome of different working areas within GIN
such as job submission, data management, security setups, and information exchange.
Finally, it is important to mention that the GIN effort does not include any attempt to
provide a common allocation or brokering of resources between production Grid projects
and infrastructures. This is viewed as beyond the scope of the GIN efforts and resource
allocation decisions are left to negotiations between projects, e-Scientists and the individual
Grid infrastructures. In collaboration with GIN, the recently started OGF-Europe project is
maybe able to make a significant step forward in this context. Nevertheless, the work within
GIN demonstrates that interoperation is feasible and technically possible today. Thus basically
enabling e-Scientists to work on cross-Grid scenarios and applications that need more than
one Grid for their scientific research.
This paper is structured as follows. After the motivation and introduction into the problem
domain of interoperation and interoperability, Section 2 shortly introduces the GIN-CG and
its participating Grid infrastructures. Section 3 provides an overview of the wide variety
of GIN efforts. It describes the fundamental process of providing a cross-Grid information
system, job submissions, data management, security setups and outlines potential solutions.
This section also includes pieces of information about the well-known Supercomputing 2006
and 2007 demonstrations. In Section 4, we provide lessons learned from these demonstrations
and provide some insights to a very interesting session at OGF21 that brought together GIN,
software providers as well as standardization groups. In this section, we also provide the current
status of standard adoption within GIN infrastructures as discussed at OGF22. Finally, this
paper ends with a survey of related work and concluding remarks.
Copyright c
2008 John Wiley & Sons, Ltd. Concurrency Computat.: Pract. Exper. 2008; 00:1–7
Prepared using cpeauth.cls

4OGF GRID INTEROPERATION NOW COMMUNITY GROUP
2. GRID INTEROPERATION NOW COMMUNITY GROUP
The origin of the GIN group began in November 2005 where Charlie Catlett organized a
multi-Grid interoperation planning meeting with well-known representatives from world-wide
Grid infrastructures. The result of this meeting basically lead to the GIN group with a slightly
different focus than today. Initially, the scope of GIN was to pursue interoperation on 6-8 month
horizons using solutions for which there are working implementations available, wherever
possible using open standards. The results of GIN were expected to lead to a more seamless
usage of different Grid infrastructures by applications while GIN did not provide resources
or support application porting. Also today, GIN provides a seamless usage of different Grid
infrastructures on the technical level, but the real usage is still required to negotiate between
end-users, resource providers and Grid infrastructures.
More recently, the goals of GIN are to organize, manage and demonstrate interoperation
between production Grid infrastructures. GIN provides valuable feedback to the OGF
standardization groups and the software providers implementing those standards in
technologies that are deployed on the infrastructures. Also, if required, GIN works closely
together with important activities that focus on special areas, such as the the Grid Laboratory
Uniform Environment (GLUE) [31] group or starts spin-offs like the worker node profile.
All Grid infrastructures that participate within GIN are shown in Table I. There are
several national Grid activities participating such as the Australian Partnership for Advanced
Computing (APAC) [54], the German national Grid initiative D-Grid [5], or the Japanese
National Research Grid Initiative (NAREGI) [60], or the National Grid Service (NGS) [21]
within the UK. The European participating infrastructures are Enabling Grids for e-Science
(EGEE) [41] and the Distributed European Infrastructure for Supercomputing Applications
(DEISA) [49]. Also, several regional Grids participate such as Pacific Rim Applications and
Grid Middleware Assembly (PRAGMA) [19], Nordic DataGrid Facility (NDGF) [17]. Finally,
participating Grids from USA are TeraGrid [9] and the Open Science Grid (OSG) [25].
To achieve real usable interoperation, GIN implements interoperation in five specific areas.
First, authorization and identity management (GIN-AUTH) deals with resource sharing among
members of the GIN Virtual Organization (VO) [18]. Second, the data management and
movement (GIN-DATA) area is working on the interoperation of different data management
technologies currently in use of multiple e-Science infrastructures. These include the Storage
Resource Broker (SRB) [20], Storage Resource Managers (SRM) [22] and GridFTP [7]. Third,
the job description and submission (GIN-JOBS) area focuses on job management across
different Grid technologies and middlewares used in production Grids today. In addition,
tracking the resource usage of these submissions is especially interesting in cross-Grid scenarios
and thus also part of this area. Also important for end-users is the information services and
schema (GIN-INFO) area, because the efforts conducted in this area basically provide the base
for cross-Grid interoperation taking up-to-date information into account. These interoperations
rely on information models such as Common Information Model (CIM) [23] and GLUE [31],
and on information systems such as Berkeley Database Information Index (BDII) [39] and
Monitoring and Discovery Services (MDS) [28]. Finally, the operations experience of pilot test
applications (GIN-OPS) for cross-Grid operations work on different applications that require
resources from multiple Grid infrastructures.
Copyright c
2008 John Wiley & Sons, Ltd. Concurrency Computat.: Pract. Exper. 2008; 00:1–7
Prepared using cpeauth.cls

INTEROPERATION OF PRODUCTION E-SCIENCE INFRASTRUCTURES 5
Table I. Grid and e-Science Infrastructures participating in GIN
Name Country/Continent/Region
APAC Australia
D-Grid Germany
DEISA Europe
EGEE Europe
NAREGI Japan
NDGF Nordic Region
NGS United Kingdom
OSG USA
PRAGMA Pacific Region
TeraGrid USA
3. GIN ACTIVITIES
The major GIN activities are related to the organization and demonstration of technical
interoperation between production Grid infrastructures. As described earlier, we define
interoperation different than interoperability, however, it seems very reasonable to consider
both approaches in the GIN efforts since they are closely related. In fact, many of the rather
short-term interoperations should lead to long-term open standards-based interoperability in
the near to mid-term future. Therefore, all GIN efforts can be not only differentiated into the
different areas (i.e. GIN-Jobs, GIN-Auth, etc.), but also in two categories named as production
and future solution.
Thus many approaches undertaken in GIN are part of the production category, which
includes efforts having the short-term interoperation character. In this category, we refer to
non standard-based solutions for which there are working implementations available, even if
they are realized by using workarounds, adapters, tweaks, or even small hacks. On the other
hand, approaches of the future solutions category use open standards (i.e. OGSA-BES [6])
were possible. This might even include emerging standards (i.e. OGSA-RUS [37]) that are still
not yet an official open standard, but have a high potential to be standardized in the near
future and are urgently needed within the infrastructures.
In this chapter, we provide an overview of the undertaken GIN efforts from 2006 until today
in the following paragraphs. Most notably, these efforts include the well-known demonstrations
as presented in media [30] and shown at Supercomputing 2006 in Tampa and the more recent
Supercomputing 2007 in Reno. Typically these efforts are achieved in many different projects
while GIN provides them a forum for discussions and exchange of experience in interoperability
and interoperation. Hence, many demonstrations are organized by GIN, but having much
contributions from a wide variety of world-wide Grid projects.
Finally, lessons learned based on the efforts described in the following paragraphs are
presented later in Chapter 4.
Copyright c
2008 John Wiley & Sons, Ltd. Concurrency Computat.: Pract. Exper. 2008; 00:1–7
Prepared using cpeauth.cls

6OGF GRID INTEROPERATION NOW COMMUNITY GROUP
Figure 1. Information schema translators for production Grid interoperations.
3.1. Information Services and Modeling
In order to identify appropriate resources for end-users within an e-Science infrastructure there
must be some form of resource information conforming to schemas and access technologies
using standard query mechanisms. The GIN-INFO area of GIN provides interoperation
components (e.g. information schema translators, adapters, etc.) to deal with the usage of
different information schemas within production e-Science infrastructures. The efforts in the
GIN-INFO area are built upon previous bi-lateral successes such as interoperation efforts
between EGEE and OSG, and between NDGF and EGEE, and others. Hence, the major goal
of GIN-INFO is to extend these pair-wise interoperations with a broader set of production
Grids by identifying a subset of information items that can be used as a common minimum
set. This also motivates the development of translators for common information items used in
different information schemas.
Information systems describe the wide variety of Grid resources that are available in
production Grids in a precise and systematic manner, to enable them to be discovered for
subsequent management or use. Over the years several schemas evolved either in scientific-
oriented production Grids or within business-oriented standard bodies such as the Distributed
Management Task Force (DMTF). Figure 1 illustrates the initial architecture of the BDII-based
interoperation between different information services and schemas. BDII itself consists of two
or more standard LDAP [58] databases that are populated by an update process. The update
process obtains LDIF [62] either by doing an ldapsearch on LDAP URL lists or by running a
local script that generates LDIF. The LDIF is then inserted into the LDAP database as an
entry.
Copyright c
2008 John Wiley & Sons, Ltd. Concurrency Computat.: Pract. Exper. 2008; 00:1–7
Prepared using cpeauth.cls

INTEROPERATION OF PRODUCTION E-SCIENCE INFRASTRUCTURES 7
Within GIN-INFO, we initially developed numerous information translators for those Grids
that do not naturally support the BDII system. This raised a demand for a set of common
minimal attributes, because the production Grids evolved over time and thus use a wide
variety attributes that deal with more or less the same pieces of information. Therefore, in
interoperation, it is extremely important to agree on a common minimal set of attributes. Of
course this common minimal set depends on the use case: for instance, in job execution the
service endpoint attributes may be published by an information system. In addition, to have
a common minimal set of attributes it is necessary to map the values to each other so that
clients are able to interpret attributes consistently. Hence, translators have been developed
that map the content of one attribute in schema A of the content of one attribute (or even
a set of attributes) in schema B. The translators are publicly available to be used within the
Grid community.
As shown in Figure 1, we used a GIN-BDII as a top-level BDII with information (attributes)
from all Grids in accordance to the GLUE schema version 1.3 [31]. As a side-remark, this version
of GLUE was created before the OGF GLUE working group was formed that currently develops
the GLUE 2.0 standard taking experience from earlier versions into account. The GLUE
schema has a site entry element, which describes the site identified, site location (longitude,
latitude), site name, and aggregated site resources. Some mandatory and several optional
attributes such as site description, site location in a human readable format, administrator
emails or site Web page were used in interoperation. Figure 1 indicates that all the mandatory
attributes for a Grid site are provided by the GIN Top-level-BDII, which in turn may
feed information into other Top-level-BDIIs (e.g. ARC) for the broadcast of interoperability
information among the Grids.
Another fundamental challenge in the context of GIN-INFO is related to a general lack
of information. Not all information systems publish all optional attributes, so a cross-Grid
application implementation may encounter errors when it requires exactly that information.
Of course these problems also arise if Grid sites do not publish this information correctly (e.g.
not GLUE schema compliant).
It seems reasonable to consider that the above mentioned information could be useful in
the context of service discovery of job execution endpoints (e.g. OGSA-BES [6] interface
implementations) across Grid boundaries. Thus, missing or incorrect data could lead to
problems when using this data in real use cases such as data staging between sites and simple
job executions. In more detail, this leads to job submission errors with confusing error messages
because the user sees an error from the job submission system, the native information system
is correct, and the real error is in the translated information system. The pieces of information
required have to be defined by the use cases and thus raise the demand to identify pieces of
information required for cross-Grid use cases. In this context, the GLUE 2.0 working group is
currently working on this particular issue.
The final approach uses the same set of attributes but is slightly different to the initial
architecture due to the administration overhead of providing a BDII for each Grid. Instead,
Figure 2 illustrates that for each production Grid an information provider has been developed,
re-using experience gained from the translators. In production scenarios, the information
provider queries the corresponding Grid site and exposes the information in LDIF in accordance
with the GLUE schema. In turn these information providers are used to provide the GIN Top-
Copyright c
2008 John Wiley & Sons, Ltd. Concurrency Computat.: Pract. Exper. 2008; 00:1–7
Prepared using cpeauth.cls

8OGF GRID INTEROPERATION NOW COMMUNITY GROUP
Figure 2. Information providers for different Grid systems.
Level-BDII with information from all participating infrastructures using a generic provider
in between. In turn this information lays the foundation for the ARC-BDII that is also a
Top-Level-BDII, but publishing in accordance to the ARC schema. The ARC schema is used
within the NDGF whose ARC middleware implements a scalable and dynamic distributed
information system, which is capable of using this information for cross-Grid scenarios.
All in all, GIN-INFO provides components to fetch information out of nine production Grids
that use different information services and schemas, namely APAC, DEISA, EGEE, NDGF,
NGS, NAREGI, PRAGMA, and TeraGrid. At the time of demonstrations, NAREGI uses the
CIM schema, NDGF relies on the ARC schema and NGS uses the MSD2.4 schema of Globus
Toolkit 2, and the rest use GLUE. When GLUE 2.0 become available and widely accepted,
the use of different information schemas is hopefully obsolete.
The described interoperations were demonstrated at the Supercomputing 2006 and 2007 by
using Google Earth showing information from all participating Grid sites. This demonstrated
a common minimal set of attributes provided by various infrastructures and thus underlines
that it is possible to interoperate in terms of information exchange. More information can be
found in the GIN-INFO area of GIN on GridForge [1].
Copyright c
2008 John Wiley & Sons, Ltd. Concurrency Computat.: Pract. Exper. 2008; 00:1–7
Prepared using cpeauth.cls

INTEROPERATION OF PRODUCTION E-SCIENCE INFRASTRUCTURES 9
3.2. Data Management and Movement
In order to move and transfer data between production e-Science infrastructures they must be
interoperable using high performance data transfers such as GridFTP [7], and data brokering
technologies such as SRB [20] and SRM [22]. Therefore, the GIN-DATA area is working
on interoperation of three different technologies. Firstly, the GridFTP technology can be
seen as the lowest common denominator for data movement in Grids today. Secondly, SRM
as a standard asynchronous control interface to Grid storage systems; with more than six
interoperating implementations, it is now an OGF standard achieved by the GSM-WG [35].
SRMs usually rely on GridFTP for data transfers. Finally, SRB implements a data Grid
approach, a shared collection management system of multiple (distributed) storage systems
that provides virtualization of whole shared data collections and their metadata. All these
three mentioned technologies are widely deployed in production Grid infrastructures today.
Most production Grids use different implementations of the GridFTP protocols, but basic
interoperation is typically achieved using test suites. Also, a subset of the GridFTP2 protocol
is more and more implemented, for instance within dCache [51], Globus C, and Java client
libraries. At Supercomputing 2007, the NDGF demonstrated its production usage, which in
turn lays the foundation for interoperation with any GridFTP2 compliant Grids. In addition,
interoperation efforts on a pair-wise fashion for scientific scenarios are also undertaken world-
wide. One example of such a scenario was demonstrated at Supercomputing 2007 showing
interoperation between European DEISA and the Australian Grid in terms of data transfers
using GridFTP. The fundamental goal of this scenario is to enable a cross-Grid scientific
application job submission based on NAMD molecular dynamics suite [45] and to seamlessly
work with the outcome afterwards. While the DEISA command line tool DESHL and its
implied SAGA implementation was used for job submissions using JSDL, the file transfer
between the Grids was successfully achieved by GridFTP implementations.
Beside these efforts for data movement, the efforts for data management are important as
well and focus on access to storage via standard interfaces such as SRM. The GIN-DATA area
achieved interoperations between different SRM implementations also using test suites, which
focused on a core subset of the SRM specification. By using this subset nine production Grid
sites where able to interoperate. While SRMs are based on a common interface specification,
many advanced data management functions (e.g. space reservation) are optional. The error
response when asking for a non-implemented feature is in the most cases not clear enough to
understand the real reason without contacting the administrator. Another challenge that the
GIN-DATA group encountered was that the most SRM implementations within production
Grids are tuned to use GridFTP as underlying data transfer protocol and thus run into
problems when other protocols (e.g. HTTP) are being used in other production Grids.
The purpose of the SRM testing tool is to check compatibility and interoperability of
SRMs according to the specification. Thus, the tool checks client-to-SRM adherence to the
specification, as well as SRM-to-SRM remote copy capabilities. The basic tests include read
access to a file in a remote Grid storage system managed by SRM. Furthermore, file replication
for a registered user between two independent storage systems is tested. Finally, also space
reservation and write access to a reserved space for a registered user in a remote Grid can be
Copyright c
2008 John Wiley & Sons, Ltd. Concurrency Computat.: Pract. Exper. 2008; 00:1–7
Prepared using cpeauth.cls

10 OGF GRID INTEROPERATION NOW COMMUNITY GROUP
Figure 3. Access to SRB and SRM data via GridFTP in production Grid interoperations.
tested by the tool. To sum up, this tool helps ensure production Grid interoperation between
SRM implementations, and is being used by the SRM-collaborations.
Another GIN-DATA activity is to achieve SRB interoperation by establishing trust between
different SRB-based data Grids. The SRB interoperation tests initially focused on single file
replication and subsequently on replication of data collections between multiple federated Grid
infrastructures. This included the federation of data Grids based on the SRB and replication
of a collection into a federated data Grid. Another useful test is the use of remote procedures
to extract provenance metadata and load the provenance metadata into a collection. Finally,
tests have been done to test the use of extensible schema mechanisms to manage hierarchical
metadata descriptions. To sum up, these tests were successfully run between 19 different Grid
sites. The three most common problems found during these tests were the establishment of trust
between the Grids that basically requires manual intervention today, interoperation between
different versions of SRB, and the identification of what metadata will be shared.
Finally, a more recent interoperation activity focused on data transfer between SRM and
SRB in a scenario that uses advanced gLite data management tools. The trick is to use a
GridFTP server developed for SRB, to endow it with an ’SRM information system’, and to
pretend it is a so-called classic storage element. This permits the gLite tools, both the File
Transfer Service (FTS) and the so-called lcg-utils, to transfer files between SRMs and SRBs,
with no development efforts required. This scenario is shown in Figure 3, which underlines that
GridFTP and information systems are integral to SRM, and also shows how interoperation was
achieved by having SRBs with an GridFTP layer on them and an added information system.
In turn, higher level Grid tools use data transport with GridFTP as the main entry point for
SRB, whereas they use the SRM protocol with the SRMs. Traditionally, higher level tools like
lcg-utils make firstly use of the information system for resource discovery and selection and
with the developed interoperation, an end-user can access SRM and SRB data.
All of the GIN-DATA activities have been demonstrated at Supercomputing 2006 and 2007.
Also, interoperation demonstrations in the context of the gLite AMGA Metadata Catalogue
[57] have been shown. This technology is used in EGEE and provides access to relational
databases. By using the OGF WS-DAIR specification [44], a standardized data access for
different versions of gLite AMGA Metadata catalogue on different sites was achieved.
Finally, more information can be found in the GIN-DATA area of GIN on GridForge [1].
Copyright c
2008 John Wiley & Sons, Ltd. Concurrency Computat.: Pract. Exper. 2008; 00:1–7
Prepared using cpeauth.cls

INTEROPERATION OF PRODUCTION E-SCIENCE INFRASTRUCTURES 11
3.3. Job Submission and Management
There are a lot of production e-Science infrastructures that all support wide varieties of Grid
middleware platforms and technologies that unfortunately provide no commonly accepted
interoperable interface for job submission and management. For example, the gLite [48]
middleware of EGEE uses the proprietary Job Description Language (JDL), Globus Toolkit’s
GRAM [32] of TeraGrid accepts job descriptions in a proprietary Resource Specification
Language (RSL) format, and UNICORE 5 [34] of DEISA uses a proprietary job description
named as Abstract Job Objects (AJOs). Hence, there is currently no standardized job
description format in use within production Grids and no well-defined interface for job
submission and management broadly adopted within e-Science infrastructures.
The lack of such a standard lead to rather complicated interoperation efforts using tweaks
and workarounds. To provide an example, the EGEE-II project developed an interoperation
between gLite and UNICORE using no standards at all. The objective of this interoperation
scenario is to submit jobs from the EGEE infrastructure based on gLite to the DEISA
infrastructure based on UNICORE 5. This interoperation is required as a fast short-term
achievement by several e-Science initiatives such as the WISDOM project [29], which requires
access to farming resources in EGEE and massively parallel resources in DEISA.
Figure 4 shows this interoperation scenario that has been demonstrated at Supercomputing
2007. A scientist of the EGEE infrastructure uses a gLite User Interface (gLite UI) to submit
the job that is intended to run on a computing resource managed by UNICORE. Like a job
running on the EGEE infrastructure the user describes the job in a JDL file, but adds a
special requirement for this job (i.e. other.GlueCEInfoLRMSType == ’UNICORE’). Through
this requirements statement the MatchMaker on the gLite Resource Broker (see Figure 4) is
advised to choose a gLite Computing Element that is configured for transferring jobs to a
UNICORE based infrastructure, shown as gLite-CE Interoperation Environment in Figure 4.
The gLite Resource Broker stores the so called inputsandbox, i.e. the data transferred by the
user from the gLite User Interface, and sends a job description including URIs of the input- and
outputsandbox to the gLite-CE Interoperation Environment. If the user for example wants to
execute a shell script, this script is send as part of the inputsandbox and stored on the gLite
Resource Broker. When the job gets executed the inputsandbox is fetched by the compute
resource, either a gLite Worker Node or a UNICORE Target System, for execution.
Also, in terms of security this interoperation scenario was a challenge since gLite relies
on proxy certificates [61] while UNICORE only accepts full X.509 certificates. For the gLite
Computing Element, Basic Local Ascii Helper (BLAH) scripts were implemented that allow
for job submission to UNICORE and control of these jobs. The job submission script builds
a UNICORE AJO based on the job description from the gLite Resource Broker. The AJO
is signed and submitted using the users VOMS proxy certificate [38]. In the UNICORE
environment the job arrives in the UNICORE Environment at the UNICORE Gateway (see
Figure 4), which authenticates the so called consignor of the job, i.e. the one who submitted the
job. In order to accept job submissions consigned by proxy certificates, the UNICORE Gateway
was modified as described in [52]. The UNICORE Network Job Supervisor (UNICORE NJS)
uses the UNICORE User DataBase (UNICORE UUDB) to match the so called endorser, i.e.
the one who signed the job, to a UNIX userid on the Target system. In order to match proxy
Copyright c
2008 John Wiley & Sons, Ltd. Concurrency Computat.: Pract. Exper. 2008; 00:1–7
Prepared using cpeauth.cls

12 OGF GRID INTEROPERATION NOW COMMUNITY GROUP
Figure 4. Interoperation of UNICORE 5 and gLite as short-term achievement.
certificates to UNIX userids a new UUDB was implemented. This UUDB compares only parts
of the certificates DN with the DataBase entry. If an entry was found the job is forwarded
to the Target System for execution. On the Target System the users inputsandbox is fetched
from the Resource Broker and the job is executed. Therefore, gLite Worker Node functionality,
available for several systems, is needed on the Target System.
The example of the above mentioned interoperation scenario underlines the demand for a
standard for job submission, including aligned security models. The OGSA - Basic Execution
Services (OGSA-BES) [6] specification provides such an interface that accepts job descriptions
in the standardized Job Submission and Description Language (JSDL) [55] format. The High
Performance Computing (HPC) - Basic Profile (BP) [4] combines both specifications together
with some HPC-specific extensions to JSDL. Recently, many software providers have started
to support the HPC - BP and thus many production Grids are evaluating the implementation
of this interface in the corresponding middlewares. Therefore, the GIN-JOBS area also uses
this interface to provide a proof-of-concept interoperation demonstration before this interface
comes into production usage within real application scenarios.
It was commonly agreed within GIN that the use of HPC-BP makes more sense than
providing yet another set of interoperable short-lived adapters for Globus GRAM, UNICORE,
or gLite environments. Also many commercial vendors (e.g. Platform Computing, Microsoft,
IBM, Fujitsu, etc.) agreed to provide such an implementation of this interface for their
Copyright c
2008 John Wiley & Sons, Ltd. Concurrency Computat.: Pract. Exper. 2008; 00:1–7
Prepared using cpeauth.cls

INTEROPERATION OF PRODUCTION E-SCIENCE INFRASTRUCTURES 13
technologies. They basically agreed because the JSDL specification is already standardized
while the HPC extensions and the OGSA-BES specifications are mature enough to become
OGF standards very soon.
Several interoperation efforts were demonstrated at the supercomputing 2006 and 2007 and
particularly these demonstrations lead to interest in computer science media and news sections
of online newspapers and reports, which in turn leads to high visibility for the standards. The
GIN-JOBS group used Transport Level Security (TLS) [16] in combination with the WS-
Security Username Token Profile [12] as the security mechanism. Even if this kind of security
can be significantly improved, the interoperation was focusing on the interface level of OGSA-
BES and the HPC-BP in order to be successful.
In this context, it is important that the OMII - Europe project [43] augments middleware
- currently gLite, UNICORE, and the Globus Toolkit - with OGSA-BES interfaces to lay the
foundation for its adoption of this interface by middleware providers. Hence, this in turn lays
the foundation for the usage of this interface and HPC-BP profile within production e-Science
infrastructures in the near future. This will lead to at least three independent implementations
of OGSA-BES; thus the OGSA-BES specification and HPC-BP will change its status from
proposed standard recommendation to full standard recommendation in OGF. In a later
section, we will describe of how the security setup in conjunction with an OGSA-BES interface
can be significantly improved by using VOMS [10] during job submissions.
Closely related to job submission is also the tracking of resource usage and accounting,
which is also highly required within e-Science infrastructures. At OGF19 and a follow-on
meeting at CERN, we decided to stay basically with the GIN areas, but look on other
important areas, and one of these areas is accounting. It lays the foundation for billing and
pricing and thus may increase the uptake of Grids in the commercial scene and supports the
sustainability of e-Science infrastructures by being not only dependent on funding of public
bodies. Especially in interoperation scenarios accounting becomes a major challenge, not only
by having different security setups and job submission technologies, but also due to the different
nature of computing resources (farming vs. HPC). This different computing resources consists
of CPUs or, more recently, cores, which have a wide range of performance and thus makes it
rather difficult to define valid pricing models for CPU/core usage.
At Supercomputing 2007, the OMII-Europe project participated in the GIN demonstrations
with a showcase using the Distributed Grid Accounting System (DGAS) [50] and the Swedish
Grid Accounting System (SGAS) [2]. DGAS is one of the accounting systems in gLite, while
SGAS is the accounting system of SweGrid, but also, as a Globus Tech Preview, often used in
Globus-based Grids. The goal of this scenario is to enable cross-Grid end-user usage records
exchange between gLite-based and Globus-based Grids. Those records are compliant with the
OGF Usage Record Format (UR) [40] and consists of used CPUs, memory, job duration, just
to list some recorded information. The records are exposed with the emerging OGF standard
interface OGSA - Resource Usage Service (RUS) [37]. OMII - Europe augmented DGAS,
SGAS, and UNICORE 6 [42] with an OGSA-RUS interface to allow for cross-Grid usage
record tracking and exchange. At Supercomputing 2007, interoperability between DGAS and
SGAS was shown, and also OGSA-RUS-based monitoring solutions on top of UNICORE 6
have been shown by using the LLview application [59].
Copyright c
2008 John Wiley & Sons, Ltd. Concurrency Computat.: Pract. Exper. 2008; 00:1–7
Prepared using cpeauth.cls

14 OGF GRID INTEROPERATION NOW COMMUNITY GROUP
3.4. Cross-Grid Applications and Operations
This section highlights several results of the interoperation efforts within the GIN-OPS area.
It focuses on discovering issues, testing ideas and verifying solutions covering different aspects
of Grid interoperation through running applications of scientific interest in the GIN testbed.
This often presuppose interoperation in the other areas of GIN.
One example of interoperation demonstrated at the Supercomputing 2006 conference, used
the scientific program Time-Dependent Density Functional Theory (TDDFT) equation [56].
TDDFT is a molecular simulation method in computational quantum chemistry, and it treats
multiple electrons excitation directly, using techniques from quantum mechanics. As a Grid
application, TDDFT is built on Grid middleware Ninf-G. The efforts include interoperation in
different scenarios, for instance between a run of the TDDFT application across the PRAGMA
Grid, TeraGrid, OSG and NorduGrid. An interface between ninf-G and NorduGrid had to be
developed to enable interoperation to NorduGrid. In particular this interoperation was achieved
by running TDDFT on six heterogenous sites across these four Grids. In fact, it demonstrated
that such a level of interoperation is neither automatic, nor is it unattainable.
In addition to TDDFT jobs, the GIN-OPS group has also started a data-intensive application
called the Savannah fire simulation in the GIN testbed to explore data-related interoperability
issues. These experiments reveal a clear demand for job submission and management
standards. Beside these issues the GIN-OPS group experiences revealed challenges in software
support environments. Specifically, some Grids require site administrators to install a specific
application (e.g. necessary libraries) and some Grids require applications be self-contained
(sandbox) which means that e-Scientists have to package all software that is needed. While
the wider adoption of the sandbox method can be an option in interoperation, some Grids in the
GIN-OPS group also worked on community software areas (CSAs) where users can install and
share software. However, there could be difficulties in management and performance for some
Grid environments, not to mention potential security problems. All in all, these experiments
provided valuable lessons for Grid infrastructure supporters and Grid application users.
In addition to these efforts, the GIN-OPS group employed the SCMSWeb software [53],
implemented crossgrid resource testing and used to monitor sites by probing all GIN
testbed resources periodically, provided near-realtime status of the authentication service,
job submission, and GridFTP of each GIN testbed site. Furthermore, GIN-OPS collaborated
with members of GIN-INFO, implemented geographic mapping of GIN sites, and worked on
a common schema to enable interoperation among various Grid monitoring software.
Another area of cross-Grid applications is related to the GIN resource testing portal that
provides access to the various GIN VO resources and monitors their availability. The portal
provides two services: first, it runs a monitoring service to check resources of the GIN VO
secondly, it offers a workflow editor and engine to create and run workflows on resources. These
services are built on Grid Execution Management for Legacy Code Applications (GEMLCA)
[14], Grid Monitoring Tool (GMT) [36] and the P-GRADE portal [26].
The P-GRADE portal [46] is a workflow-oriented portal and application hosting environment
based on GridSphere. The portal is able to manage Grid certificates, to define Grid
environments, to create and modify workflow applications, to control the execution of workflow
applications on Grid resources and to monitor and visualize the progress of workflows
Copyright c
2008 John Wiley & Sons, Ltd. Concurrency Computat.: Pract. Exper. 2008; 00:1–7
Prepared using cpeauth.cls

INTEROPERATION OF PRODUCTION E-SCIENCE INFRASTRUCTURES 15
Figure 5. Connecting GT2 and LCG-based Grids.
and their jobs. GEMLCA supports the deployment of legacy applications as Grid services
without re-engineering their codes. GEMLCA was integrated with the P-GRADE Grid
portal to provide a user-friendly interface to deploy, execute and retrieve results from legacy
applications. To access both resource- and service-oriented Grids, GEMLCA was extended
by the GEMLCA Repository (GEMLCA-R). GEMLCA-R enables the legacy code owner to
publish the application in the repository and allow authorized users to use the legacy code.
GEMLCA-R submits the legacy code as a job to GT2- and gLite/LCG-based production Grids.
In terms of monitoring Grid resources of the GIN VO, a monitoring service is offered
by GMT that uses MDS4 [28] to collect, store and index information about resources and
control resource monitoring. GMT incorporates a set of probes to monitor basic network
communication and Globus toolkit functionality, local job managers and GEMLCA services.
GMT was integrated as a portlet with the P-GRADE portal. The portlet queries the MDS4 to
retrieve the probes results and present them. System administrators can configure the MDS4
service to run the probes at different pre-defined intervals. Currently, GMT runs 44 probes on
GIN VO resources representing the EGEE Grid, NGS, OSG and TeraGrid. A snapshot of the
P-Grade portal is shown in Figure 5 showing how GT2 and LCG-based Grids are connected
in one user-friendly GUI.
In terms of running applications on multiple Grids, the Resource Testing Portal supports
workflow-level interoperation among resource- and service-oriented Grids. At Supercomputing
2006 and 2007, GIN-OPS demonstrated how to run jobs on Grids with their resources accessing
the EGEE Grid, NGS, OSG and TG using the CHARMM application. All in all, the Resource
Testing Portal supports access to multiple Grids, for example LCG- and Globus-based Grids.
The portal connects these Grids and maps the execution of different workflow components to
different resources in different Grids. As the portal is also integrated with GEMLCA-R, users
can browse the it and select and run executables published by other users.
Copyright c
2008 John Wiley & Sons, Ltd. Concurrency Computat.: Pract. Exper. 2008; 00:1–7
Prepared using cpeauth.cls

16 OGF GRID INTEROPERATION NOW COMMUNITY GROUP
3.5. Authorization and Identity Management
A functional authentication and authorization system is foundational to most of the other
interoperation activities within e-Science infrastructures. The base use case is identity-based
authorization at the service level with any further authorization restrictions enforced inside
the service at the base internal system level. More advanced use cases include setting Grid
permissions for members of specific groups or for end-users with a certain role within a VO.
These services are typically provided by a Virtual Organization Membership Service
(VOMS), so GIN-AUTH provides a GIN VOMS service to permit interoperation testing
without compromising security in production VOMS servers. VOMS is widely adopted in
production Grids today and the two basic services that are provided by VOMS are the
management of a list of members of a VO and signing attribute statements attesting to the
subject’s group/project membership or roles.
The creation of the GIN VO for testing purposes, containing a limited number of staff from
the participating Grids introduced another point of confusion for end-users of the system.
Frequently, it was mis-understood that membership in the GIN VO was the method by which
one gained access to resources from participating Grids to establish cross-Grid application
interoperation - staff actually have access to their own Grids using their own Grid’s VO, but
no access to other Grids. This was a persistent problem because part of the GIN baseline
activity was a standard series of application tests to establish functional interoperation. This
was also a problem, because the GIN VO had pre-negotiated access to all the participating
Grids, a step which was viewed as a significant barrier to e-Science VOs wishing to get started
with multi-Grid interoperations.
Therefore, the GIN-AUTH group developed an Acceptable Use Policy (AUP) for VO
membership. The AUP for the GIN VO can serve as a model for other VOs wishing to
establish serious multi-Grid interoperations. It was agreed among the participating Grids that
this AUP met most of their requirements and established a good baseline for VOs wishing
to register with new Grids. There may be additional requirements for individual Grid or e-
Science infrastructures, but those are typically few and deal with Grid-specific policies and
procedures. The AUP is publicly available at [1] for use in e-Science infrastructures that would
like to engage in interoperation scenarios.
More recently, the GIN VO is registered in OSG as operational VO today, because members
of PRAGMA require access on Fermilab resources of OSG. This underlines the real-world
recognition of the GIN efforts and its influence in world-wide production Grids. The scientific
scenario is a biology PRAGMA application within the GIN VO that is ready to be run on
OSG resources using the Nimrod/G grid parametric modeling and middleware tool.
More challenges occur during the accreditation of CAs currently in use within e-Science
infrastructures. Several of the Grids have internal processes for vetting CAs from whom they
will accept credentials and there was no universal system for selecting or ranking a common set
of CAs. Therefore, the GIN-AUTH team took the decision to concentrate on the International
Grid Trust Federation (IGTF) [63] set of regional Policy Management Authorities (PMAs) list
of accredited CAs. These represent a common set of recognized identity providers. While this
decision allowed us to clearly identify a common set of mutually acceptable identity sources
and a process for accrediting new ones, a few residual problems were uncovered.
Copyright c
2008 John Wiley & Sons, Ltd. Concurrency Computat.: Pract. Exper. 2008; 00:1–7
Prepared using cpeauth.cls

INTEROPERATION OF PRODUCTION E-SCIENCE INFRASTRUCTURES 17
Figure 6. SAML-based Attribute Authority (here VOMS) as crucial authorization element releasing
SAML assertions with attribute information used in cross-Grid authorization. SAML assertions can
transported with Web service invocations for later authorization checks within the middlewares.
Despite the agreement on credentials from IGTF sources being the commonly accepted
set of credentials, end-users frequently made the presumption that because Grids X and Y
are participating in GIN, that any credential which worked with Grid X would also work
for communicating with Grid Y. Since there remain several Grids which recognize local or
lower assurance CA’s for internal purposes, that presumption is incorrect and leads to much
confusion and frustration in end-users getting started with interoperation between Grids. It is
particularly difficult for end-users to recognize beforehand when dealing with service credentials
issued by a local CA (non IGFT). GIN-AUTH strongly recommended and encouraged e-Science
infrastructure administrators that any service for multi-Grid interoperation use only credentials
issued by an IGFT accredited source to avoid such problems in the next years.
Another important work of the GIN-AUTH group is related to the OGSA - BES adoption
and the HPC-BP profile. As mentioned above, the definition of these interfaces and profiles
are a first good step towards the right direction, however, from the GIN perspective, both can
be significantly improved. While a plain OGSA-BES discussion is given later in the text, we
here outline a more advanced security setup that is needed in real production Grids taking the
requirement of an Attribute Authority (AA) [47] like VOMS (or Shibboleth) into account.
In fact, the OMII-Europe project demonstrated at Supercomputing 2007 a scenario using
OGSA-BES services and a VOMS based on the Security Assertion Markup Language (SAML)
[27] as shown in Figure 6. The scenario shown has the potential to provide the long-term
interoperability between UNICORE 6 and gLite as requested by several scientific projects
such as WISDOM. Hence, it is an evolution of the interoperation between UNICORE 5 and
gLite described in the context of job management when DEISA and EGEE have adopted these
new developments. The SAML-based AA releases signed SAML assertions [27] that consists
of attributes with information about group/project membership or roles of end-users. These
SAML assertions are then used in conjunction with Web service invocations (e.g. an OGSA-
BES call) and the Grid middleware (trusting the AA) is using these SAML assertions for
authorization checks (e.g. using XACML-based policies [24]).
SAML-based scenarios could become generally accepted since SAML is already used in
industry, including SAML delegation. This approach is discussed with the OGSA-AuthZ group
to start a GIN spin-off activity in collaboration with security experts to work on an advanced
security profile for OGF Web services interface standards. In fact, one GIN session in OGF23
in Barcelona is planned for the discussion of security problems in interoperability.
Copyright c
2008 John Wiley & Sons, Ltd. Concurrency Computat.: Pract. Exper. 2008; 00:1–7
Prepared using cpeauth.cls

18 OGF GRID INTEROPERATION NOW COMMUNITY GROUP
4. LESSONS LEARNED
The fundamental goals of GIN are gaining experience in world-wide interoperation scenarios
and providing feedback to standardization groups of OGF. In this chapter we take lessons
learned from the last years into account, including experiences from Supercomputing 2006 and
2007 demonstrations as well as numerous OGF sessions and interoperation experiments in the
field. In the later conclusions, on the other hand, we focus more on the concrete groups and
their results and recommendations instead of general GIN infrastructure views presented in
the following sections.
4.1. SW Providers meet GIN and standards
At OGF21, GIN organized a session bringing SW providers and OGF standardization groups
together with the GIN infrastructures. The idea was to have roundtable (not exactly a panel)
for discussion about current issues in standards and to identify what are promising standards
in the near to mid-term future. Participants in the session represented Grid Middleware
technologies such as Globus Toolkit and UNICORE, and middleware enhancers like gLite,
ARC, GRIA, GridWay, CROWN, OMII-UK, and OMII-Europe. Also members of well-known
Grid software stacks participated such as SRB/iRODS and Condor. Of course, the most
infrastructures of GIN have been present in the session.
Initial discussions focused on information schemas and it was generally agreed among all
that GLUE 2.0 is a promising emerging standard that the middleware providers will follow and
also the infrastructures would deploy. Part of the discussion were issues stated from business
about sensitive elements within the GLUE 2.0 schema, which should be not exposed, but
during the discussion it turns out that GLUE as a basic schema is a perfect base for later
dynamic aggregation of information (even business contents) exposed on a trusted per-domain
base. In addition, discussions with GLUE people and data software providers (OGSA-DAI,
SRB) led to the demand of describing data resources/services with GLUE as well.
Other discussions have been around the wide variety of security setups and standards in
the field. There are systems using proxies while others use full X.509 certificates, systems
using classic VOMS (i.e. VOMS Proxies) and others using the SAML-based VOMS, and
many other differences leading to big obstacles in interoperability testings. Generally it was
agreed that there are enough standards out there, but they have been brought together as
a profile usable within infrastructures. Another issue raised was that some groups in OGF
release security standards (i.e. Express AuthN profile) bypassing any security group of OGF.
This potentially lead to inconsistence in security roadmaps for the broader Grid community
and also narrows the scope of only using a subset of security standards available and known
by security experts. As a conclusion of this discussion, we started in GIN, a problems of
interoperability in security spin-off together with the OGSA-AuthZ group. As a first result,
GIN organizes a session at OGF23 trying to work on a more advanced security profile usable in
GIN infrastructures since demonstrated results (e.g. with Username/Password) would be not
deployed on infrastructures and are just for interoperability testings. Topics discussed in this
session will be authorization/authentication in general, and third party credential forwarding
in particular.
Copyright c
2008 John Wiley & Sons, Ltd. Concurrency Computat.: Pract. Exper. 2008; 00:1–7
Prepared using cpeauth.cls

INTEROPERATION OF PRODUCTION E-SCIENCE INFRASTRUCTURES 19
Discussions in the context of computational resource access lead to general agreement
that OGSA-BES is not enough for production usage, but a good first step towards the
right direction. There are issues from all major Grid middleware providers such as Globus,
UNICORE, gLite (CREAM-BES), ARC, CROWN, and numerous others. The issues lead to
the fact that the most implement extensions to OGSA-BES, which in turn makes the interface
implementations not interoperable although the core interface is the same. For instance, the
state model currently used will require extension from many developers of the simple BES
model (Pending/Running/Failed/Finished/Terminated). Hence, extension will follow the ’state
specialization’ instructions and by doing so, other Grid clients can not interprete the status
specialized for one technology. For instance, there is one ARC state difficult to map to the
BES model: Jobs which are not available any longer on the computing service but were served
some time ago (within a grace period) enter into the ”DELETED” state. Also, the UNICORE
state model (i.e. explicit start of activity required) is quite different from the BES model.
There are many other limitations such as the lack of explicit operations to cleanup end-user
space and old activities, the demand for a meta-BES-Factory that creates the BES-Factory
as a stateful service in the context of the optional WS-RF specification support, the demand
for better integration of secure data staging technologies, but most notable better security
setups aligned with OGSA-BES. There is never the vanilla OGSA-BES interface deployed in
the infrastructures, it’s always aligned with a well-defined security setup (e.g. using attribute-
based authorization). The initially adopted Username Token Profile is not realistic for GIN
infrastructures. Hence, due to the many issues on such an important interface, the GIN group
decided to start a spin-off activity and pursue the problems with OGSA-BES and to provide
feedback to the group so that version 2.0 might be better suited for production usage.
Another major discussion topic was the storage and data access, including movement of
data between different infrastructures. Although GIN did some workarounds, it’s still a major
challenge to do this in a production scenario. Some rely on SRMs, some on SRBs, others
use just GridFTP, while some will not open a port range for GridFTP. Even getting two
SRM implementations to work together is not straightforward. Also, the data management
systems work on customized features (i.e. iRods and preservation environments) that are not
covered by a standard SRM interface, but in use by end-users during production scenarios. One
conclusion that can be drawn from the discussion is the requirement for another higher-level
data movement interface that might be the OGSA-Data Movement Interface (OGSA-DMI)
[15]. However, it was also stated that this interface still needs time to evolve and had not
focused so far on the real complicated things (e.g. third party credential forwarding).
To sum up, fundamental lessons learned from this session are that many standards are still
not improved/stable enough to be deployed on GIN infrastructures, although there is already
work going into the right directions (i.e. OGSA-BES, OGSA-DMI). Another conclusion, is
that we urgently require better security profiles, advanced profiles that cover realistic use
cases (e.g. using attribute authorities such as VOMS or Shibboleth). There are many security
specifications out there, the question is how you align them in several profiles. Both lessons
learned lead to GIN spin-off activities that are now actively pursued. The result will be
presented in future OGFs and feed into the standardization process of the respective groups.
Copyright c
2008 John Wiley & Sons, Ltd. Concurrency Computat.: Pract. Exper. 2008; 00:1–7
Prepared using cpeauth.cls

20 OGF GRID INTEROPERATION NOW COMMUNITY GROUP
Table II. Standard adoptions of Grid Middleware deployed on GIN Infrastructures
- gLite Globus Toolkit UNICORE ARC NAREGI NGS
Security X.509 X.509 X.509 X.509 X.509 X.509
VOMS VOMS VOMS VOMS VOMS VOMS
SAML SAML SAML SAML SAML
XACML XACML XACML XACML XACML
Information GLUE GLUE GLUE2 GLUE2 CIM GLUE
Systems XML XML XML XML SQL XML
Accounting RUS/UR RUS/UR RUS/UR RUS/UR RUS/UR
Job Management BES BES BES BES BES
JSDL JSDL JSDL JSDL JSDL JSDL
DRMAA DRMAA DRMAA DRMAA
Data Managment GridFTP GridFTP GridFTP GridFTP GridFTP
SRM2.2 DAIS ByteIO SRM2.2 GFS DAIS
4.2. Standard Adoptions
A crucial point within GIN is the adoption of OGF (and other) standards. The rather slow
process of OGF specification standardization lead to a slow adoption of standards in the
middleware providers. This in turn lead to the fact that many infrastructure had to create their
own solutions in the past while emerging standards have been developed slowly in parallel.
When the standard is available, the question is of why an infrastructure should change their
well-tested technologies to systems that just have been developed and are mostly not good
tested.
In addition, the standards itself seem to change itself rather often (i.e. change from OGSI
as base technology to WS-RF and WS-I in the past). This became even more crucial looking
at the adoption times and deployment rollout schedules of GIN infrastructures. A rollout of
a certain new technology really takes time and is often not even user-friendly (e.g. change of
client technologies for end-users). The question arises if interoperation in a pair-wise fashion
for dedicated scenarios is more realistic sometimes.
Therefore, at OGF22 we had a session in the specification adoption track to get an overview
which standards are adopted (and planned) in which infrastructures in the near to mid-term
future. We have summarized the result in Table II, which basically lists the standard adoptions
of the middleware systems deployed on the infrastructures. Some of infrastructures are missing
and we still request information from these that have been not present at OGF22.
Copyright c
2008 John Wiley & Sons, Ltd. Concurrency Computat.: Pract. Exper. 2008; 00:1–7
Prepared using cpeauth.cls

INTEROPERATION OF PRODUCTION E-SCIENCE INFRASTRUCTURES 21
5. RELATED WORK
There are many pair-wise efforts in the field of interoperation and interoperability within
e-Science communities and Grid projects. These efforts typically include the interoperation
between one specific version of a technology with another one.
EGEE and OSG have a long ongoing pairwise interoperation effort and have achieved full
interoperability that is now moved into a sustainable model. Experiences of this work were
fed back into GIN and in particular bootstrapped the work on GIN-INFO. Similar efforts are
ongoing between EGEE and NAREGI, EGEE and NorduGrid, OSG and TeraGrid, OSG and
PRAGMA. In addition, middleware interoperability efforts are also ongoing between gLite
(EGEE) and UNICORE (DEISA) as well as gLite (EGEE) and ARC (NorduGrid) as part of
the EGEE-II pro ject.
To provide an example, one of the major activities in reaching interoperation between
two production Grids is conducted within the EGEE-II project: a particular activity within
this project focuses on the interoperation between specific versions of gLite and UNICORE.
Specifically, interoperation uses the non Web services-based gLite middleware of EGEE with
the non Web services-based production UNICORE 5 of DEISA. The fundamental goal of this
activity is to work on job submission mechanisms to enable interoperation between EGEE
(HEP and other scientific communities) and DEISA (HPC community) on a technical level. A
closer look reveals that this interoperation is not based on open standards and is fundamentally
based on VOMS. Although related work, members of this activity participated in GIN and
demonstrated their results at the Supercomputing 2007.
The OMII - Europe project [43] deals with interoperability in key areas such as job
submission, accounting, VO management, database access, and portals. In more detail, the
project augments the Grid middleware systems UNICORE, gLite, Globus Toolkits, and
CROWN with certain standards such as OGSA-BES, JSDL, HPC-BP, UR, OGSA-RUS, just
to list some. Also, it makes these middleware systems interoperable with technologies such as
OGSA-DAI and GridSphere. OMII-Europe is one of the key contributors to the GIN efforts
and works on scientific scenarios such as the WISDOM pro ject.
Another interesting related work is the EU-IndiaGrid, which seeks to achieve interoperability
between the European infrastructures (EGEE and DEISA) and the Globus-based GARUDA
[13]. GARUDA is the national Grid of India currently evolving to a full production Grid. The
project develops an architecture that allows for seamless cross-Grid usage so that e-Scientists of
India and Europe can work together to achieve their goals. One particular example application
is related to quantum atomistic simulation using the different scales of systems available in
GARUDA, EGEE, and DEISA. There is also the EU-ChinaGrid project, which seeks to develop
interoperability between the European infrastructure EGEE and CNGRID [11].
Related work in authorization and authentication is undertaken by the German IVOM
project [8], which focuses on the interoperability of VO management technologies in the
German national Grid D-Grid [5]. This is especially interesting since D-Grid is running Globus
Toolkits, gLite, and UNICORE. Members of IVOM have started to work in GIN.
Finally, there are certainly many other projects dealing with interoperability (e.g. EU-
MedGrid interoperability with the Tunisian national Grid GTRS [33] or BRIDGE [3]) that
are all invited to participate within GIN in the future.
Copyright c
2008 John Wiley & Sons, Ltd. Concurrency Computat.: Pract. Exper. 2008; 00:1–7
Prepared using cpeauth.cls

22 OGF GRID INTEROPERATION NOW COMMUNITY GROUP
6. CONCLUSIONS
This paper describes the results of the GIN-CG until early 2008, mentioning highlights of
interoperation demonstrations at the Supercomputing 2006 and 2007 conference, and numerous
OGF sessions. These initial demonstrations provided massive insights into the process of
enabling interoperation among production Grids and e-Science infrastructures in all the
different areas of GIN.
Within GIN-INFO, all information systems are rather similar in their scope and partly
also in their functionality. Therefore, the usage and development of information providers to
populate systems was easier than expected and can be recommended for production Grids
today. This was in particular the case, because the query mechanisms to extract the data
were often based on LDAP, basic WS calls or open standards such as WS-RF. To sum up,
querying an information system and populating another was rather straightforward. More
difficult challenges were revealed in the output of queries, where information is expected
to conform to a dedicated schema. In general, the Grid community can live with different
information systems but not with different content schemas (e.g. GLUE or CIM). If there is a
use case that needs to be done across all Grid infrastructures, then the information we need for
these use cases must be present and in agreement. Also motivated by the efforts undertaken
within GIN, the newly formed GLUE-WG of the OGF works towards a general content schema
acceptable by the broader Grid community.
To demonstrate the feasibility of the interoperation of different information systems and
schemas, the GIN-INFO area demonstrated the Grid site on a world map use case. Hence,
the GIN-INFO area has successfully shown that Grids can be interoperable with respect to
information sharing and exchange, because the GIN Top-Level BDII contains information
about all participating production Grid infrastructures.
The GIN-JOBS area demonstrated that production Grids are able of use upcoming
standardized interfaces for cross-Grid job submission and management. This was particularly
achieved by using the HPC-BP and emerging the standards OGSA-BES and JSDL. Hence,
typically it makes no sense to work on adapters or hacks between the different job submission
technologies when a reasonable technology is soon standardized. However, we also have shown
that some scenarios require fast short-term solutions such in the case of the WISDOM project
that requires interoperation between EGEE and DEISA as soon as possible. At the time
of writing, the HPC-BP and OGSA-BES specifications as well as the HPC extensions of
JSDL are released as OGF recommendations and will soon become an official OGF proposed
recommendation. This will lead to even more adoption by middleware vendors and thus a wider
use of these interfaces within production e-Science infrastructures in the near future. In fact,
also the cross-Grid operations from GIN-OPS revealed that such a standardized interface is a
necessary requirement for production e-Science infrastructures, especially when dealing with
grand challenges (e.g. protein folding or global weather prediction) in interoperation scenarios.
In these scenarios, the use of portals such as the P-Grade resource portal becomes more and
more useful instead of fat middleware clients.
The efforts of the GIN-DATA group have shown that interoperation between different
Grid and e-Science infrastructures can be established via GridFTP, SRB and various SRM
implementations, and in fact all three components can be brought to work together. However,
Copyright c
2008 John Wiley & Sons, Ltd. Concurrency Computat.: Pract. Exper. 2008; 00:1–7
Prepared using cpeauth.cls

INTEROPERATION OF PRODUCTION E-SCIENCE INFRASTRUCTURES 23
it is not a straightforward task. Apart from improvements in information about the service
configurations (e.g. supported versions, location of storage areas, etc.), the main issues for
productive interoperation are in the areas of network tuning (e.g. advanced reserved dedicated
network connections) and firewall management.
The GIN-AUTH group has shown that the base functionality of an identity-based
authentication and authorization system is in place. There is a working federation of the
current major Grid credential generators (the IGTF) and production Grid infrastructures
which can form the basis of a global interoperation infrastructure. Also we have shown that
the GIN group has transformed into a platform to ease collaboration between researchers and
resource owners across the globe by the fact that real production Grids are taking the GIN
VO seriously and integrate them into their access control systems as valid VO. The GIN VO
is now an officially registered VO in OSG to access Fermilab resources in OSG by members
of PRAGMA. Hopefully other world-wide Grid infrastructure will think similar if they would
like to interoperate with other Grid and e-Science infrastructures.
In order to have a strong link into research topics about interoperation and interoperability,
the GIN group organized (together with OMII-Europe) the first International Grid
Interoperation and Interoperability Workshop (IGIIW) at the e-Science 2007 conference in
Bangalore. The method of interoperation and interoperability by gaining access to a wide
variety of resources becomes more and more the interest of the Grid community and thus the
workshop has been used to link different communities and create new cross-Grid collaborations.
This workshop was also beneficial to understand still ma jor open issues in interoperations today
and provided additional topics for the further roadmap of the GIN group. In fact, the group
plans a second IGIIW workshop at the e-Science 2008.
Technically, the described interoperation components can be used today by e-Scientists
within these infrastructures even if there is a negotiation phase needed to agree on resource
usage with the production e-Science infrastructures. In collaboration with the recently started
project OGF-Europe especially such negotiation questions might be solved in the future by
setting up policies that ease the cross-Grid usage on the policy-level. On the technical level, the
GIN efforts and the Supercomputing demonstrations provided a good first start towards world-
wide interoperable e-Science infrastructures and emphasizes that common open standards as
defined by OGF, DMTF, IETF, W3C or OASIS, are absolutely needed.
Finally, it is important to mention that the general supporting funding for Grid and e-
Science infrastructure related topics is decreasing. This will have a major impact in potential
scientific breakthroughs that will be not happening due to decreasing support and manpower
in Grids. In fact, we know that the funding in US was significantly decreased for Grid related
topics. Thus, the most GIN demonstration efforts have been supported by European funding
agencies, which also decrease the amount of money available for Grid-related research, e.g. by
the discontinuation of OMII-Europe while this project was significantly contributing to OGF
in general and GIN in particular. To sum up, the decrease of available funding could lead to
serious sustainability problems for infrastructures and will certainly decrease the efforts for
cross-Grid usage models that are typically based on a best efforts basis.
In this sense, it is important that the world-wide operating Grid and e-Science infrastructures
work more closer together instead of working against each other, for instance by contributing
to the GIN activity. This is particularly important since other communities such as the HPC
Copyright c
2008 John Wiley & Sons, Ltd. Concurrency Computat.: Pract. Exper. 2008; 00:1–7
Prepared using cpeauth.cls

24 OGF GRID INTEROPERATION NOW COMMUNITY GROUP
community are well established over years and thus Grid, as a rather new concept, has to first
prove its broader usefulness. In the past, world-wide Grids have been focused on computational
Grids instead of realizing the real Grid vision, which integrates all kinds of Grid resources far
beyond the scope of computational resources (e.g. telescopes, colliders, or other large-scale
instruments). Therefore, the recent evolution of the many-core and multi-core systems in HPC
and the elastic computing cloud concept have lead to serious considerations if the Grid concept
will remain, even if these systems or concepts only provide computational (and data) related
technologies.
To conclude, only if all infrastructures follow the GIN approach of a United Federation
of Infrastructures including national e-Science infrastructures as well as international ones,
we are able to support the uptake of Grids in the future, which in turn provides funding for
sustainability of our daily used infrastructures to research scientific breakthroughs in e-Science.
ACKNOWLEDGEMENTS
The work presented here is conducted by many talented computer scientists and e-Scientists that are
funded by various public funding organizations that we thank and acknowledge, because this work
would not have been possible without their continuous and sustainable support.
REFERENCES
1. OGF - Grid Interoperation Now Community Group (GIN-CG), http://forge.ogf.org/sf/projects/gin
2. T. Sandholm et al., A service-oriented approach to enforce grid resource allocation, Int. Journal of
Cooperative Inf. Systems, Vol.15, 2006
3. European BRIDGE Project, http://www.bridge-grid.eu
4. Dillaway B., Humphrey M., Smith C., Theimer M., Wasson G., HPC Basic Profile, Version 1.0, GFD.114,
http://www.ogf.org/documents/GFD.114.pdf
5. German National Grid D-Grid, http://www.d-grid.org
6. Foster I., Grimshaw A., Lane P., Lee W., Morgan M., Newhouse S., Pickles S., Pul-
sipher D., Smith C., Theimer M., OGSA Basic Execution Service Version 1.0, GFD.108,
http://www.ogf.org/documents/GFD.108.pdf
7. Mandrichenko I., Allcock W., Perelmutov T., GridFTP v2 Protocol Description, GFD.47,
http://www.ogf.org/documents/GFD.47.pdf
8. German IVOM Project, http://dgi.d-grid.de/index.php?id=314
9. TeraGrid, http://www.teragrid.org/index.php
10. Venturi V., Stagni F., Gianoli A., Ceccanti A., Ciaschini V., Virtual Organization Management Across
Middleware Boundaries, In Proc. of International Interoperation and Interoperability Workshop (IGIIW)
2007, Workshop at e-Science 2007, Bangalore, India
11. China National Grid, http://www.cngrid.org/web/guest/home
12. Nadalin A., Kaler C., Monzillo R., Hallam-Baker Ph., OASIS WS-Security Username
Token Profile 1.1, http://www.oasis-open.org/committees/download.php/16782/wss-v1.1-spec-os-
UsernameTokenProfile.pdf
13. India’s National Grid Computing Initiative, http://www.garudaindia.in
14. Delaite T., Kiss T., Goyeneche A., Terstynszky G., Winter S., Kacsuk P., GEMLCA: Running Legacy Code
Applications as Grid Services, Journal of Grid Computing Vol. 3. No. 1-2. June 2005, Springer Science +
Business Media B.V., Formerly Kluwer Academic Publishers B.V., ISSN 1570-7873 pp 75-90
15. OGF - OGSA - Data Movement Interface Working Group (OGSA-DMI),
https://forge.gridforum.org/sf/projects/ogsa-dmi-wg
16. Dierks T. et al., The Transport Layer Security (TLS) Protocol Version 1.1,
http://tools.ietf.org/html/rfc4346
Copyright c
2008 John Wiley & Sons, Ltd. Concurrency Computat.: Pract. Exper. 2008; 00:1–7
Prepared using cpeauth.cls

INTEROPERATION OF PRODUCTION E-SCIENCE INFRASTRUCTURES 25
17. Nordic DataGrid Facility (NDGF), http://www.ndgf.org/ndgfweb/home.html
18. Foster I. et al., The Anatomy of the Grid - Enable Scalable Virtual Organizations, Grid Computing -
Making the Global Infrastructure a Reality, pages 171–198, 2003
19. Pacific Rim Applications and Grid Midd leware Assembly (PRAGMA), http://www.pragma-grid.net/
20. Rajasekar A., Wan M., Moore R., Schroeder W., A Prototype Rule-based Distributed Data Management
System, Procedings of the HPDC Workshop on Next Generation Distributed Data Mangagement, 2006
21. National Grid Service (NGS), http://www.grid-support.ac.uk/
22. Shoshani A., Sim A., Gu J., Storage Resource Managers - Essential Components on the Grid, Grid
Resource Management, Kluwer Academic Publishers, 2003
23. DMTF: Common Information Model (CIM) Standards, http://www.dmtf.org/standards/cim/
24. OASIS - Extensible Access Control Markup Language (XACML) Technical Committee,
http://www.oasis-open.org/committees/xacml
25. Open Science Grid, http://www.opensciencegrid.org/
26. Kacsuk P., Kiss T., Sipos G., Solving the Grid Interoperability Problem by P-GRADE Portal at Workflow
Level. Proc. of the GELA Workshop at the 15th IEEE International Symposium on High Performance
Distributed Computing (HPDC-15), Paris, France, 2006
27. OASIS - Security Services Technical Committee, Security Assertion Markup Language (SAML),
http://www.oasis-open.org/committees/security
28. Schopf J.M. et al., Monitoring and Discovery in a Web Services Framework: Functionality and
Performance of the Globus Toolkit’s MDS4, Argonne National Laboratory Technical Report ANL/MCS-
P1248-0405, 2004
29. Wide In Silico Docking On Malaria (WISDOM), http://wisdom.eu-egee.fr/
30. GridToday: Striving for Grid Interoperability Now, http://www.gridtoday.com/grid/1918361.html
31. OGF GLUE 2.0 Working Group, https://forge.gridforum.org/sf/pro jects/glue-wg
32. Foster I., Globus Toolkit version 4: Software for Service-Oriented Science, Proceedings of IFIP
International Conference on Network and Parallel Computing, LNCS 3779, pages 213–223, Springer-Verlag,
2005
33. Tunisian Grid (GTRS), http://www.esstt.rnu.tn/utic/gtrs/
34. Streit A. et al., UNICORE - From Project Results to Production Grids, Grid Computing: The New
Frontiers of High Performance Processing, Advances in Parallel Computing 14, pages 357–376, Elsevier,
2005
35. Grid Storage Management (GSM) Working Group, https://forge.gridforum.org/projects/gsm-wg/
36. Bitonti L., Kiss T., Terstynszky G., Delaite T., Winter S., Kacsuk P., Dynamic Testing of Legacy Code
Resources on the Grid, in Proceedings of the ACM International conference on Computing Frontiers.
Ischia, Italy, May 2-5, 2006, pp 261-268
37. OGF - OGSA - Resource Usage Service Working Group (OGSA-RUS),
https://forge.gridforum.org/projects/rus-wg
38. Alfieri R., Cechini R., Ciaschini V., dell’Agnello L., Frohner A., L”orentey K., Spataro F., From gridmap-
file to voms: managing authorization in a grid environment, Future Generation Comp. Syst., 21(4), 549–
558, 2005
39. Berkeley Database Information Index (BDII), https://twiki.cern.ch/twiki/bin/view/EGEE/BDII
40. Mach R., Lepro-Metz R., Jackson S., McGinnis L., Usage Record - Format Recommendation, GFD98,
http://www.ogf.org/documents/GFD.98.pdf
41. Enabling Grid for e-Science (EGEE), http://public.eu-egee.org/
42. Riedel M., Schuller B., Mallmann D., Menday R., Streit A., Tweddell A., Memon M.S., Memon A.S.,
Demuth B., Lippert Th., Snelling D., van den Berghe D., Li V., Drescher M., Geiger A., Ohme
G., Benedyczak K., Bala P., Ratering R., Lukichev A., Web Services Interfaces and Open Standards
Integration into the European UNICORE 6 Grid Midd leware, Proceedings of 2007 Middleware for
Web Services (MWS 2007), Workshop at 11th International IEEE EDOC Conference ”The Enterprise
Computing Conference”, 2007, Annapolis, Maryland, USA
43. Open Middleware Infrastructure Institute for Europe (OMII-Europe), http://www.omii-europe.org
44. Antonioletti M., Collins B., Krause A., Laws S., Magowan J., Malaika S., Paton N., Web Services Data
Access and Integration - The Relational Realisation (WS-DAIR) Specification, Version 1.0, GFD.76,
http://www.ogf.org/documents/GFD.76.pdf
45. NAMD Scalable Molecular Dynamics, http://www.ks.uiuc.edu/Research/namd/
46. Kacsuk P., Sipos G., Multi-Grid, Multi-User Workflows in the P-GRADE Portal, Journal of Grid
Computing, Vol. 3, No. 3-4, Kluwer Academic Publishers, pp. 221-238, 2006
Copyright c
2008 John Wiley & Sons, Ltd. Concurrency Computat.: Pract. Exper. 2008; 00:1–7
Prepared using cpeauth.cls

26 OGF GRID INTEROPERATION NOW COMMUNITY GROUP
47. Farrell S. et al., An Internet Attribute Certificate Profile for Authorization,
http://www.ietf.org/rfc/rfc3281.txt
48. Laure E. et al., Programming The Grid with gLite, Computational Methods in Science and Technology,
pages 33-46, Scientific Publishers OWN, 2006
49. Distributed Infrastructure for Supercomputing Applications (DEISA), http://www.deisa.org
50. R. Piro et al., An Economy-based Accounting Infrastructure for the DataGrid, Proc. of the 4th Int.
Workshop on Grid Comp., Phoenix, 2003
51. dCache, http://www.dcache.org/
52. Stamou K., Hedman F., Iliopoulos A., Extending UNICORE 5 Authentication Model by Supporting Proxy
Certificate Profile Extensions, UNICORE Summit 2007 in conjunction with the European Conference on
Parallel Computing 2007 (Euro-Par 2007), Rennes, France
53. The Monitoring Software for Large Scale Grid System, http://www.opensce.org/components/SCMSWeb
54. Australian Partnership for advanced computing (APAC), http://www.apac.edu.au/
55. Anjomshoaa A., Brisard F., Drescher M., Fellows D., Ly A., McGough S., Pulsipher
D., Savva A., Job Submission Description Language (JSDL) Specification v1.0, GFD.56,
http://www.ogf.org/documents/GFD.56.pdf
56. Time-dependent density functional theory, http://www.tddft.org/
57. Santos N., Koblitz B., Distributed Metadata with the AMGA Metadata Catalog, in Workshop on Next-
Generation Distributed Data Management, HPDC-15, Paris, France, June 2006
58. Open LDAP, http://www.openldap.org
59. Frings W., Riedel M., Streit A., Mallmann D., van den Berghe S., Snelling D., Li V., LLview: User-
Level Monitoring in Computational Grids and e-Science Infrastructures, In Proc. of German e-Science
Conference 2007, Baden-Baden, Germany
60. National Research Grid Initiative (NAREGI), http://www.naregi.org
61. Foster I., Kesselman C., Tsudik G., Tuecke S., A security architecture for computational grids, 5th ACM
Conference on Computer and Communications Security, pages 83–91, Assoc. Comput. Mach Press, New
York, 1998
62. Good G., The LDAP Data Interchange Format (LDIF) - Technical Specification,
http://www.ietf.org/rfc/rfc2849.txt
63. International Grid Trust Federation (IGTF), http://www.gridpma.org/
Copyright c
2008 John Wiley & Sons, Ltd. Concurrency Computat.: Pract. Exper. 2008; 00:1–7
Prepared using cpeauth.cls