¿Qué es WCF ? – Parte 2

En el post anterior publicamos el primer post acerca de lo que es WCF. En este post vamos a continuar con la parte 2 de esta serie de articulos.

En el contrato especificado en el post de la parte 1, usamos un tipo de retorno del tipo List<Usuario>. Usuario es una clase que escribí que representa una entidad de negocios la cual me permite almacenar los datos en detalle que acepto o envio desde el servicio generado. La estructura de este objeto como veremos en un post posterior va a viajar en formato XML con el wsdl, para que el consumidor del servicio tenga acceso al tipo de datos predefinido como tipo de retorno en mi servicio. Esta información del servicio en conjunto con el detalle del endpoint – definido en el post anterior – van a conformar la metadata del servicio.

Hay que tomar en cuenta que para que el “Usuario” vaya por la red, este debe de ser serializable. Ser serializable significa que el estado del objeto en un momento determinado puede ser persistido en algún medio, ya sea un archivo o un stream de bytes o en una instancia de una clase ya activa (Si nosotros como humanos fueramos serializables, entonces podríamos teletransportarnos :) ).

Con esta metadata del servicio, un consumidor del servicio puede ahora generar un Proxy. Ahora, ¿qué es un proxy en este contexto? Un proxy en WCF es un cliente generado a partir de la metadata expuesta por el servicio que hereda de la clase ClientBase<T>, por ejemplo:

[System.Diagnostics.DebuggerStepThroughAttribute( )]
    [System.CodeDom.Compiler.GeneratedCodeAttribute("System.ServiceModel", "3.0.0.0")]
    public partial class ServiciosSeguridadClient : System.ServiceModel.ClientBase<WPF_ClienteSeguridad.ReferenciaServiciosDeSeguridad.IServiciosSeguridad>, WPF_ClienteSeguridad.ReferenciaServiciosDeSeguridad.IServiciosSeguridad

Este proxy nos abstrae toda la lógica necesaria para conectarse con el servicio que se desea consumir, desde el manejo de la dirección del servcio a consumir hasta el endpoint necesario para poder conversar con el servicio. Igualmente, cuando tenemos tipos compuestos en el retorno o en los parámetros del servicio, estos tipos son generados automáticamente por el proxy para así poder utilizarlos del lado del cliente, es decir, para que la aplicación que consume el servicio “compile” cuando utilizamos el servicio. Podemos decir entonces, que el proxy es un puente que nos expone todas las operaciones en un servicio, y abstrae la serialización y el envío a traves de la red. Finalmente debemos decir que un proxy utiliza un único endpoint.

Por último, el cliente y el host hablan entre sí a través de varios canales. Además, alrededor de estos canales, se pueden tener comportamientos – behaviors – asociados con el servicio. Un canal es el medio por el cual el mensaje viaja entre el cliente y el ente que hostea el servicio. La comunicación se lleva a través de de un modelo conocido como el channel stack el cual estaremos revisando en detalle en post posteriores. Un comportamiento sirve para modificar un mensaje cuando el mensaje viaja por el channel stack.

En resumen podemos decir que vamos a tener un cliente y un host los cuales se ponen de acuerdo en un contrato. El host expone endpoints los cuales tienen una combinación de dirección, binding y contrato – ABC. El cliente utiliza un proxy que esta ligado a un endpoint, por lo tanto esta ligado a un contrato en particular. Por último, todos los detalles relacionados con la comunicación se abstraen a través de los canales y los comportamientos.

En el siguiente post vamos a profundizar en el tema del channel stack para comprender como es que funciona la parte de comunicación en WCF.