Advanced Message Queuing Protocol

Advanced Message Queuing Protocol (AMQP) ir atvērta standarta lietojumslāņa protokols ziņojumapmaiņas starpprogrammatūrai. Lai gan AMQP radās finanšu pakalpojumu nozarē, tas ir piemērots plašam starpprogrammatūras problēmu klāstam.
AMQP izstrādā darba grupa AMQP Working Group, kas darbojas OASIS paspārnē.
Protokola pēdējā versija AMQP 1.0 tika apstiprināta 2012. gadā, un tās arhitektūra ir atšķirīga no iepriekšējām AMQP versijām. AMQP versija 1.0 ir vada protokols, kur tīkla transports ir atdalīts no starpnieka arhitektūras un pārvaldības. Protokolu var izmantot gan vienkāršās vienādranga sistēmās, gan dažādās ziņojumapmaiņas starpnieku sistēmās (brokeri, tilti utt.) ziņojumu saņemšanai, rindošanai, maršrutēšanai (ieskaitot "no punkta uz punktu" un "publicēšanu — abonēšanu) un piegādei. AMQP 1.0 nodrošina ziņojumu piegādes garantijas: "ne vairāk kā vienu reizi" (ja katrs ziņojums tiek piegādāts vienu reizi vai nekad), "vismaz vienu reizi" (ja ziņojums tiks garantēti piegādāts, bet tas var notikt vairākas reizes) un "tieši vienu reizi" (ja ziņojums noteikti pienāks, un to darīs tikai vienu reizi). AMQP darbojas virs TCP protokola.
Tiek turpināts attīstīt arī sistēmas, kas balstītas uz AMQP iepriekšējām versijām (0-10, 0-9-1, 0-9, 0-8), kurās iestrādāts brokera mehānisms.

Vēsture

Ideja par AMQP radās 2003. gadā, Džonam O'Hāram (John O'Hara) finanšu uzņēmumā JPMorgan Chase Londonā meklējot ziņapmaiņas risinājumu, kas nodrošinātu augstu ilgizturību, lielu datu apjoma apstrādi un augstu sadarbspējas pakāpi. Tolaik pieejamie komerciālie produkti nespēja nodrošināt nepieciešamo pakalpojumu līmeni, un bankas izstrādāja katra savu starpprogrammatūra, lai aizpildītu nepilnības. Uzņēmumu starpprogrammatūras izstrāde bija sarežģīta, un banku starpprogrammatūras risinājumi radās jauni un citu izstrāde tika pārtraukta. O'Hārs nolēma, ka AMQP būs atvērts kopsadarbības projekts. 
Sākotnējo projektu JPMorgan Chase izstrādāja no 2004. gada vidus līdz 2006. gada vidum, nolīgstot iMatix Corporation izstrādāt C brokera un protokola dokumentāciju. 2005. gadā JPMorgan Chase vērsās pie citiem uzņēmumiem, lai izveidotu AMQP darba grupu. Bez JPMorgan Chase darba grupā iekļāvās 22 uzņēmumi, tostarp Bank of America, Barclays, Cisco Systems, Credit Suisse, Deutsche Börse, Goldman Sachs, HCL Technologies, Progress Software, IIT Software, INETCO Systems Limited, Informatica (ar 29 West), Microsoft, my-Channels, Novell, Red Hat, Software AG, Solace Systems, StormMQ, Tervela, TWIST Process Innovations, VMware (ar iegādāto Rabbit Technologies) un WSO2.
2005. gadā sadarbībā ar Red Hat tika izveidota AMQP pirmā realizācija Apache Qpid, sākotnēji Java un drīz pēc tam C++. Neatkarīgi Rabbit Technologies Erlang sistēmai izstrādāja RabbitMQ. Vēlāk tika izstrādāta StormMQ implementācija, un Microsoft savā mākoņsistēmā Azure integrēja AMQP realizāciju Azure Service Bus.
AMQP darba grupa 2011. gada augustā paziņoja par reorganizāciju, kļūstot par OASIS dalībnieku sekciju.
2011. gada 30. oktobrī tika izlaista AMQP versija 1.0. Tā arhitektūra bija pilnībā pārstrādāta, atsakoties no brokera specifikācijām.
2012. gada 31. oktobrī AMQP 1.0 tika apstiprināts par OASIS standartu.
2014. gada aprīlī OASIS apstiprināja AMQP izlaišanai kā Starptautiskās Standartizācijas organizācijas (ISO) un Starptautiskās Elektrotehnikas komisijas (IEC) starptautisko standartu. AMQP 1.0 tika nosūtīts ar ISO un IEC Apvienotās informācijas tehnoloģiju komitejas (JTC1) starpniecību. OASIS AMQP iesniegums tika apstiprināts, un standartam piešķirts nosaukums ISO/IEC 19464.

Tipu sistēma

AMQP definē pašaprakstošu kodēšanas shēmu, kas nodrošina dažādu bieži lietotu tipu sadarbspējīgu attēlojumu. Tas arī ļauj ievadītajiem datiem būt anotētiem ar papildu nozīmi, piemēram, konkrētu virknes vērtību var anotēt tā, lai to varētu uztvert kā URL. Tāpat arī kartes vērtība, kas satur "atslēga - vērtība" pārus "vārds", "adrese" utt., var tikt anotēta kā “klienta” tipa attēlojums.
Tipu sistēmu izmanto, lai definētu ziņojuma formātu, kas, apstrādājot entītijas, ļauj izteikt un saprast standarta un paplašinātos metadatus. To izmanto arī, lai noteiktu saziņas primitivitātes, ar kuru palīdzību šādas struktūras apmainās ar ziņojumiem, t. i., AMQP "kadra ķermeņi".

Transporta slānis

AMQP transportēšanas specifikācija definē vienādranga protokolu ziņojumu pārsūtīšanai starp mezgliem AMQP tīklā.
AMQP tīkls sastāv no mezgliem (nodes), kas savienoti ar saitēm (links). Mezgli ir nosauktās entitātes, kas atbild par ziņojumu drošu glabāšanu un / vai piegādi. Ziņojumi var rasties no mezgliem, tos var pārtraukt no tiem vai nodot tiem.
Saite ir vienvirziena maršruts starp diviem mezgliem. Saite piesaistās mezglam galapunktā (terminus). Ir divu veidu galapunkti: avoti un mērķi. Avotu galapunkti izseko izejošos ziņojumus, un mērķa galapunkti izseko ienākošos ziņojumus. Ziņojumi ceļo pa saiti tikai tad, ja tie atbilst sākuma kritērijiem.
Mezgli eksistē konteinerā (container). Konteineru piemēri ir brokeri un klientu lietojumprogrammas. AMQP mezglu piemēri ir ražotāji (producers), patērētāji (consumers) un rindas (queues). Ražotāji un patērētāji ir elementi lietojumprogrammā, kas veido un apstrādā ziņojumus. Rindas ir entītijas, kas saglabā un pārsūta ziņojumus.
Lai nodrošinātu saziņu starp mezgliem dažādos konteineros, ir jāizveido savienojums.
Savienojums (connection) sastāv no pilndupleksa, ticami sakārtotas kadru secības. Kadrs (frame) ir darba vienība, kas tiek veikta savienojumā.
AMQP savienojums tiek sadalīts vairākos neatkarīgos vienvirziena kanālos. Katrs kadrs ir atzīmēts ar kanāla numuru, kas norāda tā vecāka kanālu, un kadru secība katram kanālam tiek multipleksēta savienojumam vienā kadru secībā.

Ziņojuma formāts

AMQP 1.0 pārnesamību starp dažādām sistēmām nodrošina ziņojumu kodēšana. Parasti šo kodējumu izmanto tikai, lai pievienotu maršrutēšanas rekvizītus ziņojuma "aploksnei"; aploksnes saturs tiek transportēts neskarts. Lietojumprogrammas parsti savā ziņojumu saturā izmanto XML, JSON vai līdzīgus formātus.
AMQP sūtītāja sniegtais ziņojums tiek definēts kā termins "plikais ziņojums" (bare message), un ziņojums, kāds redzams pie saņēmēja, tiek apzīmēts ar terminu "anotētais ziņojums" (annotated message).
Plikais ziņojums paliek neizmainīts, to pārsūtītot starp vienu vai vairākiem procesiem. Tas sastāv no trim sadaļām: standarta īpašībām (properties), lietojumprogrammas īpašībām (application-properties) un lietojumprogrammas datiem (application-data; ķermenis jeb pamatteksts).
Standarta īpašības ir neobligāts saraksts (ziņojuma ID, lietotāja ID, izveides laiks, atbildes adrese, tēma, korelācijas ID, grupas ID utt. Plikā ziņojuma neobligāta sekcija ir lietojumprogrammas īpašības; starpnieki var izmantot šīs struktūras datus filtrēšanas vai maršrutēšanas vajadzībām.
Lietojumprogrammas datu sekcijā tiek ievietoti binārie dati, kas var būt jebkurā formā un jebkurā lietojumprogrammas izvēlētajā kodējumā
Pliko ziņojumu pārsūtīšanas laikā var anotēt starpnieki, bet visas šādas anotācijas ir nošķirtas no nemainīgā ziņojuma. Anotācijas var pievienot pirms vai pēc plikā ziņojuma. Anotētais ziņojums sastāv no galvenes (header), piegādes anotācijām (delivery-annotations), ziņojuma anotācijām (message-annotations), plikā ziņojuma un kājenes (footer).
Galvenes sekcija satur detaļas par ziņojuma pārsūtīšanu: ilgmūžību (durability, prioritāti (priority), laiku dzīvošanai (ttl), piegāžu skaits (delivery-count; cik reižu bijuši ziņojuma piegādes neveiksmīgi mēģinājumi), first-acquirer (rāda, vai šis ziņojums ir pirmais, vai arī kāda cita saite to varējusi agrāk jau iegūt).
Kājenes sadaļa tiek izmantota, lai iegūtu detalizētu informāciju par ziņojumu vai piegādi, ko var aprēķināt vai novērtēt tikai tad, kad ir izveidots vai redzams viss plikais ziņojums (piemēram, ziņojuma jaucējkods, HMAC, paraksti un šifrēšanas detaļas).

Drošības slāņi

Drošības slāņus izmanto, lai izveidotu autentificētu un / vai šifrētu transportu, kurā var tunelēt AMQP datplūsmu. Drošības slāņus var tunelēt citu caur citu (piemēram, drošības slānis, ko autentifikācijai izmanto vienādrangi, var tikt tunelēts cauri drošības slānim, kas izveidots šifrēšanai). Šifrēšanai var izmantot SASL un / vai TLS protokolu.

AMQP 1.0 atšķirības no iepriekšējām versijām

Jaunākais AMQP standarts 1.0 ir radikāli atšķirīgs protokols no AMQP versijām 0-10, 0-9-1, 0-9 un 0-8, un tas ir daudz sarežģītāks nekā iepriekšējās versijas.
AMQP versijas 1.0 protokolā galvenā uzmanība pievērsta sadarbspējai interneta mērogā. Tajā ir mazāk skaidra maršrutēšana nekā iepriekšējās versijās, jo pamatfunkcionalitāte ir pirmā, kas tiek stingri standartizēta. Savukārt iepriekšējās versijas ir orientētas uz starpnieku (brokeri).
AMQP 1.0 paredz daudz mazāk semantisku prasību, tāpēc esošajiem brokeriem ir vieglāk pievienot AMQP 1.0 atbalstu. Savukārt iepriekšējās protokola versijas nevar darboties bez starpnieka.

Vadu protokols un brokera arhitektūra

AMQP 0-10 un agrākās versijas definē specifikāciju vadu protokolam un brokera arhitektūrai (ar jēdzieniem "centrāle" [exchange], "saistījumi" [bindings] un "rindas" [queues]). SavukārtAMQP 1.0 ir tikai protokola specifikācija, kurā nekas nav teikts par starpnieku arhitektūru. AMQP 1.0 nav nepieciešams, lai būtu kāds brokeris, centrāle vai saistījums. Protokolam arī nav noteikumu, kā starpniekus pārvaldīt.

Brokera pārvaldība

Agrākās versijas definē protokola komandas, kas tiek izmantotas starpnieka pārvaldībai, piemēram, Queue Declare, Queue Delete, Queue Query utt. AMQP 1.0 šādas komandas nav iekļautas, un tiek pieņemts, ka šādas iespējas tiks pievienotas augstākā slānī.

Simetrija

AMQP protokols pirms versijas 1.0  ir asimetrisks, jo katram savienojumam ir definēts “klienta” gals un “brokera” gals. Tādējādi tas ir stingri orientēts uz starpnieku.
Savukārt AMQP 1.0 ir simetrisks un neuzliek šādus ierobežojumus attiecībā uz savienojuma beigu punktiem. Šī protokola versija ļauj izveidot bezbrokera "punkts-punkts" sakarus. Tas arī  ļauj izveidot serverus / starpniekus, kas nav brokeri stingrā nozīmē.