Service Bus-berichtpayloads en serialisatie verkennen

Voltooid

Berichten bevatten een nettolading en metagegevens. De metagegevens hebben de vorm van eigenschappen van sleutel-waardepaar en beschrijven de nettolading en geven instructies voor Service Bus en toepassingen. Af en toe is die metagegevens voldoende om de informatie over te dragen die de afzender wil communiceren met ontvangers en blijft de nettolading leeg.

Het objectmodel van de officiële Service Bus-clients voor .NET en Java wordt toegewezen aan en van de wire-protocollen die Service Bus ondersteunt.

Een Service Bus-bericht bestaat uit een sectie met binaire nettoladingen die Service Bus nooit verwerkt in een vorm aan de servicezijde en twee sets eigenschappen. De eigenschappen van de broker zijn door het systeem gedefinieerd. Deze vooraf gedefinieerde eigenschappen bepalen de functionaliteit op berichtniveau in de broker of ze worden toegewezen aan algemene en gestandaardiseerde metagegevensitems. De gebruikerseigenschappen zijn een verzameling sleutel-waardeparen die door de toepassing zijn gedefinieerd en ingesteld.

Berichtroutering en correlatie

Een subset van de brokereigenschappen, met name To, ReplyTo, ReplyToSessionId, MessageId, en CorrelationId, SessionIdhelpen toepassingen berichten naar bepaalde bestemmingen te routeren. In de volgende patronen wordt de routering beschreven:

• Eenvoudige aanvraag/antwoord: een uitgever verzendt een bericht naar een wachtrij en verwacht een antwoord van de gebruiker van het bericht. De uitgever is eigenaar van een wachtrij om de antwoorden te ontvangen. Het adres van die wachtrij bevindt zich in de ReplyTo eigenschap van het uitgaande bericht. Wanneer de consument reageert, kopieert deze het MessageId bericht naar de CorrelationId eigenschap van het antwoordbericht en levert het bericht aan de bestemming die door de ReplyTo eigenschap wordt aangegeven. Eén bericht kan meerdere antwoorden opleveren, afhankelijk van de toepassingscontext.

• Multicast-aanvraag/antwoord: als een variant van het voorgaande patroon verzendt een uitgever het bericht naar een onderwerp en komen meerdere abonnees in aanmerking om het bericht te gebruiken. Elk van de abonnees kan reageren op de manier die eerder is beschreven. Als ReplyTo verwijst naar een onderwerp, kan een dergelijke reeks detectieantwoorden worden gedistribueerd naar een doelgroep.

• Multiplexing: met deze sessiefunctie kunnen streams van gerelateerde berichten worden ge multiplexeerd via één wachtrij of abonnement, zodat elke sessie (of groep) gerelateerde berichten, geïdentificeerd door overeenkomende SessionId waarden, worden doorgestuurd naar een specifieke ontvanger terwijl de ontvanger de sessie onder vergrendeling houdt. Meer informatie over de details van sessies vindt u hier.

• Multiplexed request/reply: Met deze sessiefunctie kunt u multiplexed antwoorden inschakelen, zodat verschillende uitgevers een antwoordwachtrij kunnen delen. Door deze instelling in te stellen ReplyToSessionId, kan de uitgever een of meer consumenten instrueren die waarde naar de SessionId eigenschap van het antwoordbericht te kopiëren. De publicatiewachtrij of het onderwerp hoeft niet sessiebewust te zijn. Wanneer het bericht wordt verzonden, kan de uitgever wachten op een sessie met de opgegeven SessionId om in de wachtrij te materialiseren door voorwaardelijk een sessieontvanger te accepteren.

Routering binnen een Service Bus-naamruimte maakt gebruik van regels voor automatisch koppelen en onderwerpabonnementen. Routering tussen naamruimten kan worden uitgevoerd met behulp van Azure LogicApps. De To eigenschap is gereserveerd voor toekomstig gebruik. Toepassingen die routering implementeren, moeten dit doen op basis van gebruikerseigenschappen en niet op de To eigenschap leunen. Als u dit nu doet, worden er echter geen compatibiliteitsproblemen veroorzaakt.

Serialisatie van nettolading

Wanneer de nettolading onderweg is of is opgeslagen in Service Bus, is de nettolading altijd een ondoorzichtig binair blok. Met ContentType de eigenschap kunnen toepassingen de nettolading beschrijven, met de voorgestelde indeling voor de eigenschapswaarden als een MIME-beschrijving van het inhoudstype volgens IETF-RFC2045, application/json;charset=utf-8bijvoorbeeld.

In tegenstelling tot de Java- of .NET Standard-varianten ondersteunt de .NET Framework-versie van de Service Bus-API het maken van BrokeredMessage exemplaren door willekeurige .NET-objecten door te geven aan de constructor.

Het verouderde SBMP-protocol serialiseert objecten met de standaard binaire serialisatiefunctie of met een serialisatiefunctie die extern wordt geleverd. Het AMQP-protocol serialiseert objecten in een AMQP-object. De ontvanger kan deze objecten ophalen met de GetBody<T>() methode, die het verwachte type levert. Met AMQP worden de objecten geserialiseerd in een AMQP-grafiek van ArrayList en IDictionary<string,object> objecten, en elke AMQP-client kan deze decoderen.

Hoewel deze verborgen serialisatiemagie handig is, moeten toepassingen expliciet de controle over objectserialisatie overnemen en hun objectgrafieken omzetten in streams voordat ze in een bericht worden opgenomen, moeten ze de omgekeerde bewerking aan de ontvangerzijde uitvoeren. Hoewel AMQP een krachtig binair coderingsmodel heeft, is het gekoppeld aan het AMQP-berichtenecosysteem en HTTP-clients hebben problemen met het decoderen van dergelijke nettoladingen.