Datenbankentwicklung mit dem Microsoft SQL Server 2005

9 SQL Server Service Broker (S. 397-398)

Der SQL Server Service Broker ermöglicht die asynchrone Verarbeitung von Daten. Der Einsatz des Service Brokers ist immer dann sinnvoll, wenn eine Online-Datenverarbeitung zu einer Lasterhöhung derart führt, dass der Server letztlich nicht mehr oder nur in ungenügender Zeit auf Anfragen reagieren kann. In einem solchen Fall kann durch die asynchrone Verarbeitung von Anfragen dafür gesorgt werden, dass ein SQL Server-System mehr Anfragen verarbeit, als es tatsächlich physikalisch kann. Hierzu werden Anfragen einfach in eine Warteschlange eingereiht, die dann Schritt für Schritt abgearbeitet wird, wobei ausgenutzt wird, dass das System in absehbarer Zeit auch wieder in einen Zustand geringerer Auslastung zurückkehrt. In diesem Zustand ist dann die Abarbeitung der Warteschlange( n) möglich. Für den Endbenutzer kann durch eine solche Verfahrensweise eine merkliche Reduzierung der Antwortzeiten erreicht werden. Unter Einsatz des Service Brokers kann ein Benachrichtigungssystem installiert werden, das den Zustand von Warteschlangen überwacht und beim Eintreffen von Ereignissen, die in diese Warteschlangen eingereiht werden, Aktionen auslöst. Der Service Broker kann aber auch Änderungen an Server- und Datenbankobjekten überwachen und beim Auftreten von solchen Änderungen Ereignisse erzeugen, verteilen oder protokollieren.

9.1 Architektur

Der SQL Server Service Broker ist ein Framework, mit dessen Hilfe eine ereignisgesteuerte Datenverarbeitung organisiert werden kann. Der Service Broker ist keine eigene Anwendung, er stellt im Rahmen des Frameworks lediglich die zur Implementierung einer serviceorientierten Architektur erforderlichen Objekte und Methoden zur Verfügung. Bevor wir betrachten, wie das Framework des Service Brokers aufgebaut ist und welche Objekte und Methoden zur Verfügung stehen, soll daher zunächst eine kurze Einführung in serviceorientierte Architekturen gegeben werden.

9.1.1 Service Oriented Architecture (SOA)

Serviceorientierte Architekturen bestehen aus Diensten, die nur lose – auf der Basis von Nachrichtenaustauschmechanismen – miteinander verbunden sind. Solche Dienste können zum Beispiel Web Services sein, die wir in Kapitel 11 noch behandeln werden. Ein Dienst – oder Service – ist hierbei die Implementierung einer genau umrissenen Aufgabe aus einer bestimmten Anwendungsdomäne. Die technische Implementierung eines Dienstes – also etwa Programmiersprache, Datenbank oder Systemplattform – ist hierbei nicht von Bedeutung. Wichtig ist nur, dass der Dienst einen Vertrag erfüllen muss. Hiermit ist gemeint, dass ein Dienst sicherstellen wird, dass er auf bestimmte Anfragen definiert reagiert. Ebenfalls per Vertrag geregelt ist die Kommunikation zwischen Dienstanbieter und Dienstnutzer, also zum Beispiel die verwendeten Schnittstellen und das Protokoll. Komponenten in einer serviceorientierten Architektur sind Nachrichten, Warteschlangen, Verträge, Dienste und Konversationen.

Dienste
Ein Dienst ist hier die softwaretechnische Umsetzung einer exakt definierten Aufgabe.

Nachrichten
Nachrichten sind die Informationsträger in einer Kommunikation. Das Nachrichtenformat sollte hierbei so gewählt werden, dass ein plattform- und implementierungsunabhängiger Nachrichtenaustausch möglich ist. Web Services zum Beispiel verwenden das Simple Object Access Protocol (SOAP) – ein spezielles XML-Format – als Nachrichtenformat, wodurch genau diese Unabhängigkeit sichergestellt wird.

Warteschlangen
Warteschlangen nehmen Nachrichten auf, die auf ihre Abarbeitung warten. Hierdurch wird eine asynchrone Verarbeitung von Daten ermöglicht. Der für eine Nachricht in einer Warteschlange verantwortliche Dienst kann diese Nachricht irgendwann auswerten bzw. abarbeiten.

Verträge
Verträge regeln die Kommunikation zwischen Diensten. In den Verträgen wird festgelegt, welche Dienste welche Nachrichten bzw. Nachrichtenformate austauschen können.

Konversationen
Eine Konversation ist der Austausch von Nachrichten, die zueinander in Beziehung stehen. Die Konversation muss zum Beispiel dafür sorgen, dass zueinander in Beziehung stehende Nachrichten in der erforderlichen Reihenfolge in die entsprechenden Warteschlangen eingereiht werden.