Decoupled Contract

How can a service express its capabilities independently of its implementation?

Problem For a service to be positioned as an effective enterprise resource, it must be equipped with a technical contract that exists independently from its implementation yet still in alignment with other services.
Solution The service contract is physically decoupled from its implementation.
Application A serviceÕs technical interface is physically separated and subject to service-orientation design principles.	Impacts Service functionality is limited to the feature-set of the decoupled contract medium.
Principles Standardized Service Contract, Service Loose Coupling	Architecture Service

Table 8.5 – Profile summary for the Decoupled Contract pattern.

Problem

Services can be built using available distributed development technologies. This includes proprietary technologies, such as .NET programming languages, as well as more open development frameworks, such as Java. Both of these development environments provide adequate platforms for building components as services (Figure 8.x).

 Figure 8.14 – A component designed as a service, exposing an official service contract.

However, they usually require that the technical contract be physically bound to the underlying service logic. This essentially requires that the service contract be expressed via the same native technologies used to build the components. This, inhibits the utilization and evolution of the service because it can only be used by consumer programs compatible with its technology. Although technology transformation products are available, this limitation generally results in a reduced number of potential service consumers, which translates into reduced reuse potential.

Furthermore, requiring that consumers be bound to a native implementation technology results in a negative form of coupling (known as technology coupling) that establishes direct dependencies on the continued existence of that technology. Should the service owner ever want to upgrade or replace the underlying logic with logic built using a different development platform, it would very difficult to accomplish without effectively breaking all existing consumer dependencies.

Figure 8.15 – Because service consumers are required to couple themselves to a service contract that is itself coupled to the native component technology, the consumers become technology coupled.

Solution

The service contract is created as a physically separate part of the overall service implementation. This decouples the contract from the underlying service implementation, allowing it to be independently designed and governed.

Figure 8.16 – By decoupling the service contract (the official endpoint of the service) from its underlying implementation, the service implementation can be evolved without directly impacting service consumers. This can increase the amount of refactoring opportunities and the range of potential consumer programs (and corresponding reuse).

Application

Web services represent the most popular means of applying this design pattern, as they force the service contract to be expressed in separate description documents using industry standard meta languages.

Service inventories based on the use of contracts that support industry standards are considered to have the greatest freedom for long-term governance and vendor diversification. Therefore, the use of Web services is recommended as long as the underlying runtime platforms are deemed sufficiently mature to support the range of processing logic required by all service capabilities and any potential composition configurations in which they may need to take part.

Figure 8.17 – The decoupling of a contract from its implementation technology is most commonly realized by delivering the service as a Web service. This introduces the need to formally define the functional expression and data representation parts of the service contract via WSDL and XML Schema  (and optional WS-Policy) definitions.

A common risk associated with expressing service contracts using Web service technologies is the established approach of auto-generating Web service contract description documents (WSDL, XML Schema, and WS-Policy definitions) via modern development tools. This technique can result implementation coupling, a negative coupling type whereby contracts express implementation details, such as physical data models or proprietary component method parameters.

Consumer programs that then bind to these types of service contracts form design-time dependencies on their physical implementation details. When the underlying service implementation is required to change, all existing service consumers are immediately affected. This inflexibility can paralyze the evolution of a service and introduce the requirement for multiple, premature service versions.

Figure 8.18 – An example of how implementation coupling of the service contract can propagate implementation coupling to service consumers.

The Service Loose Coupling design principle addresses this issue by advocating the independent creation of a service contract so that the contractÕs content can also remain decoupled from any existing or future logic and resources it may be required to encapsulate. This further allows the contract to be shaped according to existing design standards (as per the Standardized Service Contract principle) and establishes it as an endpoint into service logic freed from ties to underlying implementation details.

Figure 8.19 – Revisiting the previous example, if the service contract can be kept free of implementation details, consumers can avoid binding to them.

The strategic significance of this design pattern in combination with the Service Loose Coupling and Standardized Service Contract principles is in the long-term use of the service by consumers that by forming positive dependencies on the decoupled contract are freed from evolutionary changes to the implementation.

Impacts

When decoupled contracts are employed, the service and its consumers will be tied to any limitations associated with the maturity of the vendor platformÕs support for relevant contract and related communications technologies. Deficiencies within the contract technology platform can inhibit the utilization of the service. Standardizing on a technology decoupled contract design can then impose any deficiencies on the service inventory as a whole.

Relationships

The Decoupled Contract pattern is fundamental to many design techniques that revolve around the use of Web services or directly benefit from the existence of a physically separate service contract.

Patterns associated with the post-implementation augmentation of service contracts (such as Service Decomposition, Proxy Capability, Distributed Capability, and Contract Denormalization) all can be more effectively applied to a service with a decoupled contract.

Contract Centralization and Service Refactoring benefit tremendously from this pattern due to the independence it achieves between contract and implementation. The Service Fa¨ade pattern is often applied to add another level of abstraction between core service logic and the decoupled contract and these two patterns furthermore enable the realization of Concurrent Contracts.

Finally, the fact that this pattern can avoid negative technology coupling fully supports the Vendor-Agnostic Context pattern in its goal to avoid proprietary dependencies.

Figure 8.20 – The Decoupled Contract pattern establishes an important separation of logic, technology, and technical interface that can be leveraged by many other design patterns.

Case Study Example

Case study content is not available on this Web site.