ルーティング シナリオ
ルーティング サービスは自由にカスタマイズできますが、まったく新しい構成を作成するときは、効率的なルーティング ロジックを設計するのが困難である場合があります。 しかし、ほとんどのルーティング サービスの構成で想定されている一般的なシナリオがいくつかあります。 これらのシナリオは、特定の構成に直接、適用できない場合もありますが、これらのシナリオに対応するルーティング サービスの構成方法を理解しておくことは、ルーティング サービスを理解する助けとなります。
一般的なシナリオ
ルーティング サービスの最も基本的な用法は、複数の送信先エンドポイントを集約してクライアント アプリケーションに公開するエンドポイントの数を減らし、その後にメッセージ フィルターを使用して、各メッセージを適切な送信先にルーティングすることです。 メッセージは、論理的または物理的な処理要件 (特定のサービスで処理する必要がある種類のメッセージなど)、または任意のビジネス ニーズ (特定の送信元からのメッセージを優先的に処理するなど) に基づいてルーティングされます。 次の表に、いくつかの一般的なシナリオと、それらが発生する場面の一覧を示します。
| シナリオ | 使用する状況 |
|---|---|
| サービスのバージョン管理 | サービスの複数のバージョンをサポートする必要がある、または更新されたサービスを将来配置する可能性がある場合 |
| サービス データのパーティション分割 | 複数のホストにわたってサービスをパーティション分割する必要がある場合 |
| 動的な更新 | 変化するサービス展開に対処するために、実行時のルーティング ロジックを動的に再構成する必要がある場合 |
| マルチキャスト | 1 つのメッセージを複数のエンドポイントに送信する必要がある場合 |
| プロトコル ブリッジ | 1 つのトランスポート プロトコルでメッセージを受信し、その送信先エンドポイントで別のプロトコルが使用されている場合 |
| エラー処理 | ネットワーク障害と通信障害に対する回復力を提供する必要がある場合 |
Note
ここに示したシナリオの多くは、特定のビジネス ニーズや処理要件に特化したものですが、実行時のルーティング ロジックの変更や、一時的なネットワークおよび通信障害からの回復を可能にする、動的な更新のサポートの計画およびエラー処理の利用は、多くの場合、ベスト プラクティスと見なされます。
サービスのバージョン管理
新しいバージョンのサービスを導入するときは、多くの場合、すべてのクライアントが新しいサービスに移行するまで、以前のバージョンを保持することが必要になります。 これは、サービスが完了までに数日、数週間、または数か月にさえ及ぶ長期の処理になる場合に特に重要です。 この場合、通常は、以前のバージョンのサービスに対して元のエンドポイントを維持したままで、新しいサービスに対して新しいエンドポイント アドレスを実装する必要があります。
ルーティング サービスを使用することで、クライアント アプリケーションからメッセージを受信するための 1 つのエンドポイントを公開し、メッセージの内容に基づいて、各メッセージを適切なバージョンのサービスにルーティングできます。 最も基本的な実装には、メッセージを処理するサービスのバージョンを示すカスタム ヘッダーをメッセージに追加することが含まれます。 ルーティング サービスでは、各メッセージにカスタム ヘッダーがあるかどうかを確認し、メッセージを適切な送信先エンドポイントにルーティングするために XPathMessageFilter を使用できます。
サービスのバージョン管理構成を作成するために使用する手順については、「方法: サービスのバージョン管理」を参照してください。
サービス データのパーティション分割
分散環境を設計するときは、多くの場合、複数のコンピューターに処理負荷を分散することが望ましいとされています。これは、可用性を高め、個々のコンピューターの処理負荷を軽減し、メッセージの特定のサブセットに対して専用のリソースを提供するためです。 ルーティング サービスは負荷分散専用のソリューションに代わるものではありませんが、このサービスが内容に基づくルーティングを実施する機能は、特定の送信先に類似のメッセージをルーティングする方法として使用できます。 この例として、その他のクライアントから受信するメッセージとは別に、特定のクライアントからのメッセージを処理する必要がある場合が挙げられます。
サービス データのパーティション分割構成の作成に使用する手順については、「方法: サービス データのパーティション分割」を参照してください。
動的ルーティング
変化するビジネス ニーズを満たすために、ルーティング構成を変更した方がよい場合がよくあります。たとえば、新しいバージョンのサービスに対してルートを追加する、ルーティング条件を変更する、または、特定のメッセージに対してフィルターがルーティング先とする送信先エンドポイントを変更することが考えられます。 ルーティング サービスでは、RoutingExtension を使用して、新しい RoutingConfiguration を実行時に提供できるため、これが実現されます。 新しい構成は直ちに有効になりますが、ルーティング サービスで処理される任意の新しいセッションのみに適用されます。
動的ルーティングの実装に使用する手順については、「方法: 動的な更新」を参照してください。
マルチキャスト
メッセージをルーティングするときに、通常は、各メッセージを 1 つの特定の送信先エンドポイントにルーティングします。 しかし、メッセージのコピーを複数の送信先エンドポイントにルーティングする必要がある場合もあります。 マルチキャスト ルーティングを実行するには、次の条件を満たしている必要があります。
要求/応答では、要求への応答時にクライアント アプリケーションが受信できるのが 1 つの応答のみであることが要求されるため、チャネル形状が要求/応答でない (一方向または二重のどちらでもよい) ことが必要である。
複数のフィルターでは、メッセージの評価時に true を返す必要がある。
これらの条件を満たす場合、true を返すフィルターと関連付けられた各送信先エンドポイントは、メッセージのコピーを受信します。
プロトコル ブリッジ
メッセージを異種の SOAP プロトコル間でルーティングするときに、ルーティング サービスは、WCF API を使用して、1 つのプロトコルから他のプロトコルにメッセージを変換します。 この処理は、ルーティング サービスが公開するサービス エンドポイントで、メッセージのルーティング先のクライアント エンドポイントとは異なるプロトコルが使用されると自動的に実行されます。 使用されているプロトコルが標準ではない場合は、この動作を無効にすることができますが、ブリッジのための独自のコードを提供する必要があります。
エラー処理
分散環境では、一時的なネットワークまたは通信の障害が発生することは少なくありません。 ルーティング サービスなどの中継局サービスがない場合は、このような障害処理の負担がクライアント アプリケーションにかかることになります。 ネットワークまたは通信の障害発生時に再試行するための特定のロジックと、代替の場所に関する情報がクライアント アプリケーションに含まれていない場合は、メッセージが送信先サービスで正常に処理されるまでに、ユーザーがメッセージを複数回送信することが必要になる可能性があります。 これは、信頼性が低いと見なされる可能性があるため、アプリケーションの顧客満足度の低下につながります。
ルーティング サービスは、ネットワークまたは通信関連の障害発生時のメッセージに対して堅牢なエラー処理機能を提供することで、このシナリオを対処しようとします。 可能な送信先エンドポイントのリストを作成し、このリストを各メッセージ フィルターと関連付けることで、設定可能な送信先が 1 つのみであるために発生する単一障害点を排除します。 障害が発生した場合、ルーティング サービスは、メッセージが配信されるか、通信以外の障害が発生するか、またはすべてのエンドポイントに対する試行が終わるまで、次のエンドポイントにメッセージを配信しようとします。
エラー処理の構成に使用する手順については、「方法: エラー処理」を参照してください。