中間層クライアント アプリケーション
ここでは、Windows Communication Foundation (WCF) を使用する中間層クライアント アプリケーション固有のさまざまな問題について説明します。
中間層クライアントのパフォーマンス向上
ASP.NET を使用する Web サービスといった従来の通信技術と比べ、豊富な機能セットを備えた WCF では、WCF クライアント インスタンスの作成が複雑になる場合があります。 たとえば、ChannelFactory<TChannel> オブジェクトを開いている場合、サービスとの間にセキュリティで保護されたセッションを確立できますが、そのぶんクライアント インスタンスの起動時間が長くなります。 WCF クライアントはいくつかの呼び出しを実行してから閉じるため、通常、このような追加機能がクライアント アプリケーションに大きな影響を与えることはありません。
ただし、中間層クライアント アプリケーションでは、多くの WCF クライアント オブジェクトをすばやく作成できるので、その結果、初期化要件が増加します。 サービスを呼び出すときに中間層アプリケーションのパフォーマンスを向上させる方法は主に 2 つあります。
WCF クライアント オブジェクトをキャッシュし、可能であれば以降の呼び出しでそれを再利用します。
ChannelFactory<TChannel> オブジェクトを作成し、そのオブジェクトを使用して呼び出しごとに新しい WCF クライアント チャネル オブジェクトを作成します。
これらの方法を使用するときに検討すべきいくつかの問題があります。
サービスでセッションを使用してクライアント固有の状態を維持する場合、サービスの状態が中間層クライアントのそれに関連付けられているため、クライアント層の複数の要求を持つ中間層の WCF クライアントを再利用することはできません。
サービスでクライアントごとに認証を実行する必要がある場合、中間層のクライアント資格情報を WCF クライアント (または ChannelFactory<TChannel>) の作成後に変更できないため、中間層の WCF クライアント (または WCF クライアント チャネル オブジェクト) を再利用するのではなく、受信要求ごとに新しいクライアントを中間層に作成する必要があります。
チャネルにより作成されたチャネルとクライアントは、スレッド セーフですが複数のメッセージをネットワークに同時に書き込むことをサポートしていない場合があります。 大容量メッセージ (特にストリーミング) を送信すると、送信操作はブロックされ別の送信が完了するまで待機する場合があります。 チャネルを再利用するサービスに制御フローが戻った場合、これにより、コンカレンシーの欠如とデッドロックの可能性という 2 種類の問題が発生します (つまり、共有クライアントがサービスを呼び出すと、そのコード パスは結果的に共有クライアントにコールバックします)。 これは、再利用する WCF クライアントの型には左右されません。
チャネルを共有しているかどうかに関係なく、エラーの発生したチャネルを処理する必要があります。 ただし、チャネルを再利用するときに、エラーの発生しているチャネルは複数の保留中の要求を削除するか送信することができます。
複数の要求に対してクライアントを再利用するためのベスト プラクティスが示された例については、「ASP.NET クライアントでのデータ バインディング」を参照してください。
さらに、XmlSerializer を使用してシリアル化できるデータ型を使用するクライアントの起動時のパフォーマンスを向上したり、実行時にこのようなデータ型のシリアル化コードを生成およびコンパイルしたりすることができます (この場合、起動時のパフォーマンスが低下することがあります)。 ServiceModel メタデータ ユーティリティ ツール (Svcutil.exe) を使用すると、必要なシリアル化コードをアプリケーションのコンパイル済みアセンブリから生成することで、このようなアプリケーションの起動時のパフォーマンスを改善できます。 詳細については、「方法: XmlSerializer を使用する WCF クライアント アプリケーションの起動時間を短縮する」を参照してください。