Webservices SOAP und REST Nicole Fronhofs 1. Betreuer: Prof. Dr. Volker Sander 2. Betreuer: B. Sc. Sebastian Olscher

2 Inhalt  Grundlagen – Webservices allgemein – Remote Procedure Calls – Message Exchange Patterns  SOAP – allgemeines – SOAP Nachrichten  REST-Architektur – allgemeines – Kommunikation  SOAP und REST im Vergleich

3 Webservice allgemein  Idee: Daten oder Dienste anderen Anwendungen zur Verfügung zu stellen  Definiert eine klare Schnittstelle zum Austausch von Daten mit anderen Systemen  Datenübertragung über verschiedene Protokolle und Datenformate (Bsp.: XML, HTTP)  Plattformunabhängig  Nutzen: –Problembewältigung:Inkompatibilität mehrerer Systeme –Erleichterung bei der Zusammenarbeit mehrerer Systeme in einem Unternehmen

4 Remote Procedure Calls  Webservices können aus anderen Adressräumen aufgerufen werden → RPC ist eine Technik, die dies ermöglicht  Erste Implementierungen → jede RPC-Funktion ein Port  Knappheit der Portnummern → Einführung des Portmappers  Portmapper lauscht auf Port 111  Jeder Dienst muss Portmapper gemeldet werden  Portmapper weist, bei Anfrage, Dienst einem Port zu

5 Remote Procedure Calls

6 Message Exchange Pattern One-Way-Pattern: – Sender erwartet keine Antwort Request-Response-Pattern – Sender erwartet eine Antwort Request-Callback-Pattern – Sender erwartet Nachricht, aber ohne Blockieren Webservices tauschen Nachrichten aus. MEP ist ein Muster zum Ablauf einen Nachrichtenaustausches.

7 Inhalt  Webservices allgemein – Remote Procedure Calls – Message Exchange Patterns  SOAP – allgemeines – SOAP Nachrichten  REST-Architektur – Allgemeines – Kommunikation  SOAP und REST im Vergleich

8 SOAP  Simple Object Access Protocol → heute ein Eigenname  Standardisiert (w3c)  Protokoll mit dem man Daten zwischen Systemen austauscht  Nachrichtenaustausch über XML  Overhead durch XML  Regeln, wie Daten abgebildet und interpretiert werden  Ermöglicht Remote Procedure Calls  Plattformunabhängig  Zustandslos

9 SOAP Nachricht  3 Teile einer SOAP Nachricht:  Envelope –Wurzelelement  Header –Optional –Metadaten können gesetzt werden  Body –Nutzdaten –Informationen zum Datenaustausch

10 SOAP Anfrage MeinUser MeinPassword Müller

11 SOAP Antwort

12 SOAP env:Sender Argument missing

13 SOAP Transport  Es kann Zwischenstationen geben  Zwischenstation interpretiert nur Headerinformationen  Schritte der Verarbeitung: – Rollenermittlung – Alle Headerblocks (Achtung: mustUnderstand=true könnte Fehler verursachen) – Empfänger zuletzt den Body

14 Inhalt  Webservices allgemein – Remote Procedure Calls – Message Exchange Patterns  SOAP – allgemeines – SOAP Nachrichten  REST-Architektur – Allgemeines – Kommunikation  SOAP und REST im Vergleich

15 REST-Architektur  Represential State Transfer  Programmierparadigma für netzwerkbasierte Anwendungen  Dienste/Ressourcen werden über eine URL identifiziert  Eigenschaften eines RESTful Webservices: –Beliebige Menge von Ressourcen eindeutig identifizierbar –Zustandslos –Unterschiedliche Repräsentationen ermöglichen –Standardisierte Operationen –Ressource kann Link zu anderen Ressource enthalten

16 REST-Architektur: Kommunikation Anfrage an eine RESTful Webservice: Als Antwort wird ein Objekt zurückgeliefert. In diesem Beispiel: XML-Darstellung GET

17 REST-Architektur: Kommunikation T-shirt blau T-shirt grün

18 REST-Architektur: Kommunikation Hinzufügen eines Artikels zum Warenkorb: Artikel aus Warenkorb entfernen: POST Artikelnummer=2233 DELETE Artikelnummer=2233

19 REST-Architektur: Kommunikation Hinzufügen einer Ressource PUT T-shirt gelbes T-shirt 7,95 M HTTP/ OK Content-Type: text/xml; Content-Length: 30

20 Inhalt  Webservices allgemein – Remote Procedure Calls – Message Exchange Patterns  SOAP – allgemeines – SOAP Nachrichten  REST-Architektur – Allgemeines – Kommunikation  SOAP und REST im Vergleich

21 REST und SOAP im Vergleich  REST: Die Ressource wird direkt über eine URL angesprochen  SOAP:Alle Nachrichten werden an einen Endpunkt geschickt und dierser leitet die Nachricht an das Objekt weiter

22 REST und SOAP im Vergleich SOAPREST PerformanceXML→Overhead, XML- Parsing Alle Informationen in URL→ kein XML- Parsing nitwendig Schnittstellenänderung Große Änderungen, da Client genau auf Schnittstelle zugeschnitten sind Keine Änderungen. (Außnahme: Änderung des GET-Parameters) Zugriffssteuerung nur ganze Nachricht erlauben oder sperren HTTP Methoden können eralubt oder gesperrt werden

Fragen ? Vielen Dank für Ihre Aufmerksamkeit