Java™ Application Development on Linux - Dator

5.8 Introducing RMI145almost ready to fire our system up and give it a try. But first, we’ll give yousome information about our sample environment and talk very briefly aboutsecurity. 215.8.4.1 What RMI Servers and Clients Need to Be Able to DoRMI servers and clients need to be able to listen for connections on networkports, and they need to be able to initiate connections on network ports. Backin the Java 1.1 days, there were no limits on what RMI methods could do. TheCLASSPATH was assumed to be trusted. With the RMI 1.2 protocol specification,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, thisopens a lot of possible security risks. For this reason, RMI got a security managementlayer. It is the same security manager as the one that applets use. Italso provides a default security manager class that has virtually all such capabilitiessafely turned off. We need to turn on some of these capabilities in orderto make our sample work.The RMI system expects Java classes to be made available through one oftwo paths.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 compiledcode installed on both our server system and our client system. The classes willall 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 theclasses to be available in a JAR file via a Web server, and for thejava.rmi.server.codebase property to be set to point to the JAR file viaan http: URL.21. We’re going to gloss over this subject for now.