4005-730 Distributed Systems
Grid Computing System Version 2

Overview
The Grid Computing System
Software Requirements
Example Command Lines

Write a Java program for a simulated grid computing system. The program will include distributed objects for the various entities in the grid computing system, as well as a user client. The distributed objects will reside in multiple processes running on different host computers, and communicating with each other using Java remote method invocation (RMI).

Like Version 1, Version 2 assumes there is only one client running at a time and that processes never fail.

Version 2 adds the following features to Version 1:

• Each computation session has a name, and the compute server objects keep track of the session name.
   
• The compute server objects can generate remote events telling the session name the compute server is involved in and the compute server's reservation status.
   
• A system monitor process displays all the compute server objects, their session names, and their reservation status. By receiving remote events, the system monitor process dynamically updates its display as compute server objects bind into the Registry Server and as compute server objects participate in computation sessions.

The Grid Computing System (GCS) is the same as Version 1.

Function Interface
 
1. The requirements for the Function interface in Version 2 are the same as Version 1.
    
   Compute Server Object
    
2. The requirements for the compute server object in Version 2 are the same as Version 1.
    
   Client Program
    
3. The requirements for the compute client main program in Version 2 are the same as Version 1.
    
   System Monitor Program
    
4. The Grid Computing System must have a system monitor program to display the reservation states of all the compute servers in one place.
    
   Note: The system monitor's state display is in addition to the individual compute server objects' state displays.
    
5. The system monitor program must be run by typing this command line:
    
   java Monitor <host> <port>
    
   where <host> is the name of the host computer where the Registry Server is running, and <port> is the port number to which the Registry Server is listening; none of the arguments may be omitted.
    
   Note: This means that the system monitor program's class must be named Monitor, and this class must not be in a package.
    
6. The system monitor program must print an error message and terminate if there are any of the following problems with the command line arguments. The error message must include a meaningful explanation of the problem. The error message may include an exception stack trace.
   • Any required argument is missing.
   • An integer-valued argument cannot be parsed as an integer.
   • The Registry Server cannot be located.
      
7. The system monitor program must display the reservation states of all the compute servers at all times; specifically: Whenever one of the compute servers prints a line on the compute server's console saying that the compute server is available or reserved, the system monitor program must print the following lines on the system monitor program's console:
    
   ******** <datetime> ********
   Compute Server <name> -- reserved -- session: <sessname>
   Compute Server <name> -- available
   . . .
    
   where <datetime> is replaced with the date and time; each <name> is replaced with the name of the corresponding compute server; if the compute server is reserved, the words reserved -- session: <sessname> are printed, replacing <sessname> with the session name; if the compute server is available, the word available is printed.
    
   Note: Each time the system monitor program does the above printout, all the compute servers must be included in the printout, even compute servers whose state has not changed.
    
8. In the above printout, the compute servers must be listed in alphabetical order of their names.
    
9. The system monitor program must automatically detect all the compute server objects, including compute server objects that started before the system monitor program started and compute server objects that started after the system monitor program started.
    
10. The system monitor program must detect newly-started compute server objects via remote events.
     
11. The system monitor program must detect state changes in the compute server objects via remote events.
     
12. The system monitor's display must eventually become correct even if remote event notifications are lost. If a remote event notification is lost, the system monitor's display is permitted to be incorrect for at most 20 seconds.
     
13. If an exception occurs and the above requirements do not state how to handle the exception, the system monitor program must print an exception stack trace and must exit.

• Java class path: /home/fac/wrc/www/common/ds/gcs/gcs02/
   
• Interface Function -- (Function.java)
• Interface ComputeServerRef -- (ComputeServerRef.java)
• Class ComputeServer -- (ComputeServer.java)
• Class ComputeServerEvent -- (ComputeServerEvent.java)
• Enumeration ComputeServerState -- (ComputeServerState.java)
• Interface ComputeServerEventListener -- (ComputeServerEventListener.java)
• Class Monitor -- (Monitor.java)

• Java class path: /home/fac/wrc/www/common/ds/gcs/gcs02/client/
   
• Class ComputeClient -- (ComputeClient.java)
• Class SqrFunction -- (SqrFunction.java)
• Class LogFunction -- (LogFunction.java)
• Class SineFunction -- (SineFunction.java)

To perform the example calculation session depicted in the above timeline under "The Grid Computing System," run the following commands, each in a separate process on the same machine.

1. Run the Registry Server (script: runregistry).

   $ runregistry

   #!/bin/bash java \ -classpath /home/fac/ark/public_html/cscl/lib \ Start edu.rit.ds.registry.RegistryServer

2. Run the Grid Computing System monitor program (script: runmonitor). This can be done before or after starting the compute server objects.

   $ runmonitor

   #!/bin/bash java \ -classpath /home/fac/wrc/www/common/ds/gcs/gcs02:/home/fac/ark/public_html/cscl/lib \ Monitor localhost 9901

3. Set up a security policy for the Compute Server (policy file: policy).

   grant codebase "file:/home/fac/wrc/www/common/ds/gcs/gcs02/" { permission java.security.AllPermission; }; grant codebase "file:/home/fac/ark/public_html/cscl/lib/" { permission java.security.AllPermission; };

4. Run several instances of the Compute Server, specifying the security policy (script: runcomputeserver).

   $ runcomputeserver A
   $ runcomputeserver B
   $ runcomputeserver C

   #!/bin/bash java \ -classpath /home/fac/wrc/www/common/ds/gcs/gcs02:/home/fac/ark/public_html/cscl/lib \ -Djava.security.policy=policy \ Start ComputeServer localhost 9901 $1

5. Set up a security policy for the Compute Client (policy file: client/policy).

   grant codebase "file:/home/fac/wrc/www/common/ds/gcs/gcs02/client/" { permission java.security.AllPermission; }; grant codebase "file:/home/fac/ark/public_html/cscl/lib/" { permission java.security.AllPermission; };

6. Set up a web server so that class files in the client's class path can be downloaded from a URL. This is called the codebase URL.
    
7. Run the Compute Client, specifying the security policy and the client's codebase URL (script: client/runclient). Specify session name, function class names, and compute server names on the command line. Type arguments upon which to calculate the function. Hit CTRL-D (end-of-file) when done.

   $ runclient ARK SqrFunction A LogFunction B SineFunction C
   0.5
   1.0
   CTRL-D

   #!/bin/bash java \ -classpath /home/fac/wrc/www/common/ds/gcs/gcs02/client:/home/fac/ark/public_html/730/gcs02:/home/fac/ark/public_html/cscl/lib \ -Djava.security.policy=policy \ -Djava.rmi.server.codebase=http://www.cs.rit.edu/~ark/winter2008/730/gcs02/client/ \ ComputeClient localhost 9901 $*

Compute Server A prints the following on the console (the floating point numbers may print with additional digits of precision):

Compute Server A -- available
Compute Server A -- reserved -- session: ARK
Compute Server A -- function: sqr
Compute Server A -- successor: B
Compute Server A -- f(0.5)
Compute Server A -- sqr(-0.735) = 0.540
Compute Server A -- f(1.0)
Compute Server A -- sqr(-0.173) = 0.030
Compute Server A -- available

Compute Server B prints the following on the console (the floating point numbers may print with additional digits of precision):

Compute Server B -- available
Compute Server B -- reserved -- session: ARK
Compute Server B -- function: log
Compute Server B -- successor: C
Compute Server B -- f(0.5)
Compute Server B -- log(0.479) = -0.735
Compute Server B -- f(1.0)
Compute Server B -- log(0.841) = -0.173
Compute Server B -- available

Compute Server C prints the following on the console (the floating point numbers may print with additional digits of precision):

Compute Server C -- available
Compute Server C -- reserved -- session: ARK
Compute Server C -- function: sin
Compute Server C -- f(0.5)
Compute Server C -- sin (0.5) = 0.479
Compute Server C -- f(1.0)
Compute Server C -- sin (1.0) = 0.841
Compute Server C -- available

The compute client program prints the following on the console (the floating point numbers may print with additional digits of precision):

f(0.5) = 0.540
f(1.0) = 0.030

[an error occurred while processing this directive]

Alan Kaminsky • Department of Computer Science • Rochester Institute of Technology • 4486 + 2220 = 6706

Home Page

Copyright © 2007 Alan Kaminsky. All rights reserved. Last updated 09-Dec-2007. Please send comments to ark­@­cs.rit.edu.
Adaptations last updated 2011/01/03 by Warren R. Carithers.