Was AJAX-Entwickler über Web Services wissen sollten
Kommentare

XML
Die Übertragung von Daten in einer XML-Notation ist die echte Alternative zur Übertragung von Daten in JSON. Mit der Verwendung von XML sind die Probleme der Notation von Datentypen und komplexen

XML

Die Übertragung von Daten in einer XML-Notation ist die echte Alternative zur Übertragung von Daten in JSON. Mit der Verwendung von XML sind die Probleme der Notation von Datentypen und komplexen Objekten gelöst und es ist nicht notwendig, eigene Konventionen zu definieren. Anstatt sich an JavaScript zu orientieren, ist hierbei eine größere Nähe zu (X)HTML zu erkennen.

Inzwischen wird dieses Format von allen gängigen Browsern ebenfalls durch XML-Objekte unterstützt, und das XMLHttpRequest-Objekt ermöglicht es, dass Antworten vom Server in XML-Syntax direkt als XML-Dokument zur Verfügung stehen. XML-Dokumente sind bei großen Objekten deutlich performanter als JSON-Objekte. In den Browsern steht ein XSLT-Mechanismus zur Verfügung, der eine sehr effiziente Verarbeitung von XML-Daten und eine Umsetzung in HTML ermöglicht.

SOAP

Mit der Spezifikation SOAP (Simple Object Access Protocol) wurde 1999 ein auf XML basierender Standard definiert, der heutzutage eine erstaunliche Unterstützung und einen enormen Funktionszuwachs von verschiedenen Plattformen und Herstellern bekommt. Aus den Anfängen ist das Statement von Dave Wine, einem der SOAP-Väter bekannt: „The purpose of both specs [SOAP and XML-RPC] is to enable scripted web applications to cross operating system boundaries.“ Das ist auch eine Umschreibung für die Architektur, die heute unter AJAX bekannt ist. In der einfachsten Form besteht SOAP aus einem standardisierten XML-Dokument, das über http oder https von einem Client an einen Server übertragen wird und vom Server mit einer Antwort quittiert wird. Das Protokoll folgt damit genau dem Ansatz, der auch mit dem XMLHttpRequest-Objekt realisiert werden kann. Die gegenüber der Übertragung von reinem Text oder JSON-Ausdrücken erhöhte Komplexität von SOAP kommt primär davon, dass das Protokoll von Anfang an so aufgesetzt wurde, dass es problemlos erweiterbar ist. Das ermöglicht die zusätzliche Integration von Mechanismen wie z.B. Signaturen oder Routing-Information. Eine auf das Wesentliche gekürzte Anfrage an einen Server zeigt Listing 6.

Listing 6
------------------------------------------------------------------
POST /AJAXEngine/S03_AJAXControls/BibleData.asmx HTTP/1.1
...
soapaction: "http://www.mathertel.de/BibleData/GetVers"
Content-Type: text/xml; charset=utf-8
Host: www.mathertel.de
Content-Length: 236

luther1912;43;3;16

Die Antwort ist sehr ähnlich wie die Abfrage strukturiert (Listing 7).

Listing 7
-------------------------------------------------------------------
HTTP/1.1 200 OK
...
Cache-Control: private, max-age=0
Content-Type: text/xml; charset=utf-8
Content-Length: 558

 Also hat Gott die Welt geliebt, daß er seinen eingeborenen Sohn gab, auf daß alle, die an ihn glauben, nicht verloren werden, sondern das ewige Leben haben.

SOAP ist als Protokoll für eine Client-Server-Kommunikation im Web deswegen besonders geeignet, weil von Anfang an eine dem Web ähnliche Art der Datenübertragung vorgesehen wurde. Es kann exakt der Port des Webservers verwendet werden, der auch für die Abfrage von normalen Seiten und Grafiken verwendet wird. Das http-Protokoll war die erste spezifizierte Übertragungsmethode. Eine Implementierung eines SOAP-Clients existiert für den Microsoft Internet Explorer bereits seit ca. 1999 in der Form eines Behaviours. Inzwischen existieren für alle Server-Plattformen entsprechende SOAP-Implementierungen, sodass hier von einem echten Cross-Plattform-Standard gesprochen werden kann. SOAP-Nachrichten können im Browser erzeugt und verarbeitet werden. Im Internet gibt es einige Low-level-Beispiele, die aufzeigen, wie XML zusammengesetzt werden kann, um ein entsprechendes XML-Dokument zu erhalten. Wesentlich interessanter ist es aber, dass passend zu SOAP auch WSDL (Web Services Description Language) existiert, eine standardisierte Spezifikation der für einen SOAP-Aufruf notwendigen XML-Daten. Anhand dieser XML-basierten Definition ist es in den Hochsprachen möglich, Proxy-Klassen zu erzeugen und diese in die Implementierung der Kommunikationspartner einzubinden. Dieser Mechanismus kann auch in JavaScript-Applikationen angewendet werden. Das Behaviour für den IE von Microsoft lädt zur Laufzeit eine WSDL vom Server und generiert entsprechende JavaScript-Objekte, um die Funktionen des Servers aufzurufen. Die Implementierung, die hier und anderen AJAX-Frameworks verwendet wird, generiert JavaScript-Code bereits auf dem Server und funktioniert auch für Mozilla/Firefox und den Safari-Browser.

Plädoyer für SOAP

Um AJAX-Anwendungen zu realisieren, muss sowohl auf dem Server als auch auf dem Client der notwendige Code zum Austausch von asynchronen Nachrichten implementiert werden. Webserver-Plattformen, die bereits einen SOAP-Server als Bestandteil anbieten, stellen damit bereits schon alle Funktionalitäten standardisiert zur Verfügung. Der Aufwand der Implementierung eines serverseitigen Frameworks entfällt damit komplett – es muss natürlich die Funktionalität der Anwendung realisiert werden. Daneben ist es bereits mehrfach vorgekommen, dass gerade durch die neue Realisierung von AJAX-fähigen Services eine Sicherheitslücke im Server aufgemacht wurde. Die Gefahr, dass Buffer Overflow in Standard-SOAP-Servern von Microsoft oder Sun zu Problemen führen, ist dagegen eher gering, denn die Aufmerksamkeit auf diese Server ist aktuell sehr hoch. SOAP und die darauf basierte Web-Services-Infrastruktur entwickeln sich weiter:

  • SOAP beinhaltet eine Spezifikation für Exceptions. Die meisten Serverplattformen und JavaScript sind ebenfalls in der Lage, Exceptions zu erzeugen und zu verarbeiten. Das bringt enorme Vorteile, insbesondere bei größeren und komplexeren Architekturen.
  • Mit der aktuellen SOAP-Spezifikation 1.2 wurde die im Anfang noch verwendete eigene Beschreibung von Datentypen zugunsten von XML Schema aufgegeben.
  • SOAP-Erweiterungen, wie z.B. WS-Adressing, WS-Security oder WS-Routing, bringen weitere Konzepte und Funktionalitäten in das Protokoll.
  • SOAP wird aktuell nicht direkt vom Browser unterstützt. Der Versuch eines entsprechenden Objekts im Firefox funktioniert nicht stabil. Wenn es in Zukunft im Browser eine standardisierte Komponente für den Aufruf von Web Services geben könnte, dann wird sicher SOAP die erste Wahl sein. Ein entsprechendes ActiveX-Control von Microsoft existiert bereits auf Rechnern mit einer Office-2003-Installation.
  • XML-Daten sind durch ein XSLT direkt in JSON-Objekte konvertierbar, sodass auch diese Art der Einbindung in JavaScript möglich ist.
  • AJAX mit SOAP und WSDL basiert auf bereits im Web  etablierten Standards.

Alle diese Gründe zeigen auf, dass der anfängliche Mehraufwand bei der Implementierung eines SOAP Clients zur direkten Kommunikation mit Web Services gerechtfertigt ist.

Zum Schluss

Die Entscheidung „selber machen“ oder „kaufen“ bzw. „standardisiertes Protokoll“ oder „eigenes Protokoll“ muss jeder für sich selbst treffen. Die Protokollebene liefert aber einige Aspekte für eine fundierte Entscheidung. Ein Verständnis, was da tatsächlich auf dem http-Kanal übertragen wird, ist in jedem Fall hilfreich und spätestens bei der Fehleranalyse unabdingbar.

Matthias Hertel ist Leiter der Anwendungsentwicklung Technologie bei der Deutschen Bank Bauspar AG. Seit mehr als sechs Jahren ist die Realisierung von softwareorientierten Webapplikationen mithilfe von Web Services und AJAX-Technologien einer der technischen Schwerpunkte seiner Arbeit.
Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -