El middleware orientado a mensajes ( MOM) es una infraestructura de software o hardware que admite el envío y la recepción de mensajes entre sistemas distribuidos. 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 varios sistemas operativos y protocolos de red. El middleware crea una capa de comunicaciones distribuidas que aísla al desarrollador de la aplicación de los detalles de los diversos sistemas operativos e interfaces de red. Las API que se extienden a través de diversas plataformas y redes suelen ser proporcionadas por MOM.
Esta capa de middleware permite que los componentes de software (aplicaciones, Enterprise JavaBeans, servlets y otros componentes) que se han desarrollado de forma independiente y que se ejecutan en diferentes plataformas en 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 confiable y seguro.
MOM proporciona elementos de software que residen en todos los componentes de comunicación de una arquitectura cliente / servidor y, por lo general, admiten llamadas asincrónicas entre las aplicaciones cliente y servidor. MOM reduce la participación de los desarrolladores de aplicaciones con 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. Son diferentes 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 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 síncrona, el middleware funciona en parte como un superenlazador, ubicando el procedimiento llamado en una red y usando servicios de red para pasar parámetros de función o método al procedimiento y luego devolver resultados.
Las razones principales para usar un protocolo de comunicaciones basado en mensajes incluyen su capacidad para almacenar (almacenar en búfer), enrutar o transformar mensajes mientras los transmite de remitentes a receptores.
Otra ventaja de la mensajería mediada por el proveedor de mensajería entre clientes es que al agregar una interfaz administrativa, puede monitorear y ajustar el rendimiento. De este modo, las aplicaciones cliente se liberan de forma eficaz 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 problemas como interoperabilidad, confiabilidad, seguridad, escalabilidad y rendimiento.
Con 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 que ha enviado el mensaje, el cliente puede continuar haciendo otro trabajo, 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 poco acoplados.
MOM comprende una categoría de inter aplicación de software de comunicación que generalmente depende de asíncrona de paso de mensajes, en contraposición a una petición-respuesta arquitectura. En los sistemas asíncronos, 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 realizar copias de seguridad de la cola de mensajes. Esto significa que el remitente y el receptor no necesitan conectarse a la red al mismo tiempo ( entrega asíncrona ) y se resuelven los problemas de conectividad intermitente. También significa que si la aplicación del receptor 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 posterior procesamiento 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 propia capa de mensajería proporcione la lógica de enrutamiento, mientras que otras dependen de las aplicaciones cliente para proporcionar información de enrutamiento o permitir una combinación de ambos paradigmas. Algunas implementaciones hacen uso de 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. 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 simple operación de arrastrar y soltar de GUI.
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 ( intermediario de mensajes ). Al igual que con cualquier sistema, agregar otro componente puede provocar reducciones en el rendimiento y la confiabilidad, 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 intrínsecamente sincrónica aspecto, con el remitente querer específicamente para esperar una respuesta a un mensaje antes de continuar (ver tiempo real y en tiempo casi real para los casos extremos). Debido a que la comunicación basada en mensajes funciona inherentemente de manera asincrónica, es posible que no encaje bien en tales situaciones. Dicho esto, la mayoría de los sistemas MOM tienen facilidades para agrupar una solicitud y una respuesta como una sola transacción pseudo-síncrona.
Con un sistema de mensajería síncrona, la función que llama no regresa hasta que la función llamada ha terminado su tarea. En un sistema asincrónico débilmente acoplado, el cliente que llama puede continuar cargando trabajo sobre el destinatario hasta que los recursos necesarios para manejar este trabajo se agoten y el componente llamado falle. Por supuesto, estas condiciones se pueden minimizar o evitar supervisando el rendimiento y ajustando el flujo de mensajes, pero este es un trabajo que no es necesario con un sistema de mensajería síncrona. 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 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 el middleware orientado a mensajes es la especificación XATMI del grupo X / Open (procesamiento de transacciones distribuidas: la especificación XATMI) que estandariza la API para las comunicaciones entre procesos. Las implementaciones conocidas de esta API son el middleware Enduro / X de ATR Baltic y el Tuxedo de Oracle.
El Protocolo de cola de mensajes avanzado (AMQP) es un estándar OASIS e ISO aprobado que define el protocolo y los formatos utilizados entre los componentes de la aplicación participantes, por lo que las implementaciones son interoperables. AMQP se puede usar con esquemas de enrutamiento flexibles, incluidos paradigmas de mensajería comunes como punto a punto, distribución, publicación / suscripción y solicitud-respuesta (tenga en cuenta que estos se omiten intencionalmente de la versión 1.0 del protocolo estándar en sí, pero dependen de la implementación particular y / o del protocolo de red subyacente para el enrutamiento). También es compatible con la gestión de transacciones, la puesta en cola, la distribución, la seguridad, la gestión, la agrupación en clústeres, la federación y la compatibilidad con varias plataformas heterogéneas. 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.
La Arquitectura de alto nivel (HLA IEEE 1516) es un estándar IEEE y 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 existen servicios de intercambio de datos coordinado y avance de tiempo, basados en tiempo de simulación lógica, así como puntos de sincronización. Los servicios adicionales brindan transferencia de propiedad, optimizaciones de distribución de datos y monitoreo y administración de los Federados (sistemas) participantes.
El transporte de telemetría MQ (MQTT) es una norma ISO (ISO / IEC PRF 20922) respaldada por la organización OASIS. Proporciona un protocolo de transporte de mensajería confiable de publicación / suscripción 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 un bien escaso.
El Grupo de Gestión de Objetos 's Data Distribution Service (DDS) proporciona orientado a mensajes de publicación / suscripción (P / S) estándar middleware que tiene por objeto permitir escalable, en tiempo real, fiable, de alto rendimiento y el intercambio de datos electrónicos entre los editores y suscriptores. 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 XML (Extensible Markup Language). Diseñado para ser extensible, el protocolo también se ha utilizado para sistemas de publicación y 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 desarrollo y aplicación de sistemas abiertos, mediante 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 usando cualquier licencia de software; aunque muchas implementaciones de servidores, clientes y bibliotecas se distribuyen como software gratuito y de código abierto, también existen numerosas implementaciones de software patentado y gratuito. 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 IETF de mensajería instantánea y presencia. El grupo de trabajo XMPP elaboró cuatro especificaciones (RFC 3920, RFC 3921, RFC 3922, RFC 3923), que fueron aprobadas como estándares propuestos en 2004. En 2011, RFC 3920 y RFC 3921 fueron reemplazadas por RFC 6120 y RFC 6121 respectivamente, con RFC 6122 especificando el formato de dirección XMPP. Además de estos protocolos básicos estandarizados en el IETF, XMPP Standards Foundation (anteriormente Jabber Software Foundation) participa activamente en el desarrollo de extensiones XMPP abiertas. El software basado en XMPP se implementa ampliamente en Internet, de acuerdo con la Fundación de Estándares XMPP, y constituye la base del Marco de Capacidades Unificadas del Departamento de Defensa (DoD).
El entorno de programación Java EE proporciona una API estándar llamada JMS (Java Message Service), 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 es el del proyecto OpenMAMA, que se encuentra en evolución activa, y que tiene como objetivo proporcionar una API común, en particular para los clientes C. Sin embargo, en este momento (agosto de 2012) es principalmente apropiado para distribuir datos orientados al mercado (por ejemplo, cotizaciones de acciones) a través de middleware pub-sub.
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 disco. Los mensajes permanecen en la cola hasta que un consumidor de servicios los procesa. A través de la cola de mensajes, la aplicación se puede implementar de forma independiente: no es necesario que conozcan la posición del otro ni que continúen implementando procedimientos para eliminar la necesidad de esperar para recibir este mensaje.
