AMQP: l’Advanced Message Queuing Protocol in breve

I servizi devono essere in grado di co­mu­ni­ca­re tra loro. Ciò avviene tramite uno scambio di in­for­ma­zio­ni e una tra­smis­sio­ne di dati. Ma tutto questo potrebbe sembrare più semplice di quel che è in realtà, perché per questo tipo di co­mu­ni­ca­zio­ne tra diverse ap­pli­ca­zio­ni possono insorgere diverse dif­fi­col­tà: ad esempio, anche nei reparti in­for­ma­ti­ci esistono le barriere lin­gui­sti­che (sotto forma di diversi linguaggi di pro­gram­ma­zio­ne) e bisogna attenersi ad un pro­to­col­lo, onde evitare di pre­ci­pi­ta­re nel caos.

Una soluzione è offerta dallo standard di Advanced Message Queuing Protocol, ab­bre­via­to con AMQP: un pro­to­col­lo completo, capace di tra­smet­te­re le in­for­ma­zio­ni con l’aiuto di un in­ter­me­dia­rio. Come funziona? Cos’altro può fare l’AMQP?

Il sistema di Advanced Message Queuing Protocol, svi­lup­pa­to a partire dal 2003 non è il frutto del lavoro di un’azienda operante nel settore tec­no­lo­gi­co, ma di un’idea della JPMorgan Chase, una banca sta­tu­ni­ten­se. È stato poi deciso di con­ti­nua­re a svi­lup­pa­re il progetto in col­la­bo­ra­zio­ne con altri. Oltre ad aziende in­for­ma­ti­che come Cisco, sono state so­prat­tut­to quelle del settore fi­nan­zia­rio ad in­te­res­sar­si all’AMQP. Come mai? Perché in quel settore, il tempo è denaro: in una banca, società di carte di credito o borsa, la tra­smis­sio­ne di in­for­ma­zio­ni svolge un ruolo fon­da­men­ta­le. Qui si scambiano migliaia di messaggi al secondo. Se i messaggi giungono in ritardo o non arrivano affatto, le con­se­guen­ze po­treb­be­ro essere costose.

Poiché all’epoca non esisteva alcun prodotto com­mer­cia­le in grado di sod­di­sfa­re tali requisiti, si decise (per opera di John O’Hara, il re­spon­sa­bi­le di progetto) di im­ple­men­ta­re un proprio pro­to­col­lo. O’Hara si orientò verso standard aperti come TCP/IP e decise di mettere a di­spo­si­zio­ne gra­tui­ta­men­te anche l’AMQP per ve­lo­ciz­za­re in questo modo lo sviluppo del pro­to­col­lo. Nel frattempo un gruppo di lavoro OASIS (un’as­so­cia­zio­ne di be­ne­fi­cen­za) lavora allo sviluppo del pro­to­col­lo.

Lo standard AMQP può risolvere più problemi allo stesso tempo: da una parte il pro­to­col­lo (in col­la­bo­ra­zio­ne con il broker di mes­sag­gi­sti­ca) ga­ran­ti­sce una tra­smis­sio­ne dei dati solida, dall’altra l’AMQP permette di de­po­si­ta­re i messaggi in una coda. Questo ha favorito una co­mu­ni­ca­zio­ne asincrona: mittente e de­sti­na­ta­rio non devono agire allo stesso ritmo. Il de­sti­na­ta­rio (con­su­ma­to­re) del messaggio non deve accettare né rie­la­bo­ra­re di­ret­ta­men­te l’in­for­ma­zio­ne e non deve neppure con­fer­mar­ne la ricezione al mittente (pro­dut­to­re). Deve invece prendere il messaggio dalla coda, quando ha a di­spo­si­zio­ne le capacità ne­ces­sa­rie. In questo modo il pro­dut­to­re ha la pos­si­bi­li­tà di con­ti­nua­re a lavorare, senza tempi morti.

Questo pro­to­col­lo, ancora re­la­ti­va­men­te giovane, riscuote par­ti­co­la­re successo anche per la sua in­te­ro­pe­ra­bi­li­tà. L’Advanced Message Queuing Protocol ha una base comune autonoma. Perciò le diverse ap­pli­ca­zio­ni possono essere anche scritte in linguaggi di pro­gram­ma­zio­ne diversi. Così possono capirsi tra loro senza problemi anche programmi di diverse or­ga­niz­za­zio­ni. E poiché l’AMQP è gratuito, ciascuna azienda può uti­liz­za­re questo pro­to­col­lo senza costi ag­giun­ti­vi.

Nel modello OSI l’AMQP opera sullo strato ap­pli­ca­ti­vo: così non ha contatto diretto con i diversi programmi. Sono attivi su questo livello anche gli IMAP (per le e-mail), FTP (per la tra­smis­sio­ne di dati) e IRC (per i servizi di mes­sag­gi­sti­ca istan­ta­nea). Per la tra­smis­sio­ne di messaggi il pro­to­col­lo utilizza degli in­ter­me­dia­ri, i co­sid­det­ti broker di mes­sag­gi­sti­ca. Questi ultimi si occupano della di­stri­bu­zio­ne dei messaggi a più de­sti­na­ta­ri secondo regole stabilite. L’AMQP regola anche il com­por­ta­men­to di tali server di di­stri­bu­zio­ne.

Lo standard di Advanced Message Queuing Protocol si collega non soltanto alla co­mu­ni­ca­zio­ne tra i diversi par­te­ci­pan­ti ma anche al com­por­ta­men­to del broker stesso. Questi ultimi con­ten­go­no le in­di­ca­zio­ni pro­ve­nien­ti dai messaggi.

Nel cosmo di AMQP ruotano tre attori e un oggetto:

• Il messaggio è l’elemento chiave dell’intero processo di co­mu­ni­ca­zio­ne.
• Il pro­dut­to­re (Producer) crea un messaggio e lo invia.
• Il broker di mes­sag­gi­sti­ca di­stri­bui­sce il messaggio secondo regole definite a diverse code (Queue).
• Il con­su­ma­to­re (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 de­sti­na­ta­rio lavorando con delle routing key. Questa chiave viene con­se­gna­ta insieme al messaggio. La coda, invece, dispone di una binding key. Questa iden­ti­fi­ca la coda per l’elemento di scambio. Quando la routing key e la binding key coin­ci­do­no, il messaggio può essere inoltrato alla coda e quindi al relativo de­sti­na­ta­rio. È anche possibile che una coda disponga di più binding key e sia quindi com­pa­ti­bi­le 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ù de­sti­na­ta­ri.

Il Fanout Exchange funziona in maniera simile. Qui però il broker ignora to­tal­men­te la routing key. Al suo posto, l’elemento di scambio inoltra un messaggio a tutte le code di­spo­ni­bi­li e replica l’in­for­ma­zio­ne. Di­ver­sa­men­te funziona invece il Topic Exchange. In maniera simile al direct exchange, anche qui le routing key vengono con­fron­ta­te con le binding key, ma non deve esserci una cor­ri­spon­den­za esatta. Per questo si uti­liz­za­no caratteri jolly. Così i messaggi possono essere in­di­riz­za­ti 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 con­fron­ta­re con il binding. L’argomento con la de­fi­ni­zio­ne x-match definisce se tutti i valori debbano cor­ri­spon­de­re tra loro (valore: all) oppure se uno soltanto debba cor­ri­spon­de­re al binding (valore: any). Mentre il primo cor­ri­spon­de al Direct Exchange, con l’ultimo si può ottenere un effetto simile a quello di un Topic Exchange.

Nello standard AMQP, un frame rap­pre­sen­ta l’unità di base. Un col­le­ga­men­to è composto dalla suc­ces­sio­ne ordinata di frame. In questo caso, ordine significa che l’ultimo frame non deve giungere al de­sti­na­ta­rio, 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 ob­bli­ga­to­rio ha una di­men­sio­ne di 8 byte. Qui si trovano le in­for­ma­zio­ni che de­fi­ni­sco­no il routing del messaggio.
• Extended Header: è un segmento fa­col­ta­ti­vo e non possiede un volume stabilito. Serve ad ampliare l’header di ulteriori in­for­ma­zio­ni future.
• Frame Body: nel body si trovano le in­for­ma­zio­ni da tra­smet­te­re. Le di­men­sio­ni possono essere pre­di­spo­ste 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 col­le­ga­men­to tra broker e client.
• begin: indica l’inizio di un col­le­ga­men­to.
• attach: al messaggio viene allegato un link es­sen­zia­le per il tra­sfe­ri­men­to dei dati.
• flow: modifica lo stato di un link.
• transfer: con il frame di transfer viene trasmesso il reale messaggio.
• di­spo­si­tion: un frame di di­spo­si­tion informa su eventuali modifiche nella tra­smis­sio­ne dell’in­for­ma­zio­ne.
• detach: rimuove il link.
• end: indica la fine del col­le­ga­men­to.
• close: mette fine al col­le­ga­men­to e spiega che non verranno inviati altri frame.

Ogni coda ha un suo nome che la iden­ti­fi­ca per gli altri par­te­ci­pan­ti. È il cliente o il broker a stabilire la de­fi­ni­zio­ne. Una coda si realizza at­tra­ver­so una memoria. Questa può trovarsi o su un disco rigido o come file volatile sulla memoria prin­ci­pa­le. La variante duratura ga­ran­ti­sce che la coda sia ancora presente anche dopo un nuovo avvio del broker. Non può però garantire che i messaggi siano sal­va­guar­da­ti nel tempo. L’eventuale di­spo­ni­bi­li­tà 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 in­ter­ru­zio­ne del col­le­ga­men­to o del Client? Si può scegliere se il consumer debba con­fer­ma­re la ricezione del messaggio o se sia suf­fi­cien­te il semplice invio per ga­ran­tir­ne il successo. Se viene se­le­zio­na­ta 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 rag­giun­ge­re nuo­va­men­te il de­sti­na­ta­rio iniziale. Nel caso della variante con la ricezione di­sat­ti­va­ta e mancata lettura da parte del de­sti­na­ta­rio, il messaggio si perde.

Può anche succedere che un Client rifiuti con­sa­pe­vol­men­te la ricezione di un messaggio. Questo può essere utile, ad esempio, quando non funziona il processo di rie­la­bo­ra­zio­ne di un messaggio. Il feedback del consumer fa decidere al broker se eliminare de­fi­ni­ti­va­men­te il messaggio o in­glo­bar­lo nuo­va­men­te nella coda.

Al momento sono di­spo­ni­bi­li due versioni to­tal­men­te in­di­pen­den­ti tra loro dell’Advanced Message Queuing Protocols. La versione 1.0 è svi­lup­pa­ta dal gruppo OASIS. Ma in par­ti­co­la­re con RabbitMQ, si utilizza piuttosto la vecchia versione 0-9-1. Le due versioni non sono com­pa­ti­bi­li tra loro. La versione 1.0 si distingue prima di tutto per il ridotto si­gni­fi­ca­to di Broker, Binding ed Exchange. La versione 0-9-1 non ne ha bisogno, ma non vieta l’utilizzo di tali in­ter­me­dia­ri.