Screen Saver Science: Realizing Distributed Parallel…

     Screen Saver Science: Realizing Distributed
    Parallel Computing with Jini and JavaSpaces                                      

                 William L. George and Jacob Scott
           National Institute of Standards and Technology
                Information Technology Laboratory
          Mathematical and Computational Sciences Division
                                September 4, 2002



1     Introduction
Screen Saver Sciencetm (SSS) is a distributed computing environment in which
useful computations are performed on a set of participating computers whenever
their screen savers are activated [4]. In contrast to other distributed computing
projects, such as SETI@Home (http://setiathome.ssl.berkeley.edu), the com-
pute servers of this system, that is, the part that runs within the screen saver,
will not consist of a dedicated scientific application. The SSS server will have
no particular calculation embedded in it at all, but instead will be capable of
performing any computation, subject to local resource constraints such as the
amount of memory available. This is made possible through the use of appli-
cations compiled to portable Java bytecode along with the Jini and JavaSpaces
technologies that have been enabled by the Java environment. Another funda-
mental difference between SSS and other distributed computing projects is that
SSS servers can communicate with each other during the computation in order
to coordinate the computation, rather that simply exchanging data and results
with a central job manager, thus presenting a distributed parallel computing
model to the SSS application programmer. Also, a calculation running in an
SSS server can submit one or more new calculations back into the SSS system.
    This project will explore the issues involved in building a production quality
SSS computing environment for routine use by computational scientists. Parallel
algorithms suitable for this environment will also be developed and tested. We
expect to show that this is possible with a minimum of extra software needed
above the basic Java/Jini/JavaSpaces software that is currently available. We
intend to develop a small set of Java packages to be used to develop applications
    To be presented at the 2002 Parallel Architectures and Compilation Techniques Confer-

ence.




                                           1
for submission to our SSS system, mostly for handling file I/O and interprocess
communication [7].


2    Background: Java/Jini/JavaSpaces
Java has a number of qualities that promote it as a suitable language in which to
write distributed applications. The portability of Java bytecode greatly simpli-
fies code development for heterogeneous environments. Java's garbage collection
system removes the need for explicit memory allocation and deallocation. And
with its many high level packages, including RMI, Jini, and JavaSpaces, Java
gives the distributed application programmer a major head start over other
languages.
     In the SSS environment we expect most tasks to consist primarily of scien-
tific numerical codes, an application area that Java was not originally designed
for. However, the performance of Java on numerical computations has been
continuously improving as the result of more aggressive optimizations in the
Java Virtual Machines (JVM) as well as language improvements targeted at
numerical computations. Such improvements in Java have been the focus of the
JavaNumerics group (http://math.nist.gov/javanumerics/) of the JavaGrande
Forum (http://www.javagrande.org/).
     Jini is a network technology extension to the Java programming language.
Jini provides for the automatic discovery of services on the network using a
set of simple lookup and discovery protocols. These protocols are designed to
enable the building of scalable and robust networked systems. Jini leverages the
dynamic remote class loading ability of Java to deliver services, or proxies for
these services, to clients.
     One of the fundamentals of Jini is the Lookup service, which is at the core
of how clients and services interact. The Lookup services act as dynamic yellow
pages. Services register a proxy object with the Lookup services, as well a
set of attributes that gives more detail about the services. Proxies can be self
contained or communicate with a remote service using any wire protocol it
requires. These service objects support well known interfaces, so a client finds
a particular service that it needs by sending a template to the Lookup service,
specifying in the template which classes, interfaces, or attributes the required
service must match.
     A JavaSpace is a Jini service that provides a persistent shared memory for
other processes and Jini services on the network. This service was modeled
after the tuple-space programming paradigm developed by Gelernter [2, 3]. A
JavaSpace will register with Lookup services, just like any other Jini service,
so that processes may find it. Items in a JavaSpace are Java objects (in seri-
alized form) that can be found via an associative lookup similar to that used
by the Lookup service. The basic API provided by JavaSpaces consists of three
methods: read, write, and take (a destructive read). These methods, in combi-
nation with the Jini facilities for leases, transactions, and remote events, provide
a simple yet powerful distributed programming environment.


                                         2
    The combination of portable Java byte code with the coordination software
of Jini and JavaSpaces provide all of the infrastructure needed for construct-
ing a basic compute server environment. A compute server is a process that is
capable of accepting a unit of work called a task, and returning results upon
completion. A compute server runs an infinite loop that: gets a task, performs
the computation in the task, and returns the result. Other processes are re-
sponsible for providing the tasks and for collecting the results. For example,
a compute server environment using Jini and JavaSpaces would consist of four
main components:

 1) Tasks: Tasks are Java objects that contain the basic unit of computation.
     They have an execute() method that returns a Result object. The code
     in the execute() method can be different for each Task. Tasks are stored
     in one or more JavaSpaces until taken by a compute server. A Task can
     also act as compute client in the system by submitting Tasks from within
     its execute() method.


 2) Results: Result objects hold the output of a Task. Results are stored into
      a JavaSpace by the compute server.


 3) Compute Server: Compute servers are processes that monitor one or more
     JavaSpaces for Tasks to run. They repeatedly take a Task object from
     the space, run its execute() method, and write the Result to the space.


 4) Compute Client: Compute clients generate the Tasks and write them into
     a JavaSpace. These clients, or other processes, gather the Result objects
     and combine them, if needed, to form the final output of the distributed
     computation.

   Using JavaSpaces, each iteration of the compute server loop is wrapped in
a Jini transaction so that if a failure occurs, at any time, the current task is
automatically returned to the JavaSpace as if it was never taken.
   Most texts on JavaSpaces contain a description of a similar master-worker
system since this is one natural use of JavaSpace technology [1, 5, 6].


3    Unresolved issues
Remote access to files is crucial to the operation of SSS. It is expected that the
tasks in SSS will require the reading and writing of large files containing data
arrays and that these files will not be stored on the files systems of the SSS
servers. We are currently developing software to handle this requirement.
    The biggest unresolved issue for SSS is network security, including mu-
tual authentication, authorization, and communications integrity for both SSS
clients and servers. The latest release of the Jini protocols (version 1.2), as well

                                         3
as all previous releases, provide no security beyond what is provided by the
JVM in which it runs. Fortunately, the next major release of Jini is focused on
adding a security framework to Jini. We expect security issues to be sufficiently
addressed by the time we attempt to deploy the initial SSS system.


4    Current State of SSS
The SSS system is being developed using Java 1.4 and Jini 1.2. The SSS com-
pute server is currently capable of running any task that does not require remote
file I/O. The server runs as a stand-alone Java process and has not yet been
integrated into a screen saver, although it does act like a screen saver in that
it runs a separate thread that displays a simple animation on the local display.
To keep track of the tasks in the system, each task submitted includes unique
identifying information such as the PI (primary investigator), the project name,
computation name within that project, and task number within that compu-
tation. Each SSS Server can request that preference be given to tasks from
a particular PI and/or project. Basic statistics are maintained for each SSS
Server, each project, and each computation, such as the number of tasks sub-
mitted and completed and the total CPU time used. All of this information is
kept in the SSS JavaSpace for access by any interested process.
     An important piece of SSS, remote file I/0, is being tested externally and will
be integrated into SSS as it becomes functional. Our SSS file I/O package is de-
signed as a Jini service (modeled after Sun's experimental ByteStore service, but
using RMI), and currently has basic functionality. Clients can read and write re-
mote files, and can also create and destroy remote files. This service is built using
Keith Edwards' Service Writer's Toolkit (http://www.kedwards.com/jini/swt.html)
which provides management for persistence, administration, and leasing. Cor-
rectness testing and performance tuning are not yet complete.
     Our initial major SSS application will be a Monte Carlo computation in ab
initio quantum chemistry. This application was chosen for its highly parallel
structure and the ability to easily adjust the size of the individual tasks. The
original Fortran version of this application is currently being translated into
Java.


References
[1] Eric Freeman, Susanne Hupfer, and Ken Arnold. JavaSpaces Principles,
    Patterns, and Practice. Addison-Wesley, 1999.
[2] David Gelernter. Linda in context. Comm. of ACM, 32(4):444­458, 1984.
[3] David Gelernter. Generative communication in Linda. ACM Trans. Prog.
    Lang. and Sys., 7(1):80­112, 1985.
[4] William L. George. Screen Saver Sciencetm . NIST. http://math.nist.
    gov/mcsd/savg/parallel/screen Accessed 9 Aug. 2002.

                                        4
[5] Steven L. Halter. JavaSpaces Example by Example. Java Series. Prentice
    Hall, 2002.
[6] Sing Li. Profession Jini. Wrox Press, Chicago, Il, August 2000.
[7] James S. Sims et al. Accelerating scientific discovery through compu-
    tation and visualization II. Journal of Research of the National Insti-
    tute of Standards and Technology, 107(3):223­245, 2002. May-June issue.
    http://nvl.nist.gov/pub/nistpubs/jres/107/3/cnt107-3.htm.




                                      5