Java's platform independence and built-in network support make it well suited for distributed computing. One key feature in this context is Java Remote Method Invocation (RMI) technology (java.sun.com/javase/technologies/core/basic/rmi/index.jsp), which lets you use the familiar method invocation paradigm to communicate between remote Java objects. This abstraction simplifies the development process because you need not deal with communication protocols, on-the-wire data representation, and connection management.
Sun Microsystems' Java Runtime Environment (JRE) includes the rmiregistry tool, a reference implementation of the java.rmi.registry.Registry interface. This interface contains methods that let RMI servers bind remote object references to logical names, and allows RMI clients to lookup these bindings and download the associated object references.
To avoid security issues (such as malicious code rebinding existing object references), the server-side methods bind, rebind, and unbind can be invoked only locally, while the client-side methods list and lookup can be invoked remotely. Figure 1 is an overview of the standard Java RMI system architecture.
The downside of this trust model, however, is that it requires the host that runs rmiregistry and the RMI server object to be externally accessible. This restriction might be acceptable for heavyweight, centrally administrated applications, but not for highly dynamic, massively distributed applications, such as peer-to-peer applications. Also, the resulting distribution model prohibits location transparency, as an RMI client that retrieves a remote reference from an rmiregistry automatically knows the object's location. A further shortcoming of the rmiregistry is that all bindings are kept in main memory only, rather than stored persistently.
