Umsetzung im MS SQL Server 2005

Die Zielsetzung, die im MS SQL Server ab der Version 2005 zu erreichen versucht wird, besteht daraus, einen universellen und übergreifenden Datenzugriff auf die Datenbank (Daten, Anwendungen) anzubieten. Die angestrebte Universalität und Interoperabilität erreicht man genau über die Webservice-Techniken, da sie ein mittlerweile eingeführter und sehr weit verbreiteter Standard sind, um über Plattform- und Anwendungsgrenzen hinweg Daten auszutauschen und Dienste aufzurufen. Konkret bietet die Datenbank durch die Verwendung von allgemeinen Standards wie HTTP (Übertragung), SOAP 1.1/1.2 (Nachrichtenformat), XML Schema (Nachrichtenbeschreibung) und WSDL 1.1 (Dienstbeschreibung) die Möglichkeit an, Dienste abzurufen. Innerhalb der Datenbank steht dann entweder T-SQL oder .NET zur Verfügung, um die eingehenden Nachrichten zu verarbeiten und Antworten zurückzuliefern, wobei insbesondere die XML-Verarbeitung an vorderer Rolle steht, d.h. die Zerlegung von XML-Daten zu relationalen Daten und zurück.

Auch wenn die Klientenbeispiele in diesem Kapitel alle in .NET geschrieben sind, weil dies vermutlich das häufigste Szenario darstellt, so bietet die Wahl der Webservice-Technik die Möglichkeit, die Dienste auch mit anderen Programmiersprachen zu verwenden. Wie man sich vorstellen kann, ist allerdings die Verwendung in .NET besonders gelungen, da im Framework verschiedene zusätzliche Klassen vorhanden sind, die genau für die MS SQL Server-Webservices geschaffen wurden.

Die Zugriffsmöglichkeiten in Version 2000 bestanden aus den drei folgenden Gruppen:

• XML-Zugriff: XML-Nachrichtenaustausch unter Einsatz des Internet Information Servers
• DB-Zugriff: Rückgabe von relationalen Ergebnismengen über DB-Zugriffsbibliotheken
• Netzwerkzugriff: Nachrichtenaustausch über TCP und Named Pipes

Im MS SQL Server 2005 kommt nun die Webservice-Technik noch hinzu, sodass hier über HTTP SOAP-Anfragen zur Datenbank geschickt werden können. Die Voraussetzung für diesen Einsatz ist dabei gerade nicht der Microsoft Information Server (IIS), sondern nur der Microsoft Windows Server 2003, Microsoft Windows XP Service Pack 2 (SP2) und Kernel Model Http.Sys.support.

Innerhalb der Datenbank erstellt man Prozeduren und Funktionen, die entweder in T-SQL oder in .NET erstellt werden, um sie dann über T-SQL-Anweisungen als Endpunkt anzubieten. Es handelt sich also letztendlich um gewöhnliche Konstrukte der Programmierbarkeit, deren konkrete programmatische Ausführung darüber entscheidet, ob und wie sie als Webservice funktionieren oder nicht. Typischerweise stellt man sich vor, dass ein Parameter einer solchen Prozedur/Funktion eine XML-Nachricht erwartet, die zudem auch noch typisiert sein kann. Dieses Modul zerlegt den XML-Parameter, verarbeitet die Informationen und liefert auch wieder als Rückgabe-/Ausgabeparameter eine (typisierte) XML-Nachricht zurück.

Als zweites Modul gibt es in der Datenbank den WSDL-Generator, der die beschreibende WSDL-Nachricht zurückliefert. Diese Datei beschreibt die Nachrichtenstruktur und die Aufrufmöglichkeiten des als Webservice angemeldeten Programmier-Moduls.

Beides ist über den Endpunkt abrufbar, der im Wesentlichen eine URL darstellt, die über HTTP aufgerufen werden kann. Sie steht dann für SOAP-Zugriff (XML-Nachrichtenaustausch und eigentliche Nutzung des Webdienstes), Batch-Zugriff (T-SQL-Nachrichtenaustausch für Batch-Anweisungen) und den WSDL-Abruf (alleiniger Abruf der Beschreibungsdatei).

Der Endpunkt ist zwar der zentrale Zugriffspunkt für die drei möglichen Zugriffsarten, aber nicht alle Kombinationen von Wegen sind auch tatsächlich umsetzbar. So wirkt sich ein SOAP-Zugriff über den Endpunkt immer auf die Funktion/Prozedur aus, die den Webservice abbildet. Eine Anfrage zur Batch-Verarbeitung wird zwar auch über SOAP geschickt, gelangt allerdings nicht zu einer bestimmten Prozedur/Funktion, sondern wird unmittelbar ausgeführt. Es ist in diesem Fall auch nicht notwendig, eine Prozedur/Funktion im Server anzubieten, da ja die T-SQL-Anweisungen, die zur Ausführung gebracht werden sollen, in der Anfrage enthalten sind. Der WSDL-Aufruf schließlich erfordert nicht einmal eine SOAP-Datei, sondern lediglich eine einfache HTTP-Anfrage (Aufruf der Webservice-Adresse) und die um den Parameter ?wsdl ergänzte URL des Endpunkts.

Als Anwendungsbeispiele kommen verschiede Szenarien in Betracht:

• Im Wesentlichen stellt die Verwendung von Webservices eine zentrale Komponente von serviceorientierten Architekturen dar. Dies bedeutet, dass lose gekoppelte Anwendungen mit Hilfe von Webservices oder sonstigen Mittelschichtlösungen (unter .NET bspw. Windows-Dienste, Nachrichtensysteme) verbunden werden und dadurch eine verbesserte Wiederverwendbarkeit erreicht wird. Dies bedeutet auch, dass bei der Erstellung von solchen (Web-)Diensten über eine größere Wiederverwendbarkeit nachgedacht wird und nicht ausschließlich nur die Funktionalität angeboten wird, die tatsächlich aktuell benötigt wird.
• Sofern nur eine geringe Datenmenge abgerufen wird und die XML-Dateien nicht unmittelbar die gesamte Datenbank enthalten (ein zurzeit immer häufiger auftretendes und zu kritisierendes Phänomen), kann man die Webservice-Technik auch verwenden, um früher mit anderen Programmiersprachen durchgeführte klassische DB-Kommunikation durch Webservices umzusetzen. Anstelle von JDBC (Java) oder PDO/mssql-Funktionen (PHP) würde man nun die Webservices verwenden, um Datenbankab/anfragen in Batch-Form oder mit Hilfe von vorbereiteten Operationen auszuführen.
• Auch lose Zugriffe über mobile Klienten sind durch die Verwendung von XML-SOAP-Nachrichten möglich, da diese oftmals einfacher zu realisieren ist als eine klassische DB-Kommunikation.