この記事では、メッセージのさまざまな種類と、メッセージング インフラストラクチャに参加するエンティティについて説明します。 メッセージの各種類の要件に基づいて、この記事では Azure メッセージング サービスを推奨します。 これらのオプションには、Azure Service Bus Messaging、Azure Event Grid、および Azure Event Hubs が含まれます。 製品の比較については、「メッセージング サービス の比較」 を参照してください。
アーキテクチャのレベルでは、メッセージとは、情報を分散させることにより他のエンティティ (コンシューマー) が認識し、それに応じて行動できるようにするために、エンティティ (プロデューサー) によって作成されるデータグラムのことです。 プロデューサーとコンシューマーは、直接、または必要に応じて中間のエンティティ (メッセージ ブローカー) 経由で通信できます。 この記事では、メッセージ ブローカーを使用した非同期メッセージングに重点を置きます。
メッセージは主に 2 つのカテゴリに分類できます。 プロデューサーがコンシューマーからのアクションを予測している場合、そのメッセージはコマンドです。 メッセージがコンシューマーにアクションが実行されたことを通知する場合、そのメッセージはイベントです。
コマンド
プロデューサーは、コンシューマーがビジネス トランザクションのスコープ内で操作を実行するという意図をもってコマンドを送信します。
コマンドは高価値のメッセージであり、少なくとも 1 回は配信される必要があります。 コマンドが失われると、ビジネス トランザクション全体が失敗する可能性があります。 また、コマンドを複数回処理することもできません。 それを行うと、間違ったトランザクションが生成されることがあります。 顧客が重複した注文を受け取ったり、2 回請求されたりする可能性があります。
コマンドは多くの場合、複数のステップから成るビジネス トランザクションのワークフローを管理するために使用されます。 ビジネス ロジックに応じて、プロデューサーは、コンシューマーがメッセージを確認し、操作の結果を報告することを予測できます。 その結果に基づいて、プロデューサーはアクションの適切なコースを選択できます。
events
イベントは、プロデューサーがファクトをアナウンスするために生成するメッセージの種類です。
プロデューサー (このコンテキストではパブリッシャーと呼ばれます) は、イベントのために何からのアクションが発生することを予測していません。
関心を持つコンシューマーは、サブスクライブし、イベントをリッスンして、その使用シナリオに応じてアクションを実行できます。 イベントには複数のサブスクライバーを含めることも、サブスクライバーをまったく含めないこともできます。 2 つの異なるサブスクライバーは、あるイベントに異なるアクションで対応でき、互いに認識することはできません。
プロデューサーとコンシューマーは疎結合され、独立に管理されます。 プロデューサーは、コンシューマーがイベントの確認をプロデューサーに戻すことを予測していません。 イベントに関心がなくなったコンシューマーは登録を解除できます。これにより、プロデューサーやシステムの全体的な機能に影響を与えることなく、パイプラインからコンシューマーが削除されます。
イベントのカテゴリには、次の 2 つがあります。
プロデューサーが、離散ファクトをアナウンスするためにイベントを生成します。 一般的なユース ケースとして、イベント通知があります。 たとえば、Azure Resource Manager は、リソースを作成、変更、または削除するときにイベントを生成します。 これらのイベントのサブスクライバーとしては、アラート電子メールを送信するロジック アプリが考えられます。
プロデューサーが、関連するイベントを一定の期間にわたって順番に、またはイベントのストリームで生成します。 通常、ストリームは統計的な評価に使用されます。 この評価は、テンポラル ウィンドウ内に、またはイベントが到着したときに実行できます。 テレメトリ (システムの正常性や負荷の監視など) が一般的なユース ケースです。 別のケースとして、IoT デバイスからのイベント ストリーミングがあります。
イベント メッセージングを実装するための一般的なパターンには、パブリッシャーとサブスクライバーのパターンがあります。
メッセージ ブローカーの役割とメリット
中間のメッセージ ブローカーは、プロデューサーからコンシューマーにメッセージを移動する機能を提供するほか、その他のメリットも提供できます。
切り離し
メッセージ ブローカーは、それぞれメッセージを生成および使用するロジックで、コンシューマーからプロデューサーを切り離します。 複雑なワークフローでは、ブローカーはビジネス操作の切り離しを促進することができ、それによりワークフローの調整に役立ちます。
たとえば、1 つのビジネス トランザクションには、ビジネス ロジック シーケンスで実行される個別の操作が必要です。 プロデューサーは、コンシューマーに操作を開始するよう伝えるコマンドを発行します。 コンシューマーは、プロデューサーへの応答を用意するために予約された別のキューでメッセージを確認します。 応答を受信した後でのみ、プロデューサーは、シーケンス内の次の操作を開始するための新しいメッセージを送信します。 別のコンシューマーがそのメッセージを処理し、応答キューに完了メッセージを送信します。 メッセージングを使用することにより、サービスは、それらのサービス自体の間でトランザクションのワークフローを調整します。
メッセージ ブローカーは、一時的な切り離しを提供します。 プロデューサーとコンシューマーが同時に実行される必要はありません。 プロデューサーは、コンシューマーの可用性には関係なく、メッセージ ブローカーにメッセージを送信できます。 逆に、コンシューマーも、プロデューサーの可用性によって制限されません。
たとえば、Web アプリのユーザー インターフェイスはメッセージを生成し、メッセージ ブローカーとしてキューを使用します。 コンシューマーの準備ができたら、キューからメッセージを取得して作業を実行できます。 一時的な切り離しは、ユーザー インターフェイスの応答性を維持するために役立ちます。 つまり、メッセージが非同期的に処理されている間はブロックされません。
特定の操作の完了に長い時間がかかる場合があります。 コマンドを発行した後、プロデューサーは、コンシューマーがそのコマンドを完了するまで待つ必要はありません。 メッセージ ブローカーは、メッセージの非同期処理に役立ちます。
負荷分散
プロデューサーは、多くのコンシューマーによって処理される多数のメッセージをポストすることがあります。 サーバー間で処理を分散させ、スループットを向上させるには、メッセージ ブローカーを使用します。 コンシューマーをさまざまなサーバー上で実行して、負荷を分散させることができます。 必要な場合は、システムをスケールアウトするためにコンシューマーを動的に追加し、それ以外の場合は削除できます。
競合コンシューマー パターンは、複数のメッセージを同時に処理してスループットを最適化し、スケーラビリティと可用性を向上させ、さらにワークロードのバランスを取る方法を示しています。
負荷平準化
プロデューサーまたはプロデューサーのグループによって生成されるメッセージの量は変動することがあります。 大量に存在して、メッセージのスパイクが発生する場合があります。 コンシューマーを追加してこの作業を処理する代わりに、メッセージ ブローカーはバッファーとして機能できます。それにより、システムに負荷を与えることなく、コンシューマーは独自のペースで徐々にメッセージをドレインします。
詳細については、「キュー ベースの負荷平準化パターン」を参照してください。
信頼できるメッセージング
メッセージ ブローカーは、プロデューサーとコンシューマーの間の通信が失敗した場合でもメッセージが失われないことを保証するために役立ちます。 プロデューサーはメッセージ ブローカーにメッセージをポストでき、コンシューマーは、通信が再確立されたときにそれを取得できます。 メッセージ ブローカーとの接続が失われない限り、プロデューサーはブロックされません。
回復性があるメッセージング
メッセージ ブローカーは、システム内のコンシューマーに回復性を追加できます。 メッセージの処理中にコンシューマーが失敗した場合は、コンシューマーの別のインスタンスがそのメッセージを処理できます。 そのメッセージはブローカー内に保持されるため、再処理が可能です。
メッセージ ブローカーのためのテクノロジの選択
Azure には、それぞれが一定の範囲の機能を持つ、いくつかのメッセージ ブローカー サービスが用意されています。 サービスを選択する前に、メッセージの意図と要件を確認してください。
Azure Service Bus Messaging
Azure Service Bus Messaging キューは、プロデューサーからコンシューマーへのコマンドの転送に最適です。 次にいくつかの考慮事項を示します。
プル モデル
Service Bus キューのコンシューマーは、新しいメッセージが使用可能かどうかを確認するために Service Bus を常にポーリングします。 そのモデルは、クライアント SDK および Service Bus 用の Azure Functions トリガーに関するページに要約されています。 新しいメッセージが使用可能になると、コンシューマーのコールバックが呼び出され、そのメッセージがコンシューマーに送信されます。
保証された配信
Service Bus を使用すると、コンシューマーはキューをピークし、メッセージを他のコンシューマーからロックできます。
そのメッセージの処理の状態は、コンシューマーが報告します。 コンシューマーがメッセージを使用済みとマークした場合にのみ、Service Bus はそのメッセージをキューから削除します。 エラー、タイムアウト、またはクラッシュが発生した場合、Service Bus はそのメッセージのロックを解除して他のコンシューマーが取得できるようにします。 このようにして、転送中にメッセージが失われることはありません。
プロデューサーが誤って同じメッセージを 2 回送信することがあります。 たとえば、メッセージを送信した後にプロデューサー インスタンスが失敗したとします。 別のプロデューサーが元のインスタンスを引き継ぎ、再度メッセージを送信します。 Azure Service Bus キューは、重複したメッセージを検出して削除する組み込みの重複除外機能を提供します。 それでもまだ、メッセージが 2 回配信される可能性があります。 たとえば、コンシューマーが処理中に失敗した場合、そのメッセージはキューに返され、同じコンシューマーまたは別のコンシューマーによって取得されます。 作業が繰り返された場合でもシステムの状態が変更されないようにするために、コンシューマー内のメッセージ処理ロジックはべき等である必要があります。
メッセージの順序付け
コンシューマーがメッセージを送信された順序で取得するようにしたい場合、Service Bus キューは、セッションを使用して、先入れ先出し (FIFO) の順序による配信を保証します。 セッションには 1 つ以上のメッセージを含めることができます。 メッセージは、SessionId プロパティに関連付けられています。 セッションの一部であるメッセージは期限切れになりません。 セッションをコンシューマーにロックして、そのメッセージが別のコンシューマーによって処理されないようにすることができます。
詳細については、メッセージ セッションに関するページを参照してください。
メッセージの永続性
Service Bus キューは、一時的な切り離しをサポートしています。 コンシューマーは、使用できないか、またはメッセージを処理できない場合でもキュー内に残ります。
実行時間の長いトランザクションにチェックポイントを設ける
ビジネス トランザクションが長時間実行される場合があります。 トランザクション内の各操作に複数のメッセージを含めることができます。 ワークフローを調整し、トランザクションが失敗した場合の回復性を実現するには、チェックポイント機能を使用します。
Service Bus キューでは、セッション状態機能によるチェックポイント機能が可能になります。 状態情報は、セッションに属するメッセージのキュー (SetState) に増分記録されます。 たとえば、コンシューマーは、時々状態 (GetState) を確認することによって進行状況を追跡できます。 コンシューマーが失敗した場合は、別のコンシューマーが状態情報を使用して、セッションを再開するための最後の既知のチェックポイントを特定できます。
配信不能キュー (DLQ)
Service Bus キューには、配信または処理できなかったメッセージを保持するための、配信不能キュー (DLQ) と呼ばれる既定のサブキューがあります。 Service Bus またはコンシューマー内のメッセージ処理ロジックがメッセージを DLQ に追加できます。 DLQ はそれらのメッセージを、それがキューから取得されるまで保持します。
メッセージが最終的に DLQ に格納される可能性がある例を次に示します。
有害メッセージは、形式が不正であるか、または予期しない情報が含まれているために処理できないメッセージです。 Service Bus キューでは、キューの MaxDeliveryCount プロパティを設定することによって有害メッセージを検出できます。 同じメッセージが受信された回数がそのプロパティ値を超えた場合、Service Bus はそのメッセージを DLQ に移動します。
メッセージは、一定の期間内に処理されないと関連性がなくなることがあります。 Service Bus キューでは、プロデューサーは Time-To-Live 属性を含むメッセージをポストできます。 メッセージが受信される前にこの期間が期限切れになると、そのメッセージは DLQ に配置されます。
エラーの原因を特定するには、DLQ 内のメッセージを検証します。
ハイブリッド ソリューション
Service Bus は、オンプレミス システムとクラウド ソリューションをブリッジします。 オンプレミス システムは多くの場合、ファイアウォールの制限のために到達することが困難です。 プロデューサーとコンシューマー (オンプレミスまたはクラウド) はどちらも、Service Bus キュー エンドポイントをメッセージのピックアップとドロップオフの場所として使用できます。
メッセージング ブリッジ パターンは、これらのシナリオを処理するもう 1 つの方法です。
トピックとサブスクリプション
Service Bus は、Service Bus のトピックとサブスクリプションを使用してパブリッシャーとサブスクライバーのパターンをサポートしています。
この機能により、プロデューサーがメッセージを複数のコンシューマーにブロードキャストする方法が提供されます。 トピックがメッセージを受信すると、そのメッセージは、サブスクライブされたすべてのコンシューマーに転送されます。 必要に応じて、サブスクリプションには、コンシューマーがメッセージのサブセットを取得できるようにするフィルター条件を設定できます。 各コンシューマーは、キューと同様の方法でサブスクリプションからメッセージを取得します。
詳細については、Azure Service Bus トピックに関するページを参照してください。
Azure Event Grid
離散イベントには Azure Event Grid をお勧めします。 Event Grid は、パブリッシャーとサブスクライバーのパターンに従います。 イベント ソースがイベントをトリガーすると、そのイベントは Event Grid トピックにパブリッシュされます。 これらのイベントのコンシューマーは、イベントの種類とそのイベントを処理するイベント ハンドラーを指定することによって Event Grid サブスクリプションを作成します。 サブスクライバーが存在しない場合、そのイベントは破棄されます。 各イベントに複数のサブスクリプションを含めることができます。
プッシュ モデル
Event Grid は、メッセージをプッシュ モデルのサブスクライバーに伝播します。 Webhook を使用した Event Grid サブスクリプションがあるとします。 新しいイベントが到着すると、Event Grid は、そのイベントを Webhook エンドポイントにポストします。
Azure との統合
Azure リソースに関する通知を取得したい場合は、Event Grid を選択します。 多くの Azure サービスが、組み込みの Event Grid トピックを持つイベント ソースとして機能します。 Event Grid はまた、イベント ハンドラーとして構成できるさまざまな Azure サービスもサポートしています。 これらのトピックにサブスクライブすると、イベントを任意のイベント ハンドラーに簡単にルーティングできます。 たとえば、BLOB ストレージが作成または削除されたら、Event Grid を使用して Azure 関数を呼び出すことができます。
カスタム トピック
Event Grid と統合されていないアプリケーションまたは Azure サービスからイベントを送信する場合は、カスタム Event Grid トピックを作成します。
たとえば、ビジネス トランザクション全体の進行状況を確認するには、参加している各サービスが個々のビジネス操作を処理しているときにイベントを生成するようにする必要があります。 Web アプリによって、これらのイベントが表示されます。 この作業を完了する 1 つの方法は、カスタム トピックを作成し、HTTP Webhook 経由で登録された Web アプリを使用してサブスクリプションを追加することです。 ビジネス サービスがカスタム トピックにイベントを送信すると、Event Grid はそれを Web アプリにプッシュします。
フィルター処理されたイベント
特定のイベント ハンドラーにイベントのサブセットのみをルーティングするように Event Grid に指示するには、サブスクリプションでフィルターを指定できます。 サブスクリプション スキーマでフィルターを指定します。 フィルターに一致する値を持つトピックに送信されたイベントはすべて、そのサブスクリプションに自動的に転送されます。
たとえば、さまざまな形式のコンテンツが Blob Storage にアップロードされます。 ファイルが追加されるたびに、イベントが生成され、Event Grid にパブリッシュされます。 イベント ハンドラーがサムネイルを生成できるように、イベント サブスクリプションに画像のイベントのみを送信するフィルターが設定されていることがあります。
フィルター処理の詳細については、「Event Grid のイベントのフィルター処理」を参照してください。
高スループット
Event Grid は、リージョンごとに 1 秒あたり 10,000,000 個のイベントをルーティングできます。 毎月の最初の 100,000 操作は無料です。 コストに関する考慮事項については、「Event Grid のコスト」を参照してください。
回復性がある配信
イベントの正常な配信がコマンドほど重要ではないとしても、イベントの種類によっては、引き続き何らかの保証が必要になることがあります。 Event Grid には、再試行ポリシー、期限切れ日時、配信不能処理などの、有効にしてカスタマイズできる機能が用意されています。 詳細については、Event Grid のメッセージの配信と再試行に関する記事を参照してください。
Event Grid の再試行プロセスは回復性に役立ちますが、フェールセーフではありません。 再試行プロセスでは、エンドポイントが長時間無応答である場合、Event Grid はメッセージを複数回配信したり、スキップしたり、一部の再試行を遅延させたりする可能性があります。 詳細については、「再試行のスケジュール」を参照してください。
配信不能処理を有効にすることによって、配信されないイベントを BLOB ストレージ アカウントに保持することができます。 BLOB ストレージ エンドポイントへのメッセージの配信には遅延が発生し、そのエンドポイントが無応答である場合は、Event Grid によってイベントが破棄されます。 詳細については、「配信不能な場所の設定と再試行ポリシー」を参照してください。
Azure Event Hubs
イベント ストリームを操作する場合は、Azure Event Hubs が推奨されるメッセージ ブローカーです。 これは基本的に、短い待ち時間で大量のデータを受信できる大きなバッファーです。 受信されたデータは、同時実行操作ですばやく読み取ることができます。 任意のリアルタイム分析プロバイダーを使用して、受信されたデータを変換できます。 Event Hubs ではまた、イベントをストレージ アカウントに格納する機能も提供されます。
高速な取り込み
Event Hubs は、1 秒あたり数百万のイベントを取り込むことができます。 これらのイベントはストリームにのみ追加され、時間の順に並べられます。
プル モデル
Event Grid と同様に、Event Hubs もパブリッシャーとサブスクライバーの機能を提供しています。 Event Grid と Event Hubs の主な違いは、イベント データをサブスクライバーから使用可能にする方法にあります。 Event Grid が取り込まれたデータをサブスクライバーにプッシュするのに対して、Event Hubs はデータをプル モデルで使用可能にします。 イベントが受信されると、Event Hubs はそれをストリームに追加します。 サブスクライバーはそのカーソルを管理することにより、ストリーム内を前後に移動し、時間オフセットを選択して、自分のペースでシーケンスを再生できます。
ストリーム プロセッサは、変換と統計分析の目的で Event Hubs からデータをプルするサブスクライバーです。 時間枠での集計や異常検出などの複雑な処理には、Azure Stream Analytics および Apache Spark を使用します。
パーティションごとに各イベントに基づいて処理する場合は、イベント処理ホストを使用するか、または Azure Logic Apps などの組み込みのコネクタを使用して変換ロジックを提供することによって、データをプルできます。 別のオプションとして、Azure Functions の使用があります。
パーティション分割
パーティションは、イベント ストリームの一部です。 これらのイベントは、パーティション キーを使用して分割されます。 たとえば、いくつかの IoT デバイスは、イベント ハブにデバイス データを送信します。 パーティション キーはデバイス識別子です。 イベントが取り込まれると、Event Hubs はそれを別のパーティションに移動します。 各パーティション内では、すべてのイベントが時間の順に並べられます。
コンシューマーは、イベント データを処理するコードのインスタンスです。 Event Hubs は、パーティション分割されたコンシューマー パターンに従います。 各コンシューマーは、特定のパーティションのみを読み取ります。 複数のパーティションが存在すると、複数のコンシューマーがストリームを同時に読み取ることができるため、処理が高速化されます。
同じコンシューマーのインスタンスが 1 つのコンシューマー グループを構成します。 複数のコンシューマー グループが、さまざまな意図で同じストリームを読み取ることができます。 イベント ストリームに温度センサーからのデータが含まれているとします。 あるコンシューマー グループは、温度のスパイクなどの異常を検出するためにこのストリームを読み取ることができます。 別のグループは、テンポラル ウィンドウで移動平均温度を計算するために同じストリームを読み取ることができます。
Event Hubs は、複数のコンシューマー グループを許可することによって、パブリッシャーとサブスクライバーのパターンをサポートしています。 各コンシューマー グループがサブスクライバーです。
Event Hubs のパーティション分割の詳細については、「パーティション」を参照してください。
Event Hubs Capture
Capture 機能を使用すると、イベント ストリームを Azure BLOB ストレージまたは Data Lake Storage に格納できます。 イベント格納のこの方法は、ストレージ アカウントが使用できない場合でも Capture が一定の期間データを保持し、アカウントが使用可能になった後にストレージに書き込むため、信頼性に優れています。
ストレージ サービスもまた、イベントの分析のための追加機能を提供できます。 たとえば、BLOB ストレージ アカウントのアクセス層を利用することによって、頻繁なアクセスが必要なデータのホット層にイベントを格納できます。 そのデータを視覚化のために使用できます。 あるいは、データをアーカイブ層に格納し、監査の目的で時々取得することもできます。
Capture は、Event Hubs によって取り込まれたすべてのイベントを格納するため、バッチ処理に役立ちます。 MapReduce 関数を使用して、データに関するレポートを生成できます。 キャプチャされたデータは信頼できるソースとしても機能します。 データの集計中に特定のファクトがなくなっていた場合は、キャプチャされたデータを参照できます。
この機能の詳細については、「Azure Event Hubs で Azure Blob Storage または Azure Data Lake Storage にイベントをキャプチャする」を参照してください。
Apache Kafka クライアントのサポート
Event Hubs は、Apache Kafka クライアントのためのエンドポイントを提供します。 既存のクライアントは、自身の構成をそのエンドポイントを指すように更新し、Event Hubs へのイベントの送信を開始できます。 コードに変更を加える必要はありません。
詳細については、Apache Kafka 用の Event Hubs に関するページを参照してください。
クロスオーバーのシナリオ
2 つのメッセージング サービスを組み合わせると有利になる場合があります。
サービスの組み合わせによって、メッセージング システムの効率が向上することがあります。 たとえば、ビジネス トランザクションでは、Azure Service Bus キューを使用してメッセージを処理します。 コンシューマーは、新しいメッセージがないかどうかを確認するためにキューを常にポーリングしているため、ほとんどアイドル状態で、時々メッセージを受信するキューは非効率的です。 Azure 関数をイベント ハンドラーとして使用して Event Grid サブスクリプションを設定できます。 リッスンしているコンシューマーが存在しないときは、キューがメッセージを受信するたびに Event Grid は通知を送信します。これにより、キューをドレインする Azure 関数が呼び出されます。
Service Bus の Event Grid への接続の詳細については、「Azure Service Bus と Event Grid の統合の概要」を参照してください。
「メッセージ キューとイベントを使用したエンタープライズ統合」参照アーキテクチャは、Service Bus と Event Grid の統合の実装を示しています。
別の例: Event Grid が、一部のイベントはワークフローを必要としているのに対して、その他のイベントは通知を目的としている一連のイベントを受信します。 メッセージ メタデータは、イベントの種類を示します。 区別する 1 つの方法は、イベント サブスクリプションのフィルター機能を使用してメタデータを確認することです。 ワークフローを必要としている場合、Event Grid はそれを Azure Service Bus キューに送信します。 そのキューの受信者は必要なアクションを実行できます。 アラート電子メールを送信するために、通知イベントが Logic Apps に送信されます。
関連するパターン
非同期メッセージングを実装する場合は、次のパターンを検討してください。
- 競合コンシューマー パターン。 複数のコンシューマーに、キューからメッセージを読み取るための競合が必要になる場合があります。 このパターンは、複数のメッセージを同時に処理してスループットを最適化し、スケーラビリティと可用性を向上させ、さらにワークロードのバランスを取る方法を示しています。
- 優先順位キュー パターン。 ビジネス ロジックで、一部のメッセージを処理する前に他のメッセージを処理することが必要な場合のために、このパターンは、コンシューマーが優先順位の高いプロデューサーによってポストされたメッセージを、優先順位の低いコンシューマーによって、プロデューサーのメッセージよりすばやく受信して処理する方法を示しています。
- キュー ベースの負荷平準化パターン。 このパターンでは、プロデューサーとコンシューマーの間のバッファーとして機能するメッセージ ブローカーを使用して、これらの両方のエンティティにかかる断続的な大きい負荷が可用性と応答性に与える影響を最小限に抑えるようにします。
- 再試行パターン。 プロデューサーまたはコンシューマーがキューに接続できなくなる場合がありますが、この失敗の原因は一時的であり、すぐに成功する可能性があります。 このパターンは、この状況に対処してアプリケーションに回復性を追加する方法を示しています。
- Scheduler Agent Supervisor パターン。 メッセージングは多くの場合、ワークフロー実装の一部として使用されます。 このパターンは、メッセージングによって、分散した一連のサービスやその他のリモート リソースにまたがる一連のアクションを調整し、失敗したアクションをシステムで復旧して再試行できるようにする方法を示しています。
- コレオグラフィ パターン。 このパターンは、サービスがメッセージングを使用してビジネス トランザクションのワークフローを制御する方法を示しています。
- クレーム チェック パターン。 このパターンは、大きなメッセージを要求チェックとペイロードに分割する方法を示しています。