A Redeployment Scenario How Dynamic Classloading Works

codebase annotation if the bootstrap classloader cannot load the class. See Figur e 19- 2 . Figure 19-2. RMI indexes classloaders by codebase Before we get into the actual mechanics of dynamic classloading, we will discuss two example scenarios to make the idea a little clearer.

19.3.1 A Redeployment Scenario

Suppose that youve implemented and deployed the bank example. Three months later, you must roll out a new version using the Account2 interface: public interface Account2 extends Account { has new reporting functionality public TransactionList getLastNTransactionint numberOfTransactions throws RemoteException; public TransactionList getTransactionsSinceDate since throws RemoteException; } You have two options. The first is the traditional sweeping redeployment in which everything is shut down and you need to go to every client machine and reinstall the application in the next 24 hours or however long it takes. The second option is a staged rollout. The key to the staged rollout is realizing that, since Account2 extends Account , the first client application will work perfectly well with the new server. The code that retrieved a stub from the naming service was: private void getAccount { try { _account = AccountNaming.lookup_accountNameField.getText ; } catch Exception e { System.out.printlnCouldnt find account. Error was \n + e; e.printStackTrace ; } return; } This code will work fine if the stub implements Account2 because Account2 extends Account ™the cast will succeed. The old client application wont be able to access the new functionality, but the old application is still a fine application and probably quite usable for most tasks. If you could install the new server applications without needing to redeploy the client, then you could gradually phase in the new client application. This gradual deployment would be less stressful for IT and would allow for a much greater degree of testing for the new functionality. No matter how thoroughly you test an application, theres still a substantial risk when you roll it out to an enterprise. Dynamic classloading lets you do exactly this. When you launch the new servers, and bind in the instances of Account2 , the old client application will receive a serialized instance of the new stub. Because the old application doesnt have the appropriate classes locally, it will download them from the URL. The cast will succeed, and the server will be upgraded in a way thats totally transparent to the client application. The same idea also applies for less drastic upgrades. For example, changing a supporting class, such as a socket factory, can be instantly accomplished if either the class name changes, or if the old class isnt actually deployed on the clients filesystem.

19.3.2 A Multiple-Deployment Scenario