Jini Puts RMI on Steroids
RMI has come a long way in the last three years. The addition of Jini and Java 2 to the programmer's toolbox corrects many of the deficiencies of earlier implementations of RMI. First, RMI used a simple, string-based Naming service that lets clients find remote services on particular hosts by name. The Jini Lookup Specification leverages Java's concept of interfaces and allows much more complex lookup queries to be built. Service instances can also be looked up by globally unique ServiceIDs.
To use RMI service objects, the client had to know the network address of the service it was looking for. Jini's use of IP multicast eliminates this constraint and allows lookup services and services to be found without knowledge of where those services reside.
RMI's Naming service allowed only stub references to Remote objects to be stored. Jini's Lookup service can store both references to Remote services and Serializable service objects that can be downloaded and executed locally on the client.
Systems built on RMI were subject to resource management problems in the event of host, process, and network failures. There were no established mechanisms for Service objects to tell when its clients had failed, leaving them holding resources for clients that no longer existed. Jini's Leasing specification and Java 2's Distributed Garbage Collection (which uses a leasing mechanism) have addressed this issue.
Finally, RMI did not provide a framework for remote events, nor was there support for distributed transactions. Jini's Remote Event and Transaction Specifications have addressed this.
— B.P.
