Exportieren (0) Drucken
Alle erweitern

Creating Applications that Use Service Bus Topics and Subscriptions

Letzte Aktualisierung: Februar 2015

Microsoft Azure Service Bus unterstützt einen Satz cloudbasierter, nachrichtenorientierter Middlewaretechnologien einschließlich zuverlässigen Message Queuings und dauerhaften Veröffentlichungs-/Abonnementmessagings. Dieser Artikel setzt auf den Informationen aus dem Artikel Erstellen von Anwendungen, die Service Bus-Warteschlangen verwenden auf und enthält eine Einführung in die Veröffentlichen/Abonnieren-Fähigkeiten, die von Servicebus-Themen bereitgestellt werden. Dieser Artikel ist nicht so angelegt, dass in ihm alle Features von Servicebus beschrieben werden. Sie werden in diesem Artikel aber genügend Informationen finden, um dieses Feature verwenden zu können.

In diesem Artikel wird das Einzelhandelsszenario fortgesetzt, das bereits in Erstellen von Anwendungen, die Service Bus-Warteschlangen verwenden verwendet wurde. Wie Sie sich sicherlich erinnern, müssen Verkaufsdaten aus einzelnen POS-Terminals an ein Lagerverwaltungssystem weitergeleitet (geroutet) werden, das anhand dieser Daten feststellt, ob Bestände aufgefüllt werden müssen. Jedes POS-Terminal berichtet seine Verkaufsdaten, indem es Nachrichten an die DataCollectionQueue-Warteschlange sendet, in der die Nachrichten verbleiben, bis sie vom Lagerverwaltungssystem empfangen wurden (siehe Abbildung):

Servicebus1

Um dieses Szenario zu entwickeln, wurde dem System eine neue Anforderung hinzugefügt: Der Ladenbesitzer möchte die Möglichkeit haben, in Echtzeit zu überwachen, wie der Laden läuft.

Damit diese Anforderung umgesetzt werden kann, muss das System den Strom der Verkaufsdaten "anzapfen". Nach wie vor soll jede Nachricht, die von einem der POS-Terminals gesendet wurde, an das Lagerverwaltungssystem gesendet werden, aber es ist eine weitere Kopie jeder Nachricht erforderlich, die dazu verwendet werden kann, dem Ladenbesitzer die Dashboardansicht zu präsentieren.

In einer solchen Situation, in der jede Nachricht von mehreren Beteiligten genutzt werden soll, können Sie das Servicebus-Feature Thema verwenden. Ein Thema bietet ein Veröffentlichungs-/Abonnementmuster, in dem jede veröffentlichte Nachricht den Abonnements zur Verfügung gestellt wird, die für das Thema registriert sind. Im Gegensatz dazu wird bei Warteschlangen jede Nachricht von einem einzigen Beteiligten (Consumer) empfangen.

Nachrichten werden auf gleiche Weise an ein Thema gesendet wie an eine Warteschlange. Nachrichten werden aber nicht direkt vom jeweiligen Thema empfangen, sondern sie werden von Abonnements empfangen. Sie können sich ein Abonnement für ein Thema als eine virtuelle Warteschlange vorstellen, die Kopien der Nachrichten empfängt, die an dieses Thema gesendet wurden. Nachrichten werden von einem Abonnement auf die gleiche Weise wie von einer Warteschlange empfangen.

Zurück zum Szenario. Der erste Schritt besteht darin, die Warteschlange durch ein Thema zu ersetzen und ein Abonnement hinzuzufügen, das von der Lagerverwaltungssystem-Komponente verwendet wird. Das System sieht nun wie folgt aus:

Servicebus2

Diese Konfiguration funktioniert identisch zu dem vorherigen warteschlangenbasierten Entwurf. Das heißt, an das Thema gesendete Nachrichten werden an das Abonnement Inventory weitergeleitet, aus dem das Lagerverwaltungssystem die Nachrichten abruft.

Damit das Managementdashboard unterstützt wird, muss ein zweites Abonnement für das Thema erstellt werden (siehe Abbildung):

Servicebus3

Bei dieser Konfiguration wird jede Nachricht von einem der POS-Terminals sowohl dem Abonnement Dashboard als auch dem Abonnement Inventory zur Verfügung gestellt.

Unter Erstellen von Anwendungen, die Service Bus-Warteschlangen verwenden ist beschrieben, wie Sie sich für ein Servicebus-Konto anmelden und einen Dienstnamespace erstellen. Um den Servicebus Dienstnamespace zu verwenden, muss eine Anwendung auf die Servicebus-Assembly verweisen, insbesondere "Microsoft.ServiceBus.dll". Die einfachste Möglichkeit zum Verweisen auf Servicebus-Abhängigkeiten besteht darin, das Servicebus-Nuget-Paket zu installieren. Sie finden die Assembly auch als Bestandteil des Azure- SDKs in den Azure--Clientbibliotheken für .NET. Der Download steht auf der Azure SDK-Downloadseite zur Verfügung.

Verwaltungsoptionen für Servicebus-Nachrichtenentitäten (Warteschlangen und Veröffentlichen/Abonnieren von Themen) werden über die NamespaceManager-Klasse durchgeführt. Servicebus verwendet ein anspruchsbasiertes Sicherheitsmodell, das mithilfe der Zugriffssteuerung für Microsoft Azure Active Directory (auch Zugriffssteuerungsdienst oder ACS) implementiert ist. Für die Erstellung einer NamespaceManager-Instanz für ein bestimmtes Dienstnamespace werden gültige Anmeldeinformationen benötigt. Die TokenProvider-Klasse funktioniert als Sicherheitstokenanbieter mit integrierten Factorymethoden, die einige der bekannten Tokenanbieter zurückgeben. Es wird eine CreateSharedAccessSignatureTokenProvider-Methode verwendet, um die SAS-Anmeldeinformationen (Shared Access Signature) aufzunehmen. Die NamespaceManager-Instanz wird anschließend mit der Basisadresse von Servicebus Dienstnamespace und dem Tokenanbieter erstellt.

Die NamespaceManager-Klasse enthält Methoden zum Erstellen, Aufzählen und Löschen von Nachrichtenentitäten. Der hier dargestellte Codeausschnitt zeigt, wie die NamespaceManager-Instanz erstellt und dazu verwendet wird, die DataCollectionTopic-Warteschlange zu erstellen.

Uri uri = ServiceBusEnvironment.CreateServiceUri("sb", "ingham-blog", string.Empty);
    string name = "RootManageSharedAccessKey";
    string key = "abcdefghijklmopqrstuvwxyz";
     
    TokenProvider tokenProvider = TokenProvider.CreateSharedAccessSignatureTokenProvider(name, key);
    NamespaceManager namespaceManager = new NamespaceManager(uri, tokenProvider);
 
    namespaceManager.CreateTopic("DataCollectionTopic");

Es gibt Überladungen der Methode CreateTopic, die es Ihnen ermöglichen, Eigenschaften des Themas festzulegen. Sie können z. B. die Standardgültigkeitsdauer (Time-To-Live, TTL) für Nachrichten festlegen, die an das Thema gesendet wurden. Fügen Sie als Nächstes die Abonnements Inventory und Dashboard hinzu.

namespaceManager.CreateSubscription("DataCollectionTopic", "Inventory");
    namespaceManager.CreateSubscription("DataCollectionTopic", "Dashboard");

Für Laufzeitoperationen auf Servicebus-Entitäten, z. B. zum Versenden und Empfangen von Nachrichten, muss die Anwendung zunächst ein MessagingFactory-Objekt erstellen. Analog zur NamespaceManager-Klasse wird die MessagingFactory-Instanz mit der Basisadresse von Dienstnamespace und dem Tokenanbieter erstellt.

MessagingFactory factory = MessagingFactory.Create(uri, tokenProvider);

Nachrichten, die an Servicebus-Themen gesendet und von diesen empfangen wurden, sind Instanzen der Klasse BrokeredMessage. Diese Klasse besteht aus einer Reihe von Standardeigenschaften (wie z. B. Label und TimeToLive), einem Wörterbuch für die Anwendungseigenschaften sowie beliebigen Anwendungsdaten in Textform. Anwendungen können beliebige serialisierbare Objekte (das folgende Beispiel verwendet ein SalesData-Objekt, das Verkaufsdaten aus einem POS-Terminal darstellt) für den Datenteil übergeben. DataContractSerializer wird zum Serialisieren des Objekts verwendet. Alternativ kann ein Stream angegeben werden.

BrokeredMessage bm = new BrokeredMessage(salesData);
    bm.Label = "SalesReport";
    bm.Properties["StoreName"] = "Redmond";
    bm.Properties["MachineID"] = "POS_1";

Die einfachste Möglichkeit, Nachrichten an das Thema zu senden, besteht darin, mit CreateMessageSender ein MessageSender-Objekt direkt aus der MessagingFactory-Instanz zu erstellen.

MessageSender sender = factory.CreateMessageSender("DataCollectionQueue");
    sender.Send(bm);

Wie beim Verwenden von Warteschlange ist der einfachste Weg, Nachrichten aus einem Abonnement abzurufen, das Verwenden eines MessageReceiver-Objekts, das Sie direkt aus der MessagingFactory mithilfe von CreateMessageReceiver erstellen können. Sie können einen der beiden Empfangsmodi (ReceiveAndDelete und PeekLock) verwenden. Weitere Informationen hierzu finden Sie unter Erstellen von Anwendungen, die Service Bus-Warteschlangen verwenden.

Wenn Sie ein MessageReceiver-Objekt für Abonnements erstellen, hat der Parameter entityPath die Form topicPath/subscriptions/subscriptionName. Daher muss, soll eine MessageReceiver-Instanz für das Abonnement Inventory des DataCollectionTopic-Themas erstellt werden, entityPath gleich DataCollectionTopic/subscriptions/Inventory sein. Der Code sieht wie folgt aus:

MessageReceiver receiver = factory.CreateMessageReceiver("DataCollectionTopic/subscriptions/Inventory");
    BrokeredMessage receivedMessage = receiver.Receive();
    try
    {
        ProcessMessage(receivedMessage);
        receivedMessage.Complete();
    }
    catch (Exception e)
    {
        receivedMessage.Abandon();
    }

Bis zu dieser Stelle des Artikels werden alle Nachrichten, die an das Thema gesendet wurden, allen registrierten Abonnements zur Verfügung gestellt. Der Kernpunkt lautet „zur Verfügung gestellt“. Während Servicebus-Abonnements alle Nachrichten sehen, die an das Thema gesendet wurden, können Sie nur eine Teilmenge dieser Nachrichten in die virtuelle Abonnementwarteschlange kopieren. Dies wird mithilfe von Abonnementfiltern ausgeführt. Wenn Sie ein Abonnement erstellen, können Sie einen Filterausdruck bereitstellen, der das Format eines SQL92-Prädikats hat und die Eigenschaften der Nachricht verarbeitet, und zwar sowohl die Systemeigenschaften (z. B. Label) als auch die Anwendungseigenschaften (z. B. StoreName im vorherigen Beispiel).

Das Szenario soll erweitert werden, um dies zu veranschaulichen. Dazu wird dem Einzelhandelsszenario ein zweiter Laden hinzugefügt. Weiterhin müssen Verkaufsdaten von allen POS-Terminals aus beiden Läden an das zentrale Lagerverwaltungssystem weitergeleitet werden, aber ein Ladenmanager, der mit dem Dashboardtool arbeitet, ist nur am Ergebnis des zweiten Ladens interessiert. Sie können dies erreichen, indem Sie Abonnementfilterung verwenden. Wenn ein POS-Terminal eine Nachricht veröffentlicht, legt es die Anwendungseigenschaft StoreName für die Nachricht fest. Gibt es zwei Läden, beispielsweise Redmond und Seattle, stempeln die POS-Terminals im Laden in Redmond ihre Verkaufsdatennachrichten in StoreName mit dem Namen Redmond, wogegen die POS-Terminals im Laden in Seattle für StoreName den Namen Seattle verwenden. Der Ladenmanager des Ladens in Redmond möchte nur Daten von seinen POS-Terminals sehen. Das System sieht wie folgt aus:

Servicebus4

Damit dieses Routing eingerichtet wird, erstellen Sie das Abonnement Dashboard wie folgt:

SqlFilter dashboardFilter = new SqlFilter("StoreName = ‘Redmond’");
  namespaceManager.CreateSubscription("DataCollectionTopic", "Dashboard", dashboardFilter);

Mit diesem Abonnementfilter werden nur Nachrichten, deren Eigenschaft StoreName auf Redmond festgelegt ist, in die virtuelle Warteschlange für das Abonnement Dashboard kopiert. Zum Thema Abonnementfilterung gibt es viel mehr zu erzählen. Anwendungen können mehrere Filterregeln pro Abonnement haben und können die Fähigkeit haben, die Eigenschaften einer Nachricht auf deren Weg zur virtuellen Warteschlange eines Abonnements zu ändern.

In diesem Artikel wird im Grundsatz veranschaulicht, wie das themenbasierte Veröffentlichen/Abonnieren-Feature verwendet werden kann, das in Servicebus eingeführt wurde.

Alle Gründe, die für ein Verwenden von Warteschlangen sprechen und unter Erstellen von Anwendungen, die Service Bus-Warteschlangen verwenden beschrieben sind, gelten auch für Themen, dabei insbesondere:

  • Zeitliche Entkopplung: Nachrichtenabsender (Producer) und Nachrichtenempfänger (Consumer) müssen nicht gleichzeitig online sein.

  • Lastnivellierung (Belastungsausgleich): Lastspitzen werden von dem Thema geglättet, wodurch es ermöglicht wird, als Consumer fungierende Anwendungen für durchschnittliche Last statt für Spitzenlast bereitzustellen.

  • Lastenausgleich: Ähnlich wie bei einer Warteschlange können Sie mehrere konkurrierende Consumer haben, die auf einem einzigen Abonnement lauschen, wobei jede Nachricht nur an einen der Consumer gesendet wird, wodurch die Last ausgeglichen wird.

  • Lockere Kopplung: Sie können das Messagingnetzwerk entwickeln, ohne dass vorhandene Endpunkte davon betroffen sind; beispielsweise Hinzufügen von Abonnements zu einem Thema oder Ändern von Filtern eines Themas, damit neue Consumer berücksichtigt werden können.

Anzeigen:
© 2015 Microsoft