Challenges with the canonical schema design pattern


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

http://en.wikipedia.org/wiki/Canonical_schema_pattern

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.
Advertisements

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:

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s