Find JSRs
Submit this Search


Ad Banner
 
 
 
 

Summary  |  Proposal  |  Detail (Summary & Proposal)
JSRs: Java Specification Requests
JSR 78: RMI Custom Remote References

Stage Access Start Finish
Rejected   21 Feb, 2001  
Community Draft Reconsideration Ballot View results 13 Feb, 2001 20 Feb, 2001
Community Draft Ballot Failed   16 Jan, 2001  
Community Draft Ballot View results 09 Jan, 2001 15 Jan, 2001
Community Review Login page 12 Dec, 2000 15 Jan, 2001
JSR Review Ballot View results 15 Aug, 2000 28 Aug, 2000
Expert Group Formation   15 Aug, 2000 11 Sep, 2000
Status: Rejected
Reason: This JSR was not approved by the SE/EE Executive Committee in Draft Approval/Reconsideration Ballots.
JCP version in use: 2.1
Java Specification Participation Agreement version in use: 1.0


Description:
Provide a general framework in JavaTM 2 Standard Edition RMI for customizing remote invocation behavior.

Please direct comments on this JSR to the Spec Lead(s)
Team

Specification Leads
  Ann Wollrath Sun Microsystems, Inc.
Expert Group
  Hedman, Par Niclas IBM Lea, Doug
  Montresor, Alberto Motorola Sun Microsystems, Inc.

This JSR has been Rejected
Reason: This JSR was not approved by the SE/EE Executive Committee in Draft Approval/Reconsideration Ballots.

Update to the Specification

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.


Original Java Specification Request (JSR)

Identification | Request | Contributions | Additional Information

Section 1. Identification

Submitting Member: Sun Microsystems, Inc.

Name of Contact Person: Mark Hodapp

E-Mail Address: Mark.Hodapp@sun.com

Telephone Number: +1 781 442 2035

Fax Number: +1 781 442 1657


Specification Lead: Ann Wollrath

E-Mail Address: Ann.Wollrath@sun.com

Telephone Number: +1 781 442 0565

Fax Number: +1 781 442 1657


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.

(NOTE that this response has been updated since the original.)

2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)

Java 2 Standard Edition

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,

- Stubs for exported objects with custom invocation behavior should be represented by instances of dynamically generated proxy classes (available via the java.lang.reflect.Proxy API).

- 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 ReviewAugust-September 2000
Public ReviewOctober-November 2000
RI and TCK AvailableQ4 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.

None.