Teilen über

Nachrichten, Nutzlasten und Serialisierung

  • Artikel

Microsoft Azure Service Bus verarbeitet Nachrichten. Nachrichten enthalten eine Nutzlast und Metadaten. Die Metadaten sind Schlüssel-Wertpaare, die die Nutzlast beschreiben und Service Bus und Anwendungen Verarbeitungsanweisungen geben. Gelegentlich reichen allein diese Metadaten aus, um die Informationen zu übermitteln, die der Absender den Empfängern vermitteln möchte, und die Nutzlast bleibt leer.

Das Objektmodell der offiziellen Service Bus-Clients für. NET und Java spiegelt die abstrakte Service Bus-Nachrichtenstruktur der Übertragungsprotokolle wider, die Service Bus unterstützt.

Eine Service Bus-Nachricht besteht aus einem binären Nutzlastabschnitt, den Service Bus in keiner Form auf Dienstseite verarbeitet, und zwei Gruppen von Eigenschaften. Die Brokereigenschaften sind vom System vordefiniert. Diese vordefinierten Eigenschaften steuern entweder die Funktionalität auf Nachrichtenebene innerhalb des Brokers oder sind gemeinsamen und standardisierten Metadatenelementen zugeordnet. Die Benutzereigenschaften sind eine Sammlung von Schlüssel-Wert-Paaren, die von der Anwendung definiert und festgelegt werden können.

Die vordefinierten Brokereigenschaften sind in der folgenden Tabelle aufgeführt. Die Namen werden mit allen offiziellen Client-APIs und auch im JSON-Objekt BrokerProperties der HTTP-Protokollzuordnung verwendet.

Die entsprechenden Namen auf AMQP-Protokollebene (Advanced Message Queuing Protocol) sind in Klammern aufgelistet. Während die folgenden Namen die Pascal-Case-Groß-/Kleinschreibung verwenden, wird in JavaScript- und Python-Clients Camel bzw. Snake Casing verwendet.

Eigenschaftenname Beschreibung
ContentType (content-type) Beschreibt optional die Nutzlast der Nachricht mit einem Deskriptor im Format RFC2045, Abschnitt 5. Beispiel: application/json.
CorrelationId (correlation-id) Ermöglicht einer Anwendung, einen Kontext für die Nachricht zum Zweck der Korrelation anzugeben, z.B. die MessageId einer Nachricht, auf die geantwortet wird.
DeadLetterSource Wird nur in Nachrichten festgelegt, die unzustellbar sind und später automatisch aus der Warteschlange für unzustellbare Nachrichten an eine andere Entität weitergeleitet werden. Gibt die Entität an, in der die Nachricht unzustellbar war. Diese Eigenschaft ist schreibgeschützt.
DeliveryCount

Anzahl der Zustellversuche dieser Nachricht. Die Anzahl wird erhöht, wenn eine Nachrichtensperre abläuft oder die Nachricht vom Empfänger explizit abgewiesen wird. Diese Eigenschaft ist schreibgeschützt.

Die Anzahl wird nicht erhöht, wenn die zugrunde liegende AMQP-Verbindung geschlossen ist.
EnqueuedSequenceNumber Bei Nachrichten, die automatisch weitergeleitet wurden, entspricht diese Eigenschaft der Sequenznummer, die der Nachricht zum Zeitpunkt ihrer ursprünglichen Übermittlung zugewiesen wurde. Diese Eigenschaft ist schreibgeschützt.
EnqueuedTimeUtc Der UTC-Moment, in dem die Nachricht angenommen und in der Entität gespeichert wurde. Dieser Wert kann als autoritative und neutrale Eingangszeitangabe verwendet werden, wenn der Empfänger der Uhr des Absenders nicht vertrauen möchte. Diese Eigenschaft ist schreibgeschützt.
Expires​AtUtc (absolute-expiry-time) Der UTC-Moment, in dem die Nachricht zum Entfernen markiert wird und wegen ihres Ablaufs nicht mehr von der Entität abgerufen werden kann. Der Ablauf wird von der TimeToLive-Eigenschaft gesteuert, die anhand von „EnqueuedTimeUtc+TimeToLive“ berechnet wird. Diese Eigenschaft ist schreibgeschützt.
Label oder Subject (subject) Diese Eigenschaft ermöglicht der Anwendung, dem Empfänger auf standardisierte Weise den Zweck der Nachricht anzuzeigen, ähnlich einer Betreffzeile für E-Mails.
Locked​Until​Utc Bei Nachrichten, die unter einer Sperre (Empfangsmodus „peek-lock“, nicht vor der Übereinkunft) abgerufen werden, entspricht diese Eigenschaft dem UTC-Moment, bis zu dem die Nachricht in der Warteschlange bzw. im Abonnement gesperrt gehalten wird. Nach Ablauf der Sperre wird DeliveryCount erhöht, und die Nachricht steht wieder zum Abruf zur Verfügung. Diese Eigenschaft ist schreibgeschützt.
Lock​Token Das Sperrtoken ist ein Verweis auf die Sperre, die vom Broker im Empfangsmodus peek-lock gehalten wird. Das Token kann dazu verwendet werden, die Sperre mithilfe der Deferral-API dauerhaft zu fixieren und damit die Nachricht aus dem normalen Zustellungsfluss zu entfernen. Diese Eigenschaft ist schreibgeschützt.
Message​Id (message-id) Der Nachrichtenbezeichner ist ein von der Anwendung definierter Wert, der die Nachricht und ihre Nutzlast eindeutig identifiziert. Der Bezeichner ist eine Zeichenfolge in freier Form und kann eine GUID oder einen aus dem Anwendungskontext abgeleiteten Bezeichner widerspiegeln. Bei Aktivierung erkennt und entfernt die Funktion Duplikaterkennung zweite und weitere Übermittlungen von Nachrichten mit derselben MessageId.
Partition​Key Für partitionierte Entitäten ermöglicht das Festlegen dieses Werts, verwandte Nachrichten derselben internen Partition zuzuweisen, sodass die Reihenfolge der Übermittlung ordnungsgemäß aufgezeichnet wird. Die Partition wird von einer Hashfunktion über diesen Wert ausgewählt und kann nicht direkt ausgewählt werden. Bei sitzungsabhängigen Elementen überschreibt die SessionId-Eigenschaft diesen Wert.
Reply​To (reply-to) Dieser optionale und von der Anwendung definierte Wert ist eine Standardmethode, einen Antwortpfad zum Empfänger der Nachricht auszudrücken. Wenn ein Absender eine Antwort erwartet, legt er den Wert auf den absoluten oder relativen Pfad der Warteschlange oder des Themas fest, an den bzw. das die Antwort gesendet werden soll.
Reply​To​Session​Id (reply-to-group-id) Dieser Wert ergänzt die ReplyTo-Informationen und gibt an, welche SessionId für die Antwort festgelegt werden soll, wenn sie an die Antwortentität gesendet wird.
Scheduled​Enqueue​Time​Utc Für Nachrichten, die erst nach einer Verzögerung zum Abruf zur Verfügung gestellt werden, definiert diese Eigenschaft den UTC-Moment, in dem die Nachricht logisch in die Warteschlange gestellt, sequenziert und dadurch zum Abruf bereitgestellt wird.
Sequence​Number Die Sequenznummer ist eine eindeutige ganze 64-Bit-Zahl, die einer Nachricht zugeordnet wird, sobald sie vom Broker akzeptiert und gespeichert wird, und fungiert als ihr tatsächlicher Bezeichner. Bei partitionierte Entitäten stellen die obersten 16 Bits den Partitionsbezeichner dar. Sequenznummern erhöhen sich monoton und sind lückenlos. Sie werden auf 0 zurückgesetzt, sobald der 48-64-Bit-Bereich ausgeschöpft ist. Diese Eigenschaft ist schreibgeschützt.
Session​Id (group-id) Bei sitzungsabhängigen Entitäten gibt dieser von der Anwendung definierte Wert die Sitzungszugehörigkeit der Nachricht an. Nachrichten mit demselben Sitzungsbezeichner unterliegen einer zusammenfassenden Sperre und ermöglichen eine Verarbeitung in exakter Reihenfolge und Demultiplexing. Bei Entitäten, die nicht sitzungsabhängig sind, wird dieser Wert ignoriert.
Time​To​Live Dieser Wert ist die relative Dauer, nach der die Nachricht abläuft, beginnend mit dem Moment, in dem sie vom Broker akzeptiert und gespeichert wurde, wie in EnqueueTimeUtc erfasst. Falls nicht explizit festgelegt, ist der angenommene Wert der DefaultTimeToLive-Wert für die jeweilige Warteschlange oder das jeweilige Thema. Ein TimeToLive-Wert auf Nachrichtenebene darf nicht höher als die DefaultTimeToLive-Einstellung der Entität sein. Wenn es länger ist, wird es automatisch angepasst.
To (to) Diese Eigenschaft ist für die künftige Verwendung in Routingszenarien reserviert und wird derzeit vom Broker selbst ignoriert. Anwendungen können diesen Wert in regelbasierten Verkettungsszenarien für die automatische Weiterleitung verwenden, um das beabsichtigte logische Ziel der Nachricht anzugeben.
Via​Partition​Key Wenn eine Nachricht über eine Übertragungswarteschlange in den Bereich einer Transaktion gesendet wird, wählt dieser Wert die Partition der Übertragungswarteschlange aus.

Das abstrakte Nachrichtenmodell ermöglicht es, eine Nachricht über HTTP in eine Warteschlange zu stellen und über AMQP abzurufen. In beiden Fällen sieht die Nachricht im Kontext des jeweiligen Protokolls normal aus. Die Brokereigenschaften werden nach Bedarf übersetzt und die Benutzereigenschaften der am besten geeigneten Stelle im jeweiligen Protokollnachrichtenmodell zugeordnet. In HTTP gibt es eine direkte Zuordnung zwischen Benutzereigenschaften und HTTP-Headern. In AMQP gibt es eine Zuordnung zwischen Benutzereigenschaften und der Zuordnung application-properties.

Nachrichtenrouting und -korrelation

Eine Teilmenge der zuvor beschriebenen Brokereigenschaften, insbesondere To, ReplyTo, ReplyToSessionId, MessageId, CorrelationId und SessionId, wird verwendet, um Anwendungen beim Weiterleiten von Nachrichten an bestimmte Ziele zu unterstützen. Um dieses Feature zu veranschaulichen, betrachten Sie einige Muster:

  • Einfache Anforderung/Antwort: Ein Herausgeber sendet eine Nachricht in eine Warteschlange und erwartet eine Antwort vom Empfänger der Nachricht. Um die Antwort zu empfangen, besitzt der Herausgeber eine Warteschlange, in die die Antworten zugestellt werden sollen. Die Adresse der Warteschlange wird in der ReplyTo-Eigenschaft der ausgehenden Nachricht ausgedrückt. Wenn der Empfänger antwortet, kopiert er die MessageId der verarbeiteten Nachricht in die CorrelationId-Eigenschaft der Antwortnachricht und übermittelt die Nachricht an das von der ReplyTo-Eigenschaft angegebene Ziel. Je nach Anwendungskontext kann eine Nachricht mehrere Antworten erhalten.
  • Multicastanforderung/-antwort: Als Variation des vorherigen Musters sendet ein Herausgeber die Nachricht an ein Thema, und mehrere Abonnenten sind berechtigt, die Nachricht zu nutzen. Jeder der Abonnenten kann in der zuvor beschriebenen Weise antworten. Dieses Muster wird in Ermittlungs- oder Anwesenheitsüberprüfungsszenarien verwendet, wobei sich der Befragte normalerweise mit einer Benutzereigenschaft oder innerhalb der Nutzlast identifiziert. Wenn ReplyTo auf ein Thema verweist, können solche Ermittlungsantworten an eine Zielgruppe verteilt werden.
  • Multiplexing: Diese Sitzungsfunktion ermöglicht das Multiplexing von Streams verwandter Nachrichten über eine einzelne Warteschlange oder ein Abonnement. Jede Sitzung (oder Gruppe) verwandter Nachrichten, die durch übereinstimmende SessionId-Werte identifiziert werden, wird an einen bestimmten Empfänger geleitet wird, während der Empfänger die Sitzung gesperrt hält. Weitere Informationen zu den Details der Sitzungen finden Sie hier.
  • Multiplexanforderung/-antwort: Diese Sitzungsfunktion ermöglicht Multiplexantworten, sodass mehrere Herausgeber eine Antwortwarteschlange gemeinsam nutzen können. Durch Festlegen von ReplyToSessionId kann der Herausgeber die Consumer anweisen, diesen Wert in die SessionId-Eigenschaft der Antwortnachricht zu kopieren. Die Veröffentlichungswarteschlange bzw. das Veröffentlichungsthema muss nicht sitzungsabhängig sein. Beim Senden der Nachricht kann der Herausgeber dann gezielt darauf warten, dass eine Sitzung mit der angegebenen SessionId in die Warteschlange aufgenommen wird, indem er einen Sitzungsempfänger bedingt akzeptiert.

Das Routing innerhalb eines Service Bus-Namespaces kann mithilfe von Ketten für die automatische Weiterleitung und Regeln für Themenabonnements implementiert werden. Das Namespaces übergreifende Routing kann mithilfe von Azure Logic Apps realisiert werden. Wie in der vorangegangenen Liste angegeben, ist die To-Eigenschaft für die künftige Nutzung reserviert und kann künftig ggf. vom Broker mit einer speziell aktivierten Funktion interpretiert werden. Anwendungen, die das Routing implementieren möchten, sollten dies auf der Grundlage von Benutzereigenschaften tun und sich nicht auf die To-Eigenschaft stützen. Dies würde jedoch jetzt keine Kompatibilitätsprobleme verursachen.

Nutzlastserialisierung

Ob während des Transports oder bei Speicherung im Service Bus, die Nutzlast ist stets ein undurchsichtiger, binärer Block. Die ContentType-Eigenschaft ermöglicht es Anwendungen, die Nutzlast zu beschreiben, wobei das für die Eigenschaftswerte vorgeschlagene Format eine Beschreibung des MIME-Content-Typs gemäß IETF RFC2045 ist. Beispiel: application/json;charset=utf-8.

Im Gegensatz zu den Java- oder. NET Standard-Varianten unterstützt die. NET Framework-Version der Service Bus-API das Erstellen von BrokeredMessage-Instanzen durch Übergabe beliebiger. NET-Objekte an den Konstruktor.

Am 30. September 2026 werden die Azure Service Bus SDK-Bibliotheken „WindowsAzure.ServiceBus“, „Microsoft.Azure.ServiceBus“ und „com.microsoft.azure.servicebus“ eingestellt, da sie nicht den Azure SDK-Richtlinien entsprechen. Außerdem wird die Unterstützung des SBMP-Protokolls beendet, sodass Sie dieses Protokoll nach dem 30. September 2026 nicht mehr verwenden können. Migrieren Sie vor diesem Datum zu den neuesten Azure SDK-Bibliotheken, die wichtige Sicherheitsupdates und verbesserte Funktionen bieten.

Obwohl die älteren Bibliotheken noch über den 30. September 2026 hinaus verwendet werden können, erhalten sie keinen offiziellen Support und keine Updates mehr von Microsoft. Weitere Informationen finden Sie in der Ankündigung der Supporteinstellung.

Bei Verwendung des alten SBMP-Protokolls werden diese Objekte dann mit dem standardmäßigen binären Serialisierer oder mit einem extern bereitgestellten Serialisierer serialisiert. Das Objekt wird in ein AMQP-Objekt serialisiert. Der Empfänger kann diese Objekte mit der GetBody\<T>()-Methode abrufen und so den erwarteten Typ bereitstellen. Bei AMQP werden die Objekte in ein AMQP-Diagramm aus ArrayList- und IDictionary<string,object> -Objekten serialisiert und können von jedem AMQP-Client decodiert werden.

Am 30. September 2026 wird die Unterstützung des SBMP-Protokolls für Azure Service Bus eingestellt, sodass Sie dieses Protokoll nach dem 30. September 2026 nicht mehr verwenden können. Migrieren Sie vor diesem Datum mithilfe des AMQP-Protokolls zu den neuesten Azure Service Bus SDK-Bibliotheken, die wichtige Sicherheitsupdates und verbesserte Funktionen bieten.

Weitere Informationen finden Sie in der Ankündigung der Supporteinstellung.

Wenngleich diese Methode der versteckten Serialisierung praktisch ist, sollten Anwendungen die explizite Steuerung der Objektserialisierung übernehmen und ihre Objektgraphen in Streams umwandeln, bevor sie diese in eine Nachricht einbinden, und auf Empfängerseite das Gegenteil tun. Dies führt zu interoperablen Ergebnissen. AMQP verfügt zwar über ein leistungsfähiges binäres Codierungsmodell, ist aber an das AMQP-Messagingökosystem gebunden. HTTP-Clients haben Probleme, solche Nutzdaten zu decodieren.

Die .NET Standard- und Java-API-Varianten akzeptieren nur Bytearrays, was bedeutet, dass die Anwendung die Steuerung der Objektserialisierung übernehmen muss.

Beim Behandeln der Objektdeserialisierung aus der Nachrichtenpayload sollten Entwickler berücksichtigen, dass Nachrichten möglicherweise aus mehreren Quellen mit unterschiedlichen Serialisierungsmethoden eingehen. Dies kann auch passieren, wenn eine einzelne Anwendung weiterentwickelt wird, wobei alte Versionen möglicherweise weiterhin zusammen mit neueren Versionen ausgeführt werden. In diesen Fällen wird empfohlen, zusätzliche Deserialisierungsmethoden zu testen, wenn der erste Versuch bei der Deserialisierung fehlschlägt. Eine Bibliothek, die dies unterstützt, ist NServiceBus. Wenn alle Deserialisierungsmethoden fehlschlagen, empfiehlt es sich, die Nachricht als unzustellbar zu behandeln.

Nächste Schritte

Weitere Informationen zum Service Bus-Messaging finden Sie in folgenden Themen: