This chapter is from the book
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.
|
Problem |
If an established service needs to be decomposed into multiple services, its contract and its existing consumers can be impacted. |
|
Solution |
The original service contract is preserved, even if underlying capability logic is separated, by turning the established capability definition into a proxy. |
|
Application |
Façade logic needs to be introduced to relay requests and responses between the proxy and newly located capabilities. |
|
Impacts |
The practical solution provided by this pattern results in a measure of service denormalization. |
|
Principles |
Service Loose Coupling |
|
Architecture |
Service |
Problem
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 Moving a service capability that is part of an established service contract will predictably impact existing service consumers.
Solution
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 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.
Application
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 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.
Impacts
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.
Relationships
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 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.
Case Study Example
In the case study example for Service Decomposition (489) we explained how the Alleywood team came to the decision to split their existing Employee service into separate Employee and Employee Record services.
To see this through, they need to find a way to achieve the following:
- Establish a new Employee Record service.
- Move the corresponding functionality from the Employee service to the new Employee Record service.
- Complete Steps 1 and 2 without changing the original Employee service contract so as to not impact existing service consumers.
To complete Step 1 they model the new Employee Record service, as shown in Figure 16.21.
)
Figure 16.21 After some analysis, the new Employee Record service candidate is modeled with four capability candidates.
To accomplish Steps 2 and 3 they employ Proxy Capability for each of the capabilities in the Employee service that needs to be moved to the Employee Record service. Figure 16.22 illustrates how two of the original Employee service capabilities map to four of the Employee Record service capabilities.
)
Figure 16.22 The Employee service's AddRecord and GetHistory capabilities are positioned as proxies for the Employee Record's Add, GetRecordReport, GetHoursReport, and GetEvalReport capabilities.
The Employee Record service is eventually designed and delivered as a fully functional, standalone service. However, the Employee service contract remains unchanged, plus additional logic is added in the form of a façade component. This functionality responds to requests for the original AddRecord and GetHistory capabilities and then relays those requests over to the Employee Record. The eventual responses are then received and passed back to the Employee service consumer.
However, one issue remains. In order for the GetHistory operation to work, it must make three calls to the Employee Record service (one to each of the three GetReport operations).
The team considers whether to add a corresponding GetHistory operation to the Employee Record service just for the proxy work that the Employee service must perform. But, they are concerned that the additional operation will be confusing to other consumers. They decide instead to try to accelerate the retirement of the Employee GetHistory operation.