通常，通過消息系統集成的應用很少有同樣的消息格式。比如說，一個帳務系統同一個CRM系統對客戶對象是有著不同的概念的。基于這個，一個系統可能將消息存儲在關系表中，另一個可能存儲在文件中。集成已存在的系統通常意味著我們沒有修改系統以便使他們更好的一起工作的自由。然而，集成方案不得不協調和解決各種系統之間的不同。Message Translator模式提供了一個通用的解決方案。這里解釋幾種特定的Message Translator。
Message Transformation包含以下幾種模式：
l Envelope Wrapper
l Content Enricher
l Content Filter
l Claim Check
l Normalizer
l Canonical Data Model
大多數消息系統放置特定的需求在消息頭的格式和內容中。我們包裝有效數據到一個Envelope Wrapper中以適應消息基礎設施的需求。如果消息需要穿過不同的消息基礎設施，可以結合多個Envelope Wrapper。
如果原始系統不能提供目標系統需要的數據域，可以使用一個Content Enricher。它可以查找缺少的信息并從已有數據中計算出它。Content Filter正好相反，它從消息中刪除不需要的數據。Claim Check也從消息中刪除數據，但是它將存儲他們以便以后取回。Normalizer將多個不同格式的消息翻譯成統一格式。
消除依賴
消息轉換在集成中是一個很深的話題。Message Channels和Message Routers可以通過消除應用必須知道另外一個應用的位置的需求從而解除應用間的基本依賴。
一個應用可以發送一個消息到Message Channel而不必擔心誰來取出消息。然而消息格式增加了另外一種依賴。如果一個應用不得不將消息格式化成另外一個應用的數據格式，通過Message Channel解耦的說法就像一個幻想。接收系統的任何改變或切換到另外一個接收系統都需要對發送應用進行改變。Message Translators可以幫助除去這種依賴。
元數據管理
將消息從一個消息格式轉換到另一個格式需要操作元數據 － 描述數據格式的數據。
元數據在兩個并行系統之間的集成中扮演著非常重要的角色。一個處理實際的消息數據，另外一個處理元數據。許多用于處理消息數據的模式也同樣可以管理元數據。比如說，Channel Adapter不僅可以從一個系統中移進和移出消息，還可以從一個外部應用中獲取元數據，并將其加載到一個元數據倉庫中。使用這個倉庫，集成開發者可以定義應用元數據與Canonical Data Model.之間的轉換。
元數據集成
舉例來說，上面的圖描述了兩個需要交換客戶信息的應用的集成。每個系統的客戶數據的定義稍有不同。從A到B的消息需要轉換一下才能被B接收。如果Channel Adapters可以抽取元數據的話，創建一個轉換將非常簡單。然后這個元數據可以被放入一個倉庫，大大的簡化了Message Translator的配置和驗證。元數據可以被存儲成不同的格式。通常XML消息使用XSD格式。其他EAI工具實現所有元數據格式，但是允許管理員導入或導出到其他格式。
消息系統外的數據轉換
這些轉換模式組成的很多原則可以被應用于非消息集成。比如說，File Transfer可以執行系統間的轉換工作。類似的，Remote Procedure Invocation必須使請求使用要調用的service的格式，即使應用本身的格式可能不同。典型的，需要調用程序來執行轉換。一些最成熟的轉換引擎組成了ETL工具，比如Informatica或者DataMirror。這些工具一般都一次轉換大量的數據，而不是轉換單個消息。
Message System應專注于幾種基本的Message Translator模式。而不應該關心實體間結構轉換的細節（不同的數據模型之間的轉換，比如ER模型不支持多對多關系而其他的支持這種）。關于這個主題最老也使最相關的書是Kent的《Data and Reality》。