Capability Composition

How can a service capability be used to solve a problem that requires logic outside of the service boundary?

Problem The service logic encapsulated by a capability may not be able to fulfill all of the capabilityÕs requirements. Adding the outstanding logic to the service will compromise the integrity of its context and risk service denormalization.
Solution The capability logic composes capabilities from 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

Table 7.7 – Profile summary for the Capability Composition pattern.

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

If, to carry out the logic within a service capability, it is required that the capability execute logic outside of the serviceÕs functional boundary, then that is only carried out through the invocation and composition of a capability within whatever service is responsible for that functional boundary.

Figure 7.25 –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 service autonomy is reduced due to the fact that its capability is dependent on another service. 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 (which is why this pattern has a close relationship with Agnostic Capability).

However, the Capability Composition pattern does more than just enable service aggregation. It ensures that the key Service Normalization and Logic Centralization design patterns are fully supported by requiring external service invocation through service boundary enforcement.

It is also important that this pattern be viewed as a step toward what services and their supporting architectures must ultimately realize: Capability Recomposition.

Figure 7.26 – The Capability Composition pattern represents the ability for services to be composed, but not necessarily repeatedly.

Case study example

Case study content is not available on this Web site.