Interaction with Parameters Incorporating a Custom Socket into an Application

} catch IOException e{} return null; } public ServerSocket createServerSocketint po rt { try { if _isMonitoringOn { return new MonitoringServerSocketport; } else { return new ServerSocketport; } } catch IOException e{} return null; } public boolean equalsObject object { if object instanceof PropertyBasedMonitoringSocket_RMIClientSocketFactory { return true; } return false; } public int hashCode { return _hashCode; } }

18.2.3.1 Failure handlers

There are two additional static methods defined in RMISocketFactory : getFailure - Handler and setFailureHandler . These methods enable you to get and set the RMIFailureHandler . The RMIFailureHandler is used by RMI when, for some reason, an instance of ServerSocket is required, but cannot be created e.g., when the socket factory that is supposed to create the ServerSocket throws an exception. RMIFailureHandler is an interface with a single method: public boolean failureException ex The boolean return value is used to tell RMI how to proceed. A return value of true tells RMI to try to create the instance of ServerSocket again; a return value of false tells RMI that the attempt to create a server socket has failed completely. RMIs default implementation of RMIFailureHandler simply returns true . This is a pretty reasonable default, and overriding it by calling setFailureHandler is rarely done. The typical reason for overriding this behavior is to log the failure.

18.2.4 Interaction with Parameters

In Chapt er 16 , we discussed a number of transport layer parameters. These are global properties of the JVM used to configure RMIs behavior with respect to sockets. The transport layer parameters are sun.rmi.transport.connectionTimeout , sun.rmi.transport.tcp.readTimeout , and sun.rmi.transport.proxy.connectTimeout . Its reasonable to wonder how these interact with the definition of custom socket factories. RMIs Default Connection Strategy RMISocketFactory is an abstract class that defines five static methods. The default implementation of RMISocketFactory used by Suns implementation of RMI does not simply create instances of Socket and ServerSocket . Instead, it defines a three-tiered connection strategy. The problem is this: corporate computing environments often have firewalls in place between the corporate intranet and the Internet. These firewalls block most socket-level communication, typically on the basis of the port involved. For example, a firewall policy may involve blocking all packets that arent being sent to either a mail server or a web server. Such a policy would block any RMI server listening on a randomly assigned socket. In order to get around this, the default implementation of RMISocketFactory implements the following client-side connection strategy: 1. Attempt a direct socket connection using JRMP the default RMI protocol. 2. If that fails, wrap up the remote method invocation inside an HTTP POST command, and attempt to post the remote method invocation to the server port. 3. If that fails, wrap up the remote method invocation inside an HTTP POST command, and attempt to post the remote method invocation to the server port, but with a predefined proxy machine. 4. If that fails, wrap up the remote method invocation inside an HTTP POST command, and attempt to post the remote method invocation to port 80 using the predefined proxy machine. This strategy is both useful and dangerous. Its useful because it helps when users are outside a corporate firewall and need to connect to an RMI server. Its dangerous because, in essence, it breaches the firewall. To the extent that the firewall was necessary, RMIs default connection strategy is a security risk. Well discuss this in greater detail in Chapt er 22 . The answer is that RMI uses the custom socket factories to create sockets, and then calls methods on the sockets to configure them. The sequence RMI goes through to obtain a server socket is: 1. Use the RMIServerSocketFactory associated with the server to see if a server socket has already been allocated. If so, use the existing server socket. 2. If not, call createServerSocket on the RMIServerSocketFactory associated with the server and, after the socket has been created, configure the socket. This means that, in practice, you set defaults for custom sockets and then override the defaults using system properties. This is identical to what happens with ordinary sockets.

Chapter 19. Dynamic Classloading

Deploying a distributed application can be rather difficult. All of the computers that run parts of the application must have the relevant parts installed. For a local area network, this is usually a time- consuming, but not particularly difficult, process. However, when applications are deployed on a larger scale, and updated frequently, the deployment process becomes far more difficult. Dynamic classloading is a technology, built into RMI, which attempts to make this deployment a little easier. At this point in the book, weve covered most of the basics of building a robust and scalable distributed application. Weve gone through the rules for designing interfaces, weve spent a lot of time discussing threads, weve covered testing a distributed application, and weve even discussed how to optimize the distributed garbage collector. Now its time to dig deep into the task of deploying and redeploying an application.

19.1 Deploying Can Be Difficult

Lets start by supposing that were deploying the latest version of the banking application. We need to do the following: • Configure the server machines. • Add the stub classes to the naming service classpath, along with any other classes, such as socket factories and value objects, that might need to be instantiated inside the naming service. • If this is a redeployment, as opposed to a first-time deployment, youll probably have to restart the naming service and reregister all the objects to get rid of the existing class objects in the naming services JVM. • Install and configure the application on every client machine. This includes tracking machines that are currently unavailable e.g., laptops out on loan or machines in for repair, so the application can be installed on them later. Compare this to the deployment procedure for the typical applet, in which we must: • Configure the server machines • Write web pages that have an APPLET tag in them. Put succinctly, deploying a web application doesnt involve changes to the client side or to a naming service. Instead, when a web browser downloads a web page containing an applet tag, it also downloads the Java class files necessary to run the applet. This way of deploying applications is much less time-consuming and much more likely to be done correctly.