DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones AWS Cloud
by AWS Developer Relations
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones
AWS Cloud
by AWS Developer Relations
Securing Your Software Supply Chain with JFrog and Azure
Register Today

Trending

  • Step Into Serverless Computing
  • Send Email Using Spring Boot (SMTP Integration)
  • Integrate Cucumber in Playwright With Java
  • How AI Will Change Agile Project Management

Trending

  • Step Into Serverless Computing
  • Send Email Using Spring Boot (SMTP Integration)
  • Integrate Cucumber in Playwright With Java
  • How AI Will Change Agile Project Management
  1. DZone
  2. Data Engineering
  3. Big Data
  4. SOA Pattern of the Week (#6): Canonical Schema

SOA Pattern of the Week (#6): Canonical Schema

Masoud Kalali user avatar by
Masoud Kalali
·
May. 27, 09 · Interview
Like (0)
Save
Tweet
Share
7.68K Views

Join the DZone community and get the full member experience.

Join For Free

thomas erl ( soaschool.com) and herbjorn wilhelmsen , ( objectware ), bring you the fourth soa pattern of the week, a series comprised of original content and insights provided to you courtesy of the authors and contributors of the soapatterns.org community site and the book “soa design patterns."

the canonical schema pattern ensures that services are built with contracts capable of sharing business documents based on standardized data models (schemas). the application potential of canonical schema can become one of the fundamental influential factors that determine the scope and complexion of a service inventory architecture.

figure

of all the patterns in the soa design patterns catalog there is perhaps no other as simple to understand yet as difficult to apply in practice as canonical schema . there are also few patterns that spark as much debate. in fact, that application potential of canonical schema can become one of the fundamental influential factors that determine the scope and complexion of a service inventory architecture.

it all comes down to establishing baseline interoperability. the canonical schema pattern ensures that services are built with contracts capable of sharing business documents based on standardized data models (schemas). unlike the well-known pattern canonical data model (hohpe, woolf) which advocates that disparate applications be integrated to share data based on common data models, canonical schema requires that we build these common data models into our service contracts in advance. hence, the successful application of this pattern almost always requires that we establish and consistently enforce design standards.

but before we discuss the standardization of data models and all of the enjoyable things that come with trying to make this happen, let’s first take a step back and describe what we mean by “baseline interoperability.”

when services and service consumer programs interact, data is transmitted (usually in the form of messages) organized according to some structure and a set of rules. this structure and the associated rules constitute a formal representation (or model) of the data.

when different services are designed with different data models representing the same type of data, then they will have a problem sharing this data because the data models are simply incompatible. to address this problem, a technique called data model transformation is applied whereby data model mapping logic is developed so that data exchanged by such services is dynamically converted at runtime from compliance with one data model to another. so successful has this technique been that a corresponding data model transformation pattern was developed.

however, with data model transformation comes consequences. and with the overuse of data model transformation comes real problems pertaining to architectural complexity, increased development effort, and runtime performance demands that can impact larger service compositions to such an extent that if you press your ear close enough to your middleware you can actually hear the churning and grinding of this extra runtime latency.

these and other details and issues will be discussed separately during an upcoming series article dedicated to the data model transformation pattern. what’s important for us to understand for now is that the primary goal of applying canonical schema is for us to avoid having to apply data model transformation .

this brings us back to design standards and the scope of their application. establishing canonical schemas as part of services delivered by different project teams at different times requires that each project team agrees to use the same pre-defined data models for common business documents. this may sound like a simple requirement but something simple is not always easy. many organizations have historically struggled with the enforcement and governance of standardized data models – so much so that it has led to organizational power struggles, resentment of individuals at being “enforced”, and technical difficulties with large-scale compliance and change management (of the data models).

these are all reasons as to why the canonical schema pattern is very commonly applied together with domain inventory . limiting the application, enforcement, and governance of standardized data models to the confines of a manageably sized service inventory dramatically increases the potential to successfully realize the full potential of this pattern.

canonical schema epitomizes the transition from silo-based, integrated enterprises to service-orientation. it is a pattern that solves a big problem but asks in return that we make an equally big commitment to its on-going application.

cover

the soa pattern of the week series is comprised of original content and insights provided to you courtesy of the authors and contributors of the soapatterns.org community site and the book “soa design patterns” (erl et al., isbn: 0136135161, prentice hall, 2009), the latest title in the prentice hall service-oriented computing series from thomas erl ( www.soabooks.com ).

Schema Data (computing) Data model (GIS) SOA application

Opinions expressed by DZone contributors are their own.

Trending

  • Step Into Serverless Computing
  • Send Email Using Spring Boot (SMTP Integration)
  • Integrate Cucumber in Playwright With Java
  • How AI Will Change Agile Project Management

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com

Let's be friends: