Challenges with the canonical schema design pattern

The canonical XML schema design pattern is a popular approach to solved application integration requirements.

The basic idea being that XML schemas/DTD are used to define a common data-model of objects and messages which are used to defined application-API independent service contracts.

While it is a great idea to use canonical XML schema, a few things need to be considered.

  1. Development Cost :- Defining and maintaining the common  data-model is a significant SOA Governance exercise.  Existing applications, future needs, industry trends need to analysed
  2. Versioning :- Change is inevitable. The canonical schema definition needs to undergo changes. There is a need to implement a versioning strategy for the canonical.
  3. Complexity :- Given two or more application data-models, coming up with a canonical data-model is a non trivial task. The problem lies in the fact that a data-model design (canonical or not) implicitly defines certain business rules and constraints. Thus when a canonical data-model needs to be created, along with the vocabulary / terms in the two data-models, the implicit business rules need to be reconciled. This requires extensive business process analysis.
  4. Usability :- When XML Schema is used to express the canonical data-model, a significant amount of the business process analysis that has gone into defining the data-model is typically lost.  For example, it is not straight-forward to express in XML schema something like “While a SalesOrder can have multiple Order-lines, System A can support only SalesOrders with a single Order-line, System B can support SalesOrders with upto 100 Order-lines but only 1 priority order-line per SalesOrder”. The canonical XML schema by definition needs to support the more generic use-case, SalesOrders with multiple Order-lines.  So when both System A and System B try to expose their service-contract for a CreateSalesOrderService using the common canonical SalesOrder XML Schema, the canonical does not express their respective service interfaces accurately.
  5. Run-time cost :- When a canonical XML schema is involved a request needs to be transformed first to a canonical format and then to the target provider’s format before being processed. Considering the performance overhead inherent in XML based processing – an additional transformation hop may make the canonical unviable for several high performance systems.
All these costs and issues with using the canonical approach need to be considered before using a canonical XML schema for integration. There would be situations where you are better-off to directly expose the service providers to consumers without putting a canonical XML schema based service contract layer on top of them.

About saratnathb

Building SOA solutions using Oracle Fusion Middleware technology stack.
This entry was posted in Uncategorized and tagged , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s