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

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.

In this series

• SOA Pattern of the Week (#1): Service Façade
• SOA Pattern of the Week (#2): Non-Agnostic Context
• SOA Pattern of the Week (#3): Domain Inventory
• SOA Pattern of the Week (#4): Service Normalization
• SOA Pattern of the Week (#5): Service Decomposition

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.

Sign up for ITworld's Daily newsletter
Follow ITworld on Twitter @IT_world

• Email
• Print
• Share
  • Slashdot
  • Digg
  • Stumble
  • Reddit
  • Newsvine