Introduction

Topics:

Overview

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.

System Goals

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.

[TOC] [Prev] [Next]