Messaging con AMQP, MQTT y STOMP

Introducción

El mundo actual requiere cada vez más de la inmediatez en recibir y procesar información.

Llegar al punto de lo que se denomina real-time, que como sabemos nunca es real-time como tal.

Sin embargo, debemos tender a ello con el objetivo de poder tomar decisiones o acciones lo más rápidas posible en el tiempo de acuerdo a lo que ya ha sucedido (por eso no será nunca real-time puro, porque siempre será milisegundos o segundos después de suceder algo).

Sin embargo, la velocidad de recepción, tratamiento y acción de acuerdo a lo sucedido es o puede ser a veces un proceso crítico de suma importancia.

En el caso de la nube o cloud, de procesos críticos o de generación constante de información, y más concretamente en el caso de IoT, este campo de la prontitud de recibir, evaluar, analizar y procesar la información se hace casi más importante aún.

Para acercarnos a ello, existen muchas tecnologías que nos ofrecen posibilidades muy interesantes.

Una de ellas son los protocolos de Messasing que vamos a enumerar y ver a continuación.

Este artículo no tratará una visión muy profunda de estos protocolos, pero sí una visión generalista pero suficiente, que nos permita ponernos en contexto de posibles y futuros proyectos.

¿Quién es quién?

¿Sabes lo que es AMQP, MQTT y STOMP?.

¿Sabes diferenciarlos?.

¿Sabes para qué sirven?.

Quizás no sepas que significan estas siglas.

Quizás si lo sepas pero no lo tengas claro.

Quizás seas un experto en la materia y esta entrada te resulte intrascendente.

El caso es que cuando hablo con amigos y compañeros de trabajo sobre estos términos, he visto que muchos hacían una mueca en su gesto y no sabían en realidad de que les hablaba, otros movían un poco las cejas ya que sí habían oído campanas pero no sabían dónde, y otros, con los dedos de una mano realmente (y me sobran dedos) habían trabajado con alguno de ellos y sabían más o menos de que les hablaba, a qué sabían, de qué color eran, sus virtudes y sus miserias…

Lo más interesante no obstante llegaba cuando hablábamos de las diferencias entre unos y otros.

Y creedme que esto sí representa un problema, ya que la toma de decisiones a la hora de usar uno y no otro, son muy importantes, sobre todo desde el punto de vista arquitectural.

Es por todo esto que me he animado a escribir esta entrada con el fin de echar un poco de luz sobre el significado de AMQT, MQTT y STOMP, qué son y qué diferencias tienen entre sí.

Creo que a más de uno le resultará interesante la lectura… o al menos eso es lo que espero.

Antes de empezar…

Antes de empezar, un aviso para los más despitados y que han empezado a leer esto…

Estamos hablando de Messaging, o quizás mejor… protocolos de Messaging.

Por otro lado, aquí tenemos que tener claros 3 conceptos muy simples:

· Broker

· Publishers

· Subscribers

El broker será el puente o intermediario que une y comunica a los publishers y subscribers.

Un publisher publicará/enviará un mensaje al broker.

El broker, se encargará por su parte de recibir dicho mensaje y distribuirlo a los subscribers que estén conectados al broker.

Aunque ya te habrás construido una imagen en tu cabeza de todo esto, comparto contigo la mía:

Aunque depende de cada protocolo, normalmente para asegurar la entrega de determinados mensajes sólo a los subscribers que están interesados en dichos mensajes, se usan lo que se denominan topics, que ahora no voy a explicar de forma detallada.

Otro nivel de entrega confiable sería una entrega segura de estos mensajes, algo que vamos a mencionar de pasada en este artículo.

Siglas de AMQP, MQTT y STOMP

Antes de entrar en materia, vamos a empezar a definir, desgranar las siglas AMQT, MQTT y STOMP porque viendo las palabras que lo forman, da ya por sí solo algunas pistas:

AQMT: Advanced Message Queuing Protocol.

MQTT: Message Queue Telemetry Transport (también conocido como MQ Telemetry Transport).

STOMP: Simple/Streaming Text Oriented Messaging Protocol.

Nota: ojo con la palabra Queue de MQTT que puede llevar a confusión. A continuación lo detallaré.

2 tips rápidos sobre la historia de ellos

Sin querer pararme demasiado aquí, sí me veo en la necesidad de dar cuatro pinceladas rápidas sobre la historia de cada uno de estos protocolos.

AMQP surge como necesidad de cubrir el espacio no cubierto por otros protocolos.

Es un protocolo de transmisión binaria.

MQTT fue desarrollado por IBM de forma interna para trabajar con el sector industrial.

Unos años después, el proyecto fue movido a la comunidad Open Source.

Su crecimiento y popularidad ha tenido especial repercusión con los dispositivos móviles y con IoT.

STOMP está basado en cadenas de texto.

La existencia real de STOMP es la usar HTTP y la búsqueda de la simplicidad e interoperabilidad.

Tanto es así que podemos conectarnos a un broker STOMP con un cliente de Telnet.

Comparándolos más de cerca…

Un tip previo antes de continuar:

Normalmente se conoce como Publicador al proceso que envía mensajes, y Subscriptores a los receptores que reciben los mensajes.

Por otro lado, debemos tener en cuenta que todos los protocolos de los que hablamos en este artículo, se basan en el patrón Publish-subscribe (https://en.wikipedia.org/wiki/Publish%E2%80%93subscribe_pattern).

Se trata de un protocolo de envío/recepción de mensajes usando el protocolo TCP/IP.

AMQP

Sus principales objetivos a cubrir son la fiabilidad y la interoperabilidad.

Es usado como un complemento de asincronía a HTTP.

Posee una cabecera con propiedades y un cuerpo con el mensaje.

Entre sus características más destacadas podemos enumerar que está basado en tópicos (topics) y cabeceras (headers) para envío (publicador) y recepción de mensajes (subscriptor), enrutamiento flexible, colas confiables, transacciones y seguridad.

Punto a favor para AMQP sobre MQTT es el hecho de soportar transaccionalidad.

Adicionalmente, se puede llegar a restringir el acceso a las colas y gestionar su profundidad.

En resumen, cubre escenarios mucho más amplios y complejos que MQTT.

Ejemplos de su uso: Google o la NASA.

MQTT

Es más sencillo que AMQP, de hecho, su simplicidad y facilidad de implantación es uno de sus puntos fuertes.

Aunque lleva la palabra “Queue” en sus siglas, no tiene colas.

No posee cabeceras o propiedades del mensaje.

Su potencia se deja ver especialmente en la entrega y recepción de mensajes. Es decir, con la publicación y subscripción de mensajes.

Está especialmente indicado para trabajar con localizaciones remotas en las que el ancho de banda es limitado o cambiante, o para recursos limitados.

También es recomendado para escenarios de mensajería poco complejos.

Se usa incluso para notificaciones a dispositivos móviles.

Los brokers MQTT soportan varios miles de conexiones concurrentes de dispositivos.

Un punto adicional de MQTT es todo lo concerniente a la seguridad. Es posible intercambiar los mensajes en diferentes niveles de seguridad, utilizando transporte SSL/TLS, autenticar con certificados o mediante usuario y contraseña.

MQTT también ofrece todo lo concerniente a la calidad de servicio o QoS (Quality of Service). De este modo, el publisher puede definir la calidad de su mensaje en tres niveles:

· QoS 0 at most one entregando el mensaje como mucho una vez y sin garantías de recepción, es decir, en modo no confiable. También se le denomina por ello fire-and-forget.

· QoS 1 at least once entregando el mensaje al menos una vez, es decir, el mensaje será enviado varias veces si es necesario hasta que el broker confirme su envío a través de la red.

· QoS 2 exactly once es más complejo. Por una parte requiere que el publisher guardará el mensaje siempre que el broker no confirme su envío a través de la red. Esto requiere más control entre publisher y broker y por lo tanto, que el proceso sea más lento.

No obstante, una tarea compleja de este protocolo es llevarlo al mundo multi-tenant.

Un ejemplo de su uso: WhatsApp

https://www.facebook.com/notes/facebook-engineering/building-facebook-messenger/10150259350998920

STOMP

Es el único de estos protocolos que está basado en texto, con comunicaciones de texto, como por ejemplo un JSON o un XML.

Posee al igual que AMQP una cabecera del mensaje con propiedades y un cuerpo con el mensaje.

No posee topics de subscripción, colas o intercambio de mensajes.

Es también muy sencillo de implantar.

Un consumidor se subscribirá a los destinos que se indiquen.

STOMP puede ser utilizado por lo tanto para actualizar el estado e información de un proceso en una página Web, una aplicación móvil, o en un proceso de tiempo real.

RabbitMQ

Y aquí como bonus track de este artículo citaré a RabbitMQ.

Para trabajar con AMQP, MQTT o STOMP no necesitamos RabbitMQ, pero RabbitMQ sí tiene cierta relación con estos tres protocolos.

El porqué es muy sencillo de comprender.

RabbitMQ es un proyecto de código abierto escrito en Erlang que implementa el estándar AMQP y que puede utilizar los otros dos protocolos descritos en este artículo a través de plugins, así como tener la posibilidad de trabajar con múltiples clientes desarrollados en distintos lenguajes de programación (Java, .NET, node.js, Ruby, PHP, etc).

A RabbitMQ se la denomina por todo ello como “políglota” y como Multi Protocol Messaging Server.

Para entendernos, es un middleware de mensajería que ofrece una alta confiabilidad, disponibilidad y escalabilidad, además de una buena combinación entre rendimiento y latencia.

Un ejemplo de su uso: Instagram o Mozilla

Más información para los más inquietos

AMQP 0.9.1 Specification

http://www.rabbitmq.com/resources/specs/amqp0-9-1.pdf

MQTT v3.1 Protocol Specification

http://public.dhe.ibm.com/software/dw/webservices/ws-mqtt/mqtt-v3r1.html

STOMP v1.2 Specification

https://stomp.github.io/stomp-specification-1.2.html

Erlang

https://es.wikipedia.org/wiki/Erlang

RabbitMQ

https://es.wikipedia.org/wiki/RabbitMQ