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.