In an up coming dW article a number of my colleagues and I describes why you should care about a Canonical Message Model (CMM) and the general pattern. In this blog I give an outline of the problems and challenges that this pattern looks to address and also a general outline of the solution.
The key challenge that this paper will focus on is how to reduce the complexity of connectivity in an Enterprise Service Bus (ESB) in which service providers and consumers exchange syntactically incompatible messages. The ESB is a core architectural pattern in a Service Oriented Architecture (SOA). The role of the ESB is to provide connectivity between potentially heterogeneous service requesters (consumers) and service providers. The context in which we want to examine this problem further is a SOA where service requesters invoke services from providers which use different message models (and perhaps different metamodels) as illustrated below.
The figure above illustrates the problem of performing direct transformation between service requesters and providers. In the illustrated example, n service requesters interact with the m service providers. Each service (requester / provider) uses its proprietary message model for communication. Note that the message model is generally a reflection of the application's internal data model. In order for the requesters to invoke the providers, the message models from the requesters need to be transformed into the message models of the providers.
As demonstrated in figure above, the ESB must understand all the proprietary message models and, the ESB maps, or transforms, between the message models. In this scenario, the ESB must provide transformations for each possible interaction. For each requester (n in this scenario), a separate transformation has to be specified to each provider (m in this scenario). That means m transformations for the first requester, m transformations for the second, etc. Since there are n requesters, the total number of transformations is n * m. If one new provider is added and all requesters need to interact with it, n new transformations need to be added. If one new requester is added and needs to interact with all m providers, then m transformations need to be added. As a consequence, extending the scope of such an architected integration solution is very costly.
The recommended solution to this problem is to use a canonical message model (CMM). To better understand the idea behind a CMM consider the following analogy of the United Nations (UN). For the UN to function in a multi-lingual world it need to employs interpreters to interpret from one language to another. Take the example of an interpreter working for the French ambassador. This interpreter will need to be able to interpret from French to Chinese, from French to English, etc or to whatever the native language of the person the ambassador is talking with. This is clearly a very stressful job for the interpreter. Now let's pretend that the UN have decreed that from now on the common international language will be Irish (this would be a complete disaster by the way, as Irish is a notoriously difficult language with needlessly complicated grammar and syntax). Now all the interpreters need to know is how to convert from their host language to Irish and back again. In this simple analogy Irish would be the CMM.
Back to our enterprise, the figure above illustrates the CMM approach, where each requester (n of them) needs a transformation to the CMM and each provider (m of them) needs a transformation to the CMM (assuming that they all have different models). Therefore, the total number of transformations is n + m. If a new service - as a service requester or provider - is being introduced and this service uses a proprietary message model, only transformation between the CMM and the application-specific message model would have to be created, regardless of the number of applications that already participate. This reduction in the number of transformations illustrates the core benefit of using the CMM pattern an it helps to reduce the number of required transformation in this heterogeneous environment from n * m to n + m (for n requesters invoking services from m providers).
A CMM standardizes the message models between service requesters and providers, mandating message consistency and improving message maintainability. From a technical perspective, a CMM comprises
- A defined set of semantics representing the business entities and their businessattributes used in all messages
- A defined set of messages with a specific syntax representing the businessentities, each including a related set of the defined types, elements and attributes structured to provide a business document with a specific semantic meaning and context. It is important to understand that this doesn't mean that every requester or provider adopts the exact same message set but that the messages are consistent and all based on the same types.