Proxies

The Proxy Pattern is similar to the Decorator Pattern, although the terminology is a little different:

Note: In the original Proxy Pattern the proxy's subject is RealSubject, not the Subject interface. This means that proxies, unlike decorators, can't form chains.

Example: Client-Server Proxies

Proxies are often used in the context of client server applications to enhance an existing server. In this situation the Subject is the Server interface and the RealSubject is the actual server. Examples of proxies include cache, synchronization, security, and firewall proxies:

Here's a typical scenario:

Remote Proxies

Firewall and cache proxies typically run on the client's machine. These are called client-side proxies. Security and synchronization proxies are typically server-side proxies. To bridge the physical gap between client and server we can use remote proxies:

Here's a typical interaction, c can be a client or client-side proxy, s is a server or a server-side proxy:

Marshalling involves serializing a command or return value. This means turning it into a sequence of characters or bytes suitable for sending over a socket. This can be complicated because a command may involve parameters. The parameters can be complicated objects. An even tougher problem occurs if the client and server are implemented in different languages. For example, if the client is a Java program and the Server is written in C, then even the definition of int might be different. To make matters worse, the client generally doesn't know the implementation language of the server and vice-versa. This means translating requests and results into an agreed upon third language. This is the general idea behind IDL and DCOM.

Remote Method Invocation

Note that from c's perspective, contacting s appears to be done through an ordinary method call to the stub, which is indistinguishable from the server since it implements the same interface. This is called remote method invocation.