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
responsible 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 JVM containing the remote object,
- marshals (writes and transmits) the
parameters to the remote JVM,
- waits for the result of the method
invocation,
- unmarshals (reads) the return value
or exception returned, and
- 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 JVM, each remote
object may have a corresponding skeleton (in Java 2 platform-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, and
- marshals (writes and transmits) the
result (return value or exception) to the caller.
In the Java 2 SDK, Standard Edition,
v1.2 an additional stub protocol was introduced that eliminates the
need for skeletons in Java 2 platform-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.
CONTENTS | PREV | NEXT
Copyright 1997, 2010, Oracle and/or its affiliates. All rights
reserved.