¿Qué es WCF? – Parte 4. Arquitectura de WCF

Como vimos en los posts anteriores, WCF nos facilita la manera de crear servicios para poder consumirlos de forma sencilla a partir de la generación de un proxy que actúa como interceptor de la llamada y nos abstrae de toda la plomería necesaria para conectarnos con el provedor del servicio y obtener el resultado deseado. En este post vamos a hablar acerca de la arquitectura de WCF.

Todas las características de WCF, entre ellas confiabilidad, administración de la concurrencia, seguridad, y activación de instancias, dependen de la arquitectura de WCF, conocida como arquitectura basada en intercepción. El hecho de que un cliente interactúe con un proxy, significa que WCF siempre esta presente entre el servicio y el cliente, interceptando la llamada y llevando a cabo pre procesamiento y post procesamiento.

Esta “intercepción” inicia cuando el proxy serializa la llamada a un stack frame para un mensaje y envía el mensaje hacia abajo en la cadena de canales. El canal es simplemente un interceptor que tiene como propósito llevar a cabo tareas específicas. Este concepto de canal es algo muy similar al manejo de “pipes” utilizado por Biztalk Server para procesar mensajes.

Cada canal del lado del cliente hace un pre procesamiento del mensaje. La estructura exacta y la composición de la cadena depende en su mayoría del tipo de binding que se este utilizando. Por ejemplo, un canal puede estar encargado de la codificación del mensaje (MTOM, texto, etc.), otro de pasar el contexto de seguridad, otro de propagar las transacciones, otro por manejar la confiabilidad de la sesión, otro para encriptar el mensaje y así sucesivamente. El último canal del lado del cliente es el canal de transporte el cual envia el mensaje a través del transporte configurado en el host.

Del lado del servidor, el mensaje “sube” otra vez por la cadena de canales pero en sentido inverso al channel stack del cliente. Es decir, el primer canal en participar en el server es el canal de transporte, el cual recibe el mensaje.  Los canales subsecuentes llevan a cabo las tareas inversas realizadas en el cliente; por ejemplo, si en el cliente se encripto el mensaje, en el server se desencripta el mensaje. Igualmente, en esta ruta del mensaje se activa la instancia del servicio requerida para consumir el servicio. El último canal en el servidor pasa el mensaje a un elemento conocido como el dispatcher. El dispatcher es el elemento que administra la ejecución de servicio. El dispatcher convierte el mensaje en un stack frame ( lo deserializa. y llama la instancia del servicio creada para completar el llamado). En la siguiente figura se puede ver este proceso.

Como se puede ver, el servicio no sabe que fue llamado por un cliente externo, y el cliente no sabe que se esta comunicando con un cliente externo. Ambos, ven los componentes localmente para comunicarse – el cliente en el proxy y el servicio en el dispatcher. Este concepto de intercepción en ambos lados, cliente y servidor, garantiza que ambos obtiene el ambiente de ejecución que se requiere para operar correctamente.

Por último, en el proceso de respuesta, la instancia del servicio ejecuta la llamada y retorna el control al dispatcher, el cual a su vez convierte los valores retornados y la información del error – si existe – en el mensaje de regreso. El proceso se invierte siendo el dispatcher el que inicia la cadena del llamado, y el proxy el último en contestarle al cliente.

Para concluir podemos destacar que esta arquitectura nos permite extensibilidad en el modelo, ya que podríamos crear canales personalizados para interacciones propietarias o propias de un negocio o plataforma en específico.