私は、WCF のディスパッチ プロセス、特にさまざまな拡張ポイントへの影響と効果をよりよく理解しようとしています。下部にリストされている Web ページから、メッセージがチャネル スタックによってディスパッチャーに渡されると、WCF は次の順序で次の処理を実行するように見えます。
- メッセージインスペクター
- 操作セレクター
- メッセージのフォーマット
- パラメーター インスペクター
- オペレーション・インボーカー。
私が抱えている問題を解決するためのいくつかのオプションを見つけようとしています。私が考えている 1 つの方法は、Message Inspector、Operation Selector、Message Formatting、および Operation Invoker を組み合わせて使用することです。残念ながら、私の観察では、実行の順序は次のようになっているようです。
- 操作セレクター
- メッセージインスペクター
- 操作呼び出し元 (AllocateInputs())
- メッセージのフォーマット
- パラメーター インスペクター
- 操作呼び出し元 (Invoke())
Message Formatting セクションでは、特定のメッセージを一連のメソッド引数にデシリアライズして、適切な操作と呼び出し元の AllocateInputs( ) メソッドは、予想されるパラメーターの数を指定します。
私をスローする部分は、Message Inspector と Operation Selector の間のシーケンスの反転です。操作セレクターがメッセージの対象となるサービス操作を決定するのに対し、メッセージ インスペクターがメッセージに作用するときに最初に実行されるのは理にかなっているように思えます。
質問:
- これは、WCF のバージョンまたはリリースが異なるためですか?
- これは、WCF が拡張ポイントの実行順序を実際に指定していないためでしょうか。
参照ページ:
カスタム データ形式をサポートするための WCFの拡張- Zulfiqar のウェブログ
カスタム動作による WCFの拡張- MSDN サービス ステーション 2007 年 12 月
メッセージ フロー インターセプト ポイント- Nicholas Allen の Indigo ブログ
注: リンクを提供していないことをお詫びします。私はまだ初心者なので、リンクを複数持つことはできません。=)