Channels ▼
RSS

Tools

A Remote Java RMI Registry

Source Code Accompanies This Article. Download It Now.


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.

[Click image to view at full size]

Figure 2: Extended Java RMI system architecture with a remote RMI registry in FMC notation (www.fmcmodeling.org). (1) An RMI server object (re)binds to the remote RMI registry. The bindings in the remote RMI registry are stored persistently—to garbage collect invalid bindings, the remote RMI registry periodically pings the server objects. (2) RMI clients lookup the remote RMI registry to get the remote reference to the server object. (3) Remote method invocation is done as usual.

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.


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
 

Video