Обращение к службам с использованием клиента

Статья
02/28/2011

Клиентские приложения должны создавать, настраивать и использовать клиент WCF или объекты канала для связи со службами. В разделе Общие сведения о клиентах WCF описаны объекты и этапы создания основного клиента и объектов канала, а также их использование.

В разделе приводится подробная информация о некоторых проблемах с приложениями клиента и объектами клиента и канала, которые могут пригодиться в зависимости от вашего сценария.

Общие сведения

В разделе описаны поведение и проблемы, связанные со следующими пунктами.

Каналы и время существования сеанса.
Обработка исключений.
Понимание блокирующих проблем.
Интерактивная инициализация каналов.

Каналы и время существования сеанса

Приложения Windows Communication Foundation (WCF) включают две категории каналов: датаграмма и сеанс.

Канал датаграммы — это канал, в котором все сообщения являются некоррелированными. При использовании канала датаграммы на последующую операцию обычно не влияет то, что операция ввода или вывода не удалась, и тот же канал может быть использован повторно. По этой причине в каналах датаграмм обычно не возникает сбоев.

Каналы сеанса, однако, являются каналами с подключением к другой конечной точке. Сообщения в сессии всегда коррелируют с таким же сеансом с другой стороны. Кроме того, между участниками сеанса должно быть соглашение, описывающее требования к их диалогу, которые, для того чтобы сеанс считался успешным, должны быть удовлетворены. Если такого соглашения между участниками нет, в канале сеанса может возникнуть ошибка.

Откройте клиенты явно или неявно, вызвав первую операцию.

Примечание
Попытка явно обнаружить каналы сеанса со сбоем обычно оказывается полезной, поскольку то, когда вы будете оповещены, зависит от реализации сеанса. Например, поскольку 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 этого не делает. Дополнительные сведения см. в разделе Использование сеансов.

Правильное использование сеансов

Сеансы являются способом, с помощью которого можно узнать, полностью ли был завершен обмен сообщением и обе ли стороны считают его успешным. Рекомендуется, чтобы вызывающее приложение открыло канал, использовало его и закрыло канал внутри одного блока try. Если канал сеанса открыт и однократно вызван метод System.ServiceModel.ICommunicationObject.Close, и данный вызов успешно возвращается, значит сеанс был успешен. "Успешный" в данном случае означает, что все гарантии доставки, заданные привязкой, были обеспечены и другая сторона не вызвала System.ServiceModel.ICommunicationObject.Abort в канале перед вызовом Close.

В следующем разделе показан пример данного подхода к клиенту.

Обработка исключений

Обработка исключений в приложениях клиента является прямой. Если канал открыт, использован и закрыт внутри одного блока try, диалог был успешен, кроме случая, если было выдано исключение. Обычно при выдаче исключения диалог прерывается.

Примечание
Использование оператора using (Using в Visual Basic) не рекомендуется. Это связано с тем, что конец оператора using может привести к исключениям, которые могут маскировать другие исключения, о которых вам, возможно, нужно знать. Дополнительные сведения см. в разделе Предотвращение проблем при использовании операторов.

Использование оператора using (Using в Visual Basic) не рекомендуется. Это связано с тем, что конец оператора using может привести к исключениям, которые могут маскировать другие исключения, о которых вам, возможно, нужно знать. Дополнительные сведения см. в разделе Предотвращение проблем при использовании операторов.

В приведенном ниже примере кода демонстрируется рекомендуемый шаблон клиента с помощью блока try/catch, а не с помощью оператора using.

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

Примечание
Проверка значения свойства System.ServiceModel.ICommunicationObject.State является состоянием гонки и не рекомендуется для определения ситуации, когда канал можно использовать повторно или когда его нужно закрыть.

Каналы датаграммы не дают сбой, даже если исключения происходят при их закрытии. Кроме того, недуплексные клиенты, которые не смогли пройти проверку с помощью защищенного диалога, как правило, создают исключение System.ServiceModel.Security.MessageSecurityException. Однако если дуплексному клиенту, использующему защищенный диалог, не удается пройти проверку, клиент получает вместо этого исключение System.TimeoutException.

Подробную информацию о работе с информацией об ошибке на уровне приложения см. в разделе Задание и обработка сбоев в контрактах и службах. В Ожидаемые исключения описываются ожидаемые исключения и показано, как обрабатывать их. Дополнительные сведения том, как обрабатывать ошибки при создании каналов, см. Обработка исключений и сбоев.

Блокировка и производительность клиента

Когда приложение синхронно вызывает операцию типа запрос-ответ, клиент блокируется до тех пор, пока не будет получено возвращаемое значение или создано исключение (такое как System.TimeoutException). Такое поведение аналогично локальному поведению. Когда приложение синхронно вызывает операцию объекта клиента или канала WCF, клиент ничего не возвращает до тех пор, пока уровень канала сможет записать данные в сеть или до тех пор, пока не будет создано исключение. И до тех пор, пока шаблон одностороннего обмена сообщениями (заданный маркировкой операции с помощью System.ServiceModel.OperationContractAttribute.IsOneWay, которому присвоено значение true) повышает реакцию некоторых клиентов, односторонние операции также блокируются, в зависимости от привязки и того, какие сообщения уже были отправлены. Односторонние операции относятся только к обмену сообщениями, не больше и не меньше. Дополнительные сведения см. в разделе One-Way Services.

Большие порции данных могут замедлить обработку клиента, независимо от шаблона обмена сообщениями. Чтобы понять, как работать с данными проблемами, см. Большие наборы данных и потоковая передача.

Если ваше приложение должно выполнять больше работы при завершении операции, необходимо создать пару асинхронных методов интерфейса контракта службы, которую реализует клиент WCF. Самым простым способом сделать это является использование параметра /async в Служебное средство ServiceModel Metadata Utility Tool (Svcutil.exe). Пример см. в разделе Как асинхронно вызывать операции службы WCF.

Дополнительные сведения увеличении производительности клиента см. Клиентские приложения среднего уровня.

Включение динамического выбора учетных данных пользователем

Интерфейс IInteractiveChannelInitializer позволяет приложениям отображать интерфейс пользователя, что позволяет пользователю выбирать учетные данные пользователя с которыми канал создается до того, как запустятся таймеры периода времени.

Разработчики приложений могут использовать вставленный IInteractiveChannelInitializer двумя способами. Приложение клиента может вызвать либо метод System.ServiceModel.ClientBase.DisplayInitializationUI, либо метод System.ServiceModel.IClientChannel.DisplayInitializationUI (или асинхронную версию) до открытия канала (явный подход), либо просто вызвать первую операцию (неявный подход).

Если использовать неявный подход, то приложение должно вызвать первую операцию в расширении ClientBase или IClientChannel. Если приложение вызовет что-либо другое вместо первой операции, будет создано исключение.

Если использовать явный подход, то приложение должно выполнить следующие шаги по порядку:

Вызывать либо System.ServiceModel.ClientBase.DisplayInitializationUI, либо System.ServiceModel.IClientChannel.DisplayInitializationUI (или асинхронную версию).
После возвращения инициализаторов вызвать либо метод Open в объекте IClientChannel, либо в объекте IClientChannel, возвращенном из свойства System.ServiceModel.ClientBase.InnerChannel.
Операции вызова.

Рекомендуется, чтобы приложения для промышленного применения управляли процессом пользовательского интерфейса в соответствии с явным подходом.

Приложения, использующие неявный подход, вызывают инициализаторы интерфейса пользователя, но если пользователь приложения не сможет ответить в отведенный период времени привязки для отправки, то при возвращении пользовательского интерфейса создается исключение.

См. также

Задачи

Практическое руководство. Доступ к службам WCF с односторонним контрактом и контрактом типа «запрос-ответ»
Практическое руководство. Доступ к службам с дуплексным контрактом
Как обращаться к службе WSE 3.0 с помощью клиента WCF
Как использовать ChannelFactory
Как асинхронно вызывать операции службы WCF

Основные понятия

Дуплексные службы
Клиентские приложения среднего уровня

Поделиться через