Before we can get to the last major design pattern in Chapter 17, factories, we need to take a short detour and discuss what we’ve been referring to as “the RMI runtime.” This chapter is devoted to exploring the code that exists between, and manages the connection between, the stub and the skeleton. By the end of this chapter, you will understand how the distributed garbage collector works, how RMI maintains connections between clients and servers, how to use the RMI logging facilities, and how to customize RMI’s behavior at runtime.
The place to start is with a variation on the standard architecture diagram shown in Figure 16-1.
Figure 16-1. The layers in a remote call
This picture is a little different from the previous ones in that we’ve included the RMI runtime on the client side of the wire as well as on the server side. This is not the graphical equivalent of a typo; the RMI runtime plays a significant role on the client side as well as on the server side. By the way, note that the RMI runtime, especially on the client side, is often referred to as “the transport layer.”
In this architecture, the stub serves three distinct purposes:
It is serialized and sent over the wire from the server to a client; it contains the data that enables the client to reliably send messages to that server.
It is a proxy ...