Protocolo avanzado de cola de mensajes

El Protocolo Avanzado de Cola de Mensajes ( AMQP ) es un protocolo de capa de aplicación de estándar abierto para middleware orientado a mensajes . Las características que definen a AMQP son la orientación a mensajes, la gestión de colas, el enrutamiento (incluidos el enrutamiento punto a punto y el de publicación y suscripción ), la fiabilidad y la seguridad. ^{[ 1 ]}

AMQP exige el comportamiento del proveedor y del cliente de mensajería hasta el punto de que las implementaciones de diferentes proveedores sean interoperables , de la misma manera que SMTP , HTTP , FTP , etc., han creado sistemas interoperables. Las estandarizaciones anteriores de middleware se han producido a nivel de API (por ejemplo, JMS ) y se centraron en estandarizar la interacción del programador con diferentes implementaciones de middleware, en lugar de proporcionar interoperabilidad entre múltiples implementaciones. ^{[ 2 ]} A diferencia de JMS, que define una API y un conjunto de comportamientos que una implementación de mensajería debe proporcionar, AMQP es un protocolo a nivel de cable . Un protocolo a nivel de cable es una descripción del formato de los datos que se envían a través de la red como un flujo de bytes . En consecuencia, cualquier herramienta que pueda crear e interpretar mensajes que se ajusten a este formato de datos puede interoperar con cualquier otra herramienta compatible, independientemente del lenguaje de implementación.

AMQP es un protocolo binario de capa de aplicación, diseñado para soportar eficientemente una amplia variedad de aplicaciones de mensajería y patrones de comunicación. Proporciona comunicación orientada a mensajes con control de flujo, ^{[ 3 ]} con garantías de entrega de mensajes tales como como máximo una vez (donde cada mensaje se entrega una vez o nunca), al menos una vez (donde cada mensaje tiene la certeza de ser entregado, pero puede hacerlo varias veces) y exactamente una vez (donde el mensaje siempre llegará con certeza y lo hará solo una vez), ^{[ 4 ]} y autenticación y/o cifrado basado en SASL y/o TLS . ^{[ 5 ]} Presupone un protocolo de capa de transporte subyacente confiable como el Protocolo de Control de Transmisión (TCP). ^{[ 6 ]}

La especificación AMQP se define en varias capas: (i) un sistema de tipos, (ii) un protocolo simétrico y asíncrono para la transferencia de mensajes de un proceso a otro, (iii) un formato de mensaje estándar y extensible y (iv) un conjunto de "capacidades de mensajería" estandarizadas pero extensibles.

AMQP fue creado en 2003 por John O'Hara en JPMorgan Chase en Londres . ^{[ 1 ] [ 7 ]} AMQP fue concebido como un esfuerzo cooperativo abierto. El diseño inicial fue realizado por JPMorgan Chase desde mediados de 2004 hasta mediados de 2006 y contrató a iMatix Corporation para desarrollar un broker en C y la documentación del protocolo. En 2005, JPMorgan Chase se acercó a otras empresas para formar un grupo de trabajo que incluía a Cisco Systems , IONA Technologies , iMatix, Red Hat y Transaction Workflow Innovation Standards Team (TWIST). Ese mismo año, JPMorgan Chase se asoció con Red Hat para crear Apache Qpid , inicialmente en Java y poco después en C++. De forma independiente, RabbitMQ fue desarrollado en Erlang por Rabbit Technologies, seguido más tarde por las implementaciones de Microsoft y StormMQ.

El grupo de trabajo creció hasta incluir a 23 empresas, entre ellas Bank of America , Barclays , Cisco Systems, Credit Suisse , Deutsche Börse , Goldman Sachs , HCL Technologies Ltd , Progress Software , IIT Software , INETCO Systems Limited , Informatica (incluida 29 West), JPMorgan Chase, Microsoft Corporation , my-Channels, Novell , Red Hat , Software AG , Solace Systems , StormMQ, Tervela Inc. , TWIST Process Innovations ltd, VMware (que adquirió Rabbit Technologies) y WSO2 .

En 2008, Pieter Hintjens , director ejecutivo y diseñador jefe de software de iMatix, escribió un artículo titulado "¿Qué falla en AMQP (y cómo solucionarlo)?" ^{[ 8 ]} y lo distribuyó al grupo de trabajo para alertar sobre un fallo inminente, identificar los problemas detectados por iMatix y proponer soluciones para la especificación AMQP. Para entonces, iMatix ya había comenzado a trabajar en ZeroMQ . En 2010, Hintjens anunció que iMatix abandonaría el grupo de trabajo de AMQP y que no tenía previsto dar soporte a AMQP/1.0 en favor de ZeroMQ, significativamente más sencillo y rápido. ^{[ 9 ]}

En agosto de 2011, el grupo de trabajo AMQP anunció su reorganización como sección miembro de OASIS . ^{[ 10 ]}

AMQP 1.0 fue publicado por el grupo de trabajo de AMQP el 30 de octubre de 2011, en una conferencia en Nueva York. En el evento, Microsoft, Red Hat, VMware , Apache, INETCO e IIT Software demostraron software que ejecutaba el protocolo en una demostración de interoperabilidad. Al día siguiente, el 1 de noviembre de 2011, se anunció la formación de un Comité Técnico de OASIS ^{[ 11 ]} para impulsar esta versión 1.0 de AMQP a través del proceso internacional de estándares abiertos. El primer borrador de OASIS se publicó en febrero de 2012, ^{[ 12 ]} los cambios en comparación con el publicado por el Grupo de Trabajo se limitaron a ediciones para mejorar la claridad (sin cambios funcionales). El segundo borrador se publicó para revisión pública el 20 de junio (nuevamente sin cambios funcionales), ^{[ 13 ]} y AMQP fue aprobado como estándar de OASIS el 31 de octubre de 2012. ^{[ 14 ]}

OASIS AMQP fue aprobado para su publicación como norma internacional ISO e IEC en abril de 2014. ^{[ 15 ]} AMQP 1.0 fue sometido a votación por el Comité Técnico Conjunto de Tecnología de la Información (JTC1) de la Organización Internacional de Normalización (ISO) y la Comisión Electrotécnica Internacional (IEC). La propuesta aprobada de OASIS AMQP recibió la designación ISO/IEC 19464.

Las versiones anteriores de AMQP fueron la 0-8, publicada en junio de 2006, la 0-9, publicada en diciembre de 2006, la 0-10, publicada en febrero de 2008 ^{[ 16 ]} y la 0-9-1, publicada en noviembre de 2008. Estas versiones anteriores difieren significativamente de la especificación 1.0. ^{[ 17 ] [ 18 ]}

Si bien AMQP se originó en el sector de los servicios financieros, tiene aplicabilidad general a una amplia gama de problemas de middleware .

AMQP define un esquema de codificación autodescriptivo que permite la representación interoperable de una amplia gama de tipos de uso común. También permite que los datos tipados se anoten con significado adicional, ^{[ 19 ]} por ejemplo, un valor de cadena particular podría anotarse para que se entienda como una URL . Del mismo modo, un valor de mapa que contiene pares clave-valor para 'nombre', 'dirección', etc., podría anotarse como una representación de un tipo 'cliente'.

El sistema de tipos se utiliza para definir un formato de mensaje que permite que las entidades de procesamiento expresen y comprendan metadatos estándar y extendidos. También se utiliza para definir las primitivas de comunicación mediante las cuales se intercambian mensajes entre dichas entidades, es decir, los cuerpos de las tramas AMQP .

La unidad básica de datos en AMQP es una trama . Existen nueve cuerpos de trama AMQP definidos que se utilizan para iniciar, controlar y finalizar la transferencia de mensajes entre dos pares. Estos son:

• abrir (la conexión )
• comenzar (la sesión )
• adjuntar (el enlace )
• transferir
• fluir
• disposición
• separar (el enlace )
• finalizar (la sesión )
• cerrar (la conexión )

El protocolo de enlace es la base de AMQP.

Se envía un cuerpo de trama de enlace para iniciar un nuevo enlace; un enlace de desconexión para cerrar un enlace. Los enlaces se pueden establecer para recibir o enviar mensajes.

Los mensajes se envían a través de un enlace establecido utilizando la trama de transferencia . Los mensajes en un enlace fluyen en una sola dirección.

Las transferencias están sujetas a un esquema de control de flujo basado en créditos, gestionado mediante marcos de flujo . Esto permite que un proceso se proteja de ser sobrecargado por un volumen excesivo de mensajes o, simplemente, que un enlace suscriptor reciba mensajes cuando lo desee. ^{[ 20 ]}

Cada mensaje transferido debe ser finalmente resuelto . La resolución garantiza que el emisor y el receptor estén de acuerdo sobre el estado de la transferencia, lo que proporciona garantías de fiabilidad. Los cambios de estado y resolución para una transferencia (o conjunto de transferencias) se comunican entre los participantes mediante el marco de disposición . De esta forma se pueden aplicar diversas garantías de fiabilidad: como máximo una vez, al menos una vez y exactamente una vez. ^{[ 21 ]}

En una sesión se pueden agrupar múltiples enlaces, en ambas direcciones . Una sesión es una conversación bidireccional y secuencial entre dos pares que se inicia con una trama de inicio y finaliza con una trama de fin . Una conexión entre dos pares puede contener múltiples sesiones multiplexadas, cada una lógicamente independiente. Las conexiones se inician con una trama de apertura en la que se expresan las capacidades del par emisor y finalizan con una trama de cierre .

AMQP define el mensaje desnudo como la parte del mensaje que crea la aplicación remitente. Esta parte se considera inmutable mientras el mensaje se transfiere entre uno o más procesos.

Garantizar la inmutabilidad del mensaje enviado por la aplicación permite la firma y/o el cifrado de extremo a extremo , y asegura que las comprobaciones de integridad (como hashes o resúmenes ) sigan siendo válidas. Los intermediarios pueden añadir anotaciones al mensaje durante su transmisión, pero estas se mantienen separadas del mensaje original inmutable . Las anotaciones pueden añadirse antes o después del mensaje original.

El encabezado es un conjunto estándar de anotaciones relacionadas con la entrega que se pueden solicitar o indicar para un mensaje e incluye tiempo de vida, durabilidad y prioridad. ^{[ 22 ]}

El mensaje en sí está estructurado como una lista opcional de propiedades estándar (ID del mensaje, ID del usuario, hora de creación, responder a, asunto, ID de correlación, ID de grupo, etc.), una lista opcional de propiedades específicas de la aplicación (es decir, propiedades extendidas) y un cuerpo, al que AMQP se refiere como datos de la aplicación. ^{[ 23 ]}

Las propiedades y las anotaciones se especifican en el sistema de tipos AMQP. Los datos de la aplicación pueden ser de cualquier formato y estar codificados según la preferencia de la aplicación. Una opción es utilizar el sistema de tipos AMQP para enviar datos estructurados y autodescriptivos.

El protocolo de enlace transfiere mensajes entre dos nodos , pero presupone muy poco sobre qué son esos nodos o cómo están implementados.

Una categoría clave son aquellos nodos que sirven como punto de encuentro entre remitentes y receptores de mensajes (por ejemplo, colas o temas ). La especificación AMQP denomina a estos nodos nodos de distribución y codifica algunos comportamientos comunes. ^{[ 24 ]}

Esto incluye:

• algunos resultados estándar para las transferencias, a través de los cuales los receptores de mensajes pueden, por ejemplo, aceptar o rechazar los mensajes ^{[ 25 ].}
• un mecanismo para indicar o solicitar uno de los dos patrones de distribución básicos, consumidores competidores y no competidores, a través de los modos de distribución mover y copiar respectivamente ^{[ 26 ]}
• la capacidad de crear nodos bajo demanda, ^{[ 27 ] [ 28 ]} por ejemplo, para colas de respuesta temporales
• la capacidad de refinar el conjunto de mensajes de interés para un receptor a través de filtros ^{[ 29 ]}

Si bien AMQP puede utilizarse en sistemas peer-to-peer sencillos, la definición de este marco para las capacidades de mensajería permite, además, la interoperabilidad con intermediarios de mensajería (corredores, puentes, etc.) en redes de mensajería más amplias y sofisticadas. El marco especificado abarca comportamientos básicos, pero permite el desarrollo de extensiones que pueden codificarse y estandarizarse posteriormente.

• Apache Qpid , un proyecto de código abierto de la Fundación Apache.
• Apache ActiveMQ , un proyecto de código abierto de la Fundación Apache.
• Azure Event Hubs ^{[ 30 ] [ 31 ]}
• Azure Service Bus ^{[ 30 ] [ 32 ]}
• IBM MQ ^{[ 33 ] [ 34 ]}
• Solace PubSub+, un intermediario multiprotocolo en hardware, software y nube ^{[ 35 ]}
• RabbitMQ , un proyecto de código abierto patrocinado por VMware , es compatible con AMQP 1.0 a partir de la versión 4.0.

• JORAM , una implementación de código abierto en Java del Consorcio OW2 .
• Apache Qpid mantiene soporte para múltiples versiones de AMQP ^{[ 36 ]}

La versión 1.0 del protocolo AMQP es la versión actual de la especificación. Se centra en las características esenciales necesarias para la interoperabilidad a escala de Internet. Contiene un enrutamiento menos explícito que las versiones anteriores, ya que la funcionalidad principal es la primera en estandarizarse rigurosamente. La interoperabilidad de AMQP 1.0 se ha probado de forma más exhaustiva con un mayor número de implementadores que las versiones anteriores. ^{[ 37 ]}

El sitio web de AMQP contiene la especificación OASIS para la versión 1.0 .

Las versiones anteriores de AMQP, publicadas antes del lanzamiento de la versión 1.0 (véase el historial más arriba) y que difieren significativamente de ella, incluyen:

• AMQP 0-9-1 , que tiene clientes disponibles "para muchos lenguajes de programación y plataformas populares" ^{[ 38 ].}
• AMQP 0-10

Estas especificaciones de protocolo abierto cubren el mismo espacio o uno similar al de AMQP:

• El protocolo de mensajería orientada a texto en streaming (STOMP), un protocolo basado en texto desarrollado en Codehaus, utiliza la semántica de "destino" similar a la de JMS.
• Protocolo de mensajería y presencia extensible (XMPP), el protocolo de mensajería y presencia extensible.
• MQTT , un protocolo ligero de publicación-suscripción.
• OpenWire, tal como lo utiliza ActiveMQ .

El Servicio de Mensajería Java (JMS) se compara frecuentemente con AMQP. Sin embargo, JMS es una especificación de API (parte de la especificación Java EE ) que define cómo se implementan los productores y consumidores de mensajes. JMS no garantiza la interoperabilidad entre implementaciones, y el sistema de mensajería compatible con JMS en uso puede requerir su implementación tanto en el cliente como en el servidor. Por otro lado, AMQP es una especificación de protocolo a nivel de red. En teoría, AMQP proporciona interoperabilidad, ya que se puede implementar software compatible con AMQP tanto en el cliente como en el servidor.

• De igual a igual
• Cola de mensajes
• servicio de cola de mensajes
• Servicio de distribución de datos
• IBM MQ

• Official website
• OASIS AMQP technical committee
• High-level Overview of AMQP and the AMQP Model (version 0-9-1)
• OMG Analysis of AMQP and comparison with DDS-RTPS
• Google Tech Talk, with video and slides, about RabbitMQ
• Presentation of AMQP and RestMS messaging at FOSDEM 2009
• List of AMQP clients