脈絡：我正在設計數個透過訊息協同工作的應用程式，而每個應用程式都有自己的內部資料格式。

轉譯器數量的爆炸#

獨立開發的應用程式傾向使用不同的資料格式，因為每種格式當初都只考慮了自己那個應用程式。當某個應用程式被設計成要與未知的應用程式收發訊息時，它自然會用對自己最方便的格式；而用來整合套裝應用的商業配接器，發布與消費的資料格式也長得像該應用程式的內部資料結構。

Message Translator 能在不修改應用程式、也不讓它們知道彼此格式的前提下化解差異。

考慮到每個被整合的應用程式可能發布或消費多種訊息型別，所需的 Message Translator 數量會隨應用程式數量指數成長，很快就無法管理。

而且雖然 Message Translator 在兩個應用程式的訊息格式之間提供了一層間接，它仍相依於雙方的格式：

• 某個應用程式的資料格式一改，它與所有通訊對象之間的 Message Translator 全都得改。
• 方案中新增一個應用程式，就得為每個既有應用程式各建一個到新應用程式的 Message Translator。

維護所有這些轉譯器會變成一場惡夢。

還要記得：每加入訊息流的一個轉換步驟，都可能增加延遲、降低吞吐量。

解法#

Canonical Data Model 在各應用程式自己的資料格式之間提供了額外一層間接。

數字說明一切#

參與者少時，Canonical Data Model 看起來很麻煩；但隨著應用程式數量增加，很快就回本了。假設每個應用程式都與其他每個應用程式互送訊息：

若某個既有應用程式將來很可能被另一個取代，Canonical Data Model 也非常有用。例如若有一批應用程式都介接某個未來將被汰換的遺留系統，一開始就把 Canonical Data Model 的概念做進方案裡，日後切換系統的工夫會小得多。

怎麼讓應用程式遵循共同格式#

有三個基本選擇：

• 改變應用程式的內部資料格式——理論上可行，但在複雜的真實情境中不太可能。

而且若真能輕易讓每個應用程式原生使用同一格式，那我們不如用 Shared Database，根本不必用 Messaging。

• 在應用程式內部實作 Messaging Mapper——自製應用程式可以用 mapper 產生所需的資料格式。
• 使用外部的 Message Translator——把應用程式專屬格式轉譯成 Canonical Data Model 所指定的格式。

用 Messaging Mapper 還是外部 Message Translator，取決於轉換的複雜度與應用程式的可維護性：

• 套裝應用通常排除了 Messaging Mapper 的可能，因為拿不到原始碼。
• 自製應用則看轉換的複雜度。許多整合工具套件提供視覺化轉換編輯器，能更快建構對應規則，但轉換一複雜，這些視覺工具就可能難以駕馭。

代價：雙重轉譯#

使用 Canonical Data Model 會為訊息流引入一定的開銷：每則訊息現在要經過兩個轉譯步驟——從來源格式轉成共同格式、再從共同格式轉成目標格式。

因此使用 Canonical Data Model 有時被稱為「雙重轉譯（double translation）」（直接從一個應用程式的格式轉成另一個則稱「直接轉譯」）。每個轉譯步驟都增加訊息流的延遲，所以對吞吐量要求極高的系統，直接轉譯可能是唯一選擇。

這是「可維護性 vs. 效能」的常見取捨。最好的建議是：採用較好維護的方案（也就是 Canonical Data Model），除非效能需求不允許。

一個緩解因素是：許多轉譯是無狀態的，因此很適合用多個平行執行的 Message Translator 做負載平衡。

設計 Canonical Data Model 的難處#

設計 Canonical Data Model 可能很困難。設計者應該力求讓統一模型對所有被整合的應用程式都同樣好用，但現實中這個理想很難達成。

成功的機會會提高——只要記得 Canonical Data Model 不必為所有應用程式的完整資料模型建模，只需涵蓋「參與訊息傳遞的那一部分」。這能大幅降低建立它的複雜度。

政治上的好處#

使用 Canonical Data Model 還有政治上的優勢：它讓開發者與業務使用者能用「公司的業務領域」而非「特定套裝軟體的實作」來討論整合方案。

例如套裝應用可能用 account、payer、contact 等各種內部格式來表示「客戶」這個共同概念。定義 Canonical Data Model 往往是化解應用程式之間語意不一致的第一步。

相依性存在於多個層次#

「為每一對應用程式都建轉譯器」的那張圖，與 Message Routing 一章導論中的圖出奇地相似——這提醒我們：應用程式之間的相依性存在於多個層次。

• Message Channel 提供共同的傳輸層，移除各應用程式傳輸協定之間的相依
• Message Router 提供位置無關性，讓送件端不必相依於收件端的位置
• 共同的資料表示法（例如 XML） 移除對應用程式專屬資料型別的相依
• Canonical Data Model 化解資料格式與語意上的相依

由於標準格式很可能隨時間改變，它應該指定一個 Format Indicator。

範例：WSDL 與 TIBCO ActiveEnterprise

WSDL#

從應用程式存取外部服務時，該服務可能已經指定了要使用的 Canonical Data Model。

在 XML Web services 的世界裡，資料格式由 WSDL（Web Services Definition Language）文件指定——它規定了該服務能消費與產出的請求與回覆訊息的結構。

多數情況下，WSDL 所指定的資料格式與提供該服務的應用程式的內部格式不同。實際上，WSDL 為對話雙方指定了一個 Canonical Data Model；而雙重轉譯就由服務消費端的 Messaging Mapper 或 Gateway，以及服務提供端的 Remote Facade 構成。

TIBCO ActiveEnterprise#

許多 EAI 工具套件提供完整的工具來定義與描述標準資料格式。例如 TIBCO ActiveEnterprise 的 TIB/Designer 讓使用者檢視所有共同訊息定義，訊息定義可以從 XML schema 匯入或匯出。

用內建視覺工具實作 Message Translator 時，工具會同時呈現應用程式專屬的資料格式，以及存放在中央資料格式儲存庫中的 Canonical Data Model。