Planen der Service Broker-Entwicklung
Überprüfen Sie beim Entwerfen einer Service Broker-Anwendung Folgendes:
Die Metriken bezüglich des erwarteten Typs und Umfangs von Ein- und Ausgaben der Anwendung.
Die Anforderungen an die vorgeschlagene Anwendung.
Wenn Sie sich über diese Faktoren im Klaren sind, können Sie ein System entwickeln, das die Geschäftsziele erfüllt.
Planungsprüfliste
Berücksichtigen Sie beim Planen der Anwendung die folgenden Fragen:
Welche Rolle spielt Service Broker in der Anwendung?
Die Antwort auf diese Frage ist hilfreich, um die von der Anwendung verwendeten Nachrichtentypen, die Struktur der Anwendung sowie die Speicher- und Verarbeitungsanforderung der Anwendung zu planen.
Beispielsweise könnte die Anwendung Service Broker nutzen, um Spitzen im Nachrichteneingang abzufangen, indem die Nachrichten in Warteschlangen gespeichert werden, bis die erforderlichen Ressourcen für die Verarbeitung zur Verfügung stehen. In diesem Fall sollten die Nachrichtentypen der Anwendung der Ein- und Ausgabe der vorhandenen Anwendung möglichst ähnlich sein. Die Speicher- und Verarbeitungsanforderungen der Anwendung können Sie anhand der vorhandenen Arbeitsauslastung schätzen.
Wenn Sie hingegen eine neue Anwendung entwerfen, überlegen Sie sorgfältig, bei welchen Vorgängen Service Broker den größten Nutzen verspricht Bei Verwendung von Service Broker werden häufig Einbußen im Hinblick auf vorhersagbare Verarbeitungszeiten in Kauf genommen, und im Gegenzug wird optimalerweise Zuverlässigkeit in Fällen erzielt, in denen eine konventionelle Anwendung vollständig versagen würde.
So muss z. B. eine Anwendung für die Onlineauftragserfassung möglicherweise einen Auftrag nicht sofort bei Übermittlung vollständig verarbeiten und eine abschließende Bestätigung ausgeben. Stattdessen übermittelt die Anwendung den Auftrag möglicherweise an einen Dienst, der den Auftrag verarbeitet und eine abschließende Bestätigung per E-Mail bereitstellt. Dank dieses Konzepts kann die Auftragsanwendung auch dann weitere Aufträge annehmen, wenn diese aufgrund von Netzwerkproblemen nicht bestätigt werden können. Wenn die Netzwerkprobleme behoben sind, verarbeitet die Anwendung die Aufträge. In diesem Fall hängen die Speicher- und Verarbeitungsanforderungen für die Anwendung von der erwarteten Anzahl von Aufträgen, der Größe der einzelnen auftragsbezogenen Nachrichten und dem Zeitaufwand für die Verarbeitung der einzelnen Aufträge ab.
Welche Informationen sind in einer Konversation erforderlich, um den gewünschten Task auszuführen? Wie sehen die Schemas der Nachrichten aus, die die Endpunkte austauschen, um einander die Informationen zur Verfügung zu stellen?
Die meisten Dienste tauschen halbstrukturierte Informationen aus. Daher ist die XML-Codierung empfehlenswert. Eine binäre Codierung ist nützlich, um Binärdateien wie Bilder auszutauschen. Wenn mit einer Nachricht nur mitgeteilt werden soll, dass die Nachricht angekommen ist, verwenden Sie eine leere Nachricht.
Wenn Sie gleich den richtigen Nachrichtentyp auswählen, sinkt die Wahrscheinlichkeit, dass Sie die Anwendung später aktualisieren müssen. Je nach der Codierung des Nachrichtentyps sind bei Aktualisierungen unterschiedliche Arbeitsschritte erforderlich, angefangen beim Aktualisieren einer XML-Schemadatei bis hin zu erheblichen Codierungsänderungen in der Anwendung. Wenn aktuell nicht benötigte Datenelemente vorhanden sind, die Sie jedoch in Zukunft zu benötigen glauben, ist es u. U. sinnvoll, diese einzuschließen. Wenn Sie diese Elemente von Anfang an im Schema definieren, müssen Sie das Schema nicht ändern, wenn Sie sich entschließen, die Elemente zu unterstützen.
Wo wird die Nachrichtenverarbeitungslogik ausgeführt?
Sie können die Anwendung als gespeicherte Prozedur, die von Service Broker aktiviert wird, als Hintergrunddienst, als geplantes Ereignis oder als externe Anwendung entwerfen. Die abschließende Entscheidung hängt von der Rolle ab, die Service Broker in der Anwendung spielt. Wenn die Anwendung z. B. einen kontinuierlichen Datenstrom von Nachrichten verarbeitet, die mit einer vorhersagbaren Rate ankommen, können Sie einen Hintergrunddienst verwenden. Wenn die Anwendung je nach der Anzahl von eingehenden Nachrichten dynamisch skaliert werden muss, können Sie eine von einer Warteschlange aktivierte gespeicherte Prozedur verwenden. Wenn die Anwendung Nachrichten in einer Warteschlange speichert und alle Nachrichten zu einem festgelegten Zeitpunkt verarbeitet, können Sie ein geplantes Ereignis zum Starten der Anwendung verwenden.
Eine externe Anwendung können Sie verwenden, wenn das Programm auf Ressourcen außerhalb der Datenbank zugreifen muss, z. B. auf Webseiten oder Dateien. Die Verwendung einer externen Anwendung kann zu einer verbesserten Skalierbarkeit der Anwendung beitragen, weil die Verarbeitung nicht auf dem Datenbankserver, sondern auf den Servern der mittleren Ebene erfolgt. Ein Anwendung mit Service Broker kann problemlos dezentral skaliert werden, weil Service Broker Remotetransaktionszugriff auf Warteschlangen bereitstellt. Jede Anwendung, die Transact-SQL-Befehle an die Datenbank senden und die Ergebnisse verarbeiten kann, kann Service Broker verwenden.
Jedes externe Programm wird von anderen Programmen, die die Warteschlange verwenden, isoliert. Daher sind bei externen Programmen keine besonderen Vorkehrungen für die Verwaltung des Zugriffs auf die Warteschlange erforderlich. Zudem wird im Fall eines Verbindungsfehlers während der Verarbeitung einer Nachricht ein Rollback für die Transaktion ausgeführt, und die Nachricht wird von Service Broker erneut der Warteschlange hinzugefügt. Netzwerkprobleme können nicht dazu führen, dass eine Nachricht in der Anwendung verloren geht.
Mit welcher Technologie soll die Anwendung implementiert werden?
Sie können zum Implementieren einer externen Anwendung eine beliebige Technologie verwenden, mit der eine Verbindung mit der Datenbank hergestellt werden kann und Transact-SQL-Anweisungen in SQL Server ausgeführt werden können. Allerdings werden Anwendungen i. d. R. in einer mit .NET Framework kompatiblen Sprache und ADO.NET entwickelt. Sie können eine gespeicherte Prozedur entweder in Transact-SQL oder in einer der mit .NET Framework kompatiblen Sprachen implementieren. Transact-SQL bietet möglicherweise eine bessere Leistung für Database Engine (Datenbankmodul). Die CLR-kompatiblen (Common Language Runtime) Sprachen bieten u. U. größere Flexibilität, strengere Kontrolle des Programmflusses, höhere Leistung für prozessorintensive Anwendungen sowie Direktzugriff auf .NET Framework.
Welche Serverkomponenten werden von der Anwendung am intensivsten verwendet?
Arbeiten Sie mit dem Systemadministrator zusammen, um sicherzustellen, dass Sie über ausreichende Ressourcen zur Erzielung einer optimalen Anwendungsleistung verfügen. Ermitteln Sie, welche Komponenten am häufigsten verwendet werden. Wenn von der Anwendung z. B. Warteschlangen verwendet werden, um die durch die Verarbeitung entstehende Arbeitsauslastung auszugleichen, oder die Nachrichtenbeibehaltung aktiviert wird, stellen Sie sicher, dass genügend Speicherplatz für die wachsende Warteschlange zur Verfügung steht. Hingegen wird für eine Anwendung mit hohem Nachrichtenaufkommen, aber kürzeren Wartezeiten in der Warteschlange möglicherweise mehr Netzwerkbandbreite und weniger Speicherplatz benötigt.
Sollen die Nachrichten unterschiedliche Prioritäten aufweisen?
In stark ausgelasteten Systemen kann durch Service Broker-Konversationsprioritäten sichergestellt werden, dass wichtige Arbeitsabläufe nicht durch große Mengen weniger wichtiger Arbeitsabläufe blockiert werden. Zudem ermöglichen Konversationsprioritäten auch Entwürfe, die unterschiedliche Servicelevels unterstützen.