Data Model Transformation

How can services interoperate when using different data models for the same type of data?

Problem Services may use incompatible schemas to represent the same data, hindering service interaction and composition.
Solution A data transformation technology can be incorporated to convert data between disparate schema structures.
Application Mapping logic needs to be developed and deployed so that data compliant to one data model can be dynamically converted to comply to a different data model.	Impacts Data model transformation introduces development effort, design complexity, and runtime performance overhead, and overuse of this pattern can seriously inhibit service recomposition potential.
Principles Standardized Service Contract, Service Reusability, Service Composability	Architecture Inventory, Composition

Table 6.8 – Profile summary for the Data Model Transformation pattern.

Problem

For any service-enabled part of an enterprise where the Canonical Data Model pattern has not been successfully applied, services delivered as part of different projects run a high risk of representing similar data using different schemas.

This will typically not affect immediate service implementations, as the schemas may very well have been standardized across the initial solution or composition. However, when these same services need to be recomposed into new configurations, schema incompatibilities impose significant interoperability challenges.

Figure 6.38 – The Process Claims service represents a claim record using a different schema than the one required by the Claims service contract. This incompatibility prevents cross-service data exchange.

Solution

Data model transformation logic can be introduced to carry out the runtime conversion of data, so that data complying to one data model can be restructured to comply to a different data model. This extends a non-standardized messaging framework, enabling it to dynamically overcome disparity between the schemas used by a service contract and messages transmitted to that contract.

Figure 6.39 – Data model mapping logic is executed at runtime as part of the data exchange process, converting the structure of an XML document from the ProcessClaims schema to the Claims schema.

Application

Formalized data transformation is an established concept that dates back to the EAI era where data model incompatibilities were often resolved via broker services that existed as part of middleware platforms.

When services are implemented as Web services, XSLT is generally used to define the mapping logic that is subsequently executed to perform the transformation at runtime. In fact, the use of XSLT style sheets represents the most common application of this pattern.

Although data model transformation is a fundamental and essential part of most service-oriented architectures, it represents a pattern that is used only out of necessity. Many of the service contract patterns described in this book, in fact, result in a reduction or even an elimination of data transformation requirements. However, the realities of legacy encapsulation and common governance challenges usually introduce schema disparity that still must be dealt with.

This pattern solves an important problem, but it is equally important to be constantly aware of the fact that it is only applied when other patterns cannot be realized to their full potential. Due to the constant emphasis on Òtransformation avoidanceÓ throughout service-orientation, it is recommended to consider this pattern as a last resort.

Impacts

The use of this pattern has several predictably undesirable results:

•     The development of the mapping logic adds time and effort to the creation of service compositions.

•     The incorporation of data model transformation introduces design complexity into a service composition and the service inventory as a whole.

•     Data model transformation introduces a runtime layer wherein the execution of mapping logic adds performance overhead every time services with disparate schemas need to exchange data.

Relationships

Canonical Data Model has a well known Òtug-of-warÓ relationship with Data Model Transformation, in that this pattern generally needs to be applied to whatever extent Canonical Data Model cannot be applied.

When in use, it can help overcome disparity between services (as per Domain Inventory and Inventory Endpoint) and also between a service and the resources it encapsulates (as per Legacy Wrapper and Rules Centralization).

Although it provides important functionality, its overuse is an anti-pattern that can undermine the goals of Capability Recomposition.

Figure 6.40 – Perhaps the most common broker pattern used in composition architectures, Data Model Transformation has many ties to a diverse collection of patterns that are affected by its application.

Data Model Transformation is a core part of Broker and Enterprise Service Bus compound patterns (Figure 6.x) and also the only broker-related pattern that is associated as an optional extension of the Orchestration compound pattern (Figure 6.x).

Figure 6.41 – The Data Model Transformation pattern is one of three transformation-related design patterns that comprise the Broker and Enterprise Service Bus compound patterns (both of which are described in Chapter 9).

Figure 6.42 – The Data Model Transformation pattern is also one of the optional patterns associated with the Orchestration compound pattern (also covered in Chapter 9).

Case study example

Case study content is not availabe on this Web site.