Home > Articles > Web Services > SOA

SOA Design Patterns: Capability Composition Patterns

📄 Contents

  1. Capability Composition
  2. Capability Recomposition
  • Print
  • + Share This
Capability composition patterns build upon the service identification and definition patterns to establish the concept of service composition. Thomas Erl discusses this pattern in this chapter.
This chapter is from the Rough Cut version of 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.


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.


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.


The functionality encapsulated by a capability includes logic that can invoke other capabilities from other services.


Carrying out composition logic requires external invocation, which adds performance overhead and decreases service autonomy.




Inventory, Composition, Service


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.


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.


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).


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.


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.

  • + Share This
  • 🔖 Save To Your Account