Deploying Can Be Difficult

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. In addition to the time and effort spent in the intial deployment, you need to consider the inevitable deployment errors in the traditional scenario. A large part of the deployment hassle is the inevitable month or two of random bug reports and lost productivity that result from deployment errors. How Often Do You Deploy? Sometimes, when I mention how painful deployment can be, people respond by saying, Yeah, but how often do you really redeploy an updated application? Once a year? This is a good question. Some applications dont get redeployed very often. However, the question has a slightly circular flavor to it; part of the reason why applications dont get updated and redeployed mo re often is that deployment is such a time-consuming and difficult process. When environments make it possible to easily deploy an updated applications, applications tend to get updated and redeployed much more frequently. Web-based applications are the perfect example of this. You only need to reconfigure a few servers in order to redeploy a web-based application. And web-based applications are redeployed almost constantly. However, every time you need to update or redeploy an application, this difference looms larger and larger. Applets are, of course, limited in many ways. Because all of the bytecode is downloaded every time theyre run, they have to be small, and because the browser may be using an older JVM, the developers who write an applet cant take advantage of a great deal of the latest Java features, such as the Swing GUI toolkit. In addition, because the browsers have a stringent security model, the applets ability to open socket connections or files is severely limited. These are all even-if-the-browser-was-perfectly- implemented objections to developing client-server applets. That is, theyre valid and will always be valid objections, no matter how much the browsers improve. In addition to these, theres also the fact that the existing web browsers provide an incredibly slow and buggy JVM. The good news is that RMI contains an interesting and useful technology, called dynamic classloading, that attempts to merge these two models. It lets you build standalone applications that, at least for some parts of your codebase, have an applet-like deployment model. That is, dynamic classloading allows an RMI application to dynamically load bytecode definitions of classes from an http: or ftp: URL at runtime, when the class definition is required.

19.2 Classloaders