次の方法で共有


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

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

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

概要

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

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

  • 例外処理

  • ブロックの問題について

  • 対話方式によるチャネルの初期化

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

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

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

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

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

ms733912.note(ja-jp,VS.100).gif注 :
一般的に、障害が生じたセッションフル チャネルを明示的に検出することは有用ではありません。通知されるタイミングがセッションの実装により異なるためです。たとえば、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 ブロック内部でチャネルを開き、使用して、閉じた場合、例外がスローされない限り、メッセージ交換は正常に行われています。通常、例外がスローされた場合は、メッセージ交換が中止されます。

ms733912.note(ja-jp,VS.100).gif注 :
using ステートメント (Visual Basic では Using) を使用することはお勧めできません。その理由は、using ステートメントの最後で例外が発生し、認識する必要のある他の例外がマスクされる可能性があるためです。詳細については、次のトピックを参照してください。、「Using ステートメントに関する問題の回避」を参照してください。

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

Imports System
Imports System.ServiceModel
Imports System.ServiceModel.Channels
Imports Microsoft.WCF.Documentation

Public Class Client
  Public Shared Sub Main()
    ' Picks up configuration from the config file.
    Dim wcfClient As New SampleServiceClient()
    Try
      ' Making calls.
      Console.WriteLine("Enter the greeting to send: ")
      Dim greeting As String = Console.ReadLine()
      Console.WriteLine("The service responded: " & wcfClient.SampleMethod(greeting))

      Console.WriteLine("Press ENTER to exit:")
      Console.ReadLine()

      ' Done with service. 
      wcfClient.Close()
      Console.WriteLine("Done!")
    Catch timeProblem As TimeoutException
      Console.WriteLine("The service operation timed out. " & timeProblem.Message)
      Console.ReadLine()
      wcfClient.Abort()
    Catch greetingFault As FaultException(Of GreetingFault)
      Console.WriteLine(greetingFault.Detail.Message)
      Console.ReadLine()
      wcfClient.Abort()
    Catch unknownFault As FaultException
      Console.WriteLine("An unknown exception was received. " & unknownFault.Message)
      Console.ReadLine()
      wcfClient.Abort()
    Catch commProblem As CommunicationException
      Console.WriteLine("There was a communication problem. " & commProblem.Message + commProblem.StackTrace)
      Console.ReadLine()
      wcfClient.Abort()
    End Try
  End Sub
End Class
ms733912.note(ja-jp,VS.100).gif注 :
System.ServiceModel.ICommunicationObject.State プロパティの値を確認すると競合状態になるので、チャネルを再利用するかどうか、またはチャネルを閉じるかどうかを決定するのにこの値を確認することは推奨されません。

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

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

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

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

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

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

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

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

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

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

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

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

  1. System.ServiceModel.ClientBase.DisplayInitializationUI または System.ServiceModel.IClientChannel.DisplayInitializationUI (または非同期バージョン) を呼び出します。

  2. 初期化子が返された場合は、IClientChannel オブジェクトまたは System.ServiceModel.ClientBase.InnerChannel プロパティで返された IClientChannel オブジェクトの Open メソッドを呼び出します。

  3. 操作を呼び出します。

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

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

参照

処理手順

方法 : 一方向コントラクトと要求/応答コントラクトを使用して WCF サービスにアクセスする
方法 : 双方向コントラクトを使用してサービスにアクセスする
方法 : WCF クライアントで WSE 3.0 サービスにアクセスする
方法 : ChannelFactory を使用する
方法 : WCF サービス操作を非同期に呼び出す

概念

双方向サービス
中間層クライアント アプリケーション