jim superfly

SOAP

Sowohl SOAP als auch HTTP gehören zu den Envelope-Protokollen, die Kopf (Header) und Körper (Body) mit einer Art Umschlag umschließen. Dabei kann SOAP als Kommunikationsprotokoll im Körper eines jeden Transfer-Protokolls versendet werden, da es transportunabhängig ist. Der hauptsächliche Datenverkehr von SOAP-Protokollen geschieht jedoch auf dem HTTP-Protokoll. Das bedeutet, dass der komplette SOAP-Envelope im HTTP-Körper enthalten ist. Voraussetzung dafür ist, dass der Inhalt des SOAP-Körpers auf XML basiert. Die Kombination aus HTTP-Nachricht mit XML-Dokument führt zu einer äußerst hohen Flexibilität und Kompatibilität, denn jede Firewall kennt das HTTP-Protokoll und jeder Parser ist in der Lage, XML zu lesen. Aus diesem Grund wurde SOAP entwickelt, denn veraltete RPC-Services, die auf HTTP aufsetzen, verursachen ein Sicherheitsrisiko und damit verbundene Inkompatibilitäten.

Trotz der HTTP-Kompatibilität enthält der SOAP-Envelope Definitionen im XML-Format, die einem RPC-Aufruf gleichen. Diese Ähnlichkeit zu XML-RPC führte zur Zusatz-Bezeichnung: SOAP-RPC. Von daher orientiert sich der Service an Informationen im Dokument anstatt auf dem Envelope, was zu unflexiblen komponentenbasierten (RPC) Funktionsaufrufen führt. Der Datenaustausch erfolgt zudem durch individuelle Methoden über den POST-Parameter innerhalb einer einzigen URI , wodurch keine Orientierung an der jeweiligen Ressource verfolgt wird, was charakteristisch für RPC-Verbindungen ist (siehe: Abb. 1). Im Gegensatz dazu verfolgt ein RESTful-Webservice eine Software-Architektur, in der jede Ressource einer eindeutigen URI zugeordnet ist.

Abb. 1: Routing von SOAP-Nachrichten im HTTP-POST [Bayer 2002, S.5]

Weiterhin missachtet SOAP-RPC die vorhandenen Möglichkeiten, die HTTP zum Beispiel für die Authentifizierung oder das Zwischenspeichern anbietet. Derartige HTTP-Funktionen müssen vom Entwickler selbstständig durch neue Vereinbarungen (Methoden) ersetzt werden. Dadurch ist der Nutzer an zustandsbehaftete Sessions gebunden, die vom Remote-Server künstlich aufgesetzt werden müssen. Dieser Umstand ist auf den permanenten Transport der Methoden und Operationen über den POST-Parameter zurückzuführen. Sicherheitsaspekte, wie zum Beispiel die Beschränkung des lokalen Zugriffs auf den GET-Parameter (nur Lesezugriff), sind dadurch unmöglich. SOAP-Nachrichten werden mit einer vermittelten URI übertragen, wodurch für einen Router jedes HTTP-Paket vollkommen identisch aussieht (Intransparenz). Eine Filterung über Router-Protokolle ist daher auch nicht möglich. Deshalb werden SOAP-Nachrichten von immer mehr Routern blockiert.

Folgende Syntax-Regeln sind laut W3C für eine SOAP-Nachricht einzuhalten:

• muss über das XML-Format kodiert sein
• muss einen SOAP-Envelope Namensraum besitzen
• muss einen SOAP-Encoding Namensraum besitzen
• darf keine Verarbeitungs-Anweisungen (Processing Instructions) enthalten
• darf keine DTD -Deklarationen (z.B.: DOCTYPE) enthalten

Um ein wohlgeformtes XML-Dokument mit SOAP zu kodieren, muss das XML-Dokument in den Körper des SOAP-Envelopes gepackt werden:

  <?xml version="1.0"?>
  <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
  soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
     <soap:Header>
     </soap:Header>
     <soap:Body>
        <example xmlns="http://example.com"/>
     </soap:Body>
  </soap:Envelope>

Der Envelope-Namensraum sitzt im Rootelement und definiert über eine URI den Envelope als SOAP-Envelope. Der Encoding-Style befindet sich als Attribut ebenfalls im Rootelement und definiert die Datentypen des enthaltenen Dokuments. Die Angabe des Headers ist optional, die vom Body zwingend notwendig.

Für SOAP und die mitgeführten Nachrichten sind keine weiteren Regelungen notwendig. Die Auswertung der mitgeführten Daten ist vom Empfänger-Programm durchzuführen. So gesehen steckt hinter SOAP nichts anderes als eine Vereinbarung für die Struktur des Envelopes übermittelter XML-Daten. Daher ist eine Absprache über die eingesetzte Webservice-Struktur zwischen Dienstleister (Remote-Server) und Konsument (lokaler Server) unerlässlich. Daraus resultiert eine praktische Unbrauchbarkeit, die zwischen verschiedenen Software-Plattformen (beispielsweise PHP und .NET ) sogar noch zusätzlichen Aufwand erfordert. Die Lösung zur Problematik stellt das WSDL-Protokoll dar.

REST

Der Ausdruck REST wurde erstmals in der Dissertation von Roy Fielding geprägt und beschreibt ein Paradigma der Software-Architektur für Web-Applikationen, dessen Zielsetzung folgendes, übersetztes Zitat verdeutlicht: „Die Motivation für die Entwicklung von REST bestand darin, ein architektonisches Vorbild zu erschaffen, das beschreibt wie das Web funktionieren sollte, so dass es als grundlegendes Rahmenwerk für die Standardisierung von Web-Protokollen dienen könnte. REST wurde angewandt um eine erwünschte Web-Architektur zu beschreiben, bestehende Probleme zu identifizieren, alternative Lösungen zu vergleichen und sicherzustellen, dass Protokoll-Erweiterungen keine Grundauflagen verletzen, die das Web erfolgreich als solches auszeichnen. Diese Arbeit wurde im Rahmen der IETF und W3C ermöglicht und bestrebt, architektonische Standards für das Web zu definieren: HTTP, URI und HTML.“ [Fielding 2000, S.107]

Hinter REST versteckt sich kein Webservice oder Web-Standard. Es handelt sich ausschließlich um ein Modell, das die Software-Architektur für die Entwicklung von Web-Applikationen, wie zum Beispiel Webservices, vorgibt. Eine Web-Applikation, die den geforderten Richtlinien entspricht, wird dementsprechend als RESTful deklariert.

Als architektonisches Paradigma für Web-Applikationen, dient REST der Verständigung zwischen Lokal- und Remote-Server. Die Anfrage und Manipulation von Web-Ressourcen des Remote-Systems, wird dabei lediglich durch standardisierte HTTP-Methoden realisiert: GET, POST, PUT und DELETE. Daher müssen keine weiteren Protokoll-Konventionen zwischen Lokal- und Remote-Server bekannt sein. Es handelt sich also um ein generisches Interface, das in etablierte Konventionen einfließt, anstatt neue zu definieren. Jede REST-Ressource adressiert dabei als URI eine einzigartige Entität, die wiederum Interaktionen durch das HTTP-Protokoll ermöglicht. Letztere ähneln einer bekannten Semantik aus SQL, über welche die üblichen Anwendungsfälle für Datenmanipulation abgedeckt werden: SELECT, INSERT, UPDATE und DELETE.

Die Bedeutung übermittelter Ressourcen ist durch REST jedoch nicht definiert. An dieser Stelle wird ein weiteres Mal auf das Nachrichten-Format XML gesetzt, das eine genormte, flexible und zugleich leicht verständliche Repräsentation von Inhalten ermöglicht, die zudem direkt über XSLT in andere Ausgabeformate transformierbar sind.
Sobald eine erfolgreiche Authentifizierung des Requests vorliegt, sind alle notwendigen Informationen (wie Autorisierung etc.) in einer URI als Einstiegspunkt für den Lokal-Server gekapselt. Es findet also keine sessionbasierte Authentifizierung statt, denn der Lokal-Server wird direkt über HTTP-Methoden für den Remote-Server authentifiziert. Steigt der Anwender tiefer in die Applikation ein, bleiben diese Informationen in der URI erhalten, was die Serverlast bei hohem Traffic minimiert. Die Fähigkeit zur „verbindungslosen“ Übertragung macht sich ebenfalls dann bemerkbar, wenn man seinen Status über XLinks verlässt und sich von Ressource zu Ressource „durchhangelt“. Dieses allgemeine Vorgehen – auch als sogenanntes „Surfen“ durch Hypertext Dokumente via Hyperlinks bekannt – wird durch REST erfolgreich auf zugangsbeschränkte Webservices transferiert. Dabei ermöglicht die Repräsentation den Zustands-Transfer mit Hilfe von Verweisen: REpresentational State Transfer. Abbildung 2 veranschaulicht einen beispielhaften Zustandstransfer, indem über die URL nach einander drei verschiedene Projekte (Ressourcen) manipuliert (je nach HTTP-Methode) werden:

Abb. 2: Ressourcen-Manipulation via URL nach REST [Wirdemann, Bausterd 2007, S.2]

Im Gegensatz zu SOAP oder XML-RPC, tunnelt ein RESTful-Webservice seine Nachrichten nicht im HTTP-POST einer einzigen URI (siehe: Abb. 1). Ein Router oder Proxy ist somit in der Lage, die Bedeutung der HTTP-Anfragen zu verstehen und durch entsprechende Zugriffsprotokolle zu filtern. Ebenso sind für die Server keine Clientstatus notwendig unter REST: „Im Web werden mit Cookies und URL Rewriting auf das statuslose HTTP künstlich Session aufgesetzt, die stateful sind. In diesem Punkt weicht REST vom Web ab. Interaktionen sind in REST stateless- jede Operation steht für sich. Alle notwendigen Informationen sind in den Repräsentationen der Resourcen enthalten. Mit HTTP gibt es keine Grenzen zwischen den Anwendungen. Durch die Verfolgung eines Links kann man, ohne es zu beabsichtigen, zu einer völlig anderen Anwendung gelangen. Da alle Interaktionen statuslos sind, muss daher bei einem Wechsel von einem Server zu einem anderen kein Status zwischen den Servern propagiert werden. Dies hat positive Auswirkungen auf die Skalierbarkeit einer Anwendung.“ [Bayer 2002, S.4]