The Artima Developer Community
Sponsored Link

Object Mobility in the Jini Environment
Simplify the Installation and Configuration of Jini Applications
by Frank Sommers
First Published in JavaWorld, January 2001

<<  Page 7 of 9  >>


Deploying a Jini Service

To make this discussion concrete, imagine a situation in which you just created what you think is an extremely useful Jini service. Since you just created the service, no one else has any code available to run it. In fact, at this point, no one even knows your service exists. Your goal is to make this service as widely available as possible to other Jini services or to human users.

Your first step is to start up your service. Alternatively, you can make the service available as an activatable RMI implementation (see the Java Remote Method Invocation Specification, Section 7). If your service is written in Java (it does not have to be), the classfiles needed to run the application must be available to the local VM. There is nothing special here, since this is true of any Java program: the VM will start executing a main() method somewhere, and will load and link classes as it needs them via its class loaders. The best way to make these classes available is to include them in a jar file, and then ensure that this jar file is available to a class loader on the local VM. In other words, it has to be in the classpath for the local VM. (A convenient way is to set this jar file up as an executable jar.) No object mobility is involved at this point.

Next, you need to ensure that clients can obtain the necessary code to interact with your service. If you implemented your service using RMI, then the proxy object representing your service in the lookup service will likely be the RMI stub. Recall that when a stub is serialized via the RMI runtime, the codebase from which its classes can be downloaded is annotated in the object stream. As I discussed earlier, this codebase is obtained by the RMI system from the running VM's java.rmi.server.codebase property.

There are three steps necessary to make classfiles available to clients:

  1. Consider the classes the client needs to interact with your service, and create a separate jar file from these classes. By convention, this jar file is named servicename-dl.jar, where dl stands for downloadable (substitute the name of your own service for servicename). Every Jini service in the JSK is organized in this way. For instance, the lookup service implementation in the JSK consists of two files: reggie.jar and reggie-dl.jar. Any class that the client might need to load but does not have (because it is not part of the JDK version you're using) must be in the dl file, including any exception classes specified by your service object. You can put any net.jini classes the proxy depends on in the dl file as well.
  2. Make available some mechanism for clients to download the dl file. The easiest way is to run an HTTP server and place the dl jar file in a directory served by that server. Alternatively, you can put the dl file on an FTP server, or a shared filesystem. However, HTTP is by far the easiest way to make code downloading work. Using file URLs is usually a very bad idea, because the file systems they refer to will not likely be available to Jini clients. The JSK includes a simple HTTP server suitable for this purpose. You can run this server with the command:

    java -jar MY_JINI_DIRECTORY/lib/tools.jar -port PORT_NUMBER -dir SERVER_ROOT_DIR

    An additional -verbose parameter will also print out each download request.

  3. When starting up the service, specify the URL to the dl file as the java.rmi.server.codebase property. Thus, to start up your service, you might use a command line like this:

    java -cp LOCALLY_NEEDED_CLASSES/myservice.jar \
      -Djava.rmi.server.codebase=http://myhttpserver:8080/myservice-dl.jar \ \
      ... [OTHER PARAMETERS] ...

    For an activatable service, the codebase information needs to be available to the VM for the activation group that runs the service (see "Activatable Jini Services").

You are ready to register your service with lookup services:

  1. Create a ServiceItem object to represent the service in the lookup service. Your service objects, along with Entry objects in the service's attribute set, will be annotated with the codebase value specified to the VM (see above). Thus, when clients obtain the service item, they will be able to download the needed code from that location.
  2. Discover a lookup service and obtain its ServiceRegistrar object.
  3. Pass the service item to the registrar's register(ServiceItem serviceItem, long leaseDuration) method, thereby obtaining the ServiceRegistration object corresponding to this registration. You can use the registration object to renew your service's leases, and in general to maintain the relationship between your service and the lookup service.

Note that your service needs to load classes to interact with the lookup service. Now your service becomes a client of the lookup service and needs to download the necessary classes from the lookup service so it can instantiate the lookup service's proxy. Your service will download the reggie-dl.jar file from the lookup service's codebase. To be able to load and link these classes, your service needs to grant the required permissions to its VM. It is beyond the scope of this article to discuss how to configure security policy files to allow this. The JSK contains several example policy files in the /example directory.

To summarize, your service uses the following jar files:

  1. myservice.jar (its own classfiles), in addition to any other package it might use. These need to be in the classpath of the service's local VM.
  2. jini-core.jar and possibly jini-ext.jar to interact with the Jini environment (perform discovery, use leasing, participate in transactions, and so on.) Alternatively you could place the necessary classes in myservice.jar.
  3. myservice-dl.jar, which consists of files the client will need to interact with the service. This jar file will be downloaded from a codebase specified by your service. This codebase must be specified with the java.rmi.server.codebase property to the service's VM.

<<  Page 7 of 9  >>

Sponsored Links

Copyright © 1996-2017 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us