En informática , las colas de mensajes y los buzones de correo son componentes de ingeniería de software que normalmente se utilizan para la comunicación entre procesos (IPC) o para la comunicación entre subprocesos dentro del mismo proceso. Utilizan una cola para enviar mensajes : pasar el control o el contenido. Los sistemas de comunicación grupal proporcionan tipos similares de funcionalidad.
El paradigma de la cola de mensajes es hermano del patrón editor/suscriptor y normalmente es una parte de un sistema middleware más amplio orientado a mensajes . La mayoría de los sistemas de mensajería admiten tanto el modelo de editor/suscriptor como el de cola de mensajes en su API , por ejemplo, Java Message Service (JMS).
El patrón de consumidores competidores 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 mediante el cual 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 pueden transmitirse 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 . Estas colas existen únicamente a los efectos 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 cola de mensajes normalmente proporcionan una funcionalidad de resiliencia para garantizar que los mensajes no se "pierdan" en caso de una falla del sistema. Ejemplos de implementaciones comerciales de este tipo de software de cola de mensajes (también conocido como middleware orientado a mensajes ) incluyen IBM MQ (anteriormente MQ Series) y Oracle Advanced Queuing (AQ). Existe un estándar de Java llamado Java Message Service , que tiene varias implementaciones de software libre y propietario .
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 cola de mensajes para la comunicación entre subprocesos también incluyen VRTX y pSOS +, ambos datan 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 localmente en servidores privados o en servidores en la nube externos ( servicio de cola de mensajes ).
Ejemplos de proveedores de middleware de mensajería basada en hardware son Solace , Apigee e IBM MQ .
En una implementación típica de colas de mensajes, un administrador del sistema instala y configura el software de colas de mensajes (un administrador de colas o un intermediario) y define una cola de mensajes con nombre. O se registran en un servicio de cola 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 posteriores pueden conectarse a la cola y transferirle un mensaje.
El software del administrador de colas almacena los mensajes hasta que una aplicación receptora se conecta y luego llama a la rutina del software registrado. Luego, la aplicación receptora procesa el mensaje de manera adecuada.
A menudo existen numerosas opciones en cuanto a la semántica exacta del paso de mensajes, que incluyen:
Todas estas son consideraciones que pueden tener efectos sustanciales en la semántica de las transacciones, la confiabilidad y la eficiencia del sistema.
Históricamente, las colas de mensajes han utilizado protocolos cerrados propietarios, 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 de hacer que las colas de mensajes fueran más ubicuas fue la especificación JMS de Sun Microsystems , que proporcionaba una abstracción exclusiva de Java de una API de cliente . Esto permitió 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 , 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 el comportamiento asíncrono (que es lo que se requiere para la cola de mensajes) sobre un protocolo síncrono utilizando 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 total o el conjunto de opciones requeridas en el paso de mensajes anterior.
Muchos de los protocolos de comunicaciones 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 obvio en el que un usuario envía una solicitud de una página web y luego espera una respuesta.
Sin embargo, existen escenarios en los que el comportamiento sincrónico no es apropiado. Por ejemplo, AJAX ( JavaScript y XML asincrónicos ) se puede utilizar 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 su 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 el usuario podría estar interesado 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 sistemas de notificación de eventos y sistemas de publicación/suscripción .
En los dos ejemplos anteriores, no tendría sentido que el remitente de la información tuviera que esperar si, por ejemplo, uno de los destinatarios hubiera fallado.
Las aplicaciones no necesitan ser exclusivamente síncronas o asíncronas. Es posible que una aplicación interactiva necesite responder a ciertas partes de una solicitud de inmediato (como decirle a un cliente que se ha aceptado una solicitud de venta y manejar 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) que se realizará algún tiempo después.
En todo este tipo de situaciones, tener un subsistema que realice colas de mensajes (o, alternativamente, un sistema de transmisión de mensajes) puede ayudar a mejorar el comportamiento del sistema en general.
Hay dos implementaciones comunes de colas de mensajes en UNIX . Uno es parte de la API de SYS V, el otro es parte de POSIX .
UNIX SYS V implementa el paso de mensajes manteniendo una serie 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 ofrece funciones estándar para acceder a la función de paso de mensajes. [7]
msgget()IPC_CREATbandera está configurada, crea una nueva cola de mensajes con la clave dada y devuelve su descriptor.msgrcv()msgctl()IPC_RMIDbandera. Sólo su creador, propietario o superusuario puede eliminar una cola de mensajes.La API de cola de mensajes POSIX.1-2001 es la última de las dos API de cola de mensajes UNIX. Es distinta de la API de SYS V, pero proporciona una función similar. La página de manual de Unix mq_overview(7)proporciona 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áfica , como clics del mouse , 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, como tics del temporizador o mensajes enviados por otros hilos, 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]