
3.2 Shared resources
The GridBlocks website accesses a Globus MDS
server that publishes the attributes of GridBlocks re-
sources. This MDS server can also accept any pub-
licly available service directory where any organiza-
tion can promote their resources. If an GridBlocks
user has a Globus installation on their computer, they
can add their computing resources to GridBlocks by
publishing attributes to the MDS server. This pro-
cedure is detailed on the GridBlocks website and, in
short, includes:
• Configuring the user’s MDS daemon (grid-info-
resource-register) report the computer to the Grid-
BlocksMDS server;
• Making the computer’s Globus installation accept
/C=CH/O=HIP/OU=TECH/CN=112 Test
CA as a certificate authority;
• Modifying the local Globus authorization file
(grid-mapfile) to map proxy certificates with
subject /C=CH/O=HIP/OU=TECH/CN=hillaX to
some user account.
4 THE GRIDBLOCKS AGENT
Here, we consider that the user has received or gener-
ated a personal proxy certificate, and starts their Grid-
Blocks Agent (GB Agent) software, as in Figure 4.
After that, the work flow proceeds as follows:
Figure 4: GridBlocks Agent.
1. The client sends a job request to the “primary”
server with a JAR package of all analysis code.
The client can disconnect right after this step, or
stay connected and receive progress reports from
the server.
2. The request can define which computing servers
will be used. If this is not the case, primary server
can contact a lookup server, locate the data, and dis-
patch the job to the target computers that perform
actual computation.
3. The job is executed on the remote locations, and
status messages are regularly sent to the primary
server. When the analysis is completed, the results
are sent back to the primary server where they are
combined and stored.
4. The client can fetch the results from the primary
server at any time.
The users code, the “agents”, are divided into three
parts. The first part is for actual execution which is
done on remote servers. The second part is used for
combining the results from multiple servers. This can
be seen also as post-processing of results before they
are sent back to the user. The last part of the agent is
for presenting the results to the user in a visual format,
if necessary. This means that results are not limited to
certain formats and the visualization code can contain
some intelligent features, like sending new jobs auto-
matically based on the users input.
Simple Object Access Protocol (SOAP) (Simple
Object Access Protocol, 2002) is used as a transport
media for consistency reasons. The communication
protocol does not use any specific standard, such as
the Foundation for Intelligent Agents (FIPA, 2003)
standards for communication. This fact has been rec-
ognized and the possibility of adhering to a such a
standard in the future is being investigated. The user
authentication and all communication between clients
and servers are secured by the Grid Security Infras-
tructure (GSI). This is achieved by using Java CoG
Kit (The Globus project, 2002) and European Data-
Grid Java Security components (Security Coordina-
tion Group, 2003). Thus, GB Agent is fully compati-
ble with existing Globus security platforms.
5 APPLICATIONS
Originally, GridBlocks was designed for the analy-
sis of high energy physics data, as in Figure 5 (Ni-
inimaki et al., 2003). Recently the software has
been generalised for generic data analysis and dis-
tributed computing applications. We have, for exam-
ple, implemented the distributed aggregation calcula-
tion for OLAP (On-Line Analytical Processing) using
GB Agent and Spitfire (a web front end for relational
databases (Hoschek and McCance, 2001)). We have
also tested the use of neural network-based distributed
optimization applications.
Implementing new applications is very easy be-
cause of the mobile Java code. The user must only
GRIDBLOCKS - WEB PORTAL AND CLIENT FOR DISTRIBUTED COMPUTING
39