Entwicklung und Nutzen von XML

[Informatik- u. Master-Seminar SS04]   [Inhaltsverzeichnis]   [zurück]   [weiter] Nach unten

XML als Datenaustauschformat

Warum XML als Datenaustauschformat?

Es gibt eine Reihe von Gründen, die dafür sprechen, XML als Format zum Austausch von Informationen zu nutzen. XML ist plattformunabhängig und durch die Verwendung des Unicode-Zeichensatzes international einsetzbar. Da XML-Dokumente eine Baumstruktur besitzen lassen die sich leicht durchsuchen und auch die Verarbeitung solcher Dokumente stellt kein Problem dar. XML-Werkzeuge gibt es wie Sand am Meer und sollte man einmal in die Verlegenheit kommen, kein passendes Tool zu finden, so ist es im Vergleich zu anderen Lösungen relativ einfach, sich seine eigenen Tools zu entwicklen, die Schnittstellen dafür sind offen zugänglich vorhanden. Neben der einfachen Verarbeitung ist ein weiteres Argument, dass für XML als Datenaustauschformat spricht, die Möglichkeit Daten strukturiert zu übertragen. XML bietet ebenfso die Möglichkeit zur Meta-Daten-Übertragung in Form von Attributen.
Beispiel: Remote Procedure Calls

Remote Procedure Call bedeutet sinngemäß übersetzt Aufruf entfernter Prozeduren und ist für Client/Server-Architekturen gedacht. Es wurde von Sun Microsystems entwickelt und ist eine Sammlung von Tools und Bibliotheksfunktionen. Der RPC-Server besitzt eine Reihe von Prozeduren, die ein Client über das Netz aufrufen kann, indem er eine RPC-Anforderung an den Server schickt, zusammen mit den Prozedurparametern. Der Server führt die entsprechende Prozedur aus und schickt das Ergebnis, falls es eins gibt, an den Client zurück. Die Kommunikation erfolgt in der Regel über das User Datagramm Protocoll (UDP), bei zu großen Datenmengen, die nicht in ein UDP-Datagramm passen, kann auch das Transmission Control Protocol (TCP) eingesetzt werden. Um Plattformunabhängigkeit, was bei einer Client/Server-Architektur grundlegend ist, zu gewährleisten werden alle zwischen dem CLient und dem Server ausgetauschten Daten vom lokalen Datenformat in ein Zwischenformat umgewandelt, das sogenannte XDR-Format (External Data Representation), und dann auf der anderen Seite wieder in das entsprechende lokale Format zurückgewandelt. Dies ist ein entscheidender Nachteil von RPC, da zusätzlich zum Transport der Daten insgesamt vier Umwandlungen nötig sind. Woher weiss aber nun der Client, welche Prozeduren ein RPC-Server zur Verfügung stellt und wie er da rankommt? Ein RPC-Server bietet meist ganze Sammlungen von Prozeduren an, die auch als Programm bezeichnet werden und durch eine Programmnummer eindeutig identifiziert werden. Für jedes Programm wird nun ein seperater UDP-/TCP-Port reserviert. Der Client hat nun die Möglichkeit sich über eine Liste von Zuweisungen von Servicenamen zu Programmnummern diejenige Programmnummer herauszusuchen, die er benötigt. Jetzt kennt der Client zwar die Programmnummer, die er aufrufen muss, er weiss aber immernoch nicht, auf welchem Port das Programm auf dem Server erreichbar ist. Da RPC-Server keine Well-Known-Ports benutzen, können sich die Ports also auch ändern. Die Lösung liegt im sogenannten Portmapper. Eine RPC-Anwendung des Clients nimmt einfach irgendeinen Port, den sie kriegen kann und registriert diesen Port über ein spezielles Programm, den Portmapper-Dämon. Der Portmapper funktioniert als Dienstevermittler für alle Programme, die auf einem RPC-Server laufen. Der Client fragt also den Portmapper auf dem Host ab und dieser liefert ihm die entsprechende Portnummer zurück, unter der das gewünschte Programm erreichbar ist. Dieses Konzept beeinhaltet den grossen Nachteil, dass der Portmapper einen "single point of failure" darstellt. Wenn der Portmapper ausfällt gehen alle RPC-Port-Informationen verloren und der Dienst (evtl. der gesamte Server) muss neu gestartet werden.

XML-RPC

Da die oben genannte vierfache Umwandlung der Daten zur Kommunikation zwischen Client und Server ein wenig umständlich erscheint, hat man sich Gedanken gemacht dies durch ein gemeinsames, plattformunabhängiges Format zu vereinfachen und ist auf XML als Datenaustauschformat gekommen. XML-RPC ist eine Spezifikation und eine Anzahl von Implementierungen, die es Clients ermöglichen, Software verschiedenartiger Betriebssysteme und Rechner-Architekturen mittels Remote Procedure Calls (RPC) über das Internet zu nutzen. XML-RPC ist praktisch ein Remote Procedure Calling Protokoll mit HTTP als Transportprotokoll und XML als Datenaustauschformat (Encoding). Dabei ist XML-RPC so entworfen worden, daß es so einfach wie möglich ist, es aber trotzdem möglich ist, komplexe Datenstrukturen zu übertragen, zu verarbeiten und als Ergebnis zurückzuliefern. Es bereitet keine Probleme, weder client- noch server-seitig, XML zu lesen, zu verarbeiten und zu schreiben. Die Schnittstellen dafür sind für alle gängigen Programmiersprachen und Plattformen vorhanden und das entwickeln von Software oder Tools zur XML-Verarbeitung ist im Vergleich zu anderen Lösungen trivial. XML-RPC ist beispielsweise verfügbar für Perl, Python, Java, Frontier, SKYRIX, C/C++, Lisp, PHP, Microsoft .NET, Rebol, Real Basic, Tcl, Delphi, WebObjects, Zope u.a. Die erste Implementation von XML-RPC fand bereits 1998 in Frontier, einem Web Content Managementsystem, statt. Eine XML-RPC-Nachricht ist eine HTTP-POST-Anfrage, deren Inhalt mit XML formuliert ist und die eine Prozedur auf dem Server anstösst, welche die jeweiligen Ergebnisse wiederum im XML-Format zurückschickt. Parameter für solche mit XML-RPC aufgerufenen Prodezuren können Zahlen, Strings und Datumsangaben sein, es können jedoch auch komplexe Datensätze und Listenstrukturren verarbeitet werden.

Die Struktur eine XML-RPC Anfrage: 
POST /RPC2 HTTP/1.0
User-Agent: Frontier/5.1.2 (WinNT)
Host: betty.userland.com
Content-Type: text/xml
Content-length: 181

<?xml version="1.0"?>
<methodCall>
   <methodName>examples.getStateName</methodName>
   <params>
      <param>
         <value><i4>41</i4></value>
         </param>
      </params>
   </methodCall>

Als Anfrage-Methode ist hier, wie oben beschrieben, im Header POST angegeben. Die Angabe RPC2 ist eine URI, über die die beim Server ankommenden Requests an den entsprechenden RPC-Responder weitergeleitet werden können. Diese URI-Angabe ist notwendig, wenn der Server verschiedene HTTP-Anfragen bearbeiten kann. Durch die Angabe einer solchen URI wird praktisch ein Routing der Anfrage an den entsprechenden Prozess, der die Anfrage bearbeiten soll, unterstützt. Das Client-Programm, welches die RPC-Nachricht abschickt, ist hier das oben erwähnte Content Management System Frontier, die Angabe des Mime-Typs ist XML. Obwohl der Host, der User-Agent und die Länge sind in diesem Beispiel uninteressant, müssen alle Werte gesetzt und korrekt sein. Ebenfalls muss der Content-Type wie hier auf text/xml gesetzt sein.

Das Root-Element ist ein <Method-Call>, welche ein Kindelement <Method-Name> mit dem Namen der aufzurufenden Prozedur beeinhalten muss. Der Inhalt von <Method-Name> kann beispielsweise der Name einer Datei oder eines Skripts sein, die/das ausgeführt werden soll. Es kann auch der Name einer Zelle in einer Datenbanktabelle sein oder ein Pfad innerhalb einer Dateihierarchie. Besitzt die aufgerufene Prozedur Parameter, wie hier im Beispiel, so muss <Method-Name> ein Unterelement <Params> enthalten, welches wiederum beliebig viele Unterlemente vom Typ <Param> besitzen kann, in denen die Parameter spezifiziert werden. Jeder dieser Parameter muss nun durch ein Element <Value> näher beschrieben werden. Innerhalb des <Value-Elementes> wird nun der eigentliche Datentyp beschrieben, ebenfalls mit einem Tag. Die Angabe <i4> steht in diesem Fall für einen vorzeichenbehafteten 4 Byte Integer-Wert. Andere mögliche Datentypen sind Boolean, String, Double, dateTime.iso8601(Datums/Zeit-Angaben), base64 (Binärwert), Structs und Arrays. Auf die Datentypen und die Syntax soll hier aber nicht näher eingegangen werden, da es für die Funktionsweise von XML-RPC, die hier beschrieben werden soll, unerheblich ist, welche Datentypen und welche genaue Syntax verwendet werden muss.

Eine mögliche Antwort des RPC-Servers:
HTTP/1.1 200 OK
Connection: close
Content-Length: 158
Content-Type: text/xml
Date: Fri, 17 Jul 1998 19:55:08 GMT
Server: UserLand Frontier/5.1.2-WinNT

<?xml version="1.0"?>
<methodResponse>
   <params>
      <param>
         <value><string>South Dakota</string></value>
         </param>
      </params>
   </methodResponse>


SOAP

SOAP steht für "Simple Object Access Protocol" und ist im wesentlichen eine Weiterentwicklung von XML-RPC. Im Unterschied zu XML-RPC ist SOAP ein vom W3C verabschiedeter und unterstützter Standard, der unter anderem von Microsoft, IBM, DevelopMentor mitentwickelt wurde. SOAP stellt einen einfachen und durchsichtigen Mechanismus zum Austausch von Information zwischen Rechnern in einer dezentralisierten, verteilten Umgebung zur Verfügung, ist also von Anfang an für den Einsatz in verteilten Systemen, auch durch Firewalls hindurch, konzipiert. SOAP soll kein Programmiermodell oder eine implementationsspezifische Semantik vorgeben, sondern einen unkomplizierten Mechanismus, um die Semantik einer Anwendung zu beschreiben. SOAP kann in einem weiten Einsatzfeld gebraucht werden, von einfachen Nachrichtensystemen bis zu Remote Procedure Calls.

SOAP besteht aus 4 Teilen:
SOAP-Nachrichten sind in XML verfasst, daher ist die Möglichkeit zur Nutzung von Namensräumen gegeben. Eine SOAP-Anwendung sollte alle Namensräume für Elemente und Attribute, die von SOAP vorgegeben werden, in die verschickten Nachrichten einbinden. SOAP versucht eine große Menge von Anwendungsfällen abzubilden und ist dadurch deutlich komplizierter zu implementieren. Deutlich wird dies vor allen durch die geringe Anzahl von Implementationen, die oft zueinander inkompatibel sind. Der wesentliche Vorteil von XML-RPC gegenüber SOAP ist seine Einfachheit in Nutzung und Umsetzung. Daraus resultierend gibt es eine riesige Menge von tatsächlich kompatiblen Implementationen für praktisch jede Plattform und Programmiersprache. Nichtsdestotrotz wird SOAP XML-RPC wohl langfristig ablösen, da es das offizielle "WebServices"-Protokoll des W3C ist und breite Unterstützung von den Herstellern der großen Entwicklungstools erhält.

SOAP sollte nur in heterogenen Systemen, die keine hohe Performance-Anforderung erfordern, die keinen hohen Sicherheitsbedarf mit isch bringen und die nicht von einer einzelnen Person administriert werden. SOAP sollte vor allem dann eingesetzt werden, wenn es um die Kommunikation verschiedener Systeme aus unterschiedlichen Umgebungen über das Internet geht.
[Informatik- u. Master-Seminar SS04]   [Inhaltsverzeichnis]   [zurück]   [weiter] Inhaltsverzeichnis Nach oben