 |
|
|
|
|
 |
Site Archive (Complete) | |||
|
||||
|
ABOUT US |
CONTACT |
ADVERTISE |
SUBSCRIBE |
SOURCE CODE |
CURRENT PRINT ISSUE |
NEWSLETTERS
|
RESOURCES
|
BLOGS
|
PODCASTS
|
CAREERS
|
||||
|
||||
November 06, 2008
A Remote Java RMI RegistryA custom registry that objects can register with remotelyOliver Haase, Juergen Waesch, and Bo Zhao
Our authors present a custom registry that objects can register with remotely.
Oliver and Jürgen are computer science professors at Konstanz University of Applied Sciences and can be reached at haase@htwg-konstanz.de and juergen.waesch@htwg-konstanz.de, respectively. Bo recently received his master's degree in communication systems engineering from Konstanz University of Applied Sciences and can be reached at zhao.konstanz@googlemail.com.
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.
[Click image to view at full size]
Figure 1: Standard Java RMI system architecture with local RMI registries in FMC notation (www.fmc-modeling.org). (1) RMI server object (re)binds itself to the local RMI registry running on the same machine—(re)binding to a remote RMI registry is prohibited (AccessException). (2) RMI clients lookup the specific RMI registry to get a remote reference (a client stub), to the server object. (3) RMI client invokes methods on the remote server object via the client stub.
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.
|
|
|
|||||||||||||||||||||||||||
|
|
