(0) exportieren Drucken
Alle erweitern

Best Practices zur Nutzung der Azure-Servicebus-API für Brokermessaging

Letzte Aktualisierung: März 2014

Autor: Valery Mizonov

Mitwirkende: Seth Manheim, Paolo Salvatori, James Podgorski, Eric Lam, Jayu Katti

Dieser Artikel ist ein praktischer Leitfaden für Entwickler, die mit der .NET-verwalteten API für Brokermessaging in Microsoft Azure Service Bus arbeiten. Die in diesem Artikel enthaltenen Empfehlungen stammen direkt aus neueren Kundenprojekten. Bei der Implementierung realer Lösungen mit Servicebus haben wir einige wichtige Best Practices und bislang weniger bekannte Fakten kennen gelernt. Diese helfen Ihnen, die Zuverlässigkeit und Leistung von Lösungen, die die neuen Brokermessagingfunktionen in Servicebus nutzen, zu steigern. Dieser Artikel soll diese praktischen Erfahrungen in der Entwicklercommunity bekannt machen.

Relaymessaging oder Brokermessaging

Microsoft Azure Service Bus stellt zwei umfassende Messaginglösungen bereit. Die erste Lösung wird über einen zentralen Relaydienst (mit hoher Lastenverteilung) in der Cloud bereitgestellt. Sie unterstützt eine Vielzahl von Transportprotokollen und Webdienststandards einschließlich SOAP, WS-* und REST. Der Relaydienst unterstützt unidirektionales Messaging, Anforderungs-/Antwortmessaging und Peer-zu-Peer-Messaging. Das Prinzip, das dieser Art von Messaginglösung zugrunde liegt, wird als Relaymessaging bezeichnet. Beim Relaymessaging stellt ein lokaler oder cloudbasierter Dienst über einen ausgehenden Port eine Verbindung mit dem Relaydienst her und erstellt dann einen bidirektionaler Kommunikationssocket, der an eine bestimmte Rendevouzadresse gebunden ist. Der Client muss nicht wissen, wo sich der Dienst befindet, und der lokale Dienst muss keine eingehenden Ports in der Firewall geöffnet haben. Das Relaymessaging bietet viele Vorteile, erfordert jedoch, dass sowohl der Server als auch der Client gleichzeitig online sind, damit Nachrichten gesendet und empfangen werden können. Relaymessaging ist seit der ersten Version von Servicebus verfügbar.

Die zweite Messaginglösung bietet Funktionen für Brokermessaging. Das Brokermessaging kann auch als asynchrones oder "vorübergehend entkoppeltes" Messaging bezeichnet werden. Producer (Absender) und Consumer (Empfänger) müssen nicht zur gleichen Zeit online sein. Von der Messaginginfrastruktur werden zuverlässig Nachrichten gespeichert, bis die Empfängerseite bereit ist, diese entgegenzunehmen. Dadurch können die Komponenten der verteilten Anwendung freiwillig (z. B. zu Wartungszwecken) oder aufgrund eines Komponentenausfalls getrennt sein, ohne dass das ganze System betroffen ist. Darüber hinaus muss die empfangende Anwendung möglicherweise nur zu bestimmten Tageszeiten online sein, z. B. bei einem Bestandsverwaltungssystem, das nur am Ende eines Geschäftstages ausgeführt werden muss.

Die Kernkomponenten der Servicebus-Infrastruktur für Brokermessaging bilden Warteschlangen, Themen und Abonnements. Durch diese Komponenten werden neue asynchrone Messagingszenarien ermöglicht, z. B. für die vorübergehende Entkopplung, Veröffentlichung/Abonnements, Lastenverteilung und Lastenausgleich. Weitere Informationen zu diesen Szenarien finden Sie im Abschnitt über zusätzliche Ressourcen.

Übersicht über die Brokermessaging-API

Im gesamten Leitfaden finden Sie zahlreiche Verweise auf verschiedene Komponenten, Klassen und Typen, die in der .NET-verwalteten API für das Brokermessaging verfügbar sind. Damit Sie die Zusammenhänge besser nachvollziehen können, werden einige der wichtigsten APIs aufgelistet, durch die die Brokermessagingfunktionen von Servicebus bereitgestellt und unterstützt werden.

Bei den folgenden Klassen handelt es sich um die meistverwendeten API-Member aus dem Microsoft.ServiceBus-Namespace und dem Microsoft.ServiceBus.Messaging-Namespace, die bei der Entwicklung einer Lösung für Brokermessaging häufig eine Rolle spielen:

 

Klassenname

Beschreibung

BrokeredMessage

Stellt die Kommunikationseinheit zwischen Servicebus-Clients dar. Die serialisierten Instanzen der BrokeredMessage-Objekte werden übertragen, wenn Messagingclients über Warteschlangen und Themen kommunizieren.

QueueClient

Stellt ein Messagingobjekt dar, das das Senden und Empfangen von Nachrichten aus einer Servicebus-Warteschlange ermöglicht.

QueueDescription

Stellt ein Metadatenobjekt dar, das eine Servicebus-Warteschlange einschließlich Warteschlangenpfad, Verhaltenseinstellungen (z. B. Sperrdauer, Standardgültigkeitsdauer (TTL), Duplikaterkennung) und Informationsdatenpunkte (z. B. aktuelle Länge und Größe von Warteschlangen) beschreibt.

TopicClient

Stellt ein Messagingobjekt dar, das das Senden von Nachrichten an ein Servicebus-Thema ermöglicht.

TopicDescription

Stellt ein Metadatenobjekt dar, das ein Servicebus-Thema einschließlich Themenpfad, Verhaltenseinstellungen (z. B. Duplikaterkennung) und Informationsdatenpunkten (z. B. aktuelle Größe und maximale Themengröße) beschreibt.

SubscriptionClient

Stellt ein Messagingobjekt dar, das den Empfang von Nachrichten von einem Servicebus-Abonnement ermöglicht.

SubscriptionDescription

Stellt ein Metadatenobjekt dar, das ein Servicebus-Abonnement einschließlich Abonnementnamen, Themenpfad, Verhaltenseinstellungen (z. B. Sitzungsunterstützung, Standardgültigkeitsdauer (TTL), Sperrdauer) und Informationsdatenpunkten (z. B. die aktuelle Anzahl von Nachrichten) beschreibt.

NamespaceManager

Stellt ein Verwaltungsobjekt für Laufzeitvorgänge bei Servicebus-Messagingentitäten (Warteschlangen, Themen, Abonnements, Regeln) dar. Dazu gehören die Erstellung, der Abruf, das Löschen und die Bestätigung, dass sie vorhanden sind.

MessagingFactory

Stellt ein Factoryobjekt dar, das für das Instanziieren, die Nachverfolgung und Verwaltung des Lebenszyklus von Messagingentitätsclients wie TopicClient, QueueClient und SubscriptionClient zuständig ist.

MessageReceiver

Stellt ein abstraktes Messagingobjekt dar, das die umfangreichen Messagingfunktionen mit Schwerpunkt auf Nachrichtenempfangsvorgängen unterstützt.

MessageSender

Stellt ein abstraktes Messagingobjekt dar, das die umfangreichen Messagingfunktionen mit Schwerpunkt auf Nachrichtensendevorgängen unterstützt.

MessageSession

Stellt eine Nachrichtensitzung dar, die das Gruppieren zusammengehöriger Nachrichten unterstützt, um sie in einer Transaktion zu verarbeiten.

Filter

Stellt ein abstraktes Metadatenobjekt dar, das aus einem Filterausdruck und einer zugehörigen Aktion besteht, die im Modul zur Auswertung des Servicebus-Abonnements ausgeführt wird. Die Filter-Klasse legt den Zweck einer Basisklasse für TrueFilter, FalseFilter, SqlFilter und CorrelationFilter fest, die die Implementierungen eines Metadatenobjekts für einen bestimmten Filtertyp darstellen.

TokenProvider

Stellt ein Factoryobjekt dar, das Zugriff auf die verschiedenen Typen von Sicherheitstokenanbietern ermöglicht, die für die Beschaffung von SAML-, Shared Secret- und Simple Web-Tokens zuständig sind.

Es wird empfohlen, dass Sie sich mit diesen API-Artefakten vertraut machen, damit Sie Ihre erste Brokermessaginglösung mit Servicebus problemlos erstellen können. Beachten Sie, dass diese Liste nicht alle Klassen enthält, die in der Brokermessaging-API vorhanden sind. Eine umfassende Darstellung aller API-Member finden Sie in der MSDN-Dokumentation.

Best Practices in der Brokermessaging-API

Die Themen in diesem Abschnitt basieren auf bestimmten Empfehlungen, die aus praktischen Erfahrungen mit der .NET-verwalteten API für Brokermessaging übernommen wurden. Das Ziel dieser Empfehlungen besteht darin, Entwicklern die Verwendung der in den folgenden Abschnitten erörterten Techniken und Prinzipien näher zu bringen, damit sie zuverlässige Messaginglösungen bereitstellen können. Dieser Abschnitt umfasst folgende Themen:

Community-Beiträge

Anzeigen:
© 2014 Microsoft