The stub is an example of the
proxy pattern[1].
It is used whenever you need to decouple the specifics of an object from its clients. In this course we are decoupling the location and details of how to invoke the remote object from the client. All the client sees is the interface of the proxy, and all the details of the remote object are hidden under its surface. You will appreciate the simplicity of changing the implementation of the proxy. In doing so, you can alter remote specific implementation details such as the
network address[2] of the remote object or the transport that is being used to communicate with the remote object. All this can be done without changing a single line of code in the client. Details that change are usually location, security, transactions, etc.
A
design pattern[3] describes a solution to a problem that occurs over and over again when designing object-oriented computer systems. The following
series of images illustrates these steps.(Please note that I have ignored the actual host systems and the details of the network and show only the object specifics.)
In Java RMI, the clients of a remote object did not call methods on the
remote object directly.
Instead, they call methods on a stub, which passes the method call information over the network to the skeleton, which calls the method on the remote object. The EJB model extends this notion by introducing the idea of the EJB container as an additional element in the interaction. The container has two main functions:
- It intercepts all method calls made by the client and carries out various actions (concerned with security and transaction management, among other things) before delegating them to an instance of the implementation class itself. That is, the container provides proxies that isolate the EJB's implementation class from its clients.
- It provides general services to the EJB, such as database connection pooling.