Erkunden von Service Bus-Nachrichtennutzdaten und Serialisierung

  • 3 Minuten

Nachrichten enthalten eine Nutzlast und Metadaten. Die Metadaten sind Schlüssel-Wert-Paareigenschaften, 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 Ü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 werden vom System definiert. 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.

Nachrichtenrouting und -korrelation

Eine Teilmenge der Brokereigenschaften, insbesondere To, ReplyTo, ReplyToSessionId, MessageId, CorrelationId und SessionId, unterstützen Anwendungen beim Weiterleiten von Nachrichten an bestimmte Ziele. Die folgenden Muster beschreiben das Routing:

  • Einfache Anforderung/Antwort: Ein Herausgeber sendet eine Nachricht an eine Warteschlange und erwartet eine Antwort vom Nachrichtenconsumer. Der Herausgeber besitzt eine Warteschlange, um die Antworten zu empfangen. Die Adresse dieser Warteschlange ist in der ReplyTo-Eigenschaft der ausgehenden Nachricht enthalten. Wenn der Consumer antwortet, kopiert er die MessageId der verarbeiteten Nachricht in die Eigenschaft CorrelationId der Antwortnachricht und stellt die Nachricht an das über die Eigenschaft ReplyTo angegebene Ziel zu. 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. Wenn ReplyTo auf ein Thema verweist, kann ein solcher Satz von Ermittlungsantworten an eine Zielgruppe verteilt werden.

  • Multiplexing: Dieses Sitzungsfeature ermöglicht das Multiplexing von Datenströmen verwandter Nachrichten über eine einzelne Warteschlange oder ein Abonnement, sodass jede Sitzung (oder Gruppe) verwandter Nachrichten, die durch übereinstimmende SessionId-Werte identifiziert werden, an einen bestimmten Empfänger geroutet wird, während der Empfänger die Sitzung gesperrt hält. Weitere Informationen zu den Details der Sitzungen finden Sie hier.

  • Multiplexanforderung/-antwort: Dieses Sitzungsfeature ermöglicht Multiplexantworten, wodurch mehrere Herausgeber eine Antwortwarteschlange gemeinsam nutzen können. Durch Festlegen von ReplyToSessionId kann der Herausgeber einen oder mehrere Consumer anweisen, diesen Wert in die Eigenschaft SessionId der Antwortnachricht zu kopieren. Die Veröffentlichungswarteschlange bzw. das Veröffentlichungsthema muss nicht sitzungsabhängig sein. Beim Senden der Nachricht kann der Herausgeber dann auf eine Sitzung mit der angegebenen SessionId warten, um die Warteschlange zu materialisieren, indem er einen Sitzungsempfänger bedingt akzeptiert.

Das Routing innerhalb eines Service Bus-Namespaces verwendet Ketten für automatische Weiterleitung und Regeln für Themenabonnements. Namespaceübergreifendes Routing kann mithilfe von Azure Logic Apps ausgeführt werden. Die To-Eigenschaft ist für die zukünftige Verwendung reserviert. Anwendungen, die Routing implementieren, 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, indem beliebige .NET-Objekte an den Konstruktor übergeben werden.

Das SBMP-Legacyprotokoll serialisiert Objekte mit dem standardmäßigen binären Serialisierungsmodul oder mit einem extern bereitgestellten Serialisierungsmodul. Das AMQP-Protokoll serialisiert Objekte in ein AMQP-Objekt. 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.

Wenngleich diese Methode der versteckten Serialisierung praktisch ist, sollten Anwendungen die explizite Steuerung der Objektserialisierung übernehmen und die jeweiligen Objektgraphen in Streams umwandeln, bevor sie diese in eine Nachricht einbinden (auf Empfängerseite sollte der umgekehrte Vorgang erfolgen). 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.