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 (organization)|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 *[[Transmission Control Protocol|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ā *[[Microsoft Azure|Azure]]* integrēja *AMQP* realizāciju *Azure Service Bus*.

*AMQP* darba grupa 2011. gada augustā paziņoja par reorganizāciju, kļūstot par *[[OASIS (organization)|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***.

## ''AMQP 1.0'' apraksts
*AMQP* versijas 1.0 protokols, atšķirībā no iepriekšējām versijām, atdala tīkla transportu no brokera arhitektūras un pārvaldības. Tas atbalsta dažādas starpnieka arhitektūras, kuras var izmantot ziņojumu saņemšanai, rindošanai, maršrutēšanai un piegādei vai izmantot vienādranga veidošanai, bet standarts neapraksta pašu starpnieka arhitektūru.

*AMQP 1.0* specifikācija apraksta protokola arhitektūru vairākos slāņos:
* tipu sistēma un kodēšana
* transporta slānis - efektīvs, binārs, vienādranga protokols ziņojumu transportēšanai starp diviem procesiem tīklā
* ziņojumu slānis - ziņojuma formāts ar konkrētu kodējumu
* transakciju slānis - nosaka, kā mijiedarbību var sagrupēt atomu darbībās
* drošības slāņi

### 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ā.

#### Performatīvi un saites protokols
*AMQP* datu pamatvienība ir kadrs. Ir definēti deviņi *AMQP* kadru ķermeņi, kas tiek izmantoti, lai inicializētu, kontrolētu un pārtrauktu ziņojumu nodošanu starp diviem vienrangiem. Tie ir:
* *open* (atvērt savienojumu)
* *begin* (sākt sesiju)
* *attach* (pievienot saiti)
* *transfer* (pārsūtīt)
* *flow* (plūsma)
* *disposition* (izvietojums)
* *detach* (saites atvienošana)
* *end* (sesijas beigas)
* *close* (savienojuma aizvēršana)

Ar *attach* tiek pievienots kadra ķermenis, tādējādi izveidot jaunu saiti; *detach* nodzēš saiti. Saites var izveidot, vai nu lai saņemtu, vai lai nosūtītu ziņas.
Ziņojumi tiek nosūtīti pa nodibinātu saiti, izmantojot *transfer* kadru. Ziņojumi saitē plūst tikai vienā virzienā.

Pārsūtīšana darbojas pēc uz kredītu balstītas plūsmas kontroles shēmas, ko pārvalda, izmantojot plūsmas (*flow*) kadrus. Tas ļauj procesam sevi pasargāt no pārāk liela ziņojumu apjoma vai vēl vienkāršāk, lai ļautu abonēšanas saitei atgādāt ziņojumus tikai, kad tas ir nepieciešams.

Katrs pārsūtītais ziņojums ir jānokārto (*settle*). Nokārtošana nodrošina, ka sūtītājs un saņēmējs vienojas par pārsūtīšanas stāvokli, sniedzot uzticamības garantijas. Par pārsūtīšanas (vai pārsūtīšanu kopas) izmaiņām stāvoklī un nokārtošanā starp vienrangiem paziņo, izmantojot izvietojuma (*disposition*) kadru. Šādā veidā var ieviest dažādas uzticamības garantijas: ne vairāk kā vienu reizi, vismaz vienu reizi un tieši vienu reizi.

Sesijā var sagrupēt vairākas saites abos virzienos. Sesija ir divvirzienu secīgs dialogs starp diviem vienrangiem, kas tiek iniciēta ar sākuma (*begin*) kadru un pārtraukta ar beigu (*end*) kadru. Savienojumā starp diviem vienrangiem var būt vairākas multipleksētas sesijas, katra no tām ir loģiski neatkarīga. Savienojumi tiek iniciēti ar atvēršanas (*open*) kadru, kurā tiek izteiktas sūtītāja vienranga iespējas, un pārtraukti ar aizvēršanas (*close*) kadru.

### Ziņojumu slānis
Ziņapmaiņas slāņa pamatā ir tipu sistēmā un transporta slānī aprakstītie jēdzieni. Transportēšanas slānis nosaka vairākus paplašinājumus, kas ir piemēroti lietošanai dažādās ziņapmaiņas lietojumprogrammās. Ziņojumu līmenis nosaka standartizētu to izmantošanu, lai nodrošinātu sadarbspējīgas ziņojumapmaiņas iespējas. Šis standarts attiecas uz:
* ziņojuma formātu
** plikā ziņojuma īpašībām
** plikā ziņojuma strukturēto un nestrukturēto sekciju formātiem
** anotētā ziņojuma galvenēm un kājenēm
* starp mezgliem ceļojošo ziņojumu nogādes stāvokļiem
* sadales mezglā noglabāto ziņojumu stāvokļiem
* avotiem un mērķiem
** pārvietošanas izvietojumu pēc noklusējuma
** atbalstītajiem iznākumiem
** filtrētajiem ziņojumiem no mezgla
** izplatīšanas režīmu piekļuvei ziņojumiem, kas glabājas sadales mezglā
** mezgla izveidi pēc pieprasījuma

#### 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).

### Transakciju slānis
Transakciju ziņojumapmaiņa ļauj koordinēt citādi neatkarīgas ziņojumu transakcijas. Katrai transakciju mijiedarbībai viens konteiners darbojas kā transakciju resurss, bet otrs konteiners ir kā transakciju kontrolieris. Transakciju resurss veic transakciju darbu tā, kā to pieprasa transakciju kontrolieris.

Transakciju kontrolieris un transakciju resurss sazinās pa kontroles saiti, ko izveidojis transakciju kontrolieris. Transakciju kontrolieris pa kontroles saiti nosūta deklarēšanas un izrakstīšanas ziņojumus, lai attiecīgi sadalītu un pabeigtu darījumus.

Transakcijas darbs ir formāli definēts kā šādas operācijas:
* ziņojuma izlikšana (*posting*) mērķī; veido to pieejamu
* ziņojuma iegūšana (*acquiring*) avotā; pārveido to par iegūtu
* ziņojuma aizvēršana (*retiring*) avotā; pielieto gala iznākumu

Kontrolieris pabeidz transakciju, nosūtot izpildes ziņojumu koordinatoram. Kontrolieris norāda, ka tas vēlas veikt vai atritināt transakcijas darbu.

### 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 *[[Simple Authentication and Security Layer|SASL]]* un / vai *[[Transport Layer Security|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ārt*AMQP 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ē.

## Protokola realizācijas
*AMQP 1.0* realizācijas brokera risinājumi:
* *[[Apache Qpid]]*, *[[The Apache Software Foundation]]* atvērtā pirmkoda projekts
* *[[Apache ActiveMQ]]*, *The Apache Software Foundation* atvērtā pirmkoda projekts

*AMQP* brokera realizācijas pirms 1.0 versijas:
* *[[JORAM]]*, *[[OW2 Consortium]]* *Java* atvērtā pirmkoda implementācija
* *[[Apache Qpid]]* uztur atbalstu vairākām *AMQP* versijām
* *[[Stormmq]]*, ziņojumu rindošanas pakalpojums, izmantojot *AMQP*; tiek piedāvāts kā komerciāli pārvaldīts pakalpojums.
* *[[Rabbitmq]]*, atvērtā pirmkoda projekts, ko sponsorē *[[Pivotal Software]]*, galvenokārt atbalsta *AMQP 0-9-1*, bet 1.0 versija ir pieejama, izmantojot spraudni.

## Atsauces

## Ārējās saites
* amqp.org
* OASIS Advanced Message Queuing Protocol (AMQP) Version 1.0