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. RMI has gone through several
major revisions in the way it works. Unless you are going to work with older JVMs, it is best to read only the
most current documentation.
Advantages
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 or Servlets.
- 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.
Disadvantages
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. Most of the pain of maintaining that coherency in RMI was eliminated in JDK
1.2 when you were first able to dynamically load the most recent associated class
files using the Codebase feature. It works best if all parties are running the same JVM.
- 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. However, RMI can use IIOP as its low level protocol,
which makes it compatible with CORBA.
 |
recommend book⇒Distributed Programming with Java |
| | paperback |
|---|
| ISBN13: | 978-1-884777-65-3 |
|---|
| publisher: | Manning Publications |
|---|
| published: | 1999-09-01 |
|---|
| by: | Qusay Mahmoud |
|---|
| Discusses how to digitally sign messages going over socket. Manning books. |
|
- 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. This is actually a serialisation problem,
not something specific to RMI. Serialisation’s usual versioning gotchas and lack of generic type
information haunt you too here. If you use IIOP, the serialisation mechanism is entirely different, as are the
contents.
- Originally RMI required two copies of the JVM running on the server, one for the registry and one for the
server proper. Now the two functions nearly always run in a single JVM, See
java.rmi.registry.LocateRegistry. createRegistry for
details. For more discussion see chapter 12 of Qusay
Mahmoud’s online book Distributed Programming with Java (ISBN: 1-884777-65-1).
How It Works
I saw a demo on coding and using RMI at the Java Colorado Software Summit in 1997. 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 code on the server does all the application work. The stub code on the client just collects parameters and
bundles them into objects to send to the server.
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…
You can’t call static methods remotely. If you needed to do so, you would
have to call some remote instance method that did the static call for you. The only methods you can call remotely
are methods in an interface that extends Remote.
The RMI Registry
A special program called the Registry runs on the server. This has absolutely nothing to do with the accursed
Windows registry. The RMI Registry usually runs in the same JVM al the server. Even when it runs in its own JVM,
it always runs on the same host. When you have separate JVMs, 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.
Stubs and Skeletons
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 version 1.2 or later). 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. In Java version 1.4- you use rmic.exe to
generate the stub classes. In Java version 1.5 or later, the RMI runtime does it automatically
by constructing a java.lang.reflect. Proxy (not to be
confused with java.net. Proxy) on the fly.
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. but if and only if it is exported at the time. Otherwise, it is serialised
and exported on arrival (so it acts like a mobile remote agent). This is the intention but there have been
several bugs in this area. Exported just means the object is made visible to the
outside world. Normal objects, even if they implement Remote, are private to that
JVM. Exporting a remote object makes it available to accept incoming remote method requests. When you extend
java.rmi.server. UnicastRemoteObject or java.rmi.activation. Activatable, your class will be exported
automatically upon creation.
Microsoft Internet Explorer and Microsoft Java do not support RMI directly. You have to explicitly place the
library 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.
Books
 |
recommend book⇒Mastering RMI: Developing Enterprise Applications in Java and EJB |
| | paperback |
|---|
| ISBN13: | 978-0-471-38940-8 |
|---|
| publisher: | John Wiley & Sons |
|---|
| published: | 2001-02-21 |
|---|
| by: | Rickard Oberg |
|---|
| Covers RMI and how it interfaces with JINI and EJB. |
|
 |
recommend book⇒Java RMI |
| | paperback |
|---|
| ISBN13: | 978-1-56592-452-9 |
|---|
| publisher: | O’Reilly  |
|---|
| published: | 2001-10-15 |
|---|
| by: | William Grosso |
|---|
| Covers serialization, threading, the RMI registry, sockets and socket factories, activation, dynamic class downloading, HTTP tunneling, JNDI, and CORBA. |
|
 |
recommend book⇒Java.rmi: The Remote Method Invocation Guide |
| | paperback |
|---|
| ISBN13: | 978-0-201-70043-5 |
|---|
| publisher: | Addison-Wesley |
|---|
| published: | 2001-07-18 |
|---|
| by: | Esmond Pitt, Kathleen McNiff |
|---|
| Esmond Pitt is a frequent contributor to the newsgroups and has sent me a number of emails on how to improve various entries in the Java glossary, including the RMI entry. He is the sort of person who goes out of his way to be helpful and to explain things. Esmond is more intelligent than nearly everyone, so you will have to stretch to keep up with him. This is not a book for rank beginners. It is the definitive book on RMI. Unfortunately, the book contains precious few examples, my favourite way of learning. The author commanded me to change the wording of this mini review. I told him to get stuffed. He also made complex requests for corrections to this page on RMI, but in such an imperious and insistent way and because I did not have the physical and emotional energy to deal with his difficult wording, I eventually decided to plonk him. He is now harrassing my ISP. |
|
|
recommend book⇒Distributed Programming with Java |
| | paperback |
|---|
| ISBN13: | 978-1-884777-65-3 |
|---|
| publisher: | Manning Publications |
|---|
| published: | 1999-09-01 |
|---|
| by: | Qusay Mahmoud |
|---|
| discusses how to digitally sign messages going over socket. Chapter 12 is available online at Manning books. |
|
 |
recommend book⇒Core Web Programming, Second Edition |
| | paperback |
|---|
| ISBN13: | 978-0-13-089793-0 |
|---|
| publisher: | Prentice Hall |
|---|
| published: | 2001-06-03 |
|---|
| by: | 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. |
|
 |
recommend book⇒Core Servlets and Java Server Pages |
| | paperback |
|---|
| ISBN13: | 978-0-13-089340-6 |
|---|
| publisher: | Prentice Hall |
|---|
| published: | 2000-05-26 |
|---|
| by: | Marty Hall |
|---|
| Complete text of the book available on line in pdf format. |
|
Learning More
Sun’s JDK Technote Guide on
RMI Getting Started Tutorial : available:
Sun’s JDK Technote Guide on
RMI FAQ : available:
Sun’s JDK Technote Guide on
Codebase : available:
Sun’s Javadoc on
LocateRegistry.createRegistry : available:
Sun’s Javadoc on
Proxy class : available:
Please email your feedback for publication, errors, omissions, typos, formatting errors, ambiguities, unclear wording, broken/redirected link reports, suggestions to improve this page or comments to
Roedy Green :
