WCF (I): Introducción a Windows Communication Foundation

La plataforma .NET sufrió su gran transformación a partir de sus versiones 3.0/3.5, momento en el que surgen oficialmente las ahora conocidas como Foundations, orientadas a especializar secciones completas del framework. Windows Communication Foundation, originalmente conocida por el nombre de Indigo, es la parte encargada, como su propio nombre indica, de las comunicaciones y mensajería, aunque su principal uso son los servicios web.

Hasta el momento, el servicio de mensajería entre aplicaciones se realizaba mediante los protocolos COM, DCOM o MSQM, que obligaba a los programadores a ceñirse no sólo a una forma de programación concreta, sino que también estaba atada a la plataforma y al lenguaje de programación. Los servicios web surgen con el propósito de cambiar esta filosofía, permitiendo hacer la comunicación independiente de lenguaje de programación y plataforma gracias a la creación de estándares de comunicación. No importará si un servicio está codificado en Java o .NET, ni si corre en una plataforma Windows o Linux: lo importante será que respeten los estándares del protocolo sobre el cual está construido, del mismo modo que ocurre con los servidores web.

Tipos de servicios web

A día de hoy existe una gran variedad de protocolos sobre los que los servicios web pueden operar, pero son dos los protocolos estrella que la práctica totalidad de los servicios web utilizan hoy día:

• SOAP: Simple Object Access Protocol. Creado en 1998, se sirve de mensajes XML para el intercambio de mensajes. Puede operar sobre cualquier protocolo de transporte, aunque lo más común es que lo haga sobre HTTP o HTTPS. Es el protocolo más común en servicios web de carácter privado.
• REST: REpresentational State Transfer. Concepto surgido en el año 2000, hace uso del protocolo HTTP para el envío de mensajes, y puede utilizar lenguajes como XML o JSON.

SOAP

Este protocolo, como ya hemos dicho, utiliza XML como lenguaje de codificación, y su principal ventaja es que es agnóstico respecto a la capa de transporte, es decir, que puede ser transmitido a través de HTTP, TCP/IP, SMTP o cualquier otro, a diferencia de REST que únicamente opera sobre HTTP/HTTPS.

Su estructura recuerda vagamente a la de un documento HTML, constando de una cabecera (header) que implementará los metadatos del mensaje (opciones de seguridad, protocolo, transaccionalidad…) y de un cuerpo (body) que contendrá el mensaje en sí. Todo ello irá encapsulado dentro de un sobre (envelope). Un ejemplo de mensaje SOAP podría ser el siguiente:

    <?xml version='1.0' ?>
    <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">

        <soap:Header>
            <!-- Metadatos -->
        </soap:Header>

        <soap:Body xmlns:c="http://www.danigarcia.org/clientes">
            <c:ObtenerNombreCliente>
                <c:IdCliente>61</c:IdCliente>
            </c:ObtenerNombreCliente>
        </soap:Body>

    </soap:Envelope>

REST

Su filosofía se basa en la ausencia de estado y la «equivalencia» entre los cuatro verbos que pueden utilizarse en el protocolo HTTP y las cuatro operaciones CRUD (Create, Read, Update, Delete) básicas que pueden realizarse sobre una fuente de datos. Es el protocolo más utilizado en servicios web abiertos o públicos.

• GET ↔ SELECT (Obtener)
• POST ↔ INSERT (Crear)
• PUT ↔ UPDATE (Actualizar)
• DELETE ↔ DELETE (Borrar)

En la pequeña introducción que vimos hace un par de días acerca de Entity Framework + Webservices vimos un pequeño ejemplo de cómo se hace uso de REST para generar y consumir un servicio. Así, para recuperar un cliente realizaríamos una petición como la siguiente:

• GET http://localhost:6040/GestionPedidosDataService.svc/Cliente(61)

Una eliminación sería similar, pero haciendo uso del verbo DELETE:

• DELETE http://localhost:6040/GestionPedidosDataService.svc/Cliente(61)

SOA

Una vez que hemos descubierto las dos principales tipos de servicios web (SOAP y RESTful), es hora de hablar de SOA. Seguro que muchos hemos oído hablar de SOA, pero ¿de qué se trata? SOA son las siglas de Service-Oriented Architecture, es decir, Arquitectura Orientada a Servicios.

SOA se basa en organizar una aplicación en unidades funcionales que pueden ser gestionadas por distintos proveedores e incluso compañías de modo que puedan ser accedidas de un modo homogéneo. Por lo tanto, SOA no habla acerca de la tecnología a utilizar, como REST o SOAP, sino lo que conceptualmente debería ser un modelo de comunicaciones distribuido.

WCF entra en escena

Tras una serie de acercamientos a los servicios web utilizando SOAP y servicios web de extensión asmx, Microsoft publica finalmente Windows Communication Foundation. Su objetivo básico era el de unificar las comunicaciones. Ya no importará que nuestra aplicación distribuida se comunique a través de TCP en unos servicios, SOAP en otros y REST en otros: WCF soporta todos estos protocolos, y permitirá que nuestro código sea independiente del protocolo que vayamos a utilizar.

¿Cómo logra WCF esta independencia? Básicamente, mediante la separación entre operaciones y datos. Al igual que hacemos uso de interfaces en nuestro código para aislar la firma de los métodos de sus implementaciones (ver este artículo para refrescar estos conceptos), un servicio web WCF utiliza este mismo concepto: establece un contrato a través de una interfaz (que será adornado con atributos específicos) que una clase se encargará de implementar. De este modo, un servicio WCF, se compondrá, a grandes rasgos, de:

• Contrato de servicio (ServiceContract): expone una operación que nuestro servicio web es capaz de ejecutar. Corresponde a una interfaz.
• Contrato de datos (DataContract): implementa un tipo de dato que el servicio web será capaz de manejar. Generalmente, será el tipo de dato que manejará el contrato de servicio.
• Implementación del servicio: implementará la interfaz correspondiente al contrato de servicio, haciendo uso del contrato de datos para intercambiar la información.

En cuanto a la comunicación, se realizará mediante la configuración de los denominados endpoints, a través de un simple fichero XML. Un endpoint no es más que la dirección de un servicio, que implementa un protocolo determinado. Así, en el siguiente ejemplo tendríamos un único servicio que puede comunicarse de tres formas distintas a través de tres endpoints diferentes:

<?xml version='1.0' ?>
<configuration>
  <system.serviceModel>
    <services>
      <service name='GestionPedidosDataService'>
        <endpoint
          address='http://localhost:6040/GestionPedidosHttpService'
          binding='webHttpBinding'
          contract='IServiceContract'
        />
        <endpoint
          address='net.tcp://localhost:9043/GestionPedidosTcpService'
          binding='netTcpBinding'
          contract='IServiceContract'
        />
        <endpoint
          address='net.msmq://localhost/GestionPedidosMsmqService'
          binding='netMsmqBinding'
          contract='IServiceContract'
        />
      </service>
    </services>
  </system.serviceModel>
</configuration>

El primer endpoint realizará su comunicación a través de HTTP utilizando REST. Los otros dos endpoints realizarán el mismo trabajo que el primero, pero usarán los protocolos TCP y MSMQ utilizando SOAP. Como podemos observar, tan sólo ha sido necesario codificar una sola vez la funcionalidad del servicio web, creando en un momento tres formas distintas de realizar la comunicación.

Con esto podemos entender el éxito de WCF en la plataforma .NET: permite olvidarse del transporte y centrarse en la codificación de la lógica del servicio, ahorrando una enorme cantidad de tiempo y recursos y simplificando enormemente la interoperabilidad, ya que, si en un determinado momento es necesario un protocolo determinado para comunicarse con un cliente preexistente, basta con configurar un endpoint para que ese cliente pueda acceder a nuestro servicio en lugar de codificar toda la lógica de comunicaciones que implicaría un servicio web convencional.

A lo largo de los siguientes artículos aprenderemos a implementar distintos tipos de servicios web haciendo uso de WCF, profundizando un poco más en las posibilidades que esta tecnología nos ofrece.