Patterns - 027: Structural patterns ( Remote Proxy )

sometimes a client object may not be able to access a service provider object (also referred to as a target object) by normal means. This could happen for a variety of reasons depending on:

• The location of the target object — The target object may be present in a different address space in the same or a different computer.
• The state of existence of the target object —The target object may not exist until it is actually needed to render a service or the object may be in a compressed form.
• Special Behavior —The target object may offer or deny services based on the access privileges of its client objects. Some service provider objects may need special consideration when used in a multithreaded environment.

In such cases, the Proxy pattern suggests using a separate object referred to as a proxy to provide a means for different client objects to access the target object in a normal, straightforward manner.

• The Proxy object offers the same interface as the target object.
• The Proxy object interacts with the target object on behalf of a client object and takes care of the specific details of communicating with the target object.
• A client can call the Proxy object through its interface and the Proxy object in turn forwards those calls to the target object.

Proxy

• – The client object cannot access the target object directly.
• – A proxy object provides access control to the target object (in the case of the protection proxy).
• – A proxy object does not add any additional functionality.
• – A Proxy object represents a single object. – The client object cannot access the target object directly.
• – A Proxy object provides access control to the single target object.
• – Client requests are first received by the Proxy object, but are never processed directly by the Proxy object.
• – Client requests are always forwarded to the target object.
• – Response to the request is guaranteed, provided the communication between the client and the server locations is working.

Example

In reality, when the client invokes a method such as saveCustomerData on the CustomerFacade remote object, the CustomerFacade_stub object, which is local to the client, first receives it. The CustomerFacade_stub then transmits the method call to the server for processing.

On the server side the CustomerFacade_skel is responsible for receiving the method call through the lower levels of the communication network. It then dispatches it to the actual CustomerFacade object on the server. In case of the saveCustomerData method, the CustomerFacade object creates the necessary subsystem objects and invokes the required methods on these objects to validate and save the customer data. The result of the processing is carried back to the client in the reverse manner.

As can be seen from above, the CustomerFacade_stub class enables the client object to invoke methods on the remote CustomerFacade object as if it is present locally, which, otherwise, is not accessible by normal means. Thus the stub functions as a remote proxy.