Grundlagen: Techniken des Web 2.0

Einführung

Ein wichtiger Baustein für die Weiterentwicklung zum Web 2.0 war die Einführung des XMLHTTPRequest-Objekt von Microsoft im Internet Explorer 5 im Jaher 1999. Dieses Objekt ermöglicht es, dass Teile einer HTML Seite zu einem späteren Zeitpunkt geladen oder aktualisiert werden können. Dadurch, dass nicht mehr die komplette Internetseite neu geladen werden muss können die Seiten aufwändiger sein, weil nicht immer die komplette Seite geladen werden muss, zum anderen kann eine Ansicht aktualisiert werden, während sonstige Eingabe erhalten bleiben. Die Schlüsseltechniken hierfür sind AJAX und Webservices. Bei der Umsetzung von Webservice besteht eine breite Auswahl von verfügbaren Techniken, die drei wohl wichtigsten werden hier vorgestellt: REST, XML-RPC und SOAP.

AJAX – Asynchronous Javascript And Xml

AJAX ist ein Paradoxon: Es ist eine der wichtigsten, aber gleichzeitig wohl die überflüssigste Technik im Web 2.0. AJAX erlaubt das Nachladen oder Austauschen von Objekten im HTML-Baum, es verändert also die dargestellte HTML-Seite zu einem vom Benutzer festgelegten Zeitpunkt. Dadurch werden flexible Webanwendungen möglich, die sich ähnlich bedienen lassen wie Desktopanwendungen. Dadurch wird kaum neue Funktionalität erschlossen, aber viele Funktionen lassen sich einfacher erstellen oder sind für den Nutzer komfortabler.

Für die Betreiber eines Mashups bietet AJAX den Vorteil, dass Resourcen von externen Server dynamisch nachgeladen werden. Aufgrund der Sicherheitsrichtlinien können mit AJAX nur Objekte vom Ursprungsserver nachgeladen werden. Daher muss man zwar immer den Umweg über den eigenen Server gehen, jedoch verhindert man so, dass der Benutzer gar keine Seite angezeigt bekommt, während die Daten vom Fremdserver geladen werden.

Ausführlich wurde das Thema AJAX in dem Seminarvortrag von Tim Baumgarten behandelt.

REST – Representational State Transfer

Der Begriff Representational State Transfer (REST) bezeichnet einen Softwarearchitekturstil für verteilte Hypermedia-Informationssysteme wie das World Wide Web. Der Begriff stammt aus der Dissertation von Roy Fielding aus dem Jahr 2000, in der der Erfolg des World Wide Web auf bestimmte Eigenschaften der verwendeten Mechanismen und Protokolle (z.B. HTTP) zurückgeführt wird. Roy Fielding ist einer der Hauptautoren der Spezifikation des HTTP-Protokolls.

Grundprinzip von REST ist, dass Verben wie PUT, POST, GET oder DELETE auf Subjekte (Daten) angewandt werden.

Die beiden häufigsten Verben sind GET und POST. Bei jedem Abruf einer HTML Seite wird ein GET-Request ausgelöst, der eine bestimmte Seite vom Server abruft. Dabei können Parameter über die URL übertragen werden

GET /index.php?userid=joe&password=guessme HTTP/1.1

Beim abschicken eines Formulars an den Server wird ein POST-Request abgesetzt, der im HTTP-Header zusätzlich die Formulardaten enthält. Dabei müssen die Headerfelder "Content-Type" und "Content-Length" korrekt angegeben sein. Der Kopfbereich wird vom Inhalt durch zwei Zeilenumbrüche abgetrennt.

POST /index.php HTTP/1.1
Host: www.mysite.com
User-Agent: Mozilla/4.0
Content-Length: 27
Content-Type: application/x-www-form-urlencoded
 
userid=joe&password=guessme

Für Webservices bedeutet das REST-Modell, dass die Anfrage meist per GET oder POST an den Server geschickt wird und dann ein Ergebnis - meist XML - als HTTP-Antwort zurückgegeben wird. Dabei ist in keiner Weise spezifiziert welche Feldnamen benutzt werden sollen oder wie die Antwort aussehen soll.

XML-RPC (Remote Procedure Calls)

XML-RPC ist ein einfaches Protokoll für entfernte Prozedur- oder Methodenaufrufe (Remote Procedure Calls) über das HTTP-Protokoll. Es entstand in einer Zusammenarbeit zwischen Dave Winer (UserLand) und Microsoft als Zwischenprodukt auf dem Weg zu SOAP.

Ideen bei der Entwicklung

Es wurde aus den praktischen Anforderungen heraus definiert und ist daher leicht zu Implementieren. Dadurch war es schnell auf vielen Plattformen verfügbar.
Das Format soll so intuitiv sein, dass jeder Mensch, der mit HTML arbeitet, die Anfrage schnell und leicht deuten und schreiben kann.
Außerdem sind die Anfragen durch die Nutzung von HTTP auf allen Systemen lauffähig, die bereits mit dem Protokoll arbeiten. Es sind keine Änderungen an der Firewall notwendig.

XML-RPC Anfragen werden über einen HTTP-Post Befehl aufgerufen. Die eigentliche Prozeduranfrage ist dabei durch eine XML-Struktur definiert. Nach der Verarbeitung des Aufrufs wird eine Antwortnachricht wiederum als XML zurückgegeben.

Dabei sind nicht nur Anforderungen an die XML-Struktur, sondern auch an den HTTP-Header in der Spezifikation definiert:

User Agent und Host müssen definiert sein
Der Content-Type ist text/xml
Content-Length muss angegeben werden und korrekt sein

Die XML-Anfrage besteht aus einem Methodennamen und einer Parameterliste.

Methodennamen werden durch das methodName-Element definiert, das den Namen der Prozedur enthält. Dieser Name darf nur aus den Buchstaben a-Z, Zahlen, Unterstrich, Punkt, Komma und Slash bestehen.

In dem params-Element werden die Parameter definiert, dabei gibt es drei Arten von Parametern: Skalare, Strukturen und Listen.

Skalare

Skalare können einen der vorgegebenen Typen annehmen, eigene Typen oder Wertebereiche können nicht definiert werden. Wenn kein Typ angegeben ist, wird der Typ String angenommen.

Tag	Typ	Beispiel
<int> oder <i4>	Vorzeichenbehaftete 32-Bit Ganzzahl	-42
<boolean>	Boolean (0 oder 1)	0
<string>	Zeichenkette	Hallo Welt!
<double>	Vorzeichenbehaftete Fließkommazahl mit doppelter Präzision (in Anlehnung an C, Implementierungsabhängig)	-0.341
<dateTime.iso8601>	Datum/Uhrzeit nach ISO8601	19980717T14:08:55
<base64>	Base64-Kodierte Binärdaten	eW91IGNhbid0IHJlYWQgdGhpcyE=

Strukturen

Strukturen sind komplexe Datentypen, also eine Verbindung verschiedener Datentypen. Die Unterelemente werden in Anlehnung an die Objektorientierung Mitglieder genannt. Mitglieder werden durch einen Namen und einen Wert Beschrieben. Die Werte der Mitglieder können Skalare, Listen oder wiederum Strukturen sein.

<struct>
  <member>
    <name>lowerBound</name>
    <value><i4>18</i4></value>
  </member>
  <member>
    <name>upperBound</name>
    <value><i4>139</i4></value>
  </member>
</struct>

Listen

Eine Liste ist eine Folge von <value>-Elementen, wobei der Datentyp beliebig ist. Auch hier sind Strukturen und Listen zulässig. Außerdem müssen nicht alle Elemente einer Liste die gleichen Datentypen haben.

<array>
  <data>
    <value><i4>12</i4></value>
    <value><string>Egypt</string></value>
    <value><boolean>0</boolean></value>
    <value><i4>-31</i4></value>
  </data>
</array>

Ein Beispiel für einen kompletten XML-RPC Aufruf:

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><int>42</int></value>
    </param>
  </params>
</methodCall>

Die Antwort wird in gleicher Weise erzeugt. Sie ist eine normale HTTP-Antwort, die als Inhalt wieder eine XML-Struktur hat. Diese <methodResponse> Struktur gleicht der <methodCall>-Struktur bis auf das Detail, dass hier kein Methodenname vorgesehen ist. Dieser ergibt sich automatisch durch den Kontext, da ein XML-RPC-Aufruf immer über das HTTP-Protokoll ausgeführt wird und daher Aufruf und Antwort in direkt Beziehung zueinander stehen.

Im Header gelten auch ähnliche Anforderungen wie beim Aufruf:

Sofern kein schwerwiegender Fehler bei der Verarbeitung aufgetreten ist, lautet der Statuswert 200, abgefangene Fehler werden mit Status 200 und einer <fault>-Element beantwortet
Der Content-Type ist text/xml
Content-Length muss angegeben werden und korrekt sein

Fehlerfall

Im Falle eines abgefangenen Fehlers wird statt den normalen Rückgabewerten ein <fault>-Element zurückgegeben. Dieses Element enthält ein <value>-Elemente und soll den Fehler beschreiben. Es können Skalare, Strukturen und Listen verwendet werden. Der Inhalt ist nicht durch die Spezifikation vorgegeben.

Beispiel für eine vollständige Antwort:

HTTP/1.1 200 OK
Connection: close
Content-Length: 158
Content-Type: text/xml
Server: UserLand Frontier/5.1.2-WinNT
 
<?xml version="1.0"?>
<methodResponse>
   <fault>
      <value>
         <struct>
            <member>
               <name>faultCode</name>
               <value><int>4</int></value>
            </member>
            <member>
               <name>faultString</name>
               <value><string>Too many parameters.</string></value>
            </member>
         </struct>
     </value>
   </fault>
</methodResponse>

SOAP – Simple Object Access Protocol

Ursprünglich hieß SOAP Simple Object Access Protocol, dann wurde es kurzzeitig Service Oriented Architecture Protokoll genannt. Jetzt ist es keine Abkürzung mehr, sondern nur ein Name – Abkürzungen lassen sich nicht als Namen registrieren.

Die Abkürzungen zeigen jedoch die Umgebung in der das Protokoll eingesetzt werden soll: WebServices.

Es entstand in einer Zusammenarbeit zwischen Dave Winer und Microsoft und erblickte 1999 in Version 0.9 das Licht der Öffentlichkeit. Damals fand es jedoch keinen großen Zuspruch bei den Entwicklern. Das Projekt gewann die Beliebtheit, als 2000 unter anderem IBM in die Entwicklung eingestiegen ist. Version 1.1 wurde dem W3C als Vorschlag für eine Arbeitsgruppe eingereicht. In dieser entstand die Version 1.2, die als Entwurfsvorschlag eingereicht wurde.

SOAP wurde ursprünglich wie XML-RPC zur Verwendung mit dem HTTP-Protokoll entwickelt, mittlerweile wurde es jedoch davon abstrahiert und die XML-Daten können auf unterschiedliche Weise übertragen werden. Denkbar ist auch eine Übertragung der Dateien per FTP oder anderer Transportprotokolle.

Struktur

SOAP Nachrichten bestehen aus einem Umschlag, der das ganze Dokument umschließt, einem optionalen Kopf und einem Nachrichtenkörper.

Das Kopfelement enthält Metainformationen zu der Nachricht, z.B. Informationen zur Verschlüssekung, dem Routing oder der Zugehörigkeit zu einer Transaktion. Das ist im Mashup-Umfeld jedoch weitgehend ohne Belang.

SOAP-Anfrage vom Client (ohne HTTP-Header):

<?xml version="1.0" encoding="UTF-8"?>
  <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
                    xmlns:xsd="http://www.w3.org/2001/XMLSchema"
                    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <soapenv:Body>
      <ns1:validate
       soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
       xmlns:ns1="urn:CardValidator">
        <number xsi:type="xsd:string">1234 5678 9876 5432</number>
        <valid xsi:type="xsd:string">12/08</valid>
      </ns1:validate>
  </soapenv:Body>
</soapenv:Envelope>

SOAP-Antwort vom Server (ohne HTTP-Header):

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
                  xmlns:xsd="http://www.w3.org/2001/XMLSchema"
                  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <soapenv:Body>
    <ns1:validateResponse
     soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
     xmlns:ns1="urn:CardValidator">
      <addReturn xsi:type="xsd:boolean">true</addReturn>
    </ns1:validateResponse>
  </soapenv:Body>
</soapenv:Envelope>

Dieses Minimalbeispiel zeigt schon, dass SOAP gerade bei kleinen Aufrufen sehr viel Overhead produzieren kann und zudem nicht unbedingt intuitiv lesbar ist. Bei überlegtem Aufbau kann es aber deutlich flexibler und lesbarer als XML-RPC werden.

Inhalt | zurück | weiter