Prev
Home
Next
Menu

Remote Method Invocation (RMI) 

The Java Remote Method Invocation API, or Java RMI, allows an object running in one Java virtual machine to invoke methods on an object running in another Java virtual machine. RMI provides for remote communication between programs written in the Java programming language.

Two common implementations of the API exist:

  1. The original implementation depends on Java Virtual Machine (JVM) class representation mechanisms and it thus only supports making calls from one JVM to another. The protocol underlying this Java-only implementation is known as Java Remote Method Protocol (JRMP).
  2. In order to support code running in a non-JVM context, a Common Object Request Broker Architecture (CORBA) version was later developed named RMI-IIOP, whereas the term RMI-IIOP (read: RMI over IIOP) denotes the RMI interface delegating most of the functionality to the supporting CORBA implementation.

The programmers of the original RMI API generalized the code somewhat to support different implementations, such as an HTTP transport. Additionally, the ability to pass arguments “by value” was added to CORBA in order to support the RMI interface. Still, the RMI-IIOP and JRMP implementations do not have fully identical interfaces.

RMI functionality comes in the package java.rmi, while most of Sun’s implementation is located in the sun.rmi package. Note that with Java versions before Java 5.0 developers had to compile RMI stubs in a separate compilation step using rmic. Versions 5.0 of Java and beyond no longer require this step. Jini offers a more advanced version of RMI in Java – it functions similarly but provides more advanced searching capabilities and mechanisms for distributed object applications.

 

A Closer Look at JRMP and RMI-IIOP

  1. JRMP is the Java technology-specific protocol for looking up and referencing remote objects. It is a wire level protocol running at the level under Remote Method Invocation (RMI) and over TCP/IP. JRMP is a Java-specific, stream-based protocol; compare with RMI-IIOP. The RMI-IIOP which exposes Java objects to CORBA ORBs is an alternative to JRMP. In contrast to the RMI-IIOP, the JRMP is a protocol for Java-to-Java remote calls, which makes it language dependent and means that both client and server must use java objects. However, many application server vendors have developed their own protocols for use with RMI which claim to offer advantages over both IIOP and JRMP.
  2. RMI-IIOP denotes the Java remote method invocation (RMI) interface over the Internet Inter-ORB Protocol (IIOP), which delivers Common Object Request Broker Architecture (CORBA) distributed computing capabilities to the Java platform. Java RMI-IIOP was developed by Sun Microsystems and IBM, combining the best features of Java RMI technology with the best features of CORBA technology.

This standard was created to simplify the development of CORBA applications, while preserving all major benefits. RMI-IIOP is largely based on the Object by Value concept that serves as a container or direct replacement for CORBA structures, unions, sequences, arrays and strings. The Interface Definition Language (IDL) is not used. Instead, the data structure definitions “supposed” automatically, collecting the necessary data via reflection mechanisms. When CORBA needs supplementary generated classes for each non trivial data structure being transferred, RMI-IIOP only uses the generated code for remote objects. Less generated code results in the smaller footprint.

Both CORBA and RMI-IIOP use the same General Inter-ORB Protocol communication standard. If required, it is possible to generate the IDL definitions for the involved RMI-IIOP data structures and use these definitions to arrange the interoperability between the RMI-IIOP and plain CORBA applications. The recent versions of RMI-IIOP derive their servants from the standard Servant (CORBA) class. Hence it is possible to connect them to the CORBA ORB manually, involving, if necessary, the Portable Object Adapter, Portable Interceptors, CORBA naming service and all other standard CORBA features.

Whereas the Internet Inter-ORB Protocol (IIOP) is a protocol that makes it possible for distributed programs written in different programming languages to communicate over the Internet. IIOP is a critical part of a strategic industry standard, the Common Object Request Broker Architecture (CORBA). Using CORBA’s IIOP and related protocols, a company can write programs that will be able to communicate with their own or other company’s existing or future programs wherever they are located and without having to understand anything about the program other than its service and a name. CORBA and IIOP are competing with a similar strategy from Microsoft called the Distributed Component Object Model (DCOM).

CORBA and IIOP assume the client/server model of computing in which a client program always makes requests and a server program waits to receive requests from clients. When writing a program, we use an interface called the General Inter-ORB Protocol (GIOP). The GIOP is implemented in specialized mappings for one or more network transport layers. Undoubtedly, the most important specialized mapping of GIOP is IIOP, which passes requests or receives replies through the Internet’s transport layer using the Transmission Control Protocol (TCP). Other possible transport layers would include IBM’s Systems Network Architecture (SNA) and Novell’s IPX.

For a client to make a request of a program somewhere in a network, it must have an address for the program. This address is known as the Interoperable Object Reference (IOR). Using IIOP, part of the address is based on the server’s port number and IP address. In the client’s computer, a table can be created to map IORs to proxy names that are easier to use. The GIOP lets the program make a connection with an IOR and then send requests to it (and lets servers send replies). A Common Data Representation (CDR) provides a way to encode and decode data so that it can be exchanged in a standard way.

 

An Overview of RMI Applications

RMI applications often comprise two separate programs, a server and a client. A typical server program creates some remote objects, makes references to these objects accessible, and waits for clients to invoke methods on these objects. A typical client program obtains a remote reference to one or more remote objects on a server and then invokes methods on them. RMI provides the mechanism by which the server and the client communicate and pass information back and forth. Such an application is sometimes referred to as a distributed object application.

The distributed object applications need to do the following:

♦ Locate remote objects. Applications can use various mechanisms to obtain references to remote objects. For example, an application can register its remote objects with RMI’s simple naming facility, the RMI registry. Alternatively, an application can pass and return remote object references as part of other remote invocations.

♦ Communicate with remote objects. Details of communication between remote objects are handled by RMI. To the programmer, remote communication looks similar to regular Java method invocations.

♦ Load class definitions for objects that are passed around. Because RMI enables objects to be passed back and forth, it provides mechanisms for loading an object’s class definitions as well as for transmitting an object’s data.

The following figure (Figure 1) depicts an RMI distributed application that uses the RMI registry to obtain a reference to a remote object. The server calls the registry to associate (or bind) a name with a remote object. The client looks up the remote object by its name in the server’s registry and then invokes a method on it.

Figure 1: A general architecture of Java-RMI

 
Stub and Skeleton

See the following figure (Figure 2) to understand the concept of Java RMI.

Figure 2:  Stub and Skeleton

 

  • A client invokes a remote method; the call is first forwarded to stub.
  • The stub is responsible for sending the remote call over to the server-side skeleton
  • The stub opening a socket to the remote server, marshaling the object parameters and forwarding the data stream to the skeleton.
  • A skeleton contains a method that receives the remote calls, unmarshals the parameters, and invokes the actual remote object implementation.

Actually Java RMI allows programmer to execute remote method calls using the same semantics as local method calls. See Figure 3 below:

Figure 3: A remote method call using Java-RMI

 

Steps of Developing a Client/Server based RMI Application

In this topic we are going to make code implementations of the Java Remote Method Protocol (JRMP) only. The example codes are placed within rmi directory under C:\ (in MS Windows).

These steps are generally followed to develop a Client/Server based RMI application:

  1. Define the Remote interface
  2. Develop the remote object by implementing the Remote interface
  3. Develop the client program
  4. Compile the Java source files
  5. Generate the client stub and server skeleton
  6. Start the RMI registry
  7. Start the remote server objects
  8. Run the client
 
Step 1. Defining the Remote Interface

To create an RMI application, the first step is defining of a remote interface between the client and server objects.

/* SampleServer.java */

import java.rmi.*;

public interface SampleServer extends Remote {
     public int sum(int a, int b) throws RemoteException;
}
 
Step 2. Develop the remote object by implementing the Remote interface
  • The server is a simple unicast remote server.
  • Create server by extending java.rmi.server.UnicastRemoteObject.
/* SampleServerImpl.java */

import java.rmi.*;
import java.rmi.server.*;
import java.rmi.registry.*;

public class SampleServerImpl extends UnicastRemoteObject implements SampleServer 
{
    SampleServerImpl() throws RemoteException {
       super();
    }
  • The server uses the RMISecurityManager to protect its resources while engaging in remote communication.
  • The server must bind its name to the registry, the client will look up the server name.
  • Use java.rmi.Naming class to bind the server name to registry. In this example the name call “SAMPLE-SERVER”.
  • In the main method of the server object, the RMI security manager is created and installed.
/* SampleServerImpl.java (continued) */

   public static void main(String args[]) {

       try {
          //set the security manager
          System.setSecurityManager(new RMISecurityManager()); 

          //create a local instance of the object
          SampleServerImpl Server = new SampleServerImpl();

          //put the local instance in the registry
          Naming.rebind("SAMPLE-SERVER" , Server);

          System.out.println("Server waiting.....");
       }
       catch (java.net.MalformedURLException me)  {
          System.out.println("Malformed URL: " + me.toString());   
       }
       catch (RemoteException re)  {
          System.out.println("Remote exception: " + re.toString());  
       }
   }
  • Implement the remote mehtod.
/* SampleServerImpl.java (continued) */

   public int sum(int a, int b) throws RemoteException {
       return a + b;
   }

} //end of class SampleServerImpl
 
Step 3. Develop the client program
  • In order for the client object to invoke methods on the server, it must first look up the name of server in the registry. We use the java.rmi.Naming class to lookup the server name.
  • The server name is specified as URL in the from ( rmi://host:port/name )
  • Default RMI port is 1099.
  • The name specified in the URL must exactly match the name that the server has bound to the registry. In this example, the name is “SAMPLE-SERVER”
  • The remote method invocation is programmed using the remote interface name (remoteObject) as prefix and the remote method name (sum) as suffix.
/* SampleClient.java */

import java.rmi.*;
import java.rmi.server.*;

public class SampleClient  {

   public static void main(String[]  args)  {

       // set the security manager for the client
       System.setSecurityManager(new RMISecurityManager());

       //get the remote object from the registry
       try {
           System.out.println("Security Manager loaded");
           String url = "//localhost/SAMPLE-SERVER";

           SampleServer remoteObject = (SampleServer)Naming.lookup(url);
           System.out.println("Got remote object");

           System.out.println(" 1 + 2 = " + remoteObject.sum(1,2) );
       }
       catch (RemoteException exc) {
           System.out.println("Error in lookup: " + exc.toString()); 
       }
       catch (java.net.MalformedURLException exc) {
           System.out.println("Malformed URL: " + exc.toString());   
       }
       catch (java.rmi.NotBoundException exc)  {
           System.out.println("NotBound: " + exc.toString());
       }

   }

} //end of class SampleClient
 
Steps 4 & 5. Compile the Java source files & Generate the client stub and server skeleton
  • Assume the programs compile and executing under C:\rmi
  • Once the interface is completed, we need to generate stubs and skeleton code. The RMI system provides an RMI compiler (rmic) that takes our generated interface class and procedures stub code on its self.
C:\rmi>set classpath=C:\rmi

C:\rmi>javac SampleServer.java

C:\rmi>javac SampleServerImpl.java

C:\rmi>rmic SampleServerImpl

C:\rmi>javac SampleClient.java
 
6. Start the RMI registry
  • The RMI applications need install to Registry. And the Registry must start manual by call rmiregisty.
  • The rmiregistry us uses port 1099 by default. We can also bind rmiregistry to a different port by indicating the new port number as : rmiregistry
C:\rmi>rmiregistry
 
Steps 7 & 8. Start the remote Server objects & Run the client
  • Once the Registry is started, the server can be started and will be able to store itself in the Registry.
  • Because of the grained security model in Java, we must setup a security policy for RMI by set java.security.policy to the file policy.all

[At the Server end]

C:\rmi>java -Djava.security.policy=policy.all SampleServerImpl

[At the Client end]

C:\rmi>java -Djava.security.policy=policy.all SampleClient    

Tip: Use a separate instance of cmd for rmiregistry service, server program and client program.

 

Java Policy Files

The Java application must first obtain information regarding its privileges. It can obtain the security policy through a policy file. In above example, we allow Java code to have all permissions,  the contents of the policy file policy.all is:

grant {
    permission java.security.AllPermission;
};

Now, here is an example for assigning resource permissions:

grant {
    permission java.io.filePermission “/tmp/*”, “read”, “write”;
    permission java.net.SocketPermission “somehost.somedomain.com:999”,”connect”;
    permission java.net.SocketPermission “*:1024-65535”,”connect,request”;
    permission java.net.SocketPermission “*:80”,”connect”;
};
  1. allow the Java code to read/write any files only under the /tmp directory, includes any subdirectories
  2. allow all java classes to establish a network connection with the host “somehost.somedomain.com” on port 999
  3. allows classes to connection to or accept connections on unprivileged ports greater than 1024 , on any host
  4. allows all classes to connect to the HTTP port 80 on any host.
 
Output

Start the rmiregistry in one command prompt window at the server end:

 

 

 

 

 

 

Start the RMI Server in another command prompt window at the server end:

 

 

 

 

 

 

Start the RMI Client in another command prompt window at the client end:

 

 

 

 

 

 

Summary

The Java Remote Method Invocation API, or Java RMI, allows an object running in one Java virtual machine to invoke methods on an object running in another Java virtual machine. RMI provides the mechanism by which the server and the client communicate and pass information back and forth. Such an application is sometimes referred to as a distributed object application.

 

 

Prev
Home
Next