In the figure below we have systems talking directly to each other, as you can see the arrows indicate a request or a response, in each request the requestor needs to compose the request message to a format that the target system accepts as is input, in other words a transformation is required. In the response phase the same is true. When a system changes his service contract all systems that call this service needs to be changed to accommodate the new changes to the service contract.
[Figure 1]
Note in the next picture [Figure 2] the ESB mediating all communications between the systems. But using an ESB doesn’t mean that you must use a Canonical Data Model, still you can have multiple services contracts using the same elements as input or output. Let’s imagine that for all mobile phones we now have a new attribute, then we need to go throw all service contracts that aggregates information about mobiles and we need to refactor these service contracts to include this new attribute.
If instead we use a Canonical Data Model, we just need to include in the canonical object that represents the mobile and include this new attribute. Therefore all service contracts that use this canonical object will now contain our new attribute.
[Figure 2]
Many SOA projects identified the need to use a canonical model; in the internet you can find a lot of articles telling you the reasons of why you should use a canonical model, but very few will tell you exactly how you can do this. Using a CDM is not easy task and there is no best or unique way of doing it. There is also an initiative from Open Applications Group to define canonical data models for some business verticals, like Financial Services, Automotive services, and so on. See more on this link http://xml.gov/documents/completed/oagi/oagis.htm .
In my next post I’ll describe the steps to identify and implement a Canonical Data Model.
