AMQP 1.0 az Azure Service Bus és az Event Hubs protokoll útmutatójában

Az Advanced Message Queueing Protocol 1.0 egy szabványosított keretezési és átviteli protokoll az üzenetek két fél közötti aszinkron, biztonságos és megbízható átviteléhez. Ez az Azure Service Bus Messaging és az Azure Event Hubs elsődleges protokollja.

Az AMQP 1.0 olyan széles körű iparági együttműködés eredménye, amely köztes szoftvergyártókat, például a Microsoftot és a Red Hatot hozta össze, és számos üzenetkezelési köztesszoftver-felhasználó, például a JP Morgan Chase képviseli a pénzügyi szolgáltatási ágazatot. Az AMQP protokoll és a bővítmény specifikációinak technikai szabványosítási fóruma az OASIS, és nemzetközi szabványként iso/IEC 19494:2014 szabványként hivatalos jóváhagyást ért el.

Célok

Ez a cikk az AMQP 1.0 üzenetkezelési specifikáció alapfogalmait foglalja össze az OASIS AMQP Technical Committee által kifejlesztett bővítmény-specifikációk mentén, és ismerteti, hogyan valósítja meg és építi az Azure Service Bus ezeket a specifikációkat.

A cél az, hogy bármely olyan fejlesztő, aki bármilyen platformon használ bármilyen meglévő AMQP 1.0-ügyfélvermet, hogy az AMQP 1.0-n keresztül kommunikálhasson az Azure Service Bus szolgáltatással.

Az általános célú AMQP 1.0-s veremek, például az Apache Qpid Proton vagy a AMQP.NET Lite minden alapvető AMQP 1.0 protokollelemet implementálnak, például munkameneteket vagy hivatkozásokat. Ezek az alapvető elemek néha egy magasabb szintű API-val vannak burkolva; Az Apache Proton még kettőt is kínál, az imperatív Messenger API-t és a reaktív Reactor API-t.

A következő vitafórumban feltételezzük, hogy az AMQP-kapcsolatok, munkamenetek és kapcsolatok kezelését, valamint a keretátvitelek és a folyamatvezérlés kezelését az adott verem (például az Apache Proton-C) kezeli, és nem igényel sok figyelmet az alkalmazásfejlesztőktől. Absztraktív módon feltételezzük néhány API-primitív létezését, például a kapcsolódási képességet, valamint a küldő és a fogadó absztrakciós objektumainak valamilyen formáját, amely aztán valamilyen formában send() és receive() műveletekkel rendelkezik.

Az Azure Service Bus speciális képességeinek, például az üzenetböngészésnek vagy a munkamenetek kezelésének megvitatásakor ezeket a funkciókat AMQP-kifejezésekben ismertetjük, de a feltételezett API-absztrakción felül rétegzett pszeudo-implementációként is.

Mi az AMQP?

Az AMQP egy keretezési és átviteli protokoll. A keretezés azt jelenti, hogy olyan bináris adatfolyamok struktúráját biztosítja, amelyek a hálózati kapcsolat mindkét irányában áramlanak. A struktúra elhatárolást biztosít a kapcsolt felek között kicserélendő különböző adatblokkokhoz, úgynevezett keretekhez. Az átadási képességek biztosítják, hogy mindkét kommunikáló fél közös megegyezést alakítson ki arról, hogy mikor és mikor kell az átadásokat teljesnek tekinteni.

A néhány üzenetközvetítő által még használatban lévő AMQP-munkacsoport korábbi lejárt piszkozatverzióitól eltérően a munkacsoport végleges és szabványosított AMQP 1.0 protokollja nem írja elő az üzenetközvetítők vagy az üzenetközvetítőn belüli entitások adott topológiájának jelenlétét.

A protokoll használható szimmetrikus társközi kommunikációhoz, üzenetközvetítőkkel való interakcióhoz, amelyek támogatják az üzenetsorokat és közzéteszik/előfizetik az entitásokat, ahogyan az Azure Service Bus teszi. Az üzenetkezelési infrastruktúrával való interakcióhoz is használható, ahol az interakciós minták eltérnek a normál üzenetsoroktól, ahogyan az Azure Event Hubs esetében is. Az eseményközpontok üzenetsorként viselkednek, amikor eseményeket küldenek neki, de inkább soros tárolási szolgáltatásként viselkednek, amikor eseményeket olvasnak fel belőle; kissé hasonlít egy szalagos meghajtóra. Az ügyfél kiválaszt egy eltolást az elérhető adatfolyamba, majd az eltolástól a legújabb elérhetőig kiszolgálja az összes eseményt.

Az AMQP 1.0 protokollt bővíthetőre tervezték, így további specifikációk teszik lehetővé a képességeinek bővítését. A dokumentumban tárgyalt három bővítményspecifikáció ezt szemlélteti. A meglévő HTTPS/WebSockets-infrastruktúra közötti kommunikációhoz a natív AMQP TCP-portok konfigurálása nehézkes lehet. A kötési specifikáció meghatározza, hogyan rétegzendő az AMQP a WebSocket-eken keresztül. Az üzenetkezelési infrastruktúrával való kommunikációhoz a kérések/válaszok kezelési célokra vagy a speciális funkciók biztosításához az AMQP felügyeleti specifikációja határozza meg a szükséges alapvető interakciós primitív elemeket. Az összevont engedélyezési modell integrációjához az AMQP jogcímalapú biztonsági specifikációja határozza meg, hogyan társíthatók és újíthatók meg a hivatkozásokkal társított engedélyezési jogkivonatok.

Alapszintű AMQP-forgatókönyvek

Ez a szakasz az AMQP 1.0 és az Azure Service Bus alapszintű használatát ismerteti, amely magában foglalja a kapcsolatok, munkamenetek és hivatkozások létrehozását, valamint az üzenetek Service Bus-entitások, például üzenetsorok, témakörök és előfizetések közötti átvitelét.

Az AMQP működésének megismeréséhez a leg mérvadóbb forrás az AMQP 1.0 specifikációja, de a specifikációt úgy írták, hogy pontosan irányítsa a megvalósítást, és ne tanítsa meg a protokollt. Ez a szakasz az AMQP 1.0 használatának leírásához szükséges terminológiát mutatja be. Az AMQP átfogóbb bemutatása és az AMQP 1.0 szélesebb körű megvitatása érdekében tekintse át ezt a videós kurzust.

Csatlakozás és munkamenetek

Az AMQP meghívja a kommunikáló programok tárolóit; ezek csomópontokat tartalmaznak, amelyek a tárolókon belüli kommunikációs entitások. Az üzenetsor lehet ilyen csomópont. Az AMQP lehetővé teszi a multiplexálást, így egyetlen kapcsolat használható a csomópontok közötti számos kommunikációs útvonalhoz; Egy alkalmazásügyfél például egyidejűleg fogadhat egy üzenetsort, és ugyanazon a hálózati kapcsolaton keresztül küldhet egy másik üzenetsort.

A hálózati kapcsolat így a tárolón van rögzítve. Ezt az ügyfélszerepkör tárolója kezdeményezi, amely kimenő TCP-szoftvercsatorna-kapcsolatot létesít a fogadó szerepkörben lévő tárolóval, amely figyeli és fogadja a bejövő TCP-kapcsolatokat. A kapcsolati kézfogás magában foglalja a protokoll verziójának tárgyalását, a Transport Level Security (TLS/SSL) használatának deklarálását vagy tárgyalását, valamint a SASL-en alapuló hitelesítési/engedélyezési kézfogást.

Az Azure Service Bus vagy az Azure Event Hubs mindig megköveteli a TLS használatát. Támogatja az 5671-es TCP-porton keresztüli kapcsolatokat, így a TCP-kapcsolat először a TLS-sel van átfedésben, mielőtt belép az AMQP protokoll kézfogásába, és támogatja az 5672-es TCP-porton keresztüli kapcsolatokat is, amelyek során a kiszolgáló azonnal felajánlja a TLS-kapcsolat kötelező frissítését az AMQP által előírt modell használatával. Az AMQP WebSockets-kötés létrehoz egy alagutat a 443-es TCP-porton keresztül, amely ezután egyenértékű az AMQP 5671-kapcsolatokkal.

A kapcsolat és a TLS beállítása után a Service Bus két SASL-mechanizmust kínál:

• A SASL PLAIN-t gyakran használják a felhasználónév és a jelszó hitelesítő adatainak kiszolgálónak való átadásához. A Service Bus nem rendelkezik fiókokkal, hanem megosztott hozzáférésű biztonsági szabályokkal, amelyek jogosultságokat biztosítanak, és kulcshoz vannak társítva. A rendszer a szabály nevét használja felhasználónévként, a kulcs (base64 kódolású szövegként) pedig jelszóként. A kiválasztott szabályhoz társított jogok szabályozzák a kapcsolaton engedélyezett műveleteket.
• A SASL ANONYMOUS a SASL-engedélyezés megkerülésére szolgál, ha az ügyfél a később ismertetett jogcímalapú biztonsági (CBS) modellt szeretné használni. Ezzel a lehetőséggel egy ügyfélkapcsolatot névtelenül lehet létrehozni egy rövid ideig, amely során az ügyfél csak a CBS-végponttal tud kommunikálni, és a CBS kézfogásának befejeződnie kell.

Az átviteli kapcsolat létrejötte után a tárolók mindegyike deklarálja a maximális keretméretet, amelyet hajlandóak kezelni, és tétlen időtúllépés után egyoldalúan megszakítják a kapcsolatot, ha nincs tevékenység a kapcsolaton.

Azt is deklarálják, hogy hány egyidejű csatorna támogatott. A csatorna egy egyirányú, kimenő virtuális átviteli útvonal a kapcsolat tetején. A munkamenetek az egyes összekapcsolt tárolók csatornáját választva kétirányú kommunikációs útvonalat alkotnak.

A munkamenetek ablakalapú folyamatvezérlési modellel rendelkeznek; amikor létrejön egy munkamenet, mindegyik fél deklarálja, hogy hány keretet hajlandó elfogadni a fogadási ablakban. Ahogy a felek kereteket cserélnek, az átvitt keretek kitöltik az ablakot, és az átvitelek leállnak, amikor az ablak megtelik, és amíg az ablak alaphelyzetbe nem áll vagy ki nem bővül a folyamat performatív használatával (a performatív a két fél között kicserélt protokollszintű kézmozdulatok AMQP-kifejezése).

Ez az ablakalapú modell nagyjából hasonló az ablakalapú folyamatvezérlés TCP-koncepciójához, de a szoftvercsatornán belüli munkamenet szintjén. A protokoll azon koncepciója, hogy több egyidejű munkamenetet is lehetővé tesz, hogy a magas prioritású forgalom a szabályozott normál forgalomon haladjon át, például egy gyorsforgalmi sávon.

Az Azure Service Bus jelenleg pontosan egy munkamenetet használ minden kapcsolathoz. A Service Bus maximális keretmérete 262 144 bájt (256 K bájt) a Service Bus Standard esetében. A Service Bus Premium és az Event Hubs 1048576 (100 MB). A Service Bus nem ír elő munkamenetszintű szabályozást, de a kapcsolatszintű folyamatvezérlés részeként rendszeresen alaphelyzetbe állítja az ablakot (lásd a következő szakaszt).

Csatlakozás, csatornák és munkamenetek rövid élettartamúak. Ha a mögöttes kapcsolat összeomlik, a kapcsolatokat, a TLS-alagutat, az SASL-engedélyezési környezetet és a munkameneteket újra létre kell tenni.

AMQP kimenő portra vonatkozó követelmények

Az AMQP-kapcsolatokat TCP-n keresztül használó ügyfeleknek az 5671-es és az 5672-es portot kell megnyitniuk a helyi tűzfalon. Ezen portok mellett szükség lehet további portok megnyitására is, ha az EnableLinkRedirect funkció engedélyezve van. EnableLinkRedirect egy új üzenetkezelési funkció, amely segít kihagyni az egy ugrást az üzenetek fogadása közben, ezáltal segít növelni az átviteli sebességet. Az ügyfél közvetlenül a háttérszolgáltatással kezdene kommunikálni az 104XX porttartományon keresztül, ahogy az alábbi képen látható.

A .NET-ügyfél a SocketException (A szoftvercsatornák hozzáférési engedélyei által tiltott módon történő elérésére tett kísérlet) meghiúsulna, ha ezeket a portokat a tűzfal blokkolja. A funkció letiltható a kapcsolati sztring beállításávalEnableAmqpLinkRedirect=false, amely arra kényszeríti az ügyfeleket, hogy kommunikáljanak a távoli szolgáltatással az 5671-s porton keresztül.

Az AMQP WebSocket kötés egy AMQP-kapcsolat WebSocket-átvitelen keresztüli bújtatására szolgáló mechanizmust biztosít. Ez a kötés létrehoz egy alagutat a 443-es TCP-porton keresztül, amely egyenértékű az AMQP 5671-kapcsolatokkal. AmQP WebSocketeket akkor használjon, ha olyan tűzfal mögött van, amely blokkolja a TCP-kapcsolatokat az 5671-es és az 5672-es porton keresztül, de engedélyezi a TCP-kapcsolatokat a 443-es porton (https).

Hivatkozások

Az AMQP hivatkozásokkal továbbítja az üzeneteket. A hivatkozás egy munkameneten keresztül létrehozott kommunikációs útvonal, amely lehetővé teszi az üzenetek egyirányú átvitelét; az átadási állapot egyeztetése a kapcsolt felek közötti kapcsolaton és kétirányú kapcsolaton keresztül történik.

A hivatkozásokat bármelyik tároló bármikor létrehozhatja egy meglévő munkameneten keresztül, így az AMQP különbözik számos más protokolltól, például a HTTP-től és az MQTT-től, ahol az átvitelek és az átviteli útvonal kezdeményezése a szoftvercsatorna-kapcsolatot létrehozó fél kizárólagos jogosultsága.

A hivatkozás-kezdeményező tároló arra kéri az ellenkező tárolót, hogy fogadja el a hivatkozást, és kiválasztja a feladó vagy a fogadó szerepkörét. Ezért bármelyik tároló kezdeményezhet egyirányú vagy kétirányú kommunikációs útvonalakat, az utóbbi pedig hivatkozáspárként van modellezve.

A hivatkozások el vannak nevezve és csomópontokhoz vannak társítva. Az elején leírtak szerint a csomópontok a tárolón belüli kommunikáló entitások.

A Service Busban a csomópontok közvetlenül egyenértékűek egy üzenetsorsal, egy témakörrel, egy előfizetéssel vagy egy üzenetsor vagy előfizetés deadletter-allekérdezésével. Az AMQP-ben használt csomópontnév tehát a Service Bus-névtéren belüli entitás relatív neve. Ha egy üzenetsor neve el van nevezve myqueue, akkor az AMQP-csomópont neve is. A témakör-előfizetések a HTTP API konvencióját követik úgy, hogy egy "előfizetések" erőforráscsoportba vannak rendezve, így a mytopic témakör előfizetési almappája az AMQP-csomópont neve mytopic/subscriptions/sub.

A kapcsolódási ügyfélnek helyi csomópontnevet is kell használnia a hivatkozások létrehozásához; A Service Bus nem ír előírást ezekről a csomópontnevekről, és nem értelmezi őket. Az AMQP 1.0-ügyfélveremek általában egy sémát használnak annak biztosítására, hogy ezek a rövid élettartamú csomópontnevek egyediek legyenek az ügyfél hatókörében.

Átadások

A hivatkozás létrehozása után az üzenetek továbbíthatók a hivatkozáson keresztül. Az AMQP-ben az átvitel explicit protokollos kézmozdulattal (az átadási teljesítménnyel) történik, amely egy üzenetet a feladótól a fogadóba helyez át egy hivatkozáson keresztül. Az átadás akkor fejeződik be, ha az "kiegyenlített", ami azt jelenti, hogy mindkét fél közösen értelmezte az átadás eredményét.

A legegyszerűbb esetben a feladó dönthet úgy, hogy "előre kiegyenlített" üzeneteket küld, ami azt jelenti, hogy az ügyfél nem érdekli az eredményt, és a fogadó nem ad visszajelzést a művelet eredményéről. Ezt a módot a Service Bus az AMQP protokoll szintjén támogatja, de egyik ügyfél API-ban sem teszi közzé.

A szokásos eset az, hogy az üzeneteket a rendszer rendezetlenül küldi el, és a fogadó ezután a diszpozícióval történő elfogadást vagy elutasítást jelzi. Az elutasítás akkor fordul elő, ha a fogadó semmilyen okból nem tudja elfogadni az üzenetet, és az elutasítási üzenet információkat tartalmaz az okról, ami az AMQP által definiált hibastruktúra. Ha az üzeneteket a Service Bus belső hibái miatt utasítják el, a szolgáltatás a struktúrán belül további információkat ad vissza, amelyek diagnosztikai tippeket nyújtanak a támogatási személyzetnek, ha támogatási kérelmeket nyújt be. Később további részleteket tudhat meg a hibákról.

Az elutasítás különleges formája a felszabadított állapot, amely azt jelzi, hogy a fogadónak nincs technikai kifogása az átadás ellen, de az átadás rendezése sem érdekelt. Ez az eset például akkor áll fenn, ha egy üzenet egy Service Bus-ügyfélnek érkezik, és az ügyfél úgy dönt, hogy "megszakítja" az üzenetet, mert nem tudja elvégezni az üzenet feldolgozásából eredő munkát; maga az üzenetkézbesítés nem hibás. Ennek az állapotnak egy változata a módosított állapot, amely lehetővé teszi az üzenet módosítását a kiadáskor. A Service Bus jelenleg nem használja ezt az állapotot.

Az AMQP 1.0 specifikációja egy további, fogadottnak nevezett elhelyezési állapotot határoz meg, amely kifejezetten segít kezelni a kapcsolat helyreállítását. A kapcsolat helyreállítása lehetővé teszi a kapcsolat és a függőben lévő kézbesítések állapotának újbóli helyreállítását egy új kapcsolat és munkamenet tetején, amikor a korábbi kapcsolat és munkamenet megszakadt.

A Service Bus nem támogatja a csatolások helyreállítását; ha az ügyfél megszakad a Service Bushoz való kapcsolat egy lezáratlan üzenettovábbítás függőben, az üzenetátvitel elveszik, és az ügyfélnek újra kell kapcsolódnia, újra létre kell tennie a hivatkozást, és újra meg kell próbálkoznia az átvitelsel.

Ezért a Service Bus és az Event Hubs támogatja a "legalább egyszer" átvitelt, ahol a feladó biztos lehet abban, hogy az üzenet tárolása és elfogadása megtörtént, de nem támogatja a "pontosan egyszer" átvitelt az AMQP szintjén, ahol a rendszer megpróbálja helyreállítani a hivatkozást, és folytatja a kézbesítési állapot egyeztetését az üzenetátvitel duplikációjának elkerülése érdekében.

A lehetséges ismétlődő küldések kompenzálása érdekében a Service Bus támogatja a duplikált észlelést opcionális funkcióként az üzenetsorokon és témakörökben. A duplikált észlelés rögzíti az összes bejövő üzenet üzenetazonosítóját egy felhasználó által megadott időablakban, majd csendesen elveti az azonos üzenetazonosítókkal küldött üzeneteket ugyanazon az ablakban.

Folyamatvezérlés

A korábban tárgyalt munkamenetszintű folyamatvezérlési modell mellett minden hivatkozás saját folyamatvezérlési modellel is rendelkezik. A munkamenetszintű folyamatvezérlés megvédi a tárolót attól, hogy egyszerre túl sok képkockát kelljen kezelnie, a kapcsolatszintű folyamatvezérlés pedig az alkalmazást helyezi a felelősként arra, hogy hány üzenetet szeretne kezelni egy hivatkozásból és mikor.

Egy hivatkozáson az átvitel csak akkor történhet meg, ha a feladónak elegendő hivatkozási kreditje van. A hivatkozás kreditje egy számláló, amelyet a fogadó állít be a folyamat performatív használatával, amely egy hivatkozás hatókörébe tartozik. Amikor a feladó hivatkozási kreditet kap, az üzenetek kézbesítésével megkísérli felhasználni ezt a kreditet. Minden üzenetkézbesítés 1-gyel csökkeni a fennmaradó hivatkozási kreditet. Amikor a hivatkozás jóváírása fel van használva, a szállítások leállnak.

Ha a Service Bus a fogadó szerepkörben van, azonnal elegendő hivatkozási kreditet biztosít a feladónak, hogy az üzenetek azonnal elküldhetők legyenek. A hivatkozási kreditek használata esetén a Service Bus időnként teljesíthető folyamatot küld a feladónak a hivatkozás kreditegyenlegének frissítéséhez.

A feladói szerepkörben a Service Bus üzeneteket küld a függőben lévő hivatkozási kreditek felhasználásához.

Az API-szinten egy "fogadási" hívás olyan folyamat-teljesítményre vált, amelyet az ügyfél a Service Busnak küld, és a Service Bus felhasználja ezt a kreditet az első elérhető, feloldott üzenet üzenetsorból való felvételével, zárolásával és átvitelével. Ha nem áll rendelkezésre könnyen elérhető üzenet a kézbesítéshez, az adott entitással létesített bármely kapcsolaton belül fennálló jóváírások érkezési sorrendben lesznek rögzítve, és az üzeneteket az elérhetővé válásukkor zárolják és továbbítják, hogy felhasználhassák a fennálló krediteket.

Az üzenet zárolása akkor szabadul fel, ha az átvitel az elfogadott, elutasított vagy felszabadított terminálállapotok egyikébe kerül. Az üzenet a terminálállapot elfogadásakor törlődik a Service Busból. A Service Busban marad, és a következő fogadóhoz lesz kézbesítve, amikor az átvitel bármely más állapotba ér. A Service Bus automatikusan áthelyezi az üzenetet az entitás holtlejárati üzenetsorába, amikor eléri az entitás számára engedélyezett maximális kézbesítési számot ismétlődő elutasítások vagy kiadások miatt.

Annak ellenére, hogy a Service Bus API-k jelenleg nem teszik elérhetővé közvetlenül ezt a lehetőséget, egy alacsonyabb szintű AMQP protokollügyfél a hivatkozás-jóváírási modell használatával a "lekéréses stílusú" interakciót az egyes fogadási kérelmekhez egy "leküldéses stílusú" modellté alakíthatja azáltal, hogy nagy számú hivatkozási kreditet bocsát ki, majd további beavatkozás nélkül fogad üzeneteket, amint elérhetővé válnak. A leküldés a ServiceBusProcessor.PrefetchCount vagy a ServiceBusReceiver.PrefetchCount tulajdonságbeállításokon keresztül támogatott. Ha nem nulla, az AMQP-ügyfél hivatkozási kreditként használja.

Ebben az összefüggésben fontos tisztában lenni azzal, hogy az entitáson belüli üzenet zárolásának lejárati ideje akkor kezdődik, amikor az üzenet az entitásból származik, és nem akkor, amikor az üzenet a vezetékre kerül. Amikor az ügyfél arra utal, hogy készen áll az üzenetek fogadására hivatkozási kredit kiállításával, várhatóan aktívan leküldi az üzeneteket a hálózaton, és készen áll az üzenetek kezelésére. Ellenkező esetben előfordulhat, hogy az üzenet zárolása lejárt az üzenet kézbesítése előtt. A hivatkozás-jóváírási folyamat vezérlésének közvetlenül tükröznie kell a fogadónak küldött elérhető üzenetek kezelésére való azonnali készenlétet.

Összefoglalva, a következő szakaszok sémaszerű áttekintést nyújtanak a különböző API-interakciók során végzett performatív folyamatról. Minden szakasz egy másik logikai műveletet ír le. Néhány ilyen interakció lehet "lusta", ami azt jelenti, hogy csak szükség esetén hajthatók végre. Előfordulhat, hogy az üzenetküldő létrehozása nem okoz hálózati interakciót az első üzenet elküldéséig vagy kéréséig.

A következő táblázatban látható nyilak a teljesítményfolyamat irányát mutatják.

Üzenet fogadó létrehozása

Client	Service Bus
--> attach(<br/>name={link name},<br/>handle={numeric handle},<br/>role=**receiver**,<br/>source={entity name},<br/>target={client link ID}<br/>)	Az ügyfél fogadóként csatolja az entitást
A Service Bus válaszai a hivatkozás végét csatolják	<-- attach(<br/>name={link name},<br/>handle={numeric handle},<br/>role=**sender**,<br/>source={entity name},<br/>target={client link ID}<br/>)

Üzenetküldő létrehozása

Client	Service Bus
--> attach(<br/>name={link name},<br/>handle={numeric handle},<br/>role=**sender**,<br/>source={client link ID},<br/>target={entity name}<br/>)	Nincs művelet
Nincs művelet	<-- attach(<br/>name={link name},<br/>handle={numeric handle},<br/>role=**receiver**,<br/>source={client link ID},<br/>target={entity name}<br/>)

Üzenetküldő létrehozása (hiba)

Client	Service Bus
--> attach(<br/>name={link name},<br/>handle={numeric handle},<br/>role=**sender**,<br/>source={client link ID},<br/>target={entity name}<br/>)	Nincs művelet
Nincs művelet	<-- attach(<br/>name={link name},<br/>handle={numeric handle},<br/>role=**receiver**,<br/>source=null,<br/>target=null<br/>)<br/><br/><-- detach(<br/>handle={numeric handle},<br/>closed=**true**,<br/>error={error info}<br/>)

Üzenet fogadó/feladó bezárása

Client	Service Bus
--> detach(<br/>handle={numeric handle},<br/>closed=**true**<br/>)	Nincs művelet
Nincs művelet	<-- detach(<br/>handle={numeric handle},<br/>closed=**true**<br/>)

Küldés (sikeres)

Client	Service Bus
--> transfer(<br/>delivery-id={numeric handle},<br/>delivery-tag={binary handle},<br/>settled=**false**,,more=**false**,<br/>state=**null**,<br/>resume=**false**<br/>)	Nincs művelet
Nincs művelet	<-- disposition(<br/>role=receiver,<br/>first={delivery ID},<br/>last={delivery ID},<br/>settled=**true**,<br/>state=**accepted**<br/>)

Küldés (hiba)

Client	Service Bus
--> transfer(<br/>delivery-id={numeric handle},<br/>delivery-tag={binary handle},<br/>settled=**false**,,more=**false**,<br/>state=**null**,<br/>resume=**false**<br/>)	Nincs művelet
Nincs művelet	<-- disposition(<br/>role=receiver,<br/>first={delivery ID},<br/>last={delivery ID},<br/>settled=**true**,<br/>state=**rejected**(<br/>error={error info}<br/>)<br/>)

Fogadás

Client	Service Bus
--> flow(<br/>link-credit=1<br/>)	Nincs művelet
Nincs művelet	< transfer(<br/>delivery-id={numeric handle},<br/>delivery-tag={binary handle},<br/>settled=**false**,<br/>more=**false**,<br/>state=**null**,<br/>resume=**false**<br/>)
--> disposition(<br/>role=**receiver**,<br/>first={delivery ID},<br/>last={delivery ID},<br/>settled=**true**,<br/>state=**accepted**<br/>)	Nincs művelet

Több üzenet fogadása

Client	Service Bus
--> flow(<br/>link-credit=3<br/>)	Nincs művelet
Nincs művelet	< transfer(<br/>delivery-id={numeric handle},<br/>delivery-tag={binary handle},<br/>settled=**false**,<br/>more=**false**,<br/>state=**null**,<br/>resume=**false**<br/>)
Nincs művelet	< transfer(<br/>delivery-id={numeric handle+1},<br/>delivery-tag={binary handle},<br/>settled=**false**,<br/>more=**false**,<br/>state=**null**,<br/>resume=**false**<br/>)
Nincs művelet	< transfer(<br/>delivery-id={numeric handle+2},<br/>delivery-tag={binary handle},<br/>settled=**false**,<br/>more=**false**,<br/>state=**null**,<br/>resume=**false**<br/>)
--> disposition(<br/>role=receiver,<br/>first={delivery ID},<br/>last={delivery ID+2},<br/>settled=**true**,<br/>state=**accepted**<br/>)	Nincs művelet

Üzenetek

A következő szakaszok ismertetik, hogy a Standard AMQP üzenetszakaszok mely tulajdonságait használja a Service Bus, és hogyan vannak megfeleltetve a Service Bus API-készletnek.

Az alkalmazás által definiálandó összes tulajdonságot le kell képezni az AMQP térképére application-properties .

header

Mező neve	Usage	API neve
Tartós	-	-
Prioritás	-	-
ttl	Itt az ideje, hogy megélje ezt az üzenetet	TimeToLive
első beszerző	-	-
kézbesítések száma	-	DeliveryCount

tulajdonságok

Mező neve	Usage	API neve
üzenetazonosító	Az üzenet alkalmazás által definiált, szabad formátumú azonosítója. Duplikált észleléshez használatos.	MessageId
felhasználó-azonosító	Alkalmazás által definiált felhasználói azonosító, amelyet a Service Bus nem értelmez.	Nem érhető el a Service Bus API-val.
felhasználóként a(z)	Alkalmazás által definiált célazonosító, amelyet a Service Bus nem értelmez.	Ide:
tárgy	Alkalmazás által definiált üzenet célazonosítója, amelyet a Service Bus nem értelmez.	Tárgy
válasz	Alkalmazás által definiált válaszútmutató, amelyet a Service Bus nem értelmez.	Válasz
korrelációs azonosító	Alkalmazás által definiált korrelációs azonosító, amelyet a Service Bus nem értelmez.	Korrelációs azonosító
tartalomtípus	A törzs alkalmazás által definiált tartalomtípus-jelzője, amelyet a Service Bus nem értelmez.	ContentType
tartalomkódolás	A törzs alkalmazás által definiált tartalomkódolási jelzője, amelyet a Service Bus nem értelmez.	Nem érhető el a Service Bus API-val.
abszolút lejárati idő	Deklarálja, hogy az üzenet mely időpontban jár le. A bemeneten figyelmen kívül hagyva (a fejléc TTL-je figyelhető meg), mérvadó a kimeneten.	Nem érhető el a Service Bus API-val.
létrehozási idő	Deklarálja, hogy mikor jött létre az üzenet. A Service Bus nem használja	Nem érhető el a Service Bus API-val.
csoportazonosító	Alkalmazás által definiált azonosító egy kapcsolódó üzenetkészlethez. Service Bus-munkamenetekhez használatos.	Munkamenet
csoportütemezés	A munkameneten belüli üzenet relatív sorszámát azonosító számláló. A Service Bus figyelmen kívül hagyja.	Nem érhető el a Service Bus API-val.
válasz-csoportazonosító	-	ReplyToSessionId

Üzenetjegyzetek

Kevés más service bus üzenettulajdonság létezik, amelyek nem részei az AMQP üzenettulajdonságainak, és az üzeneten szereplő MessageAnnotations módon kerülnek továbbításra.

Széljegyzet térképkulcsa	Usage	API neve
x-opt-scheduled-enqueue-time	Deklarálja, hogy mikor jelenjen meg az üzenet az entitáson	ScheduledEnqueueTime
x-opt-partition-key	Alkalmazás által definiált kulcs, amely meghatározza, hogy az üzenet mely partíciójában kell landolnia.	PartitionKey
x-opt-via-partition-key	Alkalmazás által definiált partíciókulcs-érték, ha tranzakcióval szeretne üzeneteket küldeni egy átviteli üzenetsoron keresztül.	TransactionPartitionKey
x-opt-enqueued-time	Szolgáltatás által definiált UTC idő, amely az üzenet lekérdezésének tényleges időpontját jelöli. A bemenet figyelmen kívül hagyva.	EnqueuedTime
x-opt-sequence-number	Szolgáltatás által definiált egyedi szám, amely egy üzenethez van hozzárendelve.	SequenceNumber
x-opt-offset	Az üzenet szolgáltatás által definiált, enqueued sorszáma.	EnqueuedSequenceNumber
x-opt-locked-until	Szolgáltatás által definiált. Az a dátum és idő, amelyig az üzenet zárolva lesz az üzenetsorban/előfizetésben.	LockedUntil
x-opt-deadletter-source	Szolgáltatás által definiált. Ha az üzenet a kézbesítetlen levelek üzenetsorából érkezik, az az eredeti üzenet forrását jelöli.	DeadLetterSource

Tranzakciós képesség

Egy tranzakció két vagy több műveletet kapcsol össze egyetlen végrehajtási hatókörbe. Egy ilyen tranzakciónak természete szerint biztosítania kell, hogy egy adott műveletcsoporthoz tartozó összes művelet sikeres legyen, vagy közösen meghiúsuljon. A műveletek egy azonosító txn-idszerint vannak csoportosítva.

Tranzakciós interakció esetén az ügyfél transaction controller a csoportosítandó műveleteket vezérli. A Service Bus Service a transactional resourcetransaction controller.

Az ügyfél és a szolgáltatás egy control link , az ügyfél által létrehozott kapcsolaton keresztül kommunikál. discharge A declare vezérlő a vezérlő hivatkozáson keresztül küldi el az üzeneteket a tranzakciók lefoglalásához és befejezéséhez (nem a tranzakciós munka elhatárolását jelölik). A tényleges küldés/fogadás nem ezen a hivatkozáson történik. Minden kért tranzakciós művelet kifejezetten a kívánt txn-id módon van azonosítva, ezért előfordulhat a Csatlakozás ion bármely hivatkozásán. Ha a vezérlőhivatkozás bezárul, miközben léteznek nem mentesített tranzakciók, akkor az összes ilyen tranzakció azonnal vissza lesz vonva, és a további tranzakciós műveletek végrehajtása sikertelen lesz. A vezérlőhivatkozáson lévő üzeneteket nem szabad előre rendezni.

Minden kapcsolatnak saját vezérlőhivatkozást kell kezdeményeznie a tranzakciók elindításához és befejezéséhez. A szolgáltatás egy speciális célértéket határoz meg, amely coordinatora . Az ügyfél/vezérlő létrehoz egy vezérlőhivatkozást ehhez a célhoz. A vezérlőhivatkozás egy entitás határain kívül esik, vagyis ugyanaz a vezérlőhivatkozás használható tranzakciók több entitáshoz történő kezdeményezéséhez és levezetéséhez.

Tranzakció indítása

A tranzakciós munka megkezdéséhez. az adatkezelőnek be kell szereznie a txn-id koordinátortól. Ezt egy declare típusüzenet küldésével teszi meg. Ha a deklaráció sikeres, a koordinátor egy elhelyezési eredménnyel válaszol, amely a hozzárendelt txn-ideredményt hordozza.

Ügyfél (vezérlő)	Direction	Service Bus (koordinátor)
csatolás( name={link name}, ... , role=sender, target=Koordinátor )	------>
	<------	csatolás( name={link name}, ... , target=Coordinator() )
átadás( delivery-id=0, ...) { AmqpValue (Deklarál())}	------>
	<------	diszpozíció( first=0, last=0, state=Deklarált( txn-id={transaction ID} ))

Tranzakció kiürítése

Az adatkezelő a tranzakciós munkát úgy zárja le, hogy üzenetet küld discharge a koordinátornak. A vezérlő jelzi, hogy véglegesíteni vagy vissza kívánja állítani a tranzakciós munkát a fail mentesítési törzs jelölőjének beállításával. Ha a koordinátor nem tudja befejezni a mentesítést, a rendszer ezzel az eredménnyel elutasítja az transaction-errorüzenetet.

Megjegyzés: a fail=true egy tranzakció visszaállítására, a fail=false pedig a Véglegesítésre hivatkozik.

Ügyfél (vezérlő)	Direction	Service Bus (koordinátor)
átadás( delivery-id=0, ...) { AmqpValue (Deklarál())}	------>
	<------	diszpozíció( first=0, last=0, state=Deklarált( txn-id={transaction ID} ))
	. . . Tranzakciós munka egyéb hivatkozásokon . . .
átadás( delivery-id=57, ...) { AmqpValue ( Kisülés(txn-id=0; fail=false)}}	------>
	<------	diszpozíció( first=57, last=57, state=Accepted())

Üzenet küldése tranzakcióban

Minden tranzakciós munka a txn-azonosítót tartalmazó tranzakciós kézbesítési állapottal transactional-state történik. Üzenetek küldésekor a tranzakciós állapotot az üzenet átviteli kerete hordozza.

Ügyfél (vezérlő)	Direction	Service Bus (koordinátor)
átadás( delivery-id=0, ...) { AmqpValue (Deklarál())}	------>
	<------	diszpozíció( first=0, last=0, state=Deklarált( txn-id={transaction ID} ))
átadás( handle=1, delivery-id=1, state= TransactionalState( txn-id=0)) { hasznos adat }	------>
	<------	diszpozíció( first=1, last=1, state=TransactionalState( txn-id=0, outcome=Accepted()))

Üzenet törlése tranzakcióban

Az üzeneteloszlás olyan műveleteket tartalmaz, mint a CompleteDeadLetter / DeferAbandon / / . Ha ezeket a műveleteket egy tranzakción belül szeretné végrehajtani, adja át a transactional-state véglegesítést.

Ügyfél (vezérlő)	Direction	Service Bus (koordinátor)
átadás( delivery-id=0, ...) { AmqpValue (Deklarál())}	------>
	<------	diszpozíció( first=0, last=0, state=Deklarált( txn-id={transaction ID} ))
	<------	átadás( handle=2, delivery-id=11, state=null) { hasznos adat }
diszpozíció( first=11, last=11, state=TransactionalState( txn-id=0, outcome=Accepted()))	------>

Speciális Service Bus-képességek

Ez a szakasz az Azure Service Bus speciális képességeit ismerteti, amelyek az AMQP-hez készült vázlatkiterjesztéseken alapulnak, és jelenleg az AMQP-hez készült OASIS Műszaki Bizottságban fejlesztik. A Service Bus implementálja a piszkozatok legújabb verzióit, és bevezeti azokat a módosításokat, amelyeket a piszkozatok standard állapotának elérésekor vezetnek be.

Megjegyzés:

A Service Bus-üzenetkezelés speciális műveleteit kérés-/válaszminta támogatja. Ezeknek a műveleteknek a részleteit az AMQP 1.0 a Service Busban: request-response-based operations című cikkben ismertetjük.

AMQP-felügyelet

Az AMQP felügyeleti specifikációja az első a cikkben tárgyalt vázlatkiterjesztések közül. Ez a specifikáció az AMQP protokollra rétegzett protokollkészletet határoz meg, amely lehetővé teszi az üzenetkezelési infrastruktúrával az AMQP-n keresztüli felügyeleti interakciókat. A specifikáció általános műveleteket határoz meg, például létrehozást, olvasást, frissítést és törlést az üzenetkezelési infrastruktúrán belüli entitások kezeléséhez, valamint lekérdezési műveletek készletéhez.

Ezek a kézmozdulatok megkövetelik az ügyfél és az üzenetkezelési infrastruktúra közötti kérés-válasz interakciót, ezért a specifikáció meghatározza, hogyan modellezhető ez az interakciós minta az AMQP-n: az ügyfél csatlakozik az üzenetkezelési infrastruktúrához, munkamenetet kezdeményez, majd létrehoz egy pár hivatkozást. Az egyik hivatkozáson az ügyfél küldőként, a másikon fogadóként működik, így kétirányú csatornaként működő hivatkozáspárokat hoz létre.

Logikai művelet	Client	Service Bus
Kérelem válaszútvonalának létrehozása	--> attach(<br/>name={*link name*},<br/>handle={*numeric handle*},<br/>role=**sender**,<br/>source=**null**,<br/>target=”myentity/$management”<br/>)	Nincs művelet
Kérelem válaszútvonalának létrehozása	Nincs művelet	\<-- attach(<br/>name={*link name*},<br/>handle={*numeric handle*},<br/>role=**receiver**,<br/>source=null,<br/>target=”myentity”<br/>)
Kérelem válaszútvonalának létrehozása	--> attach(<br/>name={*link name*},<br/>handle={*numeric handle*},<br/>role=**receiver**,<br/>source=”myentity/$management”,<br/>target=”myclient$id”<br/>)
Kérelem válaszútvonalának létrehozása	Nincs művelet	\<-- attach(<br/>name={*link name*},<br/>handle={*numeric handle*},<br/>role=**sender**,<br/>source=”myentity”,<br/>target=”myclient$id”<br/>)

Ha a hivatkozáspár működik, a kérés/válasz implementációja egyszerű: a kérés egy üzenet, amelyet az üzenetkezelési infrastruktúrán belül egy entitásnak küldenek, amely megérti ezt a mintát. Ebben a kérelemüzenetben a tulajdonságok szakasz válaszmezője annak a hivatkozásnak a célazonosítójára van beállítva, amelyre a választ kézbesíteni szeretné. A kezelő entitás feldolgozza a kérést, majd elküldi a választ azon a hivatkozáson keresztül, amelynek célazonosítója megegyezik a megadott válaszazonosítóval .

A minta nyilvánvalóan megköveteli, hogy az ügyféltároló és a válasz célhely ügyfél által generált azonosítója minden ügyfél esetében egyedi legyen, és biztonsági okokból nehéz megjósolni.

A felügyeleti protokollhoz és az összes olyan protokollhoz használt üzenetcserék, amelyek ugyanazt a mintát használják, az alkalmazás szintjén történnek; nem definiálnak új AMQP protokollszintű kézmozdulatokat. Ez szándékos, hogy az alkalmazások azonnal kihasználhassák ezeket a bővítményeket a megfelelő AMQP 1.0-veremekkel.

A Service Bus jelenleg nem implementálja a felügyeleti specifikáció egyik alapvető funkcióját sem, de a felügyeleti specifikáció által meghatározott kérés-válasz minta alapvető a jogcímalapú biztonsági funkció és a következő szakaszokban tárgyalt fejlett képességek szinte mindegyikéhez:

Jogcímalapú engedélyezés

Az AMQP jogcímalapú engedélyezési (CBS) specifikációtervezete a felügyeleti specifikáció kérési/válaszmintájára épül, és egy általános modellt ír le az összevont biztonsági jogkivonatok AMQP-vel való használatára.

A bevezetésben tárgyalt AMQP alapértelmezett biztonsági modellje az SASL-en alapul, és integrálható az AMQP kapcsolati kézfogással. A SASL használata azzal az előnnyel jár, hogy bővíthető modellt biztosít, amelyhez olyan mechanizmusokat határoztak meg, amelyekből bármilyen protokoll, amely formálisan az SASL-hez támaszkodik, előnyös lehet. Ezek közül a "PLAIN" a felhasználónevek és jelszavak átvitelére, a "KÜLSŐ" a TLS-szintű biztonsághoz való kötéshez, a "NÉVTELEN" a explicit hitelesítés/engedélyezés hiányának kifejezésére, valamint számos további mechanizmus, amely lehetővé teszi a hitelesítési és/vagy engedélyezési hitelesítő adatok vagy jogkivonatok átadását.

Az AMQP SASL-integrációjának két hátránya van:

• Minden hitelesítő adat és jogkivonat hatóköre a kapcsolatra terjed ki. Előfordulhat, hogy egy üzenetkezelési infrastruktúra entitásonként szeretne differenciált hozzáférés-vezérlést biztosítani; például lehetővé teszi, hogy egy jogkivonat tulajdonosát az A üzenetsorba küldje, a B üzenetsorba azonban nem. Mivel az engedélyezési környezet a kapcsolathoz van rögzítve, nem lehet egyetlen kapcsolatot használni, és mégis különböző hozzáférési jogkivonatokat használni az A és a B üzenetsorhoz.
• A hozzáférési jogkivonatok általában csak korlátozott ideig érvényesek. Ez az érvényesség megköveteli, hogy a felhasználó rendszeresen újra lekösse a jogkivonatokat, és lehetőséget biztosít a jogkivonat-kiállítónak arra, hogy megtagadja a friss jogkivonat kiállítását, ha a felhasználó hozzáférési engedélyei megváltoztak. Az AMQP-kapcsolatok hosszú ideig tarthatnak. Az SASL-modell csak a kapcsolati időben biztosít lehetőséget a jogkivonat beállítására, ami azt jelenti, hogy az üzenetkezelési infrastruktúrának vagy le kell választania az ügyfelet a jogkivonat lejáratakor, vagy el kell fogadnia annak kockázatát, hogy lehetővé teszi a folyamatos kommunikációt egy olyan ügyféllel, aki hozzáférési jogosultságait időközben visszavonták.

A Service Bus által implementált AMQP CBS-specifikáció elegáns kerülő megoldást tesz lehetővé mindkét problémára: Lehetővé teszi az ügyfél számára, hogy hozzáférési jogkivonatokat társítson az egyes csomópontokhoz, és a lejárat előtt frissítse ezeket a jogkivonatokat anélkül, hogy megszakítanák az üzenetfolyamot.

A CBS egy $cbs nevű virtuális felügyeleti csomópontot határoz meg, amelyet az üzenetkezelési infrastruktúra biztosít. A felügyeleti csomópont jogkivonatokat fogad el az üzenetkezelési infrastruktúra bármely más csomópontja nevében.

A protokoll kézmozdulata a felügyeleti specifikációban meghatározott kérés-válasz csere. Ez azt jelenti, hogy az ügyfél kapcsolatot létesít a $cbs csomóponttal, majd továbbít egy kérést a kimenő hivatkozáson, majd megvárja a bejövő hivatkozás válaszát.

A kérelemüzenet az alábbi alkalmazástulajdonságokat tartalmazza:

Key	Lehetséges	Érték típusa	Érték tartalma
operation	Nem	sztring	put-token
type	Nem	sztring	A felhozott jogkivonat típusa.
name	Nem	sztring	A "célközönség", amelyre a jogkivonat vonatkozik.
expiration	Igen	timestamp	A jogkivonat lejárati ideje.

A névtulajdonság azonosítja azt az entitást, amelyhez a jogkivonatot társítani kell. A Service Busban ez az üzenetsor vagy témakör/előfizetés elérési útja. A típustulajdonság azonosítja a jogkivonat típusát:

Jogkivonat típusa	Jogkivonat leírása	Törzs típusa	Jegyzetek
jwt	JSON webes jogkivonat (JWT)	AMQP-érték (sztring)
servicebus.windows.net:sastoken	Service Bus SAS-jogkivonat	AMQP-érték (sztring)	-

A jogkivonatok jogokat adnak meg. A Service Bus három alapvető jogról tud: a "Küldés" lehetővé teszi a küldést, a "Figyelés" lehetővé teszi a fogadást, a "Kezelés" pedig az entitások manipulálását. A Service Bus SAS-jogkivonatok a névtéren vagy entitáson konfigurált szabályokra vonatkoznak, és ezek a szabályok jogosultságokkal vannak konfigurálva. A jogkivonatnak a szabályhoz társított kulccsal való aláírásával a jogkivonat kifejezi a megfelelő jogosultságokat. A put-tokent használó entitáshoz társított jogkivonat lehetővé teszi, hogy a csatlakoztatott ügyfél a jogkivonat-jogosultságok alapján kommunikáljon az entitással. Ahhoz a hivatkozáshoz, ahol az ügyfél felveszi a feladói szerepkört, a "Küldés" jog szükséges, a fogadó szerepkör felvételéhez pedig a "Figyelés" jogosultság szükséges.

A válaszüzenet az alábbi alkalmazástulajdonság-értékekkel rendelkezik

Key	Lehetséges	Érték típusa	Érték tartalma
status-code	Nem	egész	HTTP-válaszkód [RFC2616].
status-description	Igen	sztring	Az állapot leírása.

Az ügyfél ismétlődően és az üzenetkezelési infrastruktúrában lévő bármely entitáshoz meghívhatja a put-tokent . A jogkivonatok hatóköre az aktuális ügyfélre terjed ki, és az aktuális kapcsolaton van rögzítve, ami azt jelenti, hogy a kiszolgáló a kapcsolat megszakadásakor elveti a megőrzött jogkivonatokat.

A Service Bus jelenlegi implementációja csak a "NÉVTELEN" SASL-metódussal együtt engedélyezi a CBS-t. Az SASL-kézfogás előtt mindig léteznie kell SSL-/TLS-kapcsolatnak.

A NÉVTELEN mechanizmust ezért a kiválasztott AMQP 1.0-ügyfélnek kell támogatnia. A névtelen hozzáférés azt jelenti, hogy a kezdeti kapcsolat kézfogása, beleértve a kezdeti munkamenet létrehozását, anélkül történik, hogy a Service Bus tudná, ki hozza létre a kapcsolatot.

A kapcsolat és a munkamenet létrehozása után a $cbs csomópontra mutató hivatkozások csatolása és a put-token kérés elküldése az egyetlen engedélyezett művelet. Az érvényes jogkivonatot egy entitáscsomópontra vonatkozó put-token kéréssel kell sikeresen beállítani a kapcsolat létrejöttét követő 20 másodpercen belül, ellenkező esetben a Service Bus egyoldalúan megszakítja a kapcsolatot.

Ezt követően az ügyfél felelős a jogkivonat lejáratának nyomon követéséért. Amikor egy jogkivonat lejár, a Service Bus azonnal elveti az adott entitáshoz való kapcsolat összes hivatkozását. A probléma elkerülése érdekében az ügyfél bármikor lecserélheti a csomópont jogkivonatát egy újra a virtuális $cbs felügyeleti csomóponton keresztül ugyanazzal a put-token kézmozdulattal , és anélkül, hogy a különböző kapcsolatokon áthaladó hasznos adatforgalom útjában áll.

Küldés funkció

A küldési/átadási feladó olyan funkció, amellyel a Service Bus egy adott üzenetet továbbíthat egy cél entitásnak egy másik entitáson keresztül. Ez a funkció egyetlen tranzakció entitásai közötti műveletek végrehajtására szolgál.

Ezzel a funkcióval létre kell hoznia egy feladót, és létre kell hoznia a hivatkozását a via-entity. A hivatkozás létrehozásakor további információk kerülnek átadásra a hivatkozáson található üzenetek/átvitelek valódi céljának megállapításához. Miután a csatolás sikeres volt, a rendszer automatikusan továbbítja az ezen a hivatkozáson küldött összes üzenetet a cél-entitásnak egyenlitáson keresztül.

Megjegyzés: A hivatkozás létrehozása előtt hitelesítést kell végezni mind az entitáson, mind a célentitáson keresztül.

Client	Direction	Service Bus
attach(<br/>name={link name},<br/>role=sender,<br/>source={client link ID},<br/>target=**{via-entity}**,<br/>**properties=map [(<br/>com.microsoft:transfer-destination-address=<br/>{destination-entity} )]** )	------>
	<------	attach(<br/>name={link name},<br/>role=receiver,<br/>source={client link ID},<br/>target={via-entity},<br/>properties=map [(<br/>com.microsoft:transfer-destination-address=<br/>{destination-entity} )] )

Következő lépések

Az AMQP-ről további információt a Service Bus AMQP áttekintésében talál.