到目前為止我們介紹了大量模式：基本的訊息元件（Message Channel、Message、Message Endpoint），以及訊息通道與訊息建構的細部模式。
那麼這些模式如何拼在一起？開發者要怎麼用它們整合應用程式？程式碼長什麼樣、又怎麼運作？
本章是真正看到程式碼的地方。我們有兩個範例。
範例一：請求／回覆#
一個簡單卻強大的範例——送出一個請求、傳回一個回覆。它由兩個主要類別組成：
- Requestor——送出請求訊息並期待收到回覆訊息的物件
- Replier——收到請求訊息並以回覆訊息回應的物件
這兩個簡單類別互送簡單訊息，就示範了一連串模式：
- Message Channel 與 Point-to-Point Channel——一個通道傳請求，另一個傳回覆
- Document Message——預設的訊息型別，請求與回覆都用它
- Request-Reply——一對訊息走一對通道，讓兩個應用程式能雙向對話
- Return Address——回應該送往哪個通道
- Correlation Identifier——引發這個回應的那個請求的 ID
- Datatype Channel——每個通道上的所有訊息都該是同一型別
- Invalid Message Channel——型別不對的訊息會怎麼樣
範例程式碼也示範了後面〈訊息端點〉一章的兩個模式：
- Polling Consumer——請求方如何消費回覆訊息
- Event-Driven Consumer——回覆方如何消費請求訊息
本書在技術、產品與語言上保持中立，但程式碼不可能中立。因此這個範例選了兩個訊息程式平台各實作一次：Java J2EE 的 JMS API 與 Microsoft .NET 中以 C# 使用的 MSMQ API。
挑你熟悉的平台看即可；想看另一個平台時，即使不會寫那種語言，對照著你已經懂的那份程式碼也應該看得懂。
範例二：發布／訂閱#
這個範例探討如何用 Publish-Subscribe Channel 實作 Observer 模式。它考慮了分散與執行緒議題，並說明訊息傳遞如何大幅簡化這些問題；它同時實作了推模型與拉模型兩種通知方式並比較其後果，也探討了「當眾多主體要通知眾多觀察者」時，該如何設計一組足夠的通道。
討論與範例程式碼會示範這些模式：
- Publish-Subscribe Channel——提供發布／訂閱通知的通道
- Event Message——用來送通知的訊息型別
- Request-Reply——拉模型中，觀察者向主體索取狀態所用的技巧
- Command Message——觀察者用來索取狀態的訊息型別
- Document Message——主體用來把狀態送給觀察者的訊息型別
- Return Address——告訴主體該如何把狀態送給觀察者
- Datatype Channel——判斷「兩個不相干的主體能否用同一通道更新同一群觀察者」的主要準則
以及後面〈訊息端點〉一章的模式：
- Messaging Gateway——主體與觀察者如何封裝訊息程式碼，使自身不綁定訊息傳遞
- Event-Driven Consumer——觀察者如何消費通知訊息
- Durable Subscriber——不想錯過通知的觀察者，即使通知送出時它暫時離線
這個範例以 Java 搭配 JMS 實作，因為 JMS 透過
Topic介面明確支援 Publish-Subscribe Channel。.NET 對 MSMQ 中的發布／訂閱語意沒有同等程度的支援；等它有了，JMS 範例中的技巧應該也能直接套用到 .NET 程式上。