Design Pattern: Proxy

Intention

• Access control for different clients

• Not all clients should be authorized to use the services of a component

• Widely applicable in almost every distributed system or infrastructure for distributed systems uses the pattern to represent remote components locally

• Client always seem to communicate "locally" and authorization is checked automatically

Introduction

• This pattern makes the clients of a component communicate with a representative rather than to the component itself

• Introduce a placeholder can enhanced efficiency(how ?)

• Easier access

• Protection from unauthorized access

Example

• Different clients need access to a remote server with similar information

• Need to access the same info for different clients

• Need to have control access

• Need optimization for access data

Context

• A client needs access to the services of another component. Direct access is technically possible, but may not be the best approach

Problem

• Inappropriate to access component directly

• Do not want to hard code physical location (e.g. TCPIP address)

• Need security / access control

• Accessing the component should be run-time-efficient, effective, and safe

• Access need to be transparent and simple for the clients

• Clients need to know the trade off between performance and transparency

Solution

• Use a representative (called Proxy) between the client and the component

• Offer interface of the component but performs additional pre and post-processing such as access-control, caching, logging, etc

Structure

• Original class implements a service (e.g. return data; display data, etc)

• Client class is responsible for a specific task. To do its job, it invokes the methods of Original in an indirect way by accessing the Proxy first

• Client call Proxy the same way as calling local doable service

• The Proxy class offers the same interface as the original, and ensures correct access to the Original

• Proxy keeps a list of Original reference

• Proxy to Original can be one-to-one or one-to-many

• The AbstractOriginal provides interface implemented by the Proxy and Original. Both Proxy and Original inherit from the AbstractOriginal. Client use the same interface. (Will it be better if we use interface for Proxy and Original instead ?)

• Let's look at the CRC cards:

General Scenario

Client need to do a task

Client calls the method of Proxy (send a service message)

Proxy internally do pre-processing such as mapping to Original

Proxy sends the real service message to Original

Result returned and Proxy do post-processing and return results back to Client

Implementation

• Identify all responsibilities for dealing with access control to a component

Remote Proxy: clients or remote components should be shielded from network addresses and inter-process communication protocols

Protection Proxy: Components under access control

Cache Proxy: Multiple clients share read-only results from remote components

Synchronization Proxy: Multiple simultaneous accesses to a component must be synchronized

Counting Proxy: Audit trail for component counts

Virtual Proxy: Shield the whole component but only provide the information as needed

Firewall Proxy: Protect local client from outside world

• Introduce abstract class or Java interface that specifies the common parts of the interfaces of both the proxy and the original

• Implement Proxy's functions using the rule of the first step

• Migrate methods from Clients and Original to Proxy

• Map the Proxy and the Original by giving the Proxy a handle to the Original: Could be a pointer, reference, socket, port, etc

• Remove all direct relationships between the original and its clients

Known Uses

• OMG-CORBA - Object Request Broker

• WWW Proxy

• MS OLE

• A lot of legacy remote database access application

Consequences

Advantages

• Enhanced efficiency and lower cost

• Decoupling clients from the location of remote server components

• Separation of housekeeping code from functionality

Disadvantages

• Less efficiency due to indirection

• Complex implementation