Legacy Wrapper

How can wrapper services with non-standard contracts be prevented from spreading indirect consumer-to-implementation coupling?

Problem Wrapper services required to encapsulate legacy logic are often forced to introduce a non-standard service contract with high technology coupling requirements, resulting in a proliferation of implementation coupling throughout all service consumer programs.
Solution The wrapper service can be further wrapped with a standardized service contract.
Application A custom service needs to be developed to represent the proprietary legacy interface.	Impacts An additional service adds a layer of processing and associated performance overhead.
Principles Standardized Service Contract, Service Loose Coupling, Service Abstraction	Architecture Service

Table 8.7 – Profile summary for the Legacy Wrapper pattern.

Problem

Legacy systems must often be encapsulated by services established by proprietary component APIs or Web service adapter products. The resulting technical interface is frequently fixed and non-customizable. Because the contract is pre-determined by the product vendor, it is not compliant with internal contract design standards.

Furthermore, the nature of API and Web service adapter contracts is often such that they contain embedded, implementation-specific (and sometimes technology-specific) details. This imposes the corresponding forms of implementation and technology coupling upon all service consumers.

Figure 8.24 – High contract-to-logic coupling resulting in high implementation coupling by service consumers.

Solution

Although a legacy system API and Web service adapter expose an official, generic entry point into legacy system logic, it is often unadvisable to classify such an endpoint as an official member of a service inventory. Instead, it can be safer to view these types of APIs and Web service adapters as extensions of a legacy environment providing just another proprietary interface that is available for service encapsulation.

This perspective allows for the creation of a standardized legacy wrapper service and/or encapsulation via capabilities residing in multiple services. Either way, all legacy capabilities are expressed in a standardized manner. The result is a design that allows for the full abstraction of proprietary legacy characteristics, which provides the freedom of evolving or replacing the legacy system with minimal impact on existing service consumers.

Figure 8.25 – Tight coupling of the service logic to both the legacy API and the service contract alleviates service consumers from implementation coupling.

Application

The standardized wrapper service (or capability) contains logic that performs transformation between the standardized contract and the native legacy interfaces.

It can be beneficial to establish a sole wrapper service for a legacy system so that all required transformation logic is centralized within that serviceÕs underlying logic. If capabilities from multiple services each access the native APIs or Web service adapter interfaces, the necessary transformation logic will need to be distributed (decentralized). If a point in time arrives where the legacy system is replaced with newer technology, it will impact multiple services.

Impacts

Adding a new wrapper layer introduces performance overhead associated with the additional service invocation and data transformation requirements.

Relationships

The Legacy Wrapper pattern makes legacy logic accessible on an inter-service basis. It can therefore be part of any service capability that requires legacy functionality. Entity and utility services are the most common candidates because they tend to encapsulate logic that represents either fixed business-centric boundaries or technology resources. Therefore, this pattern is often applied in conjunction with Entity Abstraction and Utility Abstraction patterns (or, in many cases, just a particular capability of an entity or utility service).

Patterns that produce new types of utility services (such as Rules Centralization and Security Centralization) also may end up having to rely on Legacy Wrapper for access to proprietary products or legacy application logic. The Service Data Replication pattern can be combined with Legacy Wrapper to provide access to replicated proprietary repositories.

Figure 8.26 – The Legacy Wrapper pattern provides a convenient means of bringing legacy logic into a service inventory without compromising the integrity of the service contracts. It therefore is of interest to any pattern that may require access to legacy resources.

Case Study Example

Case study content is not available on this Web site.