SQL Server XML und Webanwendungsarchitektur

Veröffentlicht: 06. Jan 2001 | Aktualisiert: 17. Jun 2004

Von John A. Bocharov

Dieser Artikel bietet einen Überblick über die sich ergebenden Architekturen, nachdem sowohl die Anwendung Duwamish Books (Phase 4) als auch die robustere Duwamish Online-Anwendung in einer Reihe von SQL Server XML-basierten Lösungen angewandt wurden.

Weitere Informationen zu den SQL Server XML-Technologien, die mit Microsoft SQL Server™ 2000 eingeführt wurden, finden Sie im Artikel mit der Bezeichnung Duwamish Online SQL XML – Durchsuchen des Katalogs.

Auf dieser Seite

 Einführung
 Logische Architektur
 Physische Architektur
 Integration
 Auswirkungen
 Verwendungsempfehlung
 Schlussfolgerung

Einführung

Die Markteinführung von Microsoft SQL Server 2000 hat eine Vielzahl neuer Features mit sich gebracht, darunter eine Reihe neuer XML-Technologien, die als SQL Server XML bezeichnet werden. Diese Technologien enthalten zahlreiche Verbesserungen, Weiterentwicklungen und Features, die SQL Server zu einer webfreundlicheren Anwendung machen und der Microsoft .NET-Vision einen Schritt näher bringen.

SQL Server XML bietet die Möglichkeit, die Architektur einer Webanwendung zu erweitern, zu verbessern oder zu ersetzen. Die neuen Features lassen sich in zwei Hauptkomponenten unterteilen:

• Datenbankkomponenten, die der Datenbank das Lesen, Verarbeiten und Schreiben von XML ermöglichen

• Die SQL Server XML Internet Server API (ISAPI)-Anwendung, die den Zugriff auf die Datenbank über HTTP ermöglicht

Die Verwendung einer oder beider dieser Komponenten bietet eine Reihe interessanter Möglichkeiten im Hinblick auf die Architektur. Wir wollten die Leistung und Flexibilität der neuen Tools testen und wandten die bewährte logische Architektur von Duwamish Online in einer Reihe von SQL Server XML-basierten Lösungen an. Zur Vervollständigung unserer Untersuchung wurden sowohl die einfachere Anwendung Duwamish Books (Phase 4) als auch die robustere Duwamish Online-Anwendung als Teil unseres Tests verwendet. Es folgt ein Überblick der sich daraus ergebenden Architekturen.

Logische Architektur

Unabhängig von der Anwendung müssen immer zwei geltende Architekturen berücksichtigt werden: Die logische Architektur, bei der es sich um das organisierende Prinzip handelt, welches die Gestaltung der Anwendung steuert, und die physische Architektur, welche die Art der Implementierung einer Anwendung repräsentiert. Diese Unterscheidung ist erforderlich, da die beiden Architekturen selten parallel verlaufen. Sie werden sehen, dass die physische Architektur für einen logischen Entwurf je nach Situation unterschiedlich ist.

Bei der Erstellung von Duwamish Online und ihren Vorgängern wurde eine logische Architektur auf der Basis des n-tier-Modells von Microsoft gewählt. Diese Architektur setzt sich aus häufigen Operationen zusammen, die von Webanwendungen durchgeführt werden. Sie ist nicht spezifisch für Duwamish Online.

Abbildung 1. Logische Architektur

Die Anwendung ist in fünf logische Schichten unterteilt. Am weitesten entfernt vom Client ist die Datenschicht, in der die von der Anwendung benötigten Informationen gespeichert werden. Direkt darüber liegt die Datenzugriffsschicht, welche die Daten von ihrer Darstellung in der Datenbank abstrahiert und Routinen enthält, die für alle Datenbankoperationen gelten. Die Datenzugriffsschicht wird direkt von der Geschäftslogikschicht genutzt. Die Geschäftslogikschicht abstrahiert Geschäftstransaktionen durch Verbergen der Logik und Implementierungsdetails vor den darüber liegenden Schichten. Die Workflowschicht ist die nächste Schicht in der Architektur. Sie wird auch als "Geschäftsfassade" bezeichnet und liefert der Darstellungsschicht einfache Schnittstellen, sog. "Fassaden". Intern dient sie zur Statusverwaltung und verwendet die atomaren Operationen, die von der Geschäftslogikschicht offen gelegt werden, zur Durchführung komplizierter Workflows. Schließlich gibt es noch die Darstellungsschicht, die die von der Workflowschicht gelieferten Ergebnisse für den Benutzer umwandelt. Dies kann im einfachsten Fall die Anwendung eines XSL-Stylesheets sein, um die Ergebnisse in HTML umzuwandeln, oder eine komplexere Operation, wie die Erstellung eines Sprachalgorithmus für das Vorlesen der Ergebnisse über eine Telefonleitung.

Betrachten wir nun einige physische Architekturen, die von dieser logischen Architektur abgeleitet werden.

Physische Architektur

Verteilen der Last

Mit SQL Server XML kann die Datenbank viel mehr als nur das Lesen und Schreiben von Daten ausführen. Die XML-Funktionen ermöglichen gespeicherten Prozeduren den Umgang mit großen Mengen extrem strukturierter Daten. Die relevanten Informationen können an die gespeicherte Prozedur als XML übergeben werden, wodurch die Möglichkeit besteht, Geschäftslogik oder Workflow als gespeicherte Prozeduren anstatt als COM+ oder Skript zu implementieren. Dies bedeutet, dass Sie einen größeren Teil der Verarbeitungsarbeit der Anwendung auf die Datenbankschicht verlagern können. Wenn Sie sich für diesen radikalen Ansatz entscheiden, sollten Sie berücksichtigen, dass die Datenbank die am wenigsten skalierbare Komponente der Anwendung ist.

Die Entscheidung darüber, wie Sie die Verarbeitungsarbeit Ihrer Anwendung zwischen der Datenbank und Webservern verteilen, ist von Bedeutung. Sie wirkt sich auf folgende Faktoren aus: Die Hardware und Software, die eine Anwendung benötigt, die Fachkenntnisse für ihre Entwicklung, sowie den Bereitstellungs-, Aktualisierungs- und Verwaltungsprozess der Anwendung. Aus Gründen der Einfachheit bezeichne ich eine Serverkonfiguration, bei der Webserver den Großteil der Arbeit erledigen, als "kopflastig", umgekehrt eine Konfiguration, bei der die Datenbank die meiste Arbeit erledigt, als "bauchlastig".

Zwei Faktoren tragen dazu bei, dass der "kopflastige" Server als Modell für die meisten Anwendungen ausgewählt wird.

• Kosten. Die Software und Hardware für Datenbankserver ist in der Regel teurer als für Webserver.

• Skalierbarkeit. Die Skalierbarkeit der Datenbank wurde zwar in SQL Server 2000 gegenüber SQL Server 7.0 verbessert. Für die volle Ausnutzung der Leistungsfähigkeit neuer Hardware ist jedoch eine sorgfältige Planung und ein effektiver Wartungsplan erforderlich.

Aus diesen Gründen erfolgt die Besprechung einer Architektur, die auf einer "bauchlastigen" Serverkonfiguration basiert, zum Schluss.

Physische Architektur des n-tier-Modells von Microsoft

Sehen wir uns zum Vergleich die physische Architektur für Duwamish Online an, bei der SQL Server XML nicht verwendet wird. Sie dient dazu, die soeben beschriebene logische Architektur so detailgetreu wie möglich zu implementieren. Obwohl jede Schicht für die Durchführung einer Art logischer Operation ausgelegt ist, findet doch eine gewisse Verteilung der Funktionalität außerhalb statt. So werden z.B. einige Teile der Geschäftslogik aus Gründen der Leistungsoptimierung von gespeicherten Prozeduren ausgeführt. Die Leser, die mit Phase 4 von Duwamish Books vertraut sind, werden schnell erkennen, dass sich die Architektur wenig verändert hat.

Abbildung 2. Architektur des n-tier-Modells von Microsoft

Diese Architektur ermöglicht jeder Komponente unter Verwendung der dafür geeignetsten Technologie die Spezialisierung auf eine bestimmte Art von Aufgabe. Der Cache wurde in C++ für maximale Leistungfähigkeit erstellt. Die Darstellungslogik wird von Active Server Pages (ASP) und XSL übernommen. Workflow, Geschäftslogik und Datenzugriff wird von Microsoft Visual Basic-Komponenten durchgeführt, und Datenbankoperationen werden in Transact SQL (T-SQL) verarbeitet. Die Schichten, die nicht durch eine technologische Grenze getrennt sind, unterscheiden sich durch ihre Implementierung als separate COM+-Komponenten. Als Preis für diese Flexibilität muss dafür gesorgt werden, dass die unterschiedlichen Schichten zusammenarbeiten. Das umgebungsübergreifende Debugging ist keine einfache Aufgabe, und es muss darauf geachtet werden, dass Daten, die in einer Umgebung sicher sind, für die jeweilige Zielumgebung umformatiert werden. (Die Zeichenfolge "a < b" wird z.B. in einer Datenbank ohne Problem gespeichert, führt aber in einer XML-Datei ohne Escapezeichen zu einer fehlenden Anzahl von Klammern, wodurch es beim Parser zu gravierenden Problemen kommt.)

Physische Architektur auf der Leseseite

In Duwamish Online kommt eine einzige physische Architektur in der ganzen Anwendung zum Einsatz. Im Gegensatz dazu verwenden SQL Server XML-basierte Versionen zwei komplementäre physische Architekturen: Eine für Lesevorgänge und eine für Schreibvorgänge. In unserem Fall ist dies zutreffend, da die beiden Fälle eine unterschiedliche Art der Verarbeitung erforderlich machen.

Anmerkung Ein vollständiges Diagramm der Architektur finden Sie unter https://msdn.microsoft.com/voices/news/sqlxml.asp (in Englisch).

Abbildung 3. Architektur auf der Leseseite

Die SQL Server XML-Technologien werden von allen Schichten genutzt, also von der Datenbankschicht bis zur Darstellungsschicht, um eine maximale Leistung zu erreichen. Die SQL Server XML ISAPI-Anwendung ersetzt ASP auf der Webebene. Die ISAPI-Anwendung und der SQLOLEDB-Provider automatisieren den Datenzugriff, wodurch der Codeumfang und die Entwicklungszeit reduziert werden. Der Preis für diese Leistung ist der Verlust des robusten Objektmodells und damit der Flexibilität von ASP. Im weiter unten folgenden Abschnitt Physische Architektur auf der Schreibseite wird erklärt, welche Funktionalität verloren geht und wie sich der Anwendungscode in Ihre Architektur integrieren lässt, um diese Flexibilität ggf. wieder zu erlangen.

Sehen wir uns nun einige der etwas subtileren Funktionen der Architektur an. Die Darstellung wird ausschließlich von XSL-Stylesheets erledigt. Dies ist sinnvoll, da es sich bei den von der Datenbank zurückgelieferten Daten um XML handelt. Die Verwendung von XSL bringt den zusätzlichen Vorteil der Technologieunabhängigkeit. Anders gesagt: Eine Vorlage, eine ASP-Seite und eine COM+-Komponente können dasselbe Stylesheet verwenden. Vorlagen umfassen die Workflowschicht. (Vorlagen sind Dateien mit XML-Instruktionen, die datengesteuerte dynamische Webseiten generieren, was einen schnelleren Zugriff auf die Datenbank über HTTP ermöglicht und gleichzeitig eine Ebene der Datenabstraktion und Datensicherheit bereitstellt.) Vorlagen verwenden in der Regel gespeicherte Prozeduren für den Datenzugriff, obwohl auch eine Nutzung von XML Data Reduced (XDR)-Schemas möglich ist. Diese liefern eine intuitive Syntax für die Zuordnung von Datenbankobjekten zu XML-Elementen und bieten die Möglichkeit, XPath (XML Path Language) für Datenbankabfragen zu verwenden. Eine ausführlichere Beschreibung von Vorlagen, XDR-Schemas und Implementierungsdetails finden Sie in meinem früheren Artikel Duwamish Online SQL XML – Durchsuchen des Katalogs.

Diese Architektur verfügt über keine separate Geschäftslogikschicht. Dies liegt daran, dass die schreibgeschützen Vorgänge in unserer Anwendung nur über einen minimalen Umfang an Geschäftslogik verfügten, der sich leicht in die Datenzugriffsroutine integrieren ließ. Falls dies für Ihre Anwendung nicht zutrifft, lässt sich die Geschäftslogikschicht effektiv als eine Reihe gespeicherter Prozeduren in der Datenbank implementieren. Ideen und optimale Verfahren dafür finden Sie im Abschnitt Datenorientierte Architektur weiter unten in diesem Artikel.

Die größte Änderung liegt wohl in der Datenbankschicht. Eine Reihe neuer Funktionen ermöglicht gespeicherten Prozeduren das direkte Lesen und Schreiben von XML. Sogar der gesamte Datenempfang erfolgt über XML.

Physische Architektur auf der Schreibseite

SQL Server XML-Vorlagen sind extrem optimiert, um einen möglichst effizienten Zugriff auf die Datenbank über HTTP zu ermöglichen. Der Preis dafür ist ein etwas begrenzter Funktionsumfang. Für Fälle, in denen Funktionen benötigt werden, die nicht in Vorlagen vorhanden sind, wird die proprietäre Anwendung von SQL Server durch ASP, eine Kombination aus ASP und COM+ oder eine benutzerdefinierte ISAPI-Anwendung ersetzt.

Die in diesem Abschnitt beschriebene Architektur ist angebracht, wenn Ihre Seite folgende Aufgaben erfüllen muss:

• Zugriff auf Datenbanken auf mehreren Servern

• Verarbeiten einer HTTP-Anforderung, deren Format zur Entwurfszeit unbekannt ist

• Aufrufen eines COM/COM+-Objekts

• Verwenden von COM+-Transaktionen

• Herstellen einer Verbindung mit beliebigen Anwendungen oder Webdiensten im Internet, z.B. einem Zahlungsanbieter

Abbildung 4. Architektur auf der Schreibseite

Der Code auf der Webebene repräsentiert vier Schichten der Anwendungsfunktionalität – Datenzugriff, Geschäftslogik, Workflow und Darstellung. Stellen Sie bei der Entwicklung Ihrer Anwendung sicher, dass Sie den Code gemäß der Architektur gestalten. Dadurch wird Ihr Code wesentlich "lesbarer" und damit leichter zu verwalten. Wenn Sie sich für die ausschließliche Verwendung von ASP entscheiden, können sich Skriptklassen als sehr effektiv erweisen. Sind in den Geschäftslogik- oder Workflowschichten eine Vielzahl komplexer Verarbeitungsaufgaben durchzuführen, kann sich die Verwendung von COM+-Komponenten für diese Schichten als wesentlich schneller erweisen. Umgekehrt sind bei einem geringen Verarbeitungsaufwand evtl. Skripts schneller.

Was diese Architektur so neu und interessant macht, ist die Tatsache, dass alle Schichten, von der Daten- bis zur Darstellungsschicht, XML zur Übertragung und Speicherung von Informationen verwenden. Gespeicherte Prozeduren in der Datenbank verwenden neue Funktionen zum Lesen und Schreiben von XML. Die Datenzugriffsschicht nutzt ADO 2.6-Streams für eine effiziente, XML-basierte Kommunikation mit der Datenbank.

Noch innovativer ist der Ansatz, einige der mittleren Schichten nach unten in die Datenbank zu verschieben.

Datenorientierte Architektur

Die Duwamish Online-Architektur basiert auf der Annahme, dass die Datenbank die wenigsten Operationen durchführen muss, da sie die geringste Skalierbarkeit aufweist. Neue Funktionen, wie verteilte partitionierte Ansichten (Distributed Partitioned Views), ermöglichen die Verteilung der Arbeitsauslastung auf mehrere Server, wodurch die Skalierbarkeit der Datenbank verbessert wird und die Entwickler entscheiden können, wohin der Großteil der Arbeit verlagert werden soll.

Wenn Sie eine "bauchlastige" Serverfarm (mehr Leistung auf der Datenbankseite) bei der SQL Server XML-Architektur wählen, ist eine weitere Alternative die schichtweise Anordnung von gespeicherten Prozeduren in der Datenbank – also auf ähnliche Weise wie bei den Komponenten des n-tier-Modells. Dabei sollten Programmierstandards wie die Auswahl entsprechender Datenstrukturen und die Vermeidung von doppelten Codeabschnitten möglichst beachtet werden.

Abbildung 5. Datenorientierte Architektur

Die Darstellungsschicht in dieser Architektur enthält auch Code für den Zugriff auf gespeicherte Prozeduren in der Datenbank. Dieser kann mit dem Code in der traditionellen Datenzugriffsschicht identisch sein. Es wäre jedoch irreführend, diese als "Datenzugriffsschicht" zu bezeichnen, da diese Routinen "Fassaden" aufrufen, die von der Workflowschicht offen gelegt werden.

Es gibt eine Falle, die Sie bei der Entwicklung mit gespeicherten Prozeduren vermeiden sollten. Betrachten wir zunächst einen Entwurf, bei dem einige intelligente gespeicherte Prozeduren zum Einsatz kommen. Diese führen zunächst geläufige Tasks für die Schicht und anschließend eine Vermittlungslogik aus, die angibt, wohin der Codepfad als Nächstes führt. Ein Aufruf einer "intelligenten Prozedur" in der Workflowschicht kann einer von mehreren unterschiedlichen Prozeduren entsprechen. Eine solche Prozedur kann wie folgt aussehen:

CREATE PROCEDURE  
/* Dies ist eine intelligente Prozedur, die Workflow-Operationen durchführt */ 
DoWorkflow 
   /* Action dient zur Auswahl einer von mehreren Operationen für diesen Aufruf */ 
   @Action nvarchar(255), 
/* SomeOtherParameters ist ein Platzhalter für andere Eingaben, die der Workflow */ 
/* eventuell benötigt */ 
   @SomeOtherParameters ntext 
AS 
/* Für Workflow typische Operationen durchführen */ 
Execute SomeCommonWorkflowOperations 
If @Action = N'Action1' 
BEGIN 
      /* Action 1 ausführen */ 
   Execute BusinessLogicAction1 
END 
Else If @Action = N'Action2' 
BEGIN 
      /* Action 2 ausführen */ 
   Execute BusinessLogicAction2 
END 
GO 

Beim ersten Aufruf der Prozedur optimiert SQL Server die Ausführung für den jeweiligen Codepfad, der zuerst ausgeführt wurde. Dies bewirkt, dass die verbleibenden Codepfade weniger effizient ausgeführt werden, selbst wenn diese aufwendiger sind oder häufiger verwendet werden.

Wenn Sie eine optimale Ausführung aller Codepfade sicherstellen möchten, sollten Sie eine separate Prozedur für jede Operation erstellen und Vermittlungslogik möglichst vermeiden. Zur Vermeidung von doppelten Codeabschnitten sollte Funktionalität, die von mehreren Operationen in beliebigen Schichten geteilt wird, in einer separaten Prozedur abgelegt werden. Auch wenn dieser Entwurf zu einer großen Anzahl von Prozeduren führen kann, sollten diese Optimierungen eine größere Effizienz der Anwendung zur Folge haben.

Integration

Einer der wunderbaren Aspekte der Webentwicklung ist die Tatsache, dass die Implementierung dem Benutzer verborgen bleibt. Daher können die in diesem Artikel beschriebenen Architekturen problemlos in einer einzelnen Anwendung mit einer einheitlichen Benutzerführung kombiniert werden. Hier sind einige Richtlinien, mit denen sich die Integration unterschiedlicher Teile einer Anwendung vereinfachen lässt:

• Verwenden Sie XML in der gesamten Anwendung. XML lässt sich innerhalb verschiedener Technologien verwenden, einfach mit XSL-Stylesheets transformieren und an beliebiger Stelle problemlos speichern. Mit SQL Server XML ist die Verwendung von XML so einfach wie noch wie.

• Formatieren Sie den Code, wenn immer möglich.

  • Verwenden Sie XML-Stylesheets zum Transformieren von XML. Dasselbe XSL-Stylesheet kann problemlos von einer Vorlage, einer COM+-Komponente und einem Skript gleichzeitig genutzt werden.

  • Wenn das Skript mehrere Funktionen durchführt, formatieren Sie den Code mit Skriptklassen.

  • Verwenden Sie auf der Datenbankseite stets gespeicherte Prozeduren für den Datenbankzugriff. Nicht nur sind diese leichter zu verwalten, sondern werden auch wesentlich schneller ausgeführt als nicht kompilierte SQL-Abfragen.

Auswirkungen

Dieser Abschnitt beschreibt, wie sich die Verwendung einer dieser Architekturen auf eine Anwendung hinsichtlich ihrer Fähigkeiten und natürlich ihrer Leistung auswirkt.

Programmierbarkeit

Programmierbarkeit drückt aus, wie einfach sich eine Anwendung codieren lässt. Oft wird sie auch als Verhältnis zwischen Entwicklungszeit einer Anwendung und ihrem Funktionsumfang angesehen. Nehmen wir z.B. die Duwamish Online-Anwendung. Die fünf Schichten der Anwendung basieren auf einer Reihe extrem unterschiedlicher Technologien. Die Darstellungsschicht verwendet C++ (für die Cachekomponente) und Webtechnologien, wie XML, XSL und ASP. Die Workflow-, Geschäftslogik- und Datenzugriffsschichten sind Visual Basic COM+-Komponenten, und die gespeicherten Prozeduren in der Datenbank wurden in T-SQL erstellt. Der Einsatz so vieler Technologien hat den Vorteil, dass Entwickler die beste Technologie für jede Art von Operation auswählen können. Eine effektive und effiziente Zusammenarbeit all dieser Komponenten kann jedoch eine ziemliche Herausforderung darstellen. Die Ablaufverfolgung und das Debugging mehrerer Komponenten ist immer schwieriger, wenn die Komponenten mit unterschiedlichen Tools und Programmiersprachen entwickelt wurden.

Der übergreifende Einsatz von SQL Server XML in Ihrer Anwendung hilft Ihnen dabei, die Schwierigkeiten der Arbeit mit unterschiedlichen Technologien zu minimieren. (XSL stellt hier eine Ausnahme dar: Sie ist keineswegs auf SQL Server XML beschränkt, sondern eng in SQL Server XML-Vorlagen integriert.) Die Schichten arbeiten nahezu reibungslos zusammen. Das Debugging zwischen den Schichten ist wesentlich einfacher, da alle Zwischendaten im XML-Format vorliegen. Es ist keine Kompilierung erforderlich. Der größte Vorteil im Hinblick auf die Programmierbarkeit leitet sich jedoch von der drastischen Reduzierung des Codeumfangs ab: Die SQL Server XML-basierte Version von Duwamish Books, Phase 4, erreicht dasselbe Ergebnis wie sein COM+-basiertes Gegenstück mit etwa einem Zehntel des ursprünglichen Codes. Dies wird durch die integrierte Funktionalität von SQL Server XML für den Datenzugriff, XML-Transformationen, XSL-Transformationen und Datencaching erleichtert.

Nichtsdestoweniger werden die Vorteile durch das Fehlen eines effektiven Debugtools für XSL und die relative Unausgereiftheit der Debugtools für die anderen neuen Technologien geschmälert, vor allem im Vergleich mit den sprachübergreifenden Debuggingfunktionen in Microsoft Visual Studio.

Verwaltbarkeit

SQL Server XML-Anwendungen lassen sich leicht bereitstellen. Für den Code, der auf der Webebene ausgeführt wird, werden die Dateien einfach in ihr Zielverzeichnis kopiert, und anschließend werden durch die einmalige Ausführung eines Konfigurationsdienstprogramms die entsprechenden virtuellen Verzeichnisse hergestellt. Aktualisierungen lassen sich einfach durch Ersetzen der veralteten Dateien durchführen. Darüber hinaus ermöglich SQL Server Enterprise Manager eine einfache Verwaltung von Datenbankobjekten.

Leistung

Ausführliche Informationen finden Sie im Abschnitt zum Thema Leistung im Artikel Duwamish Online SQL XML – Durchsuchen des Katalogs.

Verwendungsempfehlung

Die möglicherweise wichtigste Frage bei allen diesen neuen Technologien ist, wann die jeweilige Technologie eingesetzt werden soll. SQL Server XML ist nicht die ultimative Lösung für jede Internetaufgabe, jedoch können die Vorteile in bestimmten Situationen überwältigend sein. Dazu zählen eine drastische Reduzierung des Codeumfangs und der Entwicklungszeit, bessere Leistung und einfachere Verwaltung. Die beiden Hauptkomponenten der neuen Technologie, die Datenbank und die ISAP-Anwendung, haben unterschiedliche Einsatzszenarios, wie in den nachfolgenden Abschnitten beschrieben.

Die Datenbankserver-Komponenten von SQL Server XML sollten in nahezu allen Anwendungen verwendet werden. Selbst die Konvertierung einer vorhandenen Anwendung für die Verwendung von XML aus der Datenbank ist den Aufwand wert. Zu den wichtigsten Vorteilen zählen:

• Einfache Lokalisierung (mit XSL)

• Plattform- und Technologieunabhängigkeit

• Einfaches Zwischenspeichern von XML-Daten

• Möglichkeit der Verwendung von Offlineanwendungen/getrennten Anwendungen

• Einfache Einbindung oder Erstellung von Webdiensten

• Interoperabilität mit anderen Anwendungen

Die Webschnittstellen-Komponenten der neuen Technologie sind wesentlich spezialisierter. Sie bieten einen sehr schnellen, effizienten Zugriff auf die Datenbank und die Möglichkeit, mit Hilfe eines XSL-Stylesheets problemlos datengesteuerte Seiten zu erstellen. Die Vorteile sind nicht unbedeutend. In unseren Tests übertraf die Katalogsuche in Duwamish Online mit SQL Server XML (ohne Cache) Duwamish Online (mit Cache) um bis zu 15 Prozent. Frühe Tests mit einer Technologievorabversion von SQL Server 2000 zeigen, dass der ISAPI-Cache von SQL Server XML die Leistung um eine weitere Größenordnung verbessern kann. Wenn Ihre Anwendung jedoch eine der folgenden Eigenschaften aufweist, sollten Sie die Verwendung einer ASP-basierten mittleren Ebene in Erwägung ziehen.

• Umfangreiche Geschäftslogikroutinen ohne Beziehung zur Datenabstrahierung. Diese können an zwei Stellen implementiert werden: gespeicherte Prozeduren in der Datenbank oder Skript in XSL. Skript ist nicht für seine Effizienz berühmt, und SQL ist u.U. nicht die optimale Sprache dafür.

• Umfangreiche Zeichenfolgenbearbeitung, vor allem des Resultsets. Die Ausnahme dieser Regel sind Escapezeichenfolgen, die in der Datenbank für XML oder HTML gespeichert sind. Eine neue Funktion in SQL Server 2000 erledigt dies automatisch. Weitere Informationen finden Sie in der SQL Server-Onlinedokumentation (XML- und Internetunterstützung \ Abrufen und Schreiben von XML-Daten \ Abrufen von XML-Dokumenten mithilfe von FOR XML \ Verwenden des EXPLICIT-Modus \ F. Angeben der cdata-Direktive).

• Große Anzahl von HTML-Eingaben. Eine Einschränkung der Vorlagen hindert diese daran, alle Informationen von einer HTTP-Anforderung abzurufen, deren Format zur Entwurfszeit bekannt ist. Dies kann mit Hilfe einer ASP-Seite erledigt werden.

Vorsicht! SQL Server 2000 ermöglicht auch den direkten Zugriff auf die Datenbank über einen URL. Dies lässt u.a. auch den Einsatz von dynamischen Vorlagen zu, wodurch eine Vielzahl der Probleme mit der Architektur gelöst werden können. Wenn Sie jedoch diese Funktion aktivieren, gestatten Sie damit auch potentielle Abfragen, die die Datenbank löschen. Stellen Sie daher bei Verwendung dieser Option sicher, dass die Datenbanksicherheit zu 100 % gewährleistet ist.

Schlussfolgerung

SQL Server XML bietet einen Anreiz für den universellen Einsatz von XML in Ihren Anwendungen, indem XML direkt von der Datenbank abgerufen werden kann. Eine neue ISAPI-Anwendung bietet zwar optimale Leistung, ist aber u.U. für bestimmte Einsatzgebiete in Ihrer Anwendung nicht immer die richtige Lösung.