The consequences for the client The consequences for the naming service The consequences for the account servers

17.3.2 Modifying the Existing Application

The various versions of our banking application have consisted of three distinct pieces of code: the client code, the server code, and the launch code. When examining the impact of an architectural change, its often useful to try and gauge the impact separately for each of these pieces. If for no other reason, it lends some structure to the planning process.

17.3.2.1 The consequences for the client

From the clients point of view, this is a little more complicated than the first version of our application. The flow of control is: 1. The client contacts the naming service to get the factorys stub. 2. The client contacts the factory to get an account. 3. The client talks to the account. 4. The client then tells the factory it is done with the account. However, this complexity, while it inserts another layer of abstraction into the client program, doesnt involve a lot of extra work. When you actually look at the code, the client really only needs a few extra lines of code, in the getAccount and releaseAccount methods. For example, the getAccount method changes from: private void getAccount { try { _account = AccountNaming.lookup_accountNameField.getText ; } catch Exception e { System.out.printlnCouldnt find account. Error was \n + e; e.printStackTrace ; } return; } to: private void getAccount { try { Factory factory = FactoryNaming.lookupACCOUNT_FACTORY_NAME; _account = factory.getAccount_accountNameField.getText ; } catch Exception e { System.out.printlnCouldnt find account. Error was \n + e; e.printStackTrace ; } return; }

17.3.2.2 The consequences for the naming service

The naming service has a much simpler task in this new application architecture. Instead of knowing about and keeping stubs for each and every account, the naming service simply needs to keep a single stub for the factory. This doesnt actually involve a change in the naming services functionality. However, it does mean that the application consumes a much smaller percentage of the naming services resources. This means that we can probably use a single naming service, located and maintained on a central server, for multiple applications.

17.3.2.3 The consequences for the account servers

There are almost no consequences for the servers implementing the Account interface. We have chosen to use servers that dont extend UnicastRemote , in order to maximize control over exactly when an object listens for client connections. But the actual functionality we implemented in the account servers does not change at all. In other words: What changes in this new architecture is when the servers are launched and when theyre shut down. The actual implementation of the account server doesnt need to change at all.

17.4 A Better Factory