How
can services be designed to avoid data model transformation?
|
Problem
Services with disparate
models for similar data impose transformation requirements that increase
development effort, design complexity, and runtime performance overhead.
|
|
Solution
Data models for common
information sets are standardized across service contracts within an
inventory boundary.
|
|
Application
Design standards are
applied to schemas used by service contracts as part of a formal design
process.
|
Impacts
Maintaining the
standardization of contract schemas can introduce significant governance
effort and can introduce cultural challenges.
|
|
Principles
Standardized Service Contract
|
Architecture
Inventory,
Service
|
Table 5.11 – Profile summary for the Canonical Data Model pattern.
Problem
For a service to send or receive data, it needs to know in
advance exactly how that data will be organized and structured. For example, a
business document such as an invoice can have its own data model structure that
determines how invoice information is organized, what the different parts of an
invoice document are called, and what data types and validation constraints
should be associated with these parts.
When different services are delivered by different project
teams, each team may decide to structure an invoice data model in a different
way. When those services need to exchange invoice data at a later point in
time, they will not be compatible and will require Data Model Transformation to
convert one invoice document structure into another.
This generally introduces the need to design and develop a
custom transformation layer consisting of logic that maps one schema to
another. This logic is implemented as part of the service hosting environment
and carries out its transformation every time data needs to be
exchanged via the affected service capabilities, and is therefore considered
undesirable.
Solution
The need for Data Model Transformation can be avoided by
ensuring that service contracts are designed with compatible schemas from the
beginning. This is achieved by applying data design standards to the data
models within service contracts.
Figure 5.47 – Multiple services implemented as Web
services have standardized XML schema definitions as a result of applying this
pattern.
Application
The Canonical Data Model pattern is commonly applied to
services implemented as Web services because this allows for data models to be defined
using the industry standard XML schema expression syntax. In this case, XML
schema definitions representing the same documents or information sets need to
be kept in alignment so that complex and simple data types remain in synch
across different service contracts.
Once standardized schema definitions are in place, this
pattern is realized via a formal process through which service contracts are
designed (such as the service-oriented design process described at
SOAMethodology.com). It is through such a process that the related
service-orientation design principle of Standardized Service Contracts can be
consistently applied.
Impacts
In larger enterprises, the scope of data model
standardization may need to be limited to individual domains so as to make the
standardization effort and the subsequent governance responsibilities more
manageable. In fact, it is the considerations raised by this pattern that often
motivates organizations to apply Domain Inventory over the Enterprise Inventory
pattern.
Relationships
By establishing an key design standard in support of service
interoperability, Canonical Data Model directly supports Service Recomposition
and forms several close relationships with other patterns, such as Schema
Centralization and Canonical Protocol.
Data models are typically standardized within the boundaries
of inventories defined by Enterprise Inventory or Domain Inventory patterns,
resulting in a healthy inventory architecture will little need for the Data
Model Transformation pattern.
Figure 5.48 – The Canonical Data Model pattern achieves
an important type of standardization that is fundamental to inventory
architectures.
Case Study Example
Case study content is not available on this Web site.
