13.10 Problems

< Day Day Up >

Explain each part of RMI. Include the programs (rmiregistry, rmic), the interfaces and classes needed, and all the files produced. Explain how each is used.
For each program in Chapter 13, delete all the ".class" files, leaving only the ".java" files. Rebuild the programs, moving each of the class files as needed. (Note: You do not need to move any ".java" files; even for interfaces, you can simply copy the ".class" files.) Explain why each file must be moved.
The Web page at [SUN02d] explains how to use the code base property to automatically download the ".class" file for the stub file when calling a remote object. Make the HelloWorld program work with the code base so that the stub file does not have to be put in the client directory.
For the chat program, first put up a dialog box that will prompt the user to log in using a user name. Change the ChatEvent and the sendChatMessage to handle inclusion of the user's name. Include the user's name when each message is displayed. Add an option to the ChatClient that allows users to disable receiving messages from a specific user.
Using the user name changes from Problem 4, change the way the ChatServer Event Source Object stores the Listeners to use some type of a map (e.g., a ListMap or HashTable). The key should be the user name, and the object is as in Program13.4 (Exhibits 15 through 19). Now create an administrator interface that can:
- Send a message to a specific user.
- Log a user out of the chat system.
Fix the race condition in the chat program that was described in Section 13.7.2.
Implement the bank and the ATM programs from Problem 11.9 using RMI. Make the Bank object the server with one or more ATM clients.
Exhibits 10 through 15 in Chapter 9 (Program9.4) implemented a gas station simulation where a pump manager was used to register open pumps and to give those pumps to customers when they asked to pump gas. Make this program distributed using RMI using the following criteria:
- The pump manager is a server object. It stores pump objects which it then sends to the customers when they request a pump.
- The pump object itself is a non-migrating object, as it does not move to another process when it is included in the PumpEvent. This means that a proxy is included with the PumpEvent. To do this, the pump object should extend UnicastRemoteObject, it will need to run rmic, and a remote interface will have to be defined.
- The car objects will be processes instead of threads. You can start cars anytime in another process, and they will request a pump from the pump manager. Note that because the cars are now separate processes, the static variables are no longer stored and shared between the cars. Move the static variables for the totalTime and totalCars to the pump manager, and define an RMI method call to update them when the car has completed pumping gas.
Often, when running a distributed program such as a bank or reservation system, several servers can be run, and one or more "load balancing" programs will take a user request and give it back to one of the servers. Starting with Problem 13.8, design a load balancing program. Extend the design to include multiple load balancing front ends. Implement your design with the bank from Problem 13.7. (Note: This implies that there will be several separate banks, but for this simulation this is all right.)
Move the storage of the data for the bank in Problem 13.9 outside of the bank object to a data storage object that is shared by several bank objects using RMI. Discuss how this architecture is three tiered. What are some of the advantages and disadvantages of this type of architecture?

< Day Day Up >