Compartir a través de


Acceso a servicios mediante un cliente

Las aplicaciones cliente deben crear, configurar y usar objetos de cliente o canal wcF para comunicarse con los servicios. El tema Información general del cliente WCF proporciona información general sobre los objetos y los pasos necesarios para crear objetos básicos de cliente y canal y usarlos.

En este tema se proporciona información detallada sobre algunos de los problemas con las aplicaciones cliente y los objetos de cliente y canal que pueden resultar útiles en función de su escenario.

Información general

En este tema se describen el comportamiento y los problemas relacionados con:

  • Canal y duraciones de la sesión.

  • Control de excepciones.

  • Descripción de los problemas de bloqueo.

  • Inicializar canales de forma interactiva.

Duración de canales y sesiones

En las aplicaciones de Windows Communication Foundation (WCF), se incluyen dos categorías de canales: los canales de datagrama y los canales con sesión.

Un canal de datagrama es un canal en el que todos los mensajes no están relacionados. Con un canal de datagrama, si se produce un error en una operación de entrada o salida, la siguiente operación normalmente no se ve 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 en los que se establece una conexión al otro punto de conexión. Los mensajes de una sesión en un lado siempre están correlacionados con la misma sesión en el otro lado. Además, ambos participantes de una sesión deben aceptar que se cumplen los requisitos de su conversación para que esa sesión se considere correcta. 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:

Intentar detectar explícitamente canales de sesión con fallos no suele ser útil, ya que el momento en que se le notificará de un fallo dependerá 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 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 confiables (establecidas por enlaces en los que el System.ServiceModel.Channels.ReliableSessionBindingElement está habilitado) están diseñadas para proteger los servicios de fallos de red pequeños. Si la sesión se puede restablecer dentro de un período de tiempo razonable, el mismo enlace (configurado para sesiones confiables) podría no producir errores hasta que la interrupción continuara durante un período de tiempo más largo.

La mayoría de los enlaces proporcionados por el sistema (que exponen canales a la capa de aplicación) usan sesiones de forma predeterminada, pero System.ServiceModel.BasicHttpBinding no. Para obtener más información, consulte Uso de sesiones.

El uso adecuado de las sesiones

Las sesiones proporcionan una manera de saber si todo el intercambio de mensajes está completo y si ambos lados lo consideran correcto. Se recomienda que una aplicación que realiza llamadas abra el canal, lo use y cierre el canal dentro de un bloque try. Si un canal de sesión está abierto y se ICommunicationObject.Close llama al método una vez y esa llamada se devuelve correctamente, la sesión se realizó 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ó ICommunicationObject.Abort en el canal antes de llamar Close.

En la sección siguiente se proporciona un ejemplo de este enfoque de cliente.

Controlar las excepciones

El control de excepciones en 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 usar la using instrucción (Using en Visual Basic). 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, consulte Uso de Close y Abort para liberar los recursos del cliente WCF.

En el siguiente ejemplo de código, se muestra el patrón de cliente recomendado utilizando un bloque try/catch y no la sentencia using.

using System;
using System.ServiceModel;
using System.ServiceModel.Channels;
using Microsoft.WCF.Documentation;

public class Client
{
  public static void Main()
  {
    // Picks up configuration from the config file.
    SampleServiceClient wcfClient = new SampleServiceClient();
    try
    {
      // Making calls.
      Console.WriteLine("Enter the greeting to send: ");
      string greeting = 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 (TimeoutException timeProblem)
    {
      Console.WriteLine("The service operation timed out. " + timeProblem.Message);
      Console.ReadLine();
      wcfClient.Abort();
    }
    catch (FaultException<GreetingFault> greetingFault)
    {
      Console.WriteLine(greetingFault.Detail.Message);
      Console.ReadLine();
      wcfClient.Abort();
    }
    catch (FaultException unknownFault)
    {
      Console.WriteLine("An unknown exception was received. " + unknownFault.Message);
      Console.ReadLine();
      wcfClient.Abort();
    }
    catch (CommunicationException commProblem)
    {
      Console.WriteLine("There was a communication problem. " + commProblem.Message + commProblem.StackTrace);
      Console.ReadLine();
      wcfClient.Abort();
    }
  }
}

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 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 fallan incluso si se producen excepciones cuando están cerrados. 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 completa sobre cómo trabajar con información de error en el nivel de aplicación, consulte Especificación y control de errores en contratos y servicios. Las excepciones esperadas describen las excepciones esperadas y muestran cómo controlarlas. Para obtener más información sobre cómo controlar los errores al desarrollar canales, consulte Control de excepciones y errores.

Bloqueo y rendimiento del cliente

Cuando una aplicación llama sincrónicamente a una operación de solicitud y respuesta, el cliente permanece bloqueado hasta que se recibe un valor devuelto o se produce una excepción (por ejemplo, System.TimeoutException). Este comportamiento es similar al comportamiento local. Cuando una aplicación invoca de forma sincrónica una operación en un objeto o canal de cliente WCF, el cliente no devuelve hasta que la capa de canal pueda escribir los datos en la red o hasta que se produzca una excepción. Y aunque el patrón de intercambio de mensajes unidireccional (especificado marcando una operación con OperationContractAttribute.IsOneWay establecida en true) puede hacer que algunos clientes respondan más, las operaciones unidireccionales también se pueden bloquear, dependiendo de la combinación y de los mensajes que ya se han enviado. Las operaciones unidireccionales solo se refieren al intercambio de mensajes, no más ni menos. Para obtener más información, consulte One-Way Services.

Los fragmentos de datos grandes pueden ralentizar el procesamiento del cliente independientemente del patrón de intercambio de mensajes. Para comprender cómo controlar estos problemas, consulte Datos grandes y streaming.

Si la aplicación debe realizar más trabajo mientras se completa una operación, debe crear un par de métodos asincrónicos en la interfaz de contrato de servicio que implementa el cliente WCF. La manera más fácil de hacerlo consiste en usar el modificador /async de la Herramienta de utilidad de metadatos de ServiceModel (Svcutil.exe). Para obtener un ejemplo completo, consulte Procedimiento para llamar a operaciones de servicio WCF de forma asincrónica.

Para obtener más información sobre cómo aumentar el rendimiento del cliente, consulte Middle-Tier Aplicaciones cliente.

Habilitar el usuario para seleccionar credenciales dinámicamente

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

Los desarrolladores de aplicaciones pueden utilizar una inserción IInteractiveChannelInitializer de dos maneras. La aplicación cliente puede llamar a ClientBase<TChannel>.DisplayInitializationUI o IClientChannel.DisplayInitializationUI (o una versión asincrónica) antes de abrir el canal (el enfoque explícito ) o llamar a la primera operación (el 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<TChannel> o IClientChannel. Si no llama a la primera operación, se inicia una excepción.

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

  1. Llame a ClientBase<TChannel>.DisplayInitializationUI o a IClientChannel.DisplayInitializationUI (o a 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 ClientBase<TChannel>.InnerChannel.

  3. Llame a las operaciones.

Se recomienda que las aplicaciones de calidad de producción controlen el proceso de interfaz de usuario adoptando 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.

Consulte también