Utforska Service Bus-meddelandenyttolaster och serialisering

  • 3 minuter

Meddelanden har en nyttolast och metadata. Metadata är i form av nyckel/värde-paregenskaper och beskriver nyttolasten och ger hanteringsinstruktioner till Service Bus och program. Ibland räcker enbart dessa metadata för att överföra den information som avsändaren vill kommunicera med mottagare och nyttolasten förblir tom.

Objektmodellen för de officiella Service Bus-klienterna för .NET och Java mappar till och från de trådprotokoll som Service Bus stöder.

Ett Service Bus-meddelande består av ett binärt nyttolastavsnitt som Service Bus aldrig hanterar i något formulär på tjänstsidan och två uppsättningar egenskaper. Egenskaperna för asynkron meddelandekö är systemdefinierade. Dessa fördefinierade egenskaper styr antingen funktionerna på meddelandenivå i asynkron meddelandekö eller mappar till vanliga och standardiserade metadataobjekt. Användaregenskaperna är en samling nyckel/värde-par som definierats och angetts av programmet.

Meddelanderoutning och korrelation

En delmängd av asynkrona egenskaper, särskilt To, ReplyTo, ReplyToSessionId, MessageId, CorrelationIdoch SessionId, hjälper program att dirigera meddelanden till specifika mål. Följande mönster beskriver routningen:

  • Enkel begäran/svar: En utgivare skickar ett meddelande till en kö och förväntar sig ett svar från meddelandekonsumenten. Utgivaren äger en kö för att ta emot svaren. Adressen till kön finns i ReplyTo egenskapen för det utgående meddelandet. När konsumenten svarar kopierar MessageId den det hanterade meddelandet till CorrelationId egenskapen för svarsmeddelandet och levererar meddelandet till det mål som anges av ReplyTo egenskapen. Ett meddelande kan ge flera svar, beroende på programkontexten.

  • Multicast-begäran/svar: Som en variant av det tidigare mönstret skickar en utgivare meddelandet till ett ämne och flera prenumeranter blir berättigade att använda meddelandet. Var och en av prenumeranterna kan svara på det sätt som beskrevs tidigare. Om ReplyTo pekar på ett ämne kan en sådan uppsättning identifieringssvar distribueras till en målgrupp.

  • Multiplexering: Den här sessionsfunktionen möjliggör multiplexering av strömmar av relaterade meddelanden via en enda kö eller prenumeration, så att varje session (eller grupp) med relaterade meddelanden, som identifieras med matchande SessionId värden, dirigeras till en specifik mottagare medan mottagaren håller sessionen under lås. Läs mer om information om sessioner här.

  • Multiplexerad begäran/svar: Den här sessionsfunktionen aktiverar multiplexade svar, vilket gör att flera utgivare kan dela en svarskö. Genom att ange ReplyToSessionIdkan utgivaren instruera en eller flera konsumenter att kopiera värdet till SessionId egenskapen för svarsmeddelandet. Publiceringskön eller ämnet behöver inte vara sessionsmedveten. När meddelandet skickas kan utgivaren vänta på en session med angiven SessionId för att materialisera i kön genom att villkorligt acceptera en sessionsmottagare.

Routning i ett Service Bus-namnområde använder regler för automatisk länkning och ämnesprenumeration. Routning mellan namnområden kan utföras med Hjälp av Azure LogicApps. Egenskapen To är reserverad för framtida användning. Program som implementerar routning bör göra det baserat på användaregenskaper och inte luta sig mot To egenskapen. Men om du gör det nu orsakas inte kompatibilitetsproblem.

Serialisering av nyttolast

När nyttolasten överförs eller lagras i Service Bus är den alltid ett täckande binärt block. Egenskapen ContentType gör det möjligt för program att beskriva nyttolasten, där det föreslagna formatet för egenskapsvärdena är en beskrivning av MIME-innehållstyp enligt IETF-RFC2045, application/json;charset=utf-8till exempel .

Till skillnad från Java- eller .NET Standard-varianterna har .NET Framework-versionen av Service Bus-API:et stöd för att skapa BrokeredMessage instanser genom att skicka godtyckliga .NET-objekt till konstruktorn.

Det äldre SBMP-protokollet serialiserar objekt med standardbinär serialiserare eller med en serialiserare som tillhandahålls externt. AMQP-protokollet serialiserar objekt till ett AMQP-objekt. Mottagaren kan hämta dessa objekt med GetBody<T>() metoden och ange den förväntade typen. Med AMQP serialiseras objekten till en AMQP-graf över ArrayList och IDictionary<string,object> objekt, och alla AMQP-klienter kan avkoda dem.

Även om den här dolda serialiseringsmagien är praktisk, bör program ta explicit kontroll över objektserialisering och omvandla objektdiagram till strömmar innan de inkluderas i ett meddelande, men de bör utföra den omvända åtgärden på mottagarsidan. AMQP har en kraftfull binär kodningsmodell, men den är knuten till AMQP-meddelandeekosystemet och HTTP-klienter har problem med att avkoda sådana nyttolaster.