Advanced Message Queuing Protocol
AMQP - standarden ( Advanced Message Queuing Protocol ) er en åpen standardprotokoll i applikasjonslaget til et kommunikasjonssystem. De definerende egenskapene til AMQP-protokollen er meldingsorientering, kø, ruting (både punkt-til-punkt og publiser-abonner), nøyaktighet og sikkerhet. [ 1 ]
AMQP fastsetter oppførselen til både serveren som leverer meldingene og meldingsklienten i den grad at implementeringer fra forskjellige leverandører virkelig er interoperable, på samme måte som SMTP , HTTP , FTP og lignende har skapt interoperable systemer. Andre tidligere forsøk på å standardisere mellomvare skjedde på API -nivå (for eksempel JMS ) og oppnådde ikke reell interoperabilitet. [ 2 ] I motsetning til JMS, som bare definerer et API, er AMQP en protokoll på trådnivå. En trådnivåprotokoll er en beskrivelse av formatet på data som sendes over nettverket som en strøm av oktetter . Følgelig kan ethvert program som kan lage og tolke meldinger som samsvarer med dette dataformatet samvirke med ethvert annet verktøy som samsvarer med denne protokollen, uavhengig av implementeringsspråket.
Utvikling
AMQP ble definert fra midten av 2004 til midten av 2006 av den amerikanske investeringsbanken JP Morgan Chase og iMatix Corporation , som også utviklet implementeringer i C / C++ og Java . JP Morgan Chase og iMatix dokumenterte protokollen som en interoperabel spesifikasjon og sendte den til en arbeidsgruppe som inkluderte Red Hat , Cisco Systems , TWIST , IONA og iMatix . Fra november 2009 består denne arbeidsgruppen av følgende selskaper: Bank of America , Barclays , Cisco Systems , Credit Suisse , Deutsche Börse Systems , Envoy Technologies, Inc., Goldman Sachs , Progress Software, iMatix Corporation, JPMorgan Chase Bank Inc. NA, Microsoft Corporation, Novell , Rabbit Technologies Ltd., Red Hat, Inc., Solace Systems , Tervela Inc. , TWIST Process Innovations ltd, WS02 og 29West Inc.
Et viktig designmål for AMQP var å oppnå opprettelsen av åpne standardprotokollstabler for bedriftsmeldinger, både innenfor samme organisasjon og mellom organisasjoner, ved å kombinere AMQP med en av de mange åpne standardene som beskriver forretningsmeldingstransaksjoner. eller mer generisk SOAP sikre transportprotokoller .
Selv om AMQP har sin opprinnelse i finansbransjen, kan den brukes på et bredt spekter av mellomvareproblemer.
AMQP-modellen
AMQP definerer en rekke enheter. Fra sammenkoblingsperspektivet er de mest relevante:
- Meldingsmegleren – En server som AMQP-klienter kobler til ved hjelp av AMQP-protokollen. Meldingsmeglere kan kjøre i et distribuert miljø, men denne muligheten er implementeringsspesifikk og dekkes ikke av spesifikasjonen.
- Bruker : En bruker er en enhet som, ved å presentere legitimasjon som et passord, kan (eller kanskje ikke) være autorisert til å koble til en megler.
- Tilkobling : en fysisk tilkobling som bruker for eksempel TCP/IP eller SCTP . En tilkobling er bundet til en bruker.
- Kanal - En logisk forbindelse som er bundet til en forbindelse. Dermed har kommunikasjon gjennom en kanal en tilstand. De klientene som utfører samtidige operasjoner gjennom samme tilkobling, må ha en annen kanal for hver av dem. De klientene som bruker en trådbasert modell for samtidighet kan for eksempel innkapsle kanaldeklarasjonen i en trådlokal variabel.
Enhetene som brukes til å sende og motta spesifikke meldinger er alle erklært innenfor en kanal. En erklæring garanterer for klienten som gjør det at enheten eksisterer (eller tidligere ble erklært av en annen klient). Ethvert forsøk på å erklære en navngitt enhet med andre egenskaper enn de den hadde da den ble erklært, resulterer i en feil. For å endre egenskapene til en navngitt enhet, må den først slettes før den opprettes på nytt.
Noen av disse enhetene er navngitt. Navnet må være unikt innenfor rammen av enheten og dens megler. Siden klienter vanligvis ikke har midler til å få en liste over alle tilgjengelige navngitte enheter (i det minste er det ingen slik operasjon definert i AMQP-spesifikasjonen), er det kunnskap om et enhetsnavn som lar klienten utføre operasjoner.
Navn bruker UTF-8-koding , må være mellom 1 og 255 tegn lange, og må begynne med et siffer, en bokstav eller understrek.
Vekslere
Utvekslerne er enhetene som meldingene sendes til. De har et navn så vel som en type og egenskaper som:
- passiv: veksleren vil ikke bli deklarert, men det vil oppstå en feil hvis den ikke eksisterer.
- varig: veksleren vil overleve en tilbakestilling av veksleren.
- auto-sletting: veksleren vil bli slettet så snart det ikke er flere køer knyttet til den. De vekslerne som aldri har hatt koblede køer vil aldri bli automatisk slettet.
Merk at vekslere er planlagt fjernet i AMQP/1.0.
Køer
Køer er enhetene som mottar meldinger. De har et navn og egenskaper, men ingen type. Kunder kan abonnere på køer, med den effekt at meldingsmegleren vil levere (via en push -mekanisme , dvs. aktivt av megleren) innholdet i køen til klienter. Alternativt kan klienter aktivt trekke meldinger fra køen etter eget ønske ( trekkmekanisme ).
Køen sørger for at meldinger leveres i samme rekkefølge som de ankom i køen; denne bestillingen er vanligvis kjent som FIFO . I noen tilfeller av omdirigering (for eksempel på grunn av en feil som involverer en omstart av megleren) er ikke denne bestillingen garantert.
Køegenskapene inkluderer:
- alternativ veksler: når en melding blir avvist av en abonnent eller blir foreldreløs på grunn av ødeleggelse av en kø, blir de omdirigert til en alternativ veksler og slettet fra denne køen.
- passiv: køen vil ikke bli deklarert, men en feil vil oppstå hvis den ikke eksisterer.
- varig: køen vil overleve en omstart av løperen.
- Eksklusivt: Det kan bare være én klient for denne spesifikke køen.
- automatisk sletting: køen vil bli slettet så snart det ikke er noen aktive abonnementer igjen for den. Denne egenskapen deler den samme begrensningen som egenskapen for automatisk sletting for vekslere: hvis ingen abonnement noen gang har vært aktiv for denne køen, vil den ikke bli automatisk slettet. En eksklusiv kø vil imidlertid alltid automatisk slettes når klienten logger ut.
Merk at køer forventes å erstatte vekslere i AMQP/1.0.
Meldinger
Meldingene har ikke noe navn og publiseres i en utveksler. De består av en overskrift og en innholdsdel. Mens brødteksten inneholder ugjennomsiktige data, inneholder overskriften en rekke valgfrie egenskaper:
- routing key ( routing-key ): Dette feltet brukes på forskjellige måter avhengig av type veksler.
- umiddelbar: Meldingen vil bli behandlet som urutbar hvis minst én av køene som skal motta meldingen ikke har noe abonnement.
- leveringsmåte: indikerer at en melding kan trenge holdbarhet. Bare for denne typen meldinger kan megleren gjøre et best mulig forsøk på å forhindre tap av meldingen før den konsumeres. Dersom det er usikkerhet på meglersiden om riktig mottak av meldingen (for eksempel ved feil), kan den valgfritt levere samme melding mer enn én gang. Ikke-vedvarende leveringsmodi viser ikke denne typen atferd.
- prioritet: en indikator (i området mellom 0 og 9) på at en melding har forrang over andre.
- expiration - Varigheten i millisekunder før megleren kan behandle meldingen som urutbar .
Linker
En binding er et forhold mellom en kø og en veksler som spesifiserer hvordan meldinger flyter fra veksleren til køen. Egenskapene til bindingen stemmer overens med rutingsalgoritmen som brukes i vekslerne. Bindinger (og veksleralgoritmer) kan bestilles på en skala fra minst til mest komplekse:
- Ubetinget: Bindingen har ingen egenskaper og krever alle meldinger fra veksleren.
- Betinget med en fast streng: Bindingen har én egenskap, rutingnøkkelen, og gjør krav på alle meldinger som har en identisk rutingnøkkel.
- Betinget med et samsvarende mønster: Bindingen har én egenskap, rutingnøkkelen, og krever alle meldinger som oppdages av en mønstertilpasningsalgoritme. Enhver vilkårlig mønstersyntaks kan brukes. AMQP implementerer emnegjenkjenning.
- Betinget med flere faste strenger: Bindingen har en tabell med egenskaper, argumentene , og gjenvinner alle meldinger hvis overskrifter samsvarer med disse argumentene, ved å bruke logiske OG- eller ELLER-operasjoner for å kombinere de forskjellige samsvarene.
- Betinget med en algoritmisk sammenligning: Bindingen tar et algoritmisk uttrykk (som en WHERE-klausul i en SELECT-setning i SQL ) og gjenvinner alle meldinger hvis overskrifter samsvarer med dette uttrykket.
- Betinget med innholdsinspeksjon: bindingen spesifiserer vilkårlige kriterier som bare kan løses ved å inspisere det faktiske innholdet i meldingen.
Ikke alle disse bindingene er implementert som standard, eller av alle implementeringer.
Typer vekslere og effekten av koblinger
Disse fire enhetene utgjør den grunnleggende modellen til AMQP. Nøkkelen til å forstå hvordan en melding sendes til en kø ligger i forholdet mellom vekslertypen og den resulterende tolkningen av rutenøkkelen.
En utveksler vil levere maksimalt én kopi av en gitt melding til en kø hvis rutenøkkelen i meldingen samsvarer med en binding (påfølgende semantisk identiske bindinger kan ikke resultere i dupliserte kopier av samme melding). Hva som utgjør en korrespondanse, er derimot utelukkende avhengig av typen veksler:
- en direkte veksler vurderer et samsvar når rutenøkkelen og bindingsnøkkelen er identiske.
- en fanout anser alltid det for å være en match, selv med nøkkelfrie bindinger.
- En utveksler med et definert emne ( emneutveksling ) vurderer et samsvar hvis rutenøkkelegenskapen til en melding samsvarer med nøkkelordene i en binding. Disse ordene er tegnstrenger atskilt med prikker. To ekstra tegn er også gyldige: stjernen "*", som samsvarer med 1 ord, og hashen "#", som samsvarer med 0 til N ord. For eksempel vil *.stock.# matche nøklene usd.stock og eur.stock.db , men ikke stock.nasdaq .
- en header-veksler vurderer at det er samsvar i nærvær av både nøkler og nøkkelverdi-par som kan kobles sammen med logiske OG- og ELLER-forbindelser i overskriften til en melding. I dette tilfellet er ikke rutingnøkkelen et samsvarskriterium som vurderes av veksleren. Bindingen inneholder heller ikke en enkelt rutenøkkel, men heller et spesielt format som inneholder overskriftsnøkler og/eller nøkkelverdi-par som skaper samsvar enten når overskriftsnøkkelen er tilstede eller når overskriftsnøkkelen og -verdien er til stede. .
Andre typer vekslere, f.eks. leverandørspesifikke, er eksplisitt tillatt i spesifikasjonen.
Konseptet med å koble navngitte køer med navngitte vekslere har kraftige egenskaper (mens kobling holder begge enhetene uavhengige av hverandre). Det er for eksempel mulig å koble en enkelt kø gjennom flere bindinger til en enkelt veksler, eller til flere. Eller flere forbrukere kan dele navnet på en kø og binde seg til den med de samme parameterne, og dermed bare få meldingene som de andre forbrukerne ikke har konsumert. Eller flere forbrukere kan erklære uavhengige køer, men deler de samme bindingene og dermed får alle beskjeden om at en annen forbruker ville ha fått på veksleren knyttet til disse bindingene.
Spesifikasjonsrevisjoner og fremtiden til AMQP
Følgende AMQP-protokollspesifikasjoner er publisert, i kronologisk rekkefølge:
- 0-8 i juni 2006
- 0-9 i desember 2006
- 0-10 (dokumenter har ingen dato)
- 0-9-1 i november 2008
- 1.0-utkast i mai 2010
- 1.0 finalen i oktober 2011
1.0-utkastet til spesifikasjonen endrer AMQP-modellen illustrert ovenfor ved å fjerne begrepene vekslere og bindinger, og erstatte dem med køer og lenker . Denne endringen tar sikte på å avhjelpe to problemer med den forrige tilnærmingen:
- Utgiveren trenger å vite mye om topologien til mottakeren (hvilke vekslere og typer vekslere er tilgjengelige).
- Produsentflytkontroll er komplekst: hvis en veksler ruter en melding til to forskjellige køer, en tom og den andre nesten full, hvilken flytkontrollinformasjon skal sendes til produsenten og hvordan skal den bestemmes?
Andre endringer inkluderer innføringen av en direkte køordning som ligner på e -post eller XMPP . Den hever forespørsler til første-ordens klasser , og tillater publisering av tjenesteplasseringsposter ved hjelp av DNS .
Implementeringer
Dette er AMQP-implementeringene som er offentlig tilgjengelige.
Megler og klient
- OpenAMQP , den originale åpen kildekode-implementeringen av AMQP, skrevet i C av iMatix. Det fungerer under Linux , AIX , Solaris , Windows og OpenVMS . Den inkluderer en megler, API-er for C/C++ og Java JMS, en ekstern administrasjonskonsoll, scripting, federation, failover og AMQP-over-HTTP som bruker RestMS -protokollen .
- AMQP Infrastructure , en yum - installerbar pakke som er AMQP 0-10-kompatibel og vedlikeholdt for de nyeste versjonene av Fedora. Det inkluderer megler, administrasjonsverktøy, agenter og klienter.
- Apache Qpid , et prosjekt fra Apache Software Foundation . Bindinger for mange språk unngår bruk av dynamiske biblioteker.
- Red Hat Enterprise MRG implementerer AMQP versjon 0-10, hvis utvalg av funksjoner inkluderer føderasjon, aktiv aktiv distribusjon ved bruk av Qpid som oppstrøms , en nettkonsoll og andre bedriftsorienterte funksjoner.
Kun løper
- RabbitMQ , en åpen kildekode frittstående implementering. Serveren er skrevet i Erlang og inkluderer også en referanseklient skrevet i Java.
- ZeroMQ , en meldingsplattform som er i stand til å behandle AMQP-meglere som noder i et distribuert meldingsnettverk. Den har bindinger til den underliggende implementeringen i C, så vel som til andre språk som Python, C++, Lisp, Ruby og andre.
- Zyre , en megler som implementerer RestMS og AMQP for å tillate REST-basert HTTP-tilgang til AMQP-nettverk.
Kun klient
Referanser
- ^ O'Hara, J. (2007). "Mot en mellomvare for en varebedrift" . ACM kø 5 : 48-55. doi : 10.1145/1255421.1255424 . Arkivert fra originalen 11. februar 2012 . Hentet 17. mai 2010 .
- ↑ Vinoski, S. (2006). Advanced Message Queuing Protocol . IEEE Internet Computing 10 : 87-89. doi : 10.1109/MIC.2006.116 . Arkivert fra originalen 7. februar 2009 . Hentet 4. oktober 2019 .
Eksterne lenker