Fakultät für Informatik. Professur Verteilte und Selbstorganisierende Rechnersysteme. Bachelorarbeit

Transkript

1 Fakultät für Informatik Professur Verteilte und Selbstorganisierende Rechnersysteme Bachelorarbeit Erweiterung der XML-Listen-Verwaltungsfunktionalität des WebComposition/Data Grid Service Tobias Zanke Chemnitz, den 15. Juli 2013 Prüfer: Betreuer: Prof. Dr.-Ing. Martin Gaedke Dipl.-Inf. Olexiy Chudnovskyy

2

3 Tobias Zanke, Erweiterung der XML-Listen-Verwaltungsfunktionalität des WebComposition/Data Grid Service Bachelorarbeit, Fakultät für Informatik Technische Universität Chemnitz, 15. Juli 2013

4

5 Aufgabenstellung Zur Unterstützung von Rapid Prototyping sowie der späteren Evolution von Software wurde der WebComposition/Data Grid Service (DGS) geschaffen. Dabei handelt es sich um eine Web-basierte Speicher- und Gatewaylösung die sich per REST/HTTP- Schnittstelle universell ansprechen lässt. Die Speicherung der Daten erfolgt basierend auf dem Modell der XML Listen. Die XML-Verwaltungsfunktionen vom DGS sind im Moment eingeschränkt. Z.B. wird Indexierung, Filterung, Sortierung oder Pagination der Daten nicht unterstützt. Eine Integration dieser Funktionalitäten in den DGS würde dessen Anbindung und spätere Verwendung effizienter gestalten. Die Arbeit soll existierende Lösungen zum effizienten Umgang mit XML Dokumenten, insbesondere, mit XML-Listen untersuchen. Anhand der erarbeiteten Kriterien sollen die Ansätze verglichen und der geeignetste anschließend in den WebComposition/Data Grid Service integriert werden. i

6

7 Inhaltsverzeichnis Abbildungsverzeichnis Tabellenverzeichnis Algorithmenverzeichnis Abkürzungsverzeichnis v vii ix xi 1 Einleitung Motivation Problemstellung Zielsetzung Struktur und Rahmen der Arbeit Stand der Technik Anforderungen XML spezifische Anforderungen Sonstige Anforderungen Analyse der Datenbanken Native XML Datenbanken Relationale Datenbanken Ergebnisse der Analyse Bewertung Zusammenfassung zum Stand der Technik Konzept 29 4 Realisierung Anbindung BaseX Datenstruktur Anlegen einer neuen DSE DataStorage für BaseX XmlList DataStorage Schema DataStorage InformationStore DataStorage MetaStore DataStorage Funktionsfähige NativeXmlDSE Optimierungen und Erweiterungen mittels XQuery Vermeidung von Datenbankabbildern iii

8 4.5.2 Validation XSLT URL Templates / UriPatternHandler QueryHandler Zusammenfassung Evaluation Bewertung der Umsetzung Indexierung XQuery XQuery and XPath Full Text XQuery Update Facility XPath Validation XSL Transformation Binärdaten Daten Import Webschnittstelle / Administrationsinterface Zusammenfassung Vergleich XmlDSE mit NativeXmlDSE Grenzen der Einsatzmöglichkeit Zusammenfassung Zusammenfassung und Ausblick 65 Literaturverzeichnis 67 Anhang A Messwerte XmlDSE und NativeXmlDSE 75 iv

9 Abbildungsverzeichnis Abbildung 3.1: Interne Struktur einer DSE des DGS Abbildung 4.1: DGS Datenstruktur in BaseX Abbildung 5.1: Vergleich der Elementsuche bei XmlDSE und NativeXmlDSE Abbildung 5.2: Vergleich XmlDSE und NativeXmlDSE bei hoher Anzahl Datensätze Abbildung 5.3: Vergleich XmlDSE mit NativeXmlDSE bei großen Datenmengen v

10

11 Tabellenverzeichnis Tabelle 2.1: XML Funktionen relationaler Datenbanken Tabelle 2.2: native XML Datenbanken im Vergleich Tabelle 2.3: Bewertung nach Anforderungen Tabelle 5.1: Bewertung der einzelnen Anforderungen vii

12

13 Algorithmenverzeichnis Listing 4.1: Initialisierung einer Datenbankverbindung zu BaseX Listing 4.2: Zugriff auf das <lists> Element mit allen DGS Listen Listing 4.3: XQuery zum Erstellen einer neuen Liste für den DGS Listing 4.4: Löschen einer DGS Liste samt aller zugehörigen Daten Listing 4.5: XQuery zur Aktualisierung des Schemas einer Liste Listing 4.6: Entfernen der XML-Deklaration in C# Listing 4.7: XQuery Namespacedeklaration Listing 4.8: XPath Auswertung auf Inline XML Listing 4.9: Lesen eines Listenelements mit vorgegebener Primärschlüsselposition Listing 4.10: Test unter Verwendung der XML Diff Bibliothek Listing 4.11: Schnittstellen zur Abfrage separater Listenbestandteile Listing 4.12: Neue Datastore Interfaces zur XML-Validation Listing 4.13: XQuery zur Validation einer DGS Liste gegen das hinterlegte Schema Listing 4.14: Anpassung des XQuery zur Elementvalidation Listing 4.15: Interface zur XSL Transformation einer DGS Liste Listing 4.16: XQuery zur XSL Transformation einer DGS Liste durch die NativeXmlDSE Listing 4.17: Ein durch die XmlDSE unterstütztes Template Listing 4.18: Neue InformationStore Methoden zur XPath Auswertung in BaseX Listing 4.19: Zwei neu erstellte DataStorage Interfaces zur XPath Auswertung Listing 4.20: XPath Read Methode des erweiterten DataStorage Listing 4.21: XQuery Update von per XPath ermittelten Listenelementen Listing 4.22: Query-Template für den QueryHandler der NativeXmlDSE Listing 4.23: Interface zur Ausführung von XQuerys über die NativeXmlDSE Listing 5.1: automatisch generierter Testdatensatz Listing 5.2: QueryHandler Template zur Pagination Listing 5.3: Volltextsuche mittels UriPatternHandler und Wildcards Listing 5.4: XQuery Befehle zum Importieren von externen Daten in BaseX ix

14

15 Abkürzungsverzeichnis API BLOB BSD BST CDATA CSV DGS DSA DSE DTD FLWOR GUI HTML HTTP JSON L-GPL NoSQL PDF REST SQL TCP TXT UIX URI URL Application Programming Interface Binary Large Object Berkeley Software Distribution Binary Search Tree Character Data Comma-Separated Values Data Grid Service Distributed System and Architecture Data Space Engine Document Type Definition Acronym für: FOR, LET, WHERE, ORDER BY, RETURN Graphical User Interface Hypertext Markup Language Hypertext Transfer Protocol JavaScript Object Notation GNU Lesser General Public License Not only SQL Portable Document Format Representational State Transfer Structured Query Language Transmission Control Protocol Text User Interface Experience Uniform Resource Identifier Uniform Resource Locator xi

16 XHTML XML XPath XSD XSL XSLT Extensible HyperText Markup Language Extensible Markup Language XML Path Language XML Schema Definition Extensible Stylesheet Language XSL Transformations xii

17 1 Einleitung 1 Einleitung 1.1 Motivation In den Anfängen des Internets war die zur Verfügung stehende Bandbreite für normale Haushalte sehr gering. Die vom Nutzer verwendeten Anwendungen wurden daher über Datenträger lokal auf dem Computer installiert. In den letzten 10 Jahren wurden durch die technischen Fortschritte aber immer höhere Bandbreiten erzielt, die auch dem privaten Anwender zu erschwinglichen Preisen zur Verfügung gestellt werden können. Mit dieser Entwicklung wurde es immer einfacher, Anwendungen direkt als Download zur Verfügung zu stellen. Eine daraus resultierende Entwicklung besteht darin, die Software direkt als Online- Anwendung anzubieten. Installierte man sich vor 10 Jahren noch eine lokale Enzyklopädie, so verwendet man heute beispielsweise Wikipedia. Diese Entwicklung stellt höhere Anforderungen an das Webengineering. Es müssen Vorgehensweisen gefunden werden, die eine effektive Entwicklung solcher Anwendung ermöglichen. Dabei sind Prototyping- und Entwicklungsphase sowie die spätere Evolution der Software zu beachten. Im Idealfall sollten die Verfahren und Werkzeuge für die Entwicklung einen unkomplizierten Übergang zwischen verschiedenen Lebenszyklusphasen ermöglichen. Um dieses Ziel zu erreichen, wurde bereits 1997 auf der 6. WWW Konferenz von Gaedke et al. die WebComposition [1] vorgestellt. Es handelt sich dabei um ein objektorientiertes Supportsystem für den Webengineering-Lebenszyklus. Eine Webanwendung wird dabei in ihre wesentlichen Komponenten zerlegt: Content-perspective (Daten- und Semantik-Aspekte) UIX-perspective (Nutzerschnittstellen-Aspekte) DSA-perspective (Verteiltheit und Architektur) Da verschiedene Phasen einer Softwareentwicklung unterschiedliche Anforderungen an die einzelnen Teilbereiche stellen, wird bei einer WebComposition eine Zwischenschicht 1

18 1 Einleitung zur Verfügung gestellt. Diese ermöglicht den Austausch der jeweiligen Komponenten, ohne dass die Anwendung selbst speziell angepasst werden muss. Als erstes Element der WebComposition wurde der Data Grid Service (DGS) geschaffen. Für den Bereich der Content-Perspective stellt er der Anwendung eine einheitliche Datenspeicherschnittstelle zur Verfügung. Um dem Entwickler größtmöglichen Freiraum beim Entwurf seiner Anwendung zur Verfügung zu stellen und um ebenso mit heterogenen Daten umgehen zu können, werden die Daten auf dem Modell von XML Listen verwaltet. Zusätzliche Metadaten können ebenso per XML (RDF) abgelegt werden. Da es sich beim DGS nur um eine Zwischenschicht handelt, werden die Daten nicht vom DGS selbst abgespeichert, sondern an eine dafür vorgesehene Datenspeicherkomponente weitergegeben. Dies ermöglicht während der Prototypingphase eine Speicherung der XML Listen ins Dateisystem. Sollten sich dann folgende Änderungen der Anforderungen ergeben, beispielsweise durch steigende Komplexität oder höhere Anzahl Nutzer, kann die Speicherlösung am DGS ohne Änderungen in der Kernanwendung ausgetauscht werden. Auf diese Weise kann das Dateisystem durch die Speicherung in eine relationale Datenbank ersetzt werden. Die DGS Schnittstelle auf Seite der Anwendung erfolgt in allen Fällen einheitlich über XML Listen. Zum Datenaustausch mit einer Anwendung dient dem DGS hierzu eine HTTP/REST Schnittstelle. Da beim Wechsel einer Speicherkomponente, in den meisten Fällen, die Daten nicht verloren gehen dürfen, müssen diese von der alten Speicherlösung in die neue Speicherlösung migriert werden. Durch den modularen Aufbau des DGS können hierzu Migrationsmodule erstellt werden, die diese Aufgabe übernehmen. Eines dieser Module wurde bereits zur Migration zu einer CouchDB Datenbank entwickelt [2]. 1.2 Problemstellung Durch die Verarbeitung der Daten auf Basis der XML-Listen ist es aus Performancegründen naheliegend, die Daten direkt im XML-Format abzuspeichern. Die meisten Datenbanken bieten hierzu mindestens die Möglichkeit der Speicherung in BLOB- oder Text-Datentypen. Um die Daten anschließend wieder lesen zu können, werden Funktionen wie Indexierung, Filterung oder auch Sortierung benötigt. Genutzt werden diese Funktionen beispielsweise dazu, dem Nutzer eine Übersicht seiner nach bestimmten Kriterien sortierten Daten auszugeben. Um die Übersichtlichkeit zu erhalten wird zudem mittels Pagination die Ergebnismenge auf mehrere blätterbare Seiten 2

19 1 Einleitung aufgeteilt. Da diese Funktionen aber mit BLOB- oder Text-Datentypen nicht zu realisieren sind, bleibt lediglich die Möglichkeit diese in den DGS zu verlagern, um die benötigten Funktionen trotzdem anbieten zu können. Dazu müssen die Daten unverarbeitet von der Speicherlösung an den DGS übergeben werden. Im Falle von Filterung oder Sortierung müssen alle Datensätze an den DGS übermittelt und anschließend dort gefiltert oder sortiert werden. Die Anbindung zur Speicherlösung wird dabei unnötig belastet. Und auch der DGS muss mit entsprechender Hardware ausgestattet sein, um die kompletten Datensätze für die Filterung zwischenzuspeichern. Während der Prototypingphase oder auch bei kleinen Anwendungen stellt dieses Vorgehen meist keine Einschränkung dar und der Vorteil der einfachen Einrichtung überwiegt. Mit steigenden Performanceanforderungen oder steigenden Datenmengen ist ein solcher Aufbau allerdings nicht mehr ohne weiteres möglich. 1.3 Zielsetzung Um dieses Problem zu vermeiden, ist es notwendig Datenbanken zu finden, welche den Umgang mit XML Daten beherrschen. Und zwar so, dass essentielle Funktionen wie die Indexierung, Filterung und Sortierung bereits von der Datenbank unterstützt werden. Ziel dieser Arbeit soll es daher sein, verschiedene Datenbankkonzepte und ihre Implementierungen auf ihre XML Verwaltungsfähigkeiten zu analysieren. Im Fokus sollen dabei auch sogenannte native XML Datenbanken aus dem Bereich der NoSQL Datenbanken stehen. Für die Datenbank, die den Anforderungen des DGS am besten entspricht, soll anschließend ein Modul implementiert werden, das die Datenbank als weitere Speicherlösung am DGS für Anwendungen nutzbar macht. 1.4 Struktur und Rahmen der Arbeit Diese Arbeit setzt sich im Weiteren zuerst mit der Analyse des Stands der Technik in Kapitel 2 auseinander. Hierzu werden verschiedene Anforderungen vorgestellt, anhand dessen die verschiedenen Speicherlösungen miteinander verglichen werden. Nach Bewertung der verschiedenen Anforderungen soll somit eine für den DGS am besten geeignete Speicherlösung ausgewählt werden. Anschließend wird in Kapitel 3 ein Konzept zur Einbindung dieser Speicherlösung in den DGS entwickelt. Dazu wird festgelegt, welche Funktionen von der Speicherlösung 3

20 1 Einleitung übernommen werden sollen und welche Erweiterungen der DGS Funktionalität unter Verwendung dieser Speicherkomponente umgesetzt werden können. Kapitel 4 stellt die Implementation der Anbindung der Speicherlösung an den DGS vor und wird von der Evaluation des Konzepts in Kapitel 5 gefolgt. Zur Evaluation soll bewertet werden, in wie fern sich aus der neuen Speicherlösung Vorteile gegenüber bisherigen Lösungen ergeben haben. Weiter sollen aufgetretene Probleme und Grenzen der Lösung aufgezeigt werden. Einen Rückblick und mögliche Verbesserungsansätze gibt letztlich Kapitel 6. 4

21 2 Stand der Technik 2 Stand der Technik 2.1 Anforderungen Das folgende Kapitel behandelt die Anforderungen an die neue Speicherlösung. Diese wurden zur besseren Übersichtlichkeit in zwei Kategorien aufgeteilt, XML spezifische und sonstige Anforderungen XML spezifische Anforderungen Indexierung Um große Datenmengen effizient auslesen zu können, ist es notwendig, einen Index über bestimmte Bereiche des Dokuments zu erstellen. Bei relationalen Datenbanken können dazu entsprechende Spalten zur Indexierung ausgewählt werden. Bei XML Datenbanken muss die Datenbank hingegen in der Lage sein, dass XML Dokument anhand der Inhalte, Elemente und Attribute zu indexieren. Da die DGS Funktionalität unter anderem um Filterung und Sortierung der Daten erweitert werden soll, ist die Unterstützung von Indexierung durch die Datenbank ein wesentliches Kriterium. XQuery Bei XQuery handelt es sich um eine Sprache zur Extraktion und Veränderung von Daten aus XML Dokumenten oder Datenbanken, vergleichbar zu SQL bei relationalen Datenbanken. XQuery wurde von der XML Query Working Group des W3C entwickelt und ist seit 2007 als Standard in Version 1.0 [3] verfügbar. Im Jahr 2010 folgte die Recommendation für Version 1.0 (Second Edition) [4]. Aktuell in der Entwicklung befindet sich Version 3.0 [5] des XQuery Standards. Wichtige Funktion des XQuery Standards sind die sogenannten FLWOR Ausdrücke. FLWOR steht für FOR, LET, WHERE, ORDER BY, RETURN und bildet damit eine 5

22 2 Stand der Technik Analogie zum SELECT, FROM, WHERE in SQL und ist für die Verarbeitung der DGS Daten mit der neuen Speicherlösung essentiell. XQuery and XPath Full Text 1.0 XQuery and XPath Full Text wurde 2011 als Version 1.0 finalisiert und dient der Erweiterung von XQuery 1.0 (Second Edition) [4] sowie XPath 2.0 (Second Edition) [6] um eine Volltextsuche [7]. XQuery Update Facility 1.0 Um Daten nicht nur aus XML Dokumenten und Datenbanken zu lesen, sondern auch Daten zu verändern, hinzuzufügen oder zu löschen, wurde mit der XQuery Update Facility 1.0 [8] im Jahr 2011 vom W3C ein Standard zur Datenmanipulation mittels XQuery geschaffen. XPath XPath dient der Adressierung von Teilen eines XML Dokuments. Erstmals 1999 [9] vom W3C standardisiert, liegt seit 2007 XPath 2.0 [10] als Recommendation vor. Nochmals überarbeitet als XPath 2.0 (Second Edition) [6], stellt dieser Standard seit 2010 die aktuellste Fassung von XPath dar. Im Januar 2013 erschien eine Candidate Recommendation für XPath 3.0 [11]. Validation Zur Validation von XML Dokumenten sind die Document Type Definition (DTD) und auch die XML Schema Definition (XSD) [12][13] geeignet. Mit der DTD oder dem XSD können Struktur und Datentypen des XML Dokuments vorgeschrieben bzw. gegen ein Schema validiert werden [14]. Somit kann sichergestellt werden, dass die mittels DGS gespeicherten Daten während den Änderungsoperationen immer in einem konsistenten Zustand bleiben. 6

23 2 Stand der Technik XSL Transformation XSL Transformation (XSLT) ist eine Sprache zur Umwandlung von XML Dokumenten hin zu einem neuen XML Dokument. Erstmals 1999 standardisiert [15], ist der aktuellste Standard Version 2.0 aus dem Jahr 2007 [16] Sonstige Anforderungen Binärdaten Neben der Speicherung von XML Daten ist es oft notwendig, zusätzliche Daten in einer Datenbank ablegen zu können. Da diese Daten nicht grundsätzlich als XML vorliegen, sollte die Datenbank ebenso mit nicht XML strukturierten Daten umgehen können und eine Möglichkeit bieten, diese als Binärdaten in der Datenbank zu hinterlegen. Da eine Vielzahl von Datenformaten aus einer XML Datenstruktur bestehen, sollte die Speicherlösung diese bestenfalls erkennen und über XML Funktionen zugreifbar machen. Daten Import Da XML Daten oft in Form von Dateien vorliegen, ist ein Import dieser während der Inbetriebnahme nötig. Auch zur späteren Datenerweiterung ist ein Datenimport aus bestehenden XML Dokumenten nützlich. Die Speicherlösung sollte daher entsprechende Möglichkeiten zum Import von existierenden Datenbeständen bieten. Webschnittstelle / Administrationsinterface Zur Administration der Datenbank sollte ein Interface existieren, mit dessen Hilfe die Daten direkt eingesehen und grundlegende Bearbeitungsmöglichkeiten zu den Datenmengen realisiert werden können. Da es sich beim DGS um eine Schnittstelle auf HTTP-Basis handelt, wäre es vorteilhaft, wenn die Speicherlösung ebenso eine Webschnittstelle bietet. 7

24 2 Stand der Technik 2.2 Analyse der Datenbanken In diesem Abschnitt werden verschiedene Datenbanken auf die erarbeiteten Anforderungen hin analysiert. Durch die Verwendung von XML bietet sich die Analyse von nativen XML Datenbanken an. Weiter werden aber auch die Möglichkeiten relationaler Datenbanken untersucht Native XML Datenbanken MarkLogic Server Der MarkLogic Server wird unter einer kommerziellen Lizenz von der Firma MarkLogic angeboten. Für Entwickler bietet MarkLogic eine kostenfreie Developer License. Im Umfeld von Forschung und Lehre kann ebenso eine kostenfreie Lizenz angefordert werden [17]. Aktuell liegt der MarkLogic Server in Version 6 vor. Indexierung Der MarkLogic Server bietet als native XML Datenbank die Möglichkeit XML Elemente sowie auch deren Attribute mit einem Index zu versehen, um einen schnellen Datenzugriff auf bestimmte Datensätze oder Datenbereich zu ermöglichen [18]. XQuery Um von Indices Gebrauch zu machen, bietet der MarkLogic Server die Abfragesprache XQuery an. Diese wird entsprechend dem W3C Standard XQuery 1.0 unterstützt [19]. Mit XQuery ermöglicht der MarkLogic Server somit Abfragen über die FLWOR Syntax. Sortierung, Filterung und Pagination auf XML Daten sind damit möglich. XQuery and XPath Full Text 1.0 Der MarkLogic Server bietet dem Entwickler weiterhin die Unterstützung für eine Volltextsuche für XML Daten. Da keine Angaben zum verwendeten Standard vom Hersteller gefunden werden konnten, wird davon ausgegangen, dass es sich bei der unterstützten Volltextsuche um ein proprietäres Verfahren handelt [20]. 8

25 2 Stand der Technik XQuery Update Facility 1.0 Die obligatorische Möglichkeit, in der Datenbank gespeicherte Daten auch zu verändern, wird über eine Update Funktionalität ermöglicht. Eine Angabe eines W3C Standards konnte nicht ermittelt werden. Die Update Funktionalität wird proprietär vom Hersteller umgesetzt. XPath Als Teil des XQuery 1.0 Standards ist der MarkLogic Server ebenso mit XPath in Version 2.0 ausgestattet [21]. Validation Zur Validation eines Dokuments ist es möglich, mit dem MarkLogic Server gegen ein gegebenes XML Schema zu validieren [22]. XSL Transformation Zur Transformation von XML Daten existiert der W3C Standard XSL Transformation. Dieser wird durch den MarkLogic Server in zwei Versionen unterstützt. So wird der ältere Standard XSLT 1.0 sowie auch der aktuell letzte finale Standard XSLT 2.0 dem Entwickler zur Verfügung gestellt [23]. Binärdaten Neben der Speicherung von XML Daten unterstützt der MarkLogic Server ebenso die Speicherung von binären Daten [24]. Neben der reinen Dateispeicherung existiert zusätzlich die Möglichkeit, Daten zwischen dem JSON und dem XML Format in das jeweils andere Format umzuwandeln [25]. Weitere unterstütze Formate sind Adobe PDF, Microsoft Office Dokumente und HTML [26]. Alle genannten Formate können zur Speicherung in XHTML umgewandelt werden und sind damit für die Datenbank entsprechend ihrer XML Funktionen durchsuch- und editierbar. Für nicht unterstützte Formate bietet der MarkLogic Server die Möglichkeit der Metadatenextraktion. Die aus den Binärdaten ermittelten Metadaten werden in XML abgespeichert und sind anschließend als XML Daten abrufbar. 9

26 2 Stand der Technik Daten Import Zur Betrachtung und Bearbeitung von gespeicherten XML Daten bietet der MarkLogic Server eine WebDav Schnittstelle [27], über die XML Dokumente von verschiedensten anderen System mit WebDav-Unterstützung gelesen und bearbeitet werden können. Zusätzlich kann über WebDav ein Import von XML Daten erfolgen. Webschnittstelle / Administrationsinterface Zur Administration und Konfiguration sowie Datenverwaltung stellt der MarkLogic Server ein Webinterface für Administratoren und Entwickler zur Verfügung [28]. BaseX Die zweite in dieser Arbeit betrachtete native XML Datenbank ist BaseX. Diese wird seit dem Jahr 2005 von der Universität Konstanz [29] als Open Source Software entwickelt. Dazu steht sie unter der BSD Lizenz [30]. Um BaseX auch für den kommerziellen Sektor interessant zu machen, wurde 2012 die BaseX GmbH gegründet. Über diese Firma wird für BaseX ein kommerzieller Support angeboten [29]. Sofern nicht anders angegeben, sind die Spezifikationen zur aktuellen Version 7.6 der Dokumentation [31] entnommen. Indexierung BaseX bietet eine Vielzahl von Indexierungsmöglichkeiten. So werden strukturelle Indices für Element- und Attributnamen sowie ein Path Index unterstützt. Diese strukturellen Indices sind nicht abschaltbar in BaseX integriert. Optional können diese durch Valueindices erweitert werden. Zu diesen zählen Text-, Attribut- und Full-Text Indices. Keiner der Indices wird standardmäßig aktuell gehalten. Es obliegt dem Entwickler nach Update-Anweisungen die Datenbankindices zu aktualisieren. Für Text- und Attributvalueindices kann alternativ die UPDINDEX Option eingeschalten werden. Diese sorgt dafür, dass diese Indices automatisch aktuell gehalten werden [31]. 10

27 2 Stand der Technik XQuery BaseX unterstützt den XQuery Standard in der aktuellsten finalen Fassung XQuery 1.0. Zusätzlich bietet BaseX Entwicklern bereits die Möglichkeit, mit dem noch unfertigen XQuery 3.0 Standard zu arbeiten. Die aktuell unterstützte Version ist die XQuery 3.0 Candidate Recommendation vom Januar XQuery and XPath Full Text 1.0 Nach Angaben des BaseX Teams war BaseX der erste Query Prozessor der den XQuery and XPath Full Text 1.0 Standard vollständig unterstützte. In der Dokumentation findet sich allerdings die Einschränkung, dass die im Standard vorhandene ignoreoption nicht von BaseX ermöglicht wird. Nichts desto trotz ist die Unterstützung dieses Standards gegeben und für den DGS geeignet. XQuery Update Facility 1.0 Um Daten in die Datenbank einzubringen oder zu bearbeiten, ermöglicht BaseX die Nutzung des erst zwei Jahre alten XQuery Update Facility 1.0 Standards [32]. XPath Im Zusammenspiel mit dem bereits unterstützten XQuery 3.0 Standard kann BaseX ebenso mit dem noch unfertigen XPath 3.0 Standard umgehen. Validation Um XML Daten auf Korrektheit zu prüfen, liefert BaseX die Unterstützung für die Document Type Definition mit. Ebenso kann auch eine Validation gegen ein XML Schema erfolgen. Beide Möglichkeiten werden standardmäßig über den Java Validator ausgeführt. Wenn gewünscht, kann diese Aufgabe auch vom Saxon XSLT Processor übernommen werden. 11

28 2 Stand der Technik XSL Transformation Zur Transformation von XML Daten kann in BaseX der W3C Standard XSLT 1.0 angewendet werden. Wenn notwendig kann der Funktionsumfang auf Basis des XSLT 2.0 Standards erweitert werden. Dazu wird allerdings der Saxon XSLT Processor benötigt. Binärdaten Das BaseX Entwicklerteam will sich vorrangig auf die Speicherung hierarchischer XML Strukturen fokussieren. Aus diesem Grunde bietet BaseX nur eine einfache Speicherung von Binärdaten an. Die Binärdaten werden dazu von BaseX lediglich in einem, unterhalb der Datenbank erzeugtem, Order namens raw abgelegt und sind anschließend über ihren Dateinamen über die BaseX APIs abrufbar. Daten Import Zum Import von bestehenden XML Daten bietet BaseX ein sogenanntes Fetch Modul an. Mit diesem können XML Daten aus dem Speicher oder über http abgerufen und abgespeichert werden. Um die Daten nicht nur zu importieren, sondern auch zu lesen und zu verändern, wird eine WebDav Schnittstelle angeboten. Die Datentypen JSON, CSV, HTML oder TXT können zudem von BaseX beim Import in eine entsprechendes XML Dokument umgewandelt werden. Webschnittstelle / Administrationsinterface Über eine Webschnittstelle verfügt BaseX nicht. Zur Administration und zum Datenmanagement wird stattdessen eine Java-Anwendung verwendet. 12

29 2 Stand der Technik exist Als dritte native XML Datenbank wird exist 2.0 untersucht. exist wird seit 2001 entwickelt und steht als Open Source unter der L-GPL Lizenz zur Verfügung [33]. Indexierung Zur Indexierung von XML Daten werden von exist mehrere Indexierungsoptionen angeboten. So unterstützt exist u.a. einen strukturellen Index, welcher Elemente, Attribute und die Knotenstruktur indexieren kann. Zusätzlich können ein Bereichsindex angelegt oder die Vorteile eines NGram Indexes ausgeschöpft werden [34]. XQuery exist unterstützt gleichermaßen wie BaseX den XQuery 3.0 Standard in der derzeitig unfertigen Vorversion [35]. Davon ausgenommen sind im Moment beispielsweise noch XQuery 3.0 Funktionen, wie Sliding Window oder die Möglichkeit mit dem Count Ausdruck zu arbeiten [36]. XQuery and XPath Full Text 1.0 Der W3C Standard zur Volltextsuche wird von exist derzeit nicht unterstützt. Als Alternative dient gegenwärtig ein auf Apache Lucene basiertes exist Modul. Auf diesem soll zukünftig eine Unterstützung für den W3C Standard aufgebaut werden [37]. XQuery Update Facility 1.0 Die von exist eingesetzte Updatefunktionalität zur Änderung von Daten existiert bereits länger als der entsprechende W3X XQuery Update Facility 1.0 Standard. Die exist Update Funktionen bauen daher nicht auf dem W3C Standard auf [38]. XPath XPath wird entsprechend des XQuery 1.0 Standard von exist in Version 2.0 unterstützt [39]. 13

30 2 Stand der Technik Validation XML innerhalb der exist Datenbank kann mittels der Document Type Definition überprüft oder gegen ein definiertes XML Schema validiert werden [40]. XSL Transformation Zur Transformation von XML Daten wird von exist die Xalan XSLT Engine verwendet. Mit dieser ist es möglich XML Daten mit dem XSLT 1.0 Standard umzuwandeln. Für Entwickler, die eine XSL Transformation nach Standard 2.0 ausführen wollen, ist es nötig, exist um den Saxon XSLT Processor zu erweitern [41]. Binärdaten Auch exist ermöglicht, wie alle bisherigen Datenbanken, die Speicherung von Daten in Binärform [42]. Zudem ist es exist möglich, bestimmte Datentypen nicht als Binärdaten, sondern nach einem Import direkt als XML zu speichern. Näheres wird in der nachfolgenden Anforderung beschrieben. Daten Import Um Binärdaten nicht nur zu speichern, sondern auch zu indexieren, Teile auszulesen oder zu editieren, bietet exist die Möglichkeit, Binärdaten in das XML Format zu wandeln. Umgesetzt wird diese Umwandlung mit dem Tika Toolkit der Apache Software Foundation [43]. Apache Tika bewerkstelligt die Umwandlung verschiedenster Datentypen, darunter HTML, Microsoft Office, PDF, verschiedene Multimediaformate sowie Pack- und Kompressionsformate [44]. Webschnittstelle / Administrationsinterface Wie BaseX bietet exist ebenfalls nur einen Java Client zur Administration der Datenbank an [45]. 14

31 2 Stand der Technik Sedna Eine weitere Open Source Datenbank ist Sedna. Sie steht unter der Apache License 2.0 zur Verfügung [46]. Die aktuelle Version von Sedna ist die 3.5 aus dem Jahr Indexierung Sedna unterstützt die Indexierung verschiedener Datentypen über B+ Bäume. Für spezielle Anwendungsfälle steht auch eine experimentelle Umsetzung mittels Block String Trie (BST) zur Verfügung [47]. XQuery XQuery wird von Sedna in Version 1.0 aus dem Jahr 2007 (First Editon) bis auf einige wenige Funktionen unterstützt [48]. XQuery and XPath Full Text 1.0 Eine Volltextsuche wird durch Sedna grundsätzlich ermöglicht, aber der dafür vorgesehene W3C Standard wird von Sedna dabei aber nicht entsprechend umgesetzt [47]. XQuery Update Facility 1.0 Sedna gibt keine Unterstützung für XQuery Update nach W3C Standard an [49]. Die Umsetzung der Update Funktionalität basiert aber auf Basis der Arbeit von Patric Lehti [50]. XPath Sedna macht keine genauen Angaben zum XPath Standard. Durch den XQuery 1.0 Standard wird XPath 2.0 allerdings vorausgesetzt [3]. Validation Weder Document Type Definition noch eine Validierung gegen ein XML Schema werden aktuell unterstützt. 15

32 2 Stand der Technik XSL Transformation Wie bei XPath wird die Unterstützung von XSLT 2.0 durch den XQuery 1.0 Standard impliziert. Binärdaten Sedna bietet keine direkte Speicherung von Binärdaten an. Um Binärdaten mittels Sedna zu speichern, müssen diese vorher beispielsweise mit Base64 kodiert bzw. mittels CDATA in ein XML Dokument integriert werden. Daten Import Mit einem Bulk Load bietet Sedna die Möglichkeit Daten zu importieren. Eine WebDav Schnittstelle wird nicht zur Verfügung gestellt. Die Kompatibilität des Importers erstreckt sich dabei lediglich auf XML Daten sowie CDATA [51]. Webschnittstelle / Administrationsinterface Eine Webschnittstelle oder ein Administrationsinterface fehlt. Allerdings gibt es ein Open Source Projekt für ein Sedna Plugin namens SednaAdmin, welches versucht diese Funktionen nachzurüsten [52]. 16

33 2 Stand der Technik Relationale Datenbanken PostgreSQL PostgreSQL, aktuell in Version 9.2, ist eine bekannte Open Source Datenbank im Bereich der relationalen Datenbanken. PostgeSQL bietet zur Speicherung von XML Daten einen eigenen XML Datentyp an. Dieser Datentyp ermöglicht die Überprüfung der Eingabedaten auf Wohlgeformtheit [53]. XML Funktionen beschränken sich allerdings auf XPath 1.0 und die Abbildung von Relationalen Tabellen auf XML [54]. Aufgrund der Tatsache, dass auch weitere wesentliche XML Standards nicht unterstützt werden, wurde auf die weitere Analyse dieser Datenbank verzichtet. MySQL Eine weitere populäre Open Source Datenbank im Bereich der relationalen Datenbanken ist MySQL. In Verbindung mit XML Daten ist sie jedoch nicht geeignet. Für die Speicherung von XML Daten existiert kein XML Datentyp, so dass die einzige Möglichkeit der Speicherung in Form des Text oder BLOB Datentyps erfolgen kann. Da somit keine XML Funktionen angewendet werden können und auch keine XML Standards unterstützt werden, wurde auf eine weitere Analyse von MySQL verzichtet. Oracle XML DB Mit der Oracle XML DB bietet Oracle ein Produkt zur Speicherung von XML Daten. Es handelt sich bei der XML DB um ein Feature der bekannten Oracle Database. Sofern nicht anders angegeben sind die Angaben dem Developer Guide [55] der aktuellen Version 11.2 entnommen. Indexierung Die Oracle XML DB bietet einen B-Baum Index sowie einen sogenannten XMLIndex. Die Verwendung richtet sich nach Art der XML Speicherung, also XML in relationalen Tabellen oder XML als CLOB. XMLIndex ermöglicht neben anderen Indices sowohl Pfad- als auch Werteindices. 17

34 2 Stand der Technik XQuery Zur Ausführung von Anfragen auf XML Daten kann der W3C XQuery 1.0 Standard genutzt werden. XQuery and XPath Full Text 1.0 Oracle XML DB unterstützt eine Volltextsuche, der dafür vorgesehene W3C Standard wird dabei aber nicht genutzt. XQuery Update Facility 1.0 Zur Aktualisierung der XML Daten können in Oracle XML DB mehrere Möglichkeiten Anwendung finden. Der W3C Standard ist allerdings nicht unter ihnen. XPath XPath wird von der Oracle XML DB in Version 2.0 unterstützt. Validation Die Überprüfung der XML Daten kann mit einer Document Type Definition erfolgen. Ebenso ist auch die Validierung gegen ein XML Schema möglich. XSL Transformation Zur Transformation von XML Dokumenten steht der XSLT 1.0 Standard zur Verfügung. Binärdaten Da die Oracle XML DB auf einer relationalen Datenbank basiert, können binäre Daten als BLOB Datentyp gespeichert werden. Zum Import von Daten mit Umwandlung in XML muss eine Middleware verwendet werden. Zu einer automatischen Transformation während des Imports konnten keine Informationen gefunden werden. 18

35 2 Stand der Technik Daten Import Neben einer WebDav Schnittstelle bietet die Oracle XML DB auch In- und Exportfunktionen. Webschnittstelle / Administrationsinterface Aufgrund der großen Produktvielfalt der Oracle Corporation konnte nicht ermittelt werden, inwiefern verschiedene Produkte und Anwendungen so zu kombinieren sind, dass die Oracle XML DB über ein Webinterface administriert werden kann. Microsoft SQL Server Der Microsoft SQL Server ist eine relationale Datenbank. Mit dem Spaltentyp XML wird die Speicherung von XML Daten nativ ermöglicht. Es wurde die aktuelle Version 2012 untersucht. Indexierung Die Indexierung einer Spalte einer relationalen Datenbank vom Typ XML kann im Microsoft SQL Server über einen XML Index erfolgen. Indexiert werden dazu u.a. alle Elemente, Werte und Pfade innerhalb der XML Zelle [56]. XQuery Zur Abfrage von XML Daten wird vom SQL Server, auch in der aktuellen Version 2012, lediglich das XQuery 1.0 Working Draft aus dem Jahr 2004 unterstützt [57]. XQuery and XPath Full Text 1.0 Mit dem Microsoft eigenen Standard SQLXML 4.0 ermöglicht der SQL Server die Volltextsuche, entspricht damit aber keinem W3C Standard [58]. XQuery Update Facility 1.0 Auch zur Veränderung der XML Daten nutzt der SQL Server den SQLXML 4.0 Standard und ist damit nicht mit dem W3C Standard konform [59]. 19

36 2 Stand der Technik XPath Der auch hier verwendete SQLXML 4.0 Standard unterstützt die Verwendung von XPath 1.0 [60]. Validation Die Validation der XML Spalten der relationalen Datenbank kann über XML Schema erfolgen [61]. Die Document Type Definition wird nicht vom SQL Server unterstützt. XSL Transformation Der Microsoft SQL Server unterstützt keine XSL Transformation. Binärdaten Über verschiedene Datentypen ermöglicht der SQL Server die Abspeicherung von binären Daten. Daten Import Der Import von bestehenden XML-Daten kann über einen Bulk-Import bewerkstelligt werden [62]. Eine WebDav Schnittstelle wird vom Microsoft SQL Server nicht angeboten. Webschnittstelle / Administrationsinterface Ebenso bietet der SQL Server keine Webschnittstelle zur Administration und Entwicklung. 20

37 2 Stand der Technik IBM DB2 purexml Bei der IBM purexml Datenbank handelt es sich um eine XML Erweiterung der IBM DB2 Datenbank. Die aktuelle Version ist die Indexierung Zur Indexierung von XML Daten mit DB2 purexml wird ein Key erzeugt. Der dabei zu indexierende Teil des XML Dokuments wird über ein XML Pattern angegeben. Dieses Vorgehen ähnelt sehr der Vorgehensweise wie von relationalen Datenbanken bekannt [63]. XQuery Die DB2 purexml unterstützt den XQuery Standard in seiner ersten Version [64]. XQuery and XPath Full Text 1.0 Eine Volltextsuche [65] wird ermöglicht, allerdings nicht nach W3C Standard [64]. XQuery Update Facility 1.0 Die XQuery Update Facility 1.0 unterstützt die IBM purexml seit Version 9.5 [66] in einer Vorversion aus dem Jahr Auch die aktuelle Version 10.5 der IBM DB2 wurde noch nicht auf die finale Version dieses Standards aktualisiert [64]. XPath XPath wird in Version 2.0 [64] von der DB2 purexml unterstützt. Validation Eine Validation der XML Daten kann anhand einer Document Type Definition oder gegen ein XML Schema erfolgen [67]. 21

38 2 Stand der Technik XSL Transformation Zur Transformation von XML Dokumenten wird XSLT in Version 1.0 unterstützt [68]. Binärdaten Zur Abspeicherung von binären Daten bietet auch die IBM DB2 entsprechende binäre Datentypen. Die Extraktion von XML obliegt aber auch hier dem Entwickler. Daten Import Zum Import von XML Daten stehen Importwerkzeuge zur Verfügung [69]. WebDav wird nicht unterstützt. Webschnittstelle / Administrationsinterface Zur Administration über ein Webinterface wird der Technology Explorer for DB2 als Open Source Erweiterung für die DB2 von IBM angeboten [70]. 22

39 2 Stand der Technik 2.3 Ergebnisse der Analyse Im Verlauf der Analyse zeigte sich bereits, dass relationale Datenbanken im Vergleich zu nativen XML Datenbanken seltener W3C Standards unterstützen. PostgreSQL und MySQL lassen XML Verarbeitung sogar ganz außen vor und werden daher im Weiteren nicht mehr betrachtet. Einen Überblick über die verbleibenden relationalen Datenbanken und deren XML Funktionsumfang gibt folgende Darstellung. Oracle XML DB Microsoft SQL Server IBM purexml Indexierung X X X XQuery 1.0 Working Draft XQuery and XPath Full Text 1.0 XQuery Update Facility 1.0 proprietär proprietär proprietär proprietär proprietär Vorversion XPath Datenvalidation XSD + DTD XSD XSD + DTD XSLT Binärdaten X X X Daten-Import Import + WebDav Import Import Webschnittstelle - - X Tabelle 2.1: XML Funktionen relationaler Datenbanken 23

40 2 Stand der Technik Es zeigt sich zwar, dass die restlichen relationalen Datenbanken die meisten geforderten Funktionen auf XML Daten unterstützen, diese aber oft proprietär umgesetzt werden. Diese Tatsache ist vor allem darauf zurückzuführen, dass zum Zeitpunkt der Implementierung dieser Funktionen oft noch kein entsprechender W3C Standard zur Verfügung stand und die Hersteller ihre eigenen Lösungen entwickeln mussten. Eine Übersicht der nativen XML Datenbanken gibt folgende Tabelle. MarkLogic Server BaseX exist Sedna Indexierung X X X X XQuery teilw teilw (f. Edition) XQuery and XPath Full Text 1.0 XQuery Update Facility 1.0 proprietär X proprietär proprietär proprietär X proprietär proprietär XPath (Candidate) Validation XSD + DTD XSD + DTD XSD + DTD - XSLT (2.0 über Saxon) 1.0 (2.0 über Saxon) 2.0 Binärdaten X X Inhaltsextraktion - Daten-Import WebDav Fetch Modul + WebDav WebDav BulkLoad Webschnittstelle X Tabelle 2.2: native XML Datenbanken im Vergleich 24

41 2 Stand der Technik Als native XML Datenbanken unterstützen alle die Indexierung der XML Daten. Um die indexierten Daten entsprechend verarbeiten zu können, wird eine Sprache zur Datenabfrage benötigt. Alle nativen XML Datenbanken unterstützen für diesen Zweck XQuery ab mindestens Version 1.0. BaseX sowie exist bieten Entwicklern bereits eine teilweise Unterstützung des noch unfertigen XQuery 3.0 Standard an und sind damit im Testfeld führend. Eine Volltextsuche und eine Daten Update Funktion bieten alle Datenbanken. Den entsprechenden W3C Standard unterstützt hingegen nur BaseX. Ebenso bietet auch nur BaseX Unterstützung für den XPath 3.0 Standard. Die restlichen nativen XML Datenbanken bieten alle den jeweils letzten finalen XPath Standard. Bis auf Sedna können alle analysierten nativen XML Datenbanken eine XML Daten Validation mittels Document Type Definition und XML Schema ausführen. Auch in Bezug auf XSL Transformation könnten alle Datenbanken mindestens Version 1.0 vorweisen. Der MarcLogic Server und Sedna bieten für den neueren Standard XSLT 2.0 direkte Unterstützung. BaseX und exist ermöglichen XSLT 2.0 über den SAXON XSLT and XQuery Processor. Im Abschnitt der sonstigen Anforderungen können alle Datenbanken mit Binärdaten umgehen. Der MarkLogic Server, BaseX und exist bieten für verschiedene Binärdaten eine Umwandlung in XML. Diese damit in XML importierten Binärdaten können anschließend ebenso mit XML Funktionen indexiert und durchsucht werden. Lediglich Sedna bietet diese Funktion nicht. Zur Betrachtung und Editierung bieten der MarkLogic Server, BaseX und exist eine WebDav Schnittstelle. Lediglich Sedna verzichtet auf diese Schnittstelle und bietet nur einen Bulkload zum Import neuer Daten an. Zur Administration der Daten kann nur der MarkLogic Server eine Webschnittstelle vorweisen. 2.4 Bewertung Ziel dieser Arbeit ist die Erweiterung der XML Verwaltungsfunktionen des DGS. Mit den aktuellen Standards bietet das W3C eine breite Palette an XML Standards an. Um die XML basierte Datenhaltung weiter voran zu bringen, ist diese Entwicklung zu begrüßen. Aus diesem Grund werden in folgender Darstellung W3C Standards besser bewertet als proprietäre Implementationen. Somit wird auch der DGS für die zukünftige Entwicklung im Bereich der XML Datenbanken gewappnet sein. 25

42 2 Stand der Technik Oracle XML DB Microsoft SQL Server IBM purexml MarkLogic Server BaseX exist Sedna Indexierung XQuery + O O XQuery and XPath Full Text XQuery Update Facility O XPath + O Datenvalidation + O XSLT O - O Binärdaten Daten-Import Webschnittstelle Tabelle 2.3: Bewertung nach Anforderungen 26

43 2 Stand der Technik Die Bewertung erfolgt nach folgenden Kriterien. ++ Anforderung nach neusten Standards erfüllt + Anforderung erfüllt O Anforderung teilweise erfüllt oder Standard veraltet - Anforderung nicht erfüllt Anschließend werden alle + addiert. Ein O wird als halber Punkt gewertet. In der sich daraus ergebenen Wertungen führt BaseX mit einer Punktzahl von elf, gefolgt vom MarkLogic Server sowie exist mit jeweils neun Punkten. Auch die separate Betrachtung der XML spezifischen Anforderungen zeigt, dass BaseX mit neun Punkten deutlich vor dem MarkLogic Server und exist mit nur sechs Punkten liegt. 2.5 Zusammenfassung zum Stand der Technik Die im Testfeld analysierten Datenbanken können im Großteil mit XML Daten umgehen. Lediglich MySQL und PostgreSQL sind aufgrund des nicht vorhandenen bzw. nur sehr geringen XML Funktionsumfangs für die Speicherung von XML Daten ungeeignet. Besser sind die verbleibenden Datenbanken, so sind bis auf den Microsoft SQL Server alle Datenbanken in der Lage, die verlangten Verwaltungsfunktionen anzubieten. Betrachtet man anschließend die unterstützen Standards der verschiedenen Datenbanken, muss festgestellt werden, dass diese vorrangig proprietärer umgesetzt werden. Nur BaseX kann sich hier mit einem breiten Spektrum an unterstützten W3C Standards, auch aktueller noch nicht finaler Standards, von den anderen Datenbanken hervorheben. 27

44

45 3 Konzept 3 Konzept Im Rahmen des WebComposition Projekts und dem daraus hervorgegangenen DGS fehlen bisher essentielle XML-Verwaltungsfunktionen. Umfang dieser Arbeit ist daher die Erweiterung des DGS um nötige XML Verwaltungsfunktionen. Wie die Analyse zeigte, sind viele Datenbanken für den Einsatz mit XML Daten bereit. Die Durchdringung mit den teilweise noch neuen W3C Standards ist aber noch nicht gegeben. Einzig BaseX kann mit der W3C standardisierten Volltextsuche und dem finalen XQuery Update Facility Standard umgehen. Zusammen mit der Unterstützung des neuen XQuery 3.0 Standard bildet BaseX damit ein gutes Fundament für die Speicherung von XML Daten über den DGS. Im weiteren Verlauf der Arbeit sollen die XML Verwaltungsfunktionen des DGS daher mit Hilfe der nativen XML Datenbank BaseX verbessert und erweitert werden. Um BaseX mit dem DGS zu verbinden ist eine geeignete API nötig. Da der DGS in C# geschrieben wurde, bietet sich die Verwendung der BaseX C# API an. Diese stellt eine Klasse mit verschiedenen Methoden zur Ausführung von BaseX sowie XQuery Befehlen zur Verfügung. Die Verbindung selbst wird über einen TCP Stream aufgebaut. Der DGS verwendet für Datenspeicher sogenannte Data Space Engines. Eine Data Space Engine (DSE) besteht dazu aus mehreren untergliederten Komponenten. Einkommende Befehle werden an verschiedene Handler weitergeleitet. Im Fehlerfall übernimmt die DSE die Fehlerverarbeitung und Ausgabe. Hat die DSE eine für eine Eingabe passenden Handler gefunden, wird die weitere Verarbeitung vom entsprechenden Handler übernommen. Je nach Eingabe und der Aufgabe des Handlers löst dieser wiederrum lesende oder datenändernde Operationen im InformationStore aus. 29

46 3 Konzept Im InformationStore werden zu den datenverändernden Operationen nötige Vorarbeiten oder Nacharbeiten ausgeführt und über den DataStorage Daten aus der Datenbank abgerufen oder darin abgelegt. Bei bisherigen DSEs befinden sich im InformationStore daher all die Operationen, die nicht nativ in der Datenbank ausgeführt werden können. So werden XPath Auswertungen oder XSL Transformationen im InformationStore ausgeführt. Aufgrund der Unterstützung nativer XML Operationen mit BaseX sollen diese Operationen aus dem InformationStore entfernt und durch geeignete Datenbankoperationen im DataStorage ersetzt werden. Um dies zu ermöglichen, müssen InformationStore und DataStorage um entsprechende Schnittstellen erweitert werden. Data Grid Service Data Space Engine Handler InformationStore DataStorage BaseX API Abbildung 3.1: Interne Struktur einer DSE des DGS Mit den neu erstellten Schnittstellen sollen Operationen nativ von BaseX übernommen werden. Dazu zählen XML Validation sowie die Transformation von XML Elementen in der Datenbank mittels XSLT. Aber auch die Selektion mit XPath über den UriPatternHandler soll von BaseX übernommen werden. Damit der Funktionsumfang nicht nur mittels BaseX optimiert wird, sondern auch bisher nicht mögliche Operationen, wie Querys, ausgeführt werden können, soll zudem ein neuer Handler für XQuerys implementiert werden. Ziel ist es, wie schon beim UriPatternHandler, ein Templates in der Datenbank abzulegen, das anschließend über 30

47 3 Konzept eine URL aufgerufen werden kann. Dabei sollen Variablen für einen XQuery Ausdruck ebenso in der URL untergebracht werden. Um die Funktionalität der Entwicklung jederzeit prüfen zu können und auch die Kompatibilität der neuen DSE mit dem DGS zu gewährleisten, sollen zudem für die XmlDSE hinterlegten Tests für die neue DSE übernommen werden. Zum Abschluss der Arbeiten wird somit ein neues Modul zur Anbindung der BaseX Datenbank an den DGS entstanden sein. 31

48

49 4 Realisierung 4 Realisierung Im folgenden Kapitel wird die Implementation der BaseX Datenbank in den DGS vorgestellt und erläutert. 4.1 Anbindung BaseX Zur Anbindung des DGS an BaseX bietet sich die von BaseX angebotene C# API an. Dabei handelt es sich um eine Klasse mit verschiedenen Methoden zur Ausführung von BaseX- und XQuery-Befehlen. Auch Querys mit mehreren Datensätzen als Ergebnis können komfortabel ausgewertet werden. Die API nutzt zur Anbindung an BaseX eine TCP Stream Schnittstelle. Die Einbindung der C# API ist in wenigen Augenblicken abgeschlossen. Nach erfolgter Initialisierung kann über das Datenbankobjekt anschließend mit der Datenbank kommuniziert werden. _dgsdb = new Session("localhost", 1984, "admin", "pass"); _dgsdb.execute("xquery for $i in 1 to 10 return $i"); Listing 4.1: Initialisierung einer Datenbankverbindung zu BaseX 4.2 Datenstruktur Der DGS bietet die Speicherung der Daten als XML-Liste. Diese XML-Liste sowie die dazugehörigen Metadaten und das XML-Schema müssen in BaseX abgelegt werden. Dazu ist der Entwurf einer entsprechenden Datenstruktur notwendig. 33

50 4 Realisierung Database1 dgs.xml lists list listdata metadata schemadata xsltdata Abbildung 4.1: DGS Datenstruktur in BaseX Innerhalb einer Datenbank in BaseX können mehrere XML Dateien hinterlegt werden. Für den DGS wurde dazu die Datei dgs.xml in BaseX geladen. Innerhalb der dgs.xml befindet sich ein XML Element <lists>, welches alle späteren DGS Listen enthält. Die Listen selbst werden wiederrum mit einem <list> Elements umschlossen. xquery doc("database1/dgs")/lists Listing 4.2: Zugriff auf das <lists> Element mit allen DGS Listen In jeder Liste sind anschließend die vier Bereiche der DGS Daten gespeichert. Für die Speicherung der Listendaten dient das Element <listdata>. Metadaten der Liste werden unter <metadata> abgelegt. Für eine XSL Transformation und das XML Schema stehen optional das <xsltdata> sowie <schemadata> Element zur Verfügung. 34

51 4 Realisierung 4.3 Anlegen einer neuen DSE Zur Umsetzung der BaseX Anbindung ist es notwendig für den DGS eine neue DSE zu entwickeln. Um dem Namensschema treu zu bleiben, wird die neue DSE NativeXmlDSE genannt. Aufgrund der Tatsache, dass die bisher existierende XmlDSE und die DbDSE Aufgaben, wie Validation und XSLT, innerhalb des InformationStorage im DGS ausführen, sind die Schnittstellen im DataStorage auf das Lesen und Schreiben kompletter Listen-, Meta-, XSLT- und Schemadaten ausgelegt. Intern arbeiten diese DSEs mit einem XML List Objekt, welches zur Ausführung von XML Funktionen außerhalb der Datenbank genutzt wird. Dieses Vorgehen ermöglicht es, in diesem Projekt zu Beginn der Entwicklung eine bereits existierende DSE zu verwenden und lediglich ihre Schreib- und Leseoperationen im DataStorage auf BaseX umzuschreiben, ohne die Funktionalität zu verändern. Auf dieser Grundlage, einer funktionierenden DSE mit BaseX Backend, können im folgenden Optimierungen und Erweiterungen des Funktionsumfangs der NativeXmlDSE vorgenommen werden. XmlDSE sowie DbDSE beinhalten bereits Unit und Acceptance Tests zur Validierung des Programmcodes. Da die APIs der DSEs für den DGS fest definiert sind, bietet es sich an, diese Tests ebenso für die neue NativeXmlDSE zu verwenden. Im NativeXmlDSE Projekt wurden daher die Tests übernommen. 4.4 DataStorage für BaseX Um die neu erzeugte NativeXmlDSE mit BaseX zu verbinden, ist es notwendig, im DataStorage Gebrauch von der BaseX API zu machen und entsprechende XQuery Befehle zu erstellen. Die Grundstruktur des DataStorage besteht dazu aus vier Teilbereichen. Den ersten Teilbereich des DataStorage bilden die Funktionen zur Verwaltung der XML-Listen in der Datenbank. Zweiter und dritter Teilbereich des DataStorage bilden die Funktionen zur Speicherung von Metadaten und dem Listen- Schema. Den vierten Bereich bilden die Funktionen zur Speicherung der einzelnen Listenelemente bzw. der Datensätze sowie XSL Transformationen. Weitere Funktionen werden später zur Optimierung und Erweiterung der NativeXmlDSE hinzukommen. Um die Übersichtlichkeit beizubehalten, wird der NativeXmlDSE DataStorage mittels partieller Typdefinition [71] auf mehrere Dateien aufgesplittert und mit eindeutigen Namen versehen. 35