Systemeigene XML-Webdienste (Übersicht)
Diese Funktion wird in zukünftigen Versionen von Microsoft SQL Server nicht mehr bereitgestellt. Verwenden Sie diese Funktion beim Entwickeln neuer Anwendungen nicht, und planen Sie das Ändern von Anwendungen, in denen es zurzeit verwendet wird.
Dieses Thema enthält einen Vergleich zwischen den systemeigenen XML-Webdiensten in MicrosoftSQL Server und Microsoft-SQLXML, beschreibt die Funktionsweise der systemeigenen XML-Webdienste und führt einige Vorteile an, die sich aus deren Nutzung ergeben.
Die systemeigenen XML-Webdienste sind für die folgenden Szenarien nicht nützlich oder nicht empfohlen:
Anwendungen, die durch ein hohes Maß an gleichzeitigen Echtzeitzugriffen mit Transaktionen von kurzer Dauer gekennzeichnet sind.
Dezentrale Skalierungen vom Typ Webfarm.
Als Ersatz für die mittlere Ebene, insbesondere wenn Ihre Anwendungsarchitektur durch umfangreiche Geschäftslogikanforderungen gekennzeichnet ist, die besser mit Komponenten der mittleren Ebene abgedeckt werden können.
Vergleich zwischen systemeigenen XML-Webdiensten und SQLXML
Vor SQL Server 2005 erforderte der Zugriff auf eine SQL Server-Datenbank die Verwendung von TDS (Tabular Data Stream). TDS ist ein proprietäres Protokoll, das für Windows-basierte Desktopclients unterstützt werden muss. In einigen Fällen müssen SQL Server-Clients Microsoft Data Access Components (MDAC) verwenden. Der MDAC-Stapel ist auf dem Clientcomputer installiert, der die Verbindung mit SQL Server herstellt. Für SQL Server ist SQLXML 3.0 eine Komponente der mittleren Ebene, die zwar den webbasierten Zugriff auf SQL Server unterstützt, es muss jedoch auch IIS (Internet Information Services) verwendet werden.
Ab SQL Server 2005 bieten die systemeigenen XML-Webdienste durch die Kombination aus der Verwendung von HTTP und SOAP eine Alternative für Nicht-Windows-Umgebungen, wie in der folgenden Abbildung gezeigt wird.
.gif "Vergleich zwischen systemeigenen XML-Webdiensten und SQLXML")
Da es nicht mehr erforderlich ist, dass entweder MDAC auf dem Client oder SQLXML mit seiner Abhängigkeit auf der mittleren Ebene von IIS installiert ist, ermöglicht der kombinierte SOAP- und HTTP-Zugriff einem breiteren Spektrum von Clients den Zugriff auf SQL Server. Das gilt auch für Webanwendungsclients, die vorhandene Clientanwendungen wie z. B. einen Webbrowser verwenden. Die systemeigenen XML-Webdienste erleichtern die Arbeit mit Microsoft.NET Framework, dem Microsoft SOAP-Toolkit sowie mit Perl und anderen Betriebssystemen und Toolsets zur Webentwicklung.
Die folgende Tabelle zeigt einige Features, die jede der Technologien bietet.
Systemeigene XML-Webdienste |
Microsoft SQLXML |
|---|---|
|
|
Funktionsweise der systemeigenen XML-Webdienste
Zum Verwenden der systemeigenen XML-Webdienste in SQL Server muss auf dem Server ein HTTP-Endpunkt eingerichtet sein. Dieser Endpunkt bildet im Prinzip das Gateway, über das HTTP-basierte Clients den Server abfragen. Nach der Einrichtung eines HTTP-Endpunkts können gespeicherte Prozeduren oder benutzerdefinierte Funktionen hinzugefügt oder den Endpunktbenutzern verfügbar gemacht werden. Das kann entweder bei Erstellen oder beim Aktualisieren des Endpunkts geschehen. Wenn Prozeduren und Funktionen aktiviert sind, werden sie als Webmethoden angegeben. Eine Auflistung von Webmethoden, die zur gemeinsamen Verwendung entworfen wurden, können als ein Webdienst bezeichnet werden.
Diese Webdienste können mit dem WSDL-Format beschrieben werden. Das WSDL-Format wird durch eine Instanz von SQL Server generiert und an SOAP-Clients für alle HTTP-Endpunkte zurückgegeben, auf denen WSDL aktiviert ist, wie das in der folgenden Abbildung gezeigt wird. Falls erforderlich, kann das WSDL-Format auch eine benutzerdefinierte Lösung anstelle des von SQL Server generierten Formats sein. Der Endpunkt kann optional so konfiguriert werden, dass er auf WSDL-Anforderungen nicht antwortet.
.gif "Funktionsweise von systemeigenen XML-Webdiensten")
Im Anschluss an diesen Prozess können Auflistungen von SQL Server-aktivierten Webdiensten implementiert und verwendet werden, um eine dienstorientierte Architektur (Service-Oriented Architecture, SOA) zu erstellen und aufzufüllen. Weitere Informationen finden Sie unter dem Stichwort "SOA" in der MSDN-Onlinebibliothek auf dieser Microsoft-Website.
Vorteile durch das Verwenden der systemeigenen XML-Webdienste
Eine Instanz von SQL Server, die als ihr eigener XML-Webdienst fungieren kann, bietet die folgenden Vorteile:
Jede Webdienstanwendung kann auf eine Instanz von SQL Server zugreifen.
Das ist der entscheidende Vorteil. Da die systemeigenen XML-Webdienste auf bewährten Technologien wie XML und HTTP basieren, kann jetzt jedes Gerät, das in der Lage ist, XML zu analysieren und HTTP-Anforderungen zu senden, auf SQL Server zugreifen. Das ermöglicht einen umfassenderen Zugriff auf SQL Server in heterogenen Umgebungen, in denen für Anwendungen, die unter anderen Betriebssystemen als Windows ausgeführt werden, die Konnektivität zu SQL Server erforderlich sein kann. Bisher bestand in solchen Fällen die einzige verfügbare Lösung darin, entweder JDBC- (Java Database Connectivity) oder ODBC-Treiber (Open Database Connectivity) zu verwenden. Die systemeigenen XML-Webdienste in SQL Server bieten hier eine alternative Lösung, die zudem kostengünstig ist. So könnte dieses Feature z. B. in Szenarien sehr nützlich sein, in denen ein Datenbankadministrator über ein in Perl geschriebenes Skript verfügt, das auf anderen Betriebssystemen als Windows ausgeführt wird, um eine SQL Server-Ressource zu verwalten.
Verbesserte Integration sowohl mit Microsoft als auch mit Drittanbieter-Toolsets zur Webentwicklung.
Mit den systemeigenen XML-Webdiensten werden die Ergebnisse von SQL-Abfragen im XML-Format zurückgegeben. Durch Verwendung vordefinierter Schemas können kleine integrierte Entwicklungsumgebungen (IDEs, Integrated Development Environments) mit integrierter SOAP/HTTP-Unterstützung wie z. B. MicrosoftVisual Studio 2005 oder JBuilder die systemeigenen XML-Webdienste zum Generieren von Proxycode nutzen, der die Kommunikation mit einer Instanz von SQL Server abstrahiert. In den meisten Fällen übernimmt die IDE das Generieren und Bereitstellen der Objekte, die von den Clientanwendungen ihrerseits zum Zugriff auf webbasierte Daten verwendet werden.
Bessere Unterstützung für mobile Clients, die nur gelegentlich oder unregelmäßig verbunden sind.
Mithilfe der systemeigenen XML-Webdienste wird auch an jedem Ort und zu jedem Zeitpunkt der Zugriff auf eine Instanz von SQL Server ermöglicht. Das erleichtert das Entwickeln von Anwendungen für mobil oder gelegentlich verbundene Geräte. Nachdem eine Verbindung hergestellt wurde und der Server mit der Verarbeitung der Anforderungen begonnen hat, kann eine Überwachung des Servers mithilfe der vorhandenen Mechanismen erfolgen, welche für herkömmliche netzwerkbasierte Clients verfügbar sind, die TDS und SQL Server Net-Libraries verwendet haben.
Die im Server integrierten Sicherheitsmaßnahmen senken die Notwendigkeit, zusätzliche Firewalls zu implementieren.
Die systemeigenen XML-Webdienste stellen eine integrierte Sicherheitsstufe für den Webzugriff bereit. Anders als bei einem üblichen Webserver lassen die HTTP-Endpunkte, die zum Verwenden durch SQL Server erstellt werden, keinen anonymen Benutzerzugriff zu. Zum Erstellen von Endpunkten sind zunächst auf dem Server Administratorprivilegien der Systemebene erforderlich, und die Endpunkte machen nur solche gespeicherten Methoden verfügbar, die auch beim Konfigurieren der Endpunkte offen gelegt wurden.
Siehe auch