| |
| |
| Webapplikationen mit Unterstützung von XML | |
| |
| Navigation: | Inhalt -> 2 Grundlagen und Voraussetzungen -> 2.2 Einführung in XML | Neues und Änderungen << Vorheriges Kapitel | Nächstes Kapitel >> |
| 2.2 | Einführung in XML |
In diesem Kapitel soll ein kurzer Überblick über XML und den dazugehörenden Standards gegeben werden. Für eine detailliertere Einführung wird auf einschlägige Literatur verwiesen.
| 2.2.1 | XML - Extensible Markup Language |
Wie bereits im Kapitel 2.1.2 Von GML zu XML beschrieben, ist eine XML-Datei ein für den Menschen lesbares Textdokument, in dem Teile durch Markup ausgezeichnet und somit besonders gekennzeichnet sind. Der Markup besteht aus Elementen, die hierarchisch - also in einer Baumstruktur angeordnet sind. Elemente können zusätzlich Attribute enthalten. Die Elemente und Attribute können dabei frei gewählt werden. Diesen Umstand verdankt XML auch das "Extensible" im Namen. Welche weiteren Merkmale sind typisch für ein XML-Dokument?
Wohlgeformt
Ein XML-Dokument ist "wohlgeformt" ("well-formed"), wenn dessen Syntax der XML-Spezifikation des W3C entspricht. Insbesondere gibt es einige markante Unterschiede zum HTML-Syntax:
Die Wohlgeformtheit eines XML-Dokuments wird mit einem XML-Parser überprüft. Neben dieser Überprüfung dienen XML-Parser hauptsächlich dazu, XML-Quelldokument einzulesen und zur Weiterverarbeitung für andere Programme vorzubereiten. Einen Überblick über die verfügbaren XML-Parser findet man unter www.xml.com/pub/rg/XML_Parsers oder unter www.xmlsoftware.com/parsers.html. Die bekannteren sind XP von James Clark, einer der ersten Parser, Expat, dessen erste Versionen ebenfalls von James Clark entwickelt wurden, und Xerces vom Apache XML Project (xml.apache.org/).
Prolog und Dokumenttyp-Deklaration
Üblicherweise sollte ein XML-Dokument mit einer XML-Deklaration beginnen. In dieser werden meist die XML-Version und die verwendete Kodierung als Attribute angegeben. Als Versionsnummer ist zur Zeit nur 1.0 erlaubt. [W3C-XML 2000] Wenn es später eine neue XML-Version gibt, dann können hiermit die einzelnen Versionen unterschieden werden, wodurch die Abwärtskompatibilität gewährleistet ist. XML erlaubt die Verwendung von Unicode und verschiedener Zeichensätze. Je nach Zeichensatz können verschiedene Zeichen verwendet werden. Außerdem werden die Zeichen je nach Zeichensatz unterschiedlich kodiert.
<?xml version="1.0" encoding="iso-8859-1"?>Beispiel 5: XML-Deklaration einer XML Datei mit Versionsangabe und ISO-8859-1 Codierung. Das ist der Latin1-Zeichensatz, der für westeuropäische Sprachen optimiert wurde und z.B. die Verwendung von Umlauten erlaubt.
Zu beachten ist, dass ein XML-Dokument auch wohlgeformt sein kann, wenn es keine XML-Deklaration enthält. Beispiel 6 ist ein typisches wohlgeformtes XML-Dokument mit XML-Deklaration. Hier sieht man auch, wie Kommentare eingefügt werden. Sie werden wie in HTML durch "<!-- Kommentartext -->" markiert.
<?xml version="1.0" encoding="iso-8859-1"?>
<Appendix>
<Caption>Anhang</Caption>
<!-- Bibliography -->
<AppendixEntry>
<Caption>Literaturverzeichnis</Caption>
<Bibliography>
<Entry>
<ID>Berners-Lee 2000</ID>
<Author>
<person:FirstName>Tim</person:FirstName>
<person:LastName>Berners-Lee</person:LastName>
</Author>
<Title>Weaving The Web</Title>
<Subtitle>
The Original Design and Ultimate Destiny of the World Wide Web
</Subtitle>
<City>New York</City>
<Date>2000</Date>
</Entry>
</Bibliography>
</AppendixEntry>
<!-- Acronyms -->
<AppendixEntry>
<Caption>Verzeichnis der Akronyme</Caption>
<AcronymIndex>
<Entry>
<ID>HTML</ID>
<Acronym>HTML</Acronym>
<Name>Hypertext Markup Language</Name>
<Description>
Markup Sprache, die verwendet wird, um Webseiten zu kodieren.
HTML ist eine vereinfachte Untermenge von
<Acronym ID="SGML">SGML</Acronym>.
Die aktuelle Version des
<Acronym ID="W3C">W3C</Acronym> ist
HTML 4.0 und wurde am 18.12.1997 als W3C-Empfehlung
verabschiedet.
</Description>
</Entry>
</AcronymIndex>
</AppendixEntry>
</Appendix>Beispiel 6:
Wohlgeformtes XML-Dokument. Es ist ein (gekürzter) Teil des
Quelldokuments des Anhangs dieser Arbeit.
| 2.2.2 | DTD - Document Type Definition |
Wenn man nicht nur mit einem XML-Dokument arbeiten will, sondern mehrere ähnliche Dokumente hat, wie beispielsweise mehrere Rechnungen, dann wäre es sinnvoll, einen eigenen XML-Dokumenttyp für diese Art von Dokumenten zu definieren. Für diesen Zweck gibt es die Dokumenttyp Definition (DTD, Document Type Definition). In einer DTD werden die Datentypen der Elemente und Attribute, die im XML-Dokument dieses Typs vorkommen dürfen, und deren hierarchische Struktur genau definiert. Die DTD kann in einer eigenen Datei ausgelagert sein, die im XML-Dokument angegeben wird, oder einfach in das XML-Dokument integriert werden. Im Folgenden ein Beispiel einer DTD in einer eigenen Datei:
<!ELEMENT Work (WorkTitle, Author+, Professor, New*, Chapter+)> <!ATTLIST Work LastModified CDATA #REQUIRED > <!ELEMENT WorkTitle (#PCDATA)> <!ELEMENT Author (Title?, FirstName, LastName)> <!ELEMENT Professor (Title?, FirstName, LastName)> <!ELEMENT Title (#PCDATA)> <!ELEMENT FirstName (#PCDATA)> <!ELEMENT LastName (#PCDATA)> <!ELEMENT Chapter (Name, New?, Chapter*, Catchwords*)> <!ELEMENT Name (#PCDATA)> <!ELEMENT Catchwords (#PCDATA)> <!ELEMENT New (#PCDATA)> <!ATTLIST New Date CDATA #REQUIRED Url CDATA #IMPLIED >Beispiel 7: Diese DTD wurde für den ersten, einfachen Entwurf des XML-Dokuments entwickelt, das den Quelltext dieser Arbeit enthält. Die DTD hier im Beispiel wurde zur besseren Übersicht etwas gekürzt.
Im Beispiel fällt eines sofort auf: Die Syntax der DTD ist offensichtlich keine XML-Syntax. Das ist auch einer der großen Nachteile einer DTD. XML-Werkzeuge, die DTDs verarbeiten, müssen um die Möglichkeit, DTD-Syntax lesen zu können, erweitert werden.
Gültige XML-Dokumente
Oben wurden bereits wohlgeformte XML-Dokumente besprochen. Solche Dokumente entsprechen der XML-Spezifikation des W3C. Wenn einem XML-Dokument eine DTD zugeordnet ist, kann nicht nur die Wohlgeformtheit überprüft werden, sondern auch, ob das Dokument gültig (engl.: valid) im Sinne der DTD ist. Ein gültiges XML-Dokument entspricht also dem Dokumenttyp, der in der DTD definiert ist. XML-Parser, die auch die Gültigkeit überprüfen können, werden "Validating XML Parser" genannt.
| 2.2.3 | Namensräume |
In XML-Dokumenten kann man selbstdefinierte Elementnamen verwenden. Was ist aber, wenn zwei Elemente mit unterschiedlicher Bedeutung denselben Namen haben? Zum Beispiel ein "Titel" Element als Kind-Element15 eines "Buch" Elements oder das "Titel" Element eines "Person" Elements. Im ersten Fall ist ein Buchtitel gemeint, im letzten ein Titel einer Person. Solange das XML-Dokument für sich alleine steht, ist das kein Problem. Wenn ein solches Dokument allerdings bearbeitet werden soll, kann es problematisch werden. Wenn zum Beispiel nur alle Buchtitel aus einem Dokument extrahiert werden sollten.
Wirklich problematisch wird es allerdings, wenn man für so ein Dokument eine DTD erstellen will. In einer DTD kann jedes Element nur einmal definiert werden. Insbesondere, wenn zwei gleichnamige Elemente einen unterschiedlichen Datentyp haben sollten, oder unterschiedliche Kind-Elemente, dann gibt es nur mehr den Ausweg, die Elemente doch unterschiedlich zu benennen. Beispielsweise "Buchtitel" und "PersonenTitel". Das funktioniert aber nur solange die Entwicklung des Dokuments innerhalb eines kleinen Teams erfolgt. Sollten Dokumente über Firmengrenzen hinweg entwickelt werden, oder sollten bereits bestehende Dokumente zusammengefügt werden, dann kann man nur mehr auf Namensräume (engl.: namespaces) bauen.
Bei der Verwendung von Namensräume können einzelne Elemente einem bestimmten Namensraum zugeordnet werden. Jeder Namensraum wird durch eine URI (Uniform Resource Identifier) eindeutig identifiziert. Eine URI ist ein eindeutiger Name für eine bestimmte Ressource (hier: für einen Namensraum) [Anderson et al. 2000, S. 251]. Eine URI kann beispielsweise eine URL sein. Allerdings braucht bei der URI das Protokoll ("http://") nicht angegeben werden und somit auch kein Dokument vorhanden sein, auf das die URI zeigt.
xmlns="www.schmiderer.cc/xmlwebapp" xmlns:person="www.schmiderer.cc/xmlwebapp/person" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"Beispiel 8: Beispiele von URIs, die zur Kennzeichnung von Namensräume dienen.
Fast immer werden bei URIs für XML-Anwendungen Internet-Adressen verwendet. URIs können aber durchaus unterschiedlich aussehen, wie zum Beispiel Telefonnummern beinhalten [W3C-Addressing 2002]. Jedenfalls müssen sie eindeutig sein. Da Internet-Adressen eindeutig sind, ist die Eindeutigkeit hier gewährleistet.
"Default Namespace" und qualifizierte Namen
Gehört ein Element zu einem bestimmten Namensraum, so muss dieser Namensraum auch dem Element zugeordnet werden. Dazu wird dem Element das Attribut "xmlns" hinzugefügt, das als Wert den Namensraum enthält. Der Namensraum gilt dann auch für alle Kind-Elemente dieses Elements. Fügt man das Attribut dem Wurzel-Element zu, dann gilt der Namensraum für das gesamte Dokument.
<Author xmlns="http://www.schmiderer.cc/xmlwebapp/person"> <FirstName>Johannes</FirstName> <LastName>Schmiderer</LastName> </Author>Beispiel 9: Beispiel einer XML-Datei mit einem "default namespace".
Hier wird der Namensraum dem Element "Author" zugeordnet. Die Kind-Elemente "FirstName" und "LastName" erben diesen Namensraum. Diese Art der Namensraumangabe funktioniert, solange nicht Elemente verschiedener Namensräume gemischt auftreten. Kommen Elemente verschiedener Namespaces gemischt vor, dann ist es meist sinnvoller qualifizierte Namen zu verwenden:
<Work xmlns="http://www.schmiderer.cc/xmlwebapp/work"
xmlns:person="http://www.schmiderer.cc/xmlwebapp/person">
<Title>Webapplikationen mit Unterstützung von XML</Title>
<Author>
<person:FirstName>Johannes</person:FirstName>
<person:LastName>Schmiderer</person:LastName>
</Author>
<Chapter>
<Caption>Einleitung</Caption>
<Content>
<Paragraph>
Erster Paragraph Einleitung
</Paragraph>
<Paragraph>
Zweiter Paragraph Einleitung
</Paragraph>
</Content>
</Chapter>
</Work>Beispiel 10:
XML-Datei mit einem "default namespace" und einem
qualifizierten Namen ("person") für einen zweiten Namensraum.
Hier gehören alle Elemente bis auf "FirstName" und "LastName" dem "default namespace" "http://www.schmiderer.cc/xmlwebapp/work" an. "FirstName" und "LastName" gehören zum Namensraum "http://www.schmiderer.cc/xmlwebapp/person". Zum Kennzeichnen dieser Elemente wird der so genannte qualifizierte Name (hier "person") mit einem Doppelpunkt vor dem eigentlichen Elementnamen gestellt. Diese qualifizierten Namen können beliebig gewählt werden. In der Praxis werden oft nur wenig Buchstaben verwendet.
| 2.2.4 | XML-Schema |
Bei der Beschreibung der DTDs wurde schon darauf hingewiesen, dass diese einige Nachteile aufweisen: Sie haben eine eigene Syntax, und es können keine gleichen Elementnamen für zwei Elemente verwendet werden, weil alle Elemente global definiert werden. Weiters unterstützen DTDs keine Namensräume und sie erlauben nur sehr rudimentäre Angaben über den Datentyp eines Elements oder Attributs.
Aus diesem Grund wurden vom W3C die XML-Schemas entwickelt. Die W3C-Empfehlung für die XML-Schemas findet man unter [W3C-Schema 2002]. Die wichtigsten Vorteile von XML-Schemas sind:
Beim Definieren eines Schemas für einen bestimmten XML-Dokumenttypen bestimmt man den Aufbau dieses XML-Dokuments. Neben grundsätzlichen Entscheidungen, ob beispielsweise Daten als Kind-Elemente oder als Attribute definiert werden sollen, gibt es noch eine Menge weiterer Entscheidungen zu treffen. Besonders auch im Zusammenhang mit Namensräumen. Nicht umsonst haben Mitglieder der XML-DEV Mailing-List auf [Costello et al. 2002] unter dem Titel "XML Schemas: Best Practices" die wichtigsten Entwurfsentscheidungsmöglichkeiten gegenübergestellt und die Vor- und Nachteile diskutiert.
| 2.2.5 | DOM und SAX |
Wenn eine Anwendung XML-Dateien verarbeiten soll, greift man auf einen XML-Parser zurück, der die XML-Dateien einliest, sie auf Wohlgeformtheit und eventuell auch auf Gültigkeit überprüft und sie über eine definierte Schnittstelle an die eigene Anwendung weitergibt. Es gibt hier allerdings zwei Vorgehensweisen, die auch die Art der Schnittstelle definieren.
Document Object Model
Die erste Möglichkeit baut auf das Document Object Model (DOM) auf. Hierbei wird eine Baumstruktur aller Elemente, Attribute, Kommentare und weiterer Inhalte des XML-Dokuments im Speicher erstellt. Im Folgenden ein einfaches XML-Dokument und die zugehörige DOM-Abbildung:
<Person Gender="male"> <person:FirstName>Franz</person:FirstName> <person:LastName>Müller</person:LastName> </Person>Beispiel 11: Ein einfaches XML-Dokument.
 |
| Abbildung 1: DOM-Darstellung des XML-Dokuments aus Beispiel 11. |
Die einzelnen Teile des DOM-Baumes werden Knoten genannt. Da der DOM-Baum im Speicher aufgebaut wurde, kann auf die einzelnen Knoten wahlfrei und schnell zugegriffen werden. Dies ist auch der große Vorteil von DOM. Insbesondere, wenn oft auf sehr verschiedene Teile des XML-Dokuments und damit auf verschiedene Knoten des DOM-Baumes zugegriffen werden muss, ist die Verwendung von DOM die erste Wahl.
Allerdings gibt es Probleme mit großen Dokumenten. Diese würden sehr viel Speicher verbrauchen, wodurch sich hier die Verwendung von DOM nicht besonders eignet.
Die DOM-Empfehlung des W3C und die aktuellen Entwicklungen findet man unter [W3C-DOM 2002].
SAX
SAX (Simple API for XML) ist eine ereignisorientierte Schnittstelle für XML-Parser. Wenn ein XML-Parser, der SAX verwendet, ein XML-Dokument einliest, meldet er "Ereignisse" an das Programm, das den XML-Parser verwendet. So ein Ereignis ist beispielsweise der Dokumentstart, ein bestimmtes Element, ein Attribut, usw. Das Programm, das das XML-Dokument mittels SAX-basierten XML-Parser einliest, erhält also Ereignisse, die den Aufbau des XML-Dokuments wiedergeben. Das Programm kann die Ereignisse, die es benötigt, weiterverarbeiten, andere kann es ignorieren.
Der Vorteil ist klar: Mit SAX kann man beliebig große XML-Dokumente einlesen, da immer nur ein kleiner Teil des Dokuments im Speicher sein muss. Allerdings kann mit SAX nicht wahlfrei auf die einzelnen Teile eines XML-Dokuments zugegriffen werden. [Anderson et al. 2000, Kapitel: SAX 1.0 Die Simple API für XML]
Interessant ist, dass SAX nicht vom W3C entwickelt wurde. Es entstand vielmehr aus der Zusammenarbeit von Entwicklern von XML-Parsern und -Anwendungen, die mit den unterschiedlichen Schnittstellen der XML-Parser zu kämpfen hatten. Die offizielle Webseite von SAX findet man unter www.saxproject.org.
| 2.2.6 | CSS und XSL |
Eines der Hauptanliegen von XML ist, die Darstellung von den Daten zu trennen. Das wird dadurch erreicht, dass im XML-Quelldokument nur die Daten gespeichert werden. Für die Darstellung werden eigene Dokumente verwendet, die so genannten Stylesheets.
CSS
Wie bereits im Kapitel 2.1.2 Von GML zu XML angesprochen, kann mit CSS (Cascading Style Sheets) die Darstellung von HTML-, XHTML- oder XML-Dokumenten beeinflusst werden. Allerdings sind die Möglichkeiten von CSS sehr eingeschränkt. Die Baumstruktur des XML-Dokuments bleibt erhalten. Es kann nur jedem Element eine Formatierung zugewiesen werden. Zum Beispiel: Schriftgröße, -art, Zeilenabstand, Rahmen, Farben, etc. So ist es möglich, dem Element "Caption" eine größere Schrift zuzuweisen als den übrigen Elementen.
XSL
Der zweite Weg, XML-Dokumente für die Darstellung aufzubereiten, ist die Verwendung von XSL (Extensible Stylesheet Language). Dessen Möglichkeiten gehen viel weiter als jene von CSS. Mit XSL können XML-Dokumente völlig umstrukturiert werden. XSL besteht aus drei Teilen: XSLT (XSL Transformations), XPath und XSL-FO (XSL Formatting Objects). [W3C-XSL 2002]
XSLT
XSLT ist eine deklarative Programmiersprache, die dazu dient, XML-Dokumente in andere XML-Dokumente, in (X)HTML-Dokumente oder in beliebige Text-Dokumente zu transformieren. Das heißt, dass man ein XML-Dokument mit Hilfe eines XSLT-Stylesheet zum Beispiel in ein HTML-Dokument umwandeln, und somit im World Wide Web darstellen kann. Oder wenn zwei Firmen XML-Daten austauschen wollen, die aber unterschiedlichen Dokumenttyps sind, können sie mit Hilfe von XSLT relativ einfach in das jeweils andere Format transferiert werden.
Die Syntax von XSLT ist selbst XML. Da es eine deklarative Programmiersprache ist, gibt es keine Nebeneffekte. Es ist z.B. nicht möglich, eine Variable zu ändern. Stattdessen muss man auf Rekursion zurückgreifen. XSLT ist deshalb nicht ganz einfach zu erlernen. Es ist doch sehr verschieden zu den bekannten prozeduralen oder objektorientierten Programmiersprachen. XSLT ist allerdings schon in der Version 1.0 bzw. 1.1 sehr mächtig und in der Praxis einsetzbar.
Um XSLT verwenden zu können, benötigt man auch einen XSLT Prozessor, der aus dem XML-Quelldokument und dem XSLT-Stylesheet das Ausgabedokument erzeugt. Eine Liste der verfügbaren XSLT-Prozessoren findet man unter www.xmlsoftware.com/xslt.html. Michael Kay, der Autor des bekannten XSLT-Prozessors Saxon, ist auch Autor des Standardwerks zu XSLT: [Kay 2001]. Mit Hilfe dieses Buches und den sehr hilfreichen XSLT-FAQs von Dave Pawson [Pawson 2002] hat der Autor die XSLT-Stylesheets geschrieben, die dieser Arbeit zugrundeliegen. (Siehe Anhang Metadaten.)
XPath
XPath ist eine Sprache um auf Teile eines XML-Dokuments zugreifen zu können. Sie wird innerhalb von XSLT und anderen XML-Anwendungen verwendet. Mit XPath sind auszugsweise folgende Abfragen möglich:
Zusätzlich gibt es Funktionen, um die Anzahl ausgewählter Elemente oder die Position des aktuellen Elements in einem gewissen Kontext zu bestimmen. Auch String-Manipulationsfunktionen sind in XPath enthalten.
XSL-FO
XSL-FO ist ein XML-Dokumenttyp, der es erlaubt ein genaues Layout - beispielsweise für die Print-Ausgabe - zu definieren. Mittels XSLT und XPath wird ein XML-Dokument in XSL-FO Format übersetzt. Ein XSL-FO Prozessor kann daraus dann beispielsweise ein PDF-Dokument erstellen. Mit Hilfe von XSL-FO wurde auch die gedruckte Version dieser Arbeit erstellt. (Siehe Anhang Metadaten.)
| 2.2.7 | Linking und Querying |
XLink
Die Hyperlinks in HTML-Dokumenten sind hinlänglich bekannt. Diese erlauben ein Dokument mit einem anderen zu verknüpfen. Allerdings nur in eine Richtung. Die W3C-Empfehlung XLink 1.0 [W3C-XLink 2001] beschreibt eine darüber hinausgehende Methode, beliebige Dokumente (das W3C spricht hier von Ressourcen) zu verknüpfen. Mit XLink sind bidirektionale Links und Verknüpfungen von mehr als nur zwei Ressourcen möglich. Außerdem ist es möglich, den Inhalt einer verknüpften Ressource anstatt des Links direkt in das Dokument einzubetten. [Anderson et al. 2000, Kapitel 8: Linking und Querying]
Von den gängigen Webbrowsern wird XLink allerdings noch nicht unterstützt. Eine Ausnahme ist der Mozilla Browser (www.mozilla.org), der einen Teil (simple Links) von XLink unterstützt.
XPointer
Eine weitere Sprache des W3C zum Verknüpfen von Dokumenten ist XPointer (XML Pointer Language). Mit Hilfe der XPointer ist es möglich, Teile eines XML-Dokuments anzusprechen, wie zum Beispiel einzelne Elemente. XPointer bedient sich dabei - wie XSLT - der XPath-Empfehlung. XPointer selbst ist noch keine gültige W3C-Empfehlung, sondern erst ein Anwärter auf eine Empfehlung ("Candidate Recommendation") [W3C-XPath 2001].
XML Query
Wer sich mit Datenbanken beschäftigt, kennt die Structured Query Language (SQL), mit deren Hilfe man Daten, die in Datenbanken gespeichert sind, auslesen bzw. manipulieren kann. Eine ähnliche Sprache wäre auch für XML-Dokumente wünschenswert. Das Auslesen bestimmter Informationen ist zwar mit XSLT möglich, aber erstens nicht so komfortabel, wie das mit einer Abfrage-Sprache (Query Language) möglich sein sollte, und zweitens sind Manipulationen am Quelldokument mit XSLT nicht möglich.
Vom W3C wurde deshalb die XML Query working group ins Leben gerufen. Entwürfe oder Standards gibt es dazu aber noch nicht. Es wurden erst die Anforderungen an XML Query und mögliche Anwendungsszenarien (Use Cases) erarbeitet. [W3C-XML Query 2002]
| 2.2.8 | XML-RPC, SOAP und Web Services |
Auf Multitasking-Systemen, wo mehrere Programme gleichzeitig laufen, ist es natürlich wünschenswert, wenn diese Programme untereinander Informationen austauschen bzw. zusammenarbeiten können. Natürlich müssen sich dabei die Programme auf einen gemeinsamen Mechanismus einigen. Microsoft bietet mit COM (Component Object Model) solch einen Mechanismus. Die Komponenten, die in einer DLL oder in einem normalen Anwendungsprogramm enthalten sein können, enthalten Funktionen und Daten. Diese können dann von anderen Programmen verwendet werden.
Interessanter wird dasselbe, wenn es über Rechnergrenzen hinweg funktionieren soll. Ein Programm soll also Funktionen eines anderen Programms auf einem anderen Rechner aufrufen und das Ergebnis zurückerhalten. Aus der Unix-Welt kommt der Begriff RPC (Remote Procedure Call). RPC erlaubt es, Funktionen eines andern Programms (auch auf einem entfernten Rechner) aufzurufen und das Ergebnis der Funktion zurückzuerhalten. Microsoft nennt die Erweiterung vom oben genannten COM, die auch über Netzwerke funktioniert, DCOM (Distributed Component Object Model). Für Java gibt es RMI (Remote Method Invocation) und der bekannteste offene und firmenunabhängige Standard hierfür ist CORBA (Common Object Request Broker Architecture).
XML-RPC
XML-RPC (XML-Remote Procedure Call) ist eine neue Möglichkeit hierfür. XML-RPC ist besonders einfach gehalten. Es verwendet HTTP, also das Protokoll, das auch für die Übertragung von Webseiten verwendet wird. Die Daten, die dabei übertragen werden, sind allerdings nicht für den Browser bestimmte Webseiten, sondern XML-Dokument mit einem genau definierten Aufbau. Im Dokument sind der Name der Funktion, die auf dem entfernten Rechner aufgerufen werden soll, und deren Parameter enthalten. Für diese Anfrage wird HTTP-Post verwendet, also dieselbe Methode, die üblicherweise verwendet wird, um HTML-Formulardaten an den Server zu schicken. Das Ergebnis wird analog einer normalen Webseite zurückgeschickt. Allerdings im XML-RPC-Format. Die Verwendung von HTTP als Übertragungsprotokoll hat den Vorteil, dass es fast überall funktioniert, weil HTTP-Verkehr auch über viele Firewalls erlaubt ist. Außerdem funktioniert HTTP auf allen Rechner-Plattformen. XML-RPC spezifiziert nur den Aufbau der XML-Daten, die zwischen zwei Rechnern übertragen werden. Die eigentliche Implementierung kann praktisch in jeder Programmiersprache durchgeführt werden. Daher ist XML-RPC plattformunabhängig.
<?xml version="1.0">
<methodCall>
<methodName>Funktionsname</methodName>
<params>
<param>
<value><string>EinZeichenkettenParameter</string></value>
</param>
<param>
<value><int>12</int></value>
</param>
</params>
</methodCall>Beispiel 12:
XML-RPC Funktionsaufruf mit einem String und einem Integer Parameter
XML-RPC ist keine Entwicklung des W3Cs. Die Spezifikation kann unter [XML-RPC 1999] abgerufen werden. Die Einfachheit dieses Verfahrens spiegelt sich auch in der außergewöhnlich kurzen Spezifikation wider.
Wie man am Beispiel 12 sehen kann, ist XML-RPC sehr verschwenderisch. Die eigentlichen Nutzdaten sind nur "Funktionsname", "EinZeichenkettenParameter" und "12". Die zu übertragenden Daten sind aber um ein Vielfaches länger. Noch schlimmer schaut es bei Speicherstrukturen wie beispielsweise Arrays aus.
SOAP
Bei SOAP (Simple Object Access Protocol) geht es nicht nur um RPC, also Funktionsaufrufe auf entfernten Rechnern, sondern grundsätzlich um den Austausch von XML-Daten. Aber auch RPC-Aufrufe können mit SOAP mit weniger Overhead durchgeführt werden als mit XML-RPC. Es können zum Beispiel die Datentypen von XML-Schemas verwendet werden. (Siehe Kapitel 2.2.4 XML-Schema.) Mit SOAP können darüber hinaus ganze XML-Dokumente - auch unter Verwendung von Namensräumen - übertragen werden. Dabei ist im Vergleich zu XML-RPC auch wieder viel weniger Overhead vorhanden.
Die aktuellen SOAP-Implementationen basieren auf SOAP 1.1, einer W3C-Note, die eigentlich nur als Diskussionsgrundlage dienen soll [W3C-SOAP 1.1 2000]. SOAP 1.2 existiert momentan als Anwärter auf eine Empfehlung ("Candidate Recommendation") [W3C-SOAP 1.2 2002].
Web Services
Web Services sind Dienste, die ein Anbieter zur Verfügung stellt. Beispiele für solche Dienste sind: Ein Händler bietet ein Webservice zur Abfrage seiner Produkte inklusive Preise und Verfügbarkeit an. Die Suchmaschine Google bietet ein Webservice zum Abfragen von Suchergebnissen an. Damit ist es möglich, Suchergebnisse von Google in die eigene Webseite oder in die eigene Anwendung zu integrieren. [Google API 2002]
Zur Übertragung der Daten wird bei Web Services SOAP verwendet. Zusätzlich gibt es allerdings die so genannte Web Service Description Language (WSDL). Ein Web Service-Anbieter stellt diese XML-Datei zum Downloaden bereit. Sie definiert die Schnittstelle: Funktionsnamen, Paramter usw. Einige Programmier-Werkzeuge können aus der WSDL-Datei automatisch Programm-Code zur Integration des Web Service erzeugen. Selbst Microsoft setzt mit ihrer neuen .NET Entwicklungsumgebung sehr stark auf diesen offenen Standard.
Weiters wurde von IBM, Microsoft und anderen Firmen eine Initiative gegründet, ein Verzeichnis der zur Verfügung stehenden Web Services aufzubauen. Ziel sollte eine Art globale "Gelbe Seiten" sein. Das ganze nennt sich UDDI (Universal Description, Discovery and Integration) und baut auf untereinander vernetzte Datenbanken, die Informationen enthalten, wo welche Firma welchen Service (Dienstleistungen, Produkte) anbietet. Momentan sind allerdings wenige bis gar keine Web Services enthalten. Meist nur Web- oder E-Mail-Adresse. [Schulz 2002]
| 2.2.9 | Weitere XML Standards |
Es gibt unzählige weitere neue Standards, die auf XML basieren. Einige interessante seien hier noch erwähnt. SVG (Scalable Vector Graphics) ist ein vektororientiertes Grafikformat für das Web [W3C-SVG 2001]. Zur Zeit funktioniert es in gängigen Web-Browsern aber nur über ein Plug-In von der Firma Adobe. SMIL (Synchronized Multimedia Integration Language) erlaubt das Erstellen von audiovisuellen Präsentationen mit allen möglichen multimedialen Inhalten [W3C-SMIL 2002]. Ein weiterer Standard, der besonders wichtig für Webapplikationen werden wird, ist XForms. Dessen Möglichkeiten gehen weit über die Möglichkeiten der zur Zeit bekannten und verwendeten HTML-Formulare hinaus [W3C-XForms 2002]. Leider gibt es für die XForms gerade mal einen Entwurf ("Working Draft"). Deshalb sieht es mit realen Implementationen noch relativ schlecht aus. Die HTML-Formulare haben nur sehr beschränkte Möglichkeiten, sodass eine schnelle Einführung dieser Spezifikation sehr zu begrüßen wäre.
Ein wichtiger Punkt ist die Verschlüsselung von Daten. Ganze Dateien können mittels SSL (Secure Socket Layer), wie es jetzt schon für kritische Webseiten verwendet wird, verschlüsselt werden. XML Encryption beschäftigt sich unter anderem mit der Möglichkeit bestimmte Bereiche eines XML-Dokments nur für bestimmte Benutzer zugänglich zu machen [W3C-XML Encryption 2002].
| 2.2.10 | Stärken von XML |
| 2.2.11 | Nachteile von XML |
Gerade das Speicherplatz-Problem ist nicht zu unterschätzen. Ein Programm könnte die reinen Nutzdaten eines XML-Dokuments auch mit viel weniger Information rekonstruieren: Tags und Attributnamen könnten durch einfache Trennzeichen ersetzt werden, ähnlich wie das bei der CSV-Darstellung (Comma Separated Values) der Fall ist. Leerzeichen, Tabulatoren und Zeilenvorschübe könnten weggelassen werden. Je nach XML-Dokument ergeben sich hier schon beträchtliche Einsparungspotentiale. Bei den Quelldokumenten dieser Arbeit konnte der Autor mit diesen Änderungen die Dateigröße auf Werte zwischen 27% und 75% der urspünglichen Größe bringen. Es können durchaus Mehrkosten entstehen, wenn ein Programm doppelt soviel Speicherplatz oder doppelt soviel Bandbreite im Netzwerk (internes Netzwerk oder Internet) benötigt.
Deshalb wird nach Möglichkeiten gesucht, XML-Dateien zu komprimieren. Beispielsweise werden die XML-Dateien mit den gängigen Komprimierungsverfahren wie gzip oder zip verkleinert. Zu besseren Komprimierungsraten kommt allerdings der Burrows-Wheeler Algorithmus der z.B. in bzip2 implementiert ist. Allerdings benötigt der auch mehr Rechenaufwand als gzip oder zip [Tamm 2000]. Eine Komprimierung mit diesen Algorithmen kann eine extreme Verkleinerung bringen. In einem Beispiel in [Mertz 2001] hat der Autor ein 1 MB großes Webserver-Log File in die XML-Darstellung gebracht, die dann 3 MB groß war. Durch Komprimierung mit bzip2 konnte die Dateigröße auf 2,2% der Originalgröße reduziert werden. Bei einem anderen Quelltext wurden nur 20% erreicht. Je mehr (gleiche) XML-Elemente und Attribute im Vergleich zu den Nutzdaten, desto kleiner kann komprimiert werden.
Eine weitere Einsparung kann man erzielen, wenn die XML-Daten vor der Komprimierung umstrukturiert werden. Vor allem der Algorithmus von gzip und zip profitiert davon. Ein Verfahren, das unter [Mertz 2001] beschrieben ist, teilt das XML-Dokument in drei Teile: Zuerst alle Element- und Attributnamen, dann die Struktur des Dokuments und zuletzt die eigentlichen Daten.
|
15 Ein Kind-Element ist ein Unterelement eines anderen Elements. Es steht also innerhalb des öffnenden und schließenden Tags des Eltern-Elements. Eigentlich müsste es im Deutschen "Tochter-Element" und "Mutter-Element" heißen. Da aber im Englischen die Ausdrücke "child element" und "parent element" verwendet werden, haben sich die Bezeichnungen "Kind-Element" und "Eltern-Element" auch in vielen deutschsprachigen Büchern schon durchgesetzt.
16Da das XML-Schema selbst ein XML-Format ist, kann man auch definieren, wie dieses XML-Format aussieht. Das heißt, es gibt ein Schema für Schemas. Anhand dieses Schemas kann man alle Schema-Dokumente auf Gültigkeit überprüfen. Dieses Schema für Schemas ist unter der Namensraum-URI http://www.w3.org/2001/XMLSchema definiert. In diesem Fall ist diese URI auch eine gültige URL unter der man einen Link zum Quelldokument des Schemas für Schemas findet.
| Nächstes Kapitel >> |
| Zum Seitenanfang | diplomarbeit_o a-t schmiderer d-o-t cc | 2003-04-25 |