Use this pattern to provide maximum decoupling between service requesters and service providers by introducing an additional level of indirection to the service.
In its most basic form the Service Proxy pattern hides the true location of a service implementation. The pattern is also of particular value in providing a management point for access control, request tracking, and auditing.
The client must call an operation on a service. The client must not access the service directly, because the address of the endpoint at which the service is located might change or the actual endpoint address might change. The actual endpoint address is hidden so that access to the service can be controlled.
How to make services available to clients in a controlled manner without exposing the actual address of the endpoint at which the service is located.
Use this pattern when:
When services are exposed beyond organizational, or departmental boundaries, issues, such as security, maintenance of audit trails, reliability, quality of service, and communications compatibility must be considered.
It is desirable to retain the flexibility of service deployment. For example, being able to move the service to a different server without impacting any clients of that service by making it seem that the address of the service endpoint has not changed.
The protocol bindings that are supported by the service might not be appropriate for a particular set of clients. One solution is to modify the service so that it supports the required protocols, but in many cases this solution might not be desirable or possible.
You might want to hide the true location of the service so that all clients must access it indirectly through a specific control point. Hiding the true location of the service allows audit capabilities or additional client authentication checks to be added.
The target service is hidden by deploying an enterprise service bus (ESB) mediation that implements the same interface. This mediation acts as a virtual service, or proxy, that redirects all requests to the real service provider. Clients see only the virtual service, which seems to be the actual provider of the service.
In some cases the virtual service might support a different set of protocol bindings to those bindings that are supported by the real service, therefore providing the necessary protocol conversion as part of the mediation.
In its most simple form, the mediation redirects each request to a preconfigured endpoint address. A more flexible approach uses a query to a service registry to determine the actual address, caching this value for use with subsequent requests.
The virtual service, or mediation, implements a number of additional features. In a typical implementation the mediation logs each request for audit purposes. The virtual service might also provide an additional level of access control, checking the credentials that are associated with each incoming request. A more sophisticated implementation might also provide identity mapping between different security domains.