Canonical implies => simplest form possible based on a standard, common view within a given context. Canonical Model is a design pattern used to communicate between different data formats in Enterprise Application Integration (EAI) - it is intended to reduce costs and standardize on agreed data definitions associated with integrating business systems. Canonical Data Model - an enterprise design pattern which provides common data naming, definition and values within a generalized data framework.
A typical migration from point-to-point (P2P) interfacing to message based integration (MOM) begins with a decision on the middleware to be used to transport messages between endpoints. Often this decision results in the adoption of an Enterprise Service Bus (ESB) or Enterprise Application Integration (EAI) solution. Most organizations also adopt a set of standards for message structure and content (message payload). The desire for consistent message payload results in the construction of an enterprise/business domain Canonical Model or adoption of an XML message standard used as the basis for message objects.
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." 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.
Done as "Data format and transformation" in two steps: the adapter converts information from the application's format to the bus's common format. Then, semantic transformations are applied on this (Eg: converting zip codes to city names, splitting/merging objects from one application into objects in the other applications, and so on). Eg: When integrating 2 disperate systems (say: Mainframe MF & a Siebel), the canonical model could be common language, each one translates to for speaking to eachother.
Canonical Schema Pattern
In order for a service consumer to send data (related to a particular business entity e.g. a purchase order), it needs to know the structure of the data i.e. the data model. The interaction between services often requires exchanging business documents often complying to certain stds eg: XML schema document (xsd). Once the service consumer knows the required data model, it can structure the data accordingly. However, under some conditions it may be possible that the service consumer already possesses the required data, which relates to a particular business document, but the data does not conform to the data model as specified by the service provider. This disparity among the data models results in the requirement of data model transformation (so that the message is transformed into the required structure as dictated by the service provider). This runtime data model transformation adds processing overhead and complicates the design of service compositions.
In order to avoid the need for data model transformation, the Canonical Schema pattern dictates the use of standardized data models for those business documents that are commonly processed by the services in a service inventory. Here, a Standardized Service Contract design principle advocates that the service contracts be based on standardized data models. This is achieved by performing an analysis of the service inventory blueprint, 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. Another way is to reuse the commonly used elements composed as complex types but involves repeated usage eg: Between Checkout Service & Payment Service, LineItems are repeatable and can be reused.
Service A is using a different data model as compared to Service B for the same business document. When messages are exchanged, runtime data model transformation needs to be performed.
Both services are using the same data model for representing a particular business document. AS a result, no data model transformation is required when messages are exchanged.
No comments:
Post a Comment