RMI package implementation

Package name java.rmi

Overview

This is a clean room implementation of java.rmi following J2SE 1.5 spec.

Current Status

Currently our package contains implementation for:

java.rmi

java.rmi.dgc

java.rmi.registry

java.rmi.server

For all packages, deprecated method/classes have not been implemented.
Package java.rmi.activation has been designed and we have plans to implement it within the next months.

Note: Tools like rmic and rmiregistry have not been implemented yet.

Note: code uses J2SE 5.0 features, such as generics, so it requires 5.0 VM and libraries (i.e.: java.util.concurrent). It has been tested against Sun SDK, removing the original java.rmi.* and replacing it by ours.

Design Decisions

We have realized that the RMI architecture fits better in a framework (container) / provider model, splitting the implementation from the framework itself.

We consider to be a better approach to separate the framework from the specific implementation, leaving the freedom to re-implement the RMI runtime as needed be. Though that would be a better solution, the RMI specification is defined in such a way that we can not develop our own implementation following that model.

For these reason we have chosen to follow a layered architecture, which seems to be the most appropriate model for the RMI implementation in accordance with the specification.

Concept Design

From a component point of view, we decided to do the architectural design based on a layered solution to the problem.

Layers

Transport layer: responsible for handling all communications between hosts.

Remote Reference layer: responsible for managing and keeping all references to objects.

Stub/Dispatcher layer:aware of the invocation and execution (respectively) of the methods exported by the objects.

Service Layer: Activation, DGC, Registry.

Services

DGC is located at both client and server, and is responsible for reference counting and talking to local GC in order to free no-longer referenced resources. DGC component is built on top of the stack.

Activator is also designed as a remote object specific app, so it sits on top of the stack.

Registry is also designed as a "bootstrapped" remote object.