J2EEOnline J2EE





EJB Architecture  «Prev  Next»
Lesson 4Client Stub Proxy Pattern
ObjectiveDescribe how the proxy pattern applies to distributed objects.

Client Stub Proxy Pattern

The stub is an example of the proxy pattern.
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 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.

EJB Proxy Pattern consisting of proxy and remote object
EJB Proxy Pattern consisting of proxy and remote object
A design pattern describes a solution to a problem that occurs over and over again when designing object-oriented computer systems.
The following SlideShow 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.)


1) The client invokes getBalance() on the stub
2) The stub marshals the method call into the appropriate wire format message and sends it across the network to the remote object's skeleton.
3) The skeleton listens on the network for messages. When the message arrives, the skeleton un-marshals it.
4) The skeleton invokes the getBalance() method of the remote object.
5) Remote object processes the call to getBalance() and returns the balance
6) Return value is marshalled by the skeleton and returned to the stub
7) The stub un-marshals the return and passes it back to the client.

EJB Proxy Pattern
  1. Proxy pattern: A pattern for implementing access to remote objects that provides a local object having the same interface as the remote object.
  2. Network address: The information that is required to access the skeleton of a remote object somewhere on a remote host.
  3. Design pattern: A generalized solution to a common frequently occurring object oriented design problem.
In the next lesson I will discuss the two aspects of a remote object:
  1. business logic and
  2. system services.