Build Test Applications The Rest of the Application

private static void launchServerNameBalancePair serverDescription { try { Account_Impl newAccount = new Account_ImplserverDescription.balance; Naming.rebindserverDescription.name, newAccount; System.out.printlnAccount + serverDescription.name + successfully launched.; } catchException e{} } private static Collection getNameBalancePairsString[] args { int i; ArrayList returnValue = new ArrayList ; for i=0; i args.length; i+=3 { NameBalancePair nextNameBalancePair = new NameBalancePair ; nextNameBalancePair.name = args[i]; Integer cents = new Integerargs[i+1]; nextNameBalancePair.balance = new Moneycents; returnValue.addnextNameBalancePair; } return returnValue; } private static class NameBalancePair { String name; Money balance; } } All this does is parse the command-line arguments, create instances of AccountImpl corresponding to them, and then register those instances with the RMI registry. So, after running our batch file, we have two instances of Account registered with the registry. One corresponds to Bob, who has exactly 100 in his account, and one corresponds to Alex, who has 12.23 in her account. Of course, this is an unrealistic piece of launch code. In a real bank, the customer account information wouldnt be stored as command-line arguments to a batch file. But, as a pedagogical device, its pretty nifty.

9.3 Build Test Applications

We all know that code needs to be tested. Thoroughly. So the following sad story shouldnt be necessary. But Im going to tell it anyway. Once upon a time, I worked for a consulting company, building a distributed application for a client. The application was written in Objective-C [ 3] for computers running the NeXTSTEP [ 4] operating system. And it utilized NeXTs Portable Distributed Objects PDO framework. [ 3] Never heard of it? Think Smalltalk with a C syntax. [ 4] An obscure Unix variant. We wrote the application. Each object worked correctly. The networking worked fine. And we even tested the application with all 10 developers running it at once. The server worked beautifully, the application ran quickly, and everything was wonderful. The customer was skeptical. So the application was rolled out to a limited number of users for testing. Everything worked fine, and the customer was enthused. We delivered an application that worked well, and we actually came in ahead of schedule. We were beaming with pride as they rolled out the application to the entire organization. At which point, of course, the application no longer worked. It turned out that the server wasnt quite as robust as wed thought. It couldnt handle large numbers of simultaneous clients. And our testing, which was actually quite thorough, failed to uncover this fact. Lets examine why. We tested: • The underlying server logic that handled each client request • The connection logic so clients could find the servers easily • The ability of the application to handle a dozen or so users But we assumed that this would be sufficent If it can do this stuff, its working fine. This was a very bad mistake. Simulate the clients environment as much as you can. If youre planning to deploy 500 clients, you need to actually test with 500 clients. Actually, test with more clients than you plan to have. Successful applications frequently see heavier use than expected. Testing our banking application isnt really very feasible right now. For one thing, stress testing is usually done with applications that simulate dozens of clients simultaneously. For another, our implementation of AccountImpl wont actually work correctly if more than one client connects with it simultaneously it isnt threadsafe. But testing is an important part of the development process, and thus deserves to be mentioned in our overall sketch of the RMI development cycle.

9.4 Build the Client Application