SOA Design Patterns: Capability Composition Patterns
This chapter is from the book
This chapter is from the book
This chapter is from the book
- Capability Composition
- Capability Recomposition
The patterns in this chapter provide the means by which to assemble and compose together the service logic that was successfully decomposed, partitioned, and streamlined via the service identification and definition patterns from Chapter 11 (Figure 16.1).
)
Figure 16.1 Capability composition patterns build upon the service identification and definition patterns to establish the concept of service composition.
These composition patterns essentially establish capabilities as the fundamental means by which service logic is aggregated to solve one or more larger problems. Studying these patterns reveals how composition logic can be a natural part of service design.
Capability Composition
How can a service capability solve a problem that requires logic outside of the service boundary?
Table 16.1. Profile summary for the Capability Composition pattern.
|
Problem A capability may not be able to fulfill its processing requirements without adding logic that resides outside of its service's functional context, thereby compromising the integrity of its context and risking service denormalization. |
|
|
Solution When requiring access to logic that falls outside of a service's boundary, capability logic within the service is designed to compose one or more capabilities in other services. |
|
|
Application The functionality encapsulated by a capability includes logic that can invoke other capabilities from other services. |
Impacts Carrying out composition logic requires external invocation, which adds performance overhead and decreases service autonomy. |
|
Principles All |
Architecture Inventory, Composition, Service |
Problem
Although the nature of a capability may be in alignment with a service's overall functional context, the logic required to carry out the capability may need to go beyond the designated service context boundary.
The service boundary could be increased, but this would change its original context and further introduces the danger of functional overlap and service denormalization because the expanded boundary could infringe on the functional boundaries of other services.
Solution
A service capability does not execute logic that resides outside of the service's functional boundary. Instead, it invokes the appropriate capability in a different service based on the appropriate functional boundary (Figure 16.2).
)
Figure 16.2 The individual capabilities of services can be aggregated to collectively help solve the large problem from which they were originally derived.
Application
This pattern is applied throughout a service delivery lifecycle. For example:
- During the service modeling phase composition candidates are assembled to define conceptual aggregates comprised of individually composed capability candidates.
- The service design process requires that the functional processing requirements of a service capability be analyzed so as to identify the potential involvement of capabilities.
- When in development, distributed invocation logic may need to be embedded within the capability routines, especially when required to access capabilities residing in other physical services.
Note that if an external body of logic is defined for which no service capability yet exists, then that logic needs to be created as part of the new capability (not as part of the existing capability).
Impacts
When capabilities are distributed across numerous services, some of which may reside in remote locations, cross-service capability invocation can impose measurable runtime performance overhead.
Also, the overall autonomy of a service is reduced due to the fact that its capability is dependent on another service. This eventuality is what the application of the Service Autonomy design principle helps prepare a service for and represents an important design dynamic within service compositions.
Furthermore requiring that a new capability be created when the required external logic does not exist can lead to unexpected scope increases in service delivery projects.
Relationships
Because service-oriented computing is a distributed computing platform, it is fully expected that a solution is comprised of parts that are aggregated together. However, Capability Composition does more than just enable service aggregation. It ensures that Service Normalization and Logic Centralization are fully supported by requiring external service invocation through service boundary enforcement.
As also shown in Figure 16.3, it is further important that this pattern be viewed as a step toward what services and their supporting architectures must ultimately realize: Capability Recomposition.
)
Figure 16.3 Capability Composition represents the ability for services to be composed, but not necessarily repeatedly.
Case Study Example
The segment of the Cutit Chain Inventory Transfer process that requires the creation of an inventory record and the cross-referencing of associated back orders could represent a body of logic that is always required with each newly created inventory record. Therefore, this query could be automatically carried out as part of the Inventory service's Add capability.
However, this pattern dictates that the Add capability only create an inventory record and nothing more. Issuing data queries against order information is outside of the capability's functional boundary and also beyond the parent service scope of inventory-related processing.
The ability for a back order query to be issued is already present within the Order service's GetBackOrders capability. Therefore, if the Inventory service's Add capability requires this functionality, it simply needs to invoke that capability via the Order service. Although this imposes performance requirements associated with multiple service invocation, it guarantees that no one service will functionally overlap with others.
The application of this pattern on a broader scale results in the assembly of all four services into a coordinated composition capable of automating the Chain Inventory Transfer business process, as shown in Figure 16.4.
)
Figure 16.4 The final composition of the services defined via the application of this pattern to all capabilities in support of the coordinated automation of the Chain Inventory Transfer process. Note composition step 3 representing the newly introduced feature of the Inventory service's Add capability to perform automatic back order checks.