CS 141a - Winter 2002
Jini Services

We have started a Jini lookup service, transaction service, and RMI activation daemon on virtuoso so that you can use Sun's JavaSpace implementation when implementing your distributed parallel processing system for Lab 8. Example code for looking up a JavaSpace by name in a Jini directory service can be found in the Lab4TestSetup source code from the Lab 4 test suite (specifically, the "setUp" method). Important things to keep in mind when using the Jini services:

You must set your java.security.policy property appropriately in order to use the Jini services. This property should point to a "policy file" which determines what access the objects in your VM have to system resources (files, networking). Sample policy files are available in the directory /home/cs141/resources/jini/policy; you can generally use the policy.all file, which eliminates most security restrictions on the Java VM's actions. To set this property when running Java from the command line, specify the command line option -Djava.security.policy=path/to/policy/file.
You must set your java.rmi.server.codebase property appropriately in order to use Jini services. This property should point to a directory on a web server that contains your class files, and is used by RMI to do dynamic class loading (when you send an object to a remote host, it will look in the codebase for the class if it doesn't have it locally). You can probably use the CS department web server for this purpose (specify ~username/cs141a-2002/lab8/classes or some other appropriate path as the code base); if you don't want to rely on the CS department web server, you can start your own HTTP server on a port of your choice and a machine of your choice (we describe how to do this later). To set this property when running Java from the command line, specify the command line option -Djava.rmi.server.codebase=http://url/to/code/base/.
You must set a system SecurityManager in your Java program if you intend to do remote class loading. This is done in the example code, right at the beginning of the "setUp" method.

Running a JavaSpace

There are two JavaSpace implementations provided by Sun. One is transient, meaning that it will run only as long as the VM you start it in; the other is persistent, meaning that it will run essentially forever until you explicitly shut it down (and will be activatable using RMI activation). You should, in general, use transient spaces for testing.

To start a transient space, the command line is:

java -jar -Djava.security.policy=path/to/policy/file -Djava.rmi.server.codebase=http://virtuoso.cs.caltech.edu:9090/outrigger-dl.jar -Dcom.sun.jini.outrigger.spaceName=YourSpaceName /home/cs141/resources/jini/lib/transient-outrigger.jar public

To start a persistent space, the command line is:

java -jar -Djava.security.policy=path/to/policy/file -Dcom.sun.jini.outrigger.spaceName=YourSpaceName /home/cs141/resources/jini/lib/outrigger.jar http://virtuoso.cs.caltech.edu:9090/outrigger-dl.jar /path/to/policy/file /path/to/log/directory public

The "public" in these command lines is the Jini group with which the JavaSpace should register; our Jini lookup service only works with group "public". The "/path/to/log/directory" in the persistent space's command line should be a pathname in your home directory that will be used by the JavaSpace for writing log files and persistent data. If you start up a transient space, it will stay in the foreground (and you will have to background it in order to do anything else); if you start up a persistent space, it will register itself with the RMI activation daemon and then return control to you (so there is no need to background it).

A transient space should be able to run on either virtuoso or orchestra, because it doesn't depend on RMI activation; a persistent space can only run on virtuoso, because we have not started an RMI activation daemon on orchestra. Again, you should probably be using transient spaces exclusively.

Running an HTTP Server

If you want to run an HTTP server to serve your codebase (like the one we are running on port 9090 of virtuoso, which is used in the command lines above for the Jini codebase), you can do so using the following command line:

java -jar /home/cs141/resources/jini/lib/tools.jar -port PortNumber -dir path/to/classes -trees

The "path/to/classes" should be the root directory of your class hierarchy (so if you've built your classes in ~username/public_html/lab8/classes, that's what you should put there).

Other Information

If you start Java processes and then log out, please make sure to stop them when you log out (unless you actually need them to keep running). On Solaris, you can see any running virtual machines by typing "ps -f | grep java"; on Linux you can see any running virtual machines by typing "ps -a | grep java". On both platforms, you can kill all your running Java virtual machines by typing "pkill -9 java".

If you want to run Jini services on your own machine for testing purposes or any other reason, you can learn how in the Jini tutorial on starting services from the command line. If you have any questions about how to do this, let us know sooner rather than later.

Daniel M. Zimmerman (Home Page)
dmz@cs.caltech.edu
Last Revised 20 February 2002

CS 141a - Winter 2002Jini Services

Running a JavaSpace

Running an HTTP Server

Other Information

CS 141a - Winter 2002
Jini Services