3.1 Stubs and Skeletons

RMI uses a standard mechanism (employed in RPC systems) for communicating with remote objects: stubs and skeletons. A stub for a remote object acts as a client's local representative or proxy for the remote object. The caller invokes a method on the local stub which is reponsible for carrying out the method call on the remote object. In RMI, a stub for a remote object implements the same set of remote interfaces that a remote object implements.

When a stub's method is invoked, it does the following:

• initiates a connection with the remote VM containing the remote object.
• marshals (writes and transmits) the parameters to the remote VM
• waits for the result of the method invocation
• unmarshals (reads) the return value or exception returned
• returns the value to the caller

The stub hides the serialization of parameters and the network-level communication in order to present a simple invocation mechanism to the caller.

In the remote VM, each remote object may have a corresponding skeleton (in JDK1.2-only environments, skeletons are not required). The skeleton is responsible for dispatching the call to the actual remote object implementation. When a skeleton receives an incoming method invocation it does the following:

• unmarshals (reads) the parameters for the remote method
• invokes the method on the actual remote object implementation
• marshals (writes and transmits) the result (return value or exception) to the caller

In JDK1.2 and additional stub protocol was introduced that eliminates the need for skeletons in JDK1.2-only environments. Instead, generic code is used to carry out the duties performed by skeletons in JDK1.1. Stubs and skeletons are generated by the rmic compiler.