Middleware orientado a mensajes

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 distribuir módulos de aplicaciones 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 distintos sistemas operativos e interfaces de red. MOM suele proporcionar las API que se extienden a través de diversas plataformas y redes.

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 la 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 seguro y tolerante a fallas.

MOM proporciona elementos de software que residen en todos los componentes de comunicación de una arquitectura cliente/servidor y normalmente 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.

Categorías de middleware

• Llamada de procedimiento remoto o middleware basado en RPC
• Interventor de solicitud de objetos o intermediario basado en ORB
• Medios orientados a mensajes o middleware basado en MOM

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 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 utilizando servicios de red para pasar parámetros de función o método al procedimiento y luego devolver resultados.

Ventajas

Las razones centrales para utilizar un protocolo de comunicaciones basado en mensajes incluyen su capacidad para almacenar (búfer), enrutar o transformar mensajes mientras los transmite de los remitentes a los 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 eficazmente 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 la interoperabilidad, la confiabilidad, la seguridad, la escalabilidad y el rendimiento.

Asincronicidad

Utilizando un sistema MOM, un cliente realiza una llamada 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, confiando en que el proveedor retendrá el mensaje hasta que un cliente receptor lo recupere. 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 de mensajes asíncrono, en lugar de una arquitectura de solicitud-respuesta. 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 asíncronos 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 se reinicie el receptor.

Rutas

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 permitir una combinación de ambos paradigmas. Algunas implementaciones utilizan paradigmas de distribución de difusión o multidifusión.

Transformación

En un sistema de middleware basado en mensajes, el mensaje recibido en el destino no tiene por qué 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 operación simple de arrastrar y soltar de GUI.

Desventajas

La principal desventaja de muchos sistemas middleware orientados a mensajes es que requieren un componente adicional en la arquitectura, el agente de transferencia de mensajes (agente de mensajes). Como ocurre 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 aspecto intrínsecamente sincrónico, en el que el remitente desea específicamente esperar una respuesta a un mensaje antes de continuar (consulte informática en tiempo real y tiempo casi real para casos extremos). Debido a que la comunicación basada en mensajes funciona inherentemente de forma asincrónica, es posible que no encaje bien en 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.

Con un sistema de mensajería sincrónico, la función que realiza la llamada no regresa hasta que la función llamada haya finalizado su tarea. En un sistema asincrónico débilmente acoplado, el cliente que llama puede continuar cargando trabajo en 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 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ónico. 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.

Estándares

Históricamente, la falta de estándares que regulen el uso de middleware orientado a mensajes 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 (Procesamiento de transacciones distribuidas: la especificación XATMI) del grupo X/Open, que estandariza la API para las comunicaciones entre procesos. Las implementaciones conocidas para 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 e ISO 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, distribución, publicación/suscripción y solicitud-respuesta (tenga en cuenta que estos se omiten intencionalmente en 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 admite gestión de transacciones, colas, distribución, seguridad, gestión, agrupación en clústeres, 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.

La arquitectura de alto nivel (HLA IEEE 1516) es un estándar IEEE y SISO para la interoperabilidad de 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 coordinado de datos y avance del tiempo, basados en simulación lógica del tiempo, así como puntos de sincronización. Los servicios adicionales brindan transferencia de propiedad, optimizaciones de la distribución de datos y monitoreo y administración de los Federados (sistemas) participantes.

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 ligero de transporte de mensajería confiable de publicación/suscripción además de 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) de 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 editores y suscriptores. El estándar proporciona interfaces para C++, C++11, C, Ada, Java y Ruby.

XMPP

El protocolo eXtensible de mensajería y presencia (XMPP) es un protocolo de comunicaciones para middleware orientado a mensajes basado en XML (lenguaje de marcado extensible). Diseñado para ser extensible, el protocolo también se ha utilizado para sistemas de publicación-suscripción, señalización para VoIP, vídeo, 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 los protocolos de otras organizaciones. implementaciones. Como XMPP es un protocolo abierto, las implementaciones se pueden desarrollar utilizando 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 gratuito 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 presencia y mensajería instantánea del IETF. El grupo de trabajo XMPP produjo 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 centrales estandarizados en el IETF, la XMPP Standards Foundation (anteriormente Jabber Software Foundation) participa activamente en el desarrollo de extensiones abiertas de XMPP. El software basado en XMPP se implementa ampliamente en Internet, según la XMPP Standards Foundation, y forma 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 se realiza con el proyecto OpenMAMA en evolución activa, cuyo objetivo es proporcionar una API común, particularmente para clientes C. Sin embargo, por el 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.

Cola de mensajes

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 se puede implementar de forma independiente: no necesitan conocer la posición de cada uno ni continuar implementando procedimientos para eliminar la necesidad de esperar para recibir este mensaje.

Tendencias

• Advanced Message Queuing Protocol (AMQP) proporciona un protocolo de capa de aplicación estándar abierto para el middleware orientado al mensaje.
• El Servicio de Distribución de Datos del Grupo de Gestión de Objetos (DDS) ha añadido muchos nuevos estándares a la especificación básica de DDS. Ver catálogo de OMG Data Distribution Service (DDS) Especificaciones para más detalles.
• XMPP es un protocolo de comunicaciones para el middleware orientado a mensajes basado en XML (Extensible Markup Language).
• Streaming Text Oriented Messaging Protocol (STOMP), anteriormente conocido como TTMP, es un simple protocolo basado en texto, proporciona un formato de alambre interoperable que permite a los clientes de STOMP hablar con cualquier Mensaje Broker que apoye el protocolo.
• Una tendencia adicional ve las funciones de middleware orientadas al mensaje que se implementan en hardware - generalmente FPGAs u otros chips de silicio especializados.