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 |
|---|
| ISBN10: | 1-884777-65-1 |
|---|
| 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 on-line 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 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. In JDK 1.4- you use rmic.exe to generate the
stub classes. In JDK 1.5+, 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 |
| ISBN10: | 0-471-38940-4 |
|---|
| 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 |
| ISBN10: | 1-56592-452-5 |
|---|
| 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 |
|---|
| ISBN10: | 0-201-70043-3 |
|---|
| 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 |
|---|
| ISBN10: | 1-884777-65-1 |
|---|
| 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 on-line at Manning books. |
|
 |
recommend book⇒Core Web Programming, Second Edition |
| | paperback |
|---|
| ISBN10: | 0-13-089793-0 |
|---|
| 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 |
|---|
| ISBN10: | 0-13-089340-4 |
|---|
| 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 the
Proxy class : available:
2008-02-22 by Roedy Green ©1996-2008 Canadian Mind Products
Please email your feedback for publication, errors, omissions, broken/redirected link reports
