Proxy
Capability
How can a service subject to decomposition continue
to support consumers affected by the decomposition?
|
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 can be preserved, even if underlying capability logic is separated,
by turning the established capability definition into a proxy.
|
|
Application
Faade logic needs to be
introduced to relay requests and responses between the proxy and newly
located capabilities.
|
Impacts
This pattern results in
service contract-level denormalization.
|
|
Principles
Service Loose Coupling
|
Architecture
Service
|
Table 8.9 – Profile summary for the Proxy Capability
pattern.
Problem
As per the Service Decomposition pattern, it is sometimes
deemed necessary to further decompose a services 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 8.32 – 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 original services 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.
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.
Figure 8.33 – By preserving the existing capability and
allowing it to act as a proxy for the relocated capability logic, existing
consumers will be less impacted.
Application
Decomposing a service may be necessary when services are
being produced as part of agile (meet-in-the-middle) delivery processes, where
a top-down analysis is only partially completed prior to service development.
In this delivery strategy, the top-down process continues concurrent with
service delivery projects. There is a commitment to revising implemented
service designs after the top-down analysis progresses to a point where
necessary changes to the original service inventory are identified.
This pattern relies on the application of the Service Faade
pattern in that a faade is established to preserve affected service
capabilities. The only difference is that instead of calling capability logic
that has been distributed but is still part of the same service, the faade
calls capabilities that are now part of new services.
Figure 8.34 – A service logic component is added to the
Invoice Web service. It is essentially responsible for relaying requests and
responses between the Invoice Reporting services Report operation and the
consumer program that invoked the Invoice services Report operation.
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 contract denormalization
that can lead to some confusion.
Proxy capabilities need to be clearly tagged with metadata
communicating the fact that they no longer represent the official endpoint for
their respective logic.
Relationships
Whereas the Distributed Capability pattern prepares a
service for eventual decomposition (as per Service Decomposition and Service
Refactoring), the Proxy Capability pattern actually implements the
decomposition while preserving the original service contract.
This is supported by the use of the Decoupled Contract
pattern that allows the contracts of both the original and the decomposed
services to be individually customized in support of the proxy capability. The
Service Faade pattern also plays an integral role within the service that is
required to support the proxy capability, in that it must relay requests (act
as the proxy) to and from the newly decomposed service.
As with Contract Denormalization, Shared Data Replication
may be applied together with this pattern to establish replicated data sources
that both original and decomposed services can use.
Finally, it is interesting to note that while this pattern
helps a service change (as per Service Refactoring), it does end up going
against the goals of the Service Normalization pattern. 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 8.35 – The Proxy Capability pattern 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
Case study content is not available on this Web site.
