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.
- Development Cost :- Defining and maintaining the common data-model is a significant SOA Governance exercise. Existing applications, future needs, industry trends need to analysed
- Versioning :- Change is inevitable. The canonical schema definition needs to undergo changes. There is a need to implement a versioning strategy for the canonical.
- 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.
- 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.
- 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.