Service Normalization

How can an inventory be designed to avoid redundant service logic?

Table 5.5 – Profile summary for the Service Normalization pattern.

Problem

The boundary of a service is defined by its functional context and the collective boundaries of its capabilities. Even within a pre-defined inventory boundary, when services are delivered by multiple project teams there is a risk that some will provide functionality that will overlap with others.

This leads to a denormalization of the inventory, which can cause several problems, such as:

•       an inability to establish service capabilities as the official endpoints for bodies of agnostic logic

•       a more convoluted architecture wherein services with overlapping functionality can become out of synch, providing the same functions in different ways

Figure 5.22 – A service inventory containing services with overlapping functional boundaries that introduce denormalization.

Solution

Services are collectively modeled before their individual physical contracts are created. This provides the opportunity for each service boundary to be planned out so as to ensure that it does not overlap with other services. The result is a service inventory with a higher degree of functional normalization (Figure 5.x).

Figure 5.23 – When services are delivered with complementary and well-aligned boundaries, normalization across the inventory is attained.

Application

The goals of this pattern are best realized by pursuing service level autonomy (as associated with the Service Autonomy design principle). Service candidates can be modeled and revised through iterations of the service modeling process, allowing for their respective boundaries and functional contexts to be repeatedly refined and validated.

The definition of a service inventory blueprint is part of a top-down delivery effort, which provides the best opportunity for this pattern to be most effectively applied. (See SOAMethodology.com for details regarding top-down delivery.)

Impacts

The guarantee of inventory-wide normalization requires that all services be conceptually modeled prior to delivery, as part of an inventory service blueprint specification. Depending on the scope of the planned inventory, this can result in a separate analysis project that needs to be completed before any service can be actually built.

Relationships

The Service Normalization pattern lays the foundation for Contract Centralization by ensuring that no two services share the same functionality. This allows contracts to be positioned as the sole entry point into service logic and further enables those services to be independently evolved, as per the Service Refactoring pattern. The related Schema Centralization and Policy Centralization patterns further support this pattern by avoiding contract-related redundancy.

To successfully preserve a normalized inventory requires the consistent enforcement of the Logic Centralization pattern, making these two patterns very closely related.

Contract Denormalization is only referred in Figure 5.x to indicate that, despite its name, it does not interfere with the goals of this pattern. As explained in Chapter 8, the Proxy Capability pattern must violate this pattern out of necessity when services require post implementation decomposition.

Figure 5.24 – The Service Normalization pattern fundamentally organizes a service inventory but relies on the successful application of other patterns to retain this state.

Case Study Example

Case study content is not available on this Web site.