Service Decomposition

How can the granularity of a service be increased subsequent to its implementation?

Problem Overly coarse-grained services can inhibit optimal composition design.
Solution A coarse-grained service can be decomposed into two or more fine-grained services.
Application The underlying service logic is restructured and new service contracts are established. The Proxy Capability pattern will likely be required to preserve the integrity of the original coarse-grained service contract.	Impacts An increase in fine-grained services naturally leads to larger, more complex service composition designs.
Principles Service Loose Coupling, Service Composability	Architecture Service

Table 8.11 – Profile summary for the Service Decomposition pattern.

Problem

When modeling services during the initial analysis phases, it is common to take practical considerations into account. For example, what may ideally be represented by a set of fine-grained business service candidates is later combined into a smaller number of coarse-grained services primarily due to performance and other infrastructure-related concerns (motivated by the need to keep service composition sizes under control).

After a service inventory architecture matures and more powerful and sophisticated technology and runtime products are incorporated, larger, more complex service compositions become a reality. When designing such compositions, it is generally preferable to keep the footprint of individual services as small as possible because only select service capabilities are required to automate the parent business task. However, when forced to work with overly coarse-grained services, composition designs are required to be less than optimal.

Figure 8.41 – An Invoice service with a functional context originally derived from three separate business entities ends up existing as a large software program with a correspondingly large footprint, regardless of which capability a composition may need to compose.

Solution

The coarse-grained service is decomposed into a set of fine-grained services that collectively represent the functional context of the original service but establish distinct functional contexts of their own.

Figure 8.42 – The original, coarse-grained Invoice service is decomposed into three separate services, one of which remains named ÒInvoiceÓ but only encapsulates a subset of the original capabilities.

Application

Carrying out this pattern essentially requires that the existing, coarse-grained service be broken apart and its logic reorganized into the new, finer-grained functional boundaries.

Therefore, the first step is usually to revisit the service inventory blueprint and decide how the service can be re-modeled into multiple service candidates. As part of this process, new capability candidates will also need to be defined, especially if the Decomposed Capability pattern was not taken into account during the serviceÕs original design.

After the modeling is completed, the new services are subject to the standard lifecycle phases, beginning with contract design (based on the modeled service candidates) and all the way through to final testing and quality assurance phases.

Unless it is decided to also retrofit previous consumer programs that formed dependencies on the original service, the Proxy Capability pattern will likely need to be applied to preserve the original service contract for backwards compatibility.

Figure 8.43 – The new, fine-grained services each provide less capabilities and therefore also impose smaller program sizes.

Impacts

The extent to which Service Decomposition can impact a service inventory depends on how established a service is and how many consumer programs have formed relationships to it. The more consumers involved, the more complicated and disruptive this pattern can be.

Because this pattern is commonly applied after an inventory architecture has matured, it is likely that it will introduce the risk of significant disruption. Its application therefore needs to be carefully planned and will usually require the additional, repeated application of the Proxy Capability pattern.

The preventative use of the Decomposed Capability pattern can ease the impact of Service Decomposition and will also result in a cleaner separation of functional service contexts.

Relationships

The Service Decomposition pattern introduces a solution comprised of a process by which service logic is partitioned in support of changing granularity and processing considerations. From a high level, this pattern helps further the goals of Business-Driven Context in that the motivation behind the decomposition of a service is often to better align the service logic with existing business models.

This pattern therefore has a series of relationships with other service-level patterns, most notably Service Refactoring. When a service is upgraded as a result of a refactoring effort, the application of Service Decomposition may very well be the means by which this is carried out.

As explained in the Proxy Capability pattern description, Service Decomposition relies on that pattern to implement the actual partitioning via the redevelopment effort required to turn one or more regular capabilities into proxies. As a result, this pattern shares several of the same patterns as Proxy Capability.

Service Decomposition is most frequently applied to agnostic services, therefore tying this pattern to Entity Abstraction and Utility Abstraction patterns. However, the result of this pattern can introduce a measure of service redundancy due to the need of the Proxy Capability pattern to violate Service Normalization to some extent.

One of the more interesting relationships involves the effects of Service Decomposition on Logic Centralization. Service Decomposition essentially establishes two entry points into the same body of logic in order to support existing and new service consumers. It therefore can oppose Logic Centralization but only to a certain extent - a service decomposition effort often includes establishing a new design standard that requires all future consumers to access the newly decomposed service. This can reduce or eliminate Logic Centralization concerns.

Figure 8.44 – The Service Decomposition pattern is a refactoring-related approach to splitting up service logic that ties into numerous patterns that shape service logic and contracts.

Case Study Example

Case study content is not available on this Web site.