Common Data Model on ESB

This item is about a CDM a.k.a CMM (Common Message Model) on the Bus, why is it wise and how can it be done.

First of all when you face a integration challenge the systems to be integrated are heterogeneous and use different data models (syntactically and semantically). So the data needs to be mapped from requester data to provider data.
1) Direct mapping, this results in n * m mappings (n=#requestors, m=#providers) and is very costly when a new provider or requester is added.
2) CDM, this results in n + m mappings
A CDM gives you:

• Message consistency
• Message maintainability

A CDM is a set of data representing the business entities used in all messages on the Bus. This does not mean that each provider or requestor uses the same set of messages but that the messages are all based on the same types.

Possible implementations for CDM on ESB
Option 1: ESB translates

• The requestor and provider keep their own models
• Only CDM is used on ESB
• Existing services do not have to be changed (especially B2B)
• Only m+ n translations to be implemented and managed
• Easier to reuse mediation logic because it can use the CDM data instead of proprietary message models of the requestors/providers
• Processing overhead? ESB becomes single point of failure?

Option 2: The services translate

• 

• The ESB is not responsible for data mapping
• Transformations run in the request's/provider's environment

Option 3: The requestors/providers all use the CDM data

• No transformations needed
• Services can adopt the CDM data model
• Reduces load and management on the ESB
• Mostly unrealistic, hard to reach consensus on model, applications are legacy and cannot be changed
  

Option 4: Hybrid (combination of option 1 and 2)

• It may lead to complex maintenance and management of the transformations.
  

Reference
http://www.ibm.com/developerworks/webservices/library/ar-esbpat3/index.html?ca=drs-