Skip to main content
Red Hat JBoss A-MQ, una plataforma de mensajería interesante

Red Hat JBoss A-MQ, una plataforma de mensajería interesante

1 estrella2 estrellas3 estrellas4 estrellas5 estrellas (Ninguna valoración todavía)
Cargando…

Una buena práctica en las arquitecturas SOA es la utilización del patrón ESB para independizarnos de la ubicación real de los distintos web services de nuestra plataforma SOA, virtualizando sus endpoints y proporcionándonos, además, la abstracción de cambios de protocolo (SOAP, REST, JMS,…) mediante transformaciones de datos o formatos de nuestros mensajes. Además de esto, dependiendo de la herramienta/producto que utilicemos para implementar dicho patrón, tendremos que añadir como beneficio temas como monitorización, gestión del throttling y políticas de seguridad, entre otros.

Esto está ya tan arraigado que, a día de hoy, no conceptuaríamos una arquitectura SOA sin la utilización del patrón ESB, pero ¿qué pasa con la infraestructura mensajería?

RedHatJBossA-MQ_ProblemaInicialIgual que nos sucede con los web services dentro de una arquitectura SOA, la plataforma de mensajería puede estar ubicada en distintas máquinas y, de esta forma, nos encontramos ante el mismo problema que resuelve la utilización del patrón ESB (esta vez sin la necesidad de cambio de protocolo). Todo ello nos lleva a plantearnos la siguiente pregunta: ¿por qué no extrapolar el concepto de ESB a nuestra plataforma de mensajería JMS sin necesidad de crearla desde cero con otras soluciones como Apache Kafka? RedHatJBossA-MQ_SolucionConceptual

Probemos con Oracle

Dentro de la plataforma de mensajería JMS que nos proporciona Oracle Weblogic Server encontramos dos funcionalidades que pueden sernos muy útiles para ayudarnos a montar nuestro ESB de mensajería. Dichas funcionalidades son los  Foreign JMS Servers y los Message Bridge:

  • Los Message Bridge introducen retardo en nuestra plataforma de mensajería (ya que los mensajes se ubican en destinos locales modo SAF –Store And Forward-) y posteriormente realizan el correspondiente forwarding al destino. Es útil cuando el destino remoto no está en alta disponibilidad ya que los mensajes se gestionan con políticas de reintentos si los destinos no están disponibles.
  • Los Foreign JMS Servers están pensados para entornos en los que los destinos están en alta disponibilidad ya que acceden directamente al destino, sin añadir retardo extra al no ubicar los mensajes en destinos locales, ni gestionar políticas de reintentos en envío.

Una combinación inteligente de ambos elementos puede llevarnos a conseguir nuestro ESB de mensajería pero con alguna que otra limitación. La más importante es que la plataforma de mensajería se nos reduce a JMS, es decir, no existe la capacidad de ser funcionales con otro tipo de protocolo interoperable como puede ser AMQP o STOMP. Otra limitación que encontraremos a la hora de usar la solución de JMS de Oracle (y esta es más de nota) se encuentra dentro de la propia especificación de JMS: un suscriptor duradero es creado con un nombre de suscriptor duradero y un clientID de JMS unívoco, lo cual habréis sufrido, si habéis luchado con tópicos distribuidos.

RedHatJBossA-MQ_JMSLimitationsOnDurableSubscribers

 

¿Por qué Red Hat JBoss A-MQ?

Red Hat JBoss A-MQ proporciona una gran cantidad de mejoras en sus Brokers de mensajería, dotándole de un valor añadido e introduciendo un extra de funcionalidad para llevar a cabo la realización de nuestro concepto de ESB de mensajería.

Entre esas mejoras que proporciona Red Hat JBoss A-MQ, hay que destacar que en sus propios Brokers de mensajería se puede introducir Apache Camel XML, lo cual nos permite insertar processors de Camel dentro de una ruta, para procesar el contenido de los mensajes pudiéndonos aprovechar también de una amplia variedad de ellos, que Camel proporciona de facto cumpliendo con el Enterprise Integration Patterns. RedHatJBossA-MQ_BrokerNetwork

Esta mejora ya nos proporciona un ESB de mensajería en sí mismo, con procesamiento del contenido de los mensajes, enrutado y adaptado a distintas implementaciones de JMS, pero ¿se queda ahí lo que Red Hat JBoss A-MQ puede ofrecer?

Otra mejora que Red Hat JBoss A-MQ proporciona son los denominados wildcard mediante los cuales un único consumidor puede suscribirse a múltiples destinos.

RedHatJBossA-MQ_WildcardsAdemás, facilita mecanismos para evitar la problemática inherente de la especificación de JMS para los suscriptores duraderos, permitiendo forwarding entre distintos destinos directamente y sin necesidad de consumidores intermedios.
RedHatJBossA-MQ_ReplacingDurableSubscriptionsWithQueues

Pero ¿y si juntamos la capacidad de los wildcards y el fordwarding entre destinos? La respuesta en este caso sería la creación de destinos virtuales mediante los cuales Red Hat JBoss A-MQ detectaría automáticamente cuándo un consumidor de una cola debería ser enlazado a un tópico.

¿En qué me afectan los destinos virtuales? Los productores envían a un tópico de la manera habitual y los consumidores consumen, valga la redundancia, usando la semántica de un tópico. Además, al ser un destino virtual, los consumidores pueden consumir de una cola física suscrita al tópico lógico, con lo que se puede ejecutar permitiendo el balanceo de carga.

RedHatJBossA-MQ_AutomatedMapping

Esta mejora tan tentadora para suplir la limitación que incluye la especificación JMS para los suscriptores duraderos, no requiere más que una configuración similar a la siguiente:
RedHatJBossA-MQ_VirtualDestination

Para terminar con todas las mejoras que incorpora Red Hat JBoss A-MQ, falta por añadir la capacidad de interoperabilidad que éste producto proporciona. Dicho producto permite, además de JMS, los protocolos AMQP, STOMP, MQTT, OpenWire y WebSocket.

Consideraciones finales

Como se puede observar, Red Hat JBoss A-MQ se convierte en una apuesta segura y una alternativa bastante interesante cuando requerimos de una plataforma enriquecida que cubra nuestra necesidad de centralización de infraestructura de mensajería mediante el patrón ESB. Además, su capacidad de interoperabilidad permite que esta solución no esté únicamente limitada a plataformas Java, ya que mediante la utilización de protocolos interoperables, como AMQP o STOMP, se puede obtener la misma abstracción que nos proporcionan los web services SOAP o REST.

Y con esto concluyo, esperando haber sido capaz de transmitiros una alternativa como plataforma de mensajería, a la que seguramente seréis capaces de sacarle un gran partido. Recordad que cada problema es un mundo y en la imaginación está el límite, así que usadla con moderación.

 

 

Elías Grande Rubio

Arquitecto SOA/BPM y Consultor de Seguridad TIC pragmático e investigador. Apasionado de la seguridad, las tecnologías middleware y de la computación de altas prestaciones. Diseñador de ideas revolucionarias que me hubieran hecho rico… pero las guardé en Megaupload y ahora escribo blogs.

Elías Grande Rubio ha escrito 7 entradas


Elías Grande Rubio

Arquitecto SOA/BPM y Consultor de Seguridad TIC pragmático e investigador. Apasionado de la seguridad, las tecnologías middleware y de la computación de altas prestaciones. Diseñador de ideas revolucionarias que me hubieran hecho rico… pero las guardé en Megaupload y ahora escribo blogs.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *