Remote Method Invocation provides a higher level of abstraction than socket for interactions between Java objects running on different machines. It is often used in client/server designs, but could be used for other distributed designs, as well.
Instead of communicating through streams of data, as is done using sockets, RMI allows an object on one machine to invoke methods in an object running on another machine. This is a relatively recent addition to the set of packages delivered as part of the standard jdk distributions and it may not be part of the Java classes included with all browsers. Consequently, for any RMI system, it is critical that the CLASSPATH on the client machine include a version of the Java class library that includes the RMI classes.
The RMI classes are found in several packages that all begin with java.rmi. Sun's on-line rmi tutorials offer a good introduction ot the subject.
There are several key steps in doing this.
- The key issue is creating a Java interface; it defines abstractly the methods that will be invoked remotely.
- That interface is then implemented in a separate class to provide the actual methods that are invoked.
- Next a server class is written that is assumed to be instantiated and running whenever the implementation class's methods are to be invoked. This may be the implementation class, itself, or a separate server or servlet class that instantiates the implementation class.
- Within the server class, the implementation class is instantiated.
- That object is then registered with a Java-supplied server, called the RMIRegistry, that binds a host/port designation for the rmiregistry and a name by which the implementation class will be known to the client.
- Once the server side classes are complete -- including the interface, implementation and server classes -- a special Java compiler for RMI application, called rmic, is run on the implementation class to produce stub and skeleton classes.
- The stub class must be available to the client application or applet, and both the stub and skeleton classes must be available to the server or servlet class.
- The application or applet class references the implementation through a URL that includes the RMIRegistry host and port and the name the server under which server registered the implementation class.
- The object returned to the client is cast using the interface class.
- The resulting object constitutes a surrogate for the implementation class and the client class may then invoke its methods. What actually happens is that the stub and skeleton objects provide a communication link with the implementation object on the server and pass calls, parameters, and return values back and forth between client and server.
The actual implementation details can be inferred from the examples and discussions that follow.
Introduction to RMI (prepared by Debra Weiss)
Hello World from RMI
Hello World from RMI, returning Serialized Object
References
References useful for this discussion include the following::