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.

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 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ē.

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.

Ārējās saites

• amqp.org
• OASIS Advanced Message Queuing Protocol (AMQP) Version 1.0