Vorteile von Service Broker

Datenbankintegration

Der integrierte Aufbau von Service Broker bietet Vorteile für die Leistung und Verwaltung von Anwendungen.

Integration mit SQL Server ermöglicht transaktionales Messaging ohne den höheren Verwaltungsaufwand und die Komplexität eines externen DTC-Dienstes (Distributed Transaction Coordinator, verteilter Transaktionskoordinator). Eine Anwendung empfängt eine oder mehrere Nachrichten, verarbeitet sie und sendet eine Antwortnachricht innerhalb einer einzigen Datenbanktransaktion. Wenn bei der Transaktion Fehler auftreten, wird ein Rollback für den gesamten Vorgang ausgeführt, und die empfangene Nachricht wird zurück an die Warteschlange gegeben, sodass erneut versucht werden kann, sie zu verarbeiten. Aktionen treten erst dann in Kraft, wenn die Anwendung für die Transaktion ein Commit ausgeführt hat. Die Anwendung bleibt in einem konsistenten Status.

Die Verwaltung ist einfacher, wenn Daten, Nachrichten und Anwendungslogik zusammen in der Datenbank sind, da die Verwaltung für die Anwendung (Wiederherstellung im Notfall, Sicherheit, Sicherung usw.) dann Teil der routinemäßigen Verwaltung für die Datenbank wird und der Administrator nicht drei oder vier Komponenten verwalten muss.

Bei herkömmlichen Messagingsystemen können der Nachrichtenspeicher und die Datenbank inkonsistent werden. Wenn z. B. eine Komponente aus einer Sicherung wiederhergestellt wird, muss eine andere Komponente auch aus einer zeitgleichen Sicherung wiederhergestellt werden, sonst stimmen die Informationen im Nachrichtenspeicher nicht mit den Informationen in der Datenbank überein. Da Service Broker Nachrichten und Daten in derselben Datenbank aufbewahrt, kann es nicht zu Inkonsistenzen kommen.

Eine gemeinsame Entwicklungsumgebung ist ein weiterer Vorteil der Datenbankintegration. Der Messagingteil einer Anwendung und der Datenteil einer Anwendung können dieselben SQL Server-Sprachen und -Tools in einer Service Broker-Anwendung verwenden. Dabei ist es vorteilhaft, dass der Entwickler mit Datenbankprogrammierungstechniken für nachrichtenbasierte Programmierung vertraut ist. Gespeicherte Prozeduren, die einen Service Broker-Dienst implementieren, können entweder in Transact-SQL oder in einer der CLR-Sprachen (Common Language Runtime) geschrieben werden. Programme außerhalb der Datenbank verwenden Transact-SQL und bekannte Datenbank-Programmierungsschnittstellen wie ADO.NET.

Datenbankintegration ermöglicht zusätzlich automatische Ressourcenverwaltung. Service Broker wird im Kontext der SQL Server-Instanz ausgeführt, also überwacht Service Broker alle Nachrichten, die innerhalb der Instanz zur Übermittlung aus allen Datenbanken bereitstehen. Dadurch kann jede Datenbank ihre eigenen Warteschlangen beibehalten, und Service Broker wird dabei unterstützt, die Ressourcennutzung über die gesamte SQL Server-Instanz hinweg zu verwalten.

Bestellen und Koordinieren von Nachrichten

Bei herkömmlichen Messagingsystemen war die Anwendung zuständig für das Bestellen und Koordinieren von Nachrichten, die möglicherweise ungeordnet empfangen wurden. Ein Beispiel dazu: Anwendung A sendet die Nachrichten 1, 2 und 3. Anwendung B empfängt und bestätigt die Nachrichten 1 und 3, bei der Nachricht 2 trat jedoch ein Fehler auf. Anwendung A sendet Nachricht 2 erneut, allerdings wird nun die Nachricht 2 nach den Nachrichten 1 und 3 empfangen. Bisher musste ein Entwickler die Anwendung entweder so konzipieren, dass die Reihenfolge der Nachrichten keine Rolle spielte, oder die Nachricht 3 so lange zwischenspeichern, bis Nachricht 2 eingegangen war, sodass die Anwendung die Nachrichten in der richtigen Reihenfolge verarbeiten konnte. Keine der beiden Lösungen ist unkompliziert und einfach.

Ein anderes Problem mit herkömmlichen Systemen bestand darin, dass Nachrichten doppelt übermittelt wurden. Wenn die Anwendung B im vorigen Beispiel die Nachricht 2 empfängt, die Bestätigungsnachricht zurück an Anwendung A jedoch verloren geht, wird Anwendung A die Nachricht 2 erneut senden, sodass Anwendung B die Nachricht doppelt empfängt. Bisher musste der Anwendungscode in der Lage sein, ein Duplikat zu erkennen und zu verwerfen oder das Duplikat ohne negative Auswirkungen erneut zu verarbeiten. Beide Vorgehensweisen waren schwierig zu implementieren.

Die Nachrichtenkoordinierung war bisher ebenso schwierig. So kann eine Anwendung Hunderte oder Tausende Anforderungen an einen Dienst senden. Der Dienst verarbeitet die Anforderungen parallel und gibt eine Antwort zurück, sobald der Dienst die Verarbeitung der Anforderung fertig gestellt hat. Da die Verarbeitung jeder Anforderung unterschiedlich lange dauert, empfängt die Anwendung Antworten in einer anderen Reihenfolge als derjenigen, in der die Anwendung die ausgehenden Nachrichten gesendet hat. Um jedoch die Antworten richtig verarbeiten zu können, muss die Anwendung jede Antwort der richtigen ausgehenden Nachricht zuordnen. Bei herkömmlichen Messagingsystemen hat jede Anwendung diese Zuordnung selbst verwaltet. Dadurch stiegen der Aufwand und die Komplexität beim Entwickeln der Anwendung.

Service Broker löst diese Probleme, indem es die Nachrichtenreihenfolge, die eindeutige Übermittlung und die Konversationsidentifikation automatisch verarbeitet. Sobald zwischen zwei Service Broker-Endpunkten eine Konversation hergestellt ist, empfängt eine Anwendung jede Nachricht nur einmal, und zwar in der Reihenfolge, in der sie gesendet wurden. Ihre Anwendung kann Nachrichten genau einmal verarbeiten, und zwar in der richtigen Reihenfolge und ohne zusätzlichen Code. Schließlich versieht Service Broker jede Nachricht automatisch mit einem Bezeichner. Eine Anwendung kann immer unterscheiden, zu welcher Konversation eine bestimmte Nachricht gehört.

Lose Verbindungen und Flexibilität bei der Arbeitsauslastung

Service Broker bietet lose Verbindungen zwischen der initiierenden Anwendung und der Zielanwendung. Eine Anwendung kann eine Nachricht an eine Warteschlange senden, die Anwendungsverarbeitung fortsetzen und sich dabei auf Service Broker verlassen, um die Nachricht an das Ziel zu übermitteln. Diese lose Verbindung bietet Planungsflexibilität. Der Initiator kann mehrere Nachrichten versenden, und mehrere Zieldienste können diese parallel verarbeiten. Jeder Zieldienst verarbeitet die Nachrichten nach seiner eigenen Leistungsfähigkeit, abhängig von der aktuellen Arbeitsauslastung.

Durch Warteschlangen können Systeme die Verarbeitung auch gleichmäßiger verteilen. Dadurch wird die von einem Server angeforderte Spitzenkapazität reduziert. Der gesamte Durchsatz und die Leistung von Datenbankanwendungen steigen an. So müssen beispielsweise viele Datenbankanwendungen einen plötzlichen Anstieg in der Transaktionsanzahl zu bestimmten Tageszeiten bewältigen, wodurch der Ressourcenverbrauch ansteigt und sich die Reaktionszeiten verschlechtern. Mit Service Broker müssen diese Anwendungen nicht die gesamte Verarbeitung einer Geschäftstransaktion zum Zeitpunkt des Eingangs ausführen. Stattdessen verwendet die Anwendung Service Broker, um Informationen über die Transaktion an Anwendungen zu senden, die die Verarbeitung im Hintergrund ausführen. Diese Anwendungen verarbeiten die Transaktionen zuverlässig über einen Zeitraum hinweg, während die Haupteintragsanwendung weiterhin neue Geschäftstransaktionen empfängt.

Wenn das Ziel nicht sofort verfügbar ist, bleibt die Nachricht in der Übermittlungswarteschlange für die sendende Datenbank. Service Broker versucht so lange, die Nachricht zu übermitteln, bis sie erfolgreich gesendet wurde oder bis die Lebensdauer der Konversation abgelaufen ist, sodass eine erfolgreiche Konversation zwischen zwei Diensten auch dann aufrechterhalten werden kann, wenn einer der beiden Dienste vorübergehend nicht erreichbar ist. Nachrichten in der Übertragungswarteschlange sind Teil der Datenbank. Service Broker übermittelt eine Nachricht auch dann, wenn es bei der Instanz zu Fehlern kommt oder sie neu gestartet wird.

Sperren verbundener Nachrichten

Bei herkömmlichen Messagingsystemen war es eine der schwierigsten Herausforderungen, mehreren Programmen das parallele Lesen derselben Warteschlange zu ermöglichen. In herkömmlichen Messagingsystemen können Nachrichten in falscher Reihenfolge verarbeitet werden, wenn mehrere Programme oder mehrere Threads aus derselben Warteschlange lesen. Service Broker verhindert diese Situation durch Sperren von Konversationsgruppen.

Betrachten Sie beispielsweise eine herkömmliche Bestellungsverarbeitungsanwendung. Nachricht A mit Anweisungen zum Erstellen der Auftragskopfzeile und Nachricht B mit Anweisungen zum Erstellen der Auftragsartikel werden in der Warteschlange empfangen. Wenn diese Nachrichten durch verschiedene Anwendungsinstanzen aus der Warteschlange genommen und gleichzeitig verarbeitet werden, könnte die Auftragsartikeltransaktion zuerst versuchen, einen Commit auszuführen. Dabei tritt ein Fehler auf, da der Auftrag noch nicht vorhanden ist. Durch den Fehler wiederum wird ein Rollback für die Transaktion ausgeführt. Die Nachricht wird erneut in die Warteschlange gestellt und erneut verarbeitet, wodurch Ressourcen verschwendet werden. Bisher haben Programmierer dieses Problem dadurch gelöst, dass sie die Informationen aus Nachricht A und Nachricht B zu einer einzigen Nachricht kombinierten. Diese Vorgehensweise mag unkompliziert für zwei Nachrichten sein, ist jedoch kaum noch empfehlenswert für Systeme, die Dutzende oder gar Hunderte Nachrichten koordinieren.

Service Broker löst dieses Problem durch Zuordnen verknüpfter Konversationen in eine Konversationsgruppe. Service Broker sperrt alle Nachrichten in derselben Konversationsgruppe automatisch, sodass diese Nachrichten nur von einer Anwendungsinstanz empfangen und verarbeitet werden können. Dabei können andere Instanzen der Anwendung weiterhin Nachrichten aus der Warteschlange nehmen und sie in anderen Konversationsgruppen verarbeiten. Dadurch können mehrere parallele Anwendungsinstanzen zuverlässig und effizient arbeiten, ohne dass komplizierter Sperrcode in der Anwendung notwendig wäre.

Automatische Aktivierung

Eines der hilfreichsten Features von Service Broker ist die Aktivierung. Sie ermöglicht es einer Anwendung, sich selbst dynamisch zu skalieren, um sich dem Volumen der in der Warteschlange eingehenden Nachrichten anzupassen. Service Broker bietet Features, mit denen Programme sowohl innerhalb als auch außerhalb einer Datenbank ausgeführt werden können. Dabei werden die Vorteile der Aktivierung genutzt. Service Broker setzt jedoch nicht zwingend voraus, dass eine Anwendung die Aktivierung verwendet.

Service Broker überwacht die Aktivität in einer Warteschlange, um zu bestimmen, ob eine Anwendung die Nachrichten aus allen Konversationen empfängt, in denen Nachrichten verfügbar sind. Bei der Aktivierung von Service Broker wird ein neuer Warteschlangenleser gestartet, wenn dafür auszuführende Aufgaben anstehen. Um zu bestimmen, ob auszuführende Aufgaben anstehen, überwacht Service Broker die Aktivität der Warteschlange. Wenn die Anzahl der Warteschlangenleser mit dem eingehenden Verkehr übereinstimmt, erreicht die Warteschlange regelmäßig einen Status, in dem entweder die Warteschlange leer ist oder alle Nachrichten in der Warteschlange zu einer Konversation gehören, die durch einen anderen Warteschlangenleser verarbeitet wird. Wenn die Warteschlange diesen Status über einen längeren Zeitraum nicht erreicht, aktiviert Service Broker eine andere Instanz der Anwendung.

Anwendungen verwenden jeweils verschiedene Vorgehensweisen, um Programme zu aktivieren, die innerhalb oder außerhalb der Datenbank ausgeführt werden. Bei Programmen innerhalb der Datenbank startet Service Broker eine weitere Version der gespeicherten Prozedur, die durch die Warteschlange angegeben ist. Bei Programmen außerhalb der Datenbank generiert Service Broker ein Aktivierungsereignis. Das Programm überwacht dieses Ereignis, um zu bestimmen, wann ein weiterer Warteschlangenleser notwendig wird.

Service Broker beendet ein Programm nicht, das durch die Aktivierung gestartet wurde. Stattdessen werden aktivierte Anwendungen so geschrieben, dass sie nach Ablauf eines bestimmten Zeitraums, in dem keine zu empfangenden Nachrichten mehr eingehen, automatisch herunterfahren. Mit einer so konzipierten Anwendung kann die Anzahl der Anwendungsinstanzen je nach Verkehr des Dienstes dynamisch wachsen oder abnehmen. Wenn das System heruntergefahren oder neu gestartet wird, werden Anwendungen automatisch gestartet, um die Nachrichten in der Warteschlange zu lesen.

Bei herkömmlichen Messagingsystemen fehlt dieses Verhalten. Bei ihnen kommt es häufig vor, dass zu einem bestimmten Zeitpunkt einer bestimmten Warteschlange entweder zu wenige oder zu viele Ressourcen zur Verfügung stehen.

Siehe auch

Andere Ressourcen