Capability Recomposition

How can the same capability be used to help solve multiple problems?

Problem Using service logic to only solve a single problem is wasteful and does not leverage the logicÕs reuse potential.
Solution Agnostic service capabilities can be repeatedly invoked in support of multiple compositions that solve multiple problems.
Application Effective recomposition requires the coordinated, successful, and repeated application of several additional patterns.	Impacts Repeated service composition demands existing and persistent standardization and governance.
Principles All	Architecture Composition

Table 7.7 – Profile summary for the Capability Recomposition pattern.

Problem

A distributed solution can be comprised of services designed for a specific composition. This is often the case when collections of services are delivered by independent projects. Because these services are tuned to automate a particular business process, little consideration is given to their potential to solve other business problems.

As a result, other business problems get solved with new collections of services. This approach enables individual solutions to distribute logic in response to immediate concerns (such as special security and performance requirements), but does not foster reuse to any meaningful extent.

Typical effects associated with missing reuse opportunities arise, reminiscent of silo-based environments. For example, the proliferation of redundant logic, wasteful delivery projects, and an increasingly bloated enterprise.

Solution

A key fundamental pattern and one that is essential to the realization of most strategic service-oriented computing goals is that of Capability Recomposition. The successful application of this pattern allows agnostic logic to be repeatedly reused as part of different service aggregates assembled to solve different problems.

Figure 7.28 – The individual capabilities of the original services can be repeatedly aggregated together with additional capabilities into different composition configurations. This enables capabilities to collectively solve the large problem for which they were originally delivered in addition to several other problems.

Application

Though fundamental, this is very much a compound pattern in that it builds upon and leverages just about every other pattern documented in this chapter. In fact, the extent to which this pattern can be realized is dependent on the extent to which other patterns have been and will continue to be successfully applied.

So, whatÕs the difference between this design pattern and the repeated application of the Capability Composition pattern? For the logic encapsulated by a capability to be repeatedly composable, it must be design in such a manner that it can facilitate numerous scenarios and concurrent invocation. These are not requirements for realizing the base Capability Composition design pattern.

Impacts

Just as this pattern results in strategic benefits from the combined application of other patterns, it also inherits their collective challenges and complexities. Service composition itself represents a design technique that may impose a learning curve upon those responsible for solution design. It is comprised of a unique process that requires a combination of creativity and awareness of how services can be effectively combined within the constraints of the underlying architecture and infrastructure.

Furthermore, the importance of governing agnostic services is greatly amplified, as these represent the parts of a service inventory most prone to repeated composition. Performance, security, version control, and interaction requirements of each agnostic service can impact the design of any given service composition. Additionally, service ownership plays a key role in ensuring that agnostic services are properly evolved throughout participation in multiple compositions.

Relationships

One constant that you may notice across most patterns in this book is that each, to some extent, supports Capability Recomposition. This multitude of supportive relationships is key to understanding the dynamics behind service-orientation. Ultimately, the repeated composition of service capabilities is what leads to the attainment of several of the key strategic benefits and goals associated with service-oriented computing.

Figure 7.29 – In service-orientation, all paths lead to Capability Recomposition.

Case study example

Case study content is not available on this Web site.