How can a service preserve its functional context
while also fulfilling special capability processing requirements?
|
Problem
A capability that belongs
within a service may have unique processing requirements that cannot be
accommodated by the default service implementation, but separating capability
logic from the service will compromise the integrity of the service context.
|
|
Solution
The underlying service
logic is distributed, thereby allowing the implementation logic for a
capability with unique processing requirements to be physically separated,
while continuing to be represented by the same service contract.
|
|
Application
The logic is moved and then
represented by a service faade, much like a Proxy Capability.
|
Impacts
The distribution of a
capabilitys logic leads to performance overhead associated with remote
communication and the need for a separate faade component.
|
|
Principles
Standardized Service Contract,
Service Autonomy
|
Architecture
Service
|
Table 8.7 – Profile summary for the Distributed Capability pattern.
Problem
Each capability within a services functional context
represents a body of processing logic. When a service exists in a physically
implemented form, its surrounding environment may not be capable of fully
supporting all of the processing requirements of all associated capabilities.
For example, a capability may have unique performance,
security, availability, or reliability requirements that can only be fulfilled
through special architectural extensions or a unique hosting environment. Other
times, it is the increased processing demands on a single capability that can
tax the overall service implementation to such an extent that it compromises
the performance and reliability of other service capabilities.
The logic supporting such a capability can be split off into
its own implementation. However, this would result in a separate service that
would break the original functional context for which the service was modeled.
Figure 8.21 – The Report operation of the Invoice Web
service has high concurrent usage and long response periods for some types of
reports. These factors regularly lock up server resources and therefore
compromise the performance and reliability of other service operations.
Solution
Capability logic with special processing requirements is
distributed to a physically remote environment. A service faade is used to
interact with local and distributed service logic on behalf of a single service
contract (Figure 8.x).
Figure 8.22 – The logic for the Report operation is
relocated to a separate physical environment. The faade component interacts
with the reporting logic on behalf of the Invoice service contract.
Application
As explained previously, the application of this pattern
consists of the creation of a faade component that acts as the controller of a
component composition. The component(s) representing the distributed capability
logic interact with the faade logic via remote access.
Performance requirements can be somewhat streamlined by
embedding additional processing logic within the faade so that it does more
than just relay request and response message values. For example, the faade
can contain routines that further parse and extract data from an incoming
request message so that only the information absolutely required by the
distributed capability logic is transmitted.
An alternative to using service faades is to develop
service agents (as per the Service Agent pattern) to intercept request messages
for a specific service capability. The agents can carry out the validation that
exists within the corresponding contract (or perhaps this validation is
deferred to the capability logic itself) and then simply route the request
message directly to the capability. These same agents can process the outgoing
response messages from the capability as well.
Impacts
This pattern preserves the purity of a services functional
context at the cost of imposing performance overhead. The positioning of the
contract as the sole access point for two or more implementations of service
logic introduces an increased likelihood of remote access whenever the service
is invoked.
If the capability logic was separated to guarantee a certain
response time during high volume usage, then this may be somewhat undermined by
the remote access requirements. On the other hand, overall service autonomy
tends to be positively impacted as the autonomy level of the separated
capability logic is usually improved as a result of its separation.
Relationships
When structuring a service to support distributed capability
processing, the service implementation itself exists like a mini-composition,
whereby a faade component takes on the role of both component controller and
single access point for the distributed service logic. This is why this pattern
has such a strong reliance on the Service Faade pattern and why it is
supported by the Decoupled Contract pattern in particular.
The Contract Centralization pattern is also an essential
part of the service design because it ensures that the contract will remain the
sole access point, regardless of the extent the underlying logic may need to be
distributed.
When a distributed capability needs to share access to
service-related data, the Service Data Replication pattern can be employed to
help facilitate this access without the need to introduce intra-service data
sharing issues.
Additionally, this pattern is often the result of applying
Service Refactoring, and can therefore be considered a continuation a
refactoring effort (especially when applied after the services initial
deployment).
Figure 8.23 – The Distributed Capability pattern
supports the internal decomposition of service logic and therefore has
relationships with both service logic and contract-related patterns.
Case Study Example
Case study content is not available on this Web site.
