Service Bus メッセージのペイロードとシリアル化を探索する
メッセージには、ペイロードとメタデータが含まれています。 メタデータはキーと値のペアのプロパティという形式をとり、ペイロードを記述し、処理の指示を Service Bus とアプリケーションに提供します。 ときには、メタデータ単独で送信者が受信者に伝える必要がある情報が運搬され、ペイロードは空のままという場合もあります。
.NET および Java 用の公式 Service Bus クライアントのオブジェクト モデルは、Service Bus でサポートされているワイヤ プロトコルと相互にマップされています。
Service Bus メッセージは、どのような形式でもサービス側で Service Bus によって処理されないバイナリ ペイロード セクションと、2 つのプロパティ セットで構成されます。 "ブローカーのプロパティ" はシステム定義です。 この事前定義されているプロパティは、ブローカー内のメッセージ レベルの機能を制御するか、一般的な標準化されたメタデータ項目にマップされます。 "ユーザー プロパティ" は、アプリケーションによって定義および設定されるキーと値のペアのコレクションです。
メッセージのルーティングと相関関係
ブローカーのプロパティ (具体的には、To、ReplyTo、ReplyToSessionId、MessageId、CorrelationId、SessionId) のサブセットは、アプリケーションによる特定の宛先へのメッセージのルーティングに役立ちます。 次のパターンでは、ルーティングについて説明します。
単純な要求/応答: パブリッシャーは、メッセージをキューに送信し、メッセージ コンシューマーからの応答を要求します。 パブリッシャーは、応答を受信するキューを所有しています。 そのキューのアドレスは、送信メッセージの
ReplyToプロパティに含まれています。 コンシューマーが応答すると、処理されたメッセージのMessageIdが応答メッセージのCorrelationIdプロパティにコピーされ、ReplyToプロパティによって指定された宛先にメッセージが配信されます。 アプリケーションのコンテキストによっては、1 つのメッセージから複数の応答が生成される場合もあります。マルチキャスト要求/応答: 前のパターンのバリエーションとして、パブリッシャーがメッセージをトピックに送信し、複数のサブスクライバーがそのメッセージを使用できるようになります。 各サブスクライバーは、上記の方法で応答することができます。
ReplyToがトピックを指している場合は、このような探索応答のセットを対象ユーザーに配布できます。多重化: このセッション機能を使用すると、1 つのキューまたはサブスクリプションを介して関連するメッセージのストリームを多重化できます。これにより、一致する
SessionId値で識別される関連メッセージの各セッション (またはグループ) は、受信側がロック中のセッションを保持している間、特定の受信者にルーティングされます。 セッションの詳細については、こちらをご覧ください。多重化要求/応答: このセッション機能により、多重応答が有効になり、複数のパブリッシャーが応答キューを共有できるようになります。
ReplyToSessionIdを設定することにより、パブリッシャーは 1 人以上のコンシューマーに、その値を返信メッセージのSessionIdプロパティ内にコピーするように指示できます。 発行キューまたはトピックがセッションを認識する必要はありません。 メッセージが送信されると、パブリッシャーは、セッションの受信者を条件付きで受け入れることで、指定されたSessionIdを持つセッションがキューで具体化されるまで待機できます。
Service Bus 名前空間内のルーティングでは、自動転送チェーンとトピック サブスクリプション規則を使用します。 名前空間の間のルーティングは、Azure LogicApps を使用して実行できます。 To プロパティは、将来使用するために予約されています。 ルーティングを実装するアプリケーションの場合は、To プロパティを使用せずにユーザー プロパティに基づいて実行する必要があります。ただし、現時点では、これにより互換性の問題が発生することはありません。
ペイロードのシリアル化
ペイロードは、転送中または Service Bus 内に格納されているときには常に、不透明なバイナリ ブロックです。 ContentType プロパティにより、アプリケーションは IETF RFC2045 に従ってペイロードを記述できます。これはプロパティ値に対する推奨形式である MIME コンテンツ タイプの記述です (例: application/json;charset=utf-8)。
Java または .NET Standard バリアントとは異なり、Service Bus API の .NET Framework バージョンでは、任意の .net オブジェクトをコンストラクターに渡すことによって BrokeredMessage インスタンスの作成をサポートしています。
レガシ SBMP プロトコルを使用すると、既定のバイナリ シリアライザーまたは外部から提供されたシリアライザーを使用してオブジェクトがシリアル化されます。 AMQP プロトコルの場合は、オブジェクトが AMQP オブジェクトにシリアル化されます。 受信側は、必要な型を指定し、GetBody<T>() メソッドを使用してこれらのオブジェクトを取得できます。 AMQP の場合、オブジェクトは ArrayList および IDictionary<string,object> の各オブジェクトの AMQP グラフにシリアル化され、どの AMQP クライアントでも復号化できます。
この見えないシリアル化のマジックは便利ですが、アプリケーションによってオブジェクトのシリアル化が明示的に制御され、オブジェクト グラフがメッセージに含まれる前にストリームに変換される場合、受信側ではその逆の操作を行う必要があります。 AMQP には強力なバイナリ エンコード モデルがありますが、それは AMQP メッセージング エコシステムに関連付けられており、そのようなペイロードをデコードすると HTTP クライアントで問題が発生します。