Java Glossary : RMI

Java definitions: 0-9 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

You are here : home : Java Glossary : R words : RMI.

Remote Method Invocation -- a specification for RPC (remote procedure calls). The client can invoke methods on objects remotely residing in the server, possibly passing it primitives or objects as parameters and receiving a primitive or object as a result. See Sun's RMI Overview. For more detail, see Sun's RMI Page and Sun's RMI tutorial. The advantages of this technique are:

You don't need to create a custom transaction protocol between client and server. The class files are all that's required.
simpler than CORBA.
No fiddling with sockets, streams or parsing the way you do with CGI.
Very flexible easy protocol, just like calling local objects to do the work. Once you have the objects defined, you can treat local and remote objects identically.

The disadvantages are:

Both client and server need access to the latest identical class definitions of the objects (or at least of their interfaces, stubs are automatically downloaded), something a traditional transaction processing or CGI environment does not require. In CGI, the code in client and server is independent. All that ties them together are the various messages exchanged. Some of the pain of maintaining that coherency in RMI has been eliminated now that you can dynamically load the most recent associated class files using the codebase feature.
Requires Java installed for both client and server. Does not work with any other language the way CORBA does. RMI is a Java-only solution. RMI can use IOP as its low level protocol to give it slightly more compatibility with CORBA. See Sun's RMI Overview for more details. For more discussion see chapter 12 of Qusay Mahmoud's online book Distributed Programming with Java (ISBN: 1-884777-65-1).
Higher overhead than other techniques. If you don't keep your wits about you, you may inadvertently send huge reams of dependent pickled objects back and forth as a side effect of your remote procedure calls. Even at the best of times, the transmitted serialised objects are bulky. Objects contain considerable identifier text, versioning, and of course nested referenced objects.
Requires two copies of the JVM running on the server, one for the registry and one for the server proper.
For more discussion see chapter 12 of Qusay Mahmoud's online book Distributed Programming with Java (ISBN: 1-884777-65-1).

I saw a demo on coding and using RMI at the Java Colorado Software Summit. It was about 30 times simpler than I imagined it would be. Objects on the server make a call to register themselves as open for business. Objects on the clients make a connection request. Then from then on, the objects on the clients just invoke the methods of the objects on the server as if they were local. All the parameters and results get passed back and forth automagically in serialised form.

For a remote procedure call, there are two objects, one local proxy stub object and one remote real object. RMI can communicate in both directions between client and server. Let's assume the client wants to execute a method on a remote server object, the usual case. The stub proxy object lives in the client's address space. The real object runs in the server's address space. The client invokes the method on the stub proxy, just as if it were working on the server's object directly. RMI magic happens, and the equivalent method call gets done on the server's object, and the results get passed back to the proxy stub object. To the client, it is just like a local method call. The only difference is it takes longer.

You don't explicitly serialise. Your calls send primitives and references over the link as parameters. The objects and the code to manipulate the objects do not travel over the link.

The method invoked on the server could do anything an ordinary method could do e.g. call other methods, read or write the disk, talk to a database engine, call methods remotely back to objects on the client ...

What about calling remote static methods? I don't think that is possible.

A special program called the Registry runs on the server. This has absolutely nothing to do with the accursed Windows registry. The RMI Registry is a totally separate EXE from the server JVM. The objects themselves live in the server's address space, not the registry's. The registry allows server objects to register themselves as available to the clients. Clients can find a registered object by asking for it by name. Since each client gets given a reference to the single copy of the registered object running on the server, that object would be very busy. Typically it is a factory object that spins off other objects and threads that do the actual work. The registry is just to get started. Once you have a reference, you no longer need the registry. You can pass your reference onto others so they can use it without ever talking to the registry. Why is the Registry a separate program? I speculate Sun did that for two reasons:

So that the Registry could run on a separate server, thus sharing the workload.
After all the clients have found all the Objects they need, you can shut down the Registry and reclaim the resources it was using.

There are two kinds of object in RMI, ordinary ones that don't implement the Remote interface, and ones that do. Ones that do, have RMIC stubs on both client (called a stub) and server (called a skeleton, but no longer needed in Java 1.2+). When you pass an object as a parameter to a remote procedure, it may go either by reference or by value. Only the server has the actual code for the class. RMI is a peer to peer protocol, so any station may act both as client and server.

Ordinary objects go by value. The object may travel in either direction, client to server or server to client, and may be passed as a parameter or returned as a result. The object's datafields are pickled by serialisation into an ObjectStream and reconstituted on the other end. You end up with two independent objects, one local and one remote. Changes made to one won't be reflected in the other.

When you pass an object that implements Remote as a parameter, it goes by reference. It may travel in either direction, client to server or server to client, and may be passed as a parameter or returned as a result. A dummy proxy object is created at the other end, but the master copy of the object with its datafields remains behind. When the other ends wants to find out about data in the object, or change data in the object, (by invoking its methods), it invokes the interface methods of the local proxy object which in turn transparently invokes the methods of the remote master object and returns the results.

Microsoft Internet Explorer does not support RMI directly. You have to explicitly place the files in an ARCHIVE statement and download the mother every time you run your Applet! ouch! You are better off using the Java Plug-in, or pre-installing the RMI class library, or running as an application rather than an Applet.

Core Web Programming, Second Edition

0-13-089793-0

Marty Hall and Gary Cornell

1250 pages. Also has some simple RMI examples. This is a great doorstop of a book. It has a few chapters on client-server programming in Java, and a section of that is on CGI. I have looked at hundreds of Java books and found nothing that deals in depth with client side Java talking to CGI, except Marty's book. It is really very simple and he does an excellent job of explaining it. Marty has posted all the source code examples from the book for anyone to use. These contain updates and errata fixes you don't get on the CD-ROM that comes with the book.

Core Servlets and Java Server Pages

0-13-089340-4

Marty Hall

Complete text of the book available on line in pdf format.

Core Servlets and Java Server Pages

0-13-089340-4

Marty Hall

Complete text of the book available on line in pdf format.

Core Servlets and Java Server Pages

0-13-067614-4

Marty Hall

Complete text of the book available on line in pdf format.

bea ¤ CORBA ¤ distributed objects ¤ IDL ¤ IIOP ¤ ORB ¤ remote file access ¤ RMI Doves ¤ RMI Tutorial ¤ serialisation ¤ servlet

home	Canadian Mind Products
	mindprod.com IP:[24.87.56.253]
	Your IP:[80.134.30.163]
	You are visitor number 2875.
	Please send errors, omissions and suggestions
	to improve this page to Roedy Green.
	You can get a fresh copy of this page from:	or possibly from your local J: drive mirror:
	http://mindprod.com/jgloss/rmi.html	J:\mindprod\jgloss\rmi.html