Compartir
Contenidos contratados por la marca que se menciona

Windows Azure Platform AppFabric. Colas en el service Bus.

Windows Azure Platform AppFabric. Colas en el service Bus.
Guardar
0 Comentarios
Publicidad
\"The \"Prueba \"Conviértete

En 2002, la empresa Sonic utilizo por primera vez el acrónimo ESB para definir una arquitectura de software que proporciona servicios fundamentales para arquitecturas complejas a través de un sistema de mensajes (el bus). Rápidamente adoptada por muchas empresas, ya en 2006, Mohammad Adil Aki de Microsoft publica artículos sobre el tema y realiza la, para mí, más clara definición de Entreprise Service Bus.

Enterprise: La "E" se refiere al hecho de que un ESB en general, se instala y se gestiona dentro de una empresa virtual.

Services: Se refiere a los servicios de valor añadido proporcionado por el ESB, incluyendo enrutamiento, gestión y transformación.

Bus: En ESB se refiere a su capacidad de sustitución de servicios sin interrupciones. Una topología de bus lógica facilita esto permitiendo que cualquier endpoint pueda comunicarse con cualquier otro de manera desacoplada.

Desde entonces ha llovido bastante y ahora Windows Azure AppFabric ofrece la tecnología de Service Bus para comunicar nuestras aplicaciones entre ellas y con Azure de forma que sean amigables con los diferentes dispositivos que están implicados en la comunicación como pueden ser Firewall, Proxys o dispositivos que realicen NAT. Sin necesidad que los desarrolladores tengan que construir las capas de comunicación y evitando los problemas de acoplamiento, rendimiento y falta de escalabilidad que la arquitectura ESB supera.

Colas de mensajes

Pero si el concepto de ESB es interesante en relación al desarrollo de aplicaciones Azure, la publicación de la CTP de Mayo de Service Bus ha llevado a David Ingham ha escribir un excelente post del voy a realizar un condensado. Centrando en las ventajas que veo al utilizar colas de mensajes en nuestros desarrollos construidos para ser publicados en Azure, o utilizando los servicios de Azure Plataform AppFabric. Las imágenes, por esta vez, son suyas. Ya que difícilmente se pueden mejorar.

Windows Azure Service Bus Queues

Cómo se ve en la figura, la práctica es básicamente hacer listas de mensajes, que pueden incluir todo tipo de información. Que se envían desde el emisor a un receptor y que, una vez recibidos, lanzan eventos u acciones en la aplicación de destino. Si estuvieramos hablando de una relación uno a uno, pues tampoco es que sean muchas las ventajas, que ya las hay, pero cuando hablamos de múltiples emisores y receptores, se puede empezar a intuir las posibilidades para el desarrollo en Cloud.

Desacople temporal

Al ser un patrón asíncrono, no es necesario que el emisor y el receptor estén ambos online al mismo tiempo. La infraestructura del Service Bus mantiene estas colas de mensajes vivas hasta que el receptor esté listo para procesarlos. Por lo cual no hay problema en detener o apagar la máquina a causa de problemas, actualizaciones o mantenimientos. El sistema seguirá funcionando en cuanto se levante todo de nuevo. Esto se ve claramente en la infraestructura del ejemplo que se ven en las imágenes, en donde los clientes envían mensajes a un servidor de inventario que, por ejemplo, solo necesitaría estar en línea a partir del cierre de todas las sucursales.

Equilibrado de carga

Windows Azure Service Bus Queues. Equilibrado de Carga.

Siguiendo con el ejemplo de las imágenes. Si tenemos los clientes realizando operaciones durante el día, obviamente tendremos picos relacionados con las ventas, y algunas veces el servidor de inventario tendrá un gran número de peticiones y otras veces estará al ralentí esperando. Si utilizamos una cola de mensajes, la entrada en el Service Bus seguirá siendo errática, pero la entrada al servidor de inventario estará modulada según las capacidades o necesidades que configuremos. Es decir, no tendremos que temer que un pico de super ventas nos pueda poner en peligro la estabilidad del sistema y podemos ajustar el ancho de banda de la conexión del servidor de inventario con Azure AppFabric ya que será previsible el volumen de tráfico.

Balanceo de carga

Windows Azure Service Bus Queues. Balanceo de Carga.

¿Si en vez de un solo equipo de inventario tuviéramos una granja de equipos?. ¿O lo tuviéramos en cloud? La propia arquitectura de Service Bus nos realizará un balanceo de carga de la cola de los mensajes, repartiéndolos entre los diferentes equipos o, mejor aún, entre las diferentes instancias que tengamos levantadas en Azure. Y con esto también cumplimos con la necesidades de escalabilidad. Ya que podemos ir incrementando el número de instancias, ajustando al máximo los recursos necesarios, de acuerdo al volumen de operaciones que los clientes realicen.

Desacoplamiento

Ya más orientado a nosotros los desarrolladores, una ventaja que no es evidente pero si nos quita un montón de dolores de cabeza es que desacoplamos la capa de comunicación de los emisores de la de los receptores. Podemos, sin problemas, realizar modificaciones, mantenimientos o actualizaciones de la forma en que se comunican los endpoint de nuestro bus sin que esto signifique que tenga que modificar el otro extremo de la comunicación. Así mismo, la propia arquitectura de la mensajería puede ir evolucionando sin que produzca efectos sobre los emisores ni los receptores.

Espero que este artículo os sea tan útil y clarificador como ha sido para mí el escribirlo.

Microsoft on the Enterprise Service Bus (ESB) ¿Por qué un Enterprise Service Bus (ESB)? Foro Windows Azure AppFabric CTP

Publicidad

También te puede gustar

Ver más artículos