このトピックでは、Windows Communication Foundation (WCF) を使用する中間層クライアント アプリケーションに固有のさまざまな問題について説明します。
Middle-Tier クライアントのパフォーマンスの向上
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 クライアント アプリケーションの起動時間を短縮する」を参照してください。