Contract Centralization

How can direct consumer-to-implementation coupling be avoided?

Problem Consumer programs can be designed to access underlying service resources using different entry-points, resulting in different forms of implementation dependencies that undermine strategic SOA goals associated with loose coupling.
Solution Access to service logic is limited to the service contract, forcing consumers to avoid implementation coupling.
Application This pattern is realized through formal enterprise design standards and the targeted application of the Service Abstraction design principle.	Impacts Forcing consumer programs to access service capabilities and resources via a central contract can impose performance overhead and on-going standardization effort.
Principles Standardized Service Contract, Service Loose Coupling	Architecture Composition

Table 8.2 – Profile summary for the Contract Centralization pattern.

Problem

Even when services within an enterprise are deployed with published, standardized service contracts, those designing consumer programs can be tempted to look for alternative entry points into service logic. For example, it may be easier or more efficient to bypass the service contract and simply access its underlying database directly using native protocols.

Subsequently, the service contract loses its significance and the service ends up with numerous tight dependencies (usually in the form of integration channels) to various parts of its implementation. This inhibits the evolution and governance of the service and undermines many of the objectives of service-orientation.

Figure 8.5 – A service consumer program simply bypasses the service contract to access underlying logic directly.

Solution

The Contract Centralization pattern establishes as a design standard that positions the service contract as the sole entry point into service logic. This allows for a consistent form of loose coupling with all service consumer programs (Figure 8.x).

Figure 8.6 – Through contract centralization we place the service contract front and center within a service-oriented architecture. This is why much of service-orientation is focused on contract design.

Application

The application of this pattern establishes a distinction between the official published service contract and other parts of the service that can also be accessed via separate technical endpoints. For example, a consumer could interface with an underlying service component via that componentÕs API. This API still represents a technical contract, but not the ÒofficialÓ service entry point. This would therefore be considered a non-centralized form of service coupling.

If Contract Centralization is enforced to a meaningful extent, the service contract becomes a focal point for a great deal of interaction. From a long-term evolutionary perspective, therefore, Web services provide an effective means of establishing a service contract that can be customized and standardized, while remaining decoupled from the serviceÕs underlying environment, as per the Decoupled Contract pattern.

On the other hand, if the contract technology is proprietary or requires the use of proprietary communication protocols, then the consumer base is limited to those programs compatible with the proprietary requirements. In this case, the application of this pattern can result in a proliferation of technology coupling throughout an inventory.

Impacts

Integration architecture has a well-rooted history that predates the emergence of middleware and the EAI movement. Few of the past integration architectures were based on a concept like centralization and, more often than not, connections were made to whatever application entry points were the most convenient and efficient to fulfill immediate requirements.

Requiring architects, developers, project managers, and other team members to now forsake all of the options theyÕve had in the past in favor of a design standard that is being established for the long-term good of the enterprise can be difficult. Resistance to centralization is common and tactical requirements, such as time-to-market timelines and budget restrictions, can motivate some project teams to simply disregard the centralization standard altogether.

Furthermore, requiring that all service consumers access a body of logic through a single entry point can result in classic convergence performance issues, especially when having to reroute multiple existing integration channels to interface with a service contract. Contract Centralization needs to be expected and planned for, especially with agnostic services because they are subject to the greatest concurrency demands.

Relationships

By looking at the variety of relationships in Figure 8.x, it is evident how important the Contract Centralization pattern is to service-orientation. It is a part of establishing an effective endpoint layer within inventories and the repeated utilization of agnostic services (such as those based on Entity Abstraction and Utility Abstraction patterns) relies on the base requirement that they only be accessed via their contracts which, in turn, fully supports the long-term, independent governance of services subject to the Service Refactoring pattern.

Contract Centralization is responsible for positioning service contracts as a fundamental service access tier that can be further extended via complementary policy and schema layers (as per the Policy Abstraction and Schema Abstraction patterns).

It is important to acknowledge that the centralization of service contracts is supported (and often enabled) by the Decoupled Contract and Service Normalization patterns. Decoupled contracts can be much more easily centralized and separately positioned from underlying service implementations (as illustrated in the Loose Contract Coupling compound pattern in Chapter 9). The normalization of services further ensures that centralized contracts do not end up representing redundant logic.

One of the closest relationships illustrated in Figure 8.x is between Contract Centralization and Logic Centralization, as explored in the Official Endpoints compound pattern description in Chapter 9.

Figure 8.7 – The core Contract Centralization pattern is a lot like an enterprise design standard in that it regulates how services are accessed and therefore has relationships with both service logic and contract-related patterns.

Case Study Example

Case study content is not available on this Web site.