Cola de mensajes

Este artículo necesita citas adicionales para su verificación . Por favor, ayude a mejorar este artículo añadiendo citas de fuentes fiables . El material sin fuentes puede ser cuestionado y eliminado. Buscar fuentes:  «Cola de mensajes» – noticias  · periódicos  · libros  · académico  · JSTOR ( mayo de 2009 ) ( Aprenda cómo y cuándo eliminar este mensaje )

En informática , las colas de mensajes y los buzones de correo son componentes de ingeniería de software que se utilizan normalmente para la comunicación entre procesos (IPC) o para la comunicación entre subprocesos dentro del mismo proceso. Utilizan una cola para la mensajería  (el paso del control o del contenido). Los sistemas de comunicación grupal proporcionan tipos de funcionalidad similares.

El paradigma de cola de mensajes es un hermano del patrón publicador/suscriptor y, por lo general, forma parte de un sistema de middleware orientado a mensajes más grande . 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 en competencia permite que varios consumidores simultáneos procesen mensajes en la misma cola de mensajes. ^[1]

Las colas de mensajes implementan un patrón de comunicación asincrónica entre dos o más procesos/hilos, por lo que la parte emisora ​​y la receptora no necesitan interactuar con la cola de mensajes al mismo tiempo. 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 sobre el tamaño de los datos que se pueden transmitir en un solo mensaje y la cantidad de mensajes que pueden permanecer pendientes en la cola. ^[2]

Muchas implementaciones de colas de mensajes funcionan internamente dentro de un sistema operativo o dentro de una aplicación . Dichas colas existen únicamente para los fines de ese sistema . ^{[3] [4] [5]}

Otras implementaciones permiten el paso de mensajes entre diferentes sistemas informáticos, conectando potencialmente múltiples aplicaciones y múltiples sistemas operativos. ^[6] Estos sistemas de colas de mensajes suelen proporcionar una funcionalidad de resiliencia para garantizar que los mensajes no se "pierdan" en caso de una falla del sistema. Entre los ejemplos de implementaciones comerciales de este tipo de software de colas de mensajes (también conocido como middleware orientado a mensajes ) se incluyen IBM MQ (anteriormente MQ Series) y Oracle Advanced Queuing (AQ). Existe un estándar Java llamado Java Message Service , que tiene varias implementaciones de software propietario y gratuito .

Los sistemas operativos en tiempo real (RTOS) como VxWorks y QNX fomentan el uso de colas de mensajes como mecanismo principal de comunicación entre procesos o entre subprocesos. Esto puede dar como resultado la integración entre el paso de mensajes y la programación de la CPU. Los primeros ejemplos de RTOS comerciales que fomentaban una base de colas de mensajes para la comunicación entre subprocesos también incluyen VRTX y pSOS +, ambos de principios de la década de 1980. El lenguaje de programación Erlang utiliza procesos para proporcionar concurrencia; estos procesos se comunican de forma asincrónica mediante colas de mensajes.

El software de cola de mensajes puede ser propietario, de código abierto o una combinación de ambos. Luego se ejecuta en servidores privados locales o en servidores en la nube externos ( servicio de cola de mensajes ).

• Las opciones propietarias son las que tienen la historia más larga e incluyen productos que datan de los inicios de las colas de mensajes, como IBM MQ , y aquellos vinculados a sistemas operativos específicos, como Microsoft Message Queuing (MSMQ) . Los proveedores de servicios en la nube también ofrecen sus soluciones propietarias, como Amazon Simple Queue Service (SQS), StormMQ, Solace e IBM MQ .
• Las opciones de código abierto de sistemas de middleware de mensajería incluyen Apache ActiveMQ , Apache Kafka , Apache Qpid , Apache RocketMQ , Enduro/X , JBoss Messaging , JORAM, RabbitMQ , Sun Open Message Queue y Tarantool .

Ejemplos de proveedores de middleware de mensajería basados ​​en hardware son Solace , Apigee e IBM MQ .

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

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

La segunda aplicación y las subsiguientes pueden conectarse a la cola y transferirle un mensaje.

El software de gestión de colas almacena los mensajes hasta que una aplicación receptora se conecta y luego 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 ellas:

• Durabilidad: los mensajes pueden conservarse en la memoria, escribirse en el disco o incluso almacenarse en un DBMS si la necesidad de confiabilidad indica una solución que consuma 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 pueda ver mensajes que coincidan con algunos criterios de interés predeterminados.
• Políticas de entrega: ¿Necesitamos 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 deberían recibir un mensaje o los mensajes de una cola?
• Políticas de procesamiento por lotes: ¿los mensajes deben enviarse inmediatamente o el sistema debe esperar un poco e intentar enviar muchos mensajes a la vez?
• Criterios de cola: ¿cuándo se debe considerar que un mensaje está "en cola"? ¿Cuándo lo tiene una cola? ¿O cuándo se ha reenviado a al menos 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 confiabilidad del sistema y la eficiencia del sistema.

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

Un primer intento de hacer que las colas de mensajes fueran más comunes fue la especificación JMS de Sun Microsystems , que proporcionaba una abstracción exclusiva de Java de una API de cliente . Esto permitía a los desarrolladores de Java cambiar entre proveedores de colas de mensajes de una manera similar a la de 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 fue tan práctico como podría ser.

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

1. Protocolo de cola de mensajes avanzado (AMQP): protocolo de cola de mensajes con numerosas funciones, aprobado como ISO/IEC 19464 desde abril de 2014
2. Protocolo de mensajería orientada 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 liviano especialmente 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 , MQTT al nivel de TCP/IP .

Algunas implementaciones propietarias también utilizan HTTP para proporcionar colas de mensajes mediante algunas implementaciones, como SQS de Amazon . Esto se debe a que siempre es posible superponer un comportamiento asincrónico (que es lo que se requiere para las colas de mensajes) sobre un protocolo sincrónico utilizando semántica de solicitud-respuesta. Sin embargo, dichas implementaciones están limitadas por el protocolo subyacente en este caso y es posible que no puedan ofrecer la fidelidad total o el conjunto de opciones requeridas en el paso de mensajes anterior.

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

Sin embargo, existen situaciones en las que el comportamiento sincrónico no es adecuado. Por ejemplo, se puede utilizar AJAX (Asynchronous JavaScript and XML ) para enviar de forma asincrónica mensajes de texto, JSON o XML para actualizar parte de una página web con información más relevante. Google utiliza este enfoque para Google Suggest, una función 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 al usuario en el proceso de escritura. Esta lista se actualiza de forma asincrónica a medida que el usuario escribe.

Existen otros ejemplos asincrónicos en los sistemas de notificación de eventos y sistemas de publicación/suscripción .

• Es posible que una aplicación necesite notificar a otra que se ha producido un evento, pero no necesita esperar una respuesta.
• En los sistemas de publicación/suscripción, una aplicación "publica" información para que cualquier número de clientes la lea.

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

Las aplicaciones no tienen por qué ser exclusivamente sincrónicas o asincrónicas. Una aplicación interactiva puede necesitar responder a ciertas partes de una solicitud inmediatamente (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 solicitar todo tipo de otros servicios) para que se realicen más tarde.

En todos estos tipos de situaciones, tener un subsistema que realice colas de mensajes (o alternativamente, un sistema de mensajería de difusión) puede ayudar a mejorar el comportamiento del sistema general.

Existen dos implementaciones comunes de colas de mensajes en UNIX . Una es parte de la API SYS V y la otra es parte de POSIX .

UNIX SYS V implementa el paso de mensajes manteniendo una matriz de listas enlazadas como colas de mensajes. Cada cola de mensajes se identifica por su índice en la matriz y tiene un descriptor único. Un índice determinado puede tener múltiples descriptores posibles. UNIX proporciona funciones estándar para acceder a la característica de paso de mensajes. ^[7]

msgget()

Esta llamada al sistema toma una clave como argumento y devuelve un descriptor de la cola con la clave correspondiente, si existe. Si no existe y el IPC_CREATindicador está activado, crea una nueva cola de mensajes con la clave dada y devuelve su descriptor.

msgrcv()

Se utiliza para recibir un mensaje de un descriptor de cola determinado. El proceso que realiza la llamada debe tener permisos de lectura para la cola. Es de dos tipos. ^[8]

• El bloqueo de la recepción pone al niño en suspensión si no puede encontrar un tipo de mensaje solicitado. Se queda en suspensión hasta que se publica otro mensaje en la cola y luego se activa para verificar nuevamente.
• La recepción sin bloqueo regresa inmediatamente al llamador, mencionando que falló.

msgctl()

Se utiliza para cambiar los parámetros de la cola de mensajes, como el propietario. Lo más importante es que se utiliza para eliminar la cola de mensajes al pasar el IPC_RMIDindicador. Una cola de mensajes solo puede ser eliminada por su creador, propietario o superusuario.

La API de cola de mensajes POSIX.1-2001 es la última de las dos API de cola de mensajes de UNIX. Es distinta de la API SYS V, pero ofrece una función similar. La página del manual de Unix mq_overview(7)ofrece una descripción general de las colas de mensajes 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áficas , como clics del mouse , eventos del 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 tics del temporizador o mensajes enviados por otros subprocesos, en la cola de mensajes. La aplicación GUI elimina estos eventos uno a la vez llamando a una rutina llamada getNextEvent()o similar en un bucle de eventos y luego llamando a la rutina de aplicación adecuada para procesar ese evento. ^[10]