Creating an Activatable Object


This page shows you the steps for creating an activatable object, by extending java.rmi.activation.Activatable. If you are interested in finding out about Making a UnicastRemoteObject Activatable or Activating an object that does not extend java.rmi.activation.Activatable, these are also available as tutorials.

Prior to the release of the JDK1.2, an instance of a UnicastRemoteObject could be accessed from a server program that (1) created an instance of the remote object, and (2) ran all the time. Now with the introduction of the class java.rmi.activation.Activatable and the RMI daemon, rmid, programs can be written to register information about remote object implementations that should be created and execute "on demand", rather than running all the time. The RMI daemon, rmid, provides a JVM from which other JVM instances may be spawned.

Note:  For the remainder of this tutorial, the terms "activatable object implementation", "activatable object," and "implementation" may be used interchangeably to refer to  the class, examples.activation.ActivatableImplementation, which implements a remote interface and is activatable.

This tutorial is organized as follows:

The files needed for this tutorial are: You may notice that while the client code is included, it is not discussed in a step-by-step manner, like the implementation and setup classes. The reason for this omission, is that the client code for activatable objects is no different than the RMI client code for accessing non-activatable remote objects.  Activation is strictly a server-side implementation decision.

For all of the source code used in the activation tutorials, you may choose from these formats:


Creating the implementation class

For this example, the implementation class will be examples.activation.ActivatableImplementation. There are four steps to create an implementation class:

  1. Make the appropriate imports in the implementation class
  2. Extend your class from java.rmi.activation.Activatable
  3. Declare a two-argument constructor in the implementation class
  4. Implement the remote interface method(s)

Creating the "setup" class

The job of the "setup" class is to create all the information necessary for the activatable class, without necessarily creating an instance of the remote object.  For this example the setup class will be examples.activation.Setup.

The setup class passes the information about the activatable class to rmid, registers a remote reference (an instance of the activatable class's stub class) and an identifier (name) with the rmiregistry, and then the setup class may exit.  There are six steps to create a setup class:

  1. Make the appropriate imports
  2. Install a SecurityManager
  3. Create an ActivationDesc instance
  4. Declare an instance of your remote interface and register with rmid
  5. Bind the stub to a name in the rmiregistry
  6. Quit the setup application
  7. Step 1:
    Make the appropriate imports in the setup class


Compile and run the code

There are six steps to compile and run the code:

  1. Compile the remote interface, implementation, client  and setup classes
  2. Run rmic on the implementation class
  3. Start the rmiregistry
  4. Start the activation daemon, rmid
  5. Run the setup program
  6. Run the client
  7. Step 1:
    Compile the remote interface, implementation, client and setup classes

    % javac -d . MyRemoteInterface.java
    % javac -d . ActivatableImplementation.java
    % javac -d . Client.java
    % javac -d . Setup.java

    Step 2:
    Run rmic on the implementation class

    % rmic -d . examples.activation.ActivatableImplementation

    Step 3:
    Start the rmiregistry

    In order to run this code on your system, you'll need to change the location of the policy file to be the location of the directory on your system, where you've installed the example source code.

    % rmiregistry -J-Djava.security.policy=/home/rmi_tutorial/activation/policy &

    Note: In this example, for simplicity,  we will use a policy file that gives global permission to anyone from anywhere. Do not use this policy file in a production environment. For more information on how to properly open up permissions using a java.security.policy file, please refer to to the following documents:
     

      http://java.sun.com/products/jdk/1.2/docs/guide/security/PolicyFiles.html
      http://java.sun.com/products/jdk/1.2/docs/guide/security/permissions.html
     
    Note:  Before you start the rmiregistry, you must make sure that the shell or window in which you will run the registry, either has no CLASSPATH set or has a CLASSPATH that does not include the path to any classes that you want downloaded to your client, including the stubs for your remote object implementation classes.

    If you start the rmiregistry, and it can find your stub classes in its CLASSPATH, it will ignore the server's java.rmi.server.codebase property, and as a result, your client(s) will not be able to download the stub code for your remote object.

    Run the setup, setting the codebase property to be the location of the implementation stubs. There are four things that need to go on the same command line:
     
    1. The "java" command
    2. A property name=value pair that specifies the location of the security policy file
    3. A property to specify where the stub code lives (no spaces from the "-D" all the way though the last "/")
    4. The fully-qualified package name of the setup program.

    5.  
    There should be one space just after the word "java", one between the two properties, and a third one just before the word "examples" (which is very hard to see when you view this as text, in a browser, or on paper).

    % java -Djava.security.policy=/home/rmi_tutorial/activation/policy -Djava.rmi.server.codebase=file:/home/rmi-tutorial/activation/ examples.activation.Setup

    The codebase property will be resolved to a URL, so it must have the form of "http://aHost/somesource/" or "file:/myDirectory/location/" or, due to the requirements of some operating systems, "file:///myDirectory/location/" (three slashes after the "file:").
     
    Please note that each of these sample URL strings has a trailing "/". The trailing slash is a requirement for the URL set by the java.rmi.server.codebase property, so the implementation can resolve (find) your class definition(s) properly.
     
    If you forget the trailing slash on the property, or if the class files can't be located at the source (they aren't really being made available for download) or if you misspell the property name, you'll get thrown a java.lang.ClassNotFoundException. This exception will be thrown when you try to bind your remote object to the rmiregistry, or when the first client attempts to access that object's stub. If the latter case occurs, you have another problem as well because the rmiregistry was finding the stubs in its CLASSPATH.

    The server output should look like this:
     

     Step 6:
    Run the client

    The argument to the examples.activation.Client program is the hostname of the implementation server, in this case, "vector".

    % java examples.activation.Client vector

    The client output should look like this:
     

     

Copyright © 1998 Sun Microsystems, Inc. All Rights Reserved.