Cola de mensajes

En informática , las colas de mensajes y los buzones de correo son componentes de ingeniería de software que se utilizan habitualmente para la comunicación entre procesos (IPC) o entre hilos dentro del mismo proceso. Utilizan una cola para la mensajería : el traspaso de control o de contenido. Los sistemas de comunicación de grupo ofrecen funcionalidades similares. 

El paradigma de cola de mensajes es similar al patrón publicador/suscriptor y suele formar parte de un sistema de middleware orientado a mensajes más amplio . La mayoría de los sistemas de mensajería admiten tanto el modelo publicador/suscriptor como el de cola de mensajes en su API , por ejemplo, Java Message Service (JMS).

El patrón de consumidores competitivos permite que múltiples consumidores simultáneos procesen mensajes en la misma cola de mensajes. ^{[ 1 ]}

Las colas de mensajes implementan un patrón de comunicación asíncrona entre dos o más procesos/hilos, de modo que el emisor y el receptor no necesitan interactuar con la cola de mensajes simultáneamente. Los mensajes colocados en la cola se almacenan hasta que el destinatario los recupera. Las colas de mensajes tienen límites implícitos o explícitos en el tamaño de los datos que se pueden transmitir en un solo mensaje y en la cantidad de mensajes que pueden permanecer pendientes en la cola. ^{[ 2 ]}

En una implementación típica de colas de mensajes, un administrador del sistema instala y configura el software de colas de mensajes (un gestor de colas o intermediario) y define una cola de mensajes con nombre. O bien, se registra en un servicio de colas de mensajes .

A continuación, la aplicación registra una rutina de software que "escucha" los mensajes colocados en la cola.

Las aplicaciones posteriores pueden conectarse a la cola y transferir un mensaje a ella.

El software gestor de colas almacena los mensajes hasta que una aplicación receptora se conecta y, a continuación, llama a la rutina de software registrada. La aplicación receptora procesa entonces el mensaje de la manera adecuada.

A menudo existen numerosas opciones en cuanto a la semántica exacta del paso de mensajes, entre las que se incluyen:

• Durabilidad: los mensajes pueden mantenerse en la memoria, escribirse en el disco o incluso confirmarse en un sistema de gestión de bases de datos (DBMS) si la necesidad de fiabilidad exige una solución que requiera más recursos.
• Políticas de seguridad: ¿qué aplicaciones deberían tener acceso a estos mensajes?
• Políticas de purga de mensajes: las colas o los mensajes pueden tener un " tiempo de vida ".
• Filtrado de mensajes: algunos sistemas admiten el filtrado de datos para que un suscriptor solo vea los mensajes que coincidan con ciertos criterios de interés predefinidos.
• Políticas de entrega: ¿debemos garantizar que un mensaje se entregue al menos una vez, o no más de una vez?
• Políticas de enrutamiento: en un sistema con muchos servidores de cola, ¿qué servidores deben recibir un mensaje o los mensajes de una cola?
• Políticas de procesamiento por lotes: ¿deben entregarse los mensajes inmediatamente? ¿O debería el sistema esperar un poco e intentar entregar varios mensajes a la vez?
• Criterios de encolamiento: ¿cuándo se considera que un mensaje está "en cola"? ¿Cuando una cola lo tiene? ¿O cuando se ha reenviado al menos a una cola remota? ¿O a todas las colas?
• Notificación de recepción: un editor puede necesitar saber cuándo algunos o todos los suscriptores han recibido un mensaje.

Todas estas son consideraciones que pueden tener efectos sustanciales en la semántica de las transacciones, la fiabilidad del sistema y la eficiencia del sistema.

Históricamente, las colas de mensajes han utilizado protocolos propietarios y cerrados, lo que restringe la capacidad de diferentes sistemas operativos o lenguajes de programación para interactuar en un conjunto heterogéneo de entornos.

Un primer intento por popularizar las colas de mensajes fue la especificación JMS de Sun Microsystems , que proporcionaba una abstracción exclusiva para Java de una API de cliente . Esto permitía a los desarrolladores de Java alternar entre proveedores de colas de mensajes de forma similar a como lo hacen los desarrolladores que utilizan bases de datos SQL . En la práctica, dada la diversidad de técnicas y escenarios de colas de mensajes, esto no siempre resultaba tan práctico como podría haber sido.

Han surgido tres estándares que se utilizan en las implementaciones de colas de mensajes de código abierto:

1. Protocolo avanzado de cola de mensajes (AMQP): protocolo de cola de mensajes con numerosas funciones, aprobado como ISO/IEC 19464 desde abril de 2014.
2. Protocolo de mensajería orientado a texto en tiempo real (STOMP): protocolo de mensajería simple y orientado a texto.
3. MQTT (anteriormente MQ Telemetry Transport): protocolo de cola de mensajes ligero especialmente diseñado para dispositivos integrados.

Estos protocolos se encuentran en diferentes etapas de estandarización y adopción. Los dos primeros operan al mismo nivel que HTTP , mientras que MQTT lo hace al nivel de TCP/IP .

Algunas implementaciones propietarias también utilizan HTTP para proporcionar colas de mensajes, como en el caso de SQS de Amazon . Esto se debe a que siempre es posible superponer un comportamiento asíncrono (necesario para las colas de mensajes) sobre un protocolo síncrono mediante la semántica de solicitud-respuesta. Sin embargo, en este caso, dichas implementaciones están limitadas por el protocolo subyacente y es posible que no puedan ofrecer la fidelidad o el conjunto completo de opciones necesarias para el paso de mensajes.

Muchos de los protocolos de comunicación más conocidos funcionan de forma síncrona . El protocolo HTTP  , utilizado en la World Wide Web y en los servicios web  , ofrece un ejemplo claro: un usuario envía una solicitud de una página web y espera una respuesta.

Sin embargo, existen situaciones en las que el comportamiento síncrono no es apropiado. Por ejemplo, AJAX ( Asynchronous JavaScript and XML ) se puede usar para enviar mensajes de texto, JSON o XML de forma asíncrona y así actualizar parte de una página web con información más relevante. Google utiliza este enfoque para su función Google Suggest, una herramienta de búsqueda que envía las consultas parcialmente escritas por el usuario a los servidores de Google y devuelve una lista de posibles consultas completas que podrían interesarle mientras escribe. Esta lista se actualiza de forma asíncrona a medida que el usuario escribe.

Existen otros ejemplos asíncronos en los sistemas de notificación de eventos y en los sistemas de publicación/suscripción .

• Una aplicación puede necesitar notificar a otra que ha ocurrido un evento, pero no necesita esperar una respuesta.
• En los sistemas de publicación/suscripción, una aplicación "publica" información para que la lean varios clientes.

En ambos ejemplos anteriores, no tendría sentido que el remitente de la información tuviera que esperar si, por ejemplo, uno de los destinatarios hubiera sufrido una avería.

Las aplicaciones no tienen por qué ser exclusivamente síncronas o asíncronas. Una aplicación interactiva puede necesitar responder a ciertas partes de una solicitud de inmediato (como informar a un cliente que se ha aceptado una solicitud de venta y gestionar la promesa de utilizar el inventario), pero puede poner en cola otras partes (como completar el cálculo de la facturación, enviar datos al sistema de contabilidad central y llamar a otros servicios) para que se realicen más adelante.

En todas estas situaciones, contar con un subsistema que gestione la puesta en cola de mensajes (o, alternativamente, un sistema de mensajería de difusión) puede ayudar a mejorar el comportamiento del sistema en general.

En UNIX existen dos implementaciones comunes de colas de mensajes . Una forma parte de la API SYS V y la otra forma parte de POSIX .

Las interfaces gráficas de usuario (GUI) emplean una cola de mensajes, también llamada cola de eventos o cola de entrada , para pasar acciones de entrada gráfica , como clics del ratón , eventos de teclado u otras entradas del usuario, al programa de aplicación . ^{[ 9 ]} El sistema de ventanas coloca mensajes que indican eventos del usuario u otros eventos, como pulsos de temporizador o mensajes enviados por otros subprocesos, en la cola de mensajes. La aplicación GUI elimina estos eventos uno a uno llamando a una rutina llamada getNextEvent()o similar en un bucle de eventos , y luego llamando a la rutina de aplicación apropiada para procesar ese evento. ^{[ 10 ]}