メッセージ、ペイロード、シリアル化

Azure Service Bus はメッセージを処理します。 メッセージには、ペイロードとメタデータが含まれています。 メタデータはキーと値のペアという形式をとり、ペイロードを記述し、処理の指示を Service Bus とアプリケーションに提供します。 場合によっては、そのメタデータだけで送信者が受信者に伝えたい情報を伝えるのに十分で、ペイロードが空のままになることがあります。

.NET および Java 用の公式 Service Bus クライアントのオブジェクト モデルは、Service Bus がサポートするワイヤ プロトコルとの間でマップされる抽象的な Service Bus メッセージ構造を反映しています。

Service Bus メッセージは、Service Bus がサービス側でいかなる形式でも処理することのないバイナリ ペイロード セクションと 2 つのプロパティ セットで構成されます。 ブローカー プロパティは、システムによって事前定義されています。 この事前定義されているプロパティは、ブローカー内のメッセージ レベルの機能を制御するか、一般的な標準化されたメタデータ項目にマップされます。 ユーザー プロパティは、アプリケーションが定義および設定できるキーと値のペアのコレクションです。

次の表に、事前定義されているブローカー プロパティの一覧を示します。 これらの名前は、すべての公式クライアント API と、HTTP プロトコル マッピングの JSON オブジェクト BrokerProperties でも使用されます。

カッコ内には、Advanced Message Queuing Protocol (AMQP) プロトコル レベルで使用される同等の名前を示しています。 次の名前ではパスカル ケースが使用されていますが、JavaScript および Python クライアントでは、それぞれキャメル ケースとスネーク ケースが使用されます。

この抽象メッセージ モデルでは、メッセージを HTTPS を介してキューに送信し、AMQP を介して取得することができます。 いずれの場合も、それぞれのプロトコルのコンテキストでは、メッセージは正常に見えます。 ブローカーのプロパティは必要に応じて変換され、ユーザーのプロパティはそれぞれのプロトコル メッセージ モデル上の最適な場所にマップされます。 HTTP では、ユーザー プロパティは HTTP ヘッダーとの間で直接マップされます。AMQP では、application-properties マップとの間でマップされます。

メッセージのルーティングと相関関係

上記のブローカー プロパティのサブセット、具体的には To、ReplyTo、ReplyToSessionId、MessageId、CorrelationId、SessionId は、アプリケーションがメッセージを特定の宛先にルーティングできるようにするために使用されます。 この機能を説明するために、いくつかのパターンを考えてみましょう。

• 単純な要求/返信: 発行元はメッセージをキューに送信し、メッセージ コンシューマーからの応答を待ちます。 応答を受信するために、発行元は、応答が配信されることを想定するキューを所有します。 キューのアドレスは、送信メッセージの ReplyTo プロパティで示されます。 コンシューマーが応答するときは、処理されるメッセージの MessageId を応答メッセージの CorrelationId プロパティにコピーし、ReplyTo プロパティで示された宛先にメッセージを配信します。 アプリケーションのコンテキストによっては、1 つのメッセージから複数の応答が生成される場合もあります。
• マルチキャストの要求/応答: 前のパターンのバリエーションとして、発行元がトピックにメッセージを送信し、複数のサブスクライバーがメッセージを使用できるようになります。 各サブスクライバーは、上記の方法で応答することができます。 このパターンは検出またはロール呼び出しのシナリオで使用され、応答者は通常、ユーザー プロパティによって、またはペイロード内で自身を識別します。 ReplyTo がトピックを指している場合、そのような検出応答のセットを対象ユーザーに配信することができます。
• 多重化: このセッション機能により、1 つのキューまたはサブスクリプションで関連するメッセージのストリームを多重化して、受信者がロックされたセッションを保持している間に、一致する SessionId 値で識別された関連するメッセージの各セッション (またはグループ) が特定の受信者にルーティングされるようにできます。 セッションの詳細については、こちらを参照してください。
• 多重化された要求/応答: このセッション機能を使用すると、多重化された応答を有効にして、複数の発行元が応答キューを共有できるようになります。 発行元は ReplyToSessionId を設定することにより、その値を応答メッセージの SessionId プロパティにコピーするようにコンシューマーに指示できます。 発行キューまたはトピックがセッションを認識する必要はありません。 メッセージが送信されると、発行元はセッション レシーバーを条件付きで受け入れることにより、特定の SessionId を持つセッションだけを待機してキューで具体化できます。

Service Bus 名前空間内のルーティングは、自動転送チェーンとトピック サブスクリプション規則によって実現できます。 名前空間の間のルーティングは、Azure LogicApps の使用によって実現できます。 前の一覧に示したように、To プロパティは将来の使用のために予約されており、最終的には特別に有効にされた機能を持つブローカーによって解釈される可能性があります。 ルーティングを実装するアプリケーションは、To プロパティを使用せずにユーザー プロパティに基づいて実装する必要があります。ただし、現時点では To プロパティを使用しても互換性の問題は発生しません。

ペイロードのシリアル化

転送中または Service Bus 内で格納されている場合、ペイロードは常に不透明なバイナリ ブロックです。 ContentType プロパティを使用すると、アプリケーションは、プロパティ値の形式として推奨される IETF RFC2045 に準拠した MIME コンテンツの種類の記述、たとえば、application/json;charset=utf-8 などでペイロードを記述することができます。

Java や .NET Standard バージョンとは異なり、.NET Framework バージョンの Service Bus API では、任意の .NET オブジェクトをコンストラクターに渡して BrokeredMessage インスタンスを作成することができます。

2026 年 9 月 30 日に、Azure SDK ガイドラインに準拠していない Azure Service Bus SDK ライブラリ WindowsAzure.ServiceBus、Microsoft.Azure.ServiceBus、および com.microsoft.azure.servicebus は廃止されます。 SBMP プロトコルのサポートも終了するため、2026 年 9 月 30 日以降はこのプロトコルを使用できなくなります。 この日付より前に、重要なセキュリティ更新プログラムと強化された機能が提供される、最新の Azure SDK ライブラリに移行してください。

古いライブラリは 2026 年 9 月 30 日以降も引き続き使用できますが、Microsoft から公式のサポートと更新プログラムは提供されなくなります。 詳細については、サポート廃止のお知らせに関するページを参照してください。

レガシ SBMP プロトコルを使用する場合、これらのオブジェクトは、既定のバイナリ シリアライザーまたは外部から提供されたシリアライザーを使用してシリアル化されます。 オブジェクトは AMQP オブジェクトにシリアル化されます。 受信者は、想定される型を指定して、GetBody<T>() メソッドを使用してこれらのオブジェクトを取得できます。 AMQP では、オブジェクトは ArrayList オブジェクトと IDictionary<string,object> オブジェクトの AMQP グラフにシリアル化され、任意の AMQP クライアントがそれらをデコードできます。

2026 年 9 月 30 日に Azure Service Bus 用の SBMP プロトコルのサポートは終了するため、2026 年 9 月 30 日以降はこのプロトコルを使用できなくなります。 その日付より前に、(重要なセキュリティ更新プログラムと強化された機能が提供される) AMQP プロトコルを使った最新の Azure Service Bus SDK ライブラリに移行してください。

詳細については、サポート廃止のお知らせに関するページを参照してください。

この隠されたシリアル化の魔法は便利ですが、アプリケーションはオブジェクトのシリアル化を明示的に制御し、オブジェクト グラフをメッセージに含める前にストリームに変換し、受信側でその逆を行う必要があります。 これは相互運用可能な結果を生成します。 AMQP には強力なバイナリ エンコード モデルがありますが、それは AMQP メッセージング エコシステムに関連付けられており、HTTP クライアントがそのようなペイロードをデコードすると問題が発生します。

.NET Standard および Java バージョンの API はバイト配列しか受け入れません。つまり、アプリケーションはオブジェクトのシリアル化制御を処理する必要があります。

メッセージ ペイロードからのオブジェクトの逆シリアル化を処理する場合、異なるシリアル化メソッドを使用して複数のソースからメッセージが到着する可能性があることを、開発者は考慮する必要があります。 これは、古いバージョンが新しいバージョンと共に実行され続ける可能性がある、単一のアプリケーションを進化させるときにも発生することがあります。 このようなケースでは、逆シリアル化の最初の試行が失敗した場合に備え、追加の逆シリアル化メソッドを用意することをお勧めします。 これに対応するライブラリの 1 つが NServiceBus です。 すべての逆シリアル化メソッドが失敗する場合は、メッセージを配信不能にすることをお勧めします。

次のステップ

Service Bus メッセージングの詳細については、次のトピックを参照してください。

• Service Bus のキュー、トピック、サブスクリプション
• Service Bus キューの使用
• Service Bus のトピックとサブスクリプションの使用方法