Previous | Next | Trail Map | Java Objects and the Directory | Storing Objects in the Directory

Remote Objects

The Java Remote Method Invocation (RMI) system is a mechanism that enables an object on one Java virtual machine to invoke methods on an object in another Java virtual machine. Any object whose methods can be invoked in this way must implement the java.rmi.Remote interface. When such an object is invoked, its arguments are marshalled and sent from the local virtual machine to the remote one, where the arguments are unmarshalled and used. When the method terminates, the results are marshalled from the remote machine and sent to the caller's virtual machine.

To make remote objects accessible to other virtual machines, the application that creates them must register each such object with the RMI registry. The application supplies to the RMI registry the string name of the remote object, and the remote object itself. When a program wants to access a remote object, it asks the RMI registry on the same machine as the remote object for a reference (stub) to the remote object. The remote object is named using an "rmi" URL such as "rmi://hostname:port/remoteObjectName", where hostname and port identify the machine and port on which the RMI registry is running, and remoteObjectName is the string name of the remote object. If remoteObjectName is omitted, then the object being named is the RMI registry itself. When the program receives the stub for the remote object, it can invoke methods on the remote object (through the stub).

Some service providers, such as Sun's LDAP service provider, support the binding of java.rmi.Remote objects into directories. By binding java.rmi.Remote objects or RMI registries into an enterprise-wide, shared namespace such as the LDAP, RMI clients can look up java.rmi.Remote objects without knowing which machine the objects are running on. The clients can look up the objects as if they were stored in the directory, even though the objects themselves are actually registered with their respective local RMI registries.

Binding a Remote Object


Before you go on:

The example in this lesson requires that you have started the RMI registry on your machine, and that you have installed and make available to your program an RMI Registry service provider (such as the one from Sun).


This example defines a java.rmi.Remote interface Hello with one method, sayHello().

public interface Hello extends Remote {
    public String sayHello() throws RemoteException;
}
It also defines an implementation of this interface, HeloImpl.
public class HelloImpl extends UnicastRemoteObject implements Hello {
    public HelloImpl() throws RemoteException {
    }

    public String sayHello() throws RemoteException {
        return ("Hello, the time is " + new java.util.Date());
    }
}

This example creates an instance of HelloImpl and binds it to the local RMI registry as "rmi://mymachine/hello".

// Create Remote object to be bound and give it a name
Hello h = new HelloImpl();
String rmiurl = "rmi://mymachine/hello";

// Bind to RMI registry
ctx.rebind(rmiurl, h);
It then binds the java.rmi.Remote object to the directory by specifying its RMI name--this is the "rmi" URL that any Java application will need to supply to the RMI registry to look up the object. This name is recorded in the "javaRemoteLocation" attribute, as specified in the Internet-draft draft-ryan-java-schema-01.rev.txt.
// Bind to directory
ctx.bind("cn=Hello", h, new BasicAttributes("javaRemoteLocation", rmiurl));
After the object has been bound in the directory, an application can look it up using the following code:
Hello h2 = (Hello)ctx.lookup("cn=Hello");
h2.sayHello();

To run this example, you must do the following:

  1. Compile Hello.java, HelloImpl.java and this example.
    # javac Hello.java HelloImpl RemoteObj.java
    
  2. Run rmic with HelloImpl as the argument to produce the stubs for the remote object.
    # rmic HelloImpl
    
  3. Copy HelloImpl.class and the class files generated by rmic to a directory on a Web server.
  4. Specify this directory as the codebase to the Java interpreter.
    # java -Djava.rmi.server.codebase=http://web1/example/classes/ RemoteObj
    
    RemoteObj does not terminate because it created the remote object HelloImpl that other RMI client can contact and use.
Afterwards, when you look up this object from the directory, and the directory will return the HelloImpl remote object that is bound. The RMI will automatically download the necessary class files from the codebase specified for the "java.rmi.server.codebase" property specified when it was bound if those class files are not available from the classpath. However, in JDK 1.1.x, you need to install a security manager that allows connection to the remote RMI registry and the Web server containing the code in order for this automatic downloading to work. In the Java 2 Platform, you can install your own security manager, or use the default security manager and specify a security policy.
# java -Djava.security.manager -Djava.security.policy=.policy myLookupProgram
See the Java 2 Plaform security model for details.

Storing Objects in the Directory: End of Lesson

What's next? Now you can:


Previous | Next | Trail Map | Java Objects and the Directory | Storing Objects in the Directory