Prozkoumání datových částí zpráv služby Service Bus a serializace
Zprávy obsahují datovou část a metadata. Metadata jsou ve formě vlastností páru klíč-hodnota a popisují datovou část a poskytují pokyny ke zpracování Service Bus a aplikacím. Tato metadata jsou někdy dostatečná k přenosu informací, které odesílatel chce sdělit příjemcům, a datová část zůstane prázdná.
Objektový model oficiálního klienta Service Bus pro .NET a Javu mapuje na protokoly drátů, které Service Bus podporuje.
Zpráva služby Service Bus se skládá z oddílu binární datové části, kterou Service Bus nikdy nezpracuje v žádném formuláři na straně služby, a dvě sady vlastností. Vlastnosti zprostředkovatele jsou definované systémem. Tyto předdefinované vlastnosti řídí funkce na úrovni zpráv uvnitř zprostředkovatele nebo se mapují na běžné a standardizované položky metadat. Vlastnosti uživatele jsou kolekce párů klíč-hodnota definovaných a nastavených aplikací.
Směrování zpráv a korelace
Podmnožina vlastností zprostředkovatele, konkrétně To, ReplyTo, ReplyToSessionIdMessageIdCorrelationIda SessionId, pomáhají aplikacím směrovat zprávy do konkrétních cílů. Následující vzory popisují směrování:
Jednoduchý požadavek/odpověď: Vydavatel odešle zprávu do fronty a očekává odpověď od příjemce zprávy. Vydavatel vlastní frontu pro příjem odpovědí. Adresa této fronty je obsažena ve
ReplyTovlastnosti odchozí zprávy. Když příjemce odpoví, zkopírujeMessageIdzpracovanou zprávu doCorrelationIdvlastnosti zprávy odpovědi a doručí zprávu do cíle označenéhoReplyTovlastností. Jedna zpráva může v závislosti na kontextu aplikace přinést více odpovědí.Žádost/odpověď vícesměrového vysílání: Jako varianta předchozího vzoru odešle vydavatel zprávu do tématu a více odběratelů může zprávu využívat. Každý z odběratelů může reagovat způsobem popsaným výše. Pokud
ReplyToodkazuje na téma, může být taková sada odpovědí zjišťování distribuována cílové skupině.Multiplexing: Tato funkce relace umožňuje multiplexování datových proudů souvisejících zpráv prostřednictvím jedné fronty nebo odběru, aby každá relace (nebo skupina) souvisejících zpráv identifikovaná odpovídajícími
SessionIdhodnotami byla směrována konkrétnímu příjemci, zatímco příjemce uchovává relaci pod zámkem. Další informace o relacích najdete tady.Multiplexed request/reply: Tato funkce relace umožňuje multiplexované odpovědi, což umožňuje několika vydavatelům sdílet frontu odpovědí.
ReplyToSessionIdNastavením může vydavatel dát jednomu nebo více příjemcům pokyn, aby tuto hodnotu zkopírovali doSessionIdvlastnosti zprávy odpovědi. Fronta nebo téma publikování nemusí být v relaci. Když se odešle zpráva, může vydavatel čekat na relaci s danouSessionIdpro materializaci ve frontě podmíněným přijetím příjemce relace.
Serializace datové části
Při přenosu nebo uložení uvnitř služby Service Bus je datová část vždy neprůrůzdný binární blok. Tato ContentType vlastnost umožňuje aplikacím popsat datovou část s navrhovaným formátem hodnot vlastností, které jsou popisem typu obsahu MIME podle RFC2045 IETF, application/json;charset=utf-8například .
Na rozdíl od variant Java nebo .NET Standard podporuje verze rozhraní .NET Framework rozhraní Service Bus API vytváření BrokeredMessage instancí předáním libovolných objektů .NET do konstruktoru.
Starší protokol SBMP serializuje objekty s výchozí binární serializátor, nebo serializátor, který je externě dodán. Protokol AMQP serializuje objekty do objektu AMQP. Příjemce může tyto objekty načíst metodou GetBody<T>() a zadat očekávaný typ. Pomocí AMQP se objekty serializují do grafu ArrayList AMQP a IDictionary<string,object> objektů a jakýkoli klient AMQP je může dekódovat.
I když je tato skrytá magie serializace pohodlná, pokud by aplikace měly převzít explicitní kontrolu nad serializací objektů a převést jejich objektové grafy na datové proudy před jejich zahrnutím do zprávy, měly by provést zpětnou operaci na straně příjemce. I když má AMQP výkonný model binárního kódování, je svázaný s ekosystémem zasílání zpráv AMQP a klienti HTTP mají potíže s dekódováním takových datových částí.