Sponsored Link •
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
There are three steps necessary to make classfiles available to clients:
dlstands 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-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
dlfile, including any exception classes specified by your service object. You can put any net.jini classes the proxy depends on in the
dlfile as well.
dlfile. The easiest way is to run an HTTP server and place the
dljar file in a directory served by that server. Alternatively, you can put the
dlfile 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
-verbose parameter will also print out each download request.
dlfile as the
java.rmi.server.codebaseproperty. Thus, to start up your service, you might use a command line like this:
java -cp LOCALLY_NEEDED_CLASSES/myservice.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:
ServiceItemobject to represent the service in the lookup service. Your service objects, along with
Entryobjects in the service's attribute set, will be annotated with the
codebasevalue 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.
register(ServiceItem serviceItem, long leaseDuration)method, thereby obtaining the
ServiceRegistrationobject 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
To summarize, your service uses the following jar files:
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.
jini-ext.jarto interact with the Jini environment (perform discovery, use leasing, participate in transactions, and so on.) Alternatively you could place the necessary classes in
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.codebaseproperty to the service's VM.