En el anterior artículo, te explicaba qué son las colas de mensajes y por qué deberías usarlas. En él, enumeraba las ventajas que tiene el uso de una cola de mensajes cuando no necesitamos procesar una información de forma inmediata. Sin embargo, una cosa es la teoría y otra bien distinta, la práctica.
Existen muchos tipos de broker de mensajería que, basándose en el concepto de intercambio de mensajes, proveen de ventajas e inconvenientes según las necesidades de tu proyecto. En este artículo, enfrentamos los diferentes protocolos para el intercambio de mensajes como son AMQP, MQTT y STOMP. Veremos qué son y cuáles son los puntos fuertes de AMQP, MQTT y STOMP, además de cuándo deberías usar cada uno
Componentes para el intercambio de mensajes
El concepto de intercambio de mensajes, asociado a una cola de mensajes, lo vimos en el artículo anterior, pero por recapitular un poco, una cola de mensajes es un espacio donde los mensajes esperan a ser entregados. Pero empecemos a llamar a cada actor por su nombre.
En primer lugar, el centro del sistema se llama broker y es el encargado de recibir y enviar los mensajes. Es como la oficina de correos: recibe los mensajes, los categoriza y los deja en la cola de mensajes, esperando poder entregarlos. Aquel que ha enviado el mensaje se llama productor o publicador, el remitente en lenguaje llano (en inglés: producer o publisher). Y el destinatario del mensaje se llama consumidor o suscriptor (en inglés, consumer o subscriber).
Explicado esto, el ciclo completo de un mensaje es el que sigue:
- Un publisher o producer envía un mensaje al broker.
- El broker recibe el mensaje y lo prepara para enviarlo a un consumer o subscriber.
- Cuando el subscriber se conecta al broker, este envía el mensaje y borra el mensaje.
Qué es AMQP. El protocolo multipropósito.
Muchas veces cuando hablamos de colas de mensajes, los desarrolladores tendemos a pensar en la herramienta que solemos conocer, dejando de lado otras posibilidades. Por ello, lo más importante es poner cara a cada uno de estos protocolos antes de empezar a ver pros y contras.
Empezamos por el más conocido de todos: AMQP. Son las siglas de Advanced Message Queuing Protocol y representan un protocolo de propósito múltiple para el intercambio de mensajes. Dispone de muchas opciones de configuración para conseguir que se adapte a los requerimientos de tu proyecto.
Dentro del protocolo AMQP, el mensaje se divide en cabeceras y cuerpo del mensaje, lo que permite mayor versatilidad. Otra de las ventajas que tiene AMQP es que permite enrutar los mensajes de formas diferentes, según se necesite, hacia una cola o varias o haciendo el modelo publisher/subscriber de forma que un mensaje llegue a muchos suscriptores al mismo tiempo. Asimismo, dispone de colas persistentes, de manera que si se reinicia el sistema, los mensajes no se borran.
Todas estas opciones hacen que AMQP sea más pesado y complejo que otras alternativas como MQTT o STOMP, pero por lo general, se adapta a casi todas las necesidades que puede tener un proyecto.
Qué es MQTT. La ligereza como punto fuerte
MQTT es la abreviatura de Message Queuing Telemetry Transport. Originalmente, IBM lo diseñó para sistemas industriales pero finalmente lo convirtió en un protocolo abierto. Sin duda, MQTT destaca por su ligereza, lo que lo convierte en la opción ideal para el Internet of Things o entornos en los que el acceso a Internet sea malo o complicado.
Cada paquete es pequeño y no dispone de todas las opciones que sí tiene su hermano mayor AMQP, pero esto puede ser ideal para aprovechar los recursos al máximo o para conexiones efímeras o infrecuentes. La ventaja de esto es que un broker de MQTT puede conectar simultáneamente miles de clientes y es idóneo para sistemas con recursos muy limitados, como un Arduino.
En definitiva, MQTT es ideal para sistemas sencillos de mensajería, donde no se requieren escenarios complejos. Por ejemplo, MQTT se usa para enviar notificaciones a dispositivos móviles o en aplicaciones como WhatsApp.
Mientras que AMQP proporciona fiabilidad absoluta en la entrega de mensajes, en el sentido de que el broker siempre confirma que ha recibido el mensaje, MQTT tiene un funcionamiento diferente. En sus términos de calidad de servicio (o Quality of Service), el productor puede configurar cómo desea comportarse en la entrega de mensajes:
-
QoS 0, también llamado at most one, intenta entregar el mensaje como mucho una vez. Esto no genera garantía en absoluto de que el mensaje ha llegado. Por ello, también se denomina este modo como fire-and-forget. Es útil cuando podemos permitirnos perder un mensaje sin que importe mucho: por ejemplo, si algunos paquetes de un termómetro doméstico se pierden.
-
QoS 1, también llamado at least once, se compromete a que el productor entregue el mensaje al menos una vez; es decir, hasta que el broker confirma la recepción. Es parecido a cómo funciona AMQP.
-
QoS 2, también llamado exactly once es el nivel más alto, pero también el más complejo y lento. En este modo, se compromete a que el mensaje solo llegará una vez a los destinatarios. Al ser el más complejo, requiere más consumo de recursos, por lo que no se suele usar mucho (va en contra de la esencia del protocolo).
Qué es STOMP. El HTTP de los mensajes
Y por último, llegamos a STOMP, el único de estos protocolos que se basa en formato texto. Esto quiere decir que todo lo que envía no es binario; es un texto que el cliente puede leer directamente, como un JSON o un XML.
STOMP es un protocolo de texto bastante sencillo y está bastante inspirado en los protocolos clásicos como HTTP dado que el frame está compuesto de forma similar a una petición HTTP: en primer lugar, figura el comando. Después las cabeceras en formato clave: valor. Posteriormente, una línea sin contenido y finalmente, el cuerpo del contenido. Esta sencillez tiene el coste de que el protocolo STOMP no posee mecanismos de suscripción ni colas.
Todo esto lo convierte en un protocolo sencillo y fácil de implementar en el lado del cliente. De hecho, es posible conectarse al servidor STOMP mediante una conexión Telnet. Sin embargo, esta sencillez característica le hace carente de muchas utilidades que si tiene AMQP.
Es un protocolo que generalmente se usa apoyado en WebSocket; es decir, permitir intercambiar información al navegador sin tener que hacer peticiones Ajax basadas en pulling. Aunque es posible utilizar WebSocket sin más, este protocolo aporta semántica y permite al usuario suscribirse a canales concretos.
Cuándo usar AMQP, MQTT y STOMP
Ante todo el abanico de protocolos que disponemos para el intercambio de mensajes, es posible que tengas dudas sobre cuál usar. Al final, el mejor protocolo lo va a determinar las necesidades del proyecto en el que se implemente.
Por un lado, STOMP es un protocolo orientado a texto y se suele emplear para aportar semántica a los websocket. Si tu intención es crear una aplicación que utilice WebSocket para el intercambio de información, como enviar datos de cotización en tiempo real, y además, no quieres complicar la implementación, puedes emplear STOMP. Un protocolo sencillo de transmitir y sencillo de depurar.
Por otro lado, MQTT es el protocolo ideal para dispositivos IoT, con ancho de banda reducido y recursos limitados. Como mencionábamos antes, es un protocolo que apenas requiere CPU o RAM (sobre todo en el modo QoS fire and forget). En la industria se utiliza mucho para transmitir el estado de diferentes máquinas o componentes a unidades de control central (termómetros, barómetros, máquinas de montaje, etc). En definitiva, es el protocolo perfecto para telemetría.
Otro de los usos frecuentes de MQTT son las aplicaciones de Chat. Con el auge de las redes sociales y las diferentes aplicaciones de chat, MQTT ha tenido un resurgir notable. En estos escenarios simples, la comunicación que requiere una aplicación de chat es sencila porque el mensaje no tiene que ser enrutado usando sistemas complejos.
Y finalmente, AMQP. Es un protocolo multipropósito y muy confiable. Es tremendamente útil para comunicación entre servicios del backend, donde el ancho de banda es grande y los recursos no son limitados. Este protocolo tiene multitud de configuraciones y de herramientas para adaptarse a las necesidades de tu proyecto, además de ser bastante fiable. En definitiva, si no tienes limitaciones de recursos, necesitas una fiabilidad alta en los mensajes y/o enrutados más complejos, AMQP es sin duda tu protocolo.
Conclusión
Ya hemos visto los principales protocolos para el intercambio de mensajes entre sistemas y hemos profundizado en los puntos fuertes de cada uno. Cuando necesites comunicar dos plataformas, analiza bien las necesidades de tu proyecto y escoge sabiamente el protocolo que mejor se adapta a ellas.
Con este artículo cerramos una colección de post dedicado al intercambio de mensajes. En primer lugar, vimos como implementarlo en PHP usando el componente Symfony Messenger. Como segundo punto, te expliqué qué son y por qué deberías emplear el intercambio de mensajes entre diferentes servicios. Y por último, hemos analizado los puntos fuertes de los protocolos más frecuentes de intercambio de mensajes.
Ya no tienes excusa para no utilizar el intercambio de mensajes cuando estés diseñando un proyecto. Así que, ya sabes la teoría y la práctica para usarlo en tu próximo proyecto.
¡Qué tengas un feliz coding!
