So, it’s one of those things that drives you nuts when everyone is talking about a buzzword, and you haven’t found the definition. Canonical in the context of SOA keeps popping up in the many briefings and product marketing conversations I’ve had these past 12 months, so I thought I’d share with you the definition as its being used.

Attempting to find a good definition…
So, I started with a good old Wikipedia try some months back and got this definition:

“Some circles in the field of computer science have borrowed this usage from mathematicians. It has come to mean “the usual or standard state or manner of something”; for example, “the canonical way to organize a file system is as a hierarchy, with extensions to make it a directed graph“. XML Signature defines canonicalization as the process of converting XML content to a canonical form, to take into account changes that can invalidate a signature over that data (from JWSDP 1.6).

For an illuminating story about the word’s use among computer scientists, see the Jargon File‘s entry for the word[1].

Some people have been known to use the noun canonicality; others use canonicity. In fields other than computer science, canonicity is this word’s canonical form.”

…led me to put it in the perspective of SOA
As you can imagine, the definition was utterly useless and left me still clueless. So here’s what I’m starting to understand after talking to my Enterprise Architect gurus that “canonical” is often used in the context of SOA to:

  • Describe data models. Most of the gurus I talked to mentioned that this would be the superset of all data required to for a specific purpose, yet not reflect all the data. It may not be complete, but it would serve as the single model.
  • Explain how applications talk to each other. Often used in discussing messaging for SOA, it’s about what metadata objects such as data types, values, and semantics are communicated to both the sending and receiving applications. The end result must be some agreement what is the right data, what does it mean to each party, and how the data will be used and shared.
  • Keep BPEL clean. In order to build a clean service repository, there exists an integration layer that transforms/mediates a variety of messages to a common format through common codes or an ESB. This layer sits between the service repository and the integration processes. Typical hub and spoke integration requires messages to be translated to an independent format and then into the required format. This allows you to add new applications by adding a translation layer making this more effective and reusable than point to point integration. It’s common in most EAI approaches.

The bottom line
Often found in conversations about SOA, “canonical” refers to a design philosophy and approach that maps between the various data, messaging, and semantic frameworks used by multiple applications and systems. It’s about an approach that allow for reuse of items, such as business processes, among different systems.

(The personal contents in this blog do not reflect the opinions, ideas, thoughts, points of view, and any other potential attribution of my current, past, or future employers.)
Copyrighted 2007 by R Wang. All rights reserved