Enterprise Canonical Schemas (continued...)

In my last post we discussed the concept of the enterprise canonical schema and its suitability when applied in the context of the various flavours of SOA we've discussed to date. As part of that discussion I stipulated that an enterprise canonical schema should be avoided when engaging in self-contained process-centric service models.

However, canonical schemas can still be very useful when we are engaging in EAI behind the service boundary. That is, when we have one or more services containing a number of legacy systems whose activities need to be orchestrated in support of those services.

Self contained services control and hold their own data locally. Data is represented within each service in such a way to best support the cohesive business processes that execute within that service. If we were to have two different CRMs within an enterprise, both would likely sit in the same Customer Management Service.

The Customer Management Service would have its own service contract expressed in terms of the customer management business domain for the enterprise (rather than in the terms of the CRM applications within the service). We have a layer of abstraction (an anti-corruption layer as termed by Eric Evans) between the CRM applications and the service boundary that coordinates the activities of the CRM applications within the service boundary in support of the service's business processes.

So that we don't have to deal with two entirely different data representations within the orchestrations coordinating the activities of the CRM applications, we develop a service canonical schema which is aligned with the service domain model. If we have multiple services enagaging in EAI internally, then we will have a different canonical schema for each service.

Any messages outbound from one of the CRM applications are first translated to the canonical schema. Likewise, any messages inbound for a CRM application are first translated to that CRM application's native syntax. The orchestrations coordinating the activities of the CRM applications are then expressed in terms of the canonical schema.

Of course, if a service does not include a number of applications that must be integrated in support of that service then there is no need for a canonical schema at all.