This chapter is from the book
This chapter is from the book
This chapter is from the book
Capability Recomposition
How can the same capability be used to help solve multiple problems?
Table 16.2. Profile summary for the Capability Recomposition pattern.
|
Problem Using agnostic 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 designed to 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 Inventory, Composition, Service |
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, the outstanding 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 16.5).
)
Figure 16.5 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 a pattern very much dependent on others in that it builds upon and leverages many other patterns in this book. 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 Capability Composition? For the logic encapsulated by a capability to be repeatedly composable, it must be designed in such a manner that it can facilitate numerous scenarios and concurrent invocation. These are not requirements for realizing Capability Composition.
It is worth noting that the Service Composability design principle is dedicated to fully realizing this pattern. The design considerations raised by this principle help ensure that other service-orientation principles are sufficiently applied so that each service capability is prepared for recomposition.
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. Service ownership also plays a key role in ensuring that agnostic services are properly evolved throughout participation in multiple compositions.
Relationships
Many patterns in this book support Capability Recomposition. This multitude of supportive relationships is key to understanding the dynamics behind service-orientation (Figure 16.6). 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 16.6 Numerous patterns relate to and support Capability Recomposition.