Middleware orientado a mensajes

El middleware orientado a mensajes ( MOM ) es una infraestructura de software o hardware que permite enviar y recibir mensajes entre sistemas distribuidos. El middleware orientado a mensajes se diferencia del middleware orientado a flujos, donde los datos se comunican como una secuencia de bytes sin límites de mensaje explícitos. Cabe destacar que los protocolos de flujo casi siempre se construyen sobre protocolos que utilizan mensajes discretos, como tramas ( Ethernet ), datagramas ( UDP ), paquetes ( IP ), celdas ( ATM ), etc.

MOM permite distribuir módulos de aplicación 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 distribuida que aísla al desarrollador de la aplicación de los detalles de los distintos 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, servlets y otros componentes) desarrollados de forma independiente y que pueden ejecutarse 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 hacerse tolerante a fallos y seguro. ^{[ 2 ]}

MOM proporciona elementos de software que residen en todos los componentes comunicantes de una arquitectura cliente/servidor y, por lo general, admiten llamadas asíncronas entre las aplicaciones cliente y servidor. MOM reduce la complejidad que implica para los desarrolladores de aplicaciones lidiar con la naturaleza maestro-esclavo del mecanismo cliente/servidor.

• Middleware basado en llamadas a procedimientos remotos o RPC
• Agente de solicitud de objetos o middleware basado en ORB ^{[ 3 ]}
• Middleware orientado a mensajes o middleware basado en MOM

Todos estos modelos permiten que un componente de software afecte el comportamiento de otro componente a través de una red. Se diferencian en que el middleware basado en RPC y ORB crea sistemas de componentes fuertemente acoplados, mientras que los sistemas basados ​​en MOM permiten un acoplamiento más 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 devuelva un resultado antes de poder realizar cualquier otra acción. En estos modelos de mensajería mayoritariamente síncronos , el middleware funciona parcialmente como un superenlazador, localizando el procedimiento llamado en una red y utilizando servicios de red para pasar parámetros de función o método al procedimiento y, posteriormente, devolver los resultados. ^{[ 2 ]} Cabe destacar que los intermediarios de solicitudes de objetos también admiten mensajería totalmente asíncrona mediante invocaciones unidireccionales. ^{[ 3 ]}

Entre las razones principales para utilizar un protocolo de comunicaciones basado en mensajes se incluye su capacidad para almacenar (guardar en búfer), enrutar o transformar mensajes mientras se transmiten desde los remitentes a los receptores.

Otra ventaja de la mensajería entre clientes mediada por el proveedor es que, al añadir una interfaz administrativa, se puede supervisar y optimizar el rendimiento. De este modo, las aplicaciones cliente quedan exentas de cualquier problema, salvo el de enviar, recibir y procesar mensajes. Corresponde al código que implementa el sistema de mensajería mediada por el proveedor y al administrador resolver cuestiones como la interoperabilidad, la fiabilidad, la seguridad, la escalabilidad y el rendimiento.

La principal desventaja de muchos sistemas de middleware orientados a mensajes es que requieren un componente adicional en su arquitectura : el agente de transferencia de mensajes (o intermediario de mensajes ). Como ocurre con cualquier sistema , añadir otro componente puede reducir el rendimiento y la fiabilidad, además de dificultar y encarecer el mantenimiento del sistema en su conjunto .

Además, muchas comunicaciones entre aplicaciones tienen un aspecto intrínsecamente síncrono , donde el remitente espera específicamente una respuesta a un mensaje antes de continuar (véanse los casos extremos de computación en tiempo real y casi real ). Dado que la comunicación basada en mensajes funciona inherentemente de forma asíncrona, puede que no sea adecuada para estas situaciones. Dicho esto, la mayoría de los sistemas MOM cuentan con mecanismos para agrupar una solicitud y una respuesta como una única transacción pseudosíncrona.

En un sistema de mensajería síncrono, la función que realiza la llamada no regresa hasta que la función llamada haya finalizado su tarea. En un sistema asíncrono de acoplamiento flexible , el cliente que realiza la llamada puede seguir sobrecargando de trabajo al receptor hasta que se agoten los recursos necesarios para gestionarlo y el componente llamado falle. Por supuesto, estas condiciones pueden minimizarse o evitarse monitorizando el rendimiento y ajustando el flujo de mensajes, pero esto no es necesario con un sistema de mensajería síncrono. Lo importante es comprender las ventajas y desventajas de cada tipo de sistema. Cada sistema es adecuado para diferentes tipos de tareas. En ocasiones, se requiere una combinación de ambos tipos de sistemas para obtener el comportamiento deseado.

Históricamente, la falta de estándares que regulen el uso de middleware orientado a mensajes ha generado 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 de larga trayectoria para el middleware orientado a mensajes es la especificación XATMI (Distributed Transaction Processing: The XATMI Specification) del grupo X/Open, que estandariza la API para las comunicaciones entre procesos . Algunas implementaciones conocidas de esta API son el middleware Enduro/X de ATR Baltic y Tuxedo de Oracle .

El Protocolo Avanzado de Cola de Mensajes (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 participantes, por lo que las implementaciones son interoperables. AMQP se puede utilizar con esquemas de enrutamiento flexibles, incluidos paradigmas de mensajería comunes como punto a punto , fan-out , publicación/suscripción y solicitud-respuesta (estos se omiten intencionalmente en la v1.0 del estándar del protocolo, pero dependen de la implementación particular y/o del protocolo de red subyacente para el enrutamiento). También admite la gestión de transacciones, colas, distribución, seguridad, administración, clustering, federación y 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 de la Organización de Estándares de Interoperabilidad de Simulación (SISO) para la interoperabilidad de simulaciones. Define un conjunto de servicios, proporcionados a través de una API en C++ o Java. Estos servicios ofrecen intercambio de información basado en publicación/suscripción, fundamentado en un modelo de objetos de federación modular. También incluye servicios para el intercambio coordinado de datos y el avance temporal, basados ​​en el tiempo lógico de simulación, así como puntos de sincronización. Otros servicios adicionales permiten la transferencia de propiedad, la optimización de la distribución de datos y la monitorización y gestión de los sistemas federados participantes.

El protocolo MQ Telemetry Transport (MQTT) es un estándar ISO (ISO/IEC PRF 20922) respaldado por la organización OASIS. Proporciona un protocolo de transporte de mensajería fiable, ligero y de publicación/suscripción, basado en TCP/IP, adecuado para la comunicación en entornos M2M/IoT donde se requiere un código reducido o el ancho de banda de la red es limitado.

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 busca 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.

Las colas de mensajes permiten el intercambio de información entre aplicaciones distribuidas. Una cola de mensajes puede residir en memoria o en almacenamiento en disco. Los mensajes permanecen en la cola hasta que un consumidor del servicio los procesa. Gracias a la cola de mensajes, las aplicaciones pueden implementarse de forma independiente; no necesitan conocer la posición de las demás ni implementar procedimientos para evitar la espera de recibir mensajes. ^{[ 9 ]}

• El Protocolo Avanzado de Cola de Mensajes (AMQP) proporciona un protocolo de capa de aplicación de estándar abierto para middleware orientado a mensajes. ^{[ 10 ]}
• El Servicio de Distribución de Datos (DDS) del Object Management Group ha incorporado numerosos estándares nuevos a la especificación básica de DDS. Consulte el Catálogo de Especificaciones del Servicio de Distribución de Datos (DDS) de OMG para obtener más información.
• La arquitectura CORBA ( Common Object Request Broker Architecture ) del Object Management Group ha incorporado recientemente numerosos estándares nuevos, entre ellos una nueva asignación de lenguaje a C# y una actualización de la especificación de asignación de IDL a C++ para dar soporte a las últimas actualizaciones de los estándares del lenguaje C++ . Consulte el Catálogo de especificaciones CORBA de OMG para obtener más información.
• El Protocolo de Mensajería y Presencia Extensible (XMPP) es un protocolo de comunicaciones para middleware orientado a mensajes basado en el Lenguaje de Marcado Extensible (XML). ^{[ 11 ]}
• El protocolo de mensajería orientada a texto en streaming (STOMP), anteriormente llamado TTMP, es un protocolo simple basado en texto que proporciona un formato de comunicación interoperable que permite a los clientes STOMP comunicarse con cualquier agente de mensajes que admita el protocolo. ^{[ 12 ]}
• Una tendencia adicional consiste en la implementación de funciones de middleware orientadas a mensajes en hardware, generalmente en una matriz de puertas programables en campo (FPGA), un circuito integrado de aplicación específica (ASIC) u otro chip de silicio especializado. ^{[ 13 ] [ 14 ]}

• Patrones de integración empresarial (libro)
• Sistema de mensajería empresarial
• Autobús de servicio empresarial
• Programación basada en flujo
• Arquitectura basada en eventos

• Fundamentos para desarrolladores de IBM MQ .
• ORBexpress: Una visión general .