フィルタ処理
Windows Communication Foundation (WCF) フィルタ処理システムは、宣言的なフィルタを使用してメッセージの照合処理と操作上の判断を行います。フィルタを使用してメッセージの一部を調べることで、そのメッセージで必要な操作を決定できます。たとえば、キュー プロセスでは、XPath 1.0 クエリを使用して既知のヘッダー優先度要素をチェックし、メッセージをキューの先頭に移動するべきかどうかを決定します。
フィルタ処理システムは、特定の WCF メッセージに対して、どのフィルタのセットが true であるかを効率よく判断できる一連のクラスから構成されます。
フィルタ処理システムは、WCF メッセージングの中核となるコンポーネントであり、非常に高速に動作するように設計されています。フィルタの各実装は、WCF メッセージの特定の種類の照合に対して最適化されています。
フィルタ処理システムは、スレッド セーフではありません。アプリケーションは、すべてのロック セマンティクスを処理する必要があります。ただし、(スレッドに対する) マルチ リーダー/シングル ライタはサポートされています。
フィルタ処理が適する場合
フィルタ処理は、メッセージを適切なアプリケーション コンポーネントにディスパッチする処理の一部であり、メッセージの受信後に行われます。フィルタ処理システムの設計では、WCF のいくつかのサブシステム (メッセージング、ルーティング、セキュリティ、イベント処理、およびシステム管理など) の要件に対処します。
フィルタ
フィルタ エンジンには、フィルタとフィルタ テーブルという 2 つの主要コンポーネントが含まれます。フィルタは、ユーザーが指定した論理条件に基づいてメッセージに関する論理判定を行います。フィルタは MessageFilter クラスを実装します。
メッセージがフィルタの一致条件を満たしているかどうかを判定するには、Match メソッドを使用します。これらのメソッドの中の 1 つは、メッセージのヘッダーをテストしますが、メッセージ本文は検査できません。他のメソッドは入力パラメータとしてメッセージ バッファを取得し、メッセージ本文の検査が可能です。
通常、フィルタは個別にテストされるのではなく、フィルタ テーブルの一部としてテストされます。フィルタ テーブルは、CreateFilterTable メソッドによって作成されるジェネリック クラスです。
数種類のフィルタがあり、それぞれが特定の種類のブール型の条件での照合処理に特化されています。フィルタを作成した後に、フィルタが使用する条件を変更することはできません。フィルタの条件を変更するには、新しいフィルタを作成し、既存のフィルタを削除します。
アクション フィルタ
ActionMessageFilter には、アクション文字列の一覧が含まれます。フィルタの一覧にあるアクションのいずれかが、メッセージまたはメッセージ バッファにある Action ヘッダーに一致した場合、Match メソッドは true を返します。この一覧が空である場合、フィルタはすべてに一致するフィルタと見なされるため、メッセージまたはメッセージ バッファはすべて一致することになり、Match メソッドは true を返します。フィルタの一覧にあるすべてのアクションが、メッセージまたはメッセージ バッファにある Action ヘッダーに一致しない場合、Match メソッドは false を返します。メッセージにアクションがなく、フィルタの一覧が空でない場合、Match メソッドは false を返します。
エンドポイント アドレス フィルタ
EndpointAddressMessageFilter は、メッセージのヘッダー コレクションに示されるエンドポイント アドレスに基づいて、メッセージおよびメッセージ バッファのフィルタ処理を行います。メッセージがこのようなフィルタを通過するには、次の条件を満たす必要があります。
- フィルタのアドレス URI (Uniform Resource Identifier) がメッセージの To ヘッダーのアドレスと同じであること。
- フィルタのアドレス (address.Headers コレクション) にある各エンドポイント パラメータが、マッピング対象のヘッダーをメッセージ内で見つけることができること。メッセージまたはメッセージ バッファの追加のヘッダーは、一致をtrue の状態にしておくためであれば、許容されます。
プレフィックス エンドポイント アドレス フィルタ
- PrefixEndpointAddressMessageFilter は、メッセージ URI のプレフィックスとも一致できるという点を除けば、EndpointAddressMessageFilter フィルタと同じように動作します。たとえば、アドレス http://www.adatum.com を指定したフィルタは、http://www.adatum.com/userA 宛のメッセージと一致します。
XPath メッセージ フィルタ
XPathMessageFilter は、XPath 式を使用して、XML ドキュメントに特定の要素、属性、テキスト、その他の XML 構文が含まれているかどうかを判定します。このフィルタは、XPath の厳密なサブセットに対して非常に効率的に処理できるように最適化されています。XML Path 言語の詳細については、W3C XML Path Language 1.0 の仕様を参照してください。
アプリケーションは通常、エンドポイントで XPathMessageFilter を使用して SOAP メッセージの内容を問い合わせ、その結果に基づいて適切なアクションを実行します。たとえば、キューの処理では、XPath クエリを使用して既知のヘッダーの優先度要素を検査し、メッセージをキューの先頭に移動するべきかどうかを決定します。
フィルタ テーブル
フィルタ テーブルは、キーと値のペアを保存するために使用されます。ここで、フィルタがキーであり、これに関連するデータが値になります。このフィルタ データは、メッセージがフィルタに一致した場合に起きるアクションを示すために使用することができ、その型はフィルタ テーブル クラスのジェネリック パラメータになります。フィルタ データは、ルーティングのルール、セッション セキュリティの状態、チャネル上のリスナなどで構成できます。データは、データ フロー制御が必要な場所で使用できます。
フィルタ テーブルは、IMessageFilterTable ジェネリック インターフェイスを実装します。
フィルタ テーブルには、テーブル内のすべてのフィルタに対してメッセージとの一致を調べて、一致したフィルタまたはデータの順序付けられていないコレクションを返すメソッドがいくつかあります。メソッドの中には複数回の一致を調べて、一致したすべての項目を返すものもあります。それ以外のメソッドは 1 回だけの一致となり、1 つの項目のみを返し、フィルタが複数回一致する場合には、MultipleFilterMatchesException をスローします。
メッセージ フィルタ テーブル
MessageFilterTable は、IMessageFilterTable の最も一般的な実装です。このテーブルには、すべての種類のフィルタを格納できます。
フィルタには数字による優先順位を割り当てることができます。一番大きな数が最も高い優先順位となります。複数の種類のフィルタが、同じ優先度を持つことができます。また特定の種類のフィルタが、複数の優先順位レベルに現れることもできます。
照合処理は優先順位が最も高いフィルタから開始され、ある優先順位で一致するフィルタが見つかると、それよりも優先順位の低いフィルタは検査されません。そのため、フィルタが 1 回だけ一致するメソッドを使用しているときに、あるメッセージに対してフィルタの一致が複数回発生した場合、一致フィルタの優先順位がそれぞれ異なっていれば、例外はスローされず、最も優先順位の高いフィルタが返されます。同様に、複数回フィルタが一致するメソッドでも、優先順位が最も高い一致フィルタのみが返されます。
XPath メッセージ フィルタ テーブル
XPathMessageFilterTable は宣言的な XPath フィルタに最適化されているため、テーブル キーは XPathMessageFilter になります。
XPathMessageFilterTable クラスは、ほとんどのメッセージ シナリオをカバーし、XPath 1.0 の文法を完全にサポートする XPath のサブセットに近づけるようマッチングを最適化します。また、効率的な並列マッチング用のアルゴリズムも最適化します。
このテーブルには、XPathNavigator および SeekableXPathNavigator 上で動作する特殊な Match メソッドがいくつかあります。SeekableXPathNavigator は、CurrentPosition プロパティを追加することで、XPathNavigator クラスを拡張します。このプロパティを使用すると、ナビゲータを複製せずに XML ドキュメント内の位置を迅速に保存し、読み込むことができます。XPathNavigator を使用してそうした操作を行うには、大量のメモリ領域を割り当てる必要があります。WCF XPath エンジンでは、XML ドキュメントでクエリの実行中にカーソルの位置を頻繁に記録する必要があるため、SeekableXPathNavigator により、メッセージ処理にとって重要な最適化が提供されます。
顧客シナリオ
フィルタ処理は、メッセージに含まれるデータに応じて、異なる処理モジュールにメッセージを送信する必要がある場合に、いつでも使用できます。一般的なのは、アクション コードに基づいてメッセージをルーティングするシナリオと、メッセージのエンドポイント アドレスに基づいてメッセージのストリームを分離化するシナリオの 2 つです。
ルーティング
エンドポイントのリスナは、メッセージの SOAP ヘッダーに 1 つ以上のアクション コードが含まれるメッセージをリッスンします。これは、アクション コードを含む配列をコンストラクタに渡して ActionMessageFilter を作成することで実装します。このフィルタは、ListenerFactory に登録するために使用されるため、アクションがフィルタ内のアクション コードのいずれかと一致するメッセージだけが特定のエンドポイントに到達します。
分離化
複数のエンドポイントがネットワーク上の同じ ServiceListener から分散している場合、メッセージを分離化し、メッセージが特定のエンドポイント アドレスに属しているかどうかを確認する唯一の方法は、EndpointAddressMessageFilter を使用することです。このフィルタは、ヘッダーに格納されている情報に対して検索を実行して、登録されているエンドポイントに向けられたメッセージを選択します。このようなフィルタを通過するのは、次の両方に対応する必要なヘッダーをすべて持っているメッセージだけです。
- EndpointAddress にある URI
- EndpointAddressMessageFilter で指定された EndpointAddress にある残りのエンドポイント パラメータ