Wie arbeitet Service Broker?

Konversationen

Service Broker wurde für die grundlegenden Funktionen des Sendens und Empfangens von Nachrichten entwickelt. Jede Nachricht ist Teil einer Konversation. Jede Konversation ist ein zuverlässiger, permanenter Kommunikationskanal. Jede Nachricht und jede Konversation weist einen bestimmten, von Service Broker erzwungenen Typ auf, mit dem die Entwickler zuverlässige Anwendungen schreiben können.

Mit den neuen Transact-SQL-Anweisungen können die Anwendungen Nachrichten zuverlässig senden und empfangen. Eine Anwendung sendet die Nachrichten an einen Dienst; dabei handelt es sich um einen Namen für eine Reihe von verwandten Aufgaben. Eine Anwendung erhält Nachrichten von einer Warteschlange, wobei es sich um eine Sicht einer internen Tabelle handelt.

Nachrichten für dieselbe Aufgabe sind Teil derselben Konversation. Innerhalb einer Konversation garantiert Service Broker, dass eine Anwendung jede Nachricht genau einmal erhält, und zwar in der Reihenfolge, in der die Nachricht gesendet wurde. Das Programm, das einen Dienst implementiert, kann verwandte Konversationen für denselben Dienst in eine Konversationsgruppe zusammenfassen, wie unter Vorteile von Service Broker beschrieben.

Die zertifikatbasierte Sicherheit schützt vertrauliche Nachrichten und steuert den Zugriff auf Dienste. Eine Analogie dazu wäre, sich Service Broker wie einen Postdienst vorzustellen. Wenn Sie eine Konversation mit entfernten Kollegen führen möchten, können Sie Briefe mit dem Postdienst senden. Der Postdienst sortiert und übermittelt die Briefe. Sie und Ihr Kollege bzw. Ihre Kollegin nehmen die Briefe aus Ihren Briefkästen, lesen sie, schreiben Antworten und senden neue Briefe, bis die Konversation beendet ist. Die Briefzustellung findet asynchron statt, d. h. während Sie und Ihr Kollege bzw. Ihre Kollegin andere Aufgaben durchführen.

Programme können Service Broker wie einen Postdienst verwenden, um asynchrone Konversationen mit anderen Programmen zu unterstützen. Die Service Broker-Nachrichten funktionieren wie Briefe. Ein Service Broker-Dienst ist die Adresse, an die der Postdienst die Briefe zustellt. Warteschlangen sind die Briefkästen, in denen die Briefe aufbewahrt werden, sobald sie zugestellt wurden. Die Anwendungen erhalten die Nachrichten, reagieren darauf und senden Antworten.

Wenn eine Anwendung eine Nachricht an einen Service Broker-Dienst sendet, wird sie von den Implementierungsdetails der Anwendung am anderen Ende der Konversation isoliert. Die empfangende Anwendung kann dynamisch neu konfiguriert oder durch neuen Code ersetzt werden, ohne sich auf die sendende Anwendung auszuwirken. Die empfangende Anwendung kann sogar vorübergehend heruntergefahren werden. Die einzige Auswirkung besteht darin, dass Service Broker der Warteschlange neue Nachrichten hinzufügt, bis die empfangende Anwendung neu gestartet wird.

Nachrichtensortierung und -koordination

Service Broker verarbeitet Warteschlangen, eine häufig angewendete Datenbanktechnik, unter zwei wesentlichen Gesichtspunkten anders als herkömmliche Produkte:

• Die Service Broker-Warteschlangen sind in die Datenbank integriert.

• Die Warteschlangen koordinieren und sortieren verwandte Nachrichten.

Integriertes Queuing bedeutet, dass Service Broker in die normale Datenbankwartung und -verwaltung integriert ist. In der Regel muss ein Administrator keine routinemäßigen Wartungsaufgaben für Service Broker durchführen.

Das Service Broker-Framework bietet eine einfache Transact-SQL-Schnittstelle zum Senden und Empfangen von Nachrichten, kombiniert mit einem Satz fester Garantien zur Nachrichtenübermittlung und -verarbeitung. Service Broker garantiert, dass ein Programm jede Nachricht einer Konversation genau einmal in der Reihenfolge empfängt, in der die Nachricht gesendet wurde, nicht in der Reihenfolge, in der die Nachricht in die Warteschlange eintritt. Herkömmliche Queuingprodukte stellen Nachrichten in der Reihenfolge bereit, in der die Nachrichten in die Warteschlange eingetreten sind. Deshalb ist eine Anwendung erforderlich, mit der die Reihenfolge und Gruppierung der Nachrichten festgelegt wird. Service Broker garantiert, dass zwei Warteschlangenleser nicht gleichzeitig Nachrichten derselben Konversation oder derselben Gruppe verwandter Konversationen verarbeiten können.

Jede Service Broker-Konversation verfügt über zwei Seiten. Die Seite, welche die Konversation startet, wird als Initiator bezeichnet; die andere Seite wird als Ziel bezeichnet. Jede Seite hat einen Dienst: den Initiatordienst und den Zieldienst. Jeder Dienst hat eine zugeordnete Nachrichtenwarteschlange.

In der folgenden Abbildung wird der Austausch von Nachrichten in einer typischen Dialogfeldkonversation dargestellt:

• Beim Initiator:

  • Ein Programm beginnt die Konversation.

  • Das Programm erstellt eine Nachricht, welche die Daten enthält, die zum Ausführen eines Tasks erforderlich sind.

  • Das Programm sendet die Nachricht an den Zieldienst.

• Beim Ziel:

  • Die Nachricht wird in die dem Zieldienst zugeordnete Warteschlange gestellt.

  • Ein Programm empfängt die Nachricht von der Warteschlange und führt die Arbeit aus.

  • Das Programm antwortet, indem es eine Nachricht an den Initiatordienst sendet.

• Beim Initiator:

  • Die Antwortnachricht wird in die dem Initiatordienst zugeordnete Warteschlange gestellt.

  • Ein Programm empfängt die Antwort und verarbeitet sie.

Dieser Zyklus wird so lange wiederholt, bis der Initiator die Konversation beendet, da keine Anforderungen mehr zum Senden an das Ziel vorhanden sind.

Service Broker unterstützt das Festlegen von Prioritäten von 10 (hoch) bis 1 (niedrig) für jede Konversation. Dadurch wird gewährleistet, dass Arbeiten niedriger Priorität keine Arbeiten hoher Priorität blockieren. Service Broker-Systeme können so konfiguriert werden, dass sie verschiedene Dienstebenen bieten. Weitere Informationen finden Sie unter Konversationsprioritäten.

Service Broker verarbeitet die schwierigsten Tasks, die beim Schreiben von Messaginganwendungen auftreten. Diese schwierigen Tasks schließen Nachrichtenkoordination, zuverlässige Nachrichtenübermittlung, Sperre und Starten von Warteschlangenlesern ein. So können sich die Datenbankentwickler darauf konzentrieren, Lösungen für Geschäftsprobleme zu erarbeiten.

Asynchrone Transaktionsprogrammierung

Bei der Service Broker-Infrastruktur ist die Nachrichtenübermittlung zwischen Anwendungen transaktional und asynchron. Da das Service Broker-Messaging transaktional ist, wird bei einem Rollback einer Transaktion für alle Service Broker-Vorgänge während der Transaktion ein Rollback durchgeführt. Diese schließen Sende- und Empfangsvorgänge ein. Bei der asynchronen Übermittlung ist Database Engine (Datenbankmodul) für die Übermittlung zuständig, während die Anwendung weiterhin ausgeführt wird. Um die Skalierbarkeit zu verbessern, bietet Service Broker Mechanismen für das automatische Starten von Programmen, mit denen eine Warteschlange verarbeitet wird, sobald für das Programm sinnvolle Arbeit vorliegt. Weitere Informationen finden Sie unter Aktivierung von Service Broker.

Die asynchrone Programmierung unterstützt Entwickler beim Schreiben von Anwendungen, die Queuing verwenden. Viele Datenbankanwendungen enthalten Tabellen, die als Warteschlangen für Arbeiten verwendet werden, die entsprechend den verfügbaren Ressourcen durchgeführt werden. Warteschlangen können gegenüber Datenbankanwendungen zwei Vorteile bieten:

• Eine Anwendung kann einem interaktiven Benutzer sofort antworten, nachdem er seine Arbeitsanforderung in eine Warteschlange gestellt hat. Die Anwendung muss vor dem Antworten nicht darauf warten, bis die dieser Anforderung zugeordnete Arbeit abgeschlossen ist. Die in der Warteschlange stehende Anforderung wird verarbeitet, wenn Ressourcen verfügbar sind. So kann die Datenbank weiterhin auf interaktive Benutzer reagieren, während die verfügbaren Ressourcen gleichzeitig effizient genutzt werden.

• Die in einer einzelnen Anforderung involvierten Vorgänge können manchmal in mehrere Arbeitseinheiten unterteilt werden, die als separate Transaktionen verarbeitet werden. In diesem Fall kann eine Datenbankanwendung jede Arbeitseinheit starten, indem eine Anforderung in eine Warteschlange gestellt wird. Service Broker führt diese Idee weiter fort, indem zugelassen wird, dass die Anwendungen Arbeit über mehrere Instanzen von Service Broker auf separaten Computern verteilen.

Das Codieren von Anwendungen für eine ordnungsgemäße Sequenzierung und Verarbeitung von Objekten in Warteschlangen ist häufig kompliziert. Die Entwickler können die im Datenbankmodul integrierten Service Broker-Funktionen verwenden, um die für eine erfolgreiche Implementierung der Datenbankwarteschlangen erforderliche Codierung zu vereinfachen.

Unterstützung von lose verbundenen Anwendungen

Service Broker unterstützt lose verbundene Anwendungen. Lose verbundene Anwendungen setzen sich aus mehreren Programmen zusammen, die unabhängig voneinander Nachrichten senden und empfangen. Solche Anwendungen müssen dieselben Definitionen für die ausgetauschten Nachrichten enthalten und dieselbe Gesamtstruktur für die Interaktion zwischen den Diensten definieren. Die Anwendungen müssen jedoch nicht gleichzeitig oder in derselben SQL Server-Instanz ausgeführt werden oder Implementierungsdetails gemeinsam nutzen. Eine Anwendung muss den physikalischen Speicherort oder die Implementierung des anderen Teilnehmers der Konversation nicht kennen.

Service Broker-Komponenten

Service Broker bietet drei Arten von Komponenten:

• Konversationskomponenten. Konversationsgruppen, Konversationen und Nachrichten aus der Laufzeitstruktur einer Service Broker-Anwendung. Anwendungen tauschen Nachrichten als Teil einer Konversation aus. Jede Konversation ist Teil einer Konversationsgruppe; eine Konversationsgruppe kann mehrere Konversationen enthalten. Jede Service Broker-Konversation ist ein Dialogfeld. Ein Dialogfeld ist eine Konversation, bei der genau zwei Teilnehmer Nachrichten austauschen. Weitere Informationen zu Konversationskomponenten finden Sie unter Konversationsarchitektur.

• Dienstdefinitionskomponenten. Dabei handelt es sich um Entwurfszeitkomponenten, die die grundlegende Struktur der Konversationen angeben, die von der Anwendung verwendet werden. Sie definieren die Nachrichtentypen, den Konversationsfluss und den Datenbankspeicher für die Anwendung. Weitere Informationen zu den Dienstdefinitionskomponenten finden Sie unter Dienstarchitektur.

• Netzwerk- und Sicherheitskomponenten. Diese Komponenten definieren die Infrastruktur, die verwendet wird, um Nachrichten zwischen den Instanzen des Datenbankmoduls auszutauschen. Um die Datenbankadministratoren bei der Verwaltung sich ändernder Umgebungen zu unterstützen, ermöglicht Service Broker den Administratoren die Konfiguration dieser Komponenten unabhängig vom Anwendungscode. Weitere Informationen zu Netzwerk- und Sicherheitskomponenten finden Sie unter Netzwerk- und Remotesicherheit.

Die Dienstdefinitions-, Netzwerk- und Sicherheitskomponenten sind Teil der Metadaten für die Datenbank und die SQL Server-Instanz. Konversationsgruppen, Konversationen und Nachrichten sind Teil der in der Datenbank enthaltenen Daten.

Siehe auch

Konzepte

Andere Ressourcen