 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 78: RMI Custom Remote References
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
This JSR has been Rejected 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
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
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 - When exporting a remote object, an application should be able to supply objects to customize:
- 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 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.
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. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
