Java Reference
In-Depth Information
almost ready to fire our system up and give it a try. But first, we'll give you
some information about our sample environment and talk very briefly about
security.
21
5.8.4.1
RMI servers and clients need to be able to listen for connections on network
ports, and they need to be able to initiate connections on network ports. Back
in the Java 1.1 days, there were no limits on what RMI methods could do. The
CLASSPATH
was assumed to be trusted. With the RMI 1.2 protocol specifica-
tion, the ability to actually pass bytecodes between VMs over RMI was added.
That means that it is possible for clients to pass code to servers. Obviously, this
opens a lot of possible security risks. For this reason, RMI got a security man-
agement layer. It is the same security manager as the one that applets use. It
also provides a default security manager class that has virtually all such capabil-
ities safely turned off. We need to turn on some of these capabilities in order
to make our sample work.
The RMI system expects Java classes to be made available through one of
two paths.
What RMI Servers and Clients Need to Be Able to Do
1. The
CLASSPATH
, either the environment variable or on the command line.
2. Through a property that points at URL. This URL may be a
file:
URL,
or an
http:
URL.
We are going to do the simplest case for now. We will have our compiled
code installed on both our server system and our client system. The classes will
all be referenced relative to the default classpath (in other words, relative to “.”,
the current directory).
This is not the typical case. The most common case will be for the
classes to be available in a JAR file via a Web server, and for the
java.rmi.server.codebase
property to be set to point to the JAR file via
an
http:
URL.
21. We're going to gloss over this subject for now.
