如 Message Translator 所述，需要被訊息系統整合的應用程式很少對共同資料格式有共識：會計系統對 Customer 物件的認知，就與 CRM 系統不同；更別提一套系統把資料存成關聯式模型，另一套用平面檔或 XML 文件。

整合既有應用程式往往意味著我們沒有「改造應用程式使其更容易與他人協作」的自由。整合方案必須自己去容納並化解系統之間的差異。

Message Translator 為這類格式差異提供了通用解法，本章則探討它的各種具體變體：

• Envelope Wrapper（信封包裝器）——多數訊息系統對表頭的格式與內容有特定要求，我們用它把訊息酬載包進符合基礎設施要求的信封。訊息若要跨越不同的訊息基礎設施，多個信封可以層層組合。
• Content Enricher（內容增補器）——當目標系統需要來源系統無法提供的資料欄位時使用。它能查出缺漏的資訊，或從既有資料算出來。
• Content Filter（內容過濾器）——做相反的事：從訊息中移除不想要的資料。
• Claim Check（寄物憑證）——同樣從訊息中移除資料，但把它存起來供日後取回。
• Normalizer（正規化器）——把以許多不同格式抵達的訊息轉譯成共同格式。
• Canonical Data Model（標準資料模型）——讓所有應用程式都以同一套與應用無關的格式收發訊息。

為什麼轉換這麼重要#

Message Channel 與 Message Router 能消除應用程式之間的基本相依性——一個應用程式不必知道另一個的位置，只要把訊息送到通道就好。

Message Translator 正是用來移除這層相依的。

兩個平行的系統：資料與中介資料#

由於訊息格式與其轉換如此重要，我們可以把任何整合方案看成兩個平行的系統：一個處理實際的訊息資料，另一個處理中介資料（metadata）——也就是描述訊息資料的資料。

許多用於建立訊息流的模式，也能用來管理中介資料。

例如 Channel Adapter 不只能把訊息送進送出某個系統，也能從外部應用程式萃取中介資料，載入中央的中介資料儲存庫。整合開發者接著就能用這個儲存庫定義「應用程式中介資料」與「Canonical Data Model」之間的轉換。

舉個例子：兩個應用程式要交換客戶資訊，但各自對客戶資料的定義略有不同——

• 應用程式 A 把姓與名存成兩個獨立欄位，應用程式 B 存成一個欄位
• 應用程式 A 存郵遞區號而不存州別，應用程式 B 只存州碼

從 A 流向 B 的訊息必須經過轉換。如果 Channel Adapter 也能萃取中介資料（描述訊息格式的資料），建立轉換就簡單得多——這些中介資料可以載入儲存庫，大幅簡化 Message Translator 的設定與驗證。

中介資料可以有多種格式。XML 訊息常用的是 XSD（XML Schema Definition）；其他 EAI 工具實作專有的中介資料格式，但通常允許管理員匯入匯出成不同格式。

適用範圍不限於訊息傳遞#

這些模式中的許多原則在訊息整合之外同樣適用：檔案傳輸也得在系統之間執行轉換；遠端程序呼叫也必須以被呼叫服務所指定的資料格式發出請求，即使應用程式的內部格式不同。

本章描述的是資料轉換任務的各種變體，不深入實體之間的結構轉換細節（例如「一個模型支援客戶與地址的多對多關係，另一個模型卻把地址欄位放在客戶紀錄上，兩者該如何轉換」）。這個主題上最老、也仍最切題的書之一是 [Kent]。