Průvodce protokolem AMQP 1.0 ve službě Azure Service Bus a Event Hubs

Advanced Message Queueing Protocol 1.0 je standardizovaný framing a přenosový protokol pro asynchronně, bezpečně a spolehlivě přenášet zprávy mezi dvěma stranami. Jedná se o primární protokol zasílání zpráv služby Azure Service Bus a služby Azure Event Hubs.

AMQP 1.0 je výsledkem široké oborové spolupráce, která spojuje dodavatele middlewaru, jako je Microsoft a Red Hat, s mnoha uživateli middlewaru pro zasílání zpráv, jako je JP Morgan Chase představující odvětví finančních služeb. Technické standardizační fórum pro protokol AMQP a specifikace rozšíření je OASIS a dosáhla formálního schválení jako mezinárodní standard iso/IEC 19494:2014.

Cíle

Tento článek shrnuje základní koncepty specifikace zasílání zpráv AMQP 1.0 spolu se specifikacemi rozšíření vyvinutými technickým výborem OASIS AMQP a vysvětluje, jak Azure Service Bus implementuje a staví na těchto specifikacích.

Cílem je, aby každý vývojář používal jakýkoli existující klientský zásobník AMQP 1.0 na libovolné platformě, aby mohl komunikovat se službou Azure Service Bus prostřednictvím AMQP 1.0.

Běžné obecné zásobníky AMQP 1.0, jako je Apache Qpid Proton nebo AMQP.NET Lite, implementují všechny základní prvky protokolu AMQP 1.0, jako jsou relace nebo odkazy. Tyto základní prvky jsou někdy zabaleny s rozhraním API vyšší úrovně; Apache Proton dokonce nabízí dvě, imperativní rozhraní Messenger API a reaktivní rozhraní Reactor API.

V následující diskuzi předpokládáme, že správa připojení, relací a propojení AMQP a zpracování přenosů snímků a řízení toku se zpracovává v příslušném zásobníku (například Apache Proton-C) a nevyžaduje mnoho, pokud by vývojáři aplikací měli zvláštní pozornost. Abstraktně předpokládáme existenci několika primitiv rozhraní API, jako je schopnost připojit se, a vytvořit určitou formu objektů abstrakce odesílatele a příjemce , které pak mají nějaký tvar send() a receive() operace.

Při diskuzi o pokročilých možnostech služby Azure Service Bus, jako je procházení zpráv nebo správa relací, jsou tyto funkce vysvětleny v AMQP termínech, ale také jako vrstvené pseudopodimi implementace nad touto předpokládanou abstrakcí rozhraní API.

Co je AMQP?

AMQP je framing a přenosový protokol. Framing znamená, že poskytuje strukturu binárních datových proudů, které proudí v libovolném směru síťového připojení. Struktura poskytuje delineaci pro různé bloky dat, označované jako rámce, které se mají vyměňovat mezi propojenými stranami. Možnosti přenosu zajišťují, aby obě komunikující strany mohly stanovit sdílené porozumění tomu, kdy budou rámce převedeny, a kdy se přenosy považují za úplné.

Na rozdíl od dřívějších verzí konceptů z pracovní skupiny AMQP, které stále používají několik zprostředkovatelů zpráv, finální a standardizovaný protokol AMQP 1.0 předepisuje přítomnost zprostředkovatele zpráv ani žádnou konkrétní topologii entit uvnitř zprostředkovatele zpráv.

Protokol lze použít pro symetrickou komunikaci mezi dvěma účastníky, pro interakci s zprostředkovateli zpráv, které podporují fronty a publikují nebo odebírat entity, jak to dělá Azure Service Bus. Dá se také použít pro interakci s infrastrukturou zasílání zpráv, kde se vzory interakce liší od běžných front, stejně jako u služby Azure Event Hubs. Centrum událostí funguje jako fronta při odesílání událostí do ní, ale funguje spíše jako služba sériového úložiště při čtení událostí z ní; to poněkud připomíná páskovou jednotku. Klient vybere posun do dostupného datového proudu a pak se obsluhuje všechny události z daného posunu na nejnovější dostupnou.

Protokol AMQP 1.0 je navržený tak, aby byl rozšiřitelný, což umožňuje další specifikace pro zvýšení jeho schopností. Tři specifikace rozšíření popsané v tomto dokumentu ilustrují. Pro komunikaci přes stávající infrastrukturu HTTPS/WebSockets může být konfigurace nativních portů TCP protokolu AMQP obtížná. Specifikace vazby definuje, jak vrstvit AMQP přes WebSockets. Pro interakci s infrastrukturou zasílání zpráv způsobem požadavků a odpovědí pro účely správy nebo poskytování pokročilých funkcí definuje specifikace správy AMQP požadované základní primitivy interakce. V případě integrace federovaného autorizačního modelu definuje specifikace zabezpečení založené na deklaracích identity AMQP způsob přidružení a obnovení autorizačních tokenů přidružených k odkazům.

Základní scénáře AMQP

Tato část vysvětluje základní použití AMQP 1.0 se službou Azure Service Bus, která zahrnuje vytváření připojení, relací a odkazů a přenos zpráv do a z entit služby Service Bus, jako jsou fronty, témata a odběry.

Nejautoritativním zdrojem informací o tom, jak AMQP funguje, je specifikace AMQP 1.0, ale specifikace byla napsána přesně na vodítko implementace a ne učit protokol. Tato část se zaměřuje na představení tolik terminologie, kolik je potřeba k popisu způsobu, jakým Service Bus používá AMQP 1.0. Podrobnější úvod do AMQP a širší diskuzi O AMQP 1.0 najdete v tomto videokursu.

Připojení a relace

AMQP volá kontejnery komunikujících programů; ty obsahují uzly, což jsou komunikující entity uvnitř těchto kontejnerů. Fronta může být takový uzel. AMQP umožňuje multiplexování, takže jedno připojení lze použít pro mnoho komunikačních cest mezi uzly; Klient aplikace může například souběžně přijímat z jedné fronty a odesílat do jiné fronty přes stejné síťové připojení.

Síťové připojení je tedy ukotveno v kontejneru. Iniciuje ho kontejner v roli klienta, který vytvoří odchozí připojení soketu TCP ke kontejneru v roli příjemce, který naslouchá příchozím připojením TCP a přijímá příchozí připojení TCP. Handshake připojení zahrnuje vyjednávání verze protokolu, deklarování nebo vyjednávání použití protokolu TLS (Transport Level Security) / SSL (Secure Sockets Layer) a metodu handshake ověřování/autorizace v oboru připojení založeném na SASL.

Azure Service Bus nebo Azure Event Hubs vyžadují vždy použití protokolu TLS. Podporuje připojení přes port TCP 5671, kdy se připojení TCP nejprve překryje protokolem TLS před vstupem do metody handshake protokolu AMQP a také podporuje připojení přes port TCP 5672, přičemž server okamžitě nabízí povinný upgrade připojení k tls pomocí předepsaného modelu AMQP. Vazba AMQP WebSockets vytvoří tunel přes port TCP 443, který pak odpovídá připojeníMQP 5671.

Po nastavení připojení a protokolu TLS nabízí Service Bus dvě možnosti mechanismu SASL:

• SASL PLAIN se běžně používá k předávání přihlašovacích údajů uživatelského jména a hesla k serveru. Service Bus nemá účty, ale pojmenovaná pravidla zabezpečení sdíleného přístupu, která udělují práva a jsou přidruženy ke klíči. Název pravidla se používá jako uživatelské jméno a klíč (jako text kódovaný v base64) se používá jako heslo. Práva přidružená k zvolenému pravidlu řídí operace povolené u připojení.
• SASL ANONYMOUS se používá k obejití autorizace SASL v případě, že klient chce použít model zabezpečení založené na deklaracích (CBS), který je popsán později. S touto možností je možné navázat připojení klienta anonymně po krátkou dobu, během které může klient pracovat pouze s koncovým bodem CBS a musí dokončit handshake SLUŽBY CBS.

Po navázání přenosového připojení kontejnery deklarují maximální velikost rámce, kterou jsou ochotni zpracovat, a po vypršení časového limitu nečinnosti se jednostranně odpojí, pokud u připojení není žádná aktivita.

Deklarují také počet podporovaných souběžných kanálů. Kanál je jednosměrná, odchozí, virtuální přenosová cesta nad připojením. Relace přebírá kanál z každého propojeného kontejneru a vytvoří obousměrnou komunikační cestu.

Relace mají model řízení toku založený na okně; když je relace vytvořena, každá strana deklaruje, kolik rámců je ochotno přijmout do svého okna příjmu. Když strany vyměňují rámce, přenesené rámce vyplní toto okno a přenese se, když je okno plné, a dokud se okno resetuje nebo rozbalí pomocí výkonu toku (performativní je termín AMQP pro gesta na úrovni protokolu vyměňovaná mezi těmito dvěma stranami).

Tento model založený na otevírně je přibližně podobný konceptu TCP řízení toku založeného na okně, ale na úrovni relace uvnitř soketu. Koncept protokolu umožňující více souběžných relací existuje tak, aby se provoz s vysokou prioritou mohl spěchat po omezování normálního provozu, jako je třeba na dálničním expresním pruhu.

Azure Service Bus aktuálně používá pro každé připojení přesně jednu relaci. Maximální velikost rámce služby Service Bus je 262 144 bajtů (256 K bajtů) pro Service Bus Standard. Je 1048576 (100 MB) pro Service Bus Premium a Event Hubs. Service Bus neukládá žádná konkrétní okna omezování na úrovni relace, ale pravidelně resetuje okno jako součást řízení toku na úrovni propojení (viz další část).

Připojení, kanály a relace jsou dočasné. Pokud základní připojení sbalí, připojení, tunel TLS, kontext autorizace SASL a relace se musí znovu publikovat.

Požadavky na odchozí porty AMQP

Klienti, kteří používají připojení AMQP přes protokol TCP, vyžadují otevření portů 5671 a 5672 v místní bráně firewall. Kromě těchto portů může být nutné otevřít další porty, pokud je povolená funkce EnableLinkRedirect . EnableLinkRedirect je nová funkce zasílání zpráv, která pomáhá přeskočit jeden segment směrování při přijímání zpráv, což pomáhá zvýšit propustnost. Klient začne komunikovat přímo s back-endovou službou přes rozsah portů 104XX, jak je znázorněno na následujícím obrázku.

Klient .NET selže se soketem ("Došlo k pokusu o přístup k soketu způsobem zakázaným jeho přístupovými oprávněními"), pokud jsou tyto porty blokovány bránou firewall. Tuto funkci lze zakázat nastavením EnableAmqpLinkRedirect=false v připojovací řetězec, což vynutí, aby klienti komunikují se vzdálenou službou přes port 5671.

Vazba AMQP WebSocket poskytuje mechanismus pro tunelování připojení AMQP přes přenos WebSocket. Tato vazba vytvoří tunel přes port TCP 443, který odpovídá připojeníMQP 5671. Pokud se nacházíte za bránou firewall, která blokuje připojení TCP přes porty 5671, 5672, ale umožňuje připojení TCP přes port 443 (https).

Odkazy

AMQP přenese zprávy přes odkazy. Odkaz je komunikační cesta vytvořená v relaci, která umožňuje přenos zpráv jedním směrem; vyjednávání o stavu převodu je přes propojení a obousměrné mezi propojenými stranami.

Propojení je možné kdykoli vytvořit buď pomocí kontejneru, a to prostřednictvím existující relace, což AMQP liší od mnoha dalších protokolů, včetně HTTP a MQTT, kde inicializace přenosů a cesty přenosu je výhradním oprávněním strany, která vytváří připojení soketu.

Kontejner iniciující propojení požádá opačný kontejner o přijetí odkazu a zvolí roli odesílatele nebo příjemce. Proto může kontejner zahájit vytváření jednosměrných nebo obousměrných komunikačních cest, přičemž druhý modelovaný jako dvojice propojení.

Propojení jsou pojmenovaná a přidružená k uzlům. Jak je uvedeno na začátku, uzly jsou komunikující entity uvnitř kontejneru.

Ve službě Service Bus je uzel přímo ekvivalentní frontě, tématu, předplatnému nebo dílčímu podkateru fronty nebo odběru. Název uzlu použitý v AMQP je proto relativní název entity uvnitř oboru názvů služby Service Bus. Pokud je fronta pojmenována myqueue, je to také název uzlu AMQP. Odběr tématu se řídí konvencí rozhraní HTTP API tím, že se řadí do kolekce prostředků "předplatná", a proto dílčí předplatné tématu mytopic má název uzlu AMQP mytopic/subscriptions/sub.

Připojení klienta je také nutné použít název místního uzlu pro vytváření propojení; Service Bus není popisující názvy těchto uzlů a interpretuje je. Klientské zásobníky AMQP 1.0 obecně používají schéma, které zajišťuje, že tyto dočasné názvy uzlů jsou jedinečné v oboru klienta.

Převody

Po vytvoření odkazu je možné zprávy přenést přes tento odkaz. V AMQP se přenos spustí s explicitním gestem protokolu ( provedením přenosu ), které přesune zprávu od odesílatele do příjemce přes odkaz. Převod je dokončen, když je "vyřešen", což znamená, že obě strany zavedly sdílené porozumění výsledku tohoto převodu.

V nejjednodušším případě může odesílatel odeslat zprávy "předem vyřešené", což znamená, že klient nemá zájem o výsledek a příjemce neposkytuje žádnou zpětnou vazbu o výsledku operace. Tento režim podporuje Service Bus na úrovni protokolu AMQP, ale není přístupný v žádném z klientských rozhraní API.

Běžným případem je, že se zprávy odesílají neospořádaně, a příjemce pak pomocí výkonu dispozice označuje přijetí nebo odmítnutí. Odmítnutí nastane, když příjemce nemůže přijmout zprávu z nějakého důvodu a zpráva o zamítnutí obsahuje informace o důvodu, což je struktura chyb definovaná AMQP. Pokud jsou zprávy odmítnuty z důvodu vnitřních chyb uvnitř služby Service Bus, vrátí služba v této struktuře další informace, které je možné použít k poskytování diagnostických tipů pracovníkům podpory, pokud vytváříte žádosti o podporu. Další podrobnosti o chybách najdete později.

Zvláštní forma zamítnutí je vydaný stav, který indikuje, že příjemce nemá žádné technické námitky k převodu, ale také žádný zájem o vyrovnání převodu. Tento případ existuje například při doručení zprávy klientovi služby Service Bus a klient se rozhodne zprávu "opustit", protože nemůže provést práci vyplývající ze zpracování zprávy; samotné doručení zprávy není vadné. Variantou tohoto stavu je upravený stav, který umožňuje změny zprávy při jejím vydání. Tento stav služba Service Bus v současné době nepoužívá.

Specifikace AMQP 1.0 definuje další stav dispozice označovaný jako přijatý, který konkrétně pomáhá zpracovat obnovení propojení. Obnovení propojení umožňuje rekonstituci stavu propojení a všech nevyřízených dodávek nad novým připojením a relací, kdy došlo ke ztrátě předchozího připojení a relace.

Service Bus nepodporuje obnovení propojení; Pokud klient ztratí připojení ke službě Service Bus s nevyřízeným přenosem zpráv, dojde ke ztrátě přenosu zpráv a klient se musí znovu připojit, obnovit propojení a zkusit přenos zopakovat.

Služba Service Bus a Event Hubs proto podporují přenos "aspoň jednou", kde se odesílatel může ujistit, že zpráva byla uložena a přijata, ale nepodporuje "přesně jednou" přenosy na úrovni AMQP, kde by se systém pokusil obnovit odkaz a pokračovat v vyjednávání stavu doručení, aby se zabránilo duplikaci přenosu zpráv.

Kvůli kompenzaci možných duplicitních odesílání podporuje Service Bus detekci duplicit jako volitelnou funkci ve frontách atématech Duplicitní detekce zaznamenává ID zpráv všech příchozích zpráv během uživatelem definovaného časového intervalu a potom bezobslužně zahodí všechny zprávy odeslané se stejnými ID zpráv během stejného okna.

Řízení toku

Kromě modelu řízení toku na úrovni relace, který jsme probírali dříve, má každý odkaz svůj vlastní model řízení toku. Řízenítoch služeb chrání kontejner před tím, že musí zpracovávat příliš mnoho snímků najednou. Řízení toku na úrovni propojení zajišťuje, kolik zpráv chce zpracovat z odkazu a kdy.

Na odkazu může dojít k převodům pouze v případě, že odesílatel má dostatek kreditu odkazu. Kredit propojení je čítač nastavený příjemcem pomocí výkonu toku , který je vymezen na propojení. Když je odesílatel přiřazený kredit odkazu, pokusí se tento kredit použít doručením zpráv. Každé doručení zprávy sníží zbývající kredit odkazu o 1. Při použití kreditu propojení se dodávky zastaví.

Když je Service Bus v roli příjemce, okamžitě poskytne odesílateli ample link kredit, aby bylo možné zprávy okamžitě odeslat. S tím, jak se používá kredit odkazu, service Bus občas pošle odesílateli výkonný tok , aby aktualizoval zůstatek kreditu propojení.

V roli odesílatele služba Service Bus odesílá zprávy, které použijí nevyrovnaný kredit odkazu.

Volání "příjmu" na úrovni rozhraní API se přeloží na tok , který klient odešle do služby Service Bus, a Service Bus tento kredit spotřebovává tak, že vezme první dostupnou, odemknutou zprávu z fronty, uzamkne ji a přenese ji. Pokud není k dispozici žádná zpráva pro doručení, všechny nevyrovnané kredity vytvořené s danou konkrétní entitou zůstanou zaznamenány v pořadí doručení a zprávy jsou uzamčeny a převedeny, jakmile budou k dispozici, aby bylo možné použít nevyrovnaný kredit.

Zámek zprávy se uvolní, když se přenos vyrovná do některého z terminálových stavů přijatých, odmítnutých nebo uvolněných. Zpráva se odebere ze služby Service Bus při přijetí stavu terminálu. Zůstane ve službě Service Bus a doručí se dalšímu příjemci, když přenos dosáhne některého z ostatních stavů. Service Bus automaticky přesune zprávu do fronty deadletter entity, když dosáhne maximálního povoleného počtu doručení pro entitu kvůli opakovaným zamítnutím nebo vydáním.

I když rozhraní API služby Service Bus tuto možnost v současnosti přímo nezpřístupňují, klient protokolu AMQP nižší úrovně může pomocí modelu link-credit změnit interakci typu vyžádání obsahu při vydávání jedné jednotky kreditu pro každý požadavek na příjem do modelu typu push tak, že vydá velký počet kreditů propojení a pak obdrží zprávy, jakmile budou k dispozici bez jakékoli další interakce. Nabízená oznámení se podporuje prostřednictvím nastavení vlastnosti ServiceBusProcessor.PrefetchCount nebo ServiceBusReceiver.PrefetchCount . Pokud nejsou nulové, klient AMQP ho použije jako kredit propojení.

V tomto kontextu je důležité pochopit, že hodiny pro vypršení platnosti zámku zprávy uvnitř entity začínají při přebírání zprávy z entity, ne při vložení zprávy do drátu. Kdykoli klient indikuje připravenost na příjem zpráv vydáním kreditu propojení, očekává se proto, že aktivně načítá zprávy v síti a bude připraven je zpracovat. Jinak mohlo dojít k vypršení platnosti zámku zprávy před doručením zprávy. Použití řízení toku kreditů propojení by mělo přímo odrážet okamžitou připravenost na zpracování dostupných zpráv odeslaných příjemci.

V souhrnu následující části obsahují schéma výkonného toku během různých interakcí s rozhraním API. Každá část popisuje jinou logickou operaci. Některé z těchto interakcí můžou být "opožděné", což znamená, že se můžou provádět jenom v případě potřeby. Vytvoření odesílatele zprávy nemusí způsobit interakci se sítí, dokud se neodesílají nebo nebudou vyžadovat první zprávy.

Šipky v následující tabulce ukazují směr výkonu toku.

Vytvoření příjemce zprávy

Klient	Service Bus
--> attach(<br/>name={link name},<br/>handle={numeric handle},<br/>role=**receiver**,<br/>source={entity name},<br/>target={client link ID}<br/>)	Klient se připojí k entitě jako příjemce.
Odpovědi služby Service Bus připojující konec odkazu	<-- attach(<br/>name={link name},<br/>handle={numeric handle},<br/>role=**sender**,<br/>source={entity name},<br/>target={client link ID}<br/>)

Vytvoření odesílatele zprávy

Klient	Service Bus
--> attach(<br/>name={link name},<br/>handle={numeric handle},<br/>role=**sender**,<br/>source={client link ID},<br/>target={entity name}<br/>)	Žádná akce
Žádná akce	<-- attach(<br/>name={link name},<br/>handle={numeric handle},<br/>role=**receiver**,<br/>source={client link ID},<br/>target={entity name}<br/>)

Vytvoření odesílatele zprávy (chyba)

Klient	Service Bus
--> attach(<br/>name={link name},<br/>handle={numeric handle},<br/>role=**sender**,<br/>source={client link ID},<br/>target={entity name}<br/>)	Žádná akce
Žádná akce	<-- 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/>)

Zavření příjemce zprávy nebo odesílatele

Klient	Service Bus
--> detach(<br/>handle={numeric handle},<br/>closed=**true**<br/>)	Žádná akce
Žádná akce	<-- detach(<br/>handle={numeric handle},<br/>closed=**true**<br/>)

Odeslat (úspěch)

Klient	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/>)	Žádná akce
Žádná akce	<-- disposition(<br/>role=receiver,<br/>first={delivery ID},<br/>last={delivery ID},<br/>settled=**true**,<br/>state=**accepted**<br/>)

Odeslat (chyba)

Klient	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/>)	Žádná akce
Žádná akce	<-- disposition(<br/>role=receiver,<br/>first={delivery ID},<br/>last={delivery ID},<br/>settled=**true**,<br/>state=**rejected**(<br/>error={error info}<br/>)<br/>)

Přijmout

Klient	Service Bus
--> flow(<br/>link-credit=1<br/>)	Žádná akce
Žádná akce	< 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/>)	Žádná akce

Příjem více zpráv

Klient	Service Bus
--> flow(<br/>link-credit=3<br/>)	Žádná akce
Žádná akce	< transfer(<br/>delivery-id={numeric handle},<br/>delivery-tag={binary handle},<br/>settled=**false**,<br/>more=**false**,<br/>state=**null**,<br/>resume=**false**<br/>)
Žádná akce	< 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/>)
Žádná akce	< 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/>)	Žádná akce

Zprávy

Následující části vysvětlují, které vlastnosti ze standardních oddílů zpráv AMQP používá Service Bus a jak se mapují na sadu rozhraní API služby Service Bus.

Všechny vlastnosti, které aplikace potřebuje definovat, by se měly mapovat na mapu AMQP application-properties .

Hlavička

Název pole	Využití	Název rozhraní API
trvalý	-	-
priorita	-	-
TTL	Doba života pro tuto zprávu	TimeToLive
first-acquirer	-	-
delivery-count	-	DeliveryCount

Vlastnosti

Název pole	Využití	Název rozhraní API
message-id	Identifikátor volného formuláře definované aplikací pro tuto zprávu. Používá se k detekci duplicit.	MessageId
user-id	Identifikátor uživatele definovaný aplikací, který není interpretován službou Service Bus.	Není přístupný prostřednictvím rozhraní API služby Service Bus.
to	Identifikátor cíle definovaný aplikací, který není interpretován službou Service Bus.	Na
subject	Identifikátor účelu zprávy definovaný aplikací, který není interpretován službou Service Bus.	Předmět
reply-to	Ukazatel cesty odpovědi definovaný aplikací, který není interpretován službou Service Bus.	Odpovědět na
correlation-id	Identifikátor korelace definovaný aplikací, který není interpretován službou Service Bus.	Id korelace
content-type	Indikátor obsahu definovaný aplikací pro tělo, který není interpretován službou Service Bus.	ContentType
content-encoding	Indikátor kódování obsahu definovaný aplikací pro tělo, který není interpretován službou Service Bus.	Není přístupný prostřednictvím rozhraní API služby Service Bus.
absolute-expiry-time	Deklaruje, v jakém absolutním okamžiku vyprší platnost zprávy. Při zadávání se ignoruje hodnota TTL (hlavička TTL se pozoruje), autoritativní na výstupu.	Není přístupný prostřednictvím rozhraní API služby Service Bus.
creation-time	Deklaruje, kdy byla zpráva vytvořena. Nepoužívá se službou Service Bus	Není přístupný prostřednictvím rozhraní API služby Service Bus.
group-id	Identifikátor definovaný aplikací pro související sadu zpráv Používá se pro relace služby Service Bus.	Id relace
group-sequence	Čítač identifikující relativní pořadové číslo zprávy uvnitř relace. Přeskočeno službou Service Bus.	Není přístupný prostřednictvím rozhraní API služby Service Bus.
reply-to-group-id	-	ReplyToSessionId

Poznámky ke zprávám

Existuje několik dalších vlastností zpráv služby Service Bus, které nejsou součástí vlastností zprávy AMQP a předávají se společně se zprávou.MessageAnnotations

Klíč mapy poznámek	Využití	Název rozhraní API
x-opt-scheduled-enqueue-time	Deklaruje, kdy se má zpráva zobrazit v entitě.	ScheduledEnqueueTime
x-opt-partition-key	Klíč definovaný aplikací, který určuje, ve kterém oddílu by se zpráva měla nacházet.	PartitionKey
x-opt-via-partition-key	Hodnota klíče oddílu definovaná aplikací při použití transakce k odesílání zpráv prostřednictvím přenosové fronty.	TransactionPartitionKey
x-opt-enqueued-time	Čas UTC definovaný službou představující skutečný čas zařazení zprávy do fronty Ignorováno při vstupu.	EnqueuedTime
x-opt-sequence-number	Jedinečné číslo definované službou přiřazené ke zprávě	SequenceNumber
x-opt-offset	Pořadové číslo zprávy definované službou	EnqueuedSequenceNumber
x-opt-locked-until	Definována službami. Datum a čas, do kterého bude zpráva uzamčena ve frontě nebo odběru.	UzamčenoUntil
x-opt-deadletter-source	Definovaná služba. Pokud je zpráva přijata z fronty nedoručených zpráv, představuje zdroj původní zprávy.	DeadLetterSource

Funkce transakce

Skupiny transakcí seskupují dvě nebo více operací do rozsahu provádění. Taková transakce musí ze své podstaty zajistit, aby všechny operace patřící dané skupině operací byly úspěšné nebo neúspěšné společně. Operace jsou seskupeny identifikátorem txn-id.

Pro transakční interakci funguje klient jako transaction controller , který řídí operace, které by měly být seskupeny dohromady. Služba Service Bus funguje jako transactional resource služba a provádí práci, kterou požaduje .transaction controller

Klient a služba komunikují přes control link , který je vytvořen klientem. Zprávy declare a discharge zprávy jsou odeslány kontrolerem přes řídicí odkaz pro přidělení a dokončení transakcí (nepředstavují demaration of transactional work). Na tomto odkazu se neprovádí skutečné odesílání a přijímání. Každá požadovaná transakční operace je explicitně identifikována požadovaným txn-id způsobem, a proto může dojít na libovolném odkazu na připojení. Pokud je řídicí propojení uzavřeno v době, kdy existují neprázdné transakce, které vytvořil, jsou všechny tyto transakce okamžitě vráceny zpět a pokusy o provedení další transakční práce na nich povede k selhání. Zprávy na řídicím odkazu nesmí být předem vyřešené.

Každé připojení musí inicializovat vlastní řídicí propojení, aby bylo možné zahájit a ukončit transakce. Služba definuje zvláštní cíl, který funguje jako coordinator. Klient/kontroler vytvoří řídicí odkaz na tento cíl. Řídicí propojení je mimo hranici entity, to znamená, že stejné řídicí propojení lze použít k zahájení a uvolnění transakcí pro více entit.

Spuštění transakce

Chcete-li zahájit transakční práci, musí kontroler získat txn-id od koordinátora. To provede odesláním declare zprávy typu. Pokud je deklarace úspěšná, koordinátor odpoví výstupem dispozice, který nese přiřazené txn-id.

Klient (kontroler)	Směr	Service Bus (koordinátor)
attach(<br/>name={link name},<br/>... ,<br/>role=**sender**,<br/>target=**Coordinator**<br/>)	------>
	<------	attach(<br/>name={link name},<br/>... ,<br/>target=Coordinator()<br/>)
transfer(<br/>delivery-id=0, ...)<br/>{ AmqpValue (**Declare()**)}	------>
	<------	disposition( <br/> first=0, last=0, <br/>state=**Declared**(<br/>**txn-id**={transaction ID}<br/>))

Vysílání transakce

Kontroler ukončí transakční práci odesláním discharge zprávy koordinátoru. Kontroler označuje, že chce potvrdit nebo vrátit transakční práci nastavením fail příznaku pro tělo uvolnění. Pokud koordinátor nemůže dokončit udělení absolutoria, zpráva je odmítnuta s tímto výsledkem, který obsahuje transaction-error.

Poznámka: fail=true odkazuje na vrácení transakce zpět a fail=false odkazuje na potvrzení.

Klient (kontroler)	Směr	Service Bus (koordinátor)
transfer(<br/>delivery-id=0, ...)<br/>{ AmqpValue (Declare())}	------>
	<------	disposition( <br/> first=0, last=0, <br/>state=Declared(<br/>txn-id={transaction ID}<br/>))
	. . . Transakční práce na jiných odkazech . . .
transfer(<br/>delivery-id=57, ...)<br/>{ AmqpValue (<br/>**Discharge(txn-id=0,<br/>fail=false)**)}	------>
	<------	disposition( <br/> first=57, last=57, <br/>state=**Accepted()**)

Odeslání zprávy v transakci

Veškerá transakční práce se provádí se stavem transactional-state transakčního doručení, který nese txn-id. Při odesílání zpráv se transakční stav přenáší přenosovým rámcem zprávy.

Klient (kontroler)	Směr	Service Bus (koordinátor)
transfer(<br/>delivery-id=0, ...)<br/>{ AmqpValue (Declare())}	------>
	<------	disposition( <br/> first=0, last=0, <br/>state=Declared(<br/>txn-id={transaction ID}<br/>))
transfer(<br/>handle=1,<br/>delivery-id=1, <br/>**state=<br/>TransactionalState(<br/>txn-id=0)**)<br/>{ payload }	------>
	<------	disposition( <br/> first=1, last=1, <br/>state=**TransactionalState(<br/>txn-id=0,<br/>outcome=Accepted()**))

Vystavení zprávy v transakci

Dispozice zpráv zahrnuje operace jako CompleteDeadLetter / DeferAbandon / / . Chcete-li provést tyto operace v rámci transakce, předejte transactional-state s dispozici.

Klient (kontroler)	Směr	Service Bus (koordinátor)
transfer(<br/>delivery-id=0, ...)<br/>{ AmqpValue (Declare())}	------>
	<------	disposition( <br/> first=0, last=0, <br/>state=Declared(<br/>txn-id={transaction ID}<br/>))
	<------	transfer(<br/>handle=2,<br/>delivery-id=11, <br/>state=null)<br/>{ payload }
disposition( <br/> first=11, last=11, <br/>state=**TransactionalState(<br/>txn-id=0,<br/>outcome=Accepted()**))	------>

Pokročilé možnosti služby Service Bus

Tato část popisuje pokročilé funkce služby Azure Service Bus založené na konceptech rozšíření AMQP, které jsou aktuálně vyvíjeny v technickém výboru OASIS pro AMQP. Service Bus implementuje nejnovější verze těchto konceptů a přijímá změny zavedené, protože tyto koncepty dosáhnou standardního stavu.

Poznámka:

Pokročilé operace zasílání zpráv služby Service Bus se podporují prostřednictvím vzoru požadavků a odpovědí. Podrobnosti o těchto operacích jsou popsány v článku AMQP 1.0 ve službě Service Bus: operace založené na požadavku.

Správa AMQP

Specifikace správy AMQP je první z konceptů rozšíření probíraných v tomto článku. Tato specifikace definuje sadu protokolů vrstvených nad protokolem AMQP, který umožňuje správu interakcí s infrastrukturou zasílání zpráv přes AMQP. Specifikace definuje obecné operace, jako je vytvoření, čtení, aktualizace a odstranění pro správu entit v infrastruktuře zasílání zpráv a sada operací dotazů.

Všechna tato gesta vyžadují interakci mezi klientem a infrastrukturou zasílání zpráv, a proto specifikace definuje, jak modelovat model interakce nad AMQP: klient se připojí k infrastruktuře zasílání zpráv, zahájí relaci a pak vytvoří dvojici propojení. Na jednom odkazu funguje klient jako odesílatel a druhý funguje jako příjemce, čímž vytvoří dvojici propojení, která může fungovat jako obousměrný kanál.

Logická operace	Klient	Service Bus
Cesta odpovědi na vytvoření žádosti	--> attach(<br/>name={*link name*},<br/>handle={*numeric handle*},<br/>role=**sender**,<br/>source=**null**,<br/>target=”myentity/$management”<br/>)	Žádná akce
Cesta odpovědi na vytvoření žádosti	Žádná akce	\<-- attach(<br/>name={*link name*},<br/>handle={*numeric handle*},<br/>role=**receiver**,<br/>source=null,<br/>target=”myentity”<br/>)
Cesta odpovědi na vytvoření žádosti	--> attach(<br/>name={*link name*},<br/>handle={*numeric handle*},<br/>role=**receiver**,<br/>source=”myentity/$management”,<br/>target=”myclient$id”<br/>)
Cesta odpovědi na vytvoření žádosti	Žádná akce	\<-- attach(<br/>name={*link name*},<br/>handle={*numeric handle*},<br/>role=**sender**,<br/>source=”myentity”,<br/>target=”myclient$id”<br/>)

Když je tato dvojice propojení zavedená, implementace požadavku a odpovědi je jednoduchá: požadavek je zpráva odeslaná entitě uvnitř infrastruktury zasílání zpráv, která rozumí tomuto vzoru. V této zprávě požadavku je pole pro odpověď v oddílu vlastností nastaveno na cílový identifikátor odkazu, na který se má odpověď doručit. Zpracovávaná entita zpracuje požadavek a pak odešle odpověď přes odkaz, jehož cílový identifikátor odpovídá uvedenému identifikátoru odpovědi.

Model samozřejmě vyžaduje, aby kontejner klienta a identifikátor vygenerovaný klientem pro cíl odpovědi byly jedinečné pro všechny klienty a z bezpečnostních důvodů také obtížné předpovědět.

Výměny zpráv používané pro protokol pro správu a pro všechny ostatní protokoly, které používají stejný vzor, probíhají na úrovni aplikace; nedefinují nová gesta na úrovni protokolu AMQP. To je záměrné, aby aplikace mohly okamžitě využívat tato rozšíření s kompatibilními zásobníky AMQP 1.0.

Service Bus v současné době neimplementuje žádné základní funkce specifikace správy, ale model požadavků a odpovědí definovaný specifikací správy je základem pro funkci zabezpečení založené na deklarací identity a téměř všechny pokročilé funkce probírané v následujících částech:

Autorizace na základě deklarace identity

Koncept specifikace AMQP pro deklarace identity na základě autorizace (CBS) vychází ze vzoru žádosti a odpovědi specifikace správy a popisuje zobecněný model pro použití federovaných tokenů zabezpečení s AMQP.

Výchozí model zabezpečení AMQP probíraný v úvodu je založený na SASL a integruje se s metodou handshake připojení AMQP. Použití SASL má výhodu, že poskytuje rozšiřitelný model, pro který byla definována sada mechanismů, ze kterého se může formálně spoléhat na SASL. Mezi tyto mechanismy patří "PLAIN" pro přenos uživatelských jmen a hesel, "EXTERNAL" k vytvoření vazby na zabezpečení na úrovni TLS, "ANONYMOUS" k vyjádření absence explicitního ověřování/autorizace a široké škály dalších mechanismů, které umožňují předávat ověřování a/nebo autorizační přihlašovací údaje nebo tokeny.

Integrace SASL AMQP má dvě nevýhody:

• Všechny přihlašovací údaje a tokeny jsou vymezeny na připojení. Infrastruktura zasílání zpráv může chtít poskytovat diferencované řízení přístupu na základě jednotlivých entit; Například umožňuje nosný token odeslat do fronty A, ale ne do fronty B. S kontextem autorizace ukotveným u připojení není možné použít jedno připojení a přesto pro frontu A a frontu B používat různé přístupové tokeny.
• Přístupové tokeny jsou obvykle platné pouze po omezenou dobu. Tato platnost vyžaduje, aby uživatel pravidelně znovu inquire tokeny a poskytuje vystavitelům tokenů příležitost odmítnout vydání nového tokenu, pokud se změnila přístupová oprávnění uživatele. Připojení AMQP můžou trvat dlouhou dobu. Model SASL poskytuje možnost nastavit token pouze v době připojení, což znamená, že infrastruktura zasílání zpráv musí klienta odpojit, jakmile vyprší platnost tokenu, nebo musí přijmout riziko povolení trvalé komunikace s klientem, který má přístupová práva, může být v přechodné fázi odvolán.

Specifikace AMQP CBS implementovaná službou Service Bus umožňuje elegantní alternativní řešení obou těchto problémů: Umožňuje klientovi přidružit přístupové tokeny ke každému uzlu a aktualizovat tyto tokeny před vypršením jejich platnosti, aniž by přerušil tok zprávy.

CBS definuje virtuální uzel správy s názvem $cbs, který má poskytovat infrastruktura zasílání zpráv. Uzel pro správu přijímá tokeny jménem všech ostatních uzlů v infrastruktuře zasílání zpráv.

Gesto protokolu je výměna žádostí a odpovědí definovaná specifikací správy. To znamená, že klient vytvoří dvojici propojení s uzlem $cbs a pak předá požadavek na odchozí propojení a pak počká na odpověď na příchozím propojení.

Zpráva požadavku má následující vlastnosti aplikace:

Klíč	Volitelné	Typ hodnoty	Obsah hodnot
operation	No	string	put-token
type	No	string	Typ putování tokenu.
name	No	string	Cílová skupina, na kterou se token vztahuje.
expiration	Ano	časové razítko	Doba vypršení platnosti tokenu.

Vlastnost name identifikuje entitu, ke které se token přidružuje. Ve službě Service Bus se jedná o cestu k frontě nebo tématu nebo předplatnému. Vlastnost typu identifikuje typ tokenu:

Typ tokenu	Popis tokenu	Základní typ	Notes
jwt	Webový token JSON (JWT)	Hodnota AMQP (řetězec)
servicebus.windows.net:sastoken	Service Bus SAS Token	Hodnota AMQP (řetězec)	-

Tokeny poskytují práva. Service Bus ví o třech základních právech: "Send" umožňuje odesílání, "Listen" umožňuje příjem a "Manage" umožňuje manipulaci s entitami. Tokeny SAS služby Service Bus odkazují na pravidla nakonfigurovaná pro obor názvů nebo entitu a tato pravidla jsou nakonfigurovaná s právy. Podpis tokenu pomocí klíče přidruženého k tomuto pravidlu tak token vyjadřuje příslušná práva. Token přidružený k entitě pomocí put-tokenu umožňuje připojenému klientovi interakci s entitou podle práv tokenu. Odkaz, ve kterém klient převezme roli odesílatele , vyžaduje právo Odeslat. Převzetí role příjemce vyžaduje právo Naslouchat.

Zpráva odpovědi obsahuje následující hodnoty vlastností aplikace.

Klíč	Volitelné	Typ hodnoty	Obsah hodnot
status-code	No	int	Kód odpovědi HTTP [RFC2616].
status-description	Ano	string	Popis stavu

Klient může opakovaně volat put-token a pro libovolnou entitu v infrastruktuře zasílání zpráv. Tokeny jsou vymezeny na aktuálního klienta a ukotvené na aktuálním připojení, což znamená, že server při poklesu připojení zahodí všechny zachované tokeny.

Aktuální implementace služby Service Bus umožňuje CBS pouze ve spojení s metodou SASL "ANONYMOUS". Před metodou handshake SASL musí vždy existovat připojení SSL/TLS.

Zvolený klient AMQP 1.0 proto musí podporovat mechanismus ANONYMOUS. Anonymní přístup znamená, že počáteční metoda handshake připojení, včetně vytvoření počáteční relace, probíhá bez toho, aby služba Service Bus věděla, kdo připojení vytváří.

Po navázání připojení a relace jsou jedinými povolenými operacemi připojení k uzlu $cbs a odeslání požadavku put-token . Platný token musí být úspěšně nastaven pomocí požadavku put-token pro určitý uzel entity do 20 sekund od navázání připojení, jinak se připojení jednostranně vyřadí službou Service Bus.

Klient je následně zodpovědný za sledování vypršení platnosti tokenu. Když vyprší platnost tokenu, Service Bus okamžitě zahodí všechny odkazy na připojení k příslušné entitě. Aby nedocházelo k problémům, klient může token uzlu kdykoli nahradit novým uzlem prostřednictvím virtuálního uzlu správy $cbs gestem put-token a bez toho, aby se dostal do způsobu přenosu datové části, který proudí na různých propojeních.

Funkce pro odesílání

Send-via / Transfer sender je funkce, která umožňuje službě Service Bus předávat danou zprávu cílové entitě prostřednictvím jiné entity. Tato funkce se používá k provádění operací napříč entitami v jedné transakci.

Pomocí této funkce vytvoříte odesílatele a vytvoříte odkaz na via-entity. Při navazování odkazu se předávají další informace pro vytvoření skutečného cíle zpráv/přenosů na tomto odkazu. Po úspěšném připojení se všechny zprávy odeslané na tomto odkazu automaticky přepošle do cílové entity prostřednictvím entity.

Poznámka: Před vytvořením tohoto odkazu je nutné provést ověřování pro entitu i cílovou entitu.

Klient	Směr	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} )] )

Související obsah

Další informace o AMQP najdete v přehledu AMQP služby Service Bus.