War diese Seite hilfreich?
Ihr Feedback ist uns wichtig. Teilen Sie uns Ihre Meinung mit.
Weiteres Feedback?
1500 verbleibende Zeichen
Exportieren (0) Drucken
Alle erweitern

WildSite: Große XML-Datenmengen verwalten

Veröffentlicht: 19. Jun 2000 | Aktualisiert: 14. Jun 2004
Von Mischa Schmierer

Der Vormarsch von XML ist kaum noch aufzuhalten. Es ist die Markup-Language der Wahl für den Datenaustausch, aber auch in der Datenhaltung. Bei hohem Datenaufkommen, Mehrbenutzerzugriff und schneller Verarbeitung wird deutlich, dass konventionelle Werkzeuge den Anforderungen von XML nicht gerecht werden. Sowohl relationale als auch dateibasierte Ansätze haben wesentliche Nachteile in der XML-Verarbeitung. Native XML-Server bieten hier eine willkommene Alternative.

* * *

Diesen Artikel können Sie hier lesen dank freundlicher Unterstützung der Zeitschrift:

Bild06





Speicherung und Manipulation von XML-Daten mit einem XML-Datenbanksystem

Für die Popularität der Extensible Markup Language (XML) sind besonders zwei Dinge verantwortlich: Zum einen ist sie in vielen vertikalen Industrien verwendbar, da sie im Grunde nur abstrakt die Struktur der Daten beschreibt, wobei die domänenspezifische Semantik mittels Document Type Definitions (DTDs) und Namespaces frei definierbar bleibt [1]. Zum anderen können die unterschiedlichsten existierenden Datenformate in XML abgebildet und überführt werden.

Sind Daten einmal im XML-Format, so ist es oft einfach, diese beispielsweise nach HTML für das Internet oder in ein anderes XML-Format für einen bestimmten Geschäftspartner zu überführen. Es ist wichtig, im Auge zu behalten, dass sich XML mit Daten beschäftigt, nicht mit "Dokumenten" im herkömmlichen Sinn. In Unternehmen fallen häufig sehr große Datenmengen an. Darüber hinaus werden Daten in der Regel von mehreren Anwendungen bzw. Personen parallel verarbeitet, so dass Mehrbenutzersysteme unabdingbar sind. Gerade in diesem Umfeld können ernsthafte Probleme auftreten, wenn der falsche technologische Ansatz gewählt wird.

Der Dateisystem-Ansatz

Sind die Vorteile von XML einmal erkannt, ist ein Projekt oft nicht weit entfernt, und man begibt sich auf die Suche nach der passenden Technologie. Um XML-Daten persistent zu halten, liegt es nahe, die Datei im Dateisystem des Betriebssystems zu wählen. Vorteile sind hier der einfache Zugriff und die Verwendung von vorhandenen Werkzeugen. Meist nutzen sie jedoch nicht die Vorzüge von XML. Wer hat noch nicht eine XML-Datei mit einem normalen Text-Editor bearbeitet oder gar eine Volltextsuche darauf ausgeführt? In der nächsten "Evolutionsstufe" benutzt man schon mal das Microsoft XML-Notepad und den Internet Explorer 5, die zumindest sicherstellen, dass Dokumente wohl geformt im Sinne von XML bleiben (s. [2]).

Um mit XML vertraut zu werden, ist dies ein gangbarer Weg, doch im operativen Einsatz sind Datenmengen im dreistelligen Mega- oder Gigabyte-Bereich keine Seltenheit mehr. Benutzt man Werkzeuge, die XML-Dokumente als Textdateien verarbeiten, dann nutzt man die Strukturinformation nicht, die doch gerade beim Suchen oder Transformieren so hilfreich ist. Benutzt man aber Werkzeuge, die dank eines XML-Parsers aus der Struktur Nutzen ziehen, merkt man bald, dass der Parser bei großen XML-Dokumenten eine ganze Zeit beschäftigt sein kann (vgl. [3]). Auch kleine Operationen, wie das Verändern eines einzigen Attributs, werden zur zeitaufwendigen Prozedur, weil XML-Dokumente nur als Ganzes gelesen und nach einer Modifikation gespeichert werden können. Wäre es hier nicht vorteilhaft, das Dokument nur einmal zu parsen und mehrere Operationen darauf auszuführen? Im Idealfall sollte auch nur der Teil des Dokuments im Arbeitsspeicher sein, den man bearbeiten möchte, und nicht das ganze Dokument, das viel größer als der Arbeitsspeicher sein kann.

Eine häufige Anforderung ist auch der parallele Zugriff auf dasselbe Dokument. Solange alle Anwender nur lesend zugreifen, gibt es keine Probleme; doch es müssen auch Daten geändert oder neue hinzugefügt werden. Die dateiorientierte Sperrenverwaltung des Dateisystems ist dafür zu grob.

Letztendlich führen die ACID-Kriterien (Atomarer, konsistenter, isolierter Zugriff mit Dauerhaftigkeit) zur Suche nach einem Datenbanksystem, das genau dafür geschaffen wurde.

Der relationale Ansatz

In absehbarer Zeit werden alle relationalen Datenbankhersteller verschiedenartige XML-Adapter anbieten (vgl. [4] oder [5]). Da relationale Datenbanksysteme zur Standardausstattung jedes Unternehmens gehören, bietet es sich förmlich an, ein weiteres Problem mit dieser wohl bekannten Technologie zu lösen. Die ACID-Kriterien sind dadurch erst einmal erfüllt, doch wie sieht es mit sonstigen Anforderungen aus?

Grundsätzlich sind zwei Speicherungsarten denkbar: die Speicherung des XML-Dokuments als BLOB (Binary Long Object), also am Stück, oder in seine Bestandteile zerlegt.

Einige Produkte speichern tatsächlich das XML-Dokument als BLOB und profitieren beim Zugriff von den Indizes, die beim Einlesen erstellt wurden. Hierbei wird die Strukturinformation indirekt, über die Indizierung, genutzt. Beim schreibenden Zugriff und beim Auslesen von Dokumentteilen muss aber wieder ein Parser zu Hilfe gezogen werden, und das kostet Zeit. Der parallele Schreibzugriff ist meist nur sehr begrenzt möglich, da die Sperrverwaltung des Datenbanksystems die Strukturinformation des Dokuments nicht nutzt.

Andere Produkte zerlegen die Dokumente gemäß ihrer Struktur. XML-Parser zerlegen XML-Dokumente in der Regel konform zum Document Object Model (DOM) [6,7]. Es ist jedoch problematisch, ein DOM in ein relationales Modell abzubilden. Das Resultat sind wenige Tabellen mit sehr vielen Einheiten. Eine Tabelle Attribute könnte beispielsweise alle Attribute aller Tags aller Dokumente beinhalten. Der Zugriff auf ein einfaches DOM-Objekt, das nur wenige Attribute und einen Text repräsentiert, würde gigantische relationale Joins verursachen. Das Laufzeitverhalten wäre entsprechend.

Abhilfe schafft eine Modellierung, die nicht das DOM abbildet, sondern eine konkrete DTD. Solche Modellierungen entsprechen einer niedrigeren Normalisierungsstufe und benötigen weniger Joins beim Datenzugriff, was ein besseres Laufzeitverhalten ergibt. Bei großen Datenmengen können zwar immer noch Engpässe auftreten, doch ist die Sperrenverwaltung feiner abgestuft, also besser geeignet für den Mehrbenutzerbetrieb. Doch da das Datenmodell in dieser Variante von einer DTD abhängig ist, erfordern Änderungen der DTD auch eine Schemaänderung der Datenbank; dadurch müssen sehr häufig Datenbestände konvertiert werden. Die Dynamik und Erweiterbarkeit, die XML verspricht, bleibt hier auf der Strecke (Kasten 1).

Das X in XML steht für extensible bzw. extensibility, also Erweiterbarkeit. Ein Ziel ist es, Datenstrukturen dynamisch erweiterbar zu halten, damit Anwendungssysteme von Strukturänderungen weitest gehend entkoppelt werden. In XML können bestimmte Anwendungen zusätzliche Attribute oder Tags hinzufügen, ohne dass ein XML-Dokument für andere "ungültig" werden muss. So kann man Anwendungen schrittweise umstellen - oder muss bestimmte Anwendungen gar nicht umstellen. Wo XML als Datenaustauschformat benutzt wird, ist die Kopplung der Kommunikationspartner also vergleichsweise lose und änderungstolerant. Dem steht die übliche, sehr enge Kopplung über Objekt-Interfaces gegenüber, bei der die Partner über COM-Interface-IDs, Positionen von Funktionsadressen in vtables, Parameterpositionen, -zahlen und -typen genau Bescheid wissen müssen (vgl. [8]).

Kasten 1: Das X in XML.

Anforderungen an die Datenhaltung in XML

Vor diesem Hintergrund ergeben sich bestimmte Anforderungen an die Datenhaltung größerer XML-Datenmengen:

  • ACID-Anforderungen zur sicheren Ablage der Daten, auch im Fehlerfall

  • Ablage in geparster Form zur Laufzeitverbesserung

  • Fein abgestufte Sperrenverwaltung für den Mehrbenutzerbetrieb

  • Strukturinformation für das Suchen, Filtern und Transformieren nutzen

  • Standardkonformität, z.B. zum Schutz vor zu starker Herstellerbindung

Beispielszenario

Ein häufiges Problem in einem Unternehmen ist die Verbreitung und das Wiederfinden von Informationen, die ja nicht immer zentral und wohl strukturiert in einer Datenbank abgelegt sind. Besonders dann nicht, wenn es sich um Gesprächszusammenfassungen, Briefe an Kunden, Angebote, Memos o.ä. handelt. Viel zu oft liegen sie in Dokumenten wie MS Word, MS Excel, MS PowerPoint, und vielen, vielen anderen Dateiformaten. Eine Gartner-Studie schätzt solche Datenbestände auf bis zu 85% aller verfügbaren Daten in einem Unternehmen.

Im Beispiel sollen die Daten aus MS Office-Dokumenten extrahiert und in ein XML-Dokument überführt werden. Eine weitere Anforderung ist, diese neue Datenbasis im Intranet über ein Browser-Frontend verfügbar zu machen, damit sie für jeden leicht zugänglich ist und die Wartungskosten minimal bleiben.

Es handelt sich dabei um strukturierte (z.B. Excel), semistrukturierte (z.B. PowerPoint) oder potenziell unstrukturierte (z.B. Word) Datenquellen. XML ist durch seine Dynamik dazu geeignet, sowohl strukturierte als auch semistrukturierte Daten abzubilden. Wenn die Strukturinformation fehlt, ist menschliche Intelligenz gefragt. Das Problem der Unstrukturiertheit kann durch organisatorische Richtlinien gelöst werden. In unserem Beispiel ist es z.B. vorgeschrieben, die zehn Standard-Überschriften in Word zu verwenden. Daraus wird die Strukturinformation abgeleitet.

Eine XML-basierte Lösung bietet sich auf Grund der Dynamik und Verschiedenartigkeit der beteiligten Dokumente an. Alle Mitarbeiter sollen jederzeit Inhalte einspielen können; zudem sollen Abfragen in Form von Recherchen ständig möglich sein. Das Datenvolumen wird mit der Zeit sehr groß, und die Akzeptanz des Systems ist sehr stark abhängig von den Antwortzeiten der Recherchen und der Transformation der Daten in darstellbares HTML-Format.

Im Beispiel werden Office-Dokumente anhand einer kleinen Visual Basic-Anwendung in XML konvertiert und in eine XML-Datenbank eingespielt, die von einem eXcelon XML-Datenserver verwaltet wird. Sofort nach dem Import sind die Daten über einen Web-Server abrufbar. Er besitzt ein spezielles Plug-In, um auf den Datenserver zuzugreifen. Damit der Endbenutzer kein XML zu sehen bekommt, werden die Daten mithilfe von XSLT-Transformationen serverseitig in HTML transformiert.

Datenhaltung und -zugriff

Der eXcelon-Datenserver

Die Firma eXcelon Corporation stellt die eXcelon Dynamic Application Platform (DAP) her [9], die aus mehreren Werkzeugen zur dynamischen XML-Verarbeitung besteht. Ein kurzer Überblick über die Komponenten befindet sich in Kasten 2. Ein wesentlicher Bestandteil ist der eXcelon-Datenserver, der geschaffen wurde, um den oben aufgeführten Anforderungen gerecht zu werden.

Dieser Datenserver verwaltet beliebig viele XML-Datenbanken. Eine XML-Datenbank ist organisiert wie ein Dateisystem. Daher existiert auch ein zusätzliches Werkzeug, der eXcelon-Explorer (siehe Hilfreiche Werkzeuge), der nicht nur vom Namen, sondern auch von der Funktionalität her an den Windows-Explorer erinnert. Eine solche eXcelon-Datenbank kann beliebige Unterverzeichnisse und beliebige Dateien enthalten. Im Beispiel werden etwa zusätzlich zu den extrahierten XML-Daten auch die Office-Dokumente selbst abgelegt. Die Besonderheit ist, dass XML-Dateien mit einem Parser gemäß dem DOM zerlegt werden können und dann tatsächlich ständig, also persistent, zur Verfügung stehen.

Datenbankaufbau

Da das zu Grunde liegende Datenmodell das DOM ist, ist eine DTD nicht zwingend erforderlich. Man kann eine DTD validieren, falls es notwendig ist. Wichtig für die dynamische Erweiterbarkeit und die Softwarewartungskosten ist aber, dass die DTD keinen Einfluss auf das Datenmodell hat, damit DTD-Änderungen nicht zu Änderungen des Datenbankschemas führen.

Ein XML-Dokument in Form des DOM ist ein Objektbaum mit Wurzel, Knoten und Blättern. Abbildung 1 soll die baumartige Struktur verdeutlichen. Ein Vorteil dieser Darstellungsart: Man kann sehr effizient von der Wurzel zu einem Blatt navigieren. Da solche Anfragen nicht vom Datenvolumen abhängen, sind sie auch bei hohem Datenvolumen performant. Für assoziative Anfragen können verschiedene Indizes definiert werden, um die Anfragezeit zu optimieren (Näheres unter Hilfreiche Werkzeuge).

Da die XML-Dokumente von einem Datenbanksystem verwaltet werden, sind die ACID-Anforderungen erfüllt. Kleine Operationen sind effizient möglich, weil eine Anwendung ständig, ohne erneutes Parsen, auf die Bestandteile des Dokuments zugreifen kann. Auch können mehrere Benutzer auf dasselbe Dokument zugreifen - Sperrkonflikte entstehen nur, wenn sie gleichzeitig schreibend auf dasselbe Element zugreifen.

Bild01

Abbildung 1: XML-Daten sind hierarchisch und können als Objektbaum dargestellt werden. Links sehen Sie ein XML-Dokument im Internet Explorer 5; rechts die Dokumentstruktur in einer Baum-Ansicht.

Server-Extensions: Die serverseitige Programmierschnittstelle

Der Datenserver besitzt ein DOM-konformes API. Ab Version 2.1 wird auch das Simple API for XML (SAX) [10] unterstützt; darauf werde ich hier jedoch nicht näher eingehen.

Der Server kann auch funktional erweitert werden; solche Erweiterungen heißen Server-Extensions und können mittels COM oder Java erstellt werden. Die Lösung für das Beispielszenario benutzt eine Server-Extension, die einen ID-Zähler implementiert, der eindeutige Dokumentenkennungen liefert. Diese oft benötigte Funktionalität ermittelt und inkrementiert den Wert des Attributs idcount vom äußersten XML-Element CONTENTS der Beispieldatenbank (s. Abbildung 1). Der Quellcode der Server-Extension befindet sich in Listing 1.

Implements IXlnServerExtension 
Private Function IXlnServerExtension_Run(ByVal ipStore 
As XLNCEXTLib.IXlnXMLStore, ByVal ipFile As XLNCEXTLib.IXlnFile, ByVal ipOptArgs 
 As XLNCEXTLib.IXlnOptArgs) As String 
Dim file As IXlnFile 
Dim doc As IXlnDOMDocument 
On Error GoTo IXlnServerExtension_Run_Error 
Set file = ipStore.RootDirectory.GetFile("DMS.xml") 
Set doc = file.ContainedObject 
Dim element As IXlnDOMElement 
Set element = doc.documentElement 
id = element.getAttribute("idcount") 
id = id + 1 
element.setAttribute "idcount", "" & id 
IXlnServerExtension_Run = "" & id 
Exit Function 
IXlnServerExtension_Run_Error: 
IXlnServerExtension_Run = "0" 
End Function

Listing 1: In dieser eXcelon Server-Extension-Komponente GenerateID wird ausschließlich die Run-Methode implementiert; alle anderen enthalten keinen Programmcode, sind also "leer". Als Erstes wird das XML-Dokument "DMS.xml" ermittelt und der Wert des idcount-Attributs des Wurzelelements erfragt. Anschließend wird dieses Attribut inkrementiert und der ursprüngliche Wert zurückgegeben. Die Server-Extension greift über die eXceloneigene DOM-Implementierung (s. IXlnDOMDocument) auf XML-Dokumente/-Fragmente zu.

Mithilfe des Explorers wird die Server-Extension unter dem Namen GenerateID mit Angabe der ProgID registriert. Zum Registrierungsfenster gelangt man, wenn man eine Datenbank auswählt und im Kontextmenü des Root-Verzeichnisses Create|Server Extension anklickt.

XML lesen und schreiben: Die clientseitige Programmierschnittstelle

Eine Visual Basic-Anwendung übernimmt das Extrahieren der Inhalte von Office-Dokumenten. Sie verwendet dafür das Client-API von eXcelon DAP. Sämtliche Werkzeuge des eXcelon DAP sind mit diesem API erstellt worden, entweder in Java oder COM. Das Client-API unterscheidet sich vom Server-API dadurch, dass Xpath-, XQL- (XML Query Language) oder XUL-(XML Update Language)-Ausdrücke an den Datenserver gesendet werden. Er nimmt sie entgegen und ermittelt anhand des jeweiligen Abfrageprozessors ein Anfrageergebnis. Dieses Ergebnis wird dann zur Client-Anwendung zurückübertragen. Es sei hier angemerkt, dass immer nur die unbedingt benötigten Teile eines Dokuments in den Arbeitsspeicher geladen werden. Solche Teildokumente bleiben weiter in einem inmemory-Cache, damit spätere ähnliche Anfragen nicht unbedingt einen Datenbankzugriff benötigen.

Der Visual Basic-Client erzeugt einmalig nur eine XML-Datei mit dem Namen DMS.xml. Alle extrahierten Dokumentinhalte werden dann dieser Datei hinzugefügt. Abbildung 2 zeigt einen Ausschnitt dieser Datei mit dem eXcelon-Explorer. Sendet man einen XPath- [11] oder ein XQL-Ausdruck zum Server, so erhält man als Ergebnis ein XML-Dokument, das z.B. ein Auszug eines viel größeren XML-Dokuments sein kann. Folgender Ausdruck ermittelt den Inhalt zwischen den SLIDE-Tags, in denen das Attribut id den Wert 2 hat.

/CONTENTS/PRESENTATION/CONTENT/SLIDE[@id="2"]

Sendet man einen XUL-Ausdruck zum Datenserver, so können Elemente in einem XML-Dokument modifiziert oder neue Elemente hinzugefügt werden. Der Beispielclient (Listing 2) erzeugt einen XUL-String, der die Daten aus einem Office-Dokument enthält. Er sendet ihn zum Datenserver (Listing 4), der die Datei DMS.xml entsprechend erweitert. Zuvor wird jedoch die Server-Extension GenerateID aufgerufen, um die ID zu ermitteln (Listing 3).

Bild02

Abbildung 2: Baumansicht der Datei DMS.xml aus dem Beispielszenario im eXcelon-Explorer. Auf der linken Seite sind alle XML-Stores eines eXcelon-Servers zu sehen.

Private Sub PowerPointToExcelon_Click() 
Dim pptFileName As String 
Dim content As String 
Dim meta As String 
Dim id As String 
On Error GoTo PowerPointToExcelon_Click_Error 
FileDialog.CancelError = True 
FileDialog.Filter = "*.ppt" 
FileDialog.DialogTitle = "Pick Microsoft PowerPoint File" 
FileDialog.Action = 1 ' open 
pptFileName = FileDialog.FileName 
docname = InputBox("Enter a name for the document", "Enter Name") 
If docname = "" Then GoTo PowerPointToExcelon_Click_Error 
DMSForm.Importing.Visible = True 
DMSForm.MousePointer = 11 
id = xlnManager.GenerateID 
meta = "<DMS id=""" & id & """ name=""" & docname & """ type=""ppt""/>" 
content = xlnManager.Powerpoint_To_XML(pptFileName, meta) 
xlnManager.Save_To_Excelon content 
xlnManager.Blob_to_Excelon pptFileName, id & ".ppt" 
UpdateDocList 
DMSForm.Importing.Visible = False 
DMSForm.MousePointer = 1 
Exit Sub 
PowerPointToExcelon_Click_Error: 
DMSForm.Importing.Visible = False 
DMSForm.MousePointer = 1 
End Sub

Listing 2: Diese Methode wird durch eine Menüauswahl in der Clientanwendung aufgerufen. Zuerst wird der Name der PowerPoint-Datei ermittelt, die importiert werden soll. Anschließend werden die Inhalte durch die Methode Powerpoint_To_XML extrahiert und in der Save_To_Excelon-Methode an den Datenserver übertragen.
Die Komponente xlnManager ist nicht Bestandteil von eXcelon, sondern gehört zur Beispielanwendung. Sie kapselt die Kommunikation mit dem XML-Server.

Public Function GenerateID() As String 
On Error GoTo GenerateID_Error 
Dim result As IXlnResult 
Set result = xlnSession.Run(xlnStoreName & ":GenerateID", "") 
GenerateID = result.Data 
Exit Function 
GenerateID_Error: 
GenerateID = 0 
End Function 

Listing 3: Clientseitiger Aufruf der Server-Extension GenerateID (s. Listing 1), um die ID für ein neues Dokument zu ermitteln.

Public Sub Save_To_Excelon(content As String) 
Dim xul As String 
xul = "<update select=""/CONTENTS""><element location=""insert"">" 
xul = xul & content 
xul = xul & "</element></update>" 
xlnSession.Update xlnDMSFileName, xul, "" 
End Sub

Listing 4: Der extrahierte XML-String wird in einen XUL-Ausdruck eingebettet und an den eXcelon-Datenserver übertragen. Der XUL-Ausdruck spezifiziert den Ort einer Veränderung im Zieldokument (hier das Wurzelelement CONTENTS) und die Art einer Veränderung (hier das Einfügen eines Elements).

Zugriff per Webserver

Wie im Szenario beschrieben, wäre es hilfreich, auf einfache Art und Weise webbasierten Zugriff auf XML-Dokumente zu erhalten. Durch die entsprechende Definition von XSLT-Vorschriften kann XML beispielweise in HTML transformiert werden. Der folgende Ausschnitt aus der Datei contents.xsl zeigt eine Transformationsvorschrift, die für jedes PRESENTATION-Element (s. Abbildung 1) im XML-Dokument eine Zeile einer HTML-Tabelle generiert. In den Tabellenfeldern befinden sich Informationen aus Unterelementen, die durch die XPath-Ausdrücke in den value-of-Elementen spezifiziert werden.

<xsl:template match="PRESENTATION"> 
<TR> 
<TD width="5%"><xsl:value-of select="DMS/@id"/></TD> 
<TD width="20%"><xsl:value-of select="DMS/@name"/></TD> 
<TD width="20%"><xsl:value-of select="METADATA/PROPERTY[@name=&apos;Title&apos;]"/></TD> 
<TD width="20%"><xsl:value-of select="METADATA/PROPERTY[@name=&apos;Author&apos;]"/></TD> 
<TD width="20%"> 
 <a href="./{DMS/@id}.{DMS/@type}"><xsl:value-of select="DMS/@type"/></a>,  
<a href="./DMS.xml?exql=/CONTENTS/*[DMS/@id={DMS/@id}]">xml</a> 
  </TD> 
</TR> 
</xsl:template> 

Wenn mehrere solcher XSLT-Templates auf ein XML-Dokument angewendet werden, entsteht Stück für Stück ein HTML-Dokument. Im eXcelon-Datenserver ist ein XSLT-Prozessor integriert, der ebenfalls davon profitiert, dass XML-Dokumente oder Teile davon nicht extra geparst werden müssen, um in HTML transformiert zu werden. Im Lieferumfang des eXcelon DAP sind diverse Webserver-Plug-Ins enthalten, die Anfrageausdrücke per URL entgegennehmen (ähnlich dem Client-API) und an den Datenserver weiterleiten.

Im Beispiel sind zwei XSLT-Definitionen enthalten:

  • contents.xsl - transformiert DMS.xml in eine HTML-Tabelle mit einer Suchmaske.

  • result.xsl - transformiert ein Suchergebnis ebenfalls in eine HTML-Tabelle.

Die Installation des benötigten Plug-Ins für den Microsoft Internet Information Server ist sehr einfach. Man muss nur die Datei xlnisapi.dll aus dem bin-Verzeichnis des Installationsverzeichnisses von eXcelon in das Scripts-Verzeichnis des Webservers kopieren (wenn sie nicht schon automatisch bei der Installation dorthin kopiert wurde).

Eine URL, die direkt das DMS.xml-Dokument in der Datenbank Test_Store abfragt, sieht dann wie folgt aus:
http://localhost/Scripts/xlnisapi.dll/Test_Store/DMS.xml

Soll dieses Dokument serverseitig erst in HTML transformiert werden, so muss die entsprechende Transformationsvorschrift angegeben werden:
http://localhost/Scripts/xlnisapi.dll/Test_Store/DMS.xml?xslsheet=Test_Store:/c ontents.xsl

Wie das HTML-Resultat auf einem Browser aussehen kann, sieht man in Abbildung 3 im Fensterbereich rechts oben.

Hilfreiche Werkzeuge

XSLT-Editor

Ein wichtiger Standard des W3C ist die Extensible Stylesheet Language (XSL) [13]. Die beiden wesentlichen Einsatzgebiete für XSL:

  • Es existiert ein XML-Dokument, man möchte es jedoch in ein anderes Format überführen. Dieses Format kann wieder ein XML-Dokument sein, das z.B. XML-basiertem Electronic Data Interchange (EDI) entspricht, d.h. der DTD eines Zulieferers.

  • Basierend auf einem XML-Dokument soll eine datengetriebene HTML-Seite erzeugt werden, die graphische Repräsentation der betreffenden Daten muss also definiert werden.

Der eXcelon XSLT-Editor Stylus zeigt die Struktur eines ausgewählten XML-Dokuments an (siehe Abbildung 3, oberes linkes Fenster). Wenn man ein Strukturelement anklickt, gelangt man in die Implementierung der Transformation für dieses Element (siehe Abbildung 3, unteres Fenster). Das Ergebnis der Transformation kann sofort kontrolliert werden (siehe Abbildung 3, rechtes Fenster).

Für den Fall, dass eine statische HTML-Seite vorliegt (z.B. von einem HTML-Designer), verfügt Stylus über eine Importfunktion für HTML-Seiten und ein Verfahren namens Visual-Backmapping, das es erlaubt, per Drag & Drop statische Seiten zu dynamisieren.

Bild03

Abbildung 3: Der XSL-Editor Stylus verfügt über zwei Editor-Modi. Hier sehen Sie die dreigeteilte Sicht auf die XML-Struktur links oben, den XSLT-Quellcode-Editor unten und die Vorschau rechts oben.

Der zweite Modus ist ein WYSIWYG-Editor auf der Basis eines MS-Frontpage-Plug-Ins.

XConnects
Ein Haupteinsatzgebiet von XML ist die Integration verschiedenster Datenquellen. Das bedeutet, dass Konvertierungen aus einer Vielfalt von Formaten in ein bestimmtes XML-Format erfolgen müssen - und bei Bedarf auch zurück. Klassischerweise werden für solche Aufgaben mehr oder minder komplexe Perl-Scripts eingesetzt. Mit XConnect erhält man ein grafisches Werkzeug (siehe Abbildung 4), das Konvertierungen von 70 weit verbreiteten Datenformaten in XML und wieder zurück ermöglicht. Auch dafür gibt es eine COM-API zur manuellen Steuerung und die XConnect-Engine, die regelmäßige automatische Konvertierungen vornimmt.

Bild04

Abbildung 4: Der Conversion-Designer als Teil von XConnect. Mit XConnect können XML-Daten aus 70 weit verbreiteten Datenformaten erzeugt werden. Der Designer hilft bei der Definition der Transformation.

Explorer

Der eXcelon-Explorer ist, wie der Name vermuten lässt, ein Browser, mit dem das Dateisystem eines XML-Store (eine eXcelon-Datenbank) bearbeitet werden kann. Mit ihm ist es möglich, per Drag & Drop XML- und Nicht-XML-Dokumente in ein XML-Store einzufügen. Genauso einfach können Dateien verschoben und gelöscht werden.

Über das hinaus, was man auch schon vom Windows-Explorer her kennt, kann man mit ihm auch in XML-Dokumente hinein navigieren, graphisch XPath-Abfragen oder XUL-Anfragen entwerfen und ausführen lassen. Der eXcelon-Explorer ist selbst ein eXcelon-Client und zeigt am besten, was das Client-API zu leisten vermag.

Bei bestimmten XPath-Abfragen kann durch Indizes die Anfragebearbeitung signifikant beschleunigt werden. Dies gilt für Anfragen, die keinen direkten Weg von der Wurzel des DOM-Baums bis zum Knoten oder Blatt beschreiben, z.B.

//DMS/@id

Solche Anfragen auf Mengen oder Anfragen mit Volltext-Suchen profitieren von einem Index-Zugriff bei der Anfrageauswertung. Aus diesem Grund kann man mit dem eXcelon-Explorer über die Menüwahl File|Manage Indexes beliebige Indizes anlegen, die sich auf Tags oder Attribute beziehen können.
Kaum zu optimieren ist dagegen folgende Anfrage:

/CONTENTS/DOCUMENT[1]/DMS/@id

Man kann mit einer nahezu konstanten Antwortzeit rechnen, da sie unabhängig von der Größe des XML-Dokuments ist.

Zu interpretieren ist diese XPath-Anfrage wie folgt: Gehe zum Wurzelknoten CONTENTS, von dort aus zum ersten Kind-Knoten DOCUMENT, von dort direkt zum Kind-Knoten DMS und dort direkt zum Attribut id. Die Möglichkeit, in der Datenbank direkt zu navigieren, vermeidet das Auswerten teurer Joins, wie man sie von relationalen Datenbanken her kennt.

Bild05

Abbildung 5: Übersicht über die Komponenten der eXcelon Dynamic Application Platform. Für eine nähere Erläuterung siehe Kasten 2.

eXcelon Dynamic Application Plattform
Die eXcelon Dynamic Application Platform (DAP) besteht aus mehreren Komponenten, die für die Entwicklung und die Laufzeitunterstützung von Applikationen ausgelegt sind (siehe Abbildung 5). Im Einzelnen sind dies:

  • XML-Datenserver - Ein nativer XML-Datenbankserver mit XPath-, XQL-, XUL- und XSLT- Prozessoren und Server-Side-API
  • XConnects - Ein Werkzeug zur Transformation von 70 Datenquellen in XML
  • Webserver Plug-Ins & Client-APIs, um z.B. Datenbankinhalte per URL abfragen zu können
  • Stylus - Ein graphischer XSLT-Editor (ab Version 2.0 mit WYSIWYG Modus)
  • Explorer - Ein Windows Explorerähnlicher Browser für XML-Datenbanken
  • Studio - Ein Designwerkzeug für XML-Schemata
  • Manager - Benutzer- und Datenbankadministration, Event-Logging und Konfiguration

Kasten 2: Die eXcelon-Komponenten im Überblick.

Fazit

Mit XML steht eine standardisierte Technologie zur Verfügung, mit der sich viele Probleme effizienter lösen lassen als zuvor. Nicht immer reicht es jedoch aus, XML-Daten mit bisherigen Technologien zu verwalten. Dateisystem und RDBMS kommen schnell an ihre Grenzen. Die Lösung für eine effiziente Speicherung und Manipulation auch großer XML-Dokumente liegt dann in speziellen XML-Datenbanken. eXcelon ist ein solches Produkt, das standardbasiert ist, aber gleichermaßen offen für Erweiterungen. Die Unterstützung von DOM, XSLT, XPath/XQL und XUL über COM-Objektmodelle und Web-Server-Schnittstelle machen die Verwaltung von XML bruchlos möglich. eXcelon bietet die Funktionalität und Verlässlichkeit von RDBMS für die Verwaltung großer XML-Datenbestände.

Ressourcen

[1] Charles F. Goldfarb, Paul Prescod: The XML Handbook - Second Edition; Prentice Hall 2000
[2] Ralf Westphal: Revolution auf leisen Sohlen: XML; BasicPro 1/98 (WildSite), S. 3
[3] Chris Lovett: Inside MSXML Performance; MSDN Online,
http://msdn.microsoft.com/xml/articles/xml02212000.asp
[4] Ralf Westphal: SQL XML Technology Preview; BasicPro 1/00, S. 59
[5] Stephen Mohr et al.: Professional XML; Wrox Press 2000
[6] http://www.w3.org/TR/REC-DOM-Level-1/ DOM Level 1 - Recommendation
[7] http://www.w3.org/TR/DOM-Level-2/ DOM Level 2 - Candidate Recommendation
[8] Ralf Westphal: COM-Interface Casting; BasicPro 6/99, S. 60
[9] http://exceloncorp.com Informationen über eXcelon DAP
[10] http://www.megginson.com/SAX/index.html SAX 1.0: The Simple API for XML
[11] http://www.w3.org/TR/xpath XML Path Language (XPath) - Recommendation
[12] http://www.w3.org/TR/xslt XSL Transformation (XSLT) - Recommendation
[13] http://www.w3.org/TR/xsl/ Extensible Stylesheet Language (XSL) - Working Draft
[14] William J. Brown et al.: Anti Patterns - Refactoring Software, Architectures, and Projects in Crisis; Wiley 1998

Für Fragen und Anregungen erreichen Sie Mischa Schmierer per EMail an Mischa.Schmierer@exceloncorp.com.

Schnellstart
Schritt 1: eXcelon-Installation
Auf der Heft-CD befindet sich eine Evaluationsversion der eXcelon DAP 2.0. Der MS Internet Information Server oder der PWS sollten ebenfalls installiert sein, wie auch MS Word, MS PowerPoint und MS Excel in einer neueren Version.

Schritt 2: Demo-Installation
Kopieren Sie das Verzeichnis des Beispiels auf ein lokales Laufwerk. Legen Sie dann mit dem eXcelon-Explorer eine XML-Datenbank mit dem Namen Test_Store an. Registrieren Sie die GenerateID-Server-Extension mit dem Kommando regsvr32 GenIDPrj.dll in der Registry und anschließend auch in der Datenbank. Ziehen Sie per Drag & Drop die Dateien contents.xsl und result.xsl in die Datenbank.

Schritt 3: Beispiel anwenden
Mit der Visual Basic-Anwendung DMS.exe können Sie Office-Dokumente in die Datenbank Test_Store einspielen. Befindet sich das xlnisapi.dll im Scripts-Verzeichnis des Webservers, können Sie per URL auf das Web-Frontend zugreifen.


Microsoft führt eine Onlineumfrage durch, um Ihre Meinung zur MSDN-Website zu erfahren. Wenn Sie sich zur Teilnahme entscheiden, wird Ihnen die Onlineumfrage angezeigt, sobald Sie die MSDN-Website verlassen.

Möchten Sie an der Umfrage teilnehmen?
Anzeigen:
© 2015 Microsoft