Acceso a los servicios utilizando un cliente

Las aplicaciones cliente deben crear, configurar y utilizar el cliente WCF u objetos de canal para comunicarse con los servicios. El tema Introducción a un cliente WCF proporciona información general de los objetos y pasos a seguir a la hora de crear un cliente básico y objetos de canal y utilizarlos.

Este tema proporciona información detallada sobre algunos de los problemas surgidos en las aplicaciones cliente y clientes y objetos de canal que pueden ser útiles en función de su escenario.

Información general

Este tema describe el comportamiento y problemas relacionados con:

• Canal y duraciones de la sesión.

• Control de excepciones

• Entender los problemas que ocasionan el bloqueo.

• Inicializar los canales interactivamente .

Duración de canales y sesiones

Las aplicaciones Windows Communication Foundation (WCF) incluyen dos categorías de canales, datagrama y canal con sesión.

Un canal del datagrama es un canal en el que todos los mensajes no están correlacionados. Con un canal de datagrama, si una operación de entrada o de salida produce un error, normalmente la operación siguiente no estará afectada y se puede reutilizar el mismo canal. Por ello, normalmente, los canales de datagrama no producen errores.

Los canales con sesión, sin embargo, son canales con una conexión al otro extremo. Los mensajes de una sesión en un lado siempre están correlacionados con la misma sesión en el otro lado. Además, para que se considere correcta está sesión, ambos participantes de una sesión deben coincidir en que los requisitos de su conversación se han cumplido. Si no pueden coincidir, el canal con sesión puede producir un error.

Abra explícitamente o implícitamente los clientes llamando a la primera operación.

Nota:

Generalmente, intentar detectar explícitamente los canales con sesión en los cuales se ha producido un error no es útil, porque cuando se notifica depende de la implementación de la sesión. Por ejemplo, dado que System.ServiceModel.NetTcpBinding (con la sesión de confianza deshabilitada) emerge la sesión de la conexión TCP, si escucha el evento System.ServiceModel.ICommunicationObject.Faulted en el servicio o el cliente, probablemente, usted será notificado de forma rápida en caso de un error en la red. Pero las sesiones de confianza (establecidas por enlaces en los que System.ServiceModel.Channels.ReliableSessionBindingElement está habilitado) están diseñadas para aislar a los servicios de los errores de red pequeños. Si se puede restablecer la sesión dentro de un período razonable de tiempo, el mismo enlace, configurado para sesiones de confianza, no podría producir un error hasta que la interrupción continuara durante un período más largo de tiempo.

La mayoría de los enlaces proporcionados por el sistema (qué exponen canales al nivel de aplicación) utiliza sesiones de forma predeterminada, pero System.ServiceModel.BasicHttpBinding no. Para obtener más información, vea Uso de sesiones.

El uso apropiado de sesiones

Las sesiones proporcionan una manera de conocer si todo el intercambio de mensajes ha finalizado, y si ambos lados lo consideraran correcto. Se recomienda que una aplicación que realiza la llamada abra el canal, lo utilice y cierre el canal dentro de un bloque try. Si un canal de sesión está abierto, y se llama al método System.ServiceModel.ICommunicationObject.Close una vez y esa llamada se devuelve correctamente, a continuación, la sesión se ha completado correctamente. Correctamente en este caso significa que todas las garantías de entrega especificadas por el enlace se cumplieron y que el otro lado no llamó System.ServiceModel.ICommunicationObject.Abort en el canal antes de llamar Close.

La sección siguiente proporciona un ejemplo de este enfoque del cliente.

Control de excepciones

Administrar las excepciones en las aplicaciones cliente es sencillo. Si se abre, se utiliza y se cierra un canal dentro de un bloque try, la conversación ha se ha completado correctamente, a menos que se produzca una excepción. En general, si se produce una excepción se anula la conversación.

Nota:
No se recomienda el uso de la instrucción (Using en Visual Basic) using. Esto es debido a que el fin de la instrucción using puede producir excepciones que pueden enmascarar otras excepciones que usted pueden necesitar conocer. Para obtener más información, vea Evitar problemas mediante una declaración de instrucción.

El ejemplo de código siguiente muestra el modelo del cliente recomendado mediante un try/bloque catch y no la instrucción 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

Nota:
Comprobar el valor de la propiedad System.ServiceModel.ICommunicationObject.State es una condición de carrera y no se recomienda para determinar si reutilizar o cerrar un canal.

Los canales de datagrama nunca producen errores, incluso si se producen excepciones cuando se cierran. Además, los clientes no dúplex que no se autentican mediante una conversación segura, normalmente, inician System.ServiceModel.Security.MessageSecurityException. Sin embargo, si el cliente dúplex que utiliza una conversación segura no se autentica, el cliente recibe en su lugar System.TimeoutException.

Para obtener más información sobre cómo trabajar con información de error en un nivel de aplicación, consulte Especificación y administración de errores en contratos y servicios. Excepciones esperadas describe excepciones esperadas y muestra cómo controlarlas. Para obtener más información sobre cómo controlar errores cuando se desarrollan canales, consulte Administración de excepciones y errores.

Bloqueo de clientes y rendimiento

Cuando una aplicación llama sincrónicamente a una operación de solicitud-respuesta, el cliente se bloquea hasta que se reciba un valor devuelto o se produzca una excepción (como un System.TimeoutException). Este comportamiento es similar al comportamiento local. Cuando una aplicación invoca sincrónicamente una operación en un objeto de cliente o canal WCF, el cliente no vuelve hasta que el nivel del canal pueda escribir los datos en la red o hasta que se produzca una excepción. Y mientras el modelo de intercambio de mensaje unidireccional (especificado marcando una operación con System.ServiceModel.OperationContractAttribute.IsOneWay establecida en true) puede hacer que algunos clientes sean más receptivos, las operaciones unidireccionales también se pueden bloquear, dependiendo del enlace y de los mensajes que ya se han enviado. Las operaciones unidireccionales son solo sobre intercambio de mensajes, nada más y nada menos. Para obtener más información, vea One-Way Services.

Los fragmentos de datos grandes pueden desacelerar el procesamiento del cliente, independientemente del modelo de intercambio de mensajes. Para entender cómo controlar estos problemas, consulte Datos de gran tamaño y secuencias.

Si su aplicación debe hacer más trabajo mientras se completa una operación, debería crear un par del métodos asincrónico en la interfaz del contrato de servicio que su cliente WCF implementa. La manera más fácil de llevarlo a cabo es utilizar el modificador /async en Herramienta de utilidad de metadatos de ServiceModel (Svcutil.exe). Vea un ejemplo en Cómo llamar a operaciones del servicio WCF de forma asincrónica.

Para obtener más información sobre aumento del rendimiento del cliente, consulte Aplicaciones cliente de nivel intermedio.

Permitir que el usuario seleccione credenciales dinámicamente

La interfaz IInteractiveChannelInitializer permite a las aplicaciones mostrar una interfaz de usuario que permite al usuario elegir credenciales con las que crear un canal antes del inicio de los temporizadores de tiempo de espera.

Hay dos maneras con las que los desarrolladores de aplicaciones pueden hacer uso de un IInteractiveChannelInitializer insertado. La aplicación cliente puede llamar a System.ServiceModel.ClientBase.DisplayInitializationUI o a System.ServiceModel.IClientChannel.DisplayInitializationUI (o a una versión asincrónica) antes de abrir el canal (enfoque explícito) o simplemente llamar a la primera operación (enfoque implícito).

Si se utiliza el enfoque implícito, la aplicación debe llamar a la primera operación en una extensión de ClientBase o IClientChannel. Si no llama a la primera operación, se inicia una excepción.

Si se utiliza el enfoque explícito, la aplicación debe realizar los pasos siguientes en orden:

1. Llamar a System.ServiceModel.ClientBase.DisplayInitializationUI o a System.ServiceModel.IClientChannel.DisplayInitializationUI (o una versión asincrónica).

2. Cuando se hayan devuelto los inicializadores, llamar al método Open en el objeto IClientChannel o en el objeto IClientChannel devuelto de la propiedad System.ServiceModel.ClientBase.InnerChannel.

3. Llamar a las operaciones.

Se recomienda que las aplicaciones de calidad de producción controlen el proceso de la interfaz del usuario mediante el enfoque explícito.

Las aplicaciones que utilizan el enfoque implícito invocan los inicializadores de la interfaz de usuario, pero si el usuario de la aplicación no responde dentro del plazo de tiempo de espera de envío del enlace, se inicia una excepción cuando se devuelve la interfaz de usuario.

Vea también

Tareas

Cómo: Obtener acceso a los servicios WCF con contratos unidireccionales y de solicitud-respuesta
Cómo: Obtener acceso a los servicios con un contrato dúplex
Cómo: Obtener acceso al servicio WSE 3.0 con un cliente WCF
Cómo utilizar ChannelFactory
Cómo llamar a operaciones del servicio WCF de forma asincrónica

Conceptos

Servicios dúplex
Aplicaciones cliente de nivel intermedio