GUSTOFarm: A Software Framework for Constructing a Utility Computing
Infrastructure
Sivadon Chaisiri
Asia Pacific Science and Technology Facility,
Faculty of Engineering, Kasetsart University,
Thailand
E-mail: sivadonc@apstf.cpe.ku.ac.th
Abstract
Building a utility computing infrastructure is a
challenging task since it requires a very scalable and
flexible middleware that can control resources
allocation in an on demand fashion. This paper
presents a design of a software framework called
GUSTOFarm. This Java and JXTA based system
allows programmer to provide utility like services in a
highly heterogeneous computing environment. The
architecture and design have been presented along
with the discussion of implementation issues involved.
The prototype system has been evaluated using a
graphic rendering application. The experimental
results show that this system can function well in a
heterogeneous distributed system. GUSTOFarm
system is a useful starting point toward the building of
full utility computing infrastructure.
Keywords: peer-to-peer computing, utility
computing, grid computing
1. Introduction
Utility computing [1, 2] is a model for
automatically constructing and managing resources
located in large distributed systems. In this model, the
infrastructure can dynamically provide resources that
match the users’ need. For example, a user needs
resources included 1 gigabytes of physical memory, 10
teraflops of processor, and installed matrices
multiplication software. After the user requests those
resources from the infrastructure, the user should get
an access method to connect those resources from the
Putchong Uthayopas
High Performance Computing and Networking
Center, Faculty of Engineering, Kasetsart
University, Thailand
E-mail: pu@ku.ac.th
infrastructure as well. The benefit of the model makes
resources can be utilized in a much more efficient way
[4].
In this work, we propose a framework called
“GUSTOFarm” (referred to Grid Utilization System
Toolkit on Office Farm). GUSTOFarm helps manage a
group of computers that provides a set of services. The
framework can utilize the computing power of those
computers by allocating them based on proper
services, then returning their locations to users. So the
users can develop software that utilized these
functionality computers. GUSTOFarm provides
architecture and application programming interface for
constructing an effective utility computing based
applications.
2. Related Works
Utility computing is a model that view resources as
utilities that user can use regardless of the locations
and pay for the cost based on the real utilization of
those resources by users [3]. The work in this area is
still in a very beginning stage. One of the widely
adopted models is grid computing [6]. The
mechanisms of the utility computing infrastructure are
much related to the mechanisms of grid computing.
These include services such as resource discovery
mechanism, job submission mechanism, monitor
mechanism and security mechanism. However, utility
computing infrastructure must deal with a much more
dynamic requirement from users and manage much
more dynamic infrastructure than Grid.
In this work, the part of the proposed architecture
relies on peer-to-peer mechanism [9] to support utility
computing infrastructure. The peer-to-peer system
provides efficient mechanisms to make a very large
resource sharing network [13]. Additionally, the
resource discovery mechanism provided by peer-to-
peer system can fully distribute the work without
requiring a centralized server for indexing the
locations of resources. Consequently, the system can
avoid the single point of failure that can be found on
many centralized systems and it still works on the large
scalable network. Moreover, the peer-to-peer system
usually provides dynamism solution to support freely
joining to and leaving from the network of any
resources without interfering to the whole system.
To implement our framework and also its
infrastructure of the utility computing, we choose Java
and JXTA [8] to be the runtime environment of the
system. JXTA is a framework for developing a peer-
to-peer application. It also provides a set of standard
protocols that most of peer-to-peer applications
require. Hence, the other frameworks that rely on such
protocols can be possibly interoperated with our
framework.
3. Proposed Work
In this work, we propose a framework called
GUSTOFarm. This framework is designed to build a
system consisted a collection of services provided by
computers. A computer located on the system is called
“Peer” and a service provided on a computer is called
“Utility service”.
A utility service provides a specified function. For
example, a utility service with a matrices
multiplication function and a utility service with a
graphics rendering function. A collection of some
utility services provide a solution for IT applications.
To provide shared resources on the system, we
propose that the resources must be provided via utility
services. For example, if we need to share a database
on the system, then we must provide a utility service
that can share and discovery the local database. We
define the basic requirements for developing the
framework as the following:
- Dynamism utility services can freely join and
leave the system without interfering to the whole
runtime system. Furthermore, utility services can be
unavailable for a period of time.
- Scalability a utility computing infrastructure
should be able to scale to a very large size. This feature
can provide a variety of utility services and also
support more redundancy of utility services.
- Heterogeneity a utility computing infrastructure
could be composed of the multiple computer platforms
(e.g., Microsoft Windows platforms, UNIX platforms,
and Apple Macintosh platforms).
- Interoperability a utility computing infrastructure
should interoperate with other utility computing
infrastructures.
To make a framework that supports the four
features listed above, so we design the architecture that
is described as the next section.
3.1 GUSTOFarm Architecture
In Figure 1, we present the GUSTOFarm
architecture. The architecture is divided into 5 layers as
follows:
1) Java Platform Layer is the lowest layer that
provides the runtime environment of every peer in the
system. The environment includes operating systems
and computer hardware. Moreover, the layer also
provides shared resources (e.g., shared files and
database etc.).
Figure 1. The proposed architecture of
GUSTOFarm framework
To make the framework to support heterogeneity
platform, we define that the Java runtime environment
must be installed on every peer.
2) Utility Services Layer is the layer of utility
services. A utility service will provide some functions
based on the Service Oriented Architecture (SOA)
[11]. So a utility service can be implemented as web
service or grid service [7]. To provide an
interoperability feature between utility services and
applications which call them, a utility service should
be relied on the Simple Object Access Protocol
(SOAP) and communicating messages should be
implemented as XML documents.
This layer must provide a mechanism for declaring
the existence and status of a utility service to be known
by other peers. The mechanism is called “Service
Advertisement” that will be discussed in the next 5) Application Layer is the top layer of users’
subsection. applications. An application is developed to call
3) JXTA Runtime Layer is the layer that provides required utility services. To allocate the utility services
a communication mechanism and functions that to an application, hence; the application must invoke
supporting the core services (that running on the Core the underlying core services (provided on the core
services layer). JXTA can support the scalability and services layer) for discovery the required utility
dynamism of the system. Furthermore, The JXTA services, monitor the connecting peers, and others. To
provides the communication mechanism that uses the develop an application to call the core services, hence;
standard XML as communicated messages between the framework provides an Application Programming
peers. So the framework can be possibly interpolated Interface API) for the calling.
with other frameworks that relied on the same
messages (e.g., the framework that uses Microsoft 3.2 Service Advertisement Mechanism
.NET Framework as the runtime environment of the
system). In this subsection, we will discuss the service
4) Core service Layer is the layer that provides the advertisement mechanism that used to declaring a
core services for supporting the basic functions of the utility service to be known by other peers. The
applications running on the utility computing mechanism works at the utility service layer.
infrastructure. The core services are listed as follows: In fact, the mechanism is developed by an
- Resource Discovery Service (RDS) is the service advertisement mechanism provided by the JXTA. The
for discovery the required utility services. The RDS advertisement mechanism is used to declare the
also functions the indexing and caching the locations metadata of a resource shared in a peer-to-peer
of utility service to accelerate the speed of discovery. network. The metadata consists of key and value pairs.
- Resource Monitoring Service (RMS) is the The metadata is helpful for discovery by any peers.
service for monitoring and tracking the existence and When a peer needs to find out some resources, it
performance status of peers (e.g., uptime and must specify the required attributes via some key and
downtime, available memory, free physical storage, value pairs. Then it sends the requirement to a
load of processor, and bandwidth network etc.). The discovery mechanism. The mechanism will search the
static status can be retrieved by this service too (e.g., matched resources by comparing the user’s
the kernel version of the operating system, the model requirement with the metadata declared in the
of processor, and the number of processor etc.). searching peer.
- Job Execution Service (JES) is the service for
submitting jobs to compute on a specified peer. A job
is meant as a program that may include parameters and
data to run.
- Workload Distribution Service (WDS) is the
service for balancing load of computing jobs that will
be submitted to peers. WDS must also support the
loads that occurred from calling utility services.
The WDS collaborates with JES for distributing
jobs and with RMS for decision making of choosing
peers which will be submitted jobs to. So the WDS
must provide some efficient algorithms for efficient
utilization of the system.
- File Management Service (FMS) is the service
for sharing files and transferring files among peers
inside the system.
- Authentication and Authorization Service
Figure 2. An example of a service
(AAS) is the service for control security inside the
advertisement of a utility service
system. The AAS consists of 2 functions:
authentication and authorization. The authentication
In the JXTA, the advertisement is a common XML
function is used to authenticate users and peers that
document consisted of some tags that each tag referred
login to the system. The authorization function is used
to a key and value pair of the metadata. For our
to control the access of peers to resources or utility
framework, we define that a service advertisement
services which the peers have the right to access.
describes the metadata of a utility service. The
metadata includes service name (the name of the utility
service), service description (short description of the
utility service), peer ID (unique code of the peer),
service type (type of the utility service: web service or
grid service), and service location (the URL to invoke
the utility service). The example of a service
advertisement is presented in Figure 2.
Figure 2 presents that this service advertisement
describes the metadata of a utility service named
“Raytrace” (see from the Name tag). The peer ID
(presented in the “PeerID” tag) is a unique code of the
peer that provides this utility service. A peer can get its
own peer ID when it firstly entered the system. The
“URL” tag represents the location for invoking the
function of the utility service. The “ServiceType” tag
shows that this utility service was implemented as a
web service. The “Description” tag gives the short
description of the utility service to be more
understandable by the user.
The RDS will use the service advertisement for
discovery. Hence, the application must build a query
message (included the key and value pair of service
advertisement) and submit it to RDS. In Figure 3, we
present the time diagram of calling the RDS.
The interaction of calling the RDS consists of 4
steps as follows
1) The application requests the RDS for discovery a
required utility service.
2) The RDS searches for the matched service
advertisements that declared on the peers that the RDS
connects to.
3) When the RDS find the matched service
advertisement, it will reply such service advertisement
to the requested application.
4) The application invokes the utility service via the
URL retrieved from the replied service advertisement.
Figure 3. A time diagram of calling the RDS
3.3 Implementation of the Framework
The GUSTOFarm framework is implemented by
Java and JXTA. In this subsection, we discuss on the
implementation of the core services layer.
In the core services layer, we finished the
implementation of RDS, RMS and AAS. The detail of
implementation of such services is presented as
follows
The RDS is implemented by the discovery
mechanism provided by the JXTA. The JXTA also
provides the Java library to call the mechanism. The
mechanism can allocate the specified utility services
by searching the metadata described in the service
advertisement located on the searching peers. The
matched advertisement will be replied to the requested
application (also see the Figure 3)
The RMS is implemented by a mechanism called
“resolver service” provided by the JXTA. The JXTA
provides the Java library for creating a query message.
The query message describes the status that the request
application needs to know. The library also includes a
function to submit the query message to the peer
specified by the peer ID. The specified peer can reply
its current status requested by the query message to the
request application.
Currently, the AAS is implemented by a framework
named “JXTA security toolkit”. The framework
provides the security model for using in a peer-to-peer
system. The AAS can authenticate a peer by
determining the specified username and password
filled when the peer entering the system.
The AAS currently does not support the
authorization. Because the JXTA security toolkit still
does not provides methods of the authorization.
However, we expect to use the Java Authorization and
Authentication Service (JAAS) for implementing the
authorization.
JES, FMS, and WDS are still in the development
step. To develop the JES, we will develop a utility
service installed to all peers for getting a request for
running a specified program from an application. The
request includes the name of the running program
(may include some parameters to run the program),
and the destination peer that program will run on.
Moreover, we define that the running program must be
preinstalled on the destination peer. However, the
application can submit a program with the FMS to
install on the destination peer.
For the first stage, we will develop the FMS by
using the advertisement mechanism provided by the
JXTA. We called the advertisement for described the
metadata of a file as “File Advertisement”. The
metadata consists of file name, file type (e.g., movies,
music, and picture etc.), file size, and a protocol for
downloading and uploading the file.
The WDS is a part of the “Broker Agent Project” –
the project of the OpenUCI. The broker agent is the
daemon software for providing the required utility
services with some specified performance status of
peers that hosted the utility services. Moreover, the
agent also provides some load balancing mechanism
for distributing loads to the appropriate peers.
3.4 Application Programming Interface
This subsection introduces the application
programming interface (API) provided for calling the
core services. The API provides some useful Java
classes for developing an application for running on
the application layer. Although the API provides many
classes, in fact a user can use a few classes for
developing his own application.
In Figure 4, we present three class diagrams of Java
classes that a user can use for implementing an
application using on the GUSTOFarm framework.
The GUSTOEngine is a main class for calling the
core services. Currently, the GUSTOEngine class still
supports the calling to 3 core services: AAS, RDS, and
RMS. Each core service can be called by invoking the
method of GUSTOEngine.
The login method is used to enter to the system of
GUSTOFarm via connecting to the AAS. The AAS
can authenticate a user via determining the parameters
username and password. The method returns the
unique peer ID (in the String format) of the local
computer which the application running on. The logout
method is used to leave from the system.
Figure 4. Class diagrams presenting three
classes that a user uses for implementing an
application
The query method is used to call the RDS for
discovery. The method will return an array of
ServiceAdvertisement object as the querying result.
This method consists of 4 parameters: peerID,
serviceName, timeout, and minRequire. After invoking
the method, the RDS will create a query message
depends on such parameters. If a user sets peerID as
the Java null pointer, the RDS will propagate the query
message to a group of random known peers.
Otherwise, if the user sets a specified peerID which
exists in the system, the RDS will directly submit the
message to that peer.
The serviceName parameter is used to specify the
name of utility service that we need to find out. We
can use an asterisk (*) wildcard. For example, we can
specify “Raytrace” for the absolute name.
Additionally, the user can specify “Raytrace*” as a
prefix “Raytrace” of the name.
The timeout parameter is used to control the infinite
waiting of the replied results. The minRequire is used
to stop waiting the result when the size of array of
ServiceAdvertisement is adequate to the requirement of
the user’s application.
We can monitor the specified peer by the monitor
method. The method consists of only one peerID
parameter for specifying the peer ID of the peer which
we need to monitor. The result will be returned in the
Performance object.
The ServiceAdvertisement class represents the
object of the service advertisement which consists of
the metadata of the utility service (also see Figure 2).
The class consists of five methods for accessing such
metadata.
The Performance class represents the object of the
currently performance status of the peer. A user can
retrieve the status via the provided methods. For
example, if a user wants to retrieve the free physical
memory, he can invoke the getMemUsed for this data.
Although the API provides only Java classes for
implement an application. However, providing APIs
for supporting other languages can be possible.
4. Evaluation
To evaluate the performance of the GUSTOFarm
framework, we develop a program based on master -
worker computing model. We implement a utility
service as a worker application by Java web service
development library named “Apache Axis” [10]. The
utility service provides a retracing function for
rendering a scene of picture. The code of rendering is
improved from open-source rendering software coded
by Computer Graphics Group at MIT [5]. The code
can render the scene coded in a script file. We use a
made script file for every testing. The Figure 5 shows We use 2 testing methods for evaluate a system that
the final rendered picture coded in the script file. built by the GUSTOFarm framework. The methods are
presented in subsection 4.1 and 4.2 as follows

4.1 Parallel Computing Test

70
1000x1000
60 2000x2000

Execution Time (sec.)

3000x3000
50

40

30

20

10

0
0 1 2 3 4 5 6 7 8 9
Figure 5. The picture which rendered by our Number of Block
implemented utility service
Figure 6. The execution time for testing the
We install this utility service on all tested system with the parallel computing
computers. A computer running this utility service is application
called as “worker peer”.
3
Table1: The configuration of computers using
in the test-bed environment 2.5

Type of Peer and Hardware Operating 2

Speedup

a number of Peer Specification System

Dual UltraSparc Solaris 10 for Sun 1.5
1 Master Peer IIIi 1.5 GHz, Sparc platform
2 GB of RAM 1
1000x1000
AMD Athlon64 MS Windows - 2000x2000
8 Worker Peers 2 GHz, 1GB of 2003 Enterprise 0.5 3000x3000
RAM x64 Edition
AMD AthlonXP Linux with kernel 0
0 2 4 6 8 10
8 Worker Peers 1.8 GHz, version 2.4.22
512MB of RAM Number of Block

We implement the master application by using Java
development kit and the API provided by the
GUSTOFarm framework. However, we only choose
the method to call the RDS for discovery the worker
peers for calling the utility service. We call a computer
installed the master application as “master peer”.
To build a test-bed environment, we prepare 17
computers supported by High Performance Computing
and Networking Center. In Table1, we present the
configuration of computers for building a master peer
and 16 worker peers. The configuration presents the
heterogeneous system that consists of multiple
platforms. We choose the 100 Mbps Ethernet as the
communication network connecting the computers.
Figure 7. The speedup of running the parallel
computing application
The method is to test the system by developing the
master application to distribute a job to process on
multiple worker peers in the parallel fashion. To
implement the parallel application, the application
divides the scene of picture into a set of block. Each
block is independent to others. Then the application
submits the divided blocks to the queried worker peers.
We test the application by defining the various sizes
of the final rendered picture: 1000 x 1000, 2000 x
2000 and 3000 x 3000 pixels. The big picture
consumes more computational time and size of
memory than the smaller one. Then we divide the
picture with different numbers of block. Furthermore,
the master application must discovery the worker peers
with the number of peers equal to the number of block.
Hence, every worker peer will compute only one block
for once time per testing (one testing done by one size
of picture and a number of blocks).
Figure 6 presents the execution time of testing the
parallel computing application with different testing. In
Figure 7 presents the speedup achieved when adding
more worker peers. We see that the speedup is scaled
down when we increase more worker peers for the
picture size 1000 x 1000 pixels. The reason is the
overhead of the framework and the communication
time overwhelms the computational time that makes
the speed up is slow down.
However, the overall speedup is not quite well due
to the additional number of worker peers. The factor
that effects to this result is the code of rendering is not
quite suitable for dividing the scene into blocks. To
submit a block to a utility service, in master of fact the
application must submit the whole scene (not only that
block). Then the application specifies two coordinators
(from one x, y coordinator to another) for locating the
block that will be rendered. Moreover, submitting the
whole scene may consume a large size of memory;
although, the small block may take more short time of
computing. So the virtual memory may be activated for
the large size of data. Then the overall execution time
may be tremendous slow down.
4.2 High Throughput Computing Test
600
250x250
500
500x500
Throughputs / 1 min.
400
300
200
100
0
0 2 4 6
Number of Peer
Figure 8. The throughputs produced by the
different numbers of worker peer
The method is testing by counting the throughputs
(or the results) computed by different numbers of
worker peer. To test the system, the master application
does not divide the scene. But the application submits
the whole scene with 2 different sizes of the scene to
the different numbers of queried worker peer.
Additionally, the worker peer can compute only one
job for a time. So the master application must be idle
(wait to submit a new job) until there is a freely worker
peer (no computing job). For each testing, we records
the number of throughputs produced within 10
minutes.
In Figure 8, we present the number of throughputs
increase when we increase the number of worker peer.
We can conclude that this application is suitable for
solving the high throughput computing problem [12].
Therefore, from the evaluation, we find that the
rendering application is not suitable for running as a
parallel computing application on the framework. Due
to the limitation of software code for dividing the
scene of picture into many blocks, so the speedup is
not increased as well. However, the application can
produce more throughputs when the number of the
utility services is increased. Hence, an application for
running on the framework should be implemented for
solving a high throughput computing problem.
5. Conclusion
The GUSTOFarm framework can be used to build
a cluster of peers providing a set of utility service.
Hence, an application can be implemented by calling
the distributed utility services that provide the required
functions. Moreover, the framework also provides the
essential services that a utility computing system
requires. The services are used for security control,
resource discovery, monitor, and job submission. The
application programming interface is also provided for
connecting to those services.
In the future work, we expect to finish the
implementation of the job execution service, workload
distribution service, and file management service.
Furthermore, we need to improve the authentication
and authorization service to support the authentication
of the X.509 digital certificate, and also integrate the
authorization mechanism by using Java Authentication
and Authorization Service (JAAS). Additionally, we
need to implement the framework to interoperate with
the legacy resource sharing infrastructure (e.g., the
8 10
infrastructure managed by the Globus Toolkit [14]).
6. References
[1] J. W. Rose and G. Westerman , “Preparing for utility
computing: The role of IT management and relation
management”, IBM Systems Journal, Vol.43, No.1, pp.5-19,
2004
[2] T. Eilam, “Using utility computing framework to develop
utility systems”, IBM Systems Journal, Vol.43, No.1, pp.97-
120, 2004
[3] Ken Lynch, “Utility computing (Pay as you go)”,
www.cimslab.com/Resources/Utility_Computing.pdf
 [4] “Self-managing networks: building the infrastructure for
utility computing”, An AT&T survey and white paper in
cooperation with The Economist Intelligence Unit, 2004
[5] Raytracer source codes: software for rendering
“http://groups.csail.mit.edu/graphics/classes/6.837/F01/Proje
ct05/project5.html”, Computer Graphics Group, MIT
[6] I. Foster, C. Kesselman, S. Tuecke “The Anatomy of the
Grid: Enabling Scalable Virtual Organizations”, International
J. Supercomputer Applications, 2001
[7] I. Foster, C. Kesselman, J. Nick, S. Tuecke “The
Physiology of the Grid: An Open Grid Services Architecture
for Distributed Systems Integration”, Open Grid Service
Infrastructure WG, Global Grid Forum, 2002
[8] L. Gong, “JXTA: A Network Programming
Environment”, IEEE Internet Computing, v. 5. pp. 88-95,
2001
[9] Schollmeier, R, “A definition of peer-to-peer networking
for the classification of peer-to-peer architectures and
applications”, Peer-to-Peer Computing, 2001. Proceedings.
First International Conference, 2001
[10] The website of Apache Axis – An implementation of
the SOAP, “http://ws.apache.org/axis”,
[11] M. S. Palloa, “Service Oriented Architecture: A
Primer”, EAI Journal, pp. 32-35, 2001
[12] M. Livny, J. Basney, R. Raman, and T. Tannenbaum,
“Mechanisms for High Throughput Computing”, SPEEDUP
Journal, Vol.11, No.1, 1997
[13] M. Ripeanu, “Peer-to-peer architecture case study:
Gnutella network”, 2001. Proceedings. First International
Conference, 2001
[14] I. Foster and C. Kesselman, “Globus: A Metacomputing
Infrastructure Toolkit”, International Journal Super
Computer Applications, 1997