Stubs and Skeletons

When a client obtains a reference to a remote object, the remote object is not sent over the network to the client. Actually, the client gets a proxy object or stub. A stub acts as a client(s) local representative for the remote object. The client invokes a method on the local stub. The stub is responsible for calling the method on the remote object. Each client gets a copy of stub object that represents the remote object. A remote object is not replicated for every client. A stub implements all the remote interfaces that a remote object implements (see Figure 2.1).

The skeleton is a server side proxy for the remote object. It is much like the stub class but resides on the server. The skeleton is responsible for calling the actual remote object implementation (see Figure 2.1).

Figure 2.1

Bootstrap Name Server

The RMI registry is a simple name server provided for storing references to remote objects. The server is responsible for registering remote objects with the registry service. The registry keeps track of the addresses of remote objects. A remote objects handle can be stored using the methods of java.rmi.Naming class. A client can obtain a reference to a remote object by looking up in the server(s) registry or as a result of a remote method call. The registry server is necessary only when making an initial contact with the application. An application can also run its own registry service. The RMI registry application (rmiregistry) is included in JDK.

Figure 2.2