Escenarios sincrónicos mediante HTTP, TCP o Named-Pipe

En este tema se describen las actividades y las transferencias para diferentes escenarios de solicitud y respuesta sincrónicos, con un cliente de un solo subproceso, mediante HTTP, TCP o canalización con nombre. Vea Escenarios asincrónicos mediante HTTP, TCP o canalización con nombre para obtener más información sobre las solicitudes multiproceso.

Solicitud o respuesta sincrónica sin errores

En esta sección se describen las actividades y las transferencias de un escenario de solicitud y respuesta sincrónico válido, con un cliente de un solo subproceso.

Cliente

Estableciendo comunicación con el punto de conexión del servicio

Un cliente se construye y se abre. Para cada uno de estos pasos, la actividad ambiental (A) se transfiere a una actividad "Construct Client" (B) y "Open Client" (C) respectivamente. Para cada actividad a la que se transfiere una operación, la actividad de entorno se suspende hasta que haya una transferencia de regreso, es decir, hasta que se ejecute el código ServiceModel.

Realización de una solicitud al punto de conexión de servicio

La actividad ambiental se transfiere a una actividad "ProcessAction" (D). Dentro de esta actividad, se envía un mensaje de solicitud y se recibe un mensaje de respuesta. La actividad finaliza cuando el control vuelve al código de usuario. Dado que se trata de una solicitud sincrónica, la actividad ambiental se suspende hasta que se devuelve el control.

Cerrar la comunicación con el punto de conexión de servicio

La actividad de cierre (I) del cliente se crea a partir de la actividad ambiente. Esto es idéntico a nuevo y abrir.

Servidor

Configuración de un host de servicio

Las actividades nuevas y abiertas de ServiceHost (N y O) se crean a partir de la actividad ambiental (M).

Una actividad de escucha (P) se crea abriendo un ServiceHost para cada escucha. La actividad de la escucha espera a recibir y procesar los datos.

Recepción de datos en la red

Cuando los datos llegan en la conexión, se crea una actividad "ReceiveBytes" si aún no existe (Q) para procesar los datos recibidos. Esta actividad se puede reutilizar para varios mensajes dentro de una conexión o cola.

La actividad ReceiveBytes inicia una actividad ProcessMessage (R) si tiene suficientes datos para formar un mensaje de acción SOAP.

En la actividad R, se procesan los encabezados de mensaje y se comprueba el encabezado activityID. Si este encabezado está presente, el identificador de actividad se establece en la actividad ProcessAction; De lo contrario, se crea un nuevo identificador.

La actividad ProcessAction (S) se crea y se transfiere cuando se procesa la llamada. Esta actividad finaliza cuando se completa todo el procesamiento relacionado con el mensaje entrante, incluida la ejecución del código de usuario (T) y el envío del mensaje de respuesta si procede.

Cerrar un host de servicio

La actividad de cierre del ServiceHost (Z) se crea a partir de la actividad ambiente.

En <A: name>, A es un símbolo abreviado que describe la actividad en el texto anterior y en la tabla 3. Name es un nombre abreviado de la actividad.

Si propagateActivity=true, la acción de procesamiento en el cliente y el servicio tienen el mismo identificador de actividad.

Solicitud y respuesta sincrónica con errores

La única diferencia con el escenario anterior es que se devuelve un mensaje de error SOAP como mensaje de respuesta. Si propagateActivity=true es, el identificador de actividad del mensaje de solicitud se agrega al mensaje de error SOAP.

Unidireccional sincrónico sin errores

La única diferencia con el primer escenario es que no se devuelve ningún mensaje al servidor. En el caso de los protocolos basados en HTTP, todavía se devuelve un estado (válido o error) al cliente. Esto se debe a que HTTP es el único protocolo con una semántica de solicitud-respuesta que forma parte de la pila de protocolos WCF. Dado que el procesamiento TCP está oculto de WCF, no se envía ninguna confirmación al cliente.

Unidireccional sincrónico con errores

Si se produce un error al procesar el mensaje (Q o más allá), no se devuelve ninguna notificación al cliente. Esto es idéntico al escenario "Unidireccional sincrónico sin errores". No debe usar un escenario de One-Way si desea recibir un mensaje de error.

Dúplex

La diferencia con los escenarios anteriores es que el cliente actúa como servicio, en el que crea las actividades ReceiveBytes y ProcessMessage, similares a los escenarios asincrónicos.