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/subprocesos, 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 ).
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.
Las segundas aplicaciones 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:
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 los 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:
Estos protocolos se encuentran en diferentes etapas de estandarización y adopción. Los dos primeros operan al mismo nivel que HTTP y 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 .
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()IPC_CREATindicador está activado, crea una nueva cola de mensajes con la clave dada y devuelve su descriptor.msgrcv()msgctl()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]