Remote RMI Registry
We have built a custom RMI registry that lets remote RMI server objects invoke bind, rebind, and unbind methods. For added robustness, the bindings in the remote RMI registry are stored persistently. Figure 2 gives an overview of the extended Java RMI system architecture using such a remote RMI registry.
The driver for this architectural extension was a project on a peer-to-peer computing system that builds on Java RMI. To provide connectivity even across firewalls and network address translation (NAT) boxes, we needed a mechanism for NAT traversal that is more lightweight than HTTP tunneling. We opted for a STUNT-enhanced Java RMI extension that uses hole punching for NAT traversal. (STUNT is short for "Simple Traversal of UDP Through NATs and TCP"; see nutss.gforge.cis.cornell.edu/pub/draft-guha-STUNT-00.text). For the STUNT-enhanced RMI communication protocol, RMI registries must be publicly accessible, whereas the RMI server objects (the peers) can reside behind NAT borders.
Independent of that project, a remote RMI registry provides added value to Java RMI because it enables new distribution models. For example, instead of several RMI registries collocated with the distributed server objects, a single central RMI registry can be run. This simplifies the operation and maintenance of a Java RMI-based distributed system, and provides transparency of the server object locations, which in turn allows for transparent object migration. Our remote Java RMI registry was designed to meet the following goals:
- Complete transparency to RMI servers and clients. Our primary goal was to provide complete transparency in the sense that RMI servers and RMI clients can use our custom remote registry instead of the standard registry without any change to their code. To meet this objective, the custom registry must not only provide the standard Registry interface, but RMI clients and servers must be able to use the getRegistry method of the JRE built-in class LocateRegistry to obtain a reference to our custom registry. While other remote registries have been described, we are not aware of one that can be accessed through the LocateRegistry.getRegistry method.
- Simple trust model without need for authentication and authorization. Authentication and authorization is not only a complex issue, but its use would also require extensions of the registry interface and thus negate the transparency mentioned earlier. We thus opted for the following simple, straightforward extension of the trust model of the reference implementation: When a name is bound, we store the sender IP address together with the <name, reference> mapping. Only this sender may rebind or unbind the same name.
- Persistent storage of the <name, reference> bindings. To allow for a lossless registry reboot, we persistently store the bindings on hard-disk. Each time a binding is added, changed, or removed, the persistent copy is updated. Because of this persistent storage, invalid bindings must be periodically garbage collected.
