在整合風格一章中，我們討論了連接應用程式的各種選項，其中包含訊息傳遞。

訊息傳遞透過非同步通訊讓應用程式鬆散耦合，而這也讓通訊更可靠——因為兩個應用程式不必同時在運行。訊息傳遞把「把資料從一個應用程式搬到另一個」的責任交給訊息系統，於是應用程式只需專注在「要共享什麼資料」，而不必太操心「怎麼共享」。

訊息傳遞的基本概念#

和多數技術一樣，訊息傳遞牽涉幾個基本概念。理解了它們，即使還沒摸熟所有使用細節，也能看懂這門技術。

• 通道（Channels）——應用程式透過 Message Channel（訊息通道） 傳輸資料，它是連接寄件端與收件端的虛擬管線。新裝好的訊息系統不含任何通道；你必須先判斷應用程式需要怎麼溝通，再建立對應的通道。
• 訊息（Messages）——Message（訊息） 是能在通道上傳輸的原子性資料封包。要傳資料，應用程式得把資料切成一或多個封包、各自包成訊息，再送上通道；接收端則從訊息中取出資料來處理。訊息系統會反覆嘗試遞送，直到成功為止。
• 多步遞送（Multi-step delivery）——最單純的情況是訊息系統把訊息直接從寄件端電腦送到收件端電腦。但訊息送出後、抵達最終接收者之前，往往需要對它做些動作——例如驗證，或因為收件端期待的格式與寄件端不同而必須轉換。Pipes and Filters（管道與過濾器） 架構描述了多個處理步驟如何用通道串接起來。
• 路由（Routing）——在應用程式與通道眾多的大型企業裡，一則訊息可能得穿過好幾個通道才抵達最終目的地。這條路徑可能複雜到原始寄件端根本不知道該送上哪個通道；此時寄件端把訊息交給 Message Router（訊息路由器）——管道－過濾器架構中的一個應用元件與過濾器——由它判斷如何在通道拓樸中導航，把訊息送到最終接收者，或至少送到下一個路由器。
• 轉換（Transformation）——不同應用程式對同一份概念資料的格式未必有共識：寄件端這樣排，收件端卻期待那樣排。要調和這件事，訊息就得經過一個中介過濾器 Message Translator（訊息轉譯器），把它從一種格式轉成另一種。
• 端點（Endpoints）——應用程式沒有內建與訊息系統介接的能力。它必須包含一層同時懂應用程式怎麼運作、也懂訊息系統怎麼運作的程式碼，把兩者橋接起來。這段橋接程式碼就是一組協調運作的 Message Endpoint（訊息端點）。

本章與全書的關係#

本章的模式提供了「用訊息傳遞達成企業整合」所需的基本詞彙與理解，後續所有章節都建立在本章的基礎模式之上。

本章給的是訊息傳遞的宏觀概觀，逐一引介主要主題。想深入其中某個主題，直接跳到該主題對應的那一章即可——那裡有更多模式做更深入的處理。