El middleware orientado a mensajes ( MOM ) es una infraestructura de software o hardware que respalda el envío y la recepción de mensajes entre sistemas distribuidos. El middleware orientado a mensajes contrasta con el middleware orientado a streaming, en el que los datos se comunican como una secuencia de bytes sin límites de mensajes explícitos. Tenga en cuenta que los protocolos de streaming casi siempre se construyen sobre protocolos que utilizan mensajes discretos, como tramas (Ethernet ), datagramas (UDP ), paquetes (IP) , celdas (ATM ), etc.
MOM permite que los módulos de aplicación se distribuyan en plataformas heterogéneas y reduce la complejidad del desarrollo de aplicaciones que abarcan múltiples sistemas operativos y protocolos de red. El middleware crea una capa de comunicaciones distribuidas que aísla al desarrollador de aplicaciones de los detalles de los diversos sistemas operativos e interfaces de red. Las interfaces de programación de aplicaciones ( API ) que se extienden a través de diversas plataformas y redes suelen ser proporcionadas por MOM. [1]
Esta capa de middleware permite que los componentes de software (aplicaciones, Jakarta Enterprise Beans , servlets y otros componentes) que se han desarrollado de forma independiente y que se ejecutan en diferentes plataformas de red interactúen entre sí. Las aplicaciones distribuidas en diferentes nodos de red utilizan la interfaz de la aplicación para comunicarse. Además, al proporcionar una interfaz administrativa, este nuevo sistema virtual de aplicaciones interconectadas puede volverse tolerante a fallas y seguro. [2]
MOM proporciona elementos de software que residen en todos los componentes de comunicación de una arquitectura cliente/servidor y que, por lo general, admiten llamadas asincrónicas entre las aplicaciones cliente y servidor. MOM reduce la participación de los desarrolladores de aplicaciones en la complejidad de la naturaleza maestro-esclavo del mecanismo cliente/servidor.
Todos estos modelos hacen posible que un componente de software afecte el comportamiento de otro componente en una red. Se diferencian en que el middleware basado en RPC y ORB crea sistemas de componentes estrechamente acoplados, mientras que los sistemas basados en MOM permiten un acoplamiento flexible de los componentes. En un sistema basado en RPC u ORB, cuando un procedimiento llama a otro, debe esperar a que el procedimiento llamado regrese antes de poder hacer cualquier otra cosa. En estos modelos de mensajería mayoritariamente sincrónicos, el middleware funciona en parte como un superenlazador, que ubica el procedimiento llamado en una red y utiliza servicios de red para pasar parámetros de función o método al procedimiento y luego devolver resultados. [2] Nótese que los intermediarios de solicitudes de objetos también admiten mensajería totalmente asincrónica a través de invocaciones unidireccionales. [3]
Las razones principales para utilizar un protocolo de comunicaciones basado en mensajes incluyen su capacidad para almacenar (almacenar en búfer), enrutar o transformar mensajes mientras se transmiten desde los remitentes a los receptores.
Otra ventaja de la mensajería mediada por el proveedor de mensajería entre clientes es que, al añadir una interfaz administrativa, se puede supervisar y ajustar el rendimiento. De este modo, las aplicaciones cliente se liberan de todos los problemas, excepto el de enviar, recibir y procesar mensajes. Depende del código que implementa el sistema MOM y del administrador resolver cuestiones como la interoperabilidad, la fiabilidad, la seguridad, la escalabilidad y el rendimiento.
Al utilizar un sistema MOM, un cliente realiza una llamada a la API para enviar un mensaje a un destino administrado por el proveedor. La llamada invoca los servicios del proveedor para enrutar y entregar el mensaje. Una vez enviado el mensaje, el cliente puede continuar con otras tareas, con la confianza de que el proveedor retiene el mensaje hasta que un cliente receptor lo recupera. El modelo basado en mensajes, junto con la mediación del proveedor, permite crear un sistema de componentes débilmente acoplados.
MOM comprende una categoría de software de comunicación entre aplicaciones que generalmente se basa en el paso asincrónico de mensajes , en lugar de una arquitectura de solicitud-respuesta . En los sistemas asincrónicos, las colas de mensajes proporcionan almacenamiento temporal cuando el programa de destino está ocupado o no está conectado. Además, la mayoría de los sistemas MOM asincrónicos proporcionan almacenamiento persistente para respaldar la cola de mensajes. Esto significa que el remitente y el receptor no necesitan conectarse a la red al mismo tiempo ( entrega asincrónica ) y se resuelven los problemas con la conectividad intermitente. También significa que si la aplicación receptora falla por cualquier motivo, los remitentes pueden continuar sin verse afectados, ya que los mensajes que envían simplemente se acumularán en la cola de mensajes para su procesamiento posterior cuando el receptor se reinicie.
Muchas implementaciones de middleware orientadas a mensajes dependen de un sistema de cola de mensajes . Algunas implementaciones permiten que la lógica de enrutamiento sea proporcionada por la propia capa de mensajería, mientras que otras dependen de las aplicaciones cliente para proporcionar información de enrutamiento o permiten una combinación de ambos paradigmas. Algunas implementaciones utilizan paradigmas de distribución de difusión o multidifusión .
En un sistema de middleware basado en mensajes, el mensaje recibido en el destino no necesita ser idéntico al mensaje enviado originalmente. Un sistema MOM con inteligencia incorporada puede transformar mensajes y enrutarlos para que coincidan con los requisitos del remitente o del destinatario. [4] Junto con las funciones de enrutamiento y difusión/ multidifusión , una aplicación puede enviar un mensaje en su propio formato nativo, y dos o más aplicaciones pueden recibir cada una una copia del mensaje en su propio formato nativo. Muchos sistemas MOM modernos proporcionan herramientas sofisticadas de transformación (o mapeo) de mensajes que permiten a los programadores especificar reglas de transformación aplicables a una operación de arrastrar y soltar de interfaz gráfica de usuario simple .
La principal desventaja de muchos sistemas de middleware orientados a mensajes es que requieren un componente adicional en la arquitectura , el agente de transferencia de mensajes ( message broker ). Como ocurre con cualquier sistema , añadir otro componente puede provocar reducciones en el rendimiento y la fiabilidad, y también puede hacer que el sistema en su conjunto sea más difícil y costoso de mantener .
Además, muchas comunicaciones entre aplicaciones tienen un aspecto intrínsecamente sincrónico , ya que el remitente desea específicamente esperar una respuesta a un mensaje antes de continuar (consulte computación en tiempo real y tiempo casi real para casos extremos). Debido a que la comunicación basada en mensajes funciona inherentemente de manera asincrónica, es posible que no se adapte bien a tales situaciones. Dicho esto, la mayoría de los sistemas MOM tienen funciones para agrupar una solicitud y una respuesta como una única transacción pseudosincrónica.
En un sistema de mensajería sincrónica, la función que realiza la llamada no regresa hasta que la función llamada ha terminado su tarea. En un sistema asincrónico débilmente acoplado , el cliente que realiza la llamada puede continuar cargando trabajo al receptor hasta que se agoten los recursos necesarios para manejar este trabajo y el componente llamado falle. Por supuesto, estas condiciones se pueden minimizar o evitar monitoreando el rendimiento y ajustando el flujo de mensajes, pero este es un trabajo que no es necesario con un sistema de mensajería sincrónica. Lo importante es comprender las ventajas y desventajas de cada tipo de sistema. Cada sistema es apropiado para diferentes tipos de tareas. A veces, se requiere una combinación de los dos tipos de sistemas para obtener el comportamiento deseado.
Históricamente, ha habido una falta de estándares que regulen el uso de middleware orientado a mensajes, lo que ha causado problemas. La mayoría de los principales proveedores tienen sus propias implementaciones, cada una con su propia interfaz de programación de aplicaciones (API) y herramientas de gestión.
Uno de los estándares más antiguos para middleware orientado a mensajes es la especificación XATMI (Distributed Transaction Processing: The XATMI Specification) del grupo X/Open, que estandariza las API para las comunicaciones entre procesos . Las implementaciones conocidas de esta API son el middleware Enduro/X de ATR Baltic y Tuxedo de Oracle .
El protocolo de colas de mensajes avanzado (AMQP) es un estándar aprobado por OASIS [5] e ISO [6] que define el protocolo y los formatos utilizados entre los componentes de la aplicación que participan, por lo que las implementaciones son interoperables. AMQP se puede utilizar con esquemas de enrutamiento flexibles, incluidos los paradigmas de mensajería comunes como punto a punto , distribución en abanico , publicación/suscripción y solicitud-respuesta (estos se omiten intencionalmente de la v1.0 del estándar de protocolo en sí, pero dependen de la implementación particular y/o el protocolo de red subyacente para el enrutamiento). También admite la gestión de transacciones, la cola, la distribución, la seguridad, la gestión, la agrupación en clústeres, la federación y el soporte multiplataforma heterogéneo. Las aplicaciones Java que utilizan AMQP suelen estar escritas en Java JMS. Otras implementaciones proporcionan API para C# , C++ , PHP , Python , Ruby y otros lenguajes de programación .
La arquitectura de alto nivel (HLA IEEE 1516) es un estándar del Instituto de Ingenieros Eléctricos y Electrónicos (IEEE) y la Organización de Estándares de Interoperabilidad de Simulación (SISO) para la interoperabilidad de la simulación. Define un conjunto de servicios, proporcionados a través de una API en C++ o Java. Los servicios ofrecen intercambio de información basado en publicación/suscripción, basado en un modelo de objetos de federación modular. También hay servicios para el intercambio coordinado de datos y avance de tiempo, basado en el tiempo de simulación lógico, así como puntos de sincronización. Los servicios adicionales proporcionan transferencia de propiedad, optimizaciones de distribución de datos y monitoreo y administración de los federados participantes (sistemas).
El transporte de telemetría MQ (MQTT) es un estándar ISO (ISO/IEC PRF 20922) respaldado por la organización OASIS. Proporciona un protocolo de transporte de mensajes confiable, de publicación/suscripción y liviano, sobre TCP/IP, adecuado para la comunicación en contextos M2M/IoT donde se requiere una pequeña huella de código y/o el ancho de banda de la red es escaso.
El Servicio de distribución de datos (DDS) del Object Management Group proporciona un estándar de middleware de publicación/suscripción (P/S) orientado a mensajes que tiene como objetivo permitir intercambios de datos escalables, en tiempo real, confiables, de alto rendimiento e interoperables entre publicadores y suscriptores. [7] El estándar proporciona interfaces para C++, C++11, C, Ada , Java y Ruby.
El Protocolo eXtensible de Mensajería y Presencia ( XMPP ) es un protocolo de comunicaciones para middleware orientado a mensajes basado en el Lenguaje de Marcado Extensible ( XML ). Diseñado para ser extensible, el protocolo también se ha utilizado para sistemas de publicación-suscripción, señalización para VoIP, video, transferencia de archivos, juegos, aplicaciones de Internet de las Cosas como la red inteligente y servicios de redes sociales. A diferencia de la mayoría de los protocolos de mensajería instantánea, XMPP se define en un estándar abierto y utiliza un enfoque de sistemas abiertos de desarrollo y aplicación, por el cual cualquiera puede implementar un servicio XMPP e interoperar con las implementaciones de otras organizaciones. Debido a que XMPP es un protocolo abierto, las implementaciones se pueden desarrollar utilizando cualquier licencia de software; aunque muchas implementaciones de servidor, cliente y biblioteca se distribuyen como software libre y de código abierto , también existen muchas implementaciones de software libre y propietario. El Grupo de Trabajo de Ingeniería de Internet (IETF) formó un grupo de trabajo XMPP en 2002 para formalizar los protocolos centrales como una tecnología de mensajería instantánea y presencia del IETF. El grupo de trabajo XMPP elaboró cuatro especificaciones (RFC 3920, RFC 3921, RFC 3922, RFC 3923), que se aprobaron como estándares propuestos en 2004. En 2011, RFC 3920 y RFC 3921 fueron reemplazadas por RFC 6120 y RFC 6121 respectivamente, siendo RFC 6122 la que especifica el formato de dirección XMPP. Además de estos protocolos básicos estandarizados en el IETF, la Fundación de Estándares XMPP (anteriormente Jabber Software Foundation) participa activamente en el desarrollo de extensiones XMPP abiertas. El software basado en XMPP se implementa ampliamente en Internet, según la Fundación de Estándares XMPP, y constituye la base del Marco de Capacidades Unificadas del Departamento de Defensa (DoD). [8]
El entorno de programación Java EE proporciona una API estándar llamada Java Message Service (JMS), que es implementada por la mayoría de los proveedores de MOM y tiene como objetivo ocultar las implementaciones particulares de la API de MOM; sin embargo, JMS no define el formato de los mensajes que se intercambian, por lo que los sistemas JMS no son interoperables.
Un esfuerzo similar se está llevando a cabo con el proyecto OpenMAMA, que está en constante evolución y que tiene como objetivo proporcionar una API común, especialmente para clientes C. A partir de agosto de 2012, es principalmente apropiada para distribuir datos orientados al mercado (por ejemplo, cotizaciones de acciones) a través de middleware de publicación y suscripción.
Las colas de mensajes permiten el intercambio de información entre aplicaciones distribuidas. Una cola de mensajes puede residir en la memoria o en el almacenamiento en disco. Los mensajes permanecen en la cola hasta el momento en que son procesados por un consumidor de servicios. A través de la cola de mensajes, la aplicación puede implementarse de forma independiente: no necesitan conocer la posición de los demás o continuar implementando procedimientos para eliminar la necesidad de esperar para recibir este mensaje. [9]
[14]