Decomposed Capability

How can a service be designed to minimize the chances of capability logic deconstruction?

Problem The decomposition of a service subsequent to its implementation can require the deconstruction of logic within capabilities, which can make the preservation of a service contract problematic.
Solution Services prone to future decomposition can be equipped with a series of granular capabilities that more easily facilitate decomposition.
Application Additional service modeling is carried out to define granular, more easily distributed capabilities.	Impacts Until the service is eventually decomposed, it may be represented by a bloated contract that stays with it as long as proxy capabilities are supported.
Principles Standardized Service Contract, Service Abstraction	Architecture Service

Table 8.4 – Profile summary for the Decomposed Capability pattern.

Problem

Some types of services are more prone to being split into two or more services after they have been developed and deployed. For example, entity services derive their functional context from corresponding business entities that are documented as part of common information architecture specifications. Often, an entity service context will initially be based around a larger, more significant business entity or even a group of related entities.

This can be adequate for immediate purposes, but can eventually result in a number of challenges, including:

•     As the service is extended, many additional capabilities are added because they are all associated with its functional context, leading to a bulky functional boundary that is difficult to govern.

•     The service, due to increased popularity as a result of increased capabilities or because of high reuse of individual capabilities, becomes a processing bottleneck.

Despite a foreknowledge of these challenges, it may still not be possible to create a larger group of more granular services due to infrastructure constraints that restrict the size of potential service compositions. Sometimes an organization needs to wait until its infrastructure is upgraded or its vendor runtime platform matures to the point that it can support complex compositions with numerous composition members. In the meantime, however, the organization cannot afford to postpone the delivery of its services.

Figure 8.11 – An Invoice entity service derived from a group of Invoice-related business entities (left) exposes coarse grained capabilities that are difficult to decompose when service decomposition requirements present themselves. Each of the affected Invoice service capabilities needs to be split up in order to accommodate the new services.

Solution

Services can be initially designed with future decomposition requirements in mind, which generally translates into the creation of more granular capabilities that better correspond to individual business entities.

This way, if the service needs to be decomposed in the future into a collection of services that represent individual business entities, the transition is facilitated by reducing the need to deconstruct capabilities.

Figure 8.12 – The Invoice service derived from the same business entities contexts exposes a series of more granular capabilities, several of which correspond to specific business entities. This increases the ease at which subsequent service composition can be accomplished.

Application

This pattern introduces more up-front service modeling effort in order to determine the appropriate service capability definitions. Specifically, the following considerations need to be taken into account:

•     how the current functional scope could potentially be divided into two or more functional contexts

•     how capabilities can be defined for these new functional contexts

This modeling effort follows a process whereby a collection of service candidates are defined in association with the scope of the service in question. These service candidates represent future services that could result from a decomposition of the current service, and therefore provide a basis for capability candidates to be defined in support of the decomposition.

Impacts

The initial service contract that results from applying this pattern can be large and difficult to use. The increased capability granularity can impose performance overhead on service consumers that may be required to invoke the service multiple times to carry out a series of granular functions that could have been grouped together in a coarse-grained capability. This may lead to the need to apply the Contract Denormalization pattern, which will result in even more capabilities.

Even after the service has been decomposed, the existing consumers of the initial service may still need to be accommodated via proxy capabilities (as per the Proxy Capability pattern) requiring the original service contract to remain for an indefinite period of time.

Relationships

The key relationship illustrated in Figure 8.x is between Decomposed Capability and Service Decomposition, because this pattern is applied in advance, with the foreknowledge that a service may need to be decomposed in the future. It can therefore also be viewed as a governance pattern in that its purpose is to minimize the impact of a serviceÕs evolution. For this same reason, it relates to the Proxy Capability pattern that will very likely end up being applied to one or more of the capabilities decomposed by this pattern.

As already mentioned, the more fine-grained capabilities introduced by this pattern may require may require that the Contract Denormalization pattern also be applied.

Figure 8.13 –Decomposed Capability prepares a service contract for eventual decomposition, making it closely related to patterns associated with Service Decomposition.

Case Study Example

Case study content is not available on this Web site.