Distributed systems require that computations running in different address
spaces, potentially on different hosts, be able to communicate. For a basic
communication mechanism, the Java language supports sockets, which are
flexible and sufficient for general communication. However, sockets require the
client and server to engage in applications-level protocols to encode and
decode messages for exchange, and the design of such protocols is
cumbersome and can be error-prone.
An alternative to sockets is Remote Procedure Call (RPC), which abstracts the
communication interface to the level of a procedure call. Instead of working
directly with sockets, the programmer has the illusion of calling a local
procedure, when in fact the arguments of the call are packaged up and shipped
off to the remote target of the call. RPC systems encode arguments and return
values using an external data representation, such as XDR.
RPC, however, does not translate well into distributed object systems, where
communication between program-level objects residing in different address
spaces is needed. In order to match the semantics of object invocation,
distributed object systems require remote method invocation or RMI. In such
systems, a local surrogate (stub) object manages the invocation on a remote
object.
The Java remote method invocation system described in this specification has
been specifically designed to operate in the Java environment. While other RMI
systems can be adapted to handle Java objects, these systems fall short of
seamless integration with the Java system due to their interoperability
requirement with other languages. For example, CORBA presumes a
heterogeneous, multilanguage environment and thus must have a language-
neutral object model. In contrast, the Java language's RMI system assumes the
homogeneous environment of the Java Virtual Machine, and the system can
therefore take advantage of the Java object model whenever possible.
The goals for supporting distributed objects in the Java language are:
Support seamless remote invocation on objects in different virtual machines.
Support callbacks from servers to applets.
Integrate the distributed object model into the Java language in a natural
way while retaining most of the Java language's object semantics.
Make differences between the distributed object model and local Java object
model apparent.
Make writing reliable distributed applications as simple as possible.
Preserve the safety provided by the Java runtime environment.
Underlying all these goals is a general requirement that the RMI model be both
simple (easy to use) and natural (fits well in the language).
In addition, the RMI system should allow extensions such as garbage collection
of remote objects, server replication, and the activation of persistent objects to
service an invocation. These extensions should be transparent to the client and
add minimal implementation requirements on the part of the servers that use
them. To support these extensions, the system should also support:
Several invocation mechanisms; for example simple invocation to a single
object or invocation to an object replicated at multiple locations. The system
should also be extensible to other invocation paradigms.
Various reference semantics for remote objects; for example live
(nonpersistent) references, persistent references, and lazy activation.
The safe Java environment provided by security managers and class loaders.
Distributed garbage collection of active objects.
Capability of supporting multiple transports.
The first two chapters in this specification describe the distributed object model
for the Java language and the system architecture. The remaining chapters
describe the RMI client and server visible APIs which are part of JDK 1.1.