AMQP: l’Advanced Message Queuing Protocol in breve

I servizi devono essere in grado di comunicare tra loro. Ciò avviene tramite uno scambio di informazioni e una trasmissione di dati. Ma tutto questo potrebbe sembrare più semplice di quel che è in realtà, perché per questo tipo di comunicazione tra diverse applicazioni possono insorgere diverse difficoltà: ad esempio, anche nei reparti informatici esistono le barriere linguistiche (sotto forma di diversi linguaggi di programmazione) e bisogna attenersi ad un protocollo, onde evitare di precipitare nel caos.

Una soluzione è offerta dallo standard di Advanced Message Queuing Protocol, abbreviato con AMQP: un protocollo completo, capace di trasmettere le informazioni con l’aiuto di un intermediario. Come funziona? Cos’altro può fare l’AMQP?

Il sistema di Advanced Message Queuing Protocol, sviluppato a partire dal 2003 non è il frutto del lavoro di un’azienda operante nel settore tecnologico, ma di un’idea della JPMorgan Chase, una banca statunitense. È stato poi deciso di continuare a sviluppare il progetto in collaborazione con altri. Oltre ad aziende informatiche come Cisco, sono state soprattutto quelle del settore finanziario ad interessarsi all’AMQP. Come mai? Perché in quel settore, il tempo è denaro: in una banca, società di carte di credito o borsa, la trasmissione di informazioni svolge un ruolo fondamentale. Qui si scambiano migliaia di messaggi al secondo. Se i messaggi giungono in ritardo o non arrivano affatto, le conseguenze potrebbero essere costose.

Poiché all’epoca non esisteva alcun prodotto commerciale in grado di soddisfare tali requisiti, si decise (per opera di John O’Hara, il responsabile di progetto) di implementare un proprio protocollo. O’Hara si orientò verso standard aperti come TCP/IP e decise di mettere a disposizione gratuitamente anche l’AMQP per velocizzare in questo modo lo sviluppo del protocollo. Nel frattempo un gruppo di lavoro OASIS (un’associazione di beneficenza) lavora allo sviluppo del protocollo.

Lo standard AMQP può risolvere più problemi allo stesso tempo: da una parte il protocollo (in collaborazione con il broker di messaggistica) garantisce una trasmissione dei dati solida, dall’altra l’AMQP permette di depositare i messaggi in una coda. Questo ha favorito una comunicazione asincrona: mittente e destinatario non devono agire allo stesso ritmo. Il destinatario (consumatore) del messaggio non deve accettare né rielaborare direttamente l’informazione e non deve neppure confermarne la ricezione al mittente (produttore). Deve invece prendere il messaggio dalla coda, quando ha a disposizione le capacità necessarie. In questo modo il produttore ha la possibilità di continuare a lavorare, senza tempi morti.

Questo protocollo, ancora relativamente giovane, riscuote particolare successo anche per la sua interoperabilità. L’Advanced Message Queuing Protocol ha una base comune autonoma. Perciò le diverse applicazioni possono essere anche scritte in linguaggi di programmazione diversi. Così possono capirsi tra loro senza problemi anche programmi di diverse organizzazioni. E poiché l’AMQP è gratuito, ciascuna azienda può utilizzare questo protocollo senza costi aggiuntivi.

Nel modello OSI l’AMQP opera sullo strato applicativo: così non ha contatto diretto con i diversi programmi. Sono attivi su questo livello anche gli IMAP (per le e-mail), FTP (per la trasmissione di dati) e IRC (per i servizi di messaggistica istantanea). Per la trasmissione di messaggi il protocollo utilizza degli intermediari, i cosiddetti broker di messaggistica. Questi ultimi si occupano della distribuzione dei messaggi a più destinatari secondo regole stabilite. L’AMQP regola anche il comportamento di tali server di distribuzione.

Lo standard di Advanced Message Queuing Protocol si collega non soltanto alla comunicazione tra i diversi partecipanti ma anche al comportamento del broker stesso. Questi ultimi contengono le indicazioni provenienti dai messaggi.

Nel cosmo di AMQP ruotano tre attori e un oggetto:

• Il messaggio è l’elemento chiave dell’intero processo di comunicazione.
• Il produttore (Producer) crea un messaggio e lo invia.
• Il broker di messaggistica distribuisce il messaggio secondo regole definite a diverse code (Queue).
• Il consumatore (Consumer) prende il messaggio dalla coda a cui può accedere e lo rielabora.

Nel broker, il messaggio si rimette in marcia ancora una volta: l’Exchange prende il messaggio e indirizza i dati alla coda corretta. Il Binding permette all’Exchange di scoprire la coda corretta del messaggio. Esistono quattro modi diversi con cui un Exchange inoltra un messaggio.

Il primo tipo, il Direct Exchange, invia i messaggi ad un solo destinatario lavorando con delle routing key. Questa chiave viene consegnata insieme al messaggio. La coda, invece, dispone di una binding key. Questa identifica la coda per l’elemento di scambio. Quando la routing key e la binding key coincidono, il messaggio può essere inoltrato alla coda e quindi al relativo destinatario. È anche possibile che una coda disponga di più binding key e sia quindi compatibile con più routing key. Viceversa, anche più code possono dividersi una binding key. Questo processo si definisce multiple binding. L’elemento exchange replica il messaggio e lo invia a più destinatari.

Il Fanout Exchange funziona in maniera simile. Qui però il broker ignora totalmente la routing key. Al suo posto, l’elemento di scambio inoltra un messaggio a tutte le code disponibili e replica l’informazione. Diversamente funziona invece il Topic Exchange. In maniera simile al direct exchange, anche qui le routing key vengono confrontate con le binding key, ma non deve esserci una corrispondenza esatta. Per questo si utilizzano caratteri jolly. Così i messaggi possono essere indirizzati a più code.

Infine, l’Headers Exchange non opera con una routing key ma con l’header di un messaggio. È qui che si trovano i valori da confrontare con il binding. L’argomento con la definizione x-match definisce se tutti i valori debbano corrispondere tra loro (valore: all) oppure se uno soltanto debba corrispondere al binding (valore: any). Mentre il primo corrisponde al Direct Exchange, con l’ultimo si può ottenere un effetto simile a quello di un Topic Exchange.

Nello standard AMQP, un frame rappresenta l’unità di base. Un collegamento è composto dalla successione ordinata di frame. In questo caso, ordine significa che l’ultimo frame non deve giungere al destinatario, prima che tutti gli altri frame abbiamo raggiunto la loro meta. Ciascun frame (nella versione 1.0) può essere suddiviso in tre segmenti:

• Frame Header: questo header obbligatorio ha una dimensione di 8 byte. Qui si trovano le informazioni che definiscono il routing del messaggio.
• Extended Header: è un segmento facoltativo e non possiede un volume stabilito. Serve ad ampliare l’header di ulteriori informazioni future.
• Frame Body: nel body si trovano le informazioni da trasmettere. Le dimensioni possono essere predisposte in maniera libera. Questo settore può anche restare vuoto, perché serve soltanto a tenere unito il frame.

Il body di un frame può comunque assumere nove forme diverse:

• open: definisce i parametri di collegamento tra broker e client.
• begin: indica l’inizio di un collegamento.
• attach: al messaggio viene allegato un link essenziale per il trasferimento dei dati.
• flow: modifica lo stato di un link.
• transfer: con il frame di transfer viene trasmesso il reale messaggio.
• disposition: un frame di disposition informa su eventuali modifiche nella trasmissione dell’informazione.
• detach: rimuove il link.
• end: indica la fine del collegamento.
• close: mette fine al collegamento e spiega che non verranno inviati altri frame.

Ogni coda ha un suo nome che la identifica per gli altri partecipanti. È il cliente o il broker a stabilire la definizione. Una coda si realizza attraverso una memoria. Questa può trovarsi o su un disco rigido o come file volatile sulla memoria principale. La variante duratura garantisce che la coda sia ancora presente anche dopo un nuovo avvio del broker. Non può però garantire che i messaggi siano salvaguardati nel tempo. L’eventuale disponibilità dopo un nuovo avvio dipende infatti dal messaggio stesso.

Cosa accade quando un consumer non riesce a ritirare un messaggio dalla coda, come ad esempio, in caso di interruzione del collegamento o del Client? Si può scegliere se il consumer debba confermare la ricezione del messaggio o se sia sufficiente il semplice invio per garantirne il successo. Se viene selezionata la prima variante e il consumer non riesce a ricevere il messaggio, il broker cercherà di inviare in messaggio ad un altro consumer oppure di raggiungere nuovamente il destinatario iniziale. Nel caso della variante con la ricezione disattivata e mancata lettura da parte del destinatario, il messaggio si perde.

Può anche succedere che un Client rifiuti consapevolmente la ricezione di un messaggio. Questo può essere utile, ad esempio, quando non funziona il processo di rielaborazione di un messaggio. Il feedback del consumer fa decidere al broker se eliminare definitivamente il messaggio o inglobarlo nuovamente nella coda.

Al momento sono disponibili due versioni totalmente indipendenti tra loro dell’Advanced Message Queuing Protocols. La versione 1.0 è sviluppata dal gruppo OASIS. Ma in particolare con RabbitMQ, si utilizza piuttosto la vecchia versione 0-9-1. Le due versioni non sono compatibili tra loro. La versione 1.0 si distingue prima di tutto per il ridotto significato di Broker, Binding ed Exchange. La versione 0-9-1 non ne ha bisogno, ma non vieta l’utilizzo di tali intermediari.