探索服務匯流排訊息承載和序列化
訊息包含承載和中繼資料。 中繼資料為索引鍵/值組屬性的形式，可描述承載，還提供處理指示給服務匯流排和應用程式。 偶爾只要該中繼資料就足夠可承載傳送者需要與接收者通訊的資訊，且承載會維持空白。
.NET 和 Java 的正式服務匯流排用戶端物件模型，會對應至線路通訊協定服務匯流排支援，以及從中對應。
服務匯流排訊息包含二進位承載區段 (服務匯流排決不會在服務端以任何形式進行處理)，以及包含兩組屬性。 訊息代理程式屬性是系統定義的屬性。 這些預先定義的屬性會控制訊息代理程式內的訊息層級功能，或是會對應至一般和標準化項目。 使用者屬性是機碼值組的集合，會由應用程式進行定義及設定。
訊息路由傳送及相互關聯
一部分訊息代理程式屬性，尤其是 To、ReplyTo、ReplyToSessionIdMessageId、CorrelationId 和 SessionId，可協助應用程式將訊息路由傳送至特定目的地。 下列模式描述路由傳送：
簡單要求/回覆：發行者將訊息傳送至佇列，然後期待訊息取用者的回覆。 發行者擁有一個可接收回覆的佇列。 在輸出訊息的
ReplyTo屬性中包含該佇列的位址。 取用者回應時會將所處理訊息的MessageId複製到回覆訊息的CorrelationId屬性，並將訊息傳遞至ReplyTo屬性指出的目的地。 一個訊息可能會產生多個回覆，視應用程式內容而定。多點傳送要求/回覆：前一種模式的變化，發行者將訊息傳送至主題，而多個訂閱者變成有資格取用訊息。 每個訂閱者可能會以先前所述的方式回應。 如果
ReplyTo指向主題，則這一組探索回應可散發給對象。多工：此工作階段功能透過單一佇列或訂用帳戶，啟用相關訊息資料流的多工處理，使得每個工作階段 (或群組) (比對
SessionId值來識別) 的相關訊息路由傳送至特定接收者，而接收者在此期間保持鎖定工作階段。 請在這裡深入了解工作階段的詳細資料。多工要求/回覆：此工作階段功能啟用多工回覆，可讓多個發行者共用一個回覆佇列。 透過設定
ReplyToSessionId，發行者可以指示一或多個取用者將該值複製到回覆訊息的SessionId屬性。 發佈佇列或主題無須感知工作階段。 傳送訊息之後，發行者可以有條件地接受工作階段接收者，以等候具有特定SessionId的工作階段在佇列上具體化。
服務匯流排命名空間內的路由傳送會使用自動轉接鏈結和主題訂用帳戶規則。 您可以使用 Azure LogicApps，來執行跨命名空間的路由傳送。
To 屬性會保留供未來使用。 實作路由傳送的應用程式應該根據使用者屬性 (而不是依賴 To 屬性) 這麼做；但是，現在這麼做也不會造成相容性問題。
承載序列化
承載在傳輸中或儲存在服務匯流排內時，一律為不透明的二進位區塊。
ContentType 屬性可讓應用程式描述承載，根據 IETF RFC2045，建議的屬性值格式為 MIME content-type 描述，例如 application/json;charset=utf-8。
不同於 JAVA 或 .NET Standard 變數，.NET Framework 版的服務匯流排 API 支援將任意 .NET 物件傳遞至建構函式，以建立 BrokeredMessage 執行個體。
舊版 SBMP 通訊協定會使用預設二進位序列化程式，或使用外部提供的序列化程式，將物件序列化。 AMQP 通訊協定會將物件序列化為 AMQP 物件。 接收者可以利用 GetBody<T>() 方法，並提供預期的類型，以擷取這些物件。 透過 AMQP，物件序列化為 ArrayList 和 IDictionary<string,object> 物件的 AMQP 圖表，而且可由任何 AMQP 用戶端解碼。
儘管這項隱藏的序列化魔術很便利，但應用程式應明確控制物件序列化，並在訊息內包含這些應用程式之前，將其物件圖轉換為串流，其應在接收者端執行反轉作業。 當 AMQP 具有功能強大的二進位編碼模型時，系統會將其繫結到 AMQP 傳訊生態系統，而 HTTP 用戶端將在為這類承載進行解碼時遇到問題。