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 previously explained service identification and definition patterns (Figure 17.1).
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 becomes a natural part of service design.
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 17.2).
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 a new capability (not as part of the existing capability). The new capability may or may not form the basis of a new service.
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 represents an important design dynamic within service compositions that the application of the Service Autonomy design principle helps prepare a service for.
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 (131) and Logic Centralization (136) are fully supported by requiring external service invocation through service boundary enforcement.
It is further important that this pattern be viewed as a step toward what services and their supporting architectures must ultimately realize: Capability Recomposition (526).
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 17.4.
Figure 17.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.
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.
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 17.5).
Figure 17.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.
Though fundamental, this is a pattern very much dependent on others in that it builds upon and leverages many of the patterns in this book. In fact, the extent to which Capability Recomposition can be realized is dependent on the extent to which other SOA 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 (521)? 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 (521).
It is worth noting that the Service Composability design principle is dedicated to supporting the goals of 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.
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.
Many patterns in this book support 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.
