Deploying the Application The Rest of the Application

getAccount ; resetBalanceField ; releaseAccount ; } catch Exception exception{ System.out.printlnCouldnt talk to account. Error was \n + exception.printStackTrace ; } } } private class WithdrawAction implements ActionListener { public void actionPerformedActionEvent event { try{ getAccount ; Money withdrawalAmount = readTextField_withdrawalTextField; _account.makeWithdrawalwithdrawalAmount; _withdrawalTextField.setText; resetBalanceField ; releaseAccount ; } catch Exception exception{ System.out.printlnCouldnt talk to account. Error was \n + exception; exception.printStackTrace ; } } } private class DepositAction implements ActionListener { public void actionPerformedActionEvent event { try { getAccount ; Money depositAmount = readTextField_depositTextField; _account.makeDepositdepositAmount; _depositTextField.setText; resetBalanceField ; releaseAccount ; } catch Exception exception { System.out.printlnCouldnt talk to account. Error was \n + exception.printStackTrace ; } } } }

9.5 Deploying the Application

The final step in implementing a distributed application is deployment. Deploying an application can be a difficult and tedious task. RMI applications are no different than ordinary applications in this regard. They do, however, add one new wrinkle: you need to deploy stubs along with your client. Recall that when you finish writing the code, you need to generate stubs and skeletons. The stubs, even though theyre generated from the server classes, are part of the client application. This can become an issue because, if you modify the server, you may need to redistribute the stubs. Even though the client code hasnt changed, if either the server classes AccountImpl in the current case or the data objects have changed, RMI will throw an exception if you use an older version of the stub classes in the client application. You also need to make sure that the naming service has the stubs on its classpath. This usually catches first-time users of RMI by surprise, but its necessary because the registry has a stub for every server that gets registered. The registry doesnt simply hold on to the serialized bytes; it actually instantiates the stub and stores the stub in a hashtable. In order to do this, the registry needs to have access to the stub classes. Well discuss why the registry does this in Chapt er 14 . For now, just remember: the stubs need to be deployed with the client application and with the registry. Part II: Drilling Down: Scalability Chapter 10. Serialization Serialization is the process of converting a set of object instances that contain references to each other into a linear stream of bytes, which can then be sent through a socket, stored to a file, or simply manipulated as a stream of data. Serialization is the mechanism used by RMI to pass objects between JVMs, either as arguments in a method invocation from a client to a server or as return values from a method invocation. In the first section of this book, I referred to this process several times but delayed a detailed discussion until now. In this chapter, we drill down on the serialization mechanism; by the end of it, you will understand exactly how serialization works and how to use it efficiently within your applications.

10.1 The Need for Serialization