Escenarios compatibles de intercambio de mensajes

Los servicios de flujo de trabajo admiten un subconjunto de los escenarios del intercambio de mensajes definido en Windows Communication Foundation (WCF). Los dos escenarios admitidos son de envío unidireccional y solicitud/respuesta. En un escenario de envío unidireccional, el cliente no espera una respuesta al llamar a una operación en el servicio del flujo de trabajo. Simplemente llama a la operación y procede con el resto de la ejecución. En un escenario de solicitud/respuesta, el cliente espera una respuesta del servicio de flujo de trabajo y bloquea el subproceso de ejecución principal hasta que se reciba esa respuesta. Como se tiene en cuenta en estos escenarios, el cliente inicia todos los intercambios de mensajes con el servicio de flujo de trabajo.

La comunicación dúplex se puede lograr de dos maneras. La primera manera es utilizar los contratos dúplex como un servicio WCF normal para establecer los id. de sesión que se utilizarán para la comunicación asincrónica. Desgraciadamente, ya que los id. de sesión están ligados directamente al canal dúplex, cada vez que se destruye el canal, la posibilidad de utilizar id. de sesión como un medio de establecer un contexto entre el cliente y el servicio ya no existe. La segunda manera de habilitar la comunicación dúplex es a través del uso de contratos puestos en correlación que se comunican a través de canales independientes. Estos contratos pasan información del id. de contexto en su invocación de la operación inicial y el estado de la operación se puede conservar como cualquier otro servicio de flujo de trabajo. Utilizando contratos unidireccionales correlativos, el id. de contexto se almacena en el nivel de aplicación, por lo que si se ha reiniciado el cliente o el servicio, éstos pueden reanudar el trabajo desde su último estado almacenado. Éste es el método preferido de comunicación dúplex para los servicios de flujo de trabajo.

Como procedimiento recomendado, debe realizar una operación de solicitud/respuesta sincrónica con el servicio antes de activarse en comunicación asincrónica. Este intercambio permitirá al cliente y al servicio establecer un contexto que se podrá utilizar al invocar operaciones futuras.

Intercambio de contexto

En esta sección se describe cómo el flujo de trabajo y los servicios duraderos utilizan los contextos para poner en correlación los mensajes entre los servicios y clientes. Después de una operación de solicitud/respuesta inicial, el cliente recibe un contexto del servicio y proporciona ese mismo contexto en todos los mensajes futuros al servicio por la duración de ese intercambio de mensajes. El contexto es opaco al cliente y sólo se proporciona para mantener las comunicaciones con un intercambio de mensajes establecido con una instancia del servicio determinada. Una vez establecido el contexto, sólo puede ser modificado mediante un mensaje entrante del servicio.

Nota

En el caso de escenarios dúplex, el servicio devuelve el contexto al cliente como un encabezado de contexto y como una parte del primer mensaje enviada del servicio al cliente, y no necesariamente como respuesta a la primera solicitud del cliente.

En lo que respecta al servicio, una instancia del canal es responsable de convertir el contexto proporcionado por el cliente en el formulario de un encabezado SOAP en mensajes entrantes a un tipo ContextMessageProperty. El nivel de aplicación o los canales pueden utilizar a continuación ContextMessageProperty en la pila. Los canales del servicio también permiten al nivel de aplicación especificar un nuevo valor de contexto que se va a propagar de nuevo al cliente.

Manteniendo este contexto en el nivel de aplicación, el canal original puede eliminarse y establecerse un canal nuevo. Aunque el canal proporciona el mecanismo de intercambio de contexto, el contexto real puede ser proporcionado y recuperado por el nivel de aplicación (tanto en cliente como en servicio).

Para los puntos finales de servicio que utilizan un transporte HTTP, y los clientes que aceptan el uso de cookies HTTP, puede utilizarse el mecanismo HttpCookie en el intercambio de contexto de la aplicación. El protocolo de intercambio de contexto permite al canal de cliente aceptar un contexto proporcionado por un servicio y aplicarlo a todas las solicitudes subsiguientes para que el servicio pueda recibir solicitudes enviadas sobre la misma instancia del canal de cliente. El protocolo de intercambio de contexto también proporciona un equivalente basado en SOAP de la característica proporcionada por las cookies HTTP en el nivel de transporte.

Nota

Los clientes basados en flujo de trabajo que utilizan una actividad SendActivity para comunicarse con un servicio duradero o servicio de flujo de trabajo, deben utilizar un enlace que contenga ContextBindingElement para intercambiar el contexto entre el cliente y el servicio, o bien proporcionar algún otro canal de la correlación que se integre con ContextMessageProperty.

El encabezado SOAP es un encabezado SOAP del wsc:Context utilizado para representar la información de contexto. El esquema de encabezado de contexto permite cualquier número de elementos secundarios, cada uno con contenido de cadena. Esto permite a la propiedad del mensaje correspondiente que representa el contexto utilizar un diccionario que asigne un nombre completo de XML (el nombre del elemento secundario y espacio de nombres en el encabezado de wsc:Context) a un valor de cadena (el valor de texto del elemento secundario en el encabezado de wsc:Context). Por lo tanto, se exige la firma digital del encabezado wsc:Context en el nivel SOAP o de transporte, cuando el enlace ofrece la función de protección del mensaje.

Obtener y establecer el contexto

La ContextMessageProperty descrita en la sección anterior es una propiedad de mensaje utilizada para comunicar el contexto entre el nivel de aplicación y la capa del canal en relación al cliente o al servicio. Si el contexto se establece en la capa del canal; el canal del contexto asociará esta propiedad a todos los mensajes entrantes del cliente y el servicio. Si el contexto está asociado a un mensaje saliente en el cliente o el servicio en el nivel de aplicación, el contexto representado por ContextMessageProperty reemplazará al contexto almacenado en la capa del canal.

Además de ContextMessageProperty que se puede utilizar para el cliente o el servicio, en el lado del cliente se puede obtener el contexto actual o se puede establecer un nuevo contexto en la instancia del canal utilizando IContextManager como se muestra en los ejemplos siguientes:

IDictionary<XmlQualifiedName, string> context;
IContextManager cm = ClientProxy.InnerChannel.GetProperty<IContextManager>();
if (cm != null)
    context = cm.GetContext();
IContextManager cm = ClientProxy.InnerChannel.GetProperty<IContextManager>();
if (cm != null)
    context = cm.SetContext();

Nota

El objeto ClientProxy es un ejemplo de una instancia de la clase de proxy que se genera a través de svcutil para realizar las invocaciones de la operación en un servicio.

Consulte también

Conceptos

Estilos de creación de servicio de flujo de trabajo

Otros recursos

Creación de servicios de flujo de trabajo y de servicios duraderos

Footer image

Copyright © 2007 Microsoft Corporation. Reservados todos los derechos.