InfoGram: A Grid Service that Supports Both Information Queries and Job Execution

High Performance Distributed Computing (HPDC-11), Edinburgh, Scotland, July 24-26, 2002
InfoGram: A Grid Service that Supports Both Information Queries and Job
Execution
Gregor von Laszewski
�
, Ian Foster
�
, Jarek Gawor
�
, Andreas Schreiber
� ��
, Carlos J. Pen˜a
� ��
�
Argonne National Laboratory, 9700 S. Cass Ave, Argonne IL 60439, U.S.A.
�
German Aerospace Center (DLR), Linder Ho¨he, 51147 Cologne, Germany
�
State University of New York at Stony Brook, Stony Brook, NY 11794, U.S.A.
gregor@mcs.anl.gov
Contents
1. Introduction 1
2. Execution Service 2
3. Information Service 2
4. Using GRAM and MDS in Production Grids 3
5 Addressing Requirements for the InfoGram Service 3
5.1. Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
5.2. Quality of Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5.3. Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5.4. Portability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5.5. Flexible and Extensible Information Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
6. InfoGRAM Architecture 4
6.1. Job execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6.2. Information Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6.3. Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6.4. Caching and Information Degradation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.5. Service Reflection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.6. Client Interaction through xRSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7. Implementation 7
8. Application 8
9. Related Work 8
10. Status and Future Plans 8
11. Discussion and Conclusion 9

InfoGram: A Grid Service that Supports Both Information Queries and Job
Execution
Gregor von Laszewski
�
, Jarek Gawor
�
, Carlos J. Pen˜a
���
and Ian Foster
�
�
Argonne National Laboratory, 9700 S. Cass Ave, Argonne IL 60439, U.S.A.
�
State University of New York at Stony Brook, Stony Brook, NY 11794, U.S.A.
gregor@mcs.anl.gov
Abstract
The research described in this paper is performed as
part of the Globus Project. It introduces a new Grid ser-
vice called InfoGram that combines the ability of serving as
information service and as a job execution service. Pre-
viously, both services were architected and implemented
within the Globus Toolkit as two different services with dif-
ferent wire protocols. Our service demonstrates a signif-
icant simplification of the architecture while treating job
submissions and information queries alike. The advantage
of our service is that it provides backwards compatibility
to existing Grid services, while at the same time provid-
ing forwards compatibility to the emerging Web services
world. Part of the work conducted within this effort is al-
ready reused by the current Open Grid Services Architec-
ture prototype implementation.
1. Introduction
The Grid approach is an important development in the
discipline of computer science and engineering[30]. It
is making rapid progress on several levels, including the
definition of terminology, the design of an architecture
and framework [13], the application in scientific problems
[5, 4], and the creation of physical instantiations of Grids on
a production level [10, 3, 2]. Grids provide an infrastructure
that allows for flexible, secure, coordinated resource sharing
among dynamic collections of individuals, resources, and
organizations.
Over the past few years, the Globus Project has devel-
oped the Globus Toolkit [18] that provides a basic Grid
middleware toolkit, which includes elementary services to
address Grid management issues related to resource man-
agement, security, information, and data management [30].
Two of the most important Grid services that are provided
by the Globus Toolkit are the information service and the
job execution service.
The information service returns information about the
capabilities and the state of the Grid infrastructure. The
Globus Toolkit provides such an information service called
Monitoring and Directory Service (MDS) [31, 7], formerly
known as Metacomputing Directory Service.
The job execution service controls the submission and
execution of jobs on remote machines. The Globus Toolkit
provides such a service under the name Grid Resource Allo-
cation and Management (GRAM) service [9]. GRAM pro-
cesses requests for execution, performs resource allocation,
monitors, and controls job execution. Furthermore, a lim-
ited amount of information related to the capabilities and
availability regarding the job execution service for a Grid
resource can be exposed through an information provider to
the MDS. This information includes, for example, the name
of the queue, details about the mode of operation, and other
important features that may guide the process of job sub-
mission by the user. Authentication to MDS and GRAM
are handled through the Grid Security Infrastructure (GSI)
[6].
The information and job execution service have so far
existed as separate services within the Globus Toolkit. Con-
siderable software engineering effort is necessary to imple-
ment, maintain, and deploy these services while at the same
time support interoperability. We argue that this complex-
ity can be reduced significantly by alternative approaches to
both protocol design and implementation. To test this hy-
pothesis, we developed a prototype that promises a signifi-
cant simplification in all aspects previously mentioned. We
have termed our prototype InfoGram in order to acknowl-
edge its dual purpose.
Our research has the following objectives and goals:
� Design of a simplified Grid service architecture to pro-
vide a unified service for information, monitoring, and
job submission.
� Develop this service while providing backwards com-
patibility by adhering to standard Grid protocols.

� Support multiple information return request formats
such as LDIF and XML.
� Improve the reliability of the job execution and in a
second phase while replacing the protocol used to per-
form the Job submission with SOAP.
� Provide an open framework that can be easily adapted
to interact with local schedulers and extract informa-
tion through custom designed information providers.
� Provide a framework that is based on GSI and its ap-
plication within the Globus toolkit to map Global Grid
User Identifiers to local account names.
� Develop this service while providing forwards compat-
ibility to Web services.
� Build a groundwork for a Web services based imple-
mentation of Globus services.
The rest of this paper is structured as follows: First, we
discuss the Globus Toolkit services GRAM and MDS in
more detail. We outline how the operational integration of
these services is achieved in production Grids. Next, we
present the enhancements to the GRAM service that allow
constructing our InfoGram service. We demonstrate that
our service provides a significant architectural simplifica-
tion but at the same time provides enhancements currently
not available in the Globus Toolkit. Additionally, we show
that this new service can still be integrated into the existing
MDS concept. Finally, we outline how such a service can
be used as part of Grid applications.
2. Execution Service
To contrast our differences to the Globus GRAM it is
necessary to revisit the architecture of the Globus GRAM
service. The basic structure of a GRAM service (version
1.1.x) and its interaction with clients relevant for our discus-
sion is depicted in Figure 1. A GRAM service provides the
basic functionality for secure and uniform access to remote
computational resources. The functionality of GRAM can
be explained as part of a typical three tier architecture. Be-
fore we include our enhancements to this architecture (Sec-
tion 6), we explain the functionality of each tier in more
detail.
Client Tier. A client can submit a job to a remote re-
source and can check on its status either through polling the
status of the job or through event notification to the client
through the GRAM Service. To allow identification of the
job, a job handle (often referred to GlobusID) is returned
on job startup so that it can be used for later connection,
including from other remote clients with appropriate autho-
rization. For example, this job handle can be used to contact
the job and issue a cancellation.
GRAM Server
Job ManagerGatekeeperClient Local JobExecution
Client Tier Middle Tier Backend Tier
Security
Policy
GRAMP
GRAMP
RSL Log
Figure 1. The Gram Architecture
Middle Tier. Internally, GRAM consists of a gatekeeper
and a job manger. The gatekeeper is responsible for authen-
tication with the client, performing a simple authorization
based on mapping the authentication information into a lo-
cal security context (e.g., a Unix login). After this initial se-
curity check, it starts up a job manager that interacts there-
after with the client based on the GRAM protocol (from
now on referred to as GRAMP). Each job submitted by a
client to the same GRAM will start its own job manager.
Backend Tier. Once the job manager is activated, it han-
dles the communication between the client and the backend
system on which the job is executed. The backend tier is
easily portable to various scheduling systems. The Globus
Toolkit services provide scheduling interfaces such as PBS,
LSF, Condor, and Unix process fork [21, 18].
The GRAM service can be accessed with the help of a
C or a Java application interface. This interface includes
the ability to specify a job runable on a particular resource
with the help of a uniform Resource Specification Language
(RSL). The RSL makes it possible to quickly and uniformly
specify jobs to be run as part of a Globus enabled Grid.
Simple tools are available to access the basic functionality
also from the command line.
Although, we have in the past demonstrated mechanisms
and protocols for application states and notification, such
advanced functionality [32] has not yet been included in the
Globus Toolkit.
3. Information Service
The basic structure of a Grid information service is de-
fined in [31] and was further refined in [8]. A Grid informa-
tion service requires:
� access to static and dynamic information regarding
system components and services,

� a framework that fits well with the heterogeneous
and dynamic nature of Grids, including decentralized
maintenance and operation,
� scalability and performance,
� integration of a variety of information providers.
The Globus Project has developed a basic information
service that addresses these requirements. The Globus Grid
information service, MDS, contains two fundamental enti-
ties: distributed information providers and information ag-
gregates. An information provider is a service that provides
a subset of useful information about resources exploited by
Grid users or Grid services. Examples of information that
may be accessed through such an information provider is
CPU, operating system, network, and file system informa-
tion.
Additionally, the aggregate service is used to integrate
a set of information providers that may be part of a vir-
tual organization [14]. To increase the scalability of a dis-
tributed information service, the MDS provides an informa-
tion caching function that allows viewing and querying the
information about a resource from a cache. Furthermore,
the newest implementation of a Grid information service
that implements the framework proposed by the MDS con-
cept integrates GSI to perform authentication.
The information contained within MDS can be queried
and used to enable more sophisticated Grid services. More
details about the protocols, the services, and the newest
nomenclature can be found in [17, 7].
The research within this paper concentrates on the in-
formation provider itself, as we can create information ag-
gregates through reuse of information providers to improve
scalability. Furthermore, we argue that it is worthwhile to
provide google-like services, as have been used in many
previous Grid like projects [28, 29, 11].
4. Using GRAM and MDS in Production Grids
Figure 2 shows how the GRAM and the MDS services
may be used in a simple production Grid. Our Grid con-
sists of one virtual organization that maintains a number
of compute resources. Each compute resource has the
Globus GRAM and the Globus Resource Information Ser-
vice (GRIS) that returns information related to the local re-
source installed.
In order for a client to perform a job execution and an
information query, two different mechanisms for contact-
ing these services must be used. Not only do the services
operate through different ports, but they also use different
protocols making the amount of code sharing for interpret-
ing return values more complex. The installation of both
services requires additional sophistication. We feel that the
Virtual Organization
Resource Layer
Connectivity Layer
Client
GRIS backend
GRAM
Figure 2. A sample interaction between a
client, GRAM, and MDS
use of different technologies is in contrast with the desire to
provide a minimal set of protocols and services for Grids as
promoted by the Global Grid Forum and the Globus Project
[14]. If we think abstractly about job execution and an in-
formation service, we must recognize that they are based on
the same principle: A query formulated and submitted to a
server followed by a stream of information that returns the
result based on the query.
5 Addressing Requirements for the Info-
Gram Service
We have designed our InfoGram service according to a
set of requirements determined by general software engi-
neering practices which include factors such as quality, per-
formance, reliability, security, and portability. All of these
factors must be addressed within the realm of Grids. Never-
theless, we concentrate our efforts on the following issues.
5.1. Performance
An information and Job execution service must perform
their tasks quickly. The elapsed time between job request
and job submission must be as short as possible. At the
same time, information within the system must be accessi-
ble quickly. For example, it may be inefficient to execute
each time a user requests data the program creating the data
or a query relayed to an external information service. A
simple example will illustrate our point. Assume we have
a large number of clients that need to know the CPU load
of a remote compute resource. It would be wasteful to ex-
ecute the command requesting the load every single time.
Instead, it can be more efficient to cache this value within
the information service, and only refresh this cache value

periodically. In order to prevent staleness of information
we attach a time to live (TTL) value with the information.
This value will tell us when a refresh of the information in
the cache is necessary.
5.2. Quality of Information
Information within Grids may become quickly inaccu-
rate. We often observe two cases. Case One: In the sim-
plest form the information can be describe as binary system
where the information is either accurate or inaccurate. Case
Two: In many other situations the information may degrade
over time in a discrete fashion. Thus, it is not unreason-
able to attach a degradation function with the actual value
of information that reflects the degree of degradation. This
function may be influenced by time, system state, or predic-
tion functions to derive a quality of information assessment.
Often it is possible to attempt to derive such degradation
information through observation or through mathematical
models while performing self correction based on observa-
tion data. This is not unlike sophisticated data assimilation
as used in climate research that corrects its values based
on a comparison between observations and prediction mod-
els. The quality of information becomes important in case
more sophisticated resource management strategies are de-
veloped. If I obtain an attribute such as “mean CPU load”
from a Grid information service, it is beneficial to have the
quality of the information attached. Knowing the standard
deviation or knowing that the accuracy of the value is valid
over the last hour or the last day is an important factor to
create more sophisticated Grid services.
5.3. Security
Access to services such as the information and job ex-
ecution needs to be performed securely. The Grid Secu-
rity Infrastructure (GSI) provides us with an elementary
framework for authentication. Nevertheless, authentication
is only one problem to be addressed within Grids. In our
framework, we strive to include authorization that allows us
to specify contracts such as “allow access to this resource
from 3 to 4 pm to user X.” Additions to GSI and the use
of more sophisticated authentication frameworks [27] may
provide them in the future.
5.4. Portability
Protocol compatibility of these services is preserved with
the Globus Toolkit while using the GRAM, and Grid Se-
curity Infrastructure (GSI) protocols. Future activities will
include the integration of commodity protocols (such as
SOAP) to provide interoperability to Web services and
greater acceptance outside of the Grid community [15, 36,
38, 37].
5.5. Flexible and Extensible Information Model
One of the issues we face with information providers is
the lack of a standard that is uniformly adhered by the com-
munity. We observe the use of CIM, MIB, MDS, or non
standard or unorthodox display of information in tables. Al-
though we believe that the creation of a consistent informa-
tion model is an important one, we focus within this paper
on the mechanism of delivering that information to the user.
The reasoning for this strategy is that our InfoGram service
provides the necessary mechanisms for delivering the infor-
mation according to the information model used within the
information provider. Our positive experience with the use
of XML schemas as basis for the next generation of Infor-
mation services makes us believe that it provides a viable
alternative to the currently used LDAP schemas. Compati-
bility can be maintained while developing strict guidelines
for the object definition by the Global Grid Forum.
Nevertheless, we believe that an additional requirement
must be fulfilled to enhance the use and acceptance of Grids.
We believe that the execution of untrusted applications in
trusted environments is important to enable the use of Grids.
We hope that through this feature the user community will
increase dramatically based on software that is developed
as part of our activities.
Providing such software will enable the creation of in-
frastructures that will promote Grids in new communities,
which previously did not have the luxury to access high end
resources. Besides making access to supercomputer cen-
ters for outside users much more feasible, we foresee that
resource providers may be more willing to contribute re-
sources otherwise not part of the national-scale Grids.
6. InfoGRAM Architecture
As pointed out earlier, we modified the architecture of
the GRAM server and enhanced it substantially in order to
fulfill the requirements described earlier. We added to the
original architecture additional components, as shown by
the shaded components in Figure 3, and describe these en-
hancements based on the functionality they are providing.
These functionalities are centered on client interaction, log-
ging and check pointing, job execution, information man-
agement, and configuration.
Logging and check pointing is enabled through a logging
service. This service can receive logging events from sev-
eral components. The log can either be stored in the middle
tier, or on the backend tier. In either case the log can be
used to restart our InfoGRAM service in case it needs to be
restarted (e.g. the machine was shut down). In the same way
it would be possible to use the logging service for check
pointing of applications. Presently, we only record mini-
mal information such as the command used and arguments