Return to Home Page
Overview
    History
    Acknowledgements
    Podcasts
    Notification Form
    Feedback Form
    Press Release #1
    Press Release #2
    Press Release #3

Master SOA Design
Pattern Catalog
    Master Pattern List (alphabetical)
    Master Pattern List (by category)
    Master Pattern List with
Page Numbers (PDF)
    Master Pattern List (Text)
    Pattern Notation
    Pattern Profiles
    Symbol Legend
    Pattern Contribution Form

SOA Candidate Patterns
    SOA Patterns Review Committee
    Candidate Patterns Overview
    Candidate Patterns List
    Candidate Pattern Contribution Form
    Candidate Pattern
Feedback Form
    SOA Pattern Template

Design Pattern Basics
    What's a Design Pattern?
    What's a Design Pattern Language?
    What's a Compound Pattern?

Supplemental
    SOA Patterns and Application Technologies
    SOA Design Patterns Historical Influences
    SOA Design Patterns and Design Principles
    SOA Design Patterns and Design Granularity
    Legal

Resources
    Design Patterns Publications
    Reference Posters
    SOAPrinciples.com
    WhatIsSOA.com
    SOA Visio Stencil


Data Model Transformation (Erl)


Home > Transformation Patterns > 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




An XSLT style sheet containing data model mapping logic (2) is added as a form of intermediary processing that is executed at runtime. With each transmission, the data model of the claims document is converted from the schema used by the Process Claims service (1) to the data model compliant with the schema used by the Claims service (3). This runtime transformation logic can reside with either service architecture or as part of a separate middleware platform.


Related Patterns in This Catalog

Canonical Resources (Erl), Canonical Schema (Erl), Capability Recomposition (Erl), Data Format Transformation (Erl), Domain Inventory (Erl), Inventory Endpoint (Erl), Legacy Wrapper (Erl, Roy), Multi-Channel Endpoint (Roy), Protocol Bridging (Little, Rischbeck, Simon), Rules Centralization (Erl), Service Agent (Erl)


Related Patterns in Other Catalogs

Message Translator (Hohpe, Woolfe)


Related Service-Oriented Computing Goals

Increased Vendor Diversification Options, Reduced IT Burden

SOA Design Patterns This page contains excerpts from:

SOA Design Patterns by Thomas Erl

Foreword by Grady Booch

With contributions from David Chappell, Jason Hogg, Anish Karmarkar, Mark Little, David Orchard, Satadru Roy,
Thomas Rischbeck, Arnaud Simon, Clemens Utschig, Dennis Wisnosky, and others.

(ISBN: 0136135161, Hardcover, Full-Color, 400+ Illustrations, 865 pages)

For more information about this book, visit
www.soabooks.com.
The Prentice Hall Service-Oriented Computing Series from Thomas Erl
Home    SOA Books    SOA Magazine    What is SOA?    SOA Principles    SOASchool.com    SOA Glossary Copyright © 2007-2009
SOA Systems Inc.