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.