Vergleich SOAP und REST

Seminar: Komponentenorientierte Softwareentwicklung und Hypermedia

Fachhochschule Dortmund Fachbereich Informatik

Betreuer: Prof. Dr. Thiesing

Thomas Kloster - 7042882 Oskar Martin - 7042911

SS 2004 / Mai 2004

Seite 1 von 40

Inhaltsverzeichnis

1 Einführung ........................................................................................................................ 3 1.1 Was sind Web Services ............................................................................................ 3 1.2 Anwendungsgebiete von Web Services .................................................................. 4

2 SOAP ................................................................................................................................. 6 2.1 Was ist SOAP?.......................................................................................................... 6 2.2 Wie wird SOAP benutzt? ........................................................................................ 7 2.3 Struktur von SOAP-Nachrichten ........................................................................... 7

2.3.1 SOAP-Envelope ................................................................................................ 8 2.3.2 SOAP-Header ................................................................................................... 9 2.3.3 SOAP-Body ....................................................................................................... 9 2.3.4 SOAP-Attachments ........................................................................................ 10 2.3.5 SOAP-Fault..................................................................................................... 10

2.4 Beispiel für eine SOAP-Nachricht ........................................................................ 11 2.5 SOAP Encoding ...................................................................................................... 12

3 REST ............................................................................................................................... 17 3.1 Was ist REST? ........................................................................................................ 17 3.2 Merkmale einer REST-Anwendung ..................................................................... 17 3.3 HTTP ....................................................................................................................... 18

3.3.1 HTTP-Anfrage................................................................................................ 18 3.3.2 HTTP-Antwort ............................................................................................... 19 3.3.3 Der HTTP-Message-Header.......................................................................... 20

3.4 REST in Verbindung mit Web Services............................................................... 21 3.5 REST-Applikation am Beispiel von sqlREST ..................................................... 23

3.5.1 Abfragen erstellen .......................................................................................... 24 3.5.2 Daten manipulieren....................................................................................... 26

3.6 Goldene Regeln bei der Implementierung von REST Web Services................. 26 4 Vergleich SOAP und REST........................................................................................... 28

4.1 Implementierung .................................................................................................... 28 4.2 Funktionsweise ....................................................................................................... 28 4.3 Sicherheit................................................................................................................. 29 4.4 Skalierbarkeit / Effizienz ....................................................................................... 30 4.5 Fazit undAusblick................................................................................................... 31

5 Fallbeispiel: Amazon Web Service ............................................................................... 32 5.1 SOAP ....................................................................................................................... 33 5.2 REST ....................................................................................................................... 35

A Abbildungsverzeichnis ..................................................................................................... 38 B Abkürzungsverzeichnis .................................................................................................... 39 C Literaturverzeichnis ......................................................................................................... 40

Seite 2 von 40

1 Einführung 1.1 Was sind Web Services? Unter Web Services versteht man eine im Internet veröffentlichte Software, die über Standardschnittstellen angesprochen wird. Die Interaktion zwischen Client und Server geschieht durch den Austausch XML-basierter Nachrichten, die mittels Internetprotokollen übertragen werden. Da Web Services ein Internetdienst sind, müssen die eingesetzten Technologien Plattformunabhängig und Unabhängig von einer bestimmten Programmiersprache sein. Wenn man im Internet nach einer Definition zu Web Service sucht, wird man vielerorts fündig. Die vielen unterschiedlichen Interpretationen spiegeln die zahlreichen Anwendungsgebiete und Implementierungsmöglichkeiten wider. Das W3C definiert Web Services wie folgt: “A software application identified by a URI (Universal Resource Identifier), whose interfaces and bindings are capable of being defined, described and discovered by XML artifacts, and supports direct interactions with other software applications using XML based messages via internet-based protocols" [1] Es haben sich drei Standards entwickelt, um Web Services zu ermöglichen: SOAP, WSDL und UDDI. Die drei Technologien ergänzen sich, sind aber unabhängig voneinander. SOAP übernimmt die Aufgabe des Protokolls. Es enthält die Nachricht, die vom Server zum Client und umgekehrt übertragen wird. Bei WSDL handelt es sich um die Beschreibungssprache für Web Services. Beschrieben werden die Operationen und Nachrichten, unabhängig von den Netzwerkprotokollen, die zur Kommunikation benutzt werden. Sowohl SOAP als auch WSDL basieren auf XML. Der Service Provider veröffentlicht seinen Service bei einem Service Broker. Er legt hierzu die WSDL-Datei in einem UDDI Register ab. Im UDDI Verzeichnis findet man außerdem Informationen zum Web Service Anbieter und eine technische Beschreibung, die den Service mit allen Funktionen beschreibt. Wir werden im weiteren Verlauf größtenteils auf den Standard SOAP und die Alternative REST eingehen, diese genauer erläutern und zum Abschluss miteinander vergleichen.

Abbildung 1: Web Service Architektur

Seite 3 von 40

1.2 Anwendungsgebiete von Web Services Der Einsatz des Internets findet weltweit immer mehr Interesse. Man versucht es in allen Bereichen unseres Lebens, sei es im Beruf als auch im Alltag, einzubinden. Die Recherche im Internet nach Informationen ist heute gängige Praxis. Der Mensch sucht mehr oder weniger gezielt nach Informationen. Er ruft also Daten und Funktionalität von einem Web Server auf. Web Services gehen da den umgekehrten Weg. Der Mensch übernimmt hier nicht mehr die aktive Rolle, die das Internet durchsucht, sondern er bekommt die Informationen, die er benötigt vom Web Service. Als Beispiel soll hier die Suche nach einem Preis für ein Artikel dienen. Im klassischen Fall würde der Suchende das Internet bei ihm bekannten Webshops nach dem günstigsten Preis durchstöbern. Nutzt er hingegen einen Web Service leistet dieser die eigentliche Arbeit. Als Ergebnis erhält der Nutzer des Services Preise von allen Webshops, die er dann miteinander vergleichen kann.

Abbildung 2: Mensch-zu-Computer-Interaktion

Neben der Mensch-zu-Computer-Interaktion gibt es die Computer-zu-Computer-Interaktion. Hier ist keiner der Kommunikationspartner ein Mensch. Eine Maschine bezeichnet hier eine Software Applikation, die beispielsweise auf einem Server liegt. Das Ergebnis der Services ist nicht nur im Browser, sondern auch in anderen Applikationen verfügbar. Heutzutage wickeln immer mehr Unternehmen einen Großteil ihrer Geschäfte elektronisch ab. Das hat zur Folge, dass der Mensch als Einflussgröße in den Hintergrund tritt und die Anwendungen ohne menschliches Zutun miteinander kommunizieren. Web Services sind ein Ansatz dieses Problem zu lösen. Die Grundidee ist, dass Anwendungen ihre Funktionalitäten und Inhalte anderen Anwendungen auf standardisierte und transparente Weise zur Verfügung stellen.

Abbildung 3: Computer-zu-Computer-Interaktion

Seite 4 von 40

Diese Konzept wird teilweise in CORBA, RMI und COM+/DCOM verwendet. Neu ist allerdings, dass Web Services neben Remote Procedure Calls (RPC) auch dokumentenbasierte Nachrichten verarbeiten können. Web Services sind im Vergleich zu CORBA sehr einfach zu handhaben und können auch problemlos von Systemen hinter einer Firewall ausgeführt werden, weil als Transportprotokoll HTTP eingesetzt werden kann. Es sind schon viele Web Services im Internet verfügbar. Die bekanntesten sind Google, Babelfish und Amazon. Diese drei haben eines gemeinsam: Sie funktionieren alle einseitig. Man kann also nur Daten abrufen, aber keine bearbeiten, löschen oder hinzufügen. Web Services erlauben aber auch eine Kommunikation in beide Richtungen. Vorstellbar wäre zum Beispiel ein Warenwirtschaftssystem, um Zulieferer einer Firma in das eigene System einzubinden. Auf Amazon wird in Kapitel 5 noch genauer eingegangen und ein Fallbeispiel dazu vorgestellt.

Seite 5 von 40

2 SOAP 2.1 Was ist SOAP? SOAP steht für Simple Object Access Protocol. Dieser Begriff entwickelt sich aber immer mehr zu einem Eigennamen. SOAP ist ein Teil von Web Services und wird für die elektronische Abwicklung von Geschäften der Unternehmen über verteilte Umgebungen wie das Internet benutzt. Es ist ein auf XML basierendes Protokoll zum Austausch strukturierter Informationen und unterliegt dem W3C-Standard. Zurzeit ist die Version 1.2 aktuell. Der große Vorteil von SOAP ist, dass dieses Protokoll plattform- und programmiersprachen-unabhängig ist, aber der Quelltext weiterhin ein lesbarer Text (human readable) bleibt. Ähnlich wie bei RMI kann SOAP Methoden, Services, Komponenten und Objekte auf entfernten Servern aufrufen. SOAP benutzt dafür das Textformat in Verbindung mit XML. SOAP kann als ein Framework für XML-Nachrichten angesehen werden und bietet nur die minimale Grundfunktionalität. Daher sind Merkmale wie Routing, Sicherheit und Verlässlichkeit nicht im Standard enthalten, können aber durch beliebige Erweiterungen zur Verfügung gestellt werden. SOAP ist auf kein bestimmtes Transportprotokoll festgelegt, üblicherweise wird aber HTTP verwendet. SOAP übernimmt bei der Kommunikation zwischen Web Service-Nutzer und –Anbieter die Verpackung, Strukturierung und Kapselung der auszutauschenden Informationen.

Abbildung 4: 3 Schichten-Modell

Seite 6 von 40

2.2 Wie wird SOAP benutzt? SOAP kann auf zwei Arten genutzt werden. Entweder über Remote Procedure Calls (RPC) oder über dokumentenbasierten Nachrichtenaustausch. Bei RPC ruft die SOAP-fähige Anwendung entfernte Methoden des Servers per Web Services auf. Dabei ist es unrelevant in welcher Programmiersprache die entfernte Methode geschrieben ist und welches Betriebssystem der Server verwendet. Es werden in der SOAP-Nachricht beim Methodenaufruf nur der Methodenname und die Parameter übertragen. Nach Ausführen der entfernten Methode wird das Ergebnis vom Web Service per SOAP zum Client übermittelt. Anwendungsgebiete dafür sind Berechnung und Prüfung von Informationen zum Beispiel Stauprüfung von Navigationssystemen. Im Gegensatz zu RPC wird beim dokumentenbasierten Nachrichtenaustausch keine entfernte Methode aufgerufen. Es werden strukturierte Informationen versendet und falls der Empfänger ein Web Services ist, werden diese Informationen verarbeitet und das Ergebnis sofort oder zeitlich versetzt zum Sender zurück geschickt. Auch hier spielen die Programmiersprache und das Betriebssystem keine Rolle. Aber um die Kompatibilität der verschiedenen Systeme gewährleisten zu können, muss die innere Struktur der SOAP-Nachricht exakt festgelegt werden. Diese Struktur wird in der WSDL festgelegt. Die WSDL dient zur Beschreibung der Schnittstellen des Web Services und dient als Implementierungsgrundlage für Client-Programme. Während dokumentenbasierte Nachrichten oft sehr aufwendig „per Hand“ programmiert werden muss, gibt es für RPC-Aufrufe Tools, die anhand eines WSDL-Dokumentes die passenden Klassen generieren. Von der eigentlichen SOAP-Nachricht sieht man in diesem Fall meistens nichts. Die Funktion und Parameter müssen angegeben werden, damit der Client diese in eine SOAP-Nachricht transformieren kann. Dies geschieht verkapselt, also vom Client verborgen. Der Server ruft die Funktion mit den entsprechenden Parametern auf, generiert wiederum eine SOAP-Nachricht und sendet sie zurück. Der Client bekommt auch hier wieder von SOAP gar nichts zu sehen, da die Nachricht wieder in den erwarteten Rückgabetyp transformiert wird. 2.3 Struktur von SOAP-Nachrichten Ein SOAP-Paket darf einen Transport-Header enthalten. Als Transportmittel können sowohl HTTP als auch SMTP, FTP, POP3 und andere Protokolle verwendet werden. Ein SOAP-Paket muss immer über eine SOAP-Message verfügen. Eine SOAP-Message

- muss mit XML verpackt werden, - muss einen SOAP-Envelope enthalten, - darf einen SOAP-Header enthalten, - muss einen SOAP-Body enthalten, - muss SOAP-Envelope-Namespace verwenden, - darf keine DTD (Data Type Definition) enthalten und - darf keine XML Processing Instructions enthalten (wie die Nachricht weiterverarbeitet

werden soll).

Seite 7 von 40

Abbildung 5: Aufbau einer SOAP-Nachricht

2.3.1 SOAP-Envelope Das Grundgerüst einer SOAP-Nachricht ist die SOAP-Envelope. Die Envelope ist ein Behälter, vergleichbar mit einem Briefumschlag, um den Inhalt und Zweck der Botschaft zu beschreiben. Ohne dieses Gerüst entspricht die Nachricht nicht dem gültigen SOAP-Format, wie vom W3C gefordert, und kann somit nicht als SOAP-Nachricht erkannt werden. In der SOAP-Envelope ist der SOAP-Header und der SOAP-Body enthalten. Falls ein SOAP-Header angegeben werden soll, muss dieser zwingend vor dem Body stehen.

<?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">

< !-- optionaler SOAP-Header --> < !-- SOAP-Body -->

</env:Envelope>

Abbildung 6: SOAP-Envelope

Die Envelope enthält außerdem Attribute mit zusätzlichen Informationen. Als erstes wird die XML-Version ( hier „1.0“) angegeben. Dies ist im Einklang mit dem XML-Standard. Danach wird die verwendete Zeichnkodierung (hier „UTF-8“) geschrieben. Nicht enthalten sind Adressangaben der Absenders und Empfängers. Dies ist Aufgabe des Transportprotokolls. Als nächstes beginnt die eigentliche SOAP-Envelope, in der das Attribut xmlns, das die URL zur Definition der SOAP-Envelope angibt, enthalten ist. Die aktuelle URL der Version 1.2 lautet „http://www.w3.org/2003/05/soap-envelope“.

Seite 8 von 40

2.3.2 SOAP-Header Der SOAP-Header ist ein optionaler Bestandteil der Nachricht. Wenn es einen Header gibt muss er unbedingt, wie bereits oben erwähnt, vor dem Body stehen. Die Funktion des Headers ist inhaltsunabhängige Daten und anwendungsspezifische Angaben, wie eine eindeutige Message-ID, anzugeben. Falls ein Empfänger diese Daten nicht verarbeiten kann, führt das nicht zu Fehlern oder Problemen, da dann der Header ignoriert wird. Mit dem Attribut „mustUnderstand“ kann die Interpretation des Headers aber erzwungen werden. Um diese Funktionalität zu erreichen, muss der Wert des Attributes „true“ sein. Kann die Empfänger in diesem Fall den Header nicht verstehen, so wird die Prozedur mit einer Fehlermeldung beendet.

<env:Header>

<x:ersterBlock xmlns:x="http://example.com" env:mustUnderstand="true"> ... </x:ersterBlock>

<y:zweiterBlock xmlns:y="http://example.com"> ... </y:zweiterBlock> </env:Header>

Abbildung 7: SOAP-Header

Ein SOAP-Header kann mehrere Blöcke besitzen. Das obige Beispiel besteht aus zwei Blöcken. Der erste Block muss interpretiert werden, ansonsten wird eine Fehlermeldung zurückgegeben. Wenn der zweite Block nicht verarbeitet werden kann, wird dieser einfach ignoriert. 2.3.3 SOAP-Body Der SOAP-Body muss genau einmal in der Nachricht enthalten sein. Der Inhalt des Body repräsentiert die eigentliche Nachricht mit den Informationen zum Funktionsaufruf: Methodenname, Parameterliste und Rückgabewert. Es gibt keine vorgeschriebene Spezifikation für die Struktur des Body. Die einzige Bedingung ist, dass der Inhalt im XML-Format geschrieben sein muss.

<env:Body>

< !— Inhalt im XML-Format --> </env:Body>

Abbildung 8: SOAP-Body

Seite 9 von 40

2.3.4 SOAP-Attachments SOAP Attachment ist optional und nicht Bestandteil der Envelope. Es wird zum Anhängen von Dokumenten verwendet. Die Nachricht kann also außer dem Inhalt zum Funktionsaufruf im Body auch eine Datei liefern. Es gibt keine Beschränkung für das Dateiformat. Man kann von der Videodatei bis zum XML-Dokument alles anhängen. 2.3.5 SOAP-Fault Das Fault-Element wird benutzt, um Informationen über eventuell aufgetretene Fehler in einer SOAP-Nachricht zu übermitteln. Es ist optional, wird es aber benutzt, muss es im Body definiert werden. Das Fault-Element besteht aus den Unterelementen, „Code“ und „Reason“, und den optionalen Elementen „Node“, „Role“ und „Detail“:

- Code: Das Code-Element dient zur Fehlerklassifizierung. Es muss in jedem Fault-Element vorhanden sein. SOAP bietet einige vordefinierte Werte, die das Code-Element annehmen kann (VersionMismatch, MustUnderstand, DataEncodingUnknown, Sender und Receiver)

- Reason: Das Reason-Element ist ebenfalls ein Musskriterium der SOAP-Fault. Es

dient der menschenlesbaren Fehlerbeschreibung.

- Node: Das Node-Element ist optional. Es gibt an in welchem Nodes der Fehler aufgetreten ist.

- Role: Das Role-Element ist eine Spezifizierung des Node-Elementes. Es bezeichnet

die Funktion des Nodes, welche beim Eintreten des Fehlers ausgeführt wurde. Auch diese Element ist optional.

- Detail: Im Detail stehen weitere Informationen zum Fehler. Es kann als

Bemerkungsfeld dienen und ist kein Pflichtfeld.

<env:Body> <env:Fault> <env:Code> <env:Value>env:Sender</env:Value> <env:Subcode> <env:Value>m:MessageTimeout</env:Value> </env:Subcode> </env:Code> <env:Reason> <env:Text xml:lang="en">Sender Timeout</env:Text> </env:Reason> <env:Detail> <m:MaxTime>P5M</m:MaxTime> </env:Detail> </env:Fault> </env:Body>

Abbildung 9: SOAP-Body

Seite 10 von 40

2.4 Beispiel für eine SOAP-Nachricht Im Folgenden Beispiel wird eine Flugbuchung bei einem Reiseunternehmen per SOAP-Message getätigt. Herr Mustermann möchte gerne am 29.05.2004 morgens von Düsseldorf nach München in der Businessklasse fliegen. Als Antwort soll der Empfänger nach Verarbeitung der Operation String setReservation(String, String, String, String)die Reservierungsnummer zurückgeben.

<?xml version='1.0' encoding="UTF-8?> <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> <env:Header> <m:reservation xmlns:m="http://travelcompany.org/reservation" env:role="http://www.w3.org/2003/05/soap-envelope/role/next" env:mustUnderstand="true"> <m:reference>uuid:093a2da1-q345-739r-ba5d</m:reference> <m:date>2004-05-10</m:date> </m:reservation> <n:passenger xmlns:n="http://mycompany.com/employees" env:role="http://www.w3.org/2003/05/soap-envelope/role/next" env:mustUnderstand="true"> <n:name>Max Mustermann</n:name> </n:passenger> </env:Header> <env:Body> <p:itinerary xmlns:p="http://travelcompany.org/reservation/travel"> <p:setReservation> <p:departing>Duesseldorf</p:departing> <p:arriving>Muenchen</p:arriving> <p:departureDate>2004-05-29</p:departureDate> <p:departureTime>mid-morning</p:departureTime> <p:class>business</p:class> </p:setReservation> </p:itinerary> <q:lodging xmlns:q="http://travelcompany.org/reservation/hotels"> <q:preference>none</q:preference> </q:lodging> </env:Body> </env:Envelope>

Abbildung 10: Beispiel für SOAP-Anfrage als RPC

Alternativ könnte man die Anfrage auch dokumentebasiert senden. In diesem Fall würde keine Operation (setReservation) aufgerufen, sondern der Empfänger extrahiert aus der SOAP-Nachricht die Flugdaten. Es wird aber die gleiche Antwort zurückgegeben wie bei der RPC-Anfrage. Der fettgedruckte Text ändert sich wie folgt:

<departing>Duesseldorf</departing> <arriving>Muenchen</arriving> <departureDate>2004-05-29</departureDate> <departureTime>mid-morning</departureTime> <class>business</class>

Abbildung 11: Beispiel für SOAP-Anfrage als dokumentenbasierte Nachricht

Seite 11 von 40

In beiden Beispielen wird die Abbildung 7 dargestellte Antwort zurückgesendet. Obwohl die eigentliche Nachricht nur eine Zeile umfasst, entsteht in SOAP ein nicht zu verachtender Overhead, der sich negativ auf die Performance auswirkt.

<?xml version='1.0' encoding="UTF-8?> <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> <env:Header> <m:reservation xmlns:m="http://travelcompany.org/reservation" env:role="http://www.w3.org/2003/05/soap-envelope/role/next" env:mustUnderstand="true"> <m:reference>uuid: 093a2da1-q345-739r-ba5d</m:reference> <m:date>2004-05-10</m:date> </m:reservation> <n:passenger xmlns:n="http://mycompany.com/employees" env:role="http://www.w3.org/2003/05/soap-envelope/role/next" env:mustUnderstand="true"> <n:name>Max Mustermann</n:name> </n:passenger> </env:Header> <env:Body> <p:itinerary xmlns:p="http://travelcompany.org/reservation/travel"> <p:reservationnumber>FA87654</p:reservationnumber> </p:itinerary> </env:Body> </env:Envelope>

Abbildung 12: Beispiel für eine SOAP-Antwort

2.5 SOAP Encoding Unter SOAP-Encoding versteht man die Definition der einzelnen Datentypen und deren Zuordnung zu den einzelnen Elementen. Das Attribut „encodingStyle im Body gibt die Regeln zur Serialisierung von SOAP-Nachrichten an. Man kann entweder eine eigene Regel im XML-Format definieren oder den Standard des W3C benutzen. „http://www.w3.org/2003/05/soap-encoding“ W3C-Standard „http://example.org/encoding“ eigene Definition „http://www.w3.org/2003/05/soap-envelope/encoding/none“ keine Regel Es wird zwischen einfache und zusammengesetzte Datentypen unterschieden. In SOAP erfolgt die Serialisierung in zwei Schritten:

- Formen des XML-Schemas aus dem Datenmodell - Erzeugung der XML-Datei aus dem Schema und den Daten

Bei der Deserialisierung wird dann aus der XML-Instanz unter Kenntnis des zugrundeliegenden Schemas eine Kopie des Datenbestands erstellt. Für jedes Element, das nicht leer ist, muss der Datentyp des enthaltenen Werts auf eine der folgenden Arten angegeben werden:

Seite 12 von 40

- der Name des Elements enthält einen Hinweis auf den Datentyp, der dann aus der zugrundliegenden Schemadatei entnommen werden kann

- das Element besitzt ein xsi:type-Attribut, durch welches der Typ definiert wird - das Element selbst befindet sich in einem Array, dessen Typ durch das SOAP-

ENC:arrayType-Attribut definiert wurde Ein einfacher Wert wird als Character Data, also ohne irgendwelche Subelemente, dargestellt. Er muss von einem in der XML Schema-Spezifikation aufgelisteten Typ sein. Dagegen besteht ein zusammengesetzter Datentyp aus einer Menge von Elementen, wobei jedes Teilelement von einem eigenen Unterelement repräsentiert wird. Enthält ein Element kein Wert, so wird ein Default-Wert angenommen. In den meisten Fällen wird der null als Default-Wert herangezogen, wobei die exakte Null-Repräsentation sich nach dem Datentyp des Wertes richtet. Im Fall eines Boolschen Wertes impliziert die Abwesenheit False, im Fall eines Integers 0. Für einfache Datentypen übernimmt SOAP die XML-Standardtypen, die in der Sektion "Built-in datatypes" der XML-Schema-Spezifikation enthalten sind.

Abbildung 13: Built-in Datatype Hierarchy [9]

Seite 13 von 40

Diese Datentypen dürfen dann direkt in Element- Schemata verwendet werden. Ein Beispiel:

<element name="student" type="string"/> <element name="matrikelnummer" type="int"/> <element name="fachbereich" type="string"/> <element name="fachrichtung"> <simpleType base="xsd:string"> <enumeration value="AI"/> <enumeration value="MI"/>

<enumeration value="TI"/> <enumeration value="WI"/> </simpleType>

Mit obigem Schema korrespondiert jetzt z. B. der folgende Datenblock:

<student> Mustermann</student> <matrikelnummer>7053848</matrikelnummer > <fachbereich>Informatik</fachbereich > <fachrichtung>WI</fachrichtung >

Abbildung 14: Eigenes XML-Schema mit korrespondierende XML-Datei

In der XML-Schema-Deklaration wird ein Mechanismus der Aufzählung definiert, welcher vom SOAP direkt übernommen wird. Ein Element eines Aufzählungstypen, also einer Liste von möglichen Werten, wird dabei durch den Namen des Werts identifiziert. Dies wird am obigen Beispiel deutlich, wo die Fachrichtung nur die Ausprägungen „AI“, „MI“, „TI“ oder „WI“ von Typ String annehmen kann. Viele Programmiersprachen unterstützen Variablen, deren Daten während der Laufzeit auf unterschiedliche Art und Weise interpretiert werden können. Eine solche Variableninstanz muss in SOAP das xsi:type-Attribut besitzen, welches den Typ des aktuellen Werts beschreibt. In SOAP werden zwei Arten von zusammengesetzten Datentypen definiert, Structs und Arrays. In Structs ist der Elementname die einzige Möglichkeit zur Unterscheidung von Subelementen, wobei die Elementnamen einzigartig sein müssen. In Arrays werden die einzelnen Werte durch ihre Position identifiziert. Die einzelnen Bestandteile eines zusammengesetzten Wertes werden durch einzelne Unterelemente repräsentiert, wobei jedes einzelne Subelement durch seinen Namen eindeutig identifiziert werden kann. Die dabei benutzen Elementnamen sind nur lokal sichtbar in Bezug auf den gesamten Struct, oder müssen voll qualifiziert angegeben. Natürlich können Structs ihrerseits auch wieder Structs enthalten. Ein Struct, der ein Buch beschreibt, könnte etwa so aussehen:

Seite 14 von 40

<e:Buch> <autor>Ken Follest</autor> <titel>Die Säulen der Erde</titel> <verlag>Bastei Luebbe</verlag> <preis>32.95</preis> </e:Buch>

Dieser Datenstruktur könnte das folgende XML-Schema-Fragment zugrunde liegen:

<element name="Buch"> <complexType> <element name="autor" type="xsd:string"/> <element name="titel" type="xsd:string"/> <element name="verlag" type="xsd:string"/> <element name="preis" type="xsd:float"/> </complexType>

Abbildung 15: Erweiterter Datentyp - Struct mit XML-Schema

Anstatt einen Wert direkt in ein Element einzufügen kann auch auf ein anderes Element verwiesen werden, in welchem dieser Wert zu finden ist. Dabei wird ein Wert durch die ihm zugewiesene ID vom Typ "ID" (nach der XML-Spezifikation) identifiziert. Jedes Element, dass auf ein anderes verweist, ist selbst leer und besitzt ein href-Attribut vom Typ "uri-reference" (nach der XML-Schema-Spezifikation). Diese Methode der Referenzierung verhindert das Bilden von redundanten Daten. Solche Referenzen sind auch über mehrere Ebenen möglich:

<e:Buch> <autor href="#pDF"/> <titel>Objektorientierung in 7 Tagen</titel> </e:Buch> <e:Buch> <autor href="#pDF"/> <titel>Lehrbuch der Objektmodellierung</titel> </e:Buch> <e:Person id="pDF"> <name>Heide Balzert</name> <adresse href="#adrDF"/> </e:Person> <e:adresse id="adrDF"> <email>mailto:balzert@fh-dortmund.de</email> <www>http://www.fh-dortmund.de</www> </e:adresse>

Abbildung 16: Referenzen nach XML-Schema

In SOAP werden Arrays durch die Werte ihrer Element repräsentiert, wobei der Elementname bei der Identifikation keine Rolle spielt. Da Arrays eine geordnete Sequenz von Elementen beinhalten, werden einzelne Elemente durch ihre Position im Array identifiziert. Ein Array kann alle möglichen Datentypen enthalten, auch weitere Arrays:

Seite 15 von 40

<primzahlen SOAP-ENC:arrayType="xsd:int[2]"> <zahl>3</zahl> <zahl>5</zahl> </primzahlen>

Zu diesem Array würde das folgende Schema-Fragment passen:

<element name="primzahlen" type="SOAP-ENC:Array"/>

Abbildung 17: 1. Möglichkeit zur Darstellung eines XML-Arrays

Eine alternative Form, dieses Array abzubilden, wäre, zu jedem Element den im SOAP- ENC-Schema vordefinierten Datentyp zu benutzen. Dabei korrespondiert dann der Elementname mit dem Datentyp:

<SOAP-ENC:Array SOAP-ENC:arrayType="xsd:int[2]"> <SOAP-ENC:int>3</SOAP-ENC:int> <SOAP-ENC:int>5</SOAP-ENC:int> </SOAP-ENC:Array>

Abbildung 18: 2. Möglichkeit zur Darstellung eines XML-Arrays

Seite 16 von 40

3 REST 3.1 Was ist REST? REST ist die Abkürzung für Representational State Transfer. Bei REST handelt es sich nicht wie bei SOAP um einen Standard, sondern um eine Softwarearchitektur zur Erstellung von Web Services. Dieser Stil wird in der Dissertation von Thomas Roy Fielding, einem Mitentwickler des HTTP-Protokolls und heute Chef der Apache Foundation, im Jahr 2000 zum ersten mal definiert. REST hat ursprünglich nichts mit Web Services zu tun. Es galt vielmehr als Architekturvorbild für das Internet. Deshalb basiert REST auf Prinzipien, die schon seit Jahren im Internet eingesetzt werden. Man könnte behaupten, dass das Internet eine riesige REST-Anwendung ist. Viele Suchmaschinen, Buchungssyteme und Shops sind instinktiv so entwickelt worden, dass sie der REST-Archtektur entsprechen. Bei REST-Anwendungen ist jede Ressource, wie zum Beispiel Bilder oder Web Seiten, über eine URI adressiert und können so angesprochen werden. Eine URI ist eine Zeichenfolge, die eine abstrakte oder physische Ressource bezeichnet. Beispiele für URIs sind „jdbc:inetdae7a:localhost:1433“, „mailto:webmaster@fh-dortmund.de“ oder „http://www.fh-dortmund.de“. Das letzt genannte Beispiel ist als URL bekannt. URL ist der Vorgänger der später spezifizierten, allgemeingültigeren URI. Es dient zur eindeutigen Beschreibung eines Dokumentes im Internet. Als Transportprotokoll für die Ressourcen bedient man sich beim HTTP-Protokoll. Möchten man beispielsweise ein Bild erhalten, so erstellt man eine HTTP-Anfrage zu der eindeutigen URL der Datei. Das Ergebnis ist die Repräsentation einer Ressource. Sie kann auf weitere Ressourcen verweisen. Der Zustand eines Clients verändert sich bei der Verfolgung der verlinkten Ressourcen. Aus diesem Grund wird die Bezeichnung Representational State Transfer verwendet. Interaktionen sind in REST stateless. Das heißt, dass eine Anfrage keinen Bezug zu einer anderen hat. Sie steht für sich selbst. Eine Anfrage muss also alle Informationen, die benötigt werden, gleichzeitig übertragen. Dieses wird am folgenden Beispiel deutlich: Ruft ein Browser eine HTML-Seite über die eindeutige URL auf, so wird ein HTML Dokument als Repräsentation der Ressource vom Server zu Client übertragen. Das erhaltenen HTML Dokument kann Verweise auf andere Seiten oder Bilder im Internet enthalten. Beim Aufruf dieser Ressourcen ändert der Client seinen Zustand. 3.2 Merkmale einer REST-Anwendung

- Ein REST-Netzwerk besteht aus Client und Server. Der Client ist aktiv und fordert vom passiven Server eine Repräsentation an bzw. modifiziert eine Ressource. Da REST plattformunabhängig ist, können Client und Server verschiedene Betriebssysteme betreiben.

- Jede Anfrage, die vom Client zum Server gestellt wird, muss alle notwendigen

Informationen für die Durchführung auf dem Server beinhalten. Der Client darf keine Annahmen über den Serverstatus machen.

Seite 17 von 40

- Antworten vom Server müssen in der Lage sein, als cacheable oder non-cacheable

markiert zu werden. Wenn eine Antwort cacheable ist, dann erhält der Client das Recht die Antwort für spätere gleiche Anfrage zwischenzuspeichern. Der Vorteil beim Verwenden des Caches ist, dass Client und Server bei bereits gespeicherten Anfragen nicht mehr interagieren müssen und so die Effizienz und die Skalierbarkeit deutlich erhöht wird.

- Alle Ressourcen müssen über eine fest definierte Schnittstelle zugänglich sein.

Die gesamte System-Architektur wird dadurch vereinfacht.

- Ein REST-System besteht aus Ressourcen, die per URI adressiert werden. - Weder Client noch Server müssen die Bedeutung einer URI verstehen. Die gleiche

Darstellung kann auch durch verschiedene URIs erreicht werden.

- Darstellungen werden untereinander verlinkt, um dem Client die Möglichkeit zu geben, von einem Zustand in den nächsten zu wechseln

3.3 HTTP HTTP (Hypertext Transfer Protocol) dient sowohl bei SOAP-Nachrichten als auch bei REST als Transportprotokoll. Bei REST nimmt es eine besondere Stellung ein und wird oft auch als „XML over HTTP“ bezeichnet. Web Server kommunizieren über HTTP miteinander. Es gibt derzeit zwei Versionen, 1.0 und 1.1. Das modernere 1.1 steht allerdings nicht allen Servern zur Verfügung. Auf Seiten der Browser dominiert inzwischen HTTP 1.1. Die Version 1.0 wurde im Mai 1996 in der RFC 1945 veröffentlicht, schon im August desselben Jahres folgte HTTP 1.1. Für das neuere Protokoll stand auch in 1999 noch kein eigenes RFC zur Verfügung, nur ein Draft. Trotz der langen Zeit (für Internet-Verhältnisse) und den enormen Vorteilen von HTTP 1.x sind immer noch Server mit der Entwicklungsversion 0.9 im Einsatz. Bei HTTP handelt es sich um ein verbindungs- oder statusloses Protokoll. Server und Client nehmen also nie einen besonderen Zustand ein, sondern beenden nach jedem Kommando den Prozess komplett, entweder mit Erfolg oder mit einer Fehlermeldung. Es obliegt dem Kommunikationspartner, darauf in angemessener Weise zu reagieren. 3.3.1 HTTP-Anfrage HTTP-Kommandos können aus mehreren Zeilen bestehen. Die erste Zeile ist immer die Kommandozeile. Daran angehängt kann ein Message-Header folgen. Der Header enthält weitere Parameter, die das Kommando spezifizieren. So kann ein Content-Length-Feld enthalten sein. Steht dort ein Wert größer als 0, folgen dem Header Daten. Die Daten werden also gleich zusammen mit dem Kommando gesendet, man spricht dann vom Body der Nachricht. HTTP versteht im Gegensatz zu SMTP den Umgang mit 8-Bit-Werten. Binärdaten, wie Bilder oder Sounds, müssen nicht konvertiert werden.

Seite 18 von 40

Folgen dem HTTP-Kommando und den Header-Zeilen zwei Leerzeilen (Zeilenwechsel »\n«), so gilt das Kommando als beendet. Kommandos mit Body haben kein spezielles Ende-Zeichen, das Content-Length-Feld bestimmt, wie viele Bytes als Inhalt der Nachricht eingelesen werden. Ein HTTP-Kommando hat immer folgenden Aufbau:

METHODE ID VERSION Mit METHODE wird das Kommando selbst bezeichnet. Die folgende Tabelle zeigt die HTTP-Kommandos auf einen Blick: Name Beschreibung DELETE Ressource löschen GET Ressource anfordern HEAD Header der Ressource anfordern LINK Verknüpfung zweier Ressourcen beantragen OPTIONS Optionen des Webservers erfragen POST Daten an einen Serverprozess senden PUT Ressource auf dem Webserver ablegen TRACE Kommando zurückschicken lassen UNLINK UNLINK Verknüpfung zwischen Ressourcen löschen

Tabelle 1: Übersicht über HTTP-Kommandos

Die Kommandos müssen unbedingt in Großbuchstaben geschrieben werden. Die ID einer Ressource kann beispielsweise eine Adresse oder ein Dateiname sein: GET index.html HTTP/1.0 Dieses Kommando fordert die Datei index.html an. Jede REST Ressource besitzt über die HTTP Methoden GET, POST, PUT und DELETE eine generische Schnittstelle. Mit diesen vier Methoden können die meisten Anwendungsfälle abgedeckt werden. Viele Anwendungen, die SQL verwenden benutzen auch nur die generischen Befehle SELECT, INSERT, UPDATE und DELETE. 3.3.2 HTTP-Antwort Die Antwort auf ein Kommando besteht im Senden eines Statuscodes. Dem Statuscode folgen optionale Felder und bei der Übertragung von Ressourcen die Daten. Die Statuszeile hat folgenden Aufbau:

VERSION STATUSCODE STATUSTEXT

Der Statuscode ist eine dreistellige Ziffer, von denen die erste die Zuordnung zu einer bestimmten Gruppe zeigt. Hier ein Überblick der wichtigsten Statuscodes:

Seite 19 von 40

Gruppen Statuscode Beschreibung 200 Kommando erfolgreich 201 Ressource wurde erstellt 202 Authentifizierung akzeptiert

Kommando erfolgreich

204 Kein Inhalt oder nicht angefordert 301 Ressource am anderen Ort 302 Ressource nicht verfügbar (temporär Zustand) Weitere Reaktion

erforderlich 304 Ressource wurde nicht verändert (steuert Proxy) 400 Syntaxfehler 401 Keine Autorisierung 403 Nicht öffentlicher Bereich

Fehler, Wiederholung mit

anderen Daten sinnvoll 404 Nicht gefunden (der berühmteste HTTP-Fehler!)

500 Serverfehler, Fehlfunktion 501 Kommando nicht implementiert 502 Feldwert oder URL ungültig (nur Proxy)

Serverfehler, Wiederholung

zwecklos 503 Dienst nicht verfügbar

Tabelle 2: Übersicht über Statuscodes 3.3.3 Der HTTP-Message-Header An ein Kommando oder an die Statuszeile können weitere Felder angehängt werden. Die Header-Felder können in drei Hauptgruppen aufgeteilt werden: - Anfrage-Felder (Request-Header-Fields) sind nur in Anfragen erlaubt - Antwort-Felder (Response-Header-Fields) kommen nur in derAntwort (Statusnachricht) vor - Informationsfelder (General-Header-Fields) übertragen alle anderen Nachrichten, wie Größen und Parameter Einige Header können untergeordnete (optionale) Informationen enthalten. So kann dem Content-Type der Name der Datei übergeben werden. Diese Elemente werden durch ein Semikolon getrennt: Content-Type: application/pdf; name=orderform.pdf Im Gegensatz zu anderen Protokollen ist die Länge eines Datenblocks im Content-Length festgelegt, irgendwelche Begrenzungszeichen gibt es nicht. Beachtenswert ist auch, dass der Server nach dem Verbindungsaufbau keine Antwort sendet. Erst das erste eintreffende Kommando löst eine Reaktion aus. Darin ist die Ursache zu sehen, wenn die Browser nach der Anforderung eines unerreichbaren Server lange Zeit nicht reagieren. Als »Totsignal« wird einfach eine vorgegebene Zeit gewartet, in welcher der Server auf das erste Kommando reagieren sollte. Eine einfache HTTP-Verbindung könnte also folgendermaßen aussehen:

Client: (Verbindungsaufbau des Browsers über TCP/IP) Server: (keine Antwort) Client: GET /index.htm HTTP/1.0

If-Modified-Since: Wed, 30 Jul 1997 00:00:00 <CRLF>

Server: HTTP/1.0 200 Document follows Date: Mon, 18 Aug 1997 23:45:21 GMT+200 Server: IIS 5.0, Microsoft Corporation Content-Type: text/html Last-Modified: Mon, 11 Aug 1997 14:43:13

Seite 20 von 40

Content-Length: 7856 <CRLF> <HTML> … </HTML>

3.4 REST in Verbindung mit Web Services Wie bereits oben erwähnt war REST bei seiner Entstehung nicht für Web Services vorgesehen. Erst später wurde die Möglichkeit entdeckt, die REST-Architektur auch für Web Services zu nutzen. Man versucht die Nachteile, die beim Einsatz von SOAP auftreten können, zu korrigieren. REST gewährleistet die unabdingbaren Vorraussetzung für Web Dienste: plattformunabhängig, skalierbar und programmiersprachenunabhängig. Ein REST Web Service wird am Besten an einem Beispiel erläutert. Im folgenden Beispiel nehmen wir an, dass ein Unternehmen zwecks Einbindung ihrer Kunden in das eigene System sie befähigen soll eine Artikelliste anzufordern, detailliertere Informationen zu einem Artikel zu erhalten und sogar eine Bestellung auszulösen. Während die ersten beiden Aktionen nur „read-only“ sind, kann man mit der Dritten Daten auf dem Server verändern.

Abbildung 19: Beispiel für ein REST Web Service

1.) Artikelliste anfordern

Der REST-Service macht eine URL zu einer Artikelliste-Ressource verfügbar. Der Client kann folgende URL für das Anfordern der Teileliste benutzen: http://www.webserver.de/artikelliste Der Web Service könnte dem Client erlauben zu bestimmen in welchem Format er die Artikelliste erhalten möchte, als HTML- oder XML-Dokument: http://www.webserver.de/artikelliste?dateiformat=xml Der Client muss nun eine HTTP-GET-Anfrage mit der entsprechenden URL an den Server stellen. Als Antwort erhält der Anfragende zum Beispiel folgende Antwort:

Seite 21 von 40

<?xml version="1.0"?> <p:Artikeliste xmlns:p="http://www.webserver.de" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.webserver.de http://www.webserver.de/aritkelliste.xsd"> <Artikel id="00345" xlink:href="http://www.webservice.de/aritkelliste/00345"/> <Artikel id="00346" xlink:href="http://www.webservice.de/aritkelliste/00346"/> <Artikel id="00347" xlink:href="http://www.webservice.de/aritkelliste/00347"/> <Artikel id="00348" xlink:href="http://www.webservice.de/aritkelliste/00348"/> </p:Artikelliste>

Abbildung 20: HTTP-Antwort Artikelliste

Die Artikelliste enthält Links, um detaillierteren Daten zu einzelnen Artikeln zu erhalten. Dies ist ein Schlüsselmerkmal von REST. Der Client wechselt von einem Zustand in den nächsten, indem es die alternativen URLs durchsucht und auswählt. 2.) nähere Informationen zu einem Artikel Der Web Service macht eine URL zu jedem Artikel verfügbar. Hier zum Beispiel eine Clientanfrage zu einem bestimmten Artikel: http://www.webservice.de/artikelliste/00345

<?xml version="1.0"?> <p:Artikel xmlns:p="http://www.webserver.de" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.webserver.de http://www.webserver.de/artikel.xsd"> <Artikel-ID>00345</Artikel-ID> <Name>Widget-A</Name> <Beschreibung>Zange für FBS </Beschreibung> <Einzelaufst xlink:href="http://www.webservice.de/aritkellist/ 00345/Einzelaufst"/> <Stueckpreis waehrung="EUR"> 0.10 </Stueckpreis> <Menge> 10 </Menge> </p:Artikel>

Abbildung 21: HTTP-Antwort Details zum Artikel 00345

Auffällig ist, dass zu noch mehr Daten verlinkt wird. Die Einzelaufstellung zu einem Artikel wird durch Verfolgung des Hyperlinks gefunden. Jedes Antwortdokument erlaubt es dem Client zu noch detailliertertere Informationen zu gelangen.

Bei der Adressierung von Ressourcen ist zu unterschieden zwischen logischen und physischen URLs. Die bisher verwendeten URLs sind logisch. Sie drücken aus, welche Ressourcen es gibt. Sie identifizieren kein physisches Objekt. Die Artikeldaten werden beispielsweise in

Seite 22 von 40

einer Datenbank abgespeichert. Der Web Server erhält die logische URL-Anfrage, parsed sie und entscheidet welche Artikel angefragt wurden. Dann stellt er eine Abfrage an die Datenbank und generiert das Antwort-Dokument, das an den Client geschickt wird. Wenn wir also eine Million Ressourcen haben, gibt es nicht eine Million statische Seiten, wie zum Beispiel:

http://www.webserver/artikelliste/000000.html http://www.webserver/artikelliste/000001.html ...

http://www.webserver/artikelliste/999999.html

Diese URLs zeigen klar auf physische HTML-Seiten. Wie sieht aber eine komplexe logischen URL aus? Wenn man zum Beispiel alle Artikel haben möchten, dessen Stückpreis unter 1 EUR liegt und dessen Menge kleiner als 10 ist, muss man etwas mehr Programmierarbeit leisten. Bei komplexeren Abfragen werden die Daten in ein Formular auf der Clientseite eingegeben. Auf Aufforderung des Clients generiert er eine URL, die er an den Server schickt. Die URL für obiges Beispiel könnte folgendermaßen aussehen: http://www.webservice.de/artikelliste/00345?stueckpreis=1&waehrung=10 Der Server wertet die URL aus und definiert die entsprechend Abfrage an die Datenbank 3.) Bestellung auslösen Der Web Service macht eine URL zur Auslösung einer Bestellung verfügbar. Der Client erstellt ein Dokument, zum Beispiel eine XML-Datei, die der xsd-Datei (Schema) des Servers entspricht. Die generierte Datei wird im Body einer POST-Anfrage an den Server gesendet. Der Empfänger verarbeitet die erhaltene Datei und gibt die Url der neu erstellten Ressource zurück.

3.5 REST-Applikation am Beispiel von sqlREST Für die Implementierung von SOAP gibt es bereits zahlreiche Tools und Frameworks. SOAP wird von weiten Teilen der IT-Branche unterstützt und unter Federführung von IBM und Microsoft beim World Wide Web Konsortium (W3C) weiterentwickelt. Für REST hingegen gibt es nur wenige spezielle Tools, da es auf bereits eingeführte Standards basiert. Anhand vom Tool sqlRest werden wir zeigen, wie man eine REST-Anwendung erstellt. sqlREST ist eine Anwendung, die auf Grundlage einer relationalen Datenbank REST-Anfragen verarbeiten kann. Mit Hilfe von HTTP und XML können Daten abgefragt, geändert und gelöscht werden. sqlREST unterstützt jede Datenbank mit JDBC Treiber und die vier HTTP-Methoden GET, POST, PUT und DELETE. Zum Parsen der XML-Dateien wird die SAX-API verwendet. Die Fremdschlüssel zu anderen Tabellen werden automatisch erstellt. Die zurückgegebene Antwort wird mit XLink Zeigern erzeugt. XLink bietet einen flexiblen Mechanismus zur Definition von Links zwischen XML-Dokumenten. Diese Ressourcen müssen nicht einmal selbst in der Lage sein, eine Link-Definition in sich zu tragen, wie zum Beispiel Dateien mit Bilddaten. Mit XLink kann man viele verschiedene Ressourcen miteinander verknüpfen.

Seite 23 von 40

Folgende Bedingungen müssen für sqlREST vorliegen: - Java runtime version 1.4.1 oder höher - Web Container wie zum Beispiel Tomcat 4.X

Bei sqlREST bilden die gesamte Datenbank, die Tabellen und die einzelnen Datensätze die Ressourcen. Die Ressourcen sind mit XLinks miteinander verknüpft. Das sqlREST-Verzeichnis muss in dem webapps-Ordner des Web Containers liegen. Nach der Installation kann über http://host:port/sqlrest/ der Web Service über den Browser angesprochen werden. In den meisten Fällen ist die URL http://localhost:8080/sqlrest/. 3.5.1 Abfragen erstellen Bei der Eingabe der URL http://localhost:8080/sqlrest/ sollte folgende XML-Datei im Browser angezeigt werden:

Abbildung 22: Oberste Ressource

Dies ist die Top-Level-Ressource, aus der ersichtlich wird, welche Unterressourcen in der Datenbank vorhanden sind. Jede Unterressource spiegelt eine eigene Tabelle wider. Die Top-Level-Ressource verweist mittels Xlink auf weitere Ressourcen, wie customer, product, invoice und item. Der Client kann durch Eingabe eines XLinks die Repräsentation einer neuen Ressource anfordern. Zum Beispiel: http://localhost:8080/sqlrest/CUSTOMER

Seite 24 von 40

Abbildung 23: Übersicht aller Kunden Der Tomcat-Server gibt eine Liste mit allen Kunden wider. Jede Reihe in der Kundentabelle wird als XLink href Attribut aufgelistet. Um einen einzelnen Datensatz zu erhalten, kann man folgende URL verwenden: http://localhost:8080/sqlrest/CUSTOMER/1.

Abbildung 24: Details zum Datensatz

In Abbildung 33 wird ein wird ein einzelner Datensatz aus der Tabelle Kunden dargestellt. Der Datensatz besteht aus den Attributen ID, Firsname, Lastname, Street und City. Attribute können auch Fremdschlüssel zu anderen Tabellen enthalten, zum Beispiel die Kunden-ID bei einer Rechnung.

Seite 25 von 40

Um einem Link zu folgen muss die URL in die Adressleiste eingegeben werden. Ein Folgen durch Anklicken des Links, wie bei Web Seiten ist nicht möglich. Web Services werden oft durch Interaktion von Applikationen abgewickelt. Der Client fragt die Ressource an, interpretiert die Antwort des Server und dringt durch Verfolgen der XLinks tiefer in die Datenstruktur ein. 3.5.2 Daten manipulieren Die GET-Methode zum Abfragen der Daten können über einen gewöhnlichen Browser, wie MS Internet Explorer, gesendet werden. Anders verhält sich das bei POST, PUT und DELETE. Um Daten zu verändern, muss der Client über ein selbst geschriebenes Programm, zum Beispiel in Java, eine HTTP-Anfrage senden, da der Browser diese Methoden nicht unterstützt. Es gibt bereits fertige Programme, die diese Methoden ausführen können, wie zum Beispiel RESTGate.

Abbildung 25: Programm RESTGate

3.6 Goldene Regeln bei der Implementierung von REST Web Services

1. Erstelle für jede Ressource eine eigene URI 2. Logische URIs sind physischen vorzuziehen, z.B.

http://www.boeing.com/airplanes/747 ist besser als http://www.boeing.com/airplanes/747.html

3. Nutze Nomen in der URI anstatt Verben. Ressourcen sind konkrete Sachen, keine Handlungen

4. Benutze Links in den Antworten. Verbinde deine Antworten mit anderen Daten, damit der Client weiß welche Daten er noch abfragen kann.

Seite 26 von 40

5. Minimiere den Gebrauch von Abfrage-Strings, also http://www.webservice.de/ artikelliste/00345 anstatt http://www.webservice.de/artikelliste?artikel-id=00345 So wird deutlich, dass zwischen der Artikelliste und dem Artikel ‚00345’ eine Beziehung besteht.

6. Benutze ein Slash „/“ in der Url, um Unterressourcen zu adressieren 7. Verwende anstatt POST immer die GET-Methode, wenn der Server eine

Repräsentation einer Ressource zurückgeben soll.

Seite 27 von 40

4 Vergleich SOAP und REST 4.1 Implementierung SOAP erfordert mehr Implementierungsaufwand als REST basierte Web Services. Für SOAP sprechen allerdings die zahlreichen Lösungspakete von den großen Softwareherstellern, die das Planen, Entwickeln, Managen und Pflegen erleichtern. Spezielle Tools generieren sogar anhand eines WSDL-Dokumentes die passenden Klassen. Für REST gibt es nur wenige Tools. Zukünftig wird es vielleicht Frameworks und Bibliotheken geben, die das Entwickeln von REST-Anwendungen erleichtern. SOAP fordert eine starke Bindung zwischen Client und Server. Bei jeder Veränderung des Servers muss der Client angepasst werden. In SOAP ist die schrittweise Entwicklung eines Services daher erschwert. Erst nach vollständiger Fertigstellung des Servers ist es ratsam den Client zu Programmieren. In REST ist das anders. Ändert sich die Darstellung einer Ressource oder werden neue Ressourcen zur Verfügung gestellt, kann das Interface des Clients beibehalten werden. Mann muss nur wissen über welche URL die neue Ressource angesprochen werden kann. Noch wird REST nur dort eingesetzt, wo man nur Daten erfragen kann. Das liegt daran, dass die HTTP-Methoden PUT und DELETE oft nicht unterstützt werden. Diese Unterstürzung müsste nachträglich implementiert werden. SOAP wird oft in einem Atemzug mit WSDL und UDDI genannt. WSDL dient der Beschreibung der Schnittstellen des Web Services. Mit Hilfe von UDDI soll der Client diesen Service finden. Allerdings sind die Standardisierungsprozesse noch nicht ganz abgeschlossen. Für REST gibt es bislang noch keinen Dienst zum Auffinden von Web Services. Auch eine standardisierte Sprache zur Beschreibung von REST-Services fehlt. Erst wenn diese Lücken gefüllt sind, kann man über REST von einem vollwertigen Ersatz für SOAP sprechen. 4.2 Funktionsweise Die Zustellung von SOAP-Nachrichten ist vergleichbar mit der Zustellung der Hauspost in einer Firma. Die Briefe werden alle an die allgemeine Firmenadresse adressiert. In der Hauspost werden die Briefe geöffnet und entschieden an welchen Mitarbeiter die Nachricht weitergeleitet wird. In REST werden die Briefe direkt an die Mitarbeiter adressiert. Da SOAP-Nachrichten über HTTP-Post verschickt werden, werden sie meist über eine URL geroutet. Die eigentlichen Funktionen sind innerhalb der Nachricht kodiert und von außen nicht zu erkennen. Alle Aufrufe werden zunächst an den Dispatcher, oder auch SOAP Router gennant, gerichtet. Dieser übernimmt die Aufgabe der Datenzustellung. SOAP Router werden mit einem Servlet oder einem CGI Skript realisiert.

Seite 28 von 40

Abbildung 26: Funktionsweise von SOAP

Bei REST wird durch die eindeutige URL die Ressource direkt angesprochen. Der Web Server interpretiert die URL und entscheidet, welche Ressource gemeint ist.

Abbildung 27: Funktionsweise von REST

4.3 Sicherheit Da Web Services meistens das HTTP-Protokoll benutzen, passieren sie Firewalls problemlos. Dies ließe sich als Angriffspunkt nutzen. SOAP-Nachrichten sehen für Netzwerkadministratoren alle gleich aus, da sie über POST an die gleiche Adresse geschickt werden. Administratoren können die Nachricht nicht verstehen, da sich Inhalt innerhalb der SOAP-Nachricht (im Body) kodiert und von außen nicht zu erkennen ist. Bei Methodenaufrufe ist es sogar möglich bösartigen Code auszuführen. In REST basierten Anwendungen ist die gesamte Nachricht in der URL kodiert. Firewalls können so konfiguriert werden, dass bestimmte URLs gesperrt sind und somit die Ressource nicht aufgerufen oder verändert werden kann. Da REST nur die HTTP-Methoden verwendet, ist es sogar möglich, dass eine Anwendung nur lesen kann, indem nur GET-Anfragen erlaubt sind, DELETE- und PUT-Aufrufe aber gesperrt werden. Durch blockieren von URLs und das Sperren von HTTP-Methoden, lässt sich der gesamte Zugriff eines Web Services steuern. In REST muss sich der Entwickler keine Gedanken um die Implementierung von Sicherheitsmechanismen zum Schutz vor unerlaubten Zugriff auf Ressourcen kümmern. Durch die Verwendung von URLs kann man nicht nur eine Firewall einsetzen. Man kann auch die vorhandenen Sicherheits- und Loggingverfahren eines Webservers eingesetzt. Alle

Seite 29 von 40

Ressourcen lassen sich mit HTTP und HTTPS authentifizieren und autorisieren. SOAP umgeht vorhandene HTTP-Authentisierungsmechanismen.

Abbildung 28: HTTP Sicherheitsmechanismus

Bei SOAP und REST werden die Daten unverschlüsselt übers Netz transportiert. Werden die Daten von einem Dritten abgefangen, können sie problemlos gelesen werden. Auch bei Transaktionen gibt es bei beiden Verfahren keine standardisierte Lösung. Bei REST ist es sehr aufwendig atomare Transaktionen zu implementieren, da jede Anfrage stateless ist. Für Transaktionen, zum Beispiel im Online Banking, ist es einfacher, eine Überweisung als SOAP-Aufruf zu implementieren als einen solchen Vorgang über URIs abzuhandeln. In SOAP könnten man alle notwendigen Daten innerhalb der SOAP-Nachricht kodieren. 4.4 Skalierbarkeit / Effizienz Da Web Services im Internet ihren Einsatz finden und mit einer natürlichen verzögerten Reaktion des Kommunikationspartners zu rechnen ist, wurde bei der Entwicklung von SOAP darauf geachtet, dass es leichtgewichtig ist. Das hatte zur Konsequenz, dass bewusst auf bestimmte Sachen, wie Verschlüsselung, Zugriffskontrolle oder Transaktionen, verzichtet wurde. Auch bei REST wird man auf Grenzen stoßen. Im Internet greifen eine große Anzahl von Leuten auf eine ebenso große Menge von Ressourcen zu. Internettechnologien müssen also skalieren. Das bedeutet, dass zum Beispiel ein Server auf 10 Anfragen ebenso schnell reagieren muss wie auf 1000 Anfragen. Der Einsatz von Proxys oder das Vorschalten eines Cache-Servers erhöhen bei vielen Anfragen die Performance. Da SOAP-Nachrichten über die HTTP-Methode POST verschickt werden, werden sie nicht gecacht. REST-Anfragen können über GET gesendet werden. Hier hat man also die Möglichkeit ein Cache-Server zu nutzen. Man hat bei REST sogar die Wahl ob eine bestimmte Anfrage gecacht werden soll oder nicht.

Seite 30 von 40

Der große Nachteil von SOAP ist dass ein großer Overhead entsteht. Mit Overhead werden alle Daten bezeichnet, die zusätzlich zu den Nutzdaten übertragen werden. Das Verhältnis von Nutzdaten zu Overhead bestimmt die Übertragungs-Performance. Ruft man über SOAP eine Funktion auf, erwartet man eigentlich nur ein Wert; man erhält aber im Header zusätzliche Informationen, die eventuell nicht verarbeitet werden. Durch das Umwandeln eines Aufrufs in XML wir der Aufwand sowohl auf der Client-Seite als auch auf dem Server zusätzlich erhöht. Auch bei REST entsteht oft ein größerer Aufwand auf dem Server. Da es sich meistens um logische URIs handelt, müssen sie ausgewertet und interpretiert werden, bevor der Server erkennt um welche Ressource es sich handelt. Auch hier sorgt, dass Erzeugen von XML für mehr Aufwand. Das komprimieren der Daten ist sowohl in REST als auch in SOAP nicht möglich, was für einen hohen Traffic sorgt. Das führt zum Beispiel im Mobilbereich zu Problemen, da die Datenkanäle hier sehr schmal sind. Im Internet werden überwiegend Lesezugriffe gemacht, zum Beispiel Aufrufen einer Webpage. Die vorhandenen Systeme können diesen Vorgang besonders gut und lassen eine hohe Skalierbarkeit zu. Der Browser kann zum Beispiel nur GET-Anfragen stellen. Andere HTTP-Methoden kennt er nicht. Zum Verändern von Ressourcen werden oft andere Mittel wie FTP eingesetzt. Die HTTP-Methoden PUT und DELETE werden zum Nachteil von REST nur selten unterstützt. Diese Unterstützung müsste also nachträglich ergänzt werden. Dabei muss auf eine ausreichende Skalierbarkeit geachtet werden. Da HTTP stateless ist, werden im Internet oft Cookies verwendet, um sich den Status einer Anfrage zu merken. REST stellt die Bedingung, dass alle Anfragen stateless sind. Alle notwendigen Informationen sind in den Repräsentationen der Ressourcen enthalten. Dies hat positive Auswirkungen auf die Skalierbarkeit von Anwendungen. 4.5 Fazit und Ausblick SOAP ist derzeit der Standard, wenn es um Web Services geht und wird es voraussichtlich auch bleiben. REST wird immer nur eine Alternative sein. SOAP hat außerdem die Unterstützung der großen Softwareunternehmen und wird ständig weiterentwickelt, um verteilte Systeme besser zu unterstützen. In Sachen Skalierbarkeit, Sicherheit und Verschlüsselung wird sich zukünftig auch noch was tun. Ob es auf Kosten der Leichtgewichtigkeit geht bleibt offen. REST bietet aber wie beschrieben einige Vorteile gegenüber SOAP. Durch die Verbindung von REST und SOAP können Web Services-Architekturen gebaut werden, die sowohl die Flexibilität und Skalierbarkeit von REST nutzen als auch die Unterstützung von Web Services-Technologien wie SOAP und WSDL ermöglichen. In neuen SOAP 1.2 Standard wird beschrieben wie man SOAP mit HTTP-GET verwenden kann. Es lassen sich SOAP-Anfragen formulieren, die sich von REST-Anfragen nicht unterscheiden.

Seite 31 von 40

5 Fallbeispiel: Amazon Web Service Amazon Web Services bietet Entwicklern die Möglichkeit sowohl REST als auch SOAP als Verfahren für ihre Software oder Website einzusetzen. Aus diesem Grund haben wir uns für dieses Fallbeispiel entschieden, um eine Musterimplementierung in Java vorzustellen. Amzon stellt Entwicklern folgende Funktionen zur Verfügung:

- laufend aktualisierte Informationen über Produkte von Amazon.de auf ihre Websites oder in ihrer Applikation zu bringen

- Produkte von Amazon.de auf ihren Websites zu verkaufen - maßgefertigte Links und dynamische Werbeplatzierungen zu erstellen

Wir haben bei unserer Software nur die Suche von Büchern über die Angaben des Titels, des Buchautors, des Verlags, der ISBN-Nummer und der Stichwörter verwirklicht. Alle Eingabefelder sind optional und bei Eingabe mehrerer Suchkriterien wird die Suche eingeschränkt. Ein Suchkriterium kann sich auch aus mehreren Wörter zusammenstellen. Als Stichwörter können zum Beispiel die Schlagwörter „heide balzert uml“ eingeben werden. Das Ergebnis beinhaltet alle Bücher, die die drei Stichwörter enthalten. Bei Amazon kann zwischen zwei Ergebnistypen gewählt werden. Der Ergebnistyp „heavy“ ist eine sehr detaillierte Antwort. Für unsere Zwecke jedoch reicht der Typ „lite“ aus, da wir nur die Informationen Titel, Autor, Preis, ISBN-Nummer, Verlag, Erscheinungsdatum, Verfügbarkeit und Artikelbild verarbeiten. Angezeigt werden auch die Anzahl der gefundenen Treffer und Seiten. Amazon hat aus Effizienzgründen die Anzahl der Artikel pro Antwort auf zehn beschränkt. In unserem Programm kann durch drücken der Buttons „weiter“ und „zurück“ die nächsten bzw. vorherigen zehn Treffer angezeigt werden. Über Radio-Button kann zwischen den Verfahren, REST oder SOAP, gewählt werden. Das Ergebnis der Anfrage ist in beiden Fällen identisch. Da die Geschwindigkeit der Bildübertragung übers Internet stark abhängig von der Bandbreite des Anschlusses ist, haben wir uns dafür entschieden, das Anfordern der Buchbilder als optionaler Bestandteil einzubinden. Dies erhöht die Performance bei niedriger Bandbreite. Die Buttons „Suche starten“ und „Exit“ sind selbsterklärend und bedürfen keiner weiteren Erklärung. Beim Betätigen des Buttons „Löschen“ werden die Felder der Suchkriterien geleert und die Darstellung der vorherigen Antwort gelöscht.

Seite 32 von 40

Abbildung 29: Graphische Benutzeroberfläche unseres Programms

5.1 Implementierung von SOAP Zur Erstellung von SOAP Web Services gibt es viele Tools, die das Implementieren vereinfachen. Wir haben für das Framework Apache Axis 1.1 entschieden. Um solche Frameworks nutzen zu können, müssen die Jar-Files in der verwendeten jdk eingebunden werden. Aus der WSDL-Datei, die von Amazon zur Verfügung gestellt wird, können mit Hilfe von Axis fertige Klassen generiert werden. Zum Erstellen dieser Klassen wird der folgende Befehl in der Shell-Box eingegeben: java org.apache.axis.wsdl.WSDL2Java -v -p com.amazon.soap.axis AmazonWebServices.wsdl

Seite 33 von 40

Über die neu erstellten Klassen wird die komplette SOAP-Verarbeitung durchgeführt. Sie werden im Package com.amazon.soap.axis abgespeichert. Als erstes wird ein Service-Objektes erzeugt, mit dessen Hilfe der RPC durchgeführt werden kann. Danach wird die Verbindung zum Server aufgebaut und die Anfrage über Operationen zusammengestellt. Anschließend wird die Anfrage an Amazon versendet. Als Antwort erhält man ein Objekt, das in der Klasse „ResultSoap“ verarbeitet wird. // Parameter für SOAP private String host="http://soap.amazon.com/onca/soap3"; private String type = "lite"; private String associatesID = "globetravel0d-21"; private String devtoken = "D2TUIBGELIDP38"; private String mode = "books-de"; private String local = "de"; private int page = 1; private String suchFeld = ""; // SOAP-Klassen laden com.amazon.soap.axis.AmazonSearchService service = new

com.amazon.soap.axis.AmazonSearchServiceLocator(); com.amazon.soap.axis.AmazonSearchPort port =

service.getAmazonSearchPort(new URL(this.host)); com.amazon.soap.axis.PowerRequest request = new

com.amazon.soap.axis.PowerRequest(); // Parameterübergabe request.setPower(this.suchFeld); request.setTag(this.associatesID); request.setType(this.type); request.setDevtag(this.devtoken); request.setMode(this.mode); request.setLocale(this.local); request.setPage(""+this.getPage()); // Antwort speichern this.result = port.powerSearchRequest(request); // ResultSoap aufrufen um Daten zu verarbeiten resultSoap = new ResultSoap(result);

Abbildung 30: Graphische Benutzeroberfläche unserer Programms

Da die SOAP-Antwort vom Amazon-Server ein Objekt ist, ist zur Compilezeit der Code des Objektes nicht bekannt. Aus diesem Grund müssen die Klassen während der Laufzeit dynamisch geladen und die vorhandenen Methoden ermittelt werden. Amazon bietet für jedes Attribut eigene Methoden wie zum Beispiel getAuthors, getUrl oder getManufacturer an. Die nun bekannten Methoden können über invoke am Objekt aufgerufen werden. Die Rückgabewerte werden in String gecastet und in Arrays gespeichert. Um die Ergebnisse graphisch darzustellen, greift die Klasse „DrawPane“ (Benutzeroberfläche) auf diese Arrays zu.

Seite 34 von 40

Method method; Class firstObject = obj.getClass(); // Anzahl Treffer method = firstObject.getMethod("getTotalResults", null); this.anzahlTreffer = Integer.valueOf( (String) method.invoke(obj, null)).intValue(); // Anzahl Seiten method = firstObject.getMethod("getTotalPages", null); this.anzahlSeiten = Integer.valueOf( (String) method.invoke(obj, null)).intValue(); method = firstObject.getMethod("getDetails", null); Object[] detail = (Object[]) method.invoke(obj, null); Class secondObject; for(int i=0; i<detail.length; i++){ secondObject = detail[i].getClass(); // URL method = secondObject.getMethod("getUrl", null); String urlString = "keine Angabe"; if (method.invoke(detail[i], null) != null) urlString = (String) method.invoke(detail[i], null); url[i] = urlString; // ASIN method = secondObject.getMethod("getAsin", null); String asinString = "keine Angabe"; if (method.invoke(detail[i], null) != null); asinString = (String) method.invoke(detail[i], null); asin[i] = asinString; ... // Preis method = secondObject.getMethod("getOurPrice", null); String preisString = "keine Angabe"; if ((method.invoke(detail[i], null)) != null) preisString=(String) method.invoke(detail[i], null); preis[i] = preisString; // Autor method = secondObject.getMethod("getAuthors", null); Object autorString[] = new Object[10]; if ((method.invoke(detail[i], null)) != null) autorString = (Object[]) method.invoke(detail[i], null); autor[i] = " " + autorString[0];

Abbildung 31: Verarbeitung der SOAP-Daten über Reflection

Seite 35 von 40

5.2 Implementierung von REST Nach Eingabe der Suchkriterien und drücken des Such-Buttons, wird ein Kontakt zu Amazon über eine Socket Verbindung (Host: "xml-eu.amazon.com", Port: 80) aufgebaut. Aus den Eingabefeldern wird ein Suchstring erstellt, der der Klasse „Rest“ übergeben wird. // Parameter der HTTP private static String HTTPHEADER = " HTTP/1.0\nHost: "; private static String HTTPHEADER2= "\nAccept: text/html, text/plain, text/sgml, text/xml\nUser-Agent:Amazon Java Xml Client/1\n\n"; private String host="xml-eu.amazon.com"; private int port = 80; private String path = "/onca/xml3"; private String version = "1.0"; private String type = "lite"; private String format = "xml"; private String associatesID = "globetravel0d-21"; private String devtoken = "D2TUIBGELIDP38"; private String mode = "books-de"; private int page = 1; private String suchFeld = ""; ... // Erstellung der HTTP public String getHTTP(){ String http = "GET "+path+"?t="+associatesID+"&dev-t="+devtoken+

"&PowerSearch="+suchFeld+"&mode="+mode+"&type="+type+ "&page="+page+"&f="+format+"&locale=de"+ HTTPHEADER+host+HTTPHEADER2;

return http; }

Abbildung 32: Graphische Benutzeroberfläche unserer Programms

Eine Beipiel-Anfrage sieht wie folgt aus: GET /onca/xml3?t=globetravel0d-21&devt=D2TUIBGELIDP38&PowerSearch=keywords: heide%20balzert%20uml&mode=books-de&type=lite&page=1&f=xml&locale=de HTTP/1.0 Host: xml-eu.amazon.com Accept: text/html, text/plain, text/sgml, text/xml User-Agent: Amazon Java Xml Client/1 Der Fettgedruckte Teil kennzeichnet die Suchkriterien. Auf die Anfrage erhält man im Body einer HTTP-Antwort die angeforderten Daten im XML-Format. Die gesamte Nachricht wird in einer Stringvariablen gespeichert, bevor der Body vom Header getrennt wird. Der Body, der die Daten enthält, wird in einer temporären XML-Datei abgespeichert, um weiter verarbeitet werden zu können. Die Klasse „ResultRest“ parsed die XML-Datei und speichert die einzelnen Elemente in String-Arrays. Die Benutzeroberfläche extrahiert die Arrays über get-Operationen und stellt die Werte graphisch dar.

Seite 36 von 40

Eine XML-Datei, die in der Klasse „ResultRest“ verarbeitet und aus einer HTTP-Antwort getrennt wird, könnte wie folgt aussehen: <?xml version="1.0" encoding="UTF-8" ?> - <ProductInfo xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:noNamespaceSchemaLocation="http://xml.amazon.com/schemas3/dev-lite.xsd">

- <Request> - <Args> <Arg value="Amazon Java Xml Client/1" name="UserAgent" /> <Arg value="0SRW16DPYR5Z30FZF6FG" name="RequestID" /> <Arg value="keywords:heide balzert uml" name="PowerSearch" /> <Arg value="de" name="locale" /> <Arg value="1" name="page" /> <Arg value="D2TUIBGELIDP38" name="dev-t" /> <Arg value="globetravel0d-21" name="t" /> <Arg value="xml" name="f" /> <Arg value="books-de" name="mode" /> <Arg value="lite" name="type" />

</Args> </Request> <TotalResults>2</TotalResults> <TotalPages>1</TotalPages> - <Details

url="http://www.amazon.de/exec/obidos/ASIN/3827410541/globetravel0d-21?dev-t=D2TUIBGELIDP38%26camp=2025%26link_code=xm2">

<Asin>3827410541</Asin> <ProductName>UML kompakt</ProductName> <Catalog>Book</Catalog> - <Authors> <Author>Heide Balzert</Author>

</Authors> <ReleaseDate>April 2001</ReleaseDate> <Manufacturer>Spektrum Akademischer Verlag</Manufacturer> <ImageUrlSmall>http://images-eu.amazon.com/images/

P/3827410541.03.THUMBZZZ.jpg</ImageUrlSmall> <ImageUrlMedium>http://images-eu.amazon.com/images/

P/3827410541.03.MZZZZZZZ.jpg</ImageUrlMedium> <ImageUrlLarge>http://images-eu.amazon.com/images/

P/3827410541.03.LZZZZZZZ.jpg</ImageUrlLarge> <Availability>Versandfertig in 24 Stunden.</Availability> <ListPrice>EUR 0,00</ListPrice> <OurPrice>EUR 9,95</OurPrice> <UsedPrice>EUR 4,00</UsedPrice>

</Details> - < etails> D

… </Details>

</ProductInfo>

Abbildung 33: Beispiel einer XML-Datei

Seite 37 von 40

A Abbildungsverzeichnis Abbildung 1: Web Service Architektur....................................................................................... 3 Abbildung 2: Mensch-zu-Computer-Interaktion ........................................................................ 4 Abbildung 3: Computer-zu-Computer-Interaktion..................................................................... 4 Abbildung 4: 3 Schichten-Modell............................................................................................... 6 Abbildung 5: Aufbau einer SOAP-Nachricht ............................................................................. 8 Abbildung 6: SOAP-Envelope .................................................................................................... 8 Abbildung 7: SOAP-Header....................................................................................................... 9 Abbildung 8: SOAP-Body........................................................................................................... 9 Abbildung 9: SOAP-Body......................................................................................................... 10 Abbildung 10: Beispiel für SOAP-Anfrage als RPC ................................................................ 11 Abbildung 11: Beispiel für SOAP-Anfrage als dokumentenbasierte Nachricht ...................... 11 Abbildung 12: Beispiel für eine SOAP-Antwort....................................................................... 12 Abbildung 13: Built-in Datatype Hierarchy [9] ...................................................................... 13 Abbildung 14: Eigenes XML-Schema mit korrespondierende XML-Datei .............................. 14 Abbildung 15: Erweiterter Datentyp - Struct mit XML-Schema ............................................ 15 Abbildung 16: Referenzen nach XML-Schema........................................................................ 15 Abbildung 17: 1. Möglichkeit zur Darstellung eines XML-Arrays ......................................... 16 Abbildung 18: 2. Möglichkeit zur Darstellung eines XML-Arrays ......................................... 16 Tabelle 1: Übersicht über HTTP-Kommandos ........................................................................ 19 Tabelle 2: Übersicht über Statuscodes..................................................................................... 20 Abbildung 19: Beispiel für ein REST Web Service .................................................................. 21 Abbildung 20: HTTP-Antwort Artikelliste ............................................................................... 22 Abbildung 21: HTTP-Antwort Details zum Artikel 00345 ....................................................... 22 Abbildung 22: Oberste Ressource............................................................................................ 24 Abbildung 23: Übersicht aller Kunden .................................................................................... 25 Abbildung 24: Details zum Datensatz ...................................................................................... 25 Abbildung 25: Programm RESTGate....................................................................................... 26 Abbildung 26: Funktionsweise von SOAP ............................................................................... 29 Abbildung 27: Funktionsweise von REST ................................................................................ 29 Abbildung 28: HTTP Sicherheitsmechanismus........................................................................ 30 Abbildung 29: Graphische Benutzeroberfläche unseres Programms ...................................... 33 Abbildung 30: Graphische Benutzeroberfläche unserer Programms ...................................... 34 Abbildung 31: Verarbeitung der SOAP-Daten über Reflection............................................... 35 Abbildung 32: Graphische Benutzeroberfläche unserer Programms ...................................... 36 Abbildung 33: Beispiel einer XML-Datei................................................................................. 37

Seite 38 von 40

B Abkürzungsverzeichnis API Application Programming Interface

COM+ Component Object Model

CORBA Common Object Request Broker Architecture

DCOM Distributed Component Object Model

DTD Document Type Definition

FTP File Transfer Protocol

HTML Hypertext Mark-up Language

HTTP Hypertext Transfer Protocol

POP3 Post Office Protocol Version 3

REST Representational State Transfer

RFC Request for Comment

RMI Remote Method Invocation

RPC Remote Procedure Call

SAX Simple API for XML

SMTP Simple Mail Tranfer Protocol

SOAP Simple Object Access Protocol

TCP/IP Transmission Control Protocol / Internet Protocol

UDDI Universal Description, Discovery and Integration

URI Universal Resource Identifier

URL Uniform Resource Locator

UTF-8 Unicode Transformation Format 8bit

W3C World Wide Web Consortium

WSDL Web Services Definition Language

XLINK XML Linking Language

XML Extensible Markup Language

Seite 39 von 40

C Literaturverzeichnis [1] Web Services Architecture Requirements, W3C Working Draft 11 October 2002, http://www.w3.org/TR/2002/WD-wsa-reqs-20021011 [2] UDDI, SOAP and WSDL – The Web Service Specification Reference Book, PH PTR, 2000, ISBN 0-13-085726-2 [3] Jörg Krause, PHP 4 – Grundlagen und Profiwissen, Hanser-Verlag, 2000, ISBN 3-446-21546-8 [4] Roy Fielding, Representational State Transfer, Internet, 2004, http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm [5] Dipl.-Kfm. Erik Wüstner und Prof. Dr. Peter Buxmann (TU Freiberg), SOAP für Web

Services, Internet, 2004, http://www.wiwi.tufreiberg.de/wi/publications/rp/wisu112002.pdf

[6] Paul Prescod, REST and the Real World, Internet , 2004, http://www.xml.com/pub/a/ws/2002/02/20/rest.html?page=1 [7] OIO – Orientation in Objects, REST Web Services - Eine Einführung, Internet, 2004, http://www.oio.de/public/xml/rest-webservices.htm [8] Matthew Langham, Der ganze REST, Internet, 2004, http://www.xml-magazin.de/itr/online_artikel/psecom,id,209,nodeid,69.html [9] W3C, SOAP Version 1.2 - W3C Recommendation 24 June 2003, Internet, 2004, http://www.w3.org/TR/2003/REC-soap12-part0-20030624/ http://www.w3.org/TR/2003/REC-soap12-part1-20030624/ http://www.w3.org/TR/2003/REC-soap12-part2-20030624/

[10] Amazon.com, Amazon Web Services API Guide, Internet, 2004, http://www.amazon.com/webservices

Seite 40 von 40