AMQP: conoce el Advanced Message Queuing Protocol

Los servicios deben ser capaces de co­mu­ni­car­se entre sí. Se in­te­r­ca­m­bia in­fo­r­ma­ción y se tra­n­s­mi­ten datos. Para muchos puede sonar más fácil de lo que realmente es, ya que en este tipo de co­n­ve­r­sa­cio­nes entre diversas apli­ca­cio­nes es preciso superar varias di­fi­cu­l­ta­des. En in­fo­r­má­ti­ca también existen barreras li­n­güí­s­ti­cas (en forma de varios lenguajes de pro­gra­ma­ción) y es preciso mantener un protocolo para evitar el caos.

Advanced Message Queuing Protocol (abreviado como AMQP) se presenta como una solución: un protocolo común que pueda tra­n­s­po­r­tar la in­fo­r­ma­ción a través de un in­te­r­me­dia­rio. ¿Cómo funciona? ¿Qué más puede hacer el estándar AMQP?

Advanced Message Queuing Protocol lleva de­sa­rro­llá­n­do­se desde 2003 y es una excepción, pues no proviene de una empresa dedicada a la te­c­no­lo­gía, sino que fue concebido ini­cia­l­me­n­te en JPMorgan Chase, un banco es­ta­dou­ni­de­n­se. Allí fue donde de­ci­die­ron seguir de­sa­rro­lla­n­do el proyecto con otros socios. Además de empresas te­c­no­ló­gi­cas como Cisco, es sobre todo el sector fi­na­n­cie­ro el que sigue in­te­re­sá­n­do­se por AMQP. ¿Por qué ocurre esto? Porque para ellos el tiempo es dinero: la tra­n­s­mi­sión de la in­fo­r­ma­ción es fu­n­da­me­n­tal para un banco, una empresa de tarjetas de crédito o una bolsa de valores, lugares donde in­te­r­ca­m­bian cientos de miles de mensajes por segundo. Es por eso que puede resultar caro que los mensajes lleguen tarde o di­re­c­ta­me­n­te no lleguen.

Dado que en aquel momento ningún producto comercial era capaz de cumplir los re­qui­si­tos de forma sa­ti­s­fa­c­to­ria, se tomó la decisión (John O'Hara como director del proyecto) de de­sa­rro­llar un protocolo propio. O'Hara se basó en los es­tá­n­da­res de código abierto como TCP/IP y decidió que AMQP también fuese libre, para así impulsar el de­sa­rro­llo del protocolo. Mientras tanto, un grupo de trabajo de OASIS (or­ga­ni­za­ción sin ánimo de lucro) trabajaba en el de­sa­rro­llo del protocolo.

El protocolo AMQP resuelve varios problemas al mismo tiempo: por un lado, el protocolo (en co­la­bo­ra­ción con un bróker de me­n­sa­je­ría) se encarga de una tra­n­s­mi­sión sólida de datos. Por otro, AMQP permite almacenar mensajes en una cola. Esto, a su vez, permite una co­mu­ni­ca­ción asíncrona: tra­n­s­mi­sor y receptor no deben actuar al mismo ritmo. El receptor (co­n­su­mi­dor) del mensaje no tiene por qué aceptar, procesar la in­fo­r­ma­ción di­re­c­ta­me­n­te y confirmar la recepción al emisor (productor). En su lugar, re­cu­pe­ra­rá el mensaje de la cola cuando tenga capacidad di­s­po­ni­ble para ello. Esto ofrece al productor, entre otras cosas, la po­si­bi­li­dad de seguir tra­ba­ja­n­do y se evitan los tiempos de inac­ti­vi­dad.

El éxito que ha ex­pe­ri­me­n­ta­do el AMQP protocol, re­la­ti­va­me­n­te nuevo, está muy re­la­cio­na­do con la in­te­ro­pe­ra­bi­li­dad. Advanced Message Queuing Protocol establece un fu­n­da­me­n­to común por sí solo. Esto permite, incluso, que las distintas apli­ca­cio­nes se puedan escribir en di­fe­re­n­tes lenguajes de pro­gra­ma­ción. De esta manera, los programas también se comunican entre ellos sin ningún tipo de co­m­pli­ca­ción, aunque no sean de la misma or­ga­ni­za­ción. Además, puesto que AMQP está di­s­po­ni­ble de forma gratuita, cualquier empresa puede utilizar el protocolo sin incurrir en costes adi­cio­na­les.

En el modelo de re­fe­re­n­cia OSI, AMQP actúa sobre la capa de apli­ca­ción: de este modo, tiene contacto directo con los distintos programas. Asimismo, IMAP (para correo ele­c­tró­ni­co), FTP (para la tra­n­s­fe­re­n­cia de archivos) e IRC (para me­n­sa­je­ría in­s­ta­n­tá­nea) están activos en esta capa. Para la tra­n­s­mi­sión de los mensajes, el protocolo apuesta por los in­te­r­me­dia­rios: los llamados brókers de me­n­sa­je­ría. Estos asumen la di­s­tri­bu­ción de los mensajes a di­fe­re­n­tes de­s­ti­na­ta­rios y de acuerdo con reglas es­ta­ble­ci­das. AMQP también regula el co­m­po­r­ta­mie­n­to de este servidor in­te­r­me­dio.

Advanced Message Queuing Protocol se refiere tanto a la co­mu­ni­ca­ción entre los distintos pa­r­ti­ci­pa­n­tes, que incluyen las in­s­tru­c­cio­nes en los mensajes, como al propio co­m­po­r­ta­mie­n­to de los brókers.

En el cosmos de AMQP hay tres actores y un objeto:

• El mensaje es el elemento central de toda la co­mu­ni­ca­ción.
• El productor (producer) crea un mensaje y lo envía.
• El bróker de me­n­sa­je­ría di­s­tri­bu­ye el mensaje de acuerdo con reglas definidas en di­fe­re­n­tes colas (queue).
• El co­n­su­mi­dor (consumer) recupera el mensaje de la cola —a la que tiene acceso— y lo edita.

El bróker in­te­rru­m­pe la difusión del mensaje una vez más: el in­te­r­ca­m­bia­dor recibe los mensajes y dirige los datos a la cola correcta. La vi­n­cu­la­ción informa al in­te­r­ca­m­bia­dor sobre la cola a la que pertenece el mensaje. Se conocen cuatro formas di­fe­re­n­tes en las que un in­te­r­ca­m­bia­dor transmite mensajes.

El primer tipo, el in­te­r­ca­m­bia­dor directo, envía mensajes a un receptor concreto y trabaja para ello con claves de en­ru­ta­mie­n­to. Al mensaje se le transmite este tipo de clave. Una cola, a su vez, tiene una clave de vi­n­cu­la­ción. Esta ide­n­ti­fi­ca la cola frente al in­te­r­ca­m­bia­dor. Si la clave de en­ru­ta­mie­n­to y la clave de vi­n­cu­la­ción son iguales, el mensaje se puede enviar a la cola y con ello al receptor del mismo. También es posible que una cola tenga varias claves de vi­n­cu­la­ción y, por lo tanto, se pueda utilizar incluso para varias claves de en­ru­ta­mie­n­to. Por el contrario, varias colas también pueden compartir una clave de vi­n­cu­la­ción, que se conoce como vi­n­cu­la­ción múltiple. El in­te­r­ca­m­bio mu­l­ti­pli­ca el mensaje y lo envía a varios de­s­ti­na­ta­rios.

El in­te­r­ca­m­bia­dor de abanico funciona de manera similar. Sin embargo, el bróker ignora en este caso la clave de en­ru­ta­mie­n­to por completo. En su lugar, el in­te­r­ca­m­bia­dor envía un mensaje a todas las colas di­s­po­ni­bles y reproduce la in­fo­r­ma­ción allí. Por el contrario, el in­te­r­ca­m­bia­dor con un tema definido funciona de otra forma. Al igual que en un in­te­r­ca­m­bia­dor directo, la clave de en­ru­ta­mie­n­to y las claves de vi­n­cu­la­ción se emparejan. Sin embargo, no debe existir una coin­ci­de­n­cia exacta. En su lugar, se utilizan comodines. De esta forma se pueden preparar mensajes es­pe­cí­fi­cos para varias colas.

Por último, el in­te­r­ca­m­bia­dor de en­ca­be­za­mie­n­tos actúa con el en­ca­be­za­mie­n­to de un mensaje, en lugar de actuar con una clave de en­ru­ta­mie­n­to. En él se en­cue­n­tran valores que se co­rre­s­po­n­den con la vi­n­cu­la­ción. El argumento con la etiqueta x-match determina si todos los valores deben coincidir (valor: todos) o solo uno de ellos debe co­rre­s­po­n­de­r­se con la vi­n­cu­la­ción (valor: cua­l­quie­ra). Mientras que el primero se co­rre­s­po­n­de con el in­te­r­ca­m­bia­dor directo, con el último se puede generar el mismo efecto que en un in­te­r­ca­m­bia­dor con un tema definido.

Un frame es la unidad básica en AMQP. Una conexión está compuesta de una secuencia ordenada de frames. En este caso, el término orden hace re­fe­re­n­cia a que el último frame no debe llegar al receptor antes de que los demás frames hayan alcanzado pre­via­me­n­te su objetivo. Cada frame se puede dividir (en la versión 1.0) en tres segmentos:

• Header del frame: este header obli­ga­to­rio tiene un tamaño de 8 bytes. Aquí en­co­n­tra­rás la in­fo­r­ma­ción que determina el en­ru­ta­mie­n­to del mensaje.
• Header extendido: este ámbito es opcional y no tiene ningún alcance definido. Sirve para ampliar la in­fo­r­ma­ción del header en un futuro.
• Cuerpo del frame: en el cuerpo se en­cue­n­tran realmente los datos a tra­n­s­mi­tir. El tamaño se puede se­le­c­cio­nar de forma ar­bi­tra­ria. Esta zona, sin embargo, puede dejarse en blanco, de forma que el frame solo sirve para mantener la conexión.

El cuerpo de un frame, a su vez, puede adoptar nueve formas di­fe­re­n­tes:

• open: negocia los pa­rá­me­tros de conexión entre el bróker y el cliente.
• begin: indica que una conexión se inicia.
• attach: se adjunta un enlace al mensaje, necesario para poder usar la tra­n­s­fe­re­n­cia de datos.
• flow: cambia el estado de un enlace.
• transfer: con el marco de la tra­n­s­fe­re­n­cia se tra­n­s­fie­re el mensaje real.
• di­s­po­si­tion: un frame de di­s­po­si­ción informa sobre mo­di­fi­ca­cio­nes en la entrega de la in­fo­r­ma­ción.
• detach: elimina el enlace.
• end: indica que se termina la conexión.
• close: termina la conexión y declara que no se van a enviar más frames.

Cada cola tiene su propio nombre, que le ide­n­ti­fi­ca entre los demás pa­r­ti­ci­pa­n­tes. O bien un cliente, o bien el bróker es­ta­ble­cen el nombre. Una cola se realiza mediante una memoria. Esta puede estar integrada en un disco duro o ser volátil y estar en la unidad de memoria principal. La versión pe­r­ma­ne­n­te asegura que, incluso después de reiniciar un bróker, la cola persiste. Sin embargo, no garantiza que los mensajes se guarden de forma pe­r­ma­ne­n­te: depende del mensaje que este siga estando di­s­po­ni­ble después de un reinicio.

¿Qué pasa si un co­n­su­mi­dor no puede recuperar el mensaje de la cola porque, por ejemplo, el cliente o la conexión se ha in­te­rru­m­pi­do? Es posible decidir si un co­n­su­mi­dor tiene que acusar recibo de un mensaje o es su­fi­cie­n­te que el envío se realice co­rre­c­ta­me­n­te. Si se elige la primera opción y el co­n­su­mi­dor no envía ningún mensaje, el bróker intentará enviar el mensaje a otro co­n­su­mi­dor o tratará de conectar con el mismo receptor una vez más. Sin embargo, si está activada la variante sin co­n­fi­r­ma­ción y el co­n­su­mi­dor no reclama la entrega del mensaje, este se perderá.

También es posible que un cliente rechace la ace­p­ta­ción de un mensaje co­n­s­cie­n­te­me­n­te. Esto puede ser útil cuando el pro­ce­sa­mie­n­to del mensaje no funciona. La respuesta del co­n­su­mi­dor empuja al bróker, bien a borrar el mensaje por completo, bien a in­te­grar­lo de nuevo en la cola.

En la ac­tua­li­dad existen dos versiones co­m­ple­ta­me­n­te in­de­pe­n­die­n­tes de Advanced Message Queuing Protocol. El grupo OASIS de­sa­rro­lló la versión 1.0. Sobre todo, RabbitMQ utiliza la versión 0-9-1, que es un poco más antigua. Ninguna de las dos son co­m­pa­ti­bles entre ellas. La versión 1.0 se di­fe­re­n­cia pri­n­ci­pa­l­me­n­te por la menor im­po­r­ta­n­cia que tienen los brókers, las vi­n­cu­la­cio­nes y los in­te­r­ca­m­bia­do­res. 0-9-1 no los necesita, aunque no prohíbe utilizar dichos in­te­r­me­dia­rios.