Running a Lookup Service
A client locates a service by querying a lookup service (service locator). In order to do this, it must first locate a lookup service. Similarly, a service must register itself with a lookup service, and in order to do so it must also first locate a lookup service.
The initial task for both a client and a service is thus discovering a lookup service. Such a service (or set of services) will usually have been started by some independent mechanism. The search for a lookup service can be done either by unicast or by multicast. Unicast means that you know the address of the lookup service and can contact it directly. Multicast is used when you do not know where a lookup service is and have to broadcast a message across the network so that any lookup service can respond. In fact, the lookup service is just another Jini service, but it is one that is specialized to store services and pass them on to clients looking for them.
Sun supplies a lookup service called reggie as part of the standard Jini distribution. The specification of a lookup service is public, and in future we can expect to see other implementations of lookup services.
There may be any number of these lookup services running in a network. A LAN may run many lookup services to provide redundancy in case one of them crashes. Similarly, across the internet, people may run lookup services for a variety of reasons: a public lookup service is running on http://www.jini.canberra.edu.au to aid people trying Jini clients and services so that they don't need to also set up a lookup service. Other lookup services may act as coordination centers, such as a repository of locations for all the atomic clock servers in the world.
Anybody can start a lookup service (depending on access permissions), but it will usually be started by an administrator, or started at boot time.
Reggie requires support services: an HTTP server and an RMI daemon, rmid . These need to be already running by the time reggie is started. If there is already an HTTP server running, it can be used, or a new one can be started.
If you don't have access to an HTTP server (such as Apache), then there is a simple one supplied by Jini. This server is incomplete, and it is only good for downloading Java class files ”it cannot be used as a general-purpose Web server. The Jini HTTP server is in the tools.jar file, and it can be started with this command:
java -jar tools.jar
This Jini HTTP server runs on a default port (8080), which means that any user can start it as long as local network policies do not forbid it. It uses the current directory as the document root for locating class files. These can be controlled by parameters:
java -jar tools-jarfile [-port port-number] [-dir document-root-dir] [-trees] [-verbose]
The HTTP server is needed to deliver the stub class files (of the registrar ) to clients. These class files are stored in reggie-dl.jar , so this file must be reachable from the document root. For example, on my machine the jar file has the full path /home/jan/tmpdir/jini1_0/lib/reggie-dl.jar . I set the document root to /home/jan/ tmpdir/jini1_0/lib , so the relative URL from this server is just /reggie-dl.jar .
The other support service needed for reggie is an RMI daemon. This is rmid , and it is a part of the standard Java distribution. Vendors could implement other RMI daemons, but this is unlikely to happen. rmid must be run on the same machine as reggie . The following command is a Unix command that runs rmid as a background process:
This command also has major options:
rmid [-port num] [-log dir]
These options can specify the TCP port used (which defaults to 4160). You can also specify the location for the log files that rmid uses to store its state ”they default to being in the log subdirectory.
There is a security issue with rmid on multiuser systems such as Unix. The activation system that it supports allows anyone on the same machine to run programs using the user ID that rmid is running under. That means you should never run rmid using a sensitive user ID such as root , but instead should run it as the least privileged user, nobody .
Once the HTTP server and rmid are running, reggie can be started with a number of compulsory parameters:
java -jar lookup-server-jarfile lookup-client-codebase lookup-policy-file \ output-log-dir lookup-service-group
The parameters are as follows :
As an example, on my own machine, I start reggie like this:
java -jar /home/jan/tmpdir/jini1_0/lib/reggie.jar \ http://jannote.dstc.edu.au:8080/reggie-dl.jar \ /home/jan/tmpdir/jini1_0/example/lookup/policy.all \ /tmp/reggie_log public
After starting, reggie will promptly exit! Don't worry about this ”it is actually kept in a passive state by rmid and will be brought back into existence whenever necessary (this is done by the new Activation mechanism of RMI in JDK 1.2).
You only need to start reggie once, even if your machine is switched off or rebooted. The activation daemon rmid restarts it on an as-needed basis, since it keeps information about reggie in its log files.
rmid and JDK 1.3
rmid is responsible for starting (or restarting) services such as reggie . It will create a new JVM on demand to run the service. rmid may look after a number of services, not just reggie , and they will all be run in their own JVMs. In JDK 1.2 there was no difference in handling these different JVMs. However, in JDK 1.3, the ability to set different security policies was introduced. This topic is dealt with in detail in Chapter 12.
In JDK 1.3, starting rmid requires an extra parameter to set the sun.rmi.activation.execPolicy policy. It is simplest to set it so that rmid behaves the same way as it did in JDK 1.2. This can be done with the following command:
This setting ignores the new security mechanism, and it is not recommended as a long- term or production solution.