• Artikel

Auswählen einer Startstrategie

In diesem Thema werden Optionen für die Aktivierung von Service Broker beschrieben.

Service Broker unterstützt asynchrones Messaging mit Warteschlangen. Da sich Konversationen über Tage, Monate oder Jahre erstrecken können, wird in vielen Anwendungen für eine dynamische Skalierung die Aktivierung verwendet. In diesem Abschnitt werden einige allgemeine Strategien zum Starten einer Anwendung beschrieben, die Service Broker verwendet.

Startstrategien

Die Strategien zum Starten einer Anwendung lassen sich grob in vier Kategorien unterteilen:

  • Interne Aktivierung

  • Ereignisbasierte Aktivierung

  • Geplanter Task

  • Starttask

Jede Aktivierungsstrategie bietet andere Vorteile. Diese Strategien können von einer Anwendung kombiniert werden. Beispielsweise kann eine Anwendung in den meisten Fällen die interne Aktivierung mit einer geringen Anzahl von Warteschlangenlesern verwenden. Zu bestimmten Tageszeiten kann sie jedoch weitere Warteschlangenleser starten.

Interne Aktivierung

Zur internen Aktivierung von Service Broker wird eine gespeicherte Prozedur bei Bedarf direkt durch eine Service Broker-Warteschlangenüberwachung aktiviert. Dies ist oft der einfachste Ansatz. Durch die direkte Aktivierung einer gespeicherten Prozedur brauchen Sie keinen zusätzlichen Code in der Anwendung zu schreiben, um die Aktivierung zu verwalten. Allerdings muss die Anwendung für die interne Aktivierung als gespeicherte Prozedur von SQL Server geschrieben werden. Wenn Sie die interne Aktivierung verwenden, schreiben Sie die Anwendung so, dass sie beendet wird, wenn keine weiteren Nachrichten zur Verarbeitung vorliegen.

Ereignisbasierte Aktivierung

Einige Anwendungen werden als Reaktion auf ein bestimmtes Ereignis ausgeführt. Sie können beispielsweise eine Anwendung ausführen, wenn die CPU-Verwendung auf dem Computer unter einen bestimmten Wert fällt, oder Sie können eine Protokollierungsanwendung ausführen, wenn eine neue Tabelle erstellt wird.

Die externe Aktivierung von Service Broker stellt einen Sonderfall der ereignisbasierten Aktivierung dar. Zur externen Aktivierung wird die Anwendung als Reaktion auf das QUEUE_ACTIVATION-Ereignis gestartet.

Die ereignisbasierte Aktivierung kann für Ereignisse, die durch Ereignisbenachrichtigungen ausgelöst werden, mit der internen Aktivierung von Service Broker kombiniert werden. In diesem Fall verwenden Sie die interne Aktivierung für die Warteschlange, die die Benachrichtigung empfängt. Die gespeicherte Aktivierungsprozedur empfängt die Benachrichtigungsmeldung und startet die Anwendung.

Für andere Ereignisse können Sie mit dem SQL Server-Agent Aufträge auf demselben Computer starten, auf dem auch SQL Server ausgeführt wird. Sie können eine Anwendung schreiben, die WMI-Ereignisse (Windows Management Instrumentation, Windows-Verwaltungsinstrumentation) von einem Remotecomputer aus überwacht. Die Anwendung kann einen Task starten, wenn ein WMI-Ereignis auf dem Computer auftritt, auf dem SQL Server ausgeführt wird.

Bei Verwendung der ereignisbasierten Aktivierung wird eine Anwendung in der Regel beendet, wenn keine weiteren Nachrichten zur Verarbeitung vorliegen.

Geplanter Task

Bei einem geplanten Task wird eine Anwendung nach einem festgelegten Zeitplan aktiviert. Diese Strategie eignet sich besonders für Batchverarbeitungsanwendungen. Eine Anwendung, die einen geplanten Task ausführt, kann beendet werden, wenn keine weiteren Nachrichten zur Verarbeitung vorliegen. Das Programm kann aber auch zu einem bestimmten Zeitpunkt beendet werden.

Beispielsweise kann eine Anwendung zur Verarbeitung von Bestellungen an einen Lieferanten tagsüber die Nachrichten speichern und diese dann über Nacht verarbeiten, sodass eine einzige Bestellung an den Lieferanten erstellt wird. In diesem Fall kann die Anwendung mithilfe eines SQL Server-Agent-Auftrags jede Nacht zu einer bestimmten Zeit gestartet werden.

Starttask

Einige Anwendungen werden einmalig gestartet, gewöhnlich beim Start des Computers oder wenn SQL Server gestartet wird. Beispiele für Starttasks sind gespeicherte Startprozeduren in SQL Server, Anwendungen in der Gruppe Autostart von Windows oder Windows-Dienste. In diesem Fall wird die Anwendung weiter ausgeführt und verarbeitet Nachrichten, wenn diese eingehen. Bei einer Anwendung, die kontinuierlich ausgeführt wird, ist beim Eintreffen einer Nachricht in der Warteschlange keine Startzeit erforderlich. Da die Anwendung jedoch nicht beendet wird, wenn keine Nachrichten vorhanden sind, verbraucht das Programm selbst dann Ressourcen, wenn keine Arbeit vorliegt.

Diese Strategie kann für Anwendungen nützlich sein, die einen konstanten Nachrichtendatenstrom verarbeiten und beim Start relativ ressourcenintensiv sind.