クライアントを使用したサービスへのアクセス

[アーティクル]
09/12/2008

クライアントアプリケーションがサービスと通信するには、クライアントアプリケーションで WCF クライアントまたはチャネルを作成および構成し、使用する必要があります。「WCF クライアントの概要」では、オブジェクトの概要および基本的なクライアントやチャネルオブジェクトの作成と使用に関する手順を説明しています。

このトピックでは、ユーザーのシナリオに応じて役立つ、クライアントアプリケーション、クライアントオブジェクト、およびチャネルオブジェクトに関するいくつかの問題について詳しく説明します。

概要

ここでは、以下の項目に関連する動作と問題について説明します。

チャネルとセッションの有効期間
例外処理
ブロックの問題について
対話方式によるチャネルの初期化

チャネルとセッションの有効期間

Windows Communication Foundation (WCF) アプリケーションのチャネルは、データグラムチャネルとセッションフルチャネルの 2 つに分類されます。

データグラム チャネルは、含まれているすべてのメッセージとの相関関係のないチャネルです。データグラムチャネルでは、入出力操作が失敗しても、通常、次の操作は影響を受けないので、同じチャネルの再利用が可能です。したがって、通常、データグラムチャネルは失敗になりません。

一方、セッションフル チャネルは、他のエンドポイントと関連付けられたチャネルです。一方のセッション内のメッセージは、他方の同じセッションと常に関連付けられています。さらに、セッションが成功したとみなされるためには、セッションの両参加要素が、メッセージ交換要件が満たされたということに同意する必要があります。両参加要素が同意できない場合、セッションチャネルは失敗になる場合があります。

クライアントを明示的に開く場合も暗黙的に開く場合も、最初の操作を呼び出します。

メモ :
一般的に、障害が生じたセッションフルチャネルを明示的に検出することは有用ではありません。通知されるタイミングがセッションの実装により異なるためです。たとえば、System.ServiceModel.NetTcpBinding (信頼できるセッションは無効) では TCP 接続のセッションが表面に出るため、サービスまたはクライアントで System.ServiceModel.ICommunicationObject.Faulted イベントをリッスンしていれば、ネットワークエラーが発生すると直ちに通知される可能性があります。一方、信頼できるセッション (System.ServiceModel.Channels.ReliableSessionBindingElement を有効化したバインディングにより確立される) は、サービスが小さなネットワークエラーから分離されるように設計されています。妥当な期間内にセッションの再確立が可能な場合、信頼できるセッション用に構成された、この同じバインディングは、中断が長期間発生し続けるまでエラーにならない場合があります。

一般的に、障害が生じたセッションフルチャネルを明示的に検出することは有用ではありません。通知されるタイミングがセッションの実装により異なるためです。たとえば、System.ServiceModel.NetTcpBinding (信頼できるセッションは無効) では TCP 接続のセッションが表面に出るため、サービスまたはクライアントで System.ServiceModel.ICommunicationObject.Faulted イベントをリッスンしていれば、ネットワークエラーが発生すると直ちに通知される可能性があります。一方、信頼できるセッション (System.ServiceModel.Channels.ReliableSessionBindingElement を有効化したバインディングにより確立される) は、サービスが小さなネットワークエラーから分離されるように設計されています。妥当な期間内にセッションの再確立が可能な場合、信頼できるセッション用に構成された、この同じバインディングは、中断が長期間発生し続けるまでエラーにならない場合があります。

アプリケーション層にチャネルを公開するほとんどのシステム提供のバインディングでは、既定でセッションが使用されますが、System.ServiceModel.BasicHttpBinding では使用されません。詳細な情報については、次のページを参照してください。「セッションの使用」を参照してください。

セッションの適切な使用

セッションを使用すると、メッセージ交換全体が完了したかどうか、そしてメッセージ交換が成功したと両側が見なしたかどうかを認識できます。呼び出し側のアプリケーションでは、チャネルを開き、使用して、閉じるまでを 1 つの try ブロック内で処理することをお勧めします。セッションチャネルが開いているときに、System.ServiceModel.ICommunicationObject.Close メソッドを 1 回呼び出して、その呼び出しが正常に返された場合、セッションは成功しています。この場合の成功とは、バインディングにより指定されているすべての配信保証が満たされ、もう一方の側では Close を呼び出す前にチャネルに対して System.ServiceModel.ICommunicationObject.Abort を呼び出さなかったことを意味します。

次のセクションで、このクライアントによる方法の例を示します。

例外処理

クライアントアプリケーションで例外を処理することは簡単です。try ブロック内部でチャネルを開き、使用して、閉じた場合、例外がスローされない限り、メッセージ交換は正常に行われています。通常、例外がスローされた場合は、メッセージ交換が中止されます。

メモ :
using ステートメント (Visual Basic では Using) を使用することはお勧めできません。その理由は、using ステートメントの最後で例外が発生し、認識する必要のある他の例外がマスクされる可能性があるためです。詳細な情報については、次のページを参照してください。「Avoiding Problems with the Using Statement」を参照してください。

using ステートメント (Visual Basic では Using) を使用することはお勧めできません。その理由は、using ステートメントの最後で例外が発生し、認識する必要のある他の例外がマスクされる可能性があるためです。詳細な情報については、次のページを参照してください。「Avoiding Problems with the Using Statement」を参照してください。

次のコード例は、using 文ではなく try/catch ブロックを使用する、推奨されるクライアントパターンを示しています。

メモ :
System.ServiceModel.ICommunicationObject.State プロパティの値を確認すると競合状態になるので、チャネルを再利用するかどうか、またはチャネルを閉じるかどうかを決定するのにこの値を確認することは推奨されません。

データグラムチャネルを閉じるときに例外が発生しても、データグラムチャネルはエラーになりません。さらに、非双方向クライアントがセキュリティで保護されたメッセージ交換を使用して認証に失敗した場合、通常、System.ServiceModel.Security.MessageSecurityException がスローされます。しかし、双方向クライアントがセキュリティで保護されたメッセージ交換を使用して認証に失敗した場合、クライアントは代わりに System.TimeoutException を受信します。

アプリケーションレベルでのエラー情報の処理の詳細については、「コントラクトおよびサービスのエラーの指定と処理」を参照してください。予期される例外とその処理方法については、「Expected Exceptions」を参照してください。チャネル開発時のエラーの処理方法詳細については、、「例外とエラーの処理」を参照してください。

クライアントのブロックとパフォーマンス

アプリケーションが要求/応答操作を同期的に呼び出す場合、戻り値が受信されるか例外 (System.TimeoutException など) がスローされるまで、クライアントはブロックされます。この動作はローカルの動作と似ています。アプリケーションが WCF クライアントオブジェクトまたはチャネルに対する操作を同期的に呼び出す場合、チャネルレイヤがデータをネットワークに書き込むことができるまで、または例外がスローされるまで、クライアントに制御は戻りません。また、一方向メッセージ交換パターン (System.ServiceModel.OperationContractAttribute.IsOneWay が true に設定された操作をマークすることで指定される) では、クライアントの応答性が向上する可能性がありますが、バインディングや送信済みのメッセージによっては、一方向操作でもブロックが生じる場合があります。一方向操作とはメッセージ交換のみを指しています。詳細な情報については、次のページを参照してください。「一方向サービス」を参照してください。

メッセージ交換パターンに関係なく、大規模データのチャンクによりクライアント処理が遅延する場合があります。この問題の処理方法を理解するには、「大規模データとストリーミング」を参照してください。

操作が完了してもアプリケーションでさらに処理を行う必要がある場合、WCF クライアントが実装するサービスコントラクトインターフェイスに非同期のメソッドのペアを作成する必要があります。これを行うには、ServiceModel Metadata Utility Tool (Svcutil.exe) で /async スイッチを使用するのが最も簡単な方法です。例については、「方法 : WCF サービス操作を非同期に呼び出す」を参照してください。

クライアントのパフォーマンス向上詳細については、、「中間層クライアントアプリケーション」を参照してください。

ユーザーによる資格情報の動的選択の有効化

IInteractiveChannelInitializer インターフェイスを使用すると、アプリケーションによりユーザーインターフェイスが表示され、ユーザーが資格情報を選択できるようになります。この資格情報は、タイムアウトタイマが開始される前に、チャネルの作成に使用されます。

アプリケーション開発者は、挿入された IInteractiveChannelInitializer を 2 つの方法で利用できます。チャネルを開く前 (明示的方法)、または最初の操作を呼び出す前 (暗黙的方法) に、クライアントアプリケーションで System.ServiceModel.ClientBase.DisplayInitializationUI または System.ServiceModel.IClientChannel.DisplayInitializationUI (または非同期バージョン) を呼び出すことができます。

暗黙的方法を使用する場合、アプリケーションは最初の操作を ClientBase または IClientChannel 拡張に対して呼び出す必要があります。アプリケーションが最初の操作以外の何かを呼び出した場合、例外がスローされます。

明示的方法を使用する場合、アプリケーションで次の手順を順番に実行する必要があります。

System.ServiceModel.ClientBase.DisplayInitializationUI または System.ServiceModel.IClientChannel.DisplayInitializationUI (または非同期バージョン) を呼び出します。
初期化子が返された場合は、IClientChannel オブジェクトまたは System.ServiceModel.ClientBase.InnerChannel プロパティで返された IClientChannel オブジェクトの Open メソッドを呼び出します。
操作を呼び出します。

製品品質のアプリケーションでは、明示的な方法を採用することによってユーザーインターフェイスのプロセスを制御することをお勧めします。

暗黙的な方法を使用するアプリケーションでは、ユーザーインターフェイス初期化子が呼び出されますが、このアプリケーションのユーザーがバインディングの送信タイムアウト期間内に応答できない場合、ユーザーインターフェイスが復帰すると例外がスローされます。

次の方法で共有