Protocolo de cola de mensajes avanzado

This article relies excessively on references to primary sources. Please improve this article by adding secondary or tertiary sources. Find sources: "Advanced Message Queuing Protocol" – news · newspapers · books · scholar · JSTOR (May 2018) (Learn how and when to remove this message)

El protocolo de colas de mensajes avanzado ( AMQP ) es un protocolo de capa de aplicación estándar abierto para middleware orientado a mensajes . Las características que definen a AMQP son la orientación de los mensajes, la cola, el enrutamiento (incluidos los de punto a punto y publicación y suscripción ), la confiabilidad y la seguridad. ^[1]

AMQP ordena el comportamiento del proveedor de mensajería y del cliente en la medida en 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 han ocurrido 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 debe proporcionar una implementación de mensajería, 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 de manera eficiente una amplia variedad de aplicaciones de mensajería y patrones de comunicación. Proporciona comunicación orientada a mensajes y controlada por flujo ^[3] con garantías de entrega de mensajes como, por ejemplo , como máximo una vez (donde cada mensaje se entrega una vez o nunca), como mínimo una vez (donde cada mensaje se entrega con certeza, 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] Supone 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 asincrónico 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 abierto cooperativo. El diseño inicial estuvo a cargo de JPMorgan Chase desde mediados de 2004 hasta mediados de 2006 y contrató a iMatix Corporation para desarrollar un bróker C y documentación de 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). En el mismo año, JPMorgan Chase se asoció con Red Hat para crear Apache Qpid , inicialmente en Java y poco después en C++. Independientemente, Rabbit Technologies desarrolló RabbitMQ en Erlang , seguido más tarde por las implementaciones de Microsoft y StormMQ.

El grupo de trabajo creció 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 , CEO y diseñador jefe de software de iMatix, escribió un artículo llamado "What is wrong with AMQP (and how to fix it)" ^[8] y lo distribuyó al grupo de trabajo para alertar sobre un fallo inminente, identificar los problemas detectados por iMatix y proponer formas de solucionar 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 AMQP y no planeaba dar soporte a AMQP/1.0 a favor de ZeroMQ, significativamente más simple y rápido. ^[9]

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

El grupo de trabajo AMQP publicó AMQP 1.0 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 avanzar esta versión 1.0 de AMQP a través del proceso de estándares abiertos internacionales. El primer borrador de OASIS se publicó en febrero de 2012 ^[12] , y 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 (de nuevo sin cambios funcionales) ^[13] , y AMQP fue aprobado como estándar de OASIS el 31 de octubre de 2012 ^[14].

El OASIS AMQP fue aprobado para su publicación como estándar internacional ISO e IEC en abril de 2014. ^[15] El AMQP 1.0 fue sometido a votación a través del Comité Técnico Conjunto sobre 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 presentación aprobada del 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 son significativamente diferentes de la especificación 1.0. ^{[17] [18]}

Si bien AMQP se originó en la industria de servicios financieros, tiene una 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 tipificados se anoten con un significado adicional, ^[19] por ejemplo, un valor de cadena particular podría anotarse de modo que pueda entenderse como una URL . Del mismo modo, un valor de mapa que contenga 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 permita que las entidades de procesamiento expresen y comprendan metadatos estándar y extendidos. También se utiliza para definir las primitivas de comunicación a través de las cuales se intercambian mensajes entre dichas entidades, es decir, los cuerpos de trama AMQP .

La unidad básica de datos en AMQP es una trama . Hay nueve cuerpos de trama AMQP definidos que se utilizan para iniciar, controlar y desmantelar 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 )
• fin (la sesión )
• cerrar (la conexión )

El protocolo de enlace es el corazón de AMQP.

Se envía un cuerpo de trama adjunta para iniciar un nuevo vínculo y un cuerpo de trama separada para eliminar un vínculo. Se pueden establecer vínculos para recibir o enviar mensajes.

Los mensajes se envían a través de un enlace establecido mediante el marco 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, administrado mediante marcos de flujo . Esto permite que un proceso se proteja de verse abrumado por un volumen demasiado grande de mensajes o, más simplemente, permite que un enlace suscriptor extraiga mensajes cuando lo desee. ^[20]

Cada mensaje transferido debe ser liquidado en algún momento . La liquidación garantiza que el emisor y el receptor estén de acuerdo sobre el estado de la transferencia, lo que proporciona garantías de confiabilidad. Los cambios de estado y la liquidación de una transferencia (o un conjunto de transferencias) se comunican entre los pares mediante el marco de disposición . Se pueden aplicar varias garantías de confiabilidad de esta manera: como máximo una vez, al menos una vez y exactamente una vez. ^[21]

Se pueden agrupar varios enlaces, en ambas direcciones, en una sesión . Una sesión es una conversación secuencial bidireccional entre dos pares que se inicia con un marco de inicio y finaliza con un marco de fin . Una conexión entre dos pares puede tener múltiples sesiones multiplexadas, cada una de ellas lógicamente independiente. Las conexiones se inician con un marco abierto en el que se expresan las capacidades del par emisor y finalizan con un marco cerrado .

AMQP define como mensaje desnudo aquella parte del mensaje que crea la aplicación que lo envía. Se considera inmutable ya que el mensaje se transfiere entre uno o más procesos.

Asegurarse de que el mensaje enviado por la aplicación sea inmutable permite la firma y/o cifrado de mensajes de extremo a extremo y garantiza que todas las comprobaciones de integridad (por ejemplo, hashes o resúmenes ) sigan siendo válidas. Los intermediarios pueden anotar el mensaje durante el tránsito, pero dichas anotaciones se mantienen separadas del mensaje simple inmutable . Las anotaciones se pueden agregar antes o después del mensaje simple.

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 (identificación del mensaje, identificación del usuario, hora de creación, respuesta, asunto, identificación de correlación, identificación del 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 se especifican en el sistema de tipos AMQP, al igual que las anotaciones. Los datos de la aplicación pueden tener cualquier formato y cualquier codificación que elija 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 asume muy poco acerca de qué son esos nodos o cómo están implementados.

Una categoría clave son aquellos nodos utilizados como punto de encuentro entre los emisores y los 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 mensajes ^[25]
• un mecanismo para indicar o solicitar uno de los dos patrones básicos de distribución, consumidores competidores y no competidores, a través de los modos de distribución mover y copiar respectivamente ^[26]
• la capacidad de crear nodos a pedido, ^{[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]

Aunque AMQP se puede utilizar en sistemas peer-to-peer simples, la definición de este marco para las capacidades de mensajería permite además la interoperabilidad con intermediarios de mensajería (brokers, puentes, etc.) en redes de mensajería más grandes y ricas. El marco especificado cubre los comportamientos básicos, pero permite la evolución de extensiones que se pueden codificar y estandarizar aún más.

• 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
• Centros de eventos de Azure ^{[30] [31]}
• Bus de servicio de Azure ^{[30] [32]}
• IBM MQ ^{[33] [34]}
• Solace PubSub+, un bróker multiprotocolo en hardware, software y nube ^[35]
• RabbitMQ , un proyecto de código abierto patrocinado por VMware , admite AMQP 1.0 con la versión 4.0

• JORAM, una implementación de código abierto de 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 de especificación actual. Se centra en las características principales que son necesarias para la interoperabilidad a escala de Internet. Contiene menos enrutamiento explícito que las versiones anteriores porque la funcionalidad principal es la primera en estandarizarse rigurosamente. La interoperabilidad de AMQP 1.0 se ha probado de forma más exhaustiva con más 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 1.0 (ver Historial arriba) y significativamente diferentes de ella, incluyen:

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

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

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

Java Message Service (JMS) suele compararse con AMQP. Sin embargo, JMS es una especificación 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 es posible que el sistema de mensajería compatible con JMS que se utilice deba implementarse tanto en el cliente como en el servidor. Por otro lado, AMQP es una especificación de protocolo a nivel de cable. En teoría, AMQP proporciona interoperabilidad, ya que se puede implementar software compatible con AMQP diferente en el lado del cliente y del servidor.

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

• Sitio web oficial
• Comité técnico AMQP de OASIS
• Descripción general de alto nivel de AMQP y el modelo AMQP (versión 0-9-1)
• Análisis OMG de AMQP y comparación con DDS-RTPS
• Google Tech Talk, con vídeo y diapositivas, sobre RabbitMQ
• Presentación de mensajería AMQP y RestMS en FOSDEM 2009
• Lista de clientes de AMQP