Skip to end of metadata
Go to start of metadata

Canonical Data Model

The section aims to describe a way in which loosly coupled system can use transformation to ensure the the messages passed between systems are not dependent on the other system(s) message formats.

In the picture below we have system A, which delivers data to System B, System C, and System D:


 
Now, lets take a look what happens if we need to replace or change System A or its message format:


 
All of the transformations must be updated to reflect the changes to System A. This leaves a brittle system where Systems are tightly coupled.

Enter the canonical data format:

 
In this model every message must first be transformaed from System A's message format (M1) to the canonical data format(M2). This is also the case for System B, System C, and System D. 

Lets take a look at what happens if one need to replace or change System A or its message format: 


 
In this case only the transformations to and from System A's message format need to be updated to reflect the changes to System A.

The down side of having a Canonical data format is the number of transformation that can effect performance.


  • No labels

1 Comment

  1. Hey Daniel, I wonder how might profiling help here. The idea of profiling is to help in situations where e.g. you have a message being emitted from a source to multiple targets (A->b, A->C etc). It allows you to define transformation configurations that are common across all transformations once and once only.

    So, you can define transformations and target them at all message exchanges where the source is "A" i.e. "from-A" and the other transforms for "to-B" and "to-C" etc.

    Another option here is to use the Smooks DOM Processing model to cut down on the processing overhead by using the Assembly Phase to create the Canonical Form, and then use the Processing Phase to produce a valid message for B, C or D. This would also use profiling by targeting the Assembly Phase Canonicalization based resources at "from-A" and then the Processing Phase resources at "to-B", "to-C" etc. In this way, you can perform the Canonicalization and transformation in a single Smooks transformation cycle.

    You could also use the Javabean Cartridge here. Use the Javabean Cartridge to construct and populate an Object model of the source message ("from-A"). Then use the Templating Cartridge (XSLT or StringTemplate) to generate the target message ("to-B", "to-C" etc) using the populated Object model. Actually, all this could be done in a single processing phase - no need for the Assembly phase to be used at all. This also maintains a high degree of isolation from changes to the source format because if the source message changes, all you need to do is modify the Javabean population configs (the "from-A" configs), assuming the basic data model is still the same i.e. the same pieces of data exist, but are just moved around in the source message.