脈絡：企業正用訊息傳遞讓應用程式溝通，但企業裡不只一套訊息系統，於是「應用程式該連上哪一套」變得混亂。

為什麼企業會有多套訊息系統#

• 併購——兩家公司各自標準化在不同的訊息產品上
• 技術分層——同一家企業用一套訊息系統整合主機／遺留系統，卻替 J2EE 或 .NET 網頁應用伺服器選了另一套，接著就得把兩者整合起來
• 跨企業參與——某個應用程式同時參與多個企業，例如想在多個拍賣系統中投標的 B2B 客戶端；若各拍賣叢集用不同的訊息系統，企業內的投標應用程式可能希望把多個外部訊息系統的訊息彙整到單一內部訊息系統
• 規模——極大型企業因為通道與端點數量龐大，可能需要多個訊息系統實例，而這些實例之間也得設法連起來

若某套系統上的訊息對另一套系統的應用程式毫無意義，兩者大可完全分開。但因為這些應用程式同屬一家企業，常常會有應用程式對另一套訊息系統上傳輸的訊息有興趣。

常見誤解：JMS 不能解決這件事#

JMS 讓兩套相容的訊息系統在客戶端應用程式眼中長得一樣，但它完全沒有讓這兩套系統彼此協作。要協作，它們必須可互通（interoperable）——使用相同的訊息格式，並以相同方式把訊息從一個訊息儲存搬到下一個。來自兩家不同廠商的訊息系統極少可互通；一家廠商的訊息儲存只能與同一家廠商的訊息儲存協作。

幾個不理想的替代方案#

• 每個應用程式各自實作所有訊息系統的客戶端——這會增加訊息層的複雜度與重複。企業一旦再加一套訊息系統、所有應用程式都得跟著改，這份冗餘就更明顯了。
• 每個應用程式只介接一套訊息系統，忽略其他系統上的資料——應用程式是簡單了，但會忽略掉大量企業資料。

我們需要的，是讓「某套訊息系統上、對另一套系統的應用程式有意義的訊息」也能在第二套系統上可用。

解法#

它實際上長什麼樣#

通常沒有實際可行的方式把兩套完整的訊息系統接起來，因此我們改為連接訊息系統之間個別對應的通道。

Messaging Bridge 是一組 Channel Adapter，只是這裡的「非訊息客戶端」其實是另一套訊息系統，而每一對配接器連接一對對應的通道。這座橋扮演兩組通道之間的對應表，同時把一方的訊息格式轉換成另一方的。被連接的通道既可用來在訊息系統的傳統客戶端之間傳訊息，也可以專門用於送給另一套訊息系統的訊息。

實作上：

• 你可能得自己實作這座橋。它是一個特化的 Message Endpoint 應用程式，同時是兩套訊息系統的客戶端：當某套系統的目標通道上有訊息送達時，橋消費該訊息，並在另一套系統的對應通道上送出一則內容相同的訊息。
• 許多訊息系統廠商提供橋接到其他廠商訊息系統的產品擴充，因此你也許能買而不是自己建。

若另一套「訊息系統」其實只是個較簡單的協定（例如 HTTP），那就套用 Channel Adapter 模式。

未來也許不必再橋接#

Messaging Bridge 之所以必要，是因為不同訊息系統實作各有專有的訊息表示法與轉送方式。

Web services 也許正在標準化這件事——兩套訊息系統安裝（即使來自不同廠商）或許能透過 Web services 標準傳輸訊息而表現得像一套。相關討論見〈企業整合的新興標準與未來〉中關於 WS-Reliability 與 WS-ReliableMessaging 的部分。