Datenaustausch mit XML

(1)

Datenaustausch mit XML

Entwicklung eines generischen Vermittlungs-Werkzeuges zwischen XML Schemas und Datenbanken

Diplomarbeit im Fach Informatik an der Universität Fribourg

Eingereicht am:

30.8.2002

Vorgelegt von:

Thomas Schädler Rue de l'Industrie 2

1700 Fribourg

thomas.schaedler@unifr.ch

1. Referent: Prof. Andreas Meier

2. Referent: Prof. Pius Hättenschwiler

Betreuer: Ass. Stefan Hüsemann

(2)

Kurzfassung

Diese Diplomarbeit befasst sich mit der Erstellung eines Vermittlungswerkzeuges zwischen XML Schemas und Datenbanken. XML Schemas werden heute immer mehr eingesetzt um Daten zwischen verschiedenen Systemen auszutauschen. Als Beispiel wird die Verwendung des AIDA IDML Schemas genauer erläutert. Dieses XML Schema wird von Organisationen im Bereich der Entwicklungsarbeit ausgearbeitet und eingesetzt. Ein noch ungelöstes Problem ist es aber, wie man die in diversen Da- tenbanken vorhandenen Informationen ohne grossen Aufwand in das gewünschte Format konvertie- ren kann.

Die bisherige Praxis geht davon aus, dass man eine Datenbank besitzt, die selbst in der Lage ist dies zu bewerkstelligen oder aber man beauftragt einen Experten der diese Arbeit durch eine speziell zu- geschnittene, neu zu erstellende Software erledigt. Dies setzt meist grosse Geldmittel voraus, was aber genau in dieser Branche nicht unbedingt gegeben ist, oder die anderweitig besser verwendet werden könnten.

Hier setzt diese Diplomarbeit an und versucht diese Nachteile durch ein generisches Vermittlungs - werkzeug zu beseitigen. Es ist detailliert beschrieben welche Grundkonzepte hinter einem solchen Werkzeug stehen. Die verschiedenen Ansätze um die Daten von einem Modell (Datenbank) in ein anderes Modell (XML Schema) zu konvertieren werden vertiefend erklärt.

In einem weiteren Teil werden die genauen Anforderungen an das zu erstellenden Werkzeug aufgelis- tet und schliesslich wird genauer auf die Implementation eingegangen. Das Werkzeug wird dabei schrittweise - nach anfallender Komplexität des jeweiligen Modells - implementiert. Der aufmerksame Leser kann somit den Entstehungsprozess besser verfolgen und durch den modularen Aufbau ist eine mögliche Erweiterung dieses Werkzeuges nicht auszuschliessen.

In einem letzten Teil wird die Arbeit mit dem neu erstellen Werkzeug für den Anwender erläutert. Da dieses Werkzeug nicht auf ein einzelnes XML Schema fixiert ist, sind viele Anwendungsmöglichkeiten denkbar und der Autor hofft, dass sein Werkzeug - da Open Source und damit absolut lizenzfrei - vie- len Entwicklern aber auch normalen Anwendern gute Dienste leistet.

Keywords

XML - XML Schema - Mapping - Datenbanken - Vermittlungswerkzeug

(3)

Inhaltsverzeichnis

1 Einleitung... 1

1.1 Problemstellung ... 1

1.2 Zielsetzung ... 2

1.3 Vorgehensweise ... 3

2 Datenaustausch mit XML ... 4

2.1 Grundlagen von XML... 4

2.1.1 XML allgemein ... 4

2.1.2 XML Schema und Namensräume... 5

2.1.3 DOM und SA X ... 9

2.2 Vor- und Nachteile von XML ...11

2.3 Alternative Möglichkeiten zum Datenaustausch...12

2.4 IDML Schema ...13

2.5 Client/Server- oder Dreischichtenarchitektur ...17

3 Datenbanken...19

3.1 Grundlegende Anforderungen...19

3.2 Schnittstellen ...19

3.3 Beziehung zwischen Datenbanken und XML...20

3.4 Mapping ...21

3.4.1 Tabellen-basiertes Mapping...21

3.4.2 Vorlagen-gesteuertes Mapping ...22

3.4.3 Objekt-relationales Mapping ...22

4 Erstellung eines Modells ...25

4.1 Anforderungen an das Modell ...25

4.2 Konstruktion des Modells ...25

4.3 Festlegung des Modells ...27

4.3.1 Der Konfigurator ...27

4.3.2 Die Serverkomponente...29

4.3.3 Die Mappingmodule ...29

5 Auswahl der Software / Programmiersprache ...31

5.1 Anforderungen ...31

5.2 Auswahl der Programmiersprache...31

5.3 Auswahl der Werkzeuge...31

5.4 Auswahl der Bibliotheken...32

6 Implementation des Modells ...33

6.1 Speicherungshierarchie der Projektdaten...33

6.2 Implementation des Konfigurators ...33

6.2.1 Implementation des Moduls «Simple DB Export» ...36

6.2.2 Implementation des Moduls «Database to XML»...39

(4)

Inhaltsverzeichnis

6.3 Implementation des Servers ...44

6.4 Erfahrungsbericht ...45

7 Informationen für Anwender ...46

7.1 Einführung ...46

7.2 Systemvoraussetzungen und Installation ...46

7.3 Handbuch: <xmlizer> configurator ...47

7.3.1 Startparameter...47

7.3.2 Anleitung...48

7.4 Handbuch: <xmlizer> server ...51

7.4.1 Startparameter...51

7.4.2 Anleitung...52

7.4.3 Anpassung an Ihre Bedürfnisse ...55

8 Schlussfolgerungen ...56

9 Quellenangaben und Literaturverzeichnis...57

Anhang A: Quelltext <xmlizer> configurator...60

Anhang B: Quelltext <xmlizer> server ... 239

Ehrenwörtliche Erklärung ... 299

(5)

Abkürzungsverzeichnis

AIDA Accessible Information on Development Activities

API Application Programming Interface (Programmierschnittstelle zu einer Applikation) ASP Active Server Pages (Proprietäre Internet-Technologie von Microsoft)

DOM Document Object Model DTD Document Type Definition

EDI Electronic Data/Document Interchange

EDIFACT Electronic Data Interchange for Administration, Commerce and Transport HTML Hypertext Markup Language

HTTP Hypertext Transfer Protocol

IDE Integrated Development Environment

IDML International Development Markup Language

ISO International Standardization Organization (Internationales Normierungsgremium für den technischen Bereich)

JDBC Java Database Connectivity

JDOM Java-based Document Object Model NPO Non-Profit Organization

ODBC Open Data Base Connectivity (Microsoft)

PHP PHP Hypertext Preprocessor (rekursives Akronym)

RDF Resource Description Framework (Standard für Metadaten-Formate) RFC Request for Comments (Vorschlag für eine Norm im TCP/IP-Bereich) RSS Rich Site Summary / RDF Site Summary / Really Simple Syndication SAX Simple API for XML

SGML Standard Generalized Markup Language SQL Structured Query Language

TCP/IP Transmission Control Protocol / Internet Protocol (Kommunikationsstandard) UML Unified Modeling Language

URI Uniform/Universal Resource Identifier (Generische Menge an Zeichenketten um Ressourcen zu referenzieren)

URL Universal/Uniform Resource Locator (Term für populäre URI's: http, ftp, etc…) URN Universal Resource Name (nach RFC 2141 definierter, eindeutiger Identifizierer) W3C World Wide Web Consortium (Vereinigung die sich um WWW-Standards kümmert)

WWW World Wide Web

XML Extensible Markup Language

XOR Exclusive Or (Logischer Operator)

(6)

Abbildungsverzeichnis

Abbildung 1 : AIDA Projects Development Gateway Website ... 2

Abbildung 2 : Beispieldokument garage.xml (XML Dokument)... 4

Abbildung 3 : Bedeutung der Namensräume in XML... 6

Abbildung 4 : Beispieldokument garage.xsd (XML Schema)... 8

Abbildung 5 : Baumstruktur des Beispielschemas [XMLSPY 01] ... 9

Abbildung 6 : Konzeption von DOM (Document Object Model)... 9

Abbildung 7 : Gegenüberstellung von DOM und SAX...11

Abbildung 8 : Site Description Schema: Beispiel von idmlInfo.xml ...13

Abbildung 9 : IDML Core Activity Schema (Baum) [XMLSPY 01] ...14

Abbildung 10 : Core Activity Schema: Beispiel von activities.xml ...16

Abbildung 11 : IDML Datenaustausch (Standardprozedur)...17

Abbildung 12 : IDML Datenaustausch (mit Vermittlungswerkzeug) ...18

Abbildung 13 : Beispiel für Tabellen-basiertes Mapping [Bourret 02] ...22

Abbildung 14 : Beispiel für Vorlagen-gesteuertes Mapping ...22

Abbildung 15 : XML Dokument aus Abbildung 2 als Objekt-Schema ...23

Abbildung 16 : XML Dokument aus Abbildung 2 als Objekt-Baum, DOM-Baum und Klassenhierarchie ...24

Abbildung 17 : Architektur des Vermittlungswerkzeugs in der Übersicht...26

Abbildung 18 : xmlizer.project.config.xsd (Baum, kein Mapping) [XMLSPY 01] ...28

Abbildung 19 : Beispiel einer Konfigurationsdatei ohne Mappinginformationen ...29

Abbildung 20 : UML Klassen-Diagramm des Konfigurators (User Interface) [JVision 02] ...34

Abbildung 21 : UML Klassen-Diagramm des Konfigurators (Daten) [JVision 02] ...35

Abbildung 22 : Beispielausgabe des Moduls «Simple DB Export» (simple) ...36

Abbildung 23 : xmlizer.smdbe.verbose.dtd...37

Abbildung 24 : Beispielausgabe des Moduls «Simple DB Export» (verbose) ...38

Abbildung 25 : Beispiel der Mappingdaten für das Modul «Simple DB Export» (gekürzt)...38

Abbildung 26 : xmlizer.project.config.xsd (Baum, nur Mapping) [XMLSPY 01] ...39

Abbildung 27 : Beispiel der Mappingdaten für das Modul «Database to XML» ...40

Abbildung 28 : UML Klassen-Diagramm des Servers (Komplett) [JVision 02] ...44

Abbildung 29 : Der Konfigurator in Aktion ...48

Abbildung 30 : Das Module «Simple DB Export» in Aktion ...49

Abbildung 31 : Das Modul «Database to XML» in Aktion : Der Datenbankbrowser ...50

Abbildung 32 : Das Modul «Database to XML» in Aktion: Drag und Drop einer Abfrage ...51

Abbildung 33 : Beispiel zweier URL's für das Modul «Simple DB Export» ...53

Abbildung 34 : Beispiel einer URL für das Modul «Database to XML» ...53

Abbildung 35 : Auflistung der Projekte des Servers (index.html) ...53

Abbildung 36 : Projektdetails für das Modul «Database to XML»...54

Abbildung 37 : Beispiel einer HTML-formatierten Ausgabe der XML Daten ...54

(7)

1 Einleitung

1.1 Problemstellung

Humanitäre Organisationen haben ein grosses Bedürfnis nach Kommunikation innerhalb der Organi- sation selber, aber auch gegenüber ihren Partnern, die im folgenden als Stakeholder bezeichnet wer- den. Die internationale Arbeit von humanitären Organisationen stellt eine weitere Hürde für eine gute Kommunikation und Information aller Stakeholder dar.

Humanitäre Projekte müssen geplant, durchgeführt und anschliessend evaluiert werden. Diese Arbeit generiert eine grosse Menge von Daten bei allen Beteiligten. Das Medium Internet kann dabei eine grosse Hilfe sein, da dessen Einsatz relativ billig und ortsunabhängig ist. Das Problem ist allerdings die Menge an Daten und die verschiedenen Datenformate die bei den verschiedenen Stakeholdern eingesetzt werden. Um an die Daten zu kommen müssen die Stakeholder viele verschiedene Quellen finden und analysieren.

Besser wäre es ein definiertes Datenformat zu haben, das dezentral gespeichert, aber von einer zent - ralen Stelle aus (z.B. von einer Website) durchsucht werden kann. Weitere Ansprüche an eine solche Webapplikation sind v.a. aus der Sicht von NPO's (Non-Profit Organisationen) der Einsatz von lizenz- freier Software und offenen Standards. Ausserdem sollten die eingesetzten Standards zukunftssicher sein, damit die angehäuften Daten nicht in kürze wieder neu aufbereitet werden müssen.

Eine Lösung für den Datenaustausch von Projektinformationen in Bezug auf Entwicklungsprojekte wird momentan in Form eines XML Schemas ausgearbeitet [IDML 01]. Dieses Schema ist auch Grundlage dieser Arbeit. Wie in Abbildung 1 zu sehen ist hat das AIDA Projekt hat schon eine Web- Applikation entwickelt um weltweit nach Entwicklungsprojekten zu suchen.

Ein noch ungelöstes Problem ist auch die Speicherung von (XML-) Projektdaten in einer (schon vor-

handenen) Datenbank und das Auslesen der Datensätze um das Austauchformat zu erhalten. Eine

mögliche Lösung ist das Programmieren eines Filters, der die richtigen Daten automatisch aus der

Datenbank auslesen und in das gewünschte XML Schema umwandeln oder vorhandene XML Daten

in die Datenbank aufnehmen kann. Besser wäre es ein generisches Werkzeug zu haben, das zwi-

schen Datenbank und XML Schema vermitteln kann.

(8)

1 Einleitung

Abbildung 1 : AIDA Projects Development Gateway Website Es gibt drei Grundlegende Szenarien:

1. Es ist keine Datenbank vorhanden (Die XML Daten werden in einer neu angelegten Daten- bank gespeichert.)

2. Es ist kein XML Schema vorhanden (Die Daten aus der Datenbank werden in einem neu ge- nerierten XML Format ausgegeben.)

3. Datenbank und Schema sind vorhanden, aber die Abbildung in beide Richtungen ist noch nicht erledigt.)

Am häufigsten wird wohl der dritte Fall vorkommen, da alle Stakeholder normalerweise schon Daten- banken besitzen und nur die Daten nach einem ebenfalls schon vorhandenen XM L Schema ex - bzw.

importieren wollen. Diese Arbeit benötigt genau Kenntnisse der Datenbank und des zu verwendenden XML Schemas. Beim ersten und zweiten Fall gibt es Möglichkeiten automatisch aus der Datenbank ein XML Schema zu generieren oder umgekehrt.

1.2 Zielsetzung

Die Zielsetzung dieser Diplomarbeit ist es ein Werkzeug zu entwickeln, das beliebige Datenbanken

auf beliebige XML Schemas abbilden kann, vorausgesetzt natürlich die Datenbank stellt alle Informa-

tionen zur Verfügung die benötigt werden. Primär ist jedoch die Funktion um XML Daten aus beliebi-

gen Datenbanken auszulesen und in das IDML Schema zu konvertieren, um damit die schnelle An-

bindung vieler neuer Datenbanken für das AIDA Projekt zu ermöglichen [AIDA 01]. Einmal für die

(9)

1 Einleitung

jeweilige Datenbank und das benutzte XML Schema konfiguriert, vermittelt dieses Werkzeug automa- tisch zwischen Datenbank und XML Schema. Es ist nachher möglich, Daten aus der Datenbank als gültige XML Datei auszulesen, die nachher verschickt oder bearbeitet werden können. Auch die Auf- nahme einer XML Datei in die Datenbank ist möglich. Dies würde auch bei Änderungen in der Anord- nung (Datenbank oder XML Schema) eine einfache Möglichkeit darstellen auf die neue Situation zu reagieren.

1.3 Vorgehensweise

In einem ersten Teil der Arbeit werden grundsätzliche Fragen zu XML (Extendend Markup Language) geklärt. Vor- und Nachteile von XML werden analysiert und ein Überblick über die momentan verwen- deten Technologien zum Austausch von Informationen über das Internet wird verschafft. Hauptau- genmerk liegt dabei auf den verwendeten Standards (XML allgemein, XML Schema, DOM und SAX), da diese Standards im weiteren Verlauf dieser Arbeit exzessiv verwendet und analysiert werden. An einem kleinen Beispiel wird die Verwendung von XML und XML Schema erklärt.

In einem zweiten Teil wird auf die Anforderungen an die zu verwendenden Datenbanken eingegan- gen. Da es Ziel der Arbeit ist mit möglichst vielen verschiedenen Datenbanken zusammenzuarbeiten ist eine Suche nach der offensten Programmierschnittstelle (API: Application Programming Interface) nötig. Dieses Kriterium schränkt schon früh ein, welche Programmiersprache sich für die künftige Implementation verwenden lässt.

Nach der Festlegung der Grundlagen wird in einem dritten Teil ein Modell aufgestellt, dass dann für die Implementation als Grundlage dienen wird. Alle bisher gesammelten Anforderungen müssen in dem Modell vereinigt werden und werden detailliert beschrieben. Die Anforderungen an die Benutzer- schnittstelle müssen auch abgeklärt werden.

Es gibt eine Unmenge an möglichen Standards, Sprachen und Softwarekomponenten, mit dem so ein Modell implementiert werden kann. Im vierten Teil werden diese Möglichkeiten und Kombinationen kurz analysiert und bewertet.

Im fünften Teil dieser Arbeit wird das aufgestellte Modell mit der am besten bewerteten Software imp- lementiert und die dabei auftretenden positiven und negativen Erfahrungen erläutert. Die Basis für die Implementation wird mit Hilfe von UML Klassen-Diagrammen erstellt. Das daraus erstellte Code- Gerüst wird anschliessen nach dem Top-Down-Verfahren implementiert und je nach Notwendigkeit erweitert.

Im sechsten und letzten Teil dieser Arbeit wird die Arbeit mit der nun erstellten Software für den zu-

künftigen Anwender in der Art eines Handbuchs erklärt um ein produktives Arbeiten zu erleichtern.

(10)

2 Datenaustausch mit XML

2.1 Grundlagen von XML

Das WWW (World Wide Web) bietet heute mehr als nur statische Inhalte. Leider ist HTML (Hypertext Markup Language) nur bedingt nützlich um neue Anwendungen im Internet abrufbar zu machen.

HTML wurde als Auszeichnungssprache konzipiert und beschreibt wie ein Dokument in einem Web- browser darzustellen ist. Bei HTML ist die Semantik der Auszeichnungselemente (engl.: tag) fest defi- niert und die Menge an Auszeichnungselementen ist genau definiert und somit limitiert. Diese Ein- schränkung ist genau das Problem, wenn man Daten über das Internet austauschen oder eigene Strukturen definieren möchte.

2.1.1 XML allgemein

XML (Extended Markup Language) ist keine Markupsprache wie HTML, sondern eine Metasprache zur Definition von Markupsprachen. XML wurde vom W3C (World Wide Web Consortium

¹

) definiert welches auch HTML definierte. HTML ist eine Untermenge von XML, und XML ist wiederum eine Un- termenge von SGML (Standard Generalized Markup Language) welches schon 1986 vom W3C als ISO-Standard (ISO 8879) definiert wurde. Da SGML nicht direkt für das WWW definiert wurde und eine sehr komplexe Sprache ist wurde XML entwickelt um diese Lücke zu schliessen.

Um die Syntax von XML besser zu verstehen folgt ein kurzes Beispieldokument. In der erste Zeile jedes XML Dokuments muss der Prolog stehen. Im Prolog stehen Versionsnummer, Codierung und eine Anweisung ob das Dokument auf eine externe DTD (Document Type Definition) oder ein XML Schema (Alternative einer DTD) verweist oder ohne auskommt. Im Wurzelelement (<garage>) werden die benötigten Namensräume definiert. Leere Elemente darf man in XML auch wie im Beispiel das Optionen-Element abkürzen (<option/>), es kann aber auch weiterhin die aus HTML bekannte Form (<option></option>) verwendet werden.

<?xml version="1.0" encoding="ISO8859-1" standalone="no"?>

<garage xmlns="http://www.e-freak.ch/xml/garage"

xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance"

xsi:schemaLocation="http://www.e-freak.ch/xml/garage garage.xsd">

<motorrad>

<marke>Yamaha</marke>

<typ herstellungsjahr="1984" zylinder="1">XT 550</typ>

<farbe>Schwarz</farbe>

<option />

</motorrad>

</garage>

Abbildung 2 : Beispieldokument garage.xml (XML Dokument)

1

World Wide Web Consortium http://www.w3.org/

Prolog

Namens- raum definitio- nen

Motorrad-

Element

(11)

2 Datenaustausch mit XML

Auszeichnungselement können auch Attribute verwenden, um zusätzliche Daten aufzunehmen. Im konkreten Beispiel hat das Auszeichnungselement «typ» ein Attribut «herstellungsjahr» und ein Attri- but «zylinder». Ob man ein Attribut oder ein neues Auszeichnungselement benutzt hängt von der Art der Daten ab. Es gibt keine allgemeingültigen Regeln, aber als Faustregeln kann man folgende Hin- weise zu Rate ziehen [XMLS 01]:

• Daten die wiederum in Unterkategorien gegliedert werden, die andere Auszeichnungselemen- te enthalten, müssen als eigenes Auszeichnungselement definiert werden (in Attributen kann man keine Auszeichnungselemente speichern, sondern nur simplen Text).

• Wenn Daten mehrere Zeilen lang sein können, muss auch ein eigenes Auszeichnungsele- ment verwendet werden. (Man könnte auch ein Attribut verwenden, allerdings wird der Code dann sehr unleserlich.)

• Wenn Daten oft ändern sollte man auch eigene Auszeichnungselemente definieren. (Mit heu- tigen XML-Editoren sind Auszeichnungselemente einfacher zu finden und zu ändern als Attribute).

• Kurze und kaum zu ändernde Daten werden bevorzugt als Attribut gespeichert.

• Sind bei den Daten eine limitierte Anzahl von Möglichkeiten vorgesehen (Auswahl), dann be- nutzt man bevorzugt Attribute (XML Editoren können dann z.B. die Auswahl das Dropdown- Liste anzeigen und es können dann nur die Daten eingetragen werden die dafür in dem XML Schema definiert wurden).

Damit ein XML Dokument syntaktisch korrekt ist (engl.: well-formed) muss sich ein XML Dokument strikt an folgende Regeln halten (ein komplette Liste aller Regeln und damit verbundne Fragen kann man bei [UUC 01] nachlesen):

• ein XML Dokument muss mindestens ein Element enthalten

• es darf nur ein Wurzel-Element enthalten, welches alle anderen Elemente umschliesst

• Elemente müssen sich immer komplett umschliessen und dürfen sich nicht überlappen

Durch das Einhalten aller Regeln wird der Austausch von XML Dokumenten erst möglich und es müs- sen keine speziellen Programme geschrieben werden um Fehler zu erkennen. Ein XML Dokument alleine hat aber noch keine Aussagekraft (für eine Maschine). Das Dokument kann zwar von einem Menschen gelesen und verstanden werden, eine Maschine braucht aber mehr Informationen zu den benutzten Auszeichnungselementen, da diese ja frei erfunden wurden. Damit ein XML Dokument gül- tig (engl.: valid) ist muss es eine DTD oder ein XML Schema assoziiert haben.

2.1.2 XML Schema und Namensräume

Im folgenden wird nur auf den XML Schema Standard eingegangen, da die DTD’s in Zukunft von XML

Schema abgelöst werden sollten. Am 3. Mai 2001 hat das World Wide Web Consortium XML Schema

als «Recommendation» herausgegeben und dieser Standard wird jetzt als stabil bezeichnet [W3CS

01]. XML Schema bietet im Vergleich zu einer DTD bessere Lesbarkeit (XML Syntax), über 40 vorde-

finierte Datentypen, Möglichkeit der Gruppierung von Elementen, Möglichkeit der objektorientierten

(12)

2 Datenaustausch mit XML

Programmierung (Vererbung, Erweiterbarkeit und Restriktion), Gebrauch von Namensräumen und Reguläre Ausdrücke um eigene Typen genau zu definieren.

Ein XML Dokument kann in unterschiedlichen Anwendungsgebieten verwendet werden. Namensräu- me (engl.: namespaces) werden definiert, damit die es keine Konflikte zwischen den Elementnamen verschiedener XML Schemas geben kann. Namensräume werden mittels einer einmaligen, fiktiven URI (Uniform Resource Identifier) oder URN (Universal Resource Name) voneinander unterschieden.

Das XML Schema muss also nicht – kann aber – unter dieser URI erreichbar sein. Nach [Castro 00]

wurden URI's gewählt, da die Namensgebung von URI's von Natur aus einmalig ist (jeder Domainna- men kann nur einmal ve rgeben werden). Jedes Schema hat seinen eigenen Namensraum, kann aber auch zu einem bestehenden Namensraum hinzugefügt werden, falls es keine Kollisionen der verwen- deten Element- und Attributnamen geben kann (engl.: sharing). Abbildung 3 verdeutlicht die Wichtig- keit von Namensräumen und zeigt auf, in welcher Verbindung die verschiedenen Namensräume ste- hen.

Abbildung 3 : Bedeutung der Namensräume in XML

Definiert man für die Namensräume ein Präfix (z.B. «xmlns:xsd» mit Präfix «xsd»), muss man bei Gebrauch eines Elementes aus diesem Namensraum das Präfix verwenden. Der Bezeichner «xmlns»

für Namensräume ist reserviert, wie alle Bezeichner, die mit «xml» beginnen. Ohne Präfix sind die Elemente global definiert und dürfen daher ohne Präfix verwendet werden. Es gibt daher drei unter- schiedliche Varianten um mit Namensräumen zu arbeiten:

• Man definiert den Namensraum des Schemas der Schemen global und die eigenen Elemente müssen mit einem Präfix gekennzeichnet werden.

• Man definiert den eigenen Namensraum global und den Namensraum des Schemas der Schemen mit einem Präfix oder

• man kann auch beiden Namensräumen ein Präfix vergeben.

garage.xml ...

schemaLocation="A garage.xsd"

...

garage.xsd ...

xmlns:xsd="B"

targetNamespace="A"

...

XMLSchema.xsd B: «schema-of-schemas»

(definiert die Elemente des Namensraumes B, um damit eigene Sche- men zu definieren)

...validiert das Ausgangsdokument nach den Regeln des übergeordneten Dokuments Ÿ benutzt Elemente aus

dem Namensraum A

Ÿ definiert Elemente des Namensraumes A Ÿ benutzt Elemente des Namensraumes B

Ÿ benutzt Elemente aus

dem Namensraum B

(URL des Schemas der

Schemen: W3C-Vorgabe)

(13)

2 Datenaustausch mit XML

Im folgenden wird die zweite - besser lesbare - Variante verwendet: Alle Elemente aus dem Namens- raum des Schemas der Schemen müssen also mit Präfix deklariert werden, eigene Elemente nicht.

Ein XML Schema ist ein Dokument das die erlaubte Syntax eines XML Dokuments definiert. Um XML Schema besser zu verstehen, folgt ein kurzes Beispieldokument, dass ein XML Schema für das in Abbildung 2 verwendete XML Dokument sein könnte. Wie schon erwähnt, steht im Prolog des XML Dokuments aus Abbildung 2 «standalone=no» und in der sechsten Zeile wird auf eine Datei «gara- ge.xsd» verwiesen. Dieses bedeutet, das dem XML Dokument ein XML Schema zugeordnet werden kann und das XML Dokument also nur zusammen mit diesem XML Schema gültig sein kann.

In der ersten Zeile in Abbildung 4 steht wiederum der bekannte XML Prolog, da es sich um ein norma-

les XML Dokument handelt. Als Wurzelelement jedes XML Schemas steht das schema-Element, wel-

ches das ganze Schema umschliesst. In ihm werden auch die Namensräume definiert. Die erste Zeile

dient dazu, die im Dokument definierten Elemente (garage, marke, type etc.) einem eigenen Zielna-

mensraum zuzuordnen (engl.: targetNamespace). Zeile zwei importiert die benötigten Elemente um

ein Schema aufzubauen aus dem Namensraum des Schemas der Schemen (z.B. element, complex-

Type, simpleType, restriction, string, integer etc.) und definiert gleichzeitig das Präfix, das benötigt

wird um auf Elemente aus dessen Namensraum zuzugreifen («xsd»). Die nächste Zeile definiert den

Standard-Namensraum für dieses Dokument - in diesem Beispiel den Zielnamensraum.

(14)

2 Datenaustausch mit XML

<?xml version="1.0"?>

<xsd:schema targetNamespace="http://www.e-freak.ch/xml/garage"

xmlns:xsd="http://www.w3.org/2000/10/XMLSchema"

xmlns="http://www.e-freak.ch/xml/garage"

elementFormDefault="qualified">

<xsd:element name="garage">

<xsd:complexType>

<xsd:sequence>

<xsd:element ref="motorrad" minOccurs="0" maxOccurs="unbounded"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="motorrad">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="marke" type="xsd:string"/>

<xsd:element name="typ">

<xsd:complexType>

<xsd:simpleContent>

<xsd:extension base="xsd:string">

<xsd:attribute name="herstellungsjahr" type="xsd:year" use="optional"/>

<xsd:attribute name="zylinder" type="zylinderType" use="required"/>

</xsd:extension>

</xsd:simpleContent>

</xsd:complexType>

</xsd:element>

<xsd:element name="farbe" type="xsd:string"/>

<xsd:element name="option"

type="xsd:string" minOccurs="0" maxOccurs="unbounded"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:simpleType name="zylinderType">

<xsd:restriction base="xsd:integer">

<xsd:minInclusive value="1"/>

<xsd:maxInclusive value="8"/>

</xsd:restriction>

</xsd:simpleType>

</xsd:schema>

Abbildung 4 : Beispieldokument garage.xsd (XML Schema)

Wie schon erwähnt, müssen Elemente aus dem Standard-Namensraum nicht mit einem Präfix qualifi- ziert werden. Die letzte Zeile im schema-Element bedeutet, dass Instanzen die dieses Schema benut - zen, den Namensraum der in «targetNamespace» angegeben ist deklarieren müssen, damit sie die neu definierten Elemente benutzen können. Ausserdem fügt es lokal deklarierte Elemente und Attribu- te zum Zielnamensraum hinzu.

Wie in Abbildung 5 zu sehen ist, definiert das in Abbildung 4 aufgeführte XML Schema einen Baum, der die Struktur der XML Dokumente festlegt, die sich an dieses XML Schema halten. Die Wurzel des Baumes ist das Garagen-Element. Innerhalb dieses Elementes kann es eine unbestimmte Anzahl an

Das Garagen-Element enthält eine Sequenz von Motorrad- Elementen (0 bis unendlich)

Das Typ-Element besteht aus einem komplexen Typ, der lokal definiert ist (eng.

anonymous type):

Inhalt ist ein String (Typ- Bezeichnung) und zwei Attribute (herstellungsjahr und zylinder)

Das Zylinder-Attribut hat einen weiter unten selbst definierten Typ (engl.

named type)

Definition des Types für das Zylinder-Element:

Basistyp: Integer

akzeptiert als Min. 1, Max. 8

minOccurs und maxOccurs

sind standardmässig immer

auf 1 gesetzt.

(15)

2 Datenaustausch mit XML

Motorrad-Elementen haben - keines bis unendlich viele. Ein Motorrad-Element wiederum besteht aus einem Marken-Element, einem Typ-Element, einem Farben-Element und einem oder mehreren, optio- nalen Optionen-Elementen. Unten sind noch die Attribute des Typ-Elements aufgeführt. Jedes Typ- Element muss also ein Zylinder-Attribut haben, das Herstellungsjahr-Attribut ist jedoch optional.

Abbildung 5 : Baumstruktur des Beispielschemas [XMLSPY 01]

2.1.3 DOM und SAX

Um XML Dokumente weiterzuverarbeiten, muss eine einfache, standardisierte Schnittstelle vorhanden sein, um auf die interne Struktur eines XML Dokuments zugreifen zu können. Dazu wurde vom World Wide Web Consortium DOM (Document Object Model) und SAX (Simple API for XML) entworfen.

DOM uns SAX sind plattformunabhängige Schnittstellen die den Zugriff auf XML Dokumente standar- disieren.

Abbildung 6 verdeutlicht das Konzept von DOM. Um mit DOM auf ein XML Dokument zuzugreifen, muss das XML Dokument zuerst geparst werden. Sind keine syntaktischen Fehler vorhanden, wird das XML Dokument gegen das XML Schema validiert. Ist das XML Dokument korrekt, wird das Do- kument auf eine Baumstruktur (siehe Abbildung 5) abgebildet. DOM definiert nun verschiedene Me- thoden, mit denen man diesen Baum komfortabel bearbeiten kann. Es besteht die Möglichkeit, den

«ta

Abbildung 6 : Konzeption von DOM (Document Object Model)

<tag></tag>

...

beispiel.xml

DOM Parser

DOM Baum

A P I

Programme

(16)

2 Datenaustausch mit XML

Baum zu ändern, im Baum zu suchen, Elemente (Blätter des Baumes) zu ändern, löschen und hinzu- fügen etc. Eine genaue Beschreibung des Standards findet man in [W3CD 01] oder in [Morrison 00].

Obwohl DOM noch als junger Standard bezeichnet werden kann, finden sich eine Menge verschiede- ner Implementation. Eine der bekanntesten, weil auch schon früh verfügbaren DOM Implementationen ist die Microsoft DOM Engine. Dadurch ist auch der Microsoft Internet Explorer (ab Version 5) der einzige verbreitete Browser mit einer DOM Anbindung. Nach [Morrison 00] ist die MS DOM Engine recht gut implementiert, hat aber ein paar nicht dem Standard entsprechende Ausnahmen. IBM hat auch eine eigene DOM Implementation (in Java oder C). Viele Programmiersprachen bringen aber heute schon ihre eigene DOM Implementation mit, oder mindestens eine Schnittstelle zu einer frei verfügbaren DOM Implementation. Unter anderem Java, C++, VisualBasic, ASP, PHP, Perl, etc.

Einen etwas anderen Weg um XML Dokumente weiterzuverarbeiten ist SAX (Simple API for XML, API

= Application Programming Interface (deutsch: Programmierschnittstelle). SAX ist kein Standard des

World Wide Web Consortiums, sondern ein sog. De-facto-Standard. Wie der Name schon sagt, ist

SAX nicht so komplex wie DOM. Allerdings kann man SAX nur begrenzt einsetzen. Ein SAX Parser

kann nur Daten aus XML Dokumenten auslesen, nicht aber die Struktur verändern. Dadurch ist ein

SAX Parser schnell, flexibel und leichter zu implementieren und zu benutzen. SAX ist im Gegensatz

zu DOM ereignisbasiert (engl.: event-based). Beim parsen eines XML Dokuments werden beim An-

treffen eines bestimmten Elements (Anfangs-Tag, End-Tag, etc.) die Daten an die Anwendung weiter-

geleitet und dort verarbeitet. Verfügbare SAX Implementationen gibt es zur Zeit für Java, Python, Perl

und PHP.

(17)

2 Datenaustausch mit XML

DOM (Document Object Model):

Ÿ für komplexe Dokumente

Ÿ für Dokumente die von verschiedenen Datenquellen stammen Ÿ bildet eine Baumstruktur des Dokumentes

Ÿ für Dokumente die komplexe Bearbeitung benötigen Ÿ objektbasiert

Ÿ freier Zugriff (engl.: random-access) auf die Elemente eines Dokuments Ÿ Lese- und Schreibzugriff möglich

SAX (Simple API for XML):

Ÿ für einfache Dokumente

Ÿ für grosse Dokumente (physikalische Dateigrösse) Ÿ Ereignisbasierte Programmierung

Ÿ für Dokumente die keine Änderung der Dokumentenstruktur benötigen Ÿ sequentieller Zugriff auf die Elemente eines Dokuments

Ÿ nur Lesezugriff möglich

Abbildung 7 : Gegenüberstellung von DOM und SAX

Ob DOM oder SAX in einer Anwendung verwendet wird (oder häufig eine Kombination davon), hängt von der Art der Anwendung ab. Abbildung 7 soll dabei helfen, die Entscheidung ob DOM oder SAX verwendet wird zu erleichtern (aus [Vanoirbeek/Aboukhaled 00]).

Das hier aufgeführte Beispiel wurde mit Hilfe von XMLSpy [XMLSPY 01] entworfen und validiert.

XMLSpy ist ein kommerzielles Produkt, das praktisch alle Aspekte rund um XML berücksichtigt und übersichtliches Arbeiten mit XML, XML Schema, DTD's, XSL und weiteren XML Dialekten erlaubt.

2.2 Vor- und Nachteile von XML

Die Bedeutung von XML nimmt immer mehr zu. Der wichtigste Grund dürfte sein, dass es ein offener

und plattformunabhängiger Standard ist. Dies sind auch die grossen Vorteile von XML gegenüber

ähnlichen Lösungen. Ein offener Standard hat aber noch mehr Vorteile: Er ist absolut lizenzfrei und

wird durch immer neue Applikationen und Erweiterungen weltweit weiterentwickelt. Allerdings kann

das auch als Nachteil gewertet werden, da viel Entwicklungswerkzeuge noch nicht fertiggestellt sind

und sich in der Entwicklung befinden. Ein weiterer grosser Vorteil von XML ist, dass ein XML Dok u-

ment ein normales Textdokument darstellt, das ganz einfach weiterverarbeitet werden kann und aus-

serdem noch für einen Menschen lesbar ist (engl.: human-readable). Damit kann eine Information

über längere Zeit ohne Konvertierungsprobleme gespeichert werden und auch in der schnelllebigen

Softwareindustrie (alle paar Jahre eine neuer Standard) bleibt die Aussagekraft eines XML Dokuments

immer gleich. [Bellanet 01]

(18)

2 Datenaustausch mit XML

Weitere Vorteile sind auch die einfache Kommunikationsinfrastruktur. Um XML Dokumente zu ver- schicken kann jedes herkömmliche Netzwerk verwendet werden, wobei hauptsächlich auf HTTP (Hy- pertext Transfer Protocol) über TCP/IP (Transmission Control Protocol / Internet Protocol) zurückge- griffen wird – dem Standard im Internet. Die dabei verwendete Bandbreite ist relativ klein, kann aber durch speziellere Protokolle (vgl. EDI) noch kleiner gehalten werden. Als negativ wird dabei der grosse Overhead von XML angesehen – ein grosser Teil eines XML Dokuments nimmt allein die Tag-Struktur ein, die Daten eher den kleineren Teil. Konkrete Zahlen sind schwer zu bekommen und hängen von dem verwendeten Schema (oder DTD) ab. Dies ist jedoch auf der anderen Seite wieder ein Vorteil: die XML Dokumente sind besser lesbar. Ausserdem kann ein XML Dokument beim Austausch kompri- miert werden um die Bandbreite bei der Übertragung zu schonen.

Als Nachteile sind aufzuführen, dass es nicht immer leicht ist ein passendes XML Schema oder eine DTD zu entwerfen. Auch das gesamte String-Handling (XML Daten sind ja nur Textdateien) in der Entwicklung von XML Applikationen wird als negativ erachtet. Jedoch ist es jedem Entwickler selbst überlassen, welche Programmiersprachen er verwendet um XML Dokumente zu verarbeiten. Es sollte also eine passende Verarbeitungssprache gesucht werden, die die Verarbeitung von Strings gut un- terstützt.

2.3 Alternative Möglichkeiten zum Datenaustausch

Bisher benutzen die meisten Applikationen kein spezielles Format um Daten auszutauschen, da keine Notwendigkeit gesehen wurde, diese Daten anderswo zu benutzen als in eigenen Applikationen die untereinander natürlich das Austauschformat kannten, und somit kein Problem mit der Kodierung und Entkodierung dieser Daten hatten. Durch die heutigen Möglichkeiten der Kommunikation wurde es aber immer interessanter Daten auch mit Geschäftspartnern auszutauschen die nicht die gleichen technischen Voraussetzungen erfüllten. Diese also z.B. eine andere Software einsetzten, eine andere Plattform (Hardware, Betriebssystem), oder auch nur ein anderes Datenbank Management System.

Mit der Zeit wurden für viele Standardapplikationen und Programmiersprachen Schnittstellen und Pro- tokolle geschaffen, mit denen es möglich ist, trotz allem miteinander zu kommunizieren. Dies löst aber noch nicht das Problem des Datenformates.

Eine Lösung verspricht EDI [EDI 01]. Electronic Data Interchange ist eine Lösung für Business-to- Business Kommunikation, entwickelt durch das "EDIFACT Standard Messages Directory" der Verein- ten Nationen (Electronic Data Interchange for Administration, Commerce and Transport) [UNEDI 01].

EDI hat ein paar Fähigkeiten die jetzt auch mit XML möglich wären und wird deshalb auch als

XML/EDI weiterentwickelt. Als Hauptpunkt sind die hohen Kosten zu vermerken die EDI bei der Ein-

führung verursacht. Da EDI hauptsächlich für den betriebswirtschaftlichen und organisatorischen Da-

tenverkehr innerhalb einer Unternehmung oder zwischen einzelnen Unternehmen entwickelt worden

ist, benutzt man häufig ein eigenes VAN (Value Added Network), für welches Benutzungsgebühren

entstehen. Ausserdem muss immer noch die benutzte Datenbank eine EDI-Schnittstelle besitzen, da

man sonst mit weiteren Softwarekosten rechnen muss. [EDIAT 01]

(19)

2 Datenaustausch mit XML

2.4 IDML Schema

Das IDML Schema ist ein speziell entwickeltes XML Schema um Daten über Entwicklungsprojekte zu speichern und auszutauschen. Da dieses Schema noch dauernd geändert wird sind die hier erklärten Sachverhalte mit Vorsicht zu geniessen. Die Grundstruktur wird sich aber nicht mehr gross ändern, da das IDML Schema schon bei Version 0.9 angelangt ist. Die Grundlagen um mit Hilfe von IDML Sche- ma Daten bereitzustellen sollen hier aufgezeigt werden. Das Vermittlungswerkzeug muss sich genau an dieses Schema halten, da die Daten sonst beim weiterverarbeiten nicht validiert werden können und für ungültig erklärt werden müssen.

Es werden mindestens zwei Dateien benötigt:

• idmlInfo.xml Æ die Beschreibung (engl: site description) basiert auf dem «Site Description Schema»

• activities.xml Æ die Daten (engl: activity information) Æ basiert auf dem «Core Activity Sche- ma» und dem «Extended Schema»

Die Beschreibung kann statisch generiert werden, da dieses XML Dokument nur wenige Daten bein- halten muss und erst auf die eigentlichen Projektdaten verweist. Die Beschreibung muss immer im root-Verzeichnis (Oberste Ebene: /) des Webserver stehen, auf dem auch die Daten abgelegt sind (oder zumindest auf dem die Daten auch gezogen werden können). Es beinhaltet die Version des verwendeten IDML Schemas, das Datum der letzten Änderung, eine Kontaktadresse (Email) dessen der sich bei dieser Organisation um die Bereitstellung der IDML Daten kümmert und einen Link auf die Daten selbst (Beispiel siehe Abbildung 8). Dieser Link kann auf eine statische XML Datei ve rweisen

<?xml version="1.0"?>

<idmlInfo>

<idmlVersion>0.9</idmlVersion>

<dataLink>

<dataType>activity</dataType>

<url>http://www.some.org/activities.xml</url>

<format>xml</format>

<updated>2001-01-01</updated>

</dataLink>

<contactEmail>idlmcontact@orgname.org</contactEmail >

</idmlInfo>

</xml>

Abbildung 8 : Site Description Schema: Beispiel von idmlInfo.xml

oder aber auf ein Skript, das die Daten dort dynamisch zur Verfügung stellt. Momentan wird zu Test- zwecken häufig die statische Variante bevorzugt, da die Daten noch nicht dynamisch generiert werden können.

IDML Versionsnummer

URL zu den Aktivitäten, kann auch ein Skript sein. (dyna- misch oder statisch)

Datum des letzten updates

Kontaktadresse des

Datenpflegers

(20)

2 Datenaustausch mit XML

Abbildung 9 : IDML Core Activity Schema (Baum) [XMLSPY 01]

(21)

2 Datenaustausch mit XML

Der Vorteil dieses geteilten Ansatzes ist ganz eindeutig die Möglichkeit eine Standarddatei (idmlIn- fo.xml) zu konsultieren, in der dann steht, wo genau die Daten bezogen werden können und welche Version des IDML Schemas zu verwenden ist. Dadurch ist der Datenteil völlig unabhängig von der Infrastruktur des Servers und dessen Möglichkeiten. Jede auf dem Server verfügbare Schnittstelle kann verwendet werden um die Daten bereitzustellen.

Das IDML Schema besteht aus drei getrennten - aber nicht unabhängigen - Schemas:

• Site Description Schema Æ Beschreibung der angebotenen Informationen

• Core Activity Schema Æ Enthält die Daten (Aktivitäten)

• Extended Schema Æ Erweitertes «Core Activity Schema»

Wie schon erwähnt wir das «Site Description Schema» nur benötigt um eine Verknüpfung mit den Aktivitäten über eine Standarddatei (gleicher Name und Zugriffspfad) zu gewährleisten. Deshalb ist dieses Schema klein und hat keinen komplizierten Aufbau. Das «Core Activity Schema» beinhaltet die Aktivitäten selbst und ist eine Teilmenge des «Extended Schemas». Der Unterschied der beiden letzt genannten Schemas liegt darin, dass das «Core Activity Schema» alle unbedingt benötigten Daten enthält. Das «Extended Schema» bietet die Möglichkeit noch weitere (nicht unmittelbar benötigte) Informationen zur Verfügung zu stellen. [IDMLDraft 01]

Eine Übersicht über die Elemente des «Core Activity Schema» bietet Abbildung 9. Allerdings sind in dieser Abbildung nur die Elemente aufgeführt und keine Attribute. Die einzelnen «activities» sind un- tereinander aufgelistet (Sequenz) und jede «activity» selbst beinhaltet weiterführende Informationen.

Abbildung 10 zeigt ein Beispiel einer gültigen XML Datei im «Core Activity Schema»-Format. Um das Beispiel zu verkürzen enthält diese Datei nur eine Aktivität. Diese muss durch einen eindeutigen Schlüssel (dbkey) gekennzeichnet sein und sollte mit dem Datum der letzten Änderung versehen sein um alle Aktivitäten garantiert unterscheiden zu können. Jede weitere Referenz auf diese Aktivität muss dann diesen Schlüssel benutzen. Mit Ausnahme des Datums, der URL und des Schlüssels sind die Formate der eingegebenen Daten nicht vorgegeben (jeder Text ist erlaubt).

Damit in diesem offenen System aber die kein Chaos entsteht, da jede Organisation z.B. im «locati- on»-Element ihre eigenen Länderkürzel verwendet, werden von der AIDA [AIDAAuth 02] sogenannte

«Authority»-Dateien zur Verfügung gestellt welche nichts anderes als Tabellen mit gültigen Werten für bestimmte Elemente sind. Somit wird gewährleistet, dass die Daten konsistent und für die automati- sche Weiterverarbeitung verständlich bleiben.

Auch an Mehrsprachigkeit wurde gedacht und es ist bei den meisten beschreibenden Elementen mög-

lich ein «lang»-Attribut hinzuzufügen. Im angegebenen Beispiel kommt das «sector»-Element zwei-

fach vor: einmal in englisch (en) und einmal in französisch (fr).

(22)

2 Datenaustausch mit XML

<?xml version="1.0" encoding="ISO-8859-1"?>

<activities>

<activity dbKey="1-0-745001" date="1996-02-09">

<ID>

<assigningOrg refKey="OECD DAC"/>

<uniqID>1-0-745001</uniqID>

</ID>

<title lang="en">AGRICULTURAL WATER RESOURCES</title>

<location locationCode ="CUB"/>

<startDate>0</startDate>

<status statusCode="6"/>

<sector lang="en">AGRICULTURAL WATER RESOURCES</sector>

<sector lang="fr">Ressources en eau à usage agricole</sector>

<notes>IRRIGATION PUMPS</notes>

<funding>

<fundingOrg>XAUT</fundingOrg>

<yearly>

<yearStarting date="1974-01-01"/>

<amount amount="3745338.4" currency="usd"/>

</yearly>

<termsAssist terms="2"/>

<total amount="3745338.4" currency="usd"/>

</funding>

<relatedLink >

<label>OECD DAC Creditor Reporting System </label>

<url>http://www.oecd.org/dac/htm/crs.htm</url>

</relatedLink>

<forMoreInfo >gateway.contact@oecd.org</forMoreInfo>

</activity>

</activities>

Abbildung 10 : Core Activity Schema: Beispiel von activities.xml

Da solche Projektdaten auch zwischen verschiedenen Stakeholdern ausgetauscht werden können ist es wichtig verfolgen zu können, welche Organisation welche Änderungen an den Daten vornimmt.

Das «Extended Schema» erlaubt es zusätzliche Informationen hinzuzufügen, welche die Herkunft der enthaltenen Daten genau verfolgen lassen (welche Information wurde wo von wem hinzugefügt oder geändert (engl.: audit trail)). Diese Informationen sind für Daten-Aggregatoren (engl.: data aggrega- tors) allerdings auch zwingend anzugeben. Ausserdem erweitert das «Extended Schema» einige Elemente dahingehend, dass diese auch ausserhalb einer «activity» Gültigkeit besitzen und als ei- genständige Elemente bestehen können.

In Abbildung 11 ist schematisch die Standardprozedur aufgezeigt, die angewendet wird um die IDML

Daten auszutauschen. Es sind zwei HTTP (Hypertext Transfer Protocol) Anfragen an den Webserver

nötig. In der Standardprozedur wird angenommen, dass entweder die Datenbank als Resultat XML

Daten liefert oder aber der Webserver die Daten vor der Endauslieferung konvertiert.

(23)

2 Datenaustausch mit XML

2.5 Client/Server- oder Dreischichtenarchitektur

Wie schon erwähnt, erfolgt der Dokumentenaustausch durch zwei HTTP Anfragen. Das Vermittlungs- werkzeug sollte sich in eine solche Architektur gut einfügen lassen und nicht zuviel Mehraufwand ver- langen. Dies wird wie in Abbildung 12 dargestellt mit einem einfachen Umleiten der zweiten HTTP Anfrage erreicht. Diese wird jetzt nicht mehr an den Webserver geschickt, sondern direkt auf einen 2.

Rechner, der dann die Abfrage der Datenbank und die Konvertierung in XML übernimmt und somit den Webserver entlastet.

Internet Webserver

(3) (6) (4) (1)

(5)

(1) HTTP Anfrage (GET /IdmlInfo.xml) (2) HTTP Resultat => IdmlInfo.xml

(3) HTTP Anfrage (GET /<link_to_idml> [und event. weitere Daten: Query]) (4) SQL Anfrage(n)

(5) DB Resultat

- wenn XML (XML-DB, XML-enabled-DB) => weiter

- wenn SQL Resultat, dann Konvertierung in XML (meist Skriptsprache) (6) HTTP Antwort (IDML XML)

(2)

START

END Data

Data Data

Abbildung 11 : IDML Datenaustausch (Standardprozedur)

Natürlich kann das Vermittlungswerkzeug auch auf dem selben Rechner laufen, und muss nicht phy- sikalisch vom Webserver getrennt sein. Dies kann je nach Hard- und Softwareausstattung aber durch- aus sinnvoll sein und muss für jeden Einsatzort einzeln abgeklärt werden.

Die Umleitung der zweiten HTTP Anfrage kann wie in Kapitel 2.4 erklärt einfach durch ersetzen des url-Eintrages in der "IdmlInfo.xml" Datei erzwungen werden.

Diese Änderung der Architektur bringt aber keinen Mehraufwand (engl.: overhead) beim Transport und der Abfrage der Daten.

Durch das Einfügen einer weiteren Abstraktionsebene (Vermittlungswerkzeug), ändert die traditionelle Client/Server Architektur in eine Dreischichtenarchitektur (Vergleiche Abbildung 11 und Abbildung 12).

Anstelle einer Standardabfrage von der Applikation direkt auf die Datenbank wird die Abfrage von

einer Middleware (Vermittlungswerkzeug) verarbeitet, die die Logik beinhaltet um das Resultat der

Datenbankabfrage in eine für die Applikation verständliche Form zu bringen.

(24)

2 Datenaustausch mit XML

Internet

Webserver (3)

(6) (1)

(4) (5)

(1) HTTP Anfrage (GET /IdmlInfo.xml) (2) HTTP Resultat => IdmlInfo.xml

(3) HTTP Anfrage (GET /<link_to_idml> [und event. weitere Daten: Query]) (4) SQL Anfrage(n)

- Generiert aus der Konfigurationsdatei (5) DB Resultat (SQL Resultat)

- Konvertierung nach den definierten Regeln (Konfigurationsdatei) (6) HTTP Antwort (IDML XML)

(2)

START

END

Vermittlungswerkzeug Data

Data Data

Abbildung 12 : IDML Datenaustausch (mit Vermittlungswerkzeug)

(25)

3 Datenbanken

3.1 Grundlegende Anforderungen

In unserem Falle sind die grundlegenden Anforderungen an die Datenbanken nicht sehr gross. Wich- tig ist vor allem, dass das Vermittlungswerkzeug mit einer Vielzahl von Datenbanken zuverlässig ar- beiten kann, da ja im Voraus nicht bekannt ist, wo welche Datenbank verwendet wird. Heute bieten viele Programmiersprachen eine grosse Fülle an verschiedenen Schnittstellen. Allen gemeinsam ist dabei, dass nur relationale Datenbanken unterstützt werden. Diese Einschränkung ist aber nicht weiter wichtig, da eigentlich alle heute verwendeten Datenbank Management Systeme (DBMS) relational DBMS sind. Die wichtigsten sind wohl ODBC und JDBC.

Die Architektur beider Schnittstellen wurden aus der SQL Call Level Interface (CLI) Spezifikation von der Open Group abgeleitet [SCLS 01]. Diese Spezifikation regelt wie man standardisiert mittels SQL auf eine Vielzahl von Datenbanken zugreifen kann und bildet somit eine Abstraktionsschicht zwischen den Programmiersprachen und den Datenbanken. Diese werden im Folgenden Abschnitt genauer erläutert. Weiterhin wird im zweiten und dritten Teil auf die Konvertierung der Daten von einer Daten- bank in XML und umgekehrt eingegangen.

3.2 Schnittstellen

ODBC (Open Database Connectivity) wurde von Microsoft entwickelt und etablierte sich schnell als De-facto-Standard, da von Anfang an eine Menge Datenbanksysteme unterstützt wurden. Die gute Treiberversorgung und Marktabdeckung von ODBC ist der grösste Vorteil. Ein Nachteil ist, dass der Treibermanager und die Treiber bei jedem Client installiert werden müssen.

JDBC (Java Database Connectivity) wurde etwas später - mit der Notwendigkeit einer Datenbank- schnittstelle für Java – umgesetzt. Die Architektur wurde im Grossen und Ganzen von ODBC über- nommen, allerdings wurde JDBC natürlich objektorientiert entwickelt. ODBC dagegen in C. Einer der Unterschiede beider Schnittstellen ist z.B., dass JDBC als Resultat ein Resultat-Objekt liefert, wohin- gegen ODBC nur einen Pointer zurückgibt. Vor allem in Blickpunkt für eine Migration wurde für JDBC auch eine JDBC-ODBC Bridge entwickelt die es ermöglicht vorhandene ODBC Treiber weiter zu ver- wenden. Wenn also eine Datenbank keine JDBC Schnittstelle hat, kann man mit der JDBC-ODBC Bridge trotzdem mit dieser Datenbank arbeiten.

Wie schon erwähnt ist die Architektur bei beiden Schnittstellen (ungefähr) die gleiche. Ein Treiberma-

nager kümmert sich um die Verbindungen und deren Verwaltung. Der Datenbanktreiber selbst küm-

mert sich dann um die (herstellerabhängige) Kommunikation mit der Datenbank und liefert auf Anfra-

gen das Resultat.

(26)

3 Datenbanken

3.3 Beziehung zwischen Datenbanken und XML

Das Vermittlungswerkzeug wird ja eine Verbindung zwischen einer Datenbank und einem XML Doku- ment herstellen. Wie in Abschnitt 1.1 auf Seite 1 erwähnt, gibt es folgende drei grundlegenden Szena- rien:

1. Es ist keine Datenbank vorhanden (Die XML Daten werden in einer neu angelegten Daten- bank gespeichert.)

2. Es ist kein XML Schema vorhanden (Die Daten aus der Datenbank werden in einem neu ge- nerierten XML Format ausgegeben.)

3. Datenbank und Schema sind vorhanden, aber die Abbildung in beide Richtungen ist noch nicht erledigt.)

Das erste Szenario ist interessant wenn man daran interessiert ist XML Daten von anderen Stakehol- dern in einer eigenen Datenbank zu speichern. Dies ist im Falle von IDML nicht das Hauptinteresse, da dort ja keine zentrale Datenbank verwendet wird und die Daten ja auch immer auf dem aktuellen Stand gehalten werden müssen. Es ist aber nicht auszuschliessen, dass andere Anwendungen auf dieses Problem stossen.

Auch das zweite Szenario ist nicht sehr häufig zu finden, da die Daten meist in einem fest definierten Format (z.B. einem XML Schema) ausgegeben werden müssen und nicht einfach in einem automa- tisch generierten Format, dass sich an dem Datenbanklayout orientiert.

Richtig interessant wird erst das dritte Szenario, in welchem die Daten nach festen Regeln abgebildet werden müssen, da ja die Datenbank und das Ausgabeformat (XML Schema) fixiert sind. Hierzu gibt es aber keine automatischen Konvertierungen und somit muss hier von Hand eine Abbildung vorge- nommen werden, die dann aber automatisch wiederholt werden kann.

Um ein XML Dokument, das einem XML Schema genügt, also ein gültiges (engl.: valid) XML Dok u- ment darstellt, in einer noch nicht vorhandenen Datenbank zu speichern, muss man erst einmal die Strukturen des verwendeten XML Dokuments kennen.

XML Dokumente kann man in zwei Lager einteilen. Erstens sind dies Daten-zentrische (engl.: data-

centric) Dokumente die vereinfacht einen Datencontainer darstellen. Zweitens sind dies Dokumenten-

zentrische Dokumente, welche hauptsächlich für den Menschen lesbar sein sollten. Es ist nicht immer

einfach zwischen diesen Kategorien zu unterscheiden, das es viele Dokumente gibt, die Merkmale

beider Kategorien vereinen. Als Faustregel wird aber vorgeschlagen, dass man Daten-zentrische Do-

kumente in einer normalen (relationalen) Datenbank abspeichert und Dokumenten-zentrische Doku-

mente in einer nativen XML Datenbank um die Vorteile von XML nicht zu verlieren. Ausserdem ist es

nicht ganz trivial Dokumenten-zentrische Daten in einer relationalen Datenbank zu speichern.

(27)

3 Datenbanken

Im Folgenden werden nun diese drei Szenarien genauer untersucht, damit im darauf folgenden Schritt das Modell festgelegt werden kann und der theoretische Hintergrund für die Implementation schon gegeben ist. Welche dieser drei Szenarien schliesslich verwendet wird ist noch nicht genau abgeklärt. Das primäre Ziel – Projektdaten über das World Wide Web in IDML zur Verfügung zu stel- len – bedeutet allerdings, dass zumindest eine Abbildung von der Datenbank in XML (IDML Schema) erfolgen muss. Da diese Szenarien sich teilweise in der Theorie überschneiden werden im nächsten Abschnitt zuerst die verschiedenen Mapping-Methoden genauer untersucht. Weitere Bedürfnisse wer- den in einem späteren Teil abgeklärt.

3.4 Mapping

Es gibt zwei unterschiedliche Ansätze um ein Mapping vorzunehmen. Die erste ist das Vorlagen- gesteuerte (engl.: template-driven) Mapping und die zweite das Modell-gesteuerte (engl.: model- driven) Mapping. Das Vorlagen-gesteuerte Mapping wird vorzugsweise für die Abbildung von der Da- tenbank in ein XML Dokument verwendet, kann aber auch für den umgekehrten Weg benutzt werden.

Beim Modell-gesteuerten Mapping gibt es zwei Ansätze: Tabellen-basiertes (engl.: table-based) und Objekt-relationales (engl. object-relational) Mapping. Das Tabellen-basierte Mapping ist der einfachste Fall, kann aber nur angewendet werden, wenn die Daten in einem festegelegten Format vorliegen. So wird es vorzugsweise für die Serialisierung von Daten aus einer Datenbank verwendet. Das Objekt- relationale Mapping ist immer anwendbar, aber auch komplizierter zu verwenden. Dabei werden die Daten in einem XML Dokument als Baumstruktur aus Objekten beschrieben. Diese Struktur ist aber nicht zu verwechseln mit einem DOM-Baum. Die Baumstruktur kann für jedes Dokument unterschied- lich sein. Die einzelnen Objekte werden als Klassen modelliert uns somit entsteht ein objekt-

orientiertes Modell. Dieses Modell wird anschliessend auf die Datenbank abgebildet. [Bourret 02]

3.4.1 Tabellen-basiertes Mapping

Tabellen-basiertes Mapping kann nur auf wenige XML Schemas angewendet werden, da eine be- stimmte Struktur vorausgesetzt wird. Häufig wird Tabellen-basiertes Mapping verwendet um das Re- sultat einer Abfrage an eine relationale Datenbank in XML umzuwandeln oder um Daten zwischen zwei relationalen Datenbanken auszutauschen. Der Aufbau beim Tabellen-basierten Mapping ist sehr einfach. Das XML Dokument bildet einfach die Tabellenstruktur der Datenbank ab (siehe Abbildung 13).

Diese Operation kann ohne Mehraufwand in beide Richtungen durchgeführt werden. Da in den meis-

ten Fällen das XML Dokument aber keine solche Struktur aufweist, wird von einer genaueren Unter-

suchung abgesehen. Sollte diese Funktionalität dennoch in diesem Projekt verwendet werden ist es

dank des einfachen Aufbaus kein Problem einen solchen Datenimport bzw. –export dennoch zu imp-

lementieren, da nur eine Seite angepasst werden muss (die andere ist fixiert).

(28)

3 Datenbanken

<?xml version="1.0"?>

<database>

<tables>

<table_1>

<row>

<column_1 >...</column_1>

</row>

</table_1>

<table_2>

...

</table_2>

</tables>

</database>

Abbildung 13 : Beispiel für Tabellen-basiertes Mapping [Bourret 02]

3.4.2 Vorlagen-gesteuertes Mapping

Vorlagen-gesteuertes Mapping wird vorwiegend benutzt um Daten aus Datenbanken in ein XML For- mat zu konvertieren. Dabei werden SQL Statements in eine XML Vorlage eingebettet, die dann von der verarbeitenden Middleware ausgeführt und in den angegeben Stellen in der XML Datei eingefügt (substituiert) werden. Diese Variante eignet sich auch sehr gut für den IDML-Export, da kein komple- xes objekt-rationales Mapping ausgeführt werden muss und alle anderen Voraussetzungen zur Genü- ge erfüllt werden. Es ist in der Verarbeitung ähnlich dem Tabellen-basierten Mapping mit dem grossen Unterschied, dass der Output sehr flexibel angepasst werden kann. Abbildung 14 zeigt ein Beispiel für Vorlagen-gesteuertes Mapping. Dieses Beispiel zeigt nur die Idee die dahintersteckt und eine

Implementation kann davon abweichen.

<?xml version="1.0"?>

<garage>

<select> SELECT marke, jahr, zylinder, typ, farbe FROM bikes</select>

<motorrad>

<marke>$marke</marke>

<typ herstellungsjahr="$jahr" zylinder="$zylinder">$typ</typ>

<farbe>$farbe</farbe>

</motorrad>

</garage>

Abbildung 14 : Beispiel für Vorlagen-gesteuertes Mapping

3.4.3 Objekt-relationales Mapping

Objekt-relationales Mapping wird in zwei Schritten ausgeführt. XML Schemas werden über ein Objekt- Schema in ein relationales Schema abgebildet. Die umgekehrte Richtung ist auch möglich, wird aber nicht weiter berücksichtigt, da in den meisten Fällen ein XML Schema schon vorhanden ist. Damit ist das zweite Szenario (siehe oben) aber nicht ausgeschlossen, da in einem solchen Fall für die Seriali- sierung der Daten ein einfacher Export mit Tabellen-basiertem Mapping gewählt werden kann.

database

row

column table

substituiert

(29)

3 Datenbanken

Ein XML Dokument wird erst in ein Objekt-Schema abgebildet, welches wiederum in Datenbank- Tabellen gemappt werden kann. Abbildung 15 zeigt das Objekt-Schema für das Beispiel-Dokument aus Abbildung 2.

objekt garage { objekt motorrad { objekt typ {

motorrad = Æmotorrad marke = "Yamaha", typ = "XT 550",

} typ = Ætyp, herst.jahr = "1984",

farbe = "schwarz", zylinder = "1"

option = "" }

}

Abbildung 15 : XML Dokument aus Abbildung 2 als Objekt-Schema

Da dieses Objekt-Schema nun alle benötigten Informationen enthält, kann es auf Datenbank-Tabellen abgebildet werden. Aus jedem Objekt wird eine Tabelle und die Eigenschaften ergeben die benötigten Spalten. Im Beispiel aus Abbildung 15 werden also drei Tabellen benötigt.

Dieses Mapping kann jetzt auch auf XML Schemas (nicht auf einzelne XML Dokumente) oder DTD's angewendet werden. Dabei werden die verschiedenen XML Schema-Komponenten (Sequenz, Aus- wahl, etc.) nach bestimmten Regeln in Klassen abgebildet (Details folgen weiter unten).

Den ersten Schritt – vom XML Schema zum Objekt-Schema – nennt man auch XML Daten-Bindung (engl.: XML data binding). Wie schon erwähnt, haben Objekt-Schemas zwar auch eine Baumstruktur, sind aber grundlegend anders ausgelegt als DOM-Bäume. DOM-Bäume modellieren das Dokument und ein Objekt-Schema (oder Objekt-Baum) modelliert die Daten in dem Dokument. Abbildung 16 erklärt anhand eines Beispiels den Unterschied zwischen einem Objekt-Baum und einem DOM-Baum.

Für ein bestimmtes XML Schema haben alle davon abgeleiteten XML Dokumente den gleichen DOM- Baum. Objekt-Schemas dagegen sind bei jedem XML Dokument unterschiedlich.

Das Objekt-Schema lässt sich leicht nachvollziehen, wenn man das XML Dokument durchliest und seine Struktur betrachtet. Als Resultat erhält man einen einfachen Baum, der die Struktur der Aus- zeichnungselemente (engl.: tags) aufzeigt. Der DOM-Baum hingegen modelliert einen anderen Baum, der jedoch für alle Instanzen eines XML Schemas gleich ist. Dieser Baum stellt die Struktur des XML Dokumentes anhand der XML Elemente dar. Die Knoten des Baumes sind Elemente oder Attribute, welche wiederum Text beinhalten (die Daten). Die Wurzel eines DOM-Baumes ist immer das Doku- ment. Objekt-Schemas werden aber normalerweise nicht als Baum gezeichnet, sondern in einer abs- trahierten – an Klassen (für Java-Programmierer) oder Strukturen (für C-Programmierer) erinnernde – Schreibweise (siehe Abbildung 15).

Eine zweite Darstellungsmöglichkeit für Objekt-Schemas ist eine Klassenhierarchie, welche dann auf eine relationale Datenbank abgebildet werden kann. Die Klassen haben verschiedene Eigenschaften, aber keine Methoden. Die Eigenschaften selbst können weiter eingeschränkt werden. Beispielsweise

Legende:

Æ = Zeiger auf Objekt

(30)

3 Datenbanken

kann eine Eigenschaft mehrfach vorkommen oder auch das NULL-Element beinhalten (im Beispiel die Auszeichnungselemente «motorrad», «option» und «herstellungsjahr»).

Legende:

[] = Array (1 und mehr)

∅ = Nullable (Null oder 1)

Objekt-Baum DOM-Baum Klassenhierarchie

Abbildung 16 : XML Dokument aus Abbildung 2 als Objekt-Baum, DOM-Baum und Klas- senhierarchie

garage

motorrad

marke

typ

farbe

option

klasse: garage

§ motorrad [] ∅

klasse: motorrad

§ marke

§ typ

§ farbe

§ option [] ∅

klasse: typ

§ typ

§ herstellungsjahr ∅

§ zylinder Dokument

Element

Text

Attribut Attribut

Text

(31)

4 Erstellung eines Modells

In diesem Kapitel werden alle vorangegangen Konzepte vereint um schliesslich das zu implementie- rende Modell zu erhalten. Dabei wird abgewägt, welchen Anforderungen das Modell standhalten soll, wie es konkret aussieht, welche Benutzerschnittstelle gewählt wird und mit welcher Software das Mo- dell anschliessend implementiert werden soll.

4.1 Anforderungen an das Modell

Was in den vorangegangenen Kapiteln schon ausformuliert wurde soll hier noch zusammengefasst werden um den Gesamtkatalog an Anforderungen zu erstellen. Gefordert wird ein Werkzeug welches sich in viele Architekturen einfach einbetten lässt und welches mit möglichst vielen verschiedenen Datenbanken zusammenarbeiten kann. Dies setzt eine offenen Architektur voraus. Da das Werkzeug frei zur Verfügung stehen soll muss ausserdem eine Architektur und Sprache gewählt werden, die ohne Lizenzgebühren und sonstigen Abgaben eingesetzt werden kann.

Das Werkzeug muss sich an die verwendeten Spezifikationen sehr genau halten (XML, XML Sche- ma). Es sollte bei der Anwendung möglichst einfach zu bedienen sein und praktisch wartungsfrei sei- nen Dienst erfüllen. Als Minimalanforderung wird vorausgesetzt, dass das Werkzeug XML Daten aus der eigenen Datenbank auslesen und in das IDML Format konvertieren kann.

Das Werkzeug muss drei verschiedene Aufgaben erledigen:

1. Eine grafische Oberfläche für das Mapping bereitstellen.

2. Mit vielen verschiedenen relationalen Datenbanken kommunizieren.

3. Einen Service bereitstellen, um die generierten Daten abzurufen.

Durch die sehr unterschiedliche Aufgabenstellung (Desktop-Applikation und Serverkomponente) stellt sich auch die Frage ob nicht zwei einfachere Werkzeuge diese Arbeit besser erledigen könnten. Eine Aufteilung vermindert die Komplexität beider Anwendungen.

4.2 Konstruktion des Modells

Das Werkzeug muss die oben genannten Anforderungen erfüllen. Abbildung 12 zeigt noch mal genau die Situation in der Übersicht. Durch eine Aufteilung in zwei oder drei Komponenten wird die Applikati- on besser wartbar und die Serverkomponente wird nicht unnötig aufgebläht. Allerdings findet noch eine Kommunikation zwischen dem Server und dem Konfigurationswerkzeug statt. Dies ist aber mit einer Konfigurationsdatei schnell erledigt. Eine mögliche dritte Komponente – ein Überwachungswerk- zeug – muss auch mit der Serverkomponente kommunizieren können. Hier reichen jedoch drei oder vier Befehle (Start, Stopp, Reload und Status).

Dabei kann man noch einmal von XML profitieren. Da die Serverkomponente sowieso mit XML umge-