Aplicaciones Híbridas: IoC con Windows Azure Service Bus Relay (Parte I)

Intro

Windows Azure Service Bus es un gran servicio de plataforma que nos permite (entre otras cosas) "enchufar" a la nube cualquiera de nuestros web services que hoy se encuentren ejecutando on-premises.

¿Por qué querríamos hacer algo así? Imaginemos que quisiéramos llevar a la nube una aplicación que requiere acceder a determinados web services que se encuentran dentro de nuestra red corporativa (ej.  detrás de un firewall y otros dispositivos de comunicaciones). Una solución posible sería configurar acceso de redes y firewalls entre nuestro Cloud Service y nuestro datacenter para que la aplicación simplemente acceda directamente a los web services que requiera. Incluso hasta podríamos crear una VPN si quisiéramos agregar mayor seguridad.

Si bien esta solución es completamente feasible, requiere la intervención de administradores expertos de redes e infrarstructura para poder configurarla (y luego mantenerla). Otro punto y no menos importante, es la fragilidad que a veces tienen este tipo de configuraciones: la realidad nos dice que los nombres de computadores y las IPs suelen estar sujetas a cambios, lo cual dificulta garantizar que los endpoints de nuestros web services siempre se encontrarán disponibles en las URIs donde fueron configurados originalmente.

Inversión-de-Control o Principio de inversión de dependencias

Quiénes estén familiarizados con patrones de diseño de software habrán escuchado hablar del principio de inversión de dependencias, formulado hace un buen tiempo por Robert C. Martin (http://www.objectmentor.com/resources/articles/dip.pdf). Dicho principio sugiere "alivianar" el acoplamiento entre dos (o más) piezas de software mediante el uso de una interface conocida por ambas piezas. De acuerdo a esta técnica, ninguna pieza sabrá de la existencia de la otra en tiempo de diseño, sino que el acoplamiento entre ambas ocurrirá en tiempo de ejecución. De esta forma, si alguna de las piezas cambia la otra no se verá afectada en tanto se respete la interface definida previamente.

Desde hace ya un buen tiempo que los web services desarrollados en .NET requieren la definición de una interface o "contrato", oligando de alguna manera a respetar este principio de inversión de dependencias (sin ir mas lejos, el WSDL de un servicio es también un "contrato" o definición de interface). No obstante, a la hora de configurar los endpoints de nuestros servicios nos encontramos con las dificultades enunciadas anterioremente (VPNs, firewalls, DNS, etc). Esta complejidad se incrementa cuando además hay que considerar ambientes diferenciados para desarrollo, testing y producción.

Haciendo la analogía del principio de inversión de dependencias, Windows Azure Service Bus hace posible "invertir la dependencia" a los endpoints físicos de nuestros web services y conectando a éstos últimos al Service Bus. Luego, las aplicaciones cliente solo requerirán conectarse al Service Bus para realizar las invocaciones. 

La ventaja de este enfoque es que si en algún momento necesitáramos mover nuestros web services a otra infraestructura, esto no supondría ningún cambio en las configuraciones de los endpoints. Solo bastaría con poner en marcha nuestros web services en la nueva infraestructura para que automáticamente se conecten al Service Bus y vuelvan a estar disponibles para las aplicaciones clientes.

Una de las características de Windows Azure Service Bus que hacen posible que la nube actúe de intermediario entre las aplicaciones cliente y los web services son los "Relays". Y gracias a la arquitectura de Windows Communication Foundation es muy fácil utilizarlos mediante simples cambios de configuración en nuestra aplicación, e incluso sin necesidad de tener que cambiar código alguno.

Bindings y Behaviors

De acuerdo a la arquitectura WCF, los web services deben exponer "endpoints" de comunicación para que los clientes puedan acceder a ellos. Un "endpoint" consiste en una configuración en la cual se definen los siguientes elementos:

• Address. Identificador único del recurso en la red (ej. URI) 
• Binding. Detalles de los protocolos de comunicación y codificación.
• Contract. Referencia a la interface o contrato que describe las operaciones expuestas en el endpoint.

Adicionalmente, es posible espeficar "behaviors" o componentes de lógica transversal que operen sobre los mensajes recibidos y devueltos por el servicio. Típicamente los behaviors son utilizados para dar tratamiento a necesidades transversales como la autenticación y la autorización.

Todos estos elementos hacen referencia a piezas provistas por WCF y que son habitualmente configurados en el archivo de configuración de la aplicación (.config) y pueden ser alterados sin que esto suponga un cambio de código o recompilaciones. De esta forma un mismo web service puede exponer sus operaciones utilizando varios endpoints en direcciones y protocolos diferentes, 

Adicionalmente, Windows Azure Service Bus provee un SDK con elementos adicionales para configurar los endpoints de un servicio de forma tal estos puedan recibir mensajes provenientes desde el bus. Puntualmente el SDK provee un nuevo binding denominado "netTcpRelayBinding" y que contiene la lógica de conectividad con el bus. A diferencia de otros bindings que se activan cuando un cliente intenta enviar un mensaje, este binding requiere ser activado al iniciar el web service y durante su activación establece un canal de comunicación directo con el Service Bus. Este canal se mantendrá en tanto el web service siga en ejecución, y por él llegarán los mensajes enviados desde el bus.Así mismo el netTcpRelayBinding puede ser utilizado por las aplicaciones cliente para invocar a los web services expuestos en el bus.

La parte interesante de todo esto es que dado la comunicación es originada inicialmente por el web service, no es necesario habilitar conexiones entrantes en nuestro firewall corporativo, sino que solo basta que el web service pueda establecer una conexión saliente hacia el datacenter de Windows Azure. 

Otro elemento necesario y provisto por el SDK es un behavior utilizado para lograr la autenticación con el Service Bus y de esta forma evitar que otro web service no autorizado pueda recibir mensajes que no le correspondan.

En el siguiente post exploraremos un ejemplo de como conectar un web service al service bus para después consumirlo desde nuestra aplicación.

Link a la segunda parte:
http://brmcc.blogspot.com/2013/12/aplicaciones-hibridas-ioc-con-windows_3.html