Un message broker es un software que permite que las aplicaciones, los sistemas y los servicios se comuniquen entre sí e intercambien información. Para ello, el message broker convierte mensajes entre protocolos de mensajería formal. Esto permite que los servicios interdependientes "hablen" entre sí directamente, incluso si están escritos en diferentes lenguajes o implementados en plataformas distintas.

Los message brokers son módulos de software dentro de las soluciones de middleware de mensajería o middleware orientado a mensajes (MOM). Este tipo de middleware proporciona a los desarrolladores un medio estandarizado de manejo del flujo de datos entre los componentes de una aplicación para que puedan enfocarse en su lógica central. Puede servir como una capa de comunicaciones distribuidas que permite que las aplicaciones que abarcan múltiples plataformas se comuniquen internamente.

Los message brokers pueden validar, almacenar, enrutar y enviar mensajes a los destinos adecuados. Sirven como intermediarios entre otras aplicaciones, permitiendo a los remitentes emitir mensajes sin saber dónde están los receptores, si están activos o no, o cuál es su número. Esto facilita el desacoplamiento de procesos y servicios en los sistemas.

Para proporcionar un almacenamiento de mensajes confiable y una entrega garantizada, los message brokers normalmente confían en una subestructura o componente denominado cola de mensajes,  que almacena y ordena los mensajes hasta que las aplicaciones que los consumen puedan procesarlos. En una cola de mensajes, los mensajes se almacenan en el orden exacto en el que se transmitieron y permanecen en la cola hasta que se confirma la recepción.

La mensajería asincrónica (15:11) se refiere al tipo de comunicación entre aplicaciones que hacen posible los message brokers. Evita la pérdida de datos valiosos y permite que los sistemas continúen funcionando incluso frente a problemas de latencia o conectividad intermitente comunes en las redes públicas. La mensajería asincrónica garantiza que los mensajes se entreguen una vez (y solo una vez) en el orden correcto en relación con otros mensajes.

Los message brokers pueden incluir administradores de colas que manejan las interacciones entre múltiples colas de mensajes, así como servicios que ofrecen enrutamiento de datos, traducción de mensajes, persistencia y funcionalidades de gestión del estado del cliente.

Los message brokers ofrecen dos patrones básicos de distribución de mensajes o estilos de mensajería:

Mensajería punto a punto: este es el patrón de distribución utilizado en las colas de mensajes con una relación de uno a uno entre el remitente y el receptor del mensaje. Cada mensaje de la cola se envía a un solo destinatario y se consume solo una vez. La mensajería punto a punto se solicita cuando se debe actuar en respuesta a un mensaje solo una vez. Ejemplos de casos de uso adecuados para este estilo de mensajería incluyen la gestión de nóminas y transacciones financieras. En estos sistemas, tanto los remitentes como los destinatarios necesitan una garantía de que cada pago se enviará solo una vez.

Mensajería de publicación/suscripción: en este patrón de distribución de mensajes, a menudo denominado "pub/sus", el productor de cada mensaje lo publica en un tema y varios consumidores de mensajes se suscriben a temas sobre los que desean recibir mensajes. Todos los mensajes publicados sobre un tema se distribuyen a todas las aplicaciones suscritas al mismo. Este es un método de distribución de estilo transmisión, en el que existe una relación de uno a muchos entre quien publica el mensaje y sus consumidores. Si, por ejemplo, una aerolínea difundiera actualizaciones sobre los horarios de aterrizaje o la demora de sus vuelos, varias partes podrían hacer uso de la información: el personal de tierra que realiza el mantenimiento y reabastecimiento de combustible del avión, los acomodadores de equipaje, los asistentes de vuelo y pilotos que se preparan para el siguiente vuelo del avión y los operadores de pantallas visuales de información al público. En este escenario, sería apropiado un estilo de mensajería pub/sus.

Las aplicaciones nativas en la nube están creadas para aprovechar las ventajas inherentes a la computación en la nube, incluida la flexibilidad, la escalabilidad y la implementación rápida. Estas aplicaciones están conformadas por componentes pequeños, discretos y reutilizables llamados microservicios. Cada microservicio se implementa y se puede ejecutar de forma independiente de los demás. Esto significa que cualquiera de ellos se puede actualizar, escalar o reiniciar sin afectar otros servicios del sistema. Los microservicios, a menudo empaquetados en contenedores, funcionan juntos para formar una aplicación completa, aunque cada uno tiene su propia pila, incluida una base de datos y un modelo de datos que pueden diferir de los demás.

Los microservicios deben tener un medio de comunicarse entre sí para funcionar en conjunto. Los message brokers son un mecanismo que utilizan para crear la red troncal de comunicaciones compartidas.

Los message brokers se utilizan a menudo para gestionar las comunicaciones entre los sistemas locales y los componentes de la nube en entornos de nube híbrida.  El uso de un message broker brinda un mayor control sobre las comunicaciones entre servicios, lo que garantiza que los datos se envíen de manera segura, confiable y eficiente entre los componentes de una aplicación. Los message brokers pueden desempeñar un papel similar en la integración de entornos multinube, lo que permite la comunicación entre cargas de trabajo y tiempos de ejecución que residen en diferentes plataformas. También son adecuados para su uso en computación sin servidor, en la que los servicios individuales alojados en la nube se ejecutan de acuerdo a las necesidades y a petición.

API REST se utilizan normalmente para las comunicaciones entre microservicios. El término Transferencia de estado representacional (REST) define un conjunto de principios y restricciones que los desarrolladores pueden seguir al crear servicios web. Cualquier servicio que se adhiera a ellos podrá comunicarse a través de un conjunto de operadores y solicitudes uniformes compartidos sin estado. La interfaz de programación de aplicaciones (API) denota el código subyacente que, si se ajusta a las reglas REST, permite que los servicios se comuniquen entre sí.

Las API REST utilizan el Protocolo de transferencia de hipertexto (HTTP) para comunicarse. Debido a que HTTP es el protocolo de transporte estándar de la Internet pública, las API REST son ampliamente conocidas, utilizadas con frecuencia y ampliamente interoperables. Sin embargo, HTTP es un protocolo de solicitud/respuesta, por lo que es mejor utilizarlo en situaciones que requieren una solicitud/respuesta sincrónica. Esto significa que los servicios que realizan solicitudes a través de API REST deben diseñarse para esperar una respuesta inmediata. Si el cliente que recibe la respuesta no funciona, el servicio de envío se bloqueará mientras espera la respuesta. La lógica de gestión de errores y conmutación por falla debe integrarse en ambos servicios.

Los message brokers permiten comunicaciones asincrónicas entre servicios para que el servicio de envío no tenga que esperar la respuesta del servicio de recepción. Esto mejora la tolerancia a fallas y la resistencia en los sistemas en los que se emplean. Además, el uso de message brokers facilita el escalado de los sistemas, ya que un patrón de mensajería pub/sus puede admitir fácilmente números cambiantes de servicios. Los message brokers también realizan un seguimiento de los estados de los consumidores.

Mientras que los message brokers pueden admitir dos o más patrones de mensajería, incluidas las colas de mensajes y pub/sus, las plataformas de transmisión de eventos solo ofrecen patrones de distribución de estilo pub/sus. Diseñadas para usarse con grandes volúmenes de mensajes, las plataformas de transmisión de eventos son fácilmente escalables. Son capaces de ordenar flujos de registros en categorías llamadas temas y almacenarlos durante un período de tiempo predeterminado. Sin embargo, a diferencia de los message brokers, las plataformas de transmisión de eventos no pueden garantizar la entrega de mensajes ni rastrear qué consumidores han recibido mensajes.

Las plataformas de transmisión de eventos ofrecen más escalabilidad que los message brokers, pero menos características que garantizan la tolerancia a fallas (como el reenvío de mensajes), y capacidades más limitadas de enrutamiento y puesta en cola de mensajes.

Conozca más sobre la arquitectura impulsada por eventos.

Un bus de servicio empresarial (ESB) es un patrón de arquitectura que a veces se utiliza en arquitecturas orientadas a servicios implementadas en las empresas. En un ESB, una plataforma centralizada de software combina protocolos de comunicación y formatos de datos en un "lenguaje común" que todos los servicios y aplicaciones de la arquitectura pueden compartir. Podría, por ejemplo, traducir las solicitudes que recibe de un protocolo (como XML) a otro (como JSON). Los ESB transforman la carga útil de sus mensajes mediante un proceso automatizado. La plataforma de software centralizada también maneja otra lógica de orquestación, como la conectividad, el enrutamiento y el procesamiento de solicitudes.

Sin embargo, las infraestructuras ESB son complejas y pueden ser difíciles de integrar y costosas de mantener. Es difícil darle solución a los problemas relacionados con estas infraestructuras cuando ocurren en entornos de producción, no son fáciles de escalar y la actualización es tediosa.

Los message brokers son una alternativa "ligera" a los ESB que brindan una funcionalidad similar, vale decir, un mecanismo para las comunicaciones entre servicios, de manera más simple y a menor costo. Son adecuados para su uso en las arquitecturas de microservicios, que se han vuelto más frecuentes a medida que los ESB han perdido popularidad.

La implementación de message brokers puede abordar una amplia variedad de necesidades comerciales en todas las industrias y en diversos entornos informáticos empresariales. Son útiles en cualquier momento y lugar donde se requiera una comunicación confiable entre aplicaciones y una entrega segura de mensajes.

Los message brokers se emplean a menudo de las siguientes formas:

• Transacciones financieras y procesamiento de pagos: es fundamental asegurarse de que los pagos se envíen una sola vez. El uso de un message broker para manejar los datos de estas transacciones ofrece la seguridad de que la información de pago no se perderá ni se duplicará accidentalmente, proporciona un comprobante de recepción y permite que los sistemas se comuniquen de manera confiable incluso cuando las redes intermediarias no funcionan.
  
  
• Procesamiento y cumplimiento de pedidos de comercio electrónico: si hace negocios en línea, la solidez de la reputación de su marca depende de la confiabilidad de su sitio web y plataforma de comercio electrónico. La capacidad de los message brokers de mejorar la tolerancia a fallas y garantizar que los mensajes se consuman una sola vez los convierte en una opción natural para procesar pedidos en línea.
  
  
• Protección de datos altamente sensibles inactivos y en tránsito: si su industria es un sector estrictamente regulado o su empresa enfrenta importantes riesgos de seguridad, elija una solución de mensajería con capacidades de cifrado end-to-end.