Comments from the JSR review resulted in the following update to the original JSR.

2.1 Please describe the proposed Specification:

Communication with remote objects may have varying requirements; it
may need to use custom invocation behavior such as passing additional
information in a remote method call, or use a different transport or
protocol. Additionally, an application may need to control (at the
server) the manner in which a remote call is invoked on (or dispatched
to) the target remote object.

To support differing invocation and communication requirements, the
proposal is to add a general framework for exporting remote objects with
custom remote invocation handlers and remote method dispatchers
(collectively called "custom remote reference types") in RMI. In RMI,
remote reference types control communication between clients and the
remote objects. There are several remote reference types that exist
in RMI today: a simple "unicast" reference type, a reference type that
makes use of custom socket factories, and a reference type for an
"activatable" remote object. Currently, these reference types are
specified implicitly by exporting an object via APIs such as
java.rmi.server.UnicastRemoteObject and
java.rmi.activation.Activatable. New reference types
cannot currently be defined by an application. The proposed specification
will allow new remote reference types to be defined and used by RMI
applications.

The proposed API is specifically targeted toward exposing the RMI/JRMP
architectural layers for customized Java-to-Java communication. However,
consideration will be given to adaption of parts of the API for use with
RMI/IIOP, where it is possible to do so without compromising functionality
or adding undue complexity.

Projected Expert Group will include experts in distributed object systems and RMI.

Section 2: Request

2.1 Please describe the proposed Specification:

Communication with remote objects may have varying requirements; it
may need to use custom invocation behavior such as passing additional
information in a remote method call, or use a different transport or
protocol. Additionally, an application may need to control (at the
server) the manner in which a remote call is invoked on (or dispatched
to) the target remote object.

To support differing invocation and communication requirements, the
proposal is to add a general framework for exporting remote objects with
custom remote invocation handlers and remote method dispatchers
(collectively called "custom remote reference types") in RMI. In RMI,
remote reference types control communication between clients and the
remote objects. There are several remote reference types that exist
in RMI today: a simple "unicast" reference type, a reference type that
makes use of custom socket factories, and a reference type for an
"activatable" remote object. Currently, these reference types are
specified implicitly by exporting an object via APIs such as
java.rmi.server.UnicastRemoteObject and
java.rmi.activation.Activatable. New reference types
cannot currently be defined by an application. The proposed specification
will allow new remote reference types to be defined and used by RMI
applications.

2.3 What need of the Java community will be addressed by the proposed specification?

Custom remote reference types will provide a general and customizable
framework for remote object invocation under a unified API. The
proposed features enable secure communication, group communication,
and non-TCP based communication, and other custom remote communication
(such as passing additional parameters) to be modeled as remote method
invocations.

2.4 Why isn't this need met by existing specifications?

The current RMI specification only supports custom communication
via socket factories, but this feature is not sufficiently general to
handle non-TCP based transports and other custom invocation behavior.
The existing specification does not define any way to customize
remote invocation handling and dispatching to remote objects.

2.5 Please give a short description of the underlying technology or technologies:

The API should allow exporting objects with customized invocation
behavior and dispatch behavior. More precisely,

- When exporting a remote object, an application should be able to supply
objects to customize:

invocation behavior in the remote object's proxy, and

dispatch behavior to the remote object

- The API will provide a "request/response" abstraction over transport
types so that, when exporting objects, the application can supply its
own implementation of those abstractions for non-TCP based
communication. The RMI API will provide a TCP-based and HTTP-based
protocol implementation of these abstractions for RMI applications to use.

- The API will allow exporting a remote object specifying a customizable
set of endpoints for communication fallback (for firewall tunnelling, for
example).

- The API will support asynchronous remote method
invocation, call cancellation and timeout.

- The API will support exporting a single object on multiple transport types.

- The API will support exporting an object with a specific object ID
(including well-known object IDs) for bootstrapping purposes.

- The API will allow control over an object's participation in distributed
garbage collection.

- The API will also define a configuration utility that allows an
application to change how an object is exported without having to recode
the application.

2.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)

The APIs will be added to the java.rmi package hierarchy.

2.7 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?

No.

2.8 Are there any security issues that cannot be addressed by the current security model?

No.

2.9 Are there any internationalization or localization issues?

No.

2.10 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?

No.

2.11 Please describe the anticipated schedule for the development of this
specification.

Member Review

August-September 2000

Public Review

October-November 2000

RI and TCK Available

Q4 2001

We will include a preliminary implementation of this API
in Merlin Beta.

Section 3: Contributions

3.1 Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available.

None.

3.2 Explanation of how these items might be used as a starting point for the work.