The goal of the Canonical Model is to provide a dictionary of reusable common objects and definitions at an enterprise or business domain level to enhance system interoperability. A Canonical Data Model allows developers and business users to discuss the integration solution in terms of the company's business domain, not a specific package implementation. For example, packaged applications may represent the common concept of a customer in many different internal formats, such as 'account', 'payer', and 'contact'. Defining a Canonical Data Model is often the first step to resolving cases of semantic dissonance between applications.^ <http://en.wikipedia.org/wiki/Canonical_Model#cite_note-1> Enterprise integration models provide a foundation for a decoupled, consistent, reusable integration methodology which can be implemented using messaging supported by middleware products. Message payloads (business data content) in the _*form of XML schema*_ are built from the common model objects thus providing the desired consistency and re-usability while ensuring data integrity. It aims to reduce the need for performing data model transformation when services^ <http://en.wikipedia.org/wiki/Canonical_Schema_Pattern#cite_note-services-1> exchange messages that reference the same data model. As stated by thomas Erl: This design pattern is fully supported by the application of the Standardized Service Contract design principle. The Standardized Service Contract design principle advocates that the service contracts be based on standardized data models. (which sometimes difficult to achieve) This is achieved by performing an analysis of the service inventory blueprint^ <http://en.wikipedia.org/wiki/Canonical_Schema_Pattern#cite_note-service_inventory_blueprint-6> in order to find out the commonly occurring business documents that are exchanged between services. These business documents are then modeled in a standardized manner. For example, in case of web services, the business documents are modeled as XML schemas. Once a standardized data representation layer exists in a service inventory, different service contracts can make use of the same data models if they need to exchange the same business documents. This eliminates the need for any data model transformation and reduces the processing overhead associated with the data model transformation. It also increases the reusability potential of a service as now the service can be consumed without requiring any custom data model transformation logic. In a way, the application of the Canonical Schema pattern reduces the need for the application of the Data Model Transformation^ <http://en.wikipedia.org/wiki/Canonical_Schema_Pattern#cite_note-DataModelTransformation-7> design pattern.^ <http://en.wikipedia.org/wiki/Canonical_Schema_Pattern#cite_note-SODI-2> Please visit the canonical schema pattern explained by Thomas Erl. It is a very valuable resource. It has no direct relationship with the existing ER model. You model the standardized enterprise format that all parties agreed upon without considering the existing ER model.
All the best Ashraf Galal [email protected] wrote: > > > Hello all. > > I have a question for the design of a canonical data model. > > The issue is that I want to create a data services layer, and for > making the design of services that expose data, first I want to create > the canonical data model, which allows me to properly design services, > and I want to know if this canonical data model should correspond to > the data model of the database, E / R model , or I just model the > information concepts that are handled in the database. > > Jorge. > > > > > > > > > > > > > > > >
