DEV214 - Introducing WCF

Esta sesión era la primera de una serie de sesiones sobre WCF que se dieron en el tech·ed. La verdad es que fue una sesión bien explicada e interesante.
Antes que nada, nos comentó los principios de diseño de WCF:

1. Unificar tecnologías existentes
2. Aumentar la productividad
3. Permitir la integración con otras tecnologías de mensajería (de otros fabricantes o de la propia MS).

Luego vino el dibujo general de lo que es WCF: Un cliente y un servicio que intercambian mensajes a través de un endpoint. Si el cliente puede crear un endpoint compatible con alguno de los endpoints expuestos por el servidor, entonces la comunicación es posible. Los servicios pueden estar hospedados en un IIS pero también en una aplicación CLR (p.ej. una aplicación WinForms).

Luego creó paso a paso el "Hello World" de WCF:

1. Crear la clase servidor que tendrá el hosting del servicio. Clase estándard con el Main().
2. Crear un interface para definir el contrato (què puede hacer) del servicio.
3. Implementar el interface en una clase (la clase servicio).
4. Usar la clase ServiceHost para hospedar el servicio en la clase Servidor.
5. Activar el servicio (desde la clase servidor) usando ServiceHost.Open().

Al compilar y ejecutar la clase servidor... excepción al canto. La razón: faltaban definir los endpoints de acceso al servicio. Dicha definición puede hacerse por configuración (app.config) o bien por código. Definió el endpoint (en el app.config) y la aplicación se ejecutó correctamente.
Ahora el siguiente paso era crear el cliente. Aquí nos comentó que, dado que los clientes necesitaban crear un endpoint compatible con alguno de los endpoints del servicio para comunicarse, debía existir una manera de que el servicio expusiera todos sus endpoints a sus clientes. La manera en como los servicios WCF exponen sus endpoints a sus posibles clientes es usando WSDL, pero que no lo hacen automáticamente, si no que para ello debe configurarse un behaviour concreto llamado behaviour metadata. Lo configuró en el app.config del servidor (entre la información que introdujo fue en que URL estaría el WSDL del servicio). Entonces ya pudo crear el cliente: añadio una service reference desde Visual Studio, y automáticamente se creó la clase proxy para acceder al servicio usando un endpoint correcto.

Una vez hecha esa demo, entramos un poco más en profundidad en cada uno de los aspectos básicos de WCF, siempre teniendo presente el ABC de WCF: endpoint = Address + Binding + Contract.

Contracts
Los contratos definen que puede hacer un servicio. En WCF hay tres tipos de contratos, dos de ellos se usan constantemente y el tercero es más raro.

1. Service Contract: Define los métodos que un servicio expone a sus clientes.
2. Data Contract: Define la composición de los parámetros de los métodos definidos en el service contract. Es en definitiva el nuevo modelo de serialización que lleva WCF.
3. Message Contract: Es el tipo de contrato que no suele usarse. Permite especificar a nivel de mensaje que datos van en la cabecera y en el cuerpo.

Luego vimos la definición de contratos.
Para Service Contracts: Definir una interface y aplicar el atributo [OperationContract] a cada método que se desea que el servicio exponga. Sólo los métodos que tengan ese atributo serán expuestos por el servicio a sus clientes.
Para Data Contracts: Definir una clase y aplicar el atributo [DataMember] a cada miembro de la clase que deba ser serializado. Sólo los miembros que tengan ese atributo serán serializados (y por lo tanto pasados/recibidos a/desde el servicio cuando se opere con datos de esa clase).

Luego vimos varios puntos interesantes sobre los contratos:

1. Como mapear llamadas desconocidas a un método en concreto del servicio (p.ej. si un cliente envía un mensaje con un método que no existe se puede mapear esa llamada a un método inexistente a un método en concreto).
2. Como declarar métodos asíncronos [OperationContract(AsyncPattern=true)]
3. Como declarar métodos one-way (de los que no se espera respuesta) [OperationContract(IsOneWay=true)]
4. Como definir contratos duplex: Un contrato duplex es aquel que permite que el servicio invoque una función de callback al cliente, para informar de que una operación ha terminado. Para ello el cliente debe implementar la interfaz de callback.
5. Como declarar que un método de un servicio puede lanzar una excepción de tipo X. Se declaran en el contrato con [FaultContract(typeof(X))], se lanzan en el servicio con throw new FaultException(...) y se capturan en el cliente con catch (X ex).

Bindings
Si los contratos definen que hace un servicio, los bindings definen como acceder al servicio. Un binding se compone de tres partes:

1. Un protocolo de transporte (p.ej http o tcp)
2. Una codificación determinada (p.ej. binario o soap)
3. Uno o más protocolos de funcionamiento (p.ej. Transacciones, reliable messaging, ...)

Los bindings se pueden configurar en el app.config.

Aquí hizo una demo curiosa: un servicio con dos endpoints. En uno de los endpoints el binding era con transporte http y en el otro era con transporte msmq (el resto era todo igual). Luego tenía dos clientes (eran el mismo programa que en función de un parámetro creaba un endpoint compatible con http o con msmq). Puso en marcha el servidor y los dos clientes y enseñó que todo funcionaba bien. Luego paró el servidor y mandó mensajes desde los dos clientes. El cliente http dio un error, mientras que el cliente msmq no dio ninguno. Luego puso en marcha el servidor de nuevo, y los mensajes enviados anteriormente por el cliente msmq fueron recibidos.

Behaviours
Los Behaviours son elementos locales al cliente o al servidor (no forman parte de los endpoints). Los behaviours permiten controlar aspectos relativos a la infraestructura de WCF, pudiendose controlar entre otros aspectos lo siguiente:

1. Como el servicio expone su metadata (WSDL)
2. Gestión de las instancias del servicio (singletons, un servicio por cliente, un servicio por mensaje).
3. Máximo número de clientes admitidos.
4. Información de enrutamiento

Aquí nos hizo una demo de un servicio que controlaba el número de mensajes recibidos, y jugando con el behaviour (definido en app.config) de gestión de instancias comprobamos que se trataba de un singlenton, o de un servicio por cliente o de un servicio que era creado y destruido para cada mensaje.

Eso fue todo lo que dio de si esa sesión (que no fue poco)... y era sólo la primera de una serie de tres o cuatro que hubieron en el tech·ed sobre WCF.