Home > Articles > Web Services > SOA

  • Print
  • + Share This
This chapter is from the book

This chapter is from the book

Proxy Capability

How can a service subject to decomposition continue to support consumers affected by the decomposition?

Table 16.6. Profile summary for the Proxy Capability pattern.


If an established service needs to be decomposed into multiple services, its contract and its existing consumers can be impacted.


The original service contract is preserved, even if underlying capability logic is separated, by turning the established capability definition into a proxy.


Façade logic needs to be introduced to relay requests and responses between the proxy and newly located capabilities.


The practical solution provided by this pattern results in a measure of service denormalization.


Service Loose Coupling




As per Service Decomposition (489), it is sometimes deemed necessary to further decompose a service's functional boundary into two or more functional boundaries, essentially establishing new services within the overall inventory. This can clearly impact existing service consumers who have already formed dependencies on the established service contract (Figure 16.17).

Figure 16.17

Figure 16.17 Moving a service capability that is part of an established service contract will predictably impact existing service consumers.


Capabilities affected by the decomposition are preserved, while those same capabilities are still allowed to become part of new services. Although the service's original functional context is changed and its official functional boundary is reduced, it continues to provide capabilities that no longer belong within its context or boundary. These are proxy capabilities that are preserved (often for a limited period of time) to reduce the impact of the decomposition on the service inventory (Figure 16.18).

Figure 16.18

Figure 16.18 By preserving the existing capability and allowing it to act as a proxy for the relocated capability logic, existing consumers will be less impacted.

This does not prevent the capabilities in the new services from being independently accessed. In fact, access to the capability logic via its new service contract is encouraged so as to minimize the eventual effort for proxy capabilities to be phased out.


Proxy Capability relies on the application of Service Façade (333) in that a façade is established to preserve affected service capabilities. The only difference is that instead of calling capability logic that is still part of the same service, the façade calls capabilities that are now part of new services (Figure 16.19).

Figure 16.19

Figure 16.19 When an existing consumer requests an Invoice service operation that has been moved due to the decomposition of the service (1), a newly added façade component relays the request to the capability's new location (2), in this case the Invoice Reporting service.


Although the application of this pattern extends the longevity of service contracts while allowing for the creative decomposition of service logic, it does introduce a measure of service denormalization that runs contrary to the goals of Service Normalization (131).

Proxy capabilities need to be clearly tagged with metadata communicating the fact that they no longer represent the official endpoint for their respective logic to avoid having consumers inadvertently bind to them.

Furthermore, this pattern alone does not guarantee that a proxy capability will continue to provide the same behavior and reliability of the original capability it replaced.


Whereas Distributed Capability (510) prepares a service for the eventual application of Service Decomposition (489), Proxy Capability actually implements the decomposition while preserving the original service contract.

This is supported by Decoupled Contract (401), which allows the contracts of both the original and the decomposed services to be individually customized in support of the proxy capability. Service Façade (333) also plays an integral role in that it can be used to relay requests (act as the proxy) to and from the newly decomposed service.

And as previously mentioned, this pattern does end up going against the goals of Service Normalization (131). From an endpoint perspective especially, this pattern introduces the appearance of redundant functionality, a trade-off that is accepted in support of service evolution.

Figure 16.20

Figure 16.20 Proxy Capability alters the structure of a service in support of the creation of a new service and therefore touches several patterns related to service logic structure and the service decomposition process.

  • + Share This
  • 🔖 Save To Your Account