兩個應用程式想交換一份資料時，會把它包進一則訊息。Message Channel 本身無法傳輸原始資料，但它能傳輸被包進訊息裡的資料。

決定「建立一則 Message 並送出」之後，還有幾個議題要處理。

訊息意圖#

訊息終究只是一包資料，但寄件端對「接收端該拿它怎麼辦」可以有不同意圖：

• Command Message（命令訊息）——指定接收端上某個寄件端想喚起的函式或方法。寄件端在告訴接收端要跑哪段程式碼。
• Document Message（文件訊息）——把自己的某個資料結構傳給接收端。寄件端只是把資料交過去，不指定接收端該拿它做什麼。
• Event Message（事件訊息）——通知接收端「寄件端這邊變了」。寄件端不告訴接收端該如何反應，只是提供通知。

回傳回應#

應用程式送出訊息後，常會期待一個回應——確認訊息已被處理，並帶回結果。這就是 Request-Reply 情境：

• 請求通常是 Command Message，回覆通常是含有結果值或例外的 Document Message
• 請求方應在請求中指定 Return Address，告訴回覆方該用哪個通道傳回覆
• 請求方可能同時有多個請求在進行中，因此回覆應包含 Correlation Identifier，指明這是哪一個請求的回覆

有兩種常見的 Request-Reply 情境值得一提，兩者都是「Command Message 請求 + Document Message 回覆」：

• Messaging RPC——請求方不只想喚起回覆方的某個函式，還想要那個函式的回傳值。這是應用程式用訊息傳遞做 RPC 的方式。
• Messaging Query——請求方發出一個查詢，由回覆方執行並在回覆中帶回結果。這是應用程式用訊息傳遞做遠端查詢的方式。

巨量資料#

有時應用程式想傳輸一個非常大的資料結構，大到塞不進單一訊息。此時把資料切成較好處理的區塊，以 Message Sequence 送出。

這些區塊必須以序列的形式送出，而不能只是「一堆訊息」——接收端才有辦法重建原本的資料結構。

慢速訊息#

訊息傳遞的一個顧慮是：寄件端往往不知道接收端要多久才會收到訊息。但訊息內容可能對時間敏感——若沒能在期限前被接收，它就該被忽略與丟棄。

此時寄件端可以用 Message Expiration 指定一個到期時間：

• 若訊息系統在到期前無法遞送，就該丟棄該訊息
• 若接收端在到期後才收到訊息，也該丟棄它

所以「決定要用 Message」是不夠的——只要有資料要傳，就一定會透過訊息完成。本章要說明的，是讓訊息真正管用所需的其他決策。