12.Vorlesung Cluster-, Grid- und Cloud-Computing Hochschule Mannheim

Transkript

1 Dr. Christian Baun 12.Vorlesung Cluster-, Grid- und Cloud-Computing Hochschule Mannheim WS1112 1/46 12.Vorlesung Cluster-, Grid- und Cloud-Computing Hochschule Mannheim Dr. Christian Baun

2 Dr. Christian Baun 12.Vorlesung Cluster-, Grid- und Cloud-Computing Hochschule Mannheim WS1112 2/46 Wiederholung vom letzten Mal MapReduce/Hadoop Eckdaten Grundlagen Ablauf Einsatzgebiete Google PageRank Komponenten und Erweiterungen Hadoop Distributed File System (HDFS) Pig Hive HBase Cloudera Installationsanleitung mit der Installation Amazon Elastic MapReduce Weitere MapReduce-Implementierungen

3 Dr. Christian Baun 12.Vorlesung Cluster-, Grid- und Cloud-Computing Hochschule Mannheim WS1112 3/46 Heute Service-orientierte Architekturen Web Services Big Web Services SOAP WSDL UDDI WS-Inspection Web Services mit REST

4 Dr. Christian Baun 12.Vorlesung Cluster-, Grid- und Cloud-Computing Hochschule Mannheim WS1112 4/46 Service-orientierte Architekturen (SOA) SOA ist eine Methode um IT-Komponenten in Dienste zu kapseln und dann zu koordinieren (Orchestrierung) Ziel: Zusammenfassung von Diensten zu höheren Diensten und einfache Bereitstellung an andere Organisationsabteilungen oder Kunden Theorie: Kosten in der Softwareentwicklung werden langfristig gesenkt, da irgendwann alle notwendigen Services vorhanden sind und diese nur noch orchestriert werden müssen Technische Umsetzung: Web Services

5 Dr. Christian Baun 12.Vorlesung Cluster-, Grid- und Cloud-Computing Hochschule Mannheim WS1112 5/46 Die Realität von SOA und das Ergebnis davon

6 Dr. Christian Baun 12.Vorlesung Cluster-, Grid- und Cloud-Computing Hochschule Mannheim WS1112 6/46 Web Services In verteilten Systemen sind meist heterogene Ressourcen integriert Die theoretische Ausbreitung dieser Ressourcen ist weltweit Verbindungen über weite Strecken haben im Vergleich zu lokalen Netzwerken prinzipielle Nachteile Hohe Antwortzeiten Geringe Datenübertragungskapazitäten Potentiell unzuverlässige Verbindungen In solchen Umgebungen hat sich die schwach gekoppelte, asynchrone und nachrichtenbasierte Kommunikation über Web Services bewährt Web Services kann man als eine verteilte Middleware verstehen, die eine Maschine-zu-Maschine-Kommunikation auf Basis von Web-Protokollen ermöglicht

7 Dr. Christian Baun 12.Vorlesung Cluster-, Grid- und Cloud-Computing Hochschule Mannheim WS1112 7/46 Web Services Definition Definition der Web Services Architecture Working Group Ein Web-Service ist ein durch einen Uniform Resource Identifiers (URI) eindeutige identifizierte Softwareanwendung, deren Schnittstellen als XML-Artefakte definiert, beschrieben und gefunden werden können. Ein Web-Service unterstützt die direkte Interaktion mit anderen Softwareagenten durch XML-basierte Nachrichten, die über Internetprotokolle ausgetauscht werden Quelle:

8 Dr. Christian Baun 12.Vorlesung Cluster-, Grid- und Cloud-Computing Hochschule Mannheim WS1112 8/46 Anwendungsmöglichkeiten für Web Services Die populärsten Anwendungsmöglichkeiten für Web Services sind Entfernte Funktionsaufrufe (englisch: Remote Procedure Call) SOAP mit WSDL als Kommunikationsinterface RESTful Web Services

9 Dr. Christian Baun 12.Vorlesung Cluster-, Grid- und Cloud-Computing Hochschule Mannheim WS1112 9/46 Entfernte Funktionsaufrufe XML-RPC XML-RPC ist ein einfaches Protokoll für entfernte Funktionsaufrufe über das Protokoll HTTP Entfernte Funktionsaufrufe bezeichnet man als Remote Procedure Calls XML dient zur Strukturierung der Übergabeparameter an die entfernten Funktionen XML-RPC ist sprachunabhängig Server und Clients können in beliebigen Programmiersprachen wie Java, Python, Ruby, C/C++ oder Perl implementiert werden Funktionsaufrufe werden per HTTP POST an den Server geschickt Der Server wertet das in der Nachricht enthaltene XML-Dokument aus und verwendet dessen Inhalt als Parameter für den Aufruf der gewünschten Funktion Das Ergebnis wird in ein XML-Dokument geschrieben und zum Client übertragen

10 Dr. Christian Baun 12.Vorlesung Cluster-, Grid- und Cloud-Computing Hochschule Mannheim WS /46 Beispiel zu XML-RPC (Server in Perl geschrieben) Ziel: Eine Funktion, die addiert und subtrahiert #!/ usr / bin / perl use strict ; use Frontier :: Daemon ; sub sumanddifference { my ($x, $y) return { sum => $x + $y, difference => $x - $y }; } # Call me as http :// localhost :8080/ RPC2 my $methods = { sample. sumanddifference => \& sumanddifference }; Frontier :: Daemon ->new ( LocalPort => 8080, methods => $methods ) or die " Couldn t start HTTP server : $!"; Quelle:

11 Dr. Christian Baun 12.Vorlesung Cluster-, Grid- und Cloud-Computing Hochschule Mannheim WS /46 Beispiel zu XML-RPC (Client in Perl geschrieben) #!/ usr / bin / perl use strict ; use Frontier :: Client ; unless ( scalar ) == 2) { die " usage : $0 x y\n"; } # Make an object to represent the XML - RPC server. my $server_url = http :// localhost :8080/ RPC2 ; my $server = Frontier :: Client ->new (url => $server_url ); # Call the remote server and get our result. my $result = $server ->call ( sample. ); my $sum = $result - >{ sum }; my $difference = $result - >{ difference }; print " Sum : $sum, Difference : $difference \n"; Quelle:

12 Dr. Christian Baun 12.Vorlesung Cluster-, Grid- und Cloud-Computing Hochschule Mannheim WS /46 Beispiel zu XML-RPC (Anfrage via HTTP POST) POST / RPC2 HTTP /1.1 TE: deflate, gzip ;q=0.3 Connection : TE, close Host : localhost :8080 User - Agent : libwww -perl /5.808 Content - Type : text / xml Content - Length : 199 <? xml version =" 1.0 "?> <methodcall > <methodname >sample. sumanddifference </ methodname > <params > <param > <value ><int >2</int ></ value > </ param > <param > <value ><int >3</int ></ value > </ param > </ params > </ methodcall > Quelle:

13 Dr. Christian Baun 12.Vorlesung Cluster-, Grid- und Cloud-Computing Hochschule Mannheim WS /46 Beispiel zu XML-RPC (Antwort) HTTP / OK Date : Tue, 27 Jul :19:10 GMT Server : libwww -perl - daemon /1.39 Content - Length : 252 Content - Type : text / xml <? xml version =" 1.0 "?> < methodresponse > <params > <param > <value > <struct > <member > <name >difference </ name > <value ><int > -1</int ></ value > </ member > <member > <name >sum </ name > <value ><int >5</int ></ value > </ member > </ struct > </ value > </ param > </ params > </ methodresponse > Quelle:

14 Dr. Christian Baun 12.Vorlesung Cluster-, Grid- und Cloud-Computing Hochschule Mannheim WS /46 Big Web Services mit SOAP in der Theorie Web Services mit SOAP werden auch Big Web Services genannt Die theoretische Umsetzung von Web Services enthält 3 Rollen Dienstanbieter Dienstnutzer Dienstverzeichnis bzw. Dienstvermittler

15 Dr. Christian Baun 12.Vorlesung Cluster-, Grid- und Cloud-Computing Hochschule Mannheim WS /46 Web Services mit SOAP: Komponenten Jeder Dienst wird von seinem Dienstanbieter in einem Dienstverzeichnis angeboten bzw. registriert Ein Dienstnutzer sucht einen passenden Dienst in einem Dienstverzeichnis Das Dienstverzeichnis wird auch als Dienstvermittler bezeichnet Ist ein passender Dienst gefunden, erhält der Dienstnutzer vom Dienstverzeichnis eine Referenz (Adresse) auf die Schnittstellenbeschreibung (WSDL) und kann anschließend den Web Service aufrufen Funktionsaufrufe und Datenaustausch erfolgen über das leichtgewichtige Netzwerkprotokoll SOAP Dienstverzeichnis, WSDL-Beschreibungen und SOAP-Nachrichten basieren auf der Auszeichnungssprache XML

16 Dr. Christian Baun 12.Vorlesung Cluster-, Grid- und Cloud-Computing Hochschule Mannheim WS /46 Web Services: SOAP Das XML-Vokabular SOAP ist die Basis klassischer Web Services SOAP ist ein vollständiges Netzwerkprotokoll zum Austausch von Daten und für entfernte Funktionsaufrufe Es sieht nicht nur Nutzdaten sondern auch Verwaltungsinformationen (wie zum Beispiel für das Routing) vor Meist werden SOAP-Nachrichten im Body einer HTTP POST-Anforderung an eine URL geschickt Andere Protokolle wie SMTP (asynchron) oder FTP (umfangreiche Nutzdaten) sind möglich SOAP entstand 1999 aus dem Übertragungsstandard XML-RPC und stand ursprünglich für Simple Object Access Protocol Seit Version 1.2 wird die Abkürzung SOAP nicht mehr als Akronym gebraucht, da es (subjektiv) nicht einfach (Simple) ist und nicht nur dem Zugriff auf Objekte (Object Access) dient

17 Dr. Christian Baun 12.Vorlesung Cluster-, Grid- und Cloud-Computing Hochschule Mannheim WS /46 Web Services: SOAP SOAP-Nachrichten sind XML-Dokumente, die aus zwei Teilen bestehen Der virtuelle Umschlag (SOAP Envelope) enthält den optionalen SOAP Header, in dem u.a. Informationen zum Routing und Informationen zur Authentifizierung und Autorisierung enthalten sein können Hier sind keine Nutzdaten enthalten Der zwingend notwendige SOAP Body mit der eigentlichen Nachricht ( Payload ) kann Informationen zum Datenaustausch oder Anweisungen für einen entfernten Prozeduraufruf enthalten

18 Dr. Christian Baun 12.Vorlesung Cluster-, Grid- und Cloud-Computing Hochschule Mannheim WS /46 Beispiel für eine XML-basierte SOAP-Nachricht <? xml version=" 1.0 " encoding="utf -8"?> <env:envelope xmlns:env=" http: // /2001/09/ soap - envelope "> < env:header > < n:alertcontrol xmlns:n =" http: // example.org / alertcontrol "> < n:priority >1</ n:priority > <n:expires> T14:00:00-05 :00</ n:expires> </ n:alertcontrol > </ env:header > < env:body > < m:alert xmlns:m =" http: // example.org / alert "> <m:msg >Mary um 14 Uhr von der Schule abholen </ m:msg > </ m:alert > </ env:body > </ env:envelope > Quelle: Tanenbaum, van Steen: Verteilte Systeme. Pearson Studium (2008) Die Nachricht sendet einen Text an einen Web Service Die Nachricht hat eine bestimmte Priorität (1) und wird verworfen, wenn Sie nach 14 Uhr beim Web Service ankommt

19 Dr. Christian Baun 12.Vorlesung Cluster-, Grid- und Cloud-Computing Hochschule Mannheim WS /46 Web Services: WSDL WSDL (Web Services Description Language) ist eine XML-basierende Schnittstellenbeschreibungssprache, um die Schnittstellen (Zugriffspunkte) von Web Services eindeutig zu definieren Eine WSDL-Beschreibung enthält: Beschreibung der vom Web-Service verwendeten Datentypen Beschreibung der vom Web-Service unterstützten Funktionen und Operationen Protokollbeschreibungen Zugriffspunkte (Schnittstellen und Ports) XML-Root-Element: <definitions> 6 XML-Kind-Elemente existieren

20 Dr. Christian Baun 12.Vorlesung Cluster-, Grid- und Cloud-Computing Hochschule Mannheim WS /46 WSDL definiert Web Services durch 6 XML-Elemente 1 types: Definition der Datentypen, die zum Austausch der messages verwendet werden Beschreibt die Nachrichten, die der Web Service sendet und empfängt 2 message: Abstrakte Definitionen der übertragenen Daten Gibt an, welcher Nachrichteninhalt übertragen werden kann 3 porttype: Beschreibung von Operationen. 4 Modi existieren One-way: WS kann Nachricht empfangen, sendet aber keine Antwort Request-response: WS kann Nachricht empfangen und sendet Antwort Solicit-response: WS kann Nachricht senden und wartet auf Antwort Notification: WS kann Nachricht senden und wartet nicht auf Antwort

21 Dr. Christian Baun 12.Vorlesung Cluster-, Grid- und Cloud-Computing Hochschule Mannheim WS /46 WSDL definiert Web Services durch 6 XML-Elemente 4 binding: Bestimmt Protokoll und Datenformat für die Arbeitsschritte und Nachrichten, die durch einen bestimmten Port-Typ gegeben sind Beschreibt wie der Dienst aufgerufen wird 5 port: Spezifiziert die Adresse (Kommunikationsschnittstelle) Ist üblicherweise eine URI In WSDL 2.0 ist das üblicherweise ein Teil von service 6 service: Fasst eine Menge verwandter Ports zusammen Wo überall finde ich die Web Services

22 Dr. Christian Baun 12.Vorlesung Cluster-, Grid- und Cloud-Computing Hochschule Mannheim WS /46 WSDL-Beispiel Teil 1 Das WSDL-Beispiel ist aus der Vorlesung Web Services von Ingo Melzer (WS0304) <? xml version=" 1.0 " encoding="utf -8"?> < wsdl:definitions targetnamespace =" http: // localhost /axis /Calc.jws " xmlns =" http: // schemas. xmlsoap.org /wsdl /" xmlns:apachesoap=" http: // xml. apache.org /xml -soap " xmlns:impl =" http: // localhost /axis /Calc.jws " xmlns:intf =" http: // localhost /axis /Calc.jws " xmlns:soapenc =" http: // schemas. xmlsoap.org /soap / encoding /" xmlns:wsdl =" http: // schemas. xmlsoap.org /wsdl /" xmlns:wsdlsoap =" http: // schemas. xmlsoap.org /wsdl /soap /" xmlns:xsd=" http: // /2001/ XMLSchema "> <! -- porttype --> <! -- message --> <! -- binding --> <! -- service --> </ wsdl:definitions > Das Root-Element mit den benötigten Namensräumen.

23 Dr. Christian Baun 12.Vorlesung Cluster-, Grid- und Cloud-Computing Hochschule Mannheim WS /46 WSDL-Beispiel Teil 2 <! -- definitions --> < wsdl:porttype name =" Calc "> < wsdl:operation name =" add " parameterorder ="a b"> < wsdl:input message =" impl:addrequest " name =" addrequest "/> < wsdl:output message =" impl:addresponse " name =" addresponse "/> </ wsdl:operation > </ wsdl:porttype > <! -- message --> <! -- binding --> <! -- service --> Operation add zum Addieren von zwei Werten und deren Verhalten Web Service kann eine Nachricht empfangen (addrequest) und sendet eine Antwort (addresponse)

24 Dr. Christian Baun 12.Vorlesung Cluster-, Grid- und Cloud-Computing Hochschule Mannheim WS /46 WSDL-Beispiel Teil 3 <! -- definitions --> <! -- porttype --> < wsdl:message name =" addrequest "> < wsdl:part name ="a" type =" xsd:int "/> < wsdl:part name ="b" type =" xsd:int "/> </ wsdl:message > < wsdl:message name =" addresponse "> < wsdl:part name =" addreturn " type =" xsd:int "/> </ wsdl:message > <! -- binding --> <! -- service --> Ein- und Ausgabeparameter (in diesem Beispiel alles Integer) Die Anfrage (addrequest) enthält zwei Parameter (a und b) Die Antwort (addresponse) enthält einen Parameter (addreturn)

25 WSDL-Beispiel Teil 4 <! -- definitions --> <! -- porttype --> <! -- message --> < wsdl:binding name =" CalcSoapBinding " type =" impl:calc "> < wsdlsoap:binding style =" rpc " transport =" http: // schemas. xmlsoap.org /soap /http "/> < wsdl:operation name =" add "> < wsdlsoap:operation soapaction =""/> < wsdl:input name =" addrequest "> < wsdlsoap:body encodingstyle =" http: // schemas. xmlsoap.org /soap / encoding /" namespace =" http: // DefaultNamespace " use =" encoded "/> </ wsdl:input > < wsdl:output name =" addresponse "> < wsdlsoap:body encodingstyle =" http: // schemas. xmlsoap.org /soap / encoding /" namespace =" http: // localhost /axis /Calc.jws " use =" encoded "/> </ wsdl:output > </ wsdl:operation > </ wsdl:binding > <! -- service --> Web Service wird im RPC-Style über HTTP angesprochen Protokolle der Ein- und Ausgabe (addrequest und addresponse) der Methode add werden mit encodingstyle referenziert und somit spezifiziert Dr. Christian Baun 12.Vorlesung Cluster-, Grid- und Cloud-Computing Hochschule Mannheim WS /46

26 Dr. Christian Baun 12.Vorlesung Cluster-, Grid- und Cloud-Computing Hochschule Mannheim WS /46 WSDL-Beispiel Teil 5 <! -- definitions --> <! -- porttype --> <! -- message --> <! -- binding --> < wsdl:service name =" CalcService "> < wsdl:port binding =" impl:calcsoapbinding " name ="Calc "> < wsdlsoap:address location =" http: // localhost /axis /Calc.jws "/> </ wsdl:port > </ wsdl:service > Hier erfolgt die Definition des oder der Zugriffspunkte(s) Es können pro Web Service mehrere Zugriffspunkte festgelegt werden Web Service läuft lokal und liegt in /axis/calc.jws

27 Dr. Christian Baun 12.Vorlesung Cluster-, Grid- und Cloud-Computing Hochschule Mannheim WS /46 Web Services: UDDI UDDI ist ein Verzeichnisdienst UDDI = Universal Description, Discovery and Integration Web Services werden in UDDI-Verzeichnissen klassifiziert, katalogisiert und verwaltet Bietet eine standardisierte Verzeichnisstruktur für die Metadaten von Web Services Technische Eigenschaften, Anforderungen und Anbieterinformationen Basiert auf XML Bei UDDI wird zwischen drei Arten von Informationen unterschieden: 1 White Pages Vergleichbar mit dem Telefonbuch Enthalten die Adresse und Kontaktinformationen des Dienstanbieters 2 Yellow Pages Vergleichbar mit dem Branchenverzeichnis (= Gelbe Seiten) Katalogisierung der Dienste hinsichtlich ihres Zweckes 3 Green Pages Enthalten technische Beschreibungen über die bereitgestellten Dienste Dazu gehören die Schnittstellenbeschreibungen

28 Dr. Christian Baun 12.Vorlesung Cluster-, Grid- und Cloud-Computing Hochschule Mannheim WS /46 Architektur und Datenmodell von UDDI Architektur Client Einer oder mehrere UDDI-Knoten, die eine Registratur bilden Taxonomie-Server (Taxonomie = hierarchische Klassifizierung) Datenmodell (Datenstrukturen) businessentity: Informationen über den Dienstanbieter businessservice: Allgemeine Beschreibung des angebotenen Dienstes bindingtemplate: Technische Eigenschaften des Web Services die zur Nutzung des Dienstes notwendig sind (u.a. die Adresse/URL) tmodel: Technische Spezifikation des Dienstes publisherassertion: Beschreibt die Beziehung zwischen mehreren Dienstanbietern Denkbares Szenario: Ein Unternehmen hat mehrere Tochterfirmen operationalinfo: Speichert Veränderungen im UDDI-Verzeichnis Wird ein Datensatz im Verzeichnis verändert, wird hier gespeichert, von wem und an welchem Knoten der Datensatz erstellt bzw. verändert wurde

29 Alternative zu UDDI: WS-Inspection WS-Inspection ist ein einfacheres Konzept als UDDI zum Auffinden von Web Services Unterschiedliche Architektur UDDI verwendet wenige, zentralisierte Verzeichnisse, in denen verschiedene Dienstanbieter ihre Dienste publizieren WS-Inspection verwendet viele dezentrale, kleine Verzeichnisse, in denen nur einer oder wenige Anbieter ihre Dienste veröffentlichen WS-Inspection versucht zwei Schwierigkeiten von UDDI zu umgehen Die ungenügende Moderation der Verzeichnisse und die damit verbundenen schlechten Suchergebnisse WS-Inspection erlaubt das Suchen von Diensten nur bei Anbietern, denen die Kunden vertrauen WS-Inspection-Dokumente werden im Basisverzeichnis des Webservers des Anbieters Veröffentlicht Die genauen Regeln für das Auffinden der WS-Inspection-Dokumente legt die von IBM und Microsoft entwickelte Spezifikation von 2001 fest Dr. Christian Baun 12.Vorlesung Cluster-, Grid- und Cloud-Computing Hochschule Mannheim WS /46

30 WS-Inspection im Vergleich zu UDDI Quelle: Dr. Christian Baun 12.Vorlesung Cluster-, Grid- und Cloud-Computing Hochschule Mannheim WS /46

31 Dr. Christian Baun 12.Vorlesung Cluster-, Grid- und Cloud-Computing Hochschule Mannheim WS /46 WS-Inspection WS-Inspection ist ein vollständig dokumentenbasiertes Verfahren Auf der Website des Anbieters liegt ein Dokument mit vordefiniertem Namen inspection.wsil bereit Das Dokument enthält Informationen über die angebotenen Dienste Die Nutzer rufen das Dokument via HTTP auf und erhalten eine Liste der Web Services und eine Beschreibung im WSDL-Format Mit dem link-element kann eine Hierarchie von WS-Inspection-Dokumenten realisiert werden Ein WS-Inspection-Dokument verweist mit link auf ein oder mehrere untergeordnete WS-Inspection-Dokumente WS-Inspection konnte sich nicht durchsetzen

32 Dr. Christian Baun 12.Vorlesung Cluster-, Grid- und Cloud-Computing Hochschule Mannheim WS /46 Beispiel für ein WS-Inspection-Dokument <? xml version =" 1.0 "?> < inspection xmlns =" http: // schemas. xmlsoap.org /ws /2001/10/ inspection /"> < service > < description referencednamespace =" http: // schemas. xmlsoap.org /wsdl /" location =" http: // test.uddi. microsoft.com / inquire.asmx?wsdl " /> </ service > < service > <description referencednamespace="urn:uddi - org:api "> < wsiluddi:servicedescription location =" http: // uddi.ibm.com /ubr / publishapi "> <wsiluddi:servicekey >52946BB0 -BC28-11D5 -A AC49CC1E</ wsiluddi:servicekey > </ wsiluddi:servicedescription > </ description > </ service > <link referencednamespace =" http: // schemas. xmlsoap.org /ws /2001/10/ inspection /" location=" http: // wetter.fmi.uni - passau.de/ inspection.wsil " /> </ inspection > Quelle: Service-orientierte Architekturen mit Web Services. Elsevier (2005) Zwei Dienste werden angeboten Der erste Dienst verweist auf die WSDL-Beschreibung der Inquiry API des UDDI-Testverzeichnisses von Microsoft Der zweite Dienst ist die Publishing API eines UDDI-Knotens von IBM Auch ein Link auf ein weiteres WS-Inspection-Dokument ist enthalten

33 Dr. Christian Baun 12.Vorlesung Cluster-, Grid- und Cloud-Computing Hochschule Mannheim WS /46 Web Services mit SOAP in der Realität Der theoretische Aufbau einer Web-Service-Umgebung ist in der Realität heute zumeist anders Öffentlich zugängliche Web Services werden in der Regel ohne die Verwendung von UDDI vermarktet Der Grund ist, dass die einzelnen Web Services mitsamt den notwendigen Zugriffsdaten dem Benutzer bzw. der eingesetzten Client-Anwendung schon bekannt sind und diese daher nicht mehr einen Verzeichnisdienst suchen müssen Aufgrund dieser Entwicklung wurde am 12.Januar 2006 das zu jener Zeit größte UDDI-Verzeichnis, das von IBM, Microsoft und SAP betriebene UDDI Business Registry (UBR), abgeschaltet UDDI konnte sich wie auch WS-Inspection nicht durchsetzen

34 Dr. Christian Baun 12.Vorlesung Cluster-, Grid- und Cloud-Computing Hochschule Mannheim WS /46 Web Services mit SOAP in der Realität Heute gültiger Aufbau von Web Services mit SOAP in der Realität Ausschließlich Dienstnutzer und Dienstanbieter sind beteiligt Die Benutzer kennen die Dienste, die sie nutzen möchten, deren Erreichbarkeit und Anbieter Ein externer Verzeichnisdienst ist nicht notwendig

35 Dr. Christian Baun 12.Vorlesung Cluster-, Grid- und Cloud-Computing Hochschule Mannheim WS /46 Web Services mit REST REST = REpresentational State Transfer RESTful Web Services werden ausschließlich über die HTTP-Schnittstelle angesprochen REST ist zustandslose Kommunikation. Der Server hält keine Zustandsinformation über den Client SOAP stellt Anfragen über XML Bei REST findet eine Zustandsrepräsentationsübertragung statt Die vier HTTP-Methoden PUT, GET, POST und DELETE reichen aus, um sämtliche notwendigen Funktionen auf Objekten auszulösen Datensatz anlegen Datensatz lesen Datensatz aktualisieren Datensatz löschen Dissertation von Roy Thomas Fielding. Architectural Styles and the Design of Network-based Software Architectures. 2000

36 Dr. Christian Baun 12.Vorlesung Cluster-, Grid- und Cloud-Computing Hochschule Mannheim WS /46 HTTP-Methoden bei REST Web Services HTTP CRUD-Aktionen SQL Beschreibung PUT/POST Create INSERT Ressource erzeugen oder deren Inhalt ersetzen GET Read/Retrieve SELECT Ressource bzw. deren Repräsentation anfordern PUT Update UPDATE Einer Ressource verändern DELETE Delete/Destroy DELETE Ressource löschen Die Methoden erinnern an die aus dem Datenbanken-Umfeld bekannten CRUD-Aktionen CRUD steht für die grundlegenden Operationen Create, Read/Retrieve, Update und Delete/Destroy auf dauerhaftem (persistentem) Speicher Zum Vergleich sind in der Tabelle auch die passenden SQL-Anweisungen

37 Dr. Christian Baun 12.Vorlesung Cluster-, Grid- und Cloud-Computing Hochschule Mannheim WS /46 HTTP-Methoden bei REST Web Services Zusätzlich zu den 4 HTTP-Methoden existieren die Methoden HEAD und OPTIONS HEAD fordert vom Server nur den Header einer Ressource (Datei) an So kann sich der Benutzer des Web-Service über die Metadaten informieren, ohne die eigentlichen Ressource zu übertragen Es wird der gleiche Header zurückgeliefert wie bei GET OPTIONS prüft welche Methoden auf einer Ressource verfügbar sind Soll beispielsweise vom objektbasierten Speicherdienst S3 eine Ressourcen, in diesem Fall ein Objekt mit dem Namen beispiel.txt angefordert werden, geschieht dieses mit der HTTP-Methode GET GET /beispiel.txt HTTP/1.1 Das Löschen der Ressourcen (des Objekts) geschieht unter der Voraussetzung, dass die Benutzerrechte diese Aktion zulassen, mit der HTTP-Methode DELETE DELETE /beispiel.txt HTTP/1.1

38 Dr. Christian Baun 12.Vorlesung Cluster-, Grid- und Cloud-Computing Hochschule Mannheim WS /46 Liste der Buckets in S3 anfordern (REST) Anfrage des Clients GET / HTTP /1.1 Host : s3. amazonaws. com Accept - Encoding : identity Date : Fri, 29 Oct : 05: 23 GMT Content - Length : 0 Authorization : AWS 1 QHSHZGENHP57C0JK5JSZEBAS23AS... usw... User - Agent : Boto /1.8 d ( linux2 ) Erste Teil der Autorisierung: AWS Access Key Zweite Teil der Autorisierung: Signatur Aufbau der Signatur: Siehe Folien der 5.Vorlesung

39 Dr. Christian Baun 12.Vorlesung Cluster-, Grid- und Cloud-Computing Hochschule Mannheim WS /46 Liste der Buckets: Antwort von S3 (= 3 Buckets) HTTP / OK x-amz -id -2: JaYLRR6nqyUpOM+eWegCmaBNC2NZJZ... usw... x-amz - request -id: 1FCDF412571D35AA Date : Fri, 29 Oct :05:25 GMT Content - Type : application / xml Transfer - Encoding : chunked Server : AmazonS3 <? xml version=" 1.0 " encoding="utf -8"?> <ListAllMyBucketsResult xmlns="http :// s3. amazonaws.com /doc / / "> <Owner > <ID>af0af9137ff66f0aeeeb68dd1e50a91... usw... </ID> <DisplayName >christianbaun </ DisplayName > </ Owner > < Buckets > < Bucket > <Name>SCC - Seminar</Name> <CreationDate > T20 :35:56.000Z</ CreationDate > </ Bucket > < Bucket > <Name>christianbaun </ Name> <CreationDate > T14 :20:10.000Z</ CreationDate > </ Bucket > < Bucket > <Name>cloud - vorlesung - bucket</name> <CreationDate > T21 :52:46.000Z</ CreationDate > </ Bucket > </ Buckets > </ ListAllMyBucketsResult >

40 Dr. Christian Baun 12.Vorlesung Cluster-, Grid- und Cloud-Computing Hochschule Mannheim WS /46 Merkwürdige HTTP Header Warum sind in der Antwort von S3 die HTTP Header x-amz-id-2 und x-amz-request-id? Beide werden von Amazon bei jeder Anfrage automatisch neu generiert und an die Antwort angehängt Im Fehlerfall, können diese Header dem Anbieter (Amazon) helfen, das Problem zurückzuverfolgen Quelle:

41 Dr. Christian Baun 12.Vorlesung Cluster-, Grid- und Cloud-Computing Hochschule Mannheim WS /46 Liste der Keys in einem Bucket anfordern (REST) Anfrage des Clients GET / cloud - vorlesung - bucket / HTTP /1.1 Host : s3. amazonaws. com Accept - Encoding : identity Date : Fri, 29 Oct : 42: 09 GMT Content - Length : 0 Authorization : AWS AKIAI4QECP523R4SGJJJASHEU27HAZW... usw... User - Agent : Boto /1.8 d ( linux2 )

42 Liste der Keys in einem Bucket: Antwort von S3 HTTP / OK x-amz -id -2: K3xUpOC3VkCg0K2Ix9wgDRPLCysFw... usw... x-amz - request -id: D25FD87E92C49520 Date : Fri, 29 Oct :42:10 GMT Content - Type : application / xml Transfer - Encoding : chunked Server : AmazonS3 <? xml version=" 1.0 " encoding="utf -8"?> <ListBucketResult xmlns="http :// s3. amazonaws.com /doc / / "> <Name>cloud - vorlesung - bucket</name> < Prefix ></ Prefix > < Marker ></ Marker > < MaxKeys >1000 </ MaxKeys > <IsTruncated >false</ IsTruncated > < Contents > <Key > Testdatei. txt </ Key > <LastModified > T21 :54:11.000Z</ LastModified > <ETag>& quot ;20437 f481bb3f606f6c4bb64e997da7d & quot ;</ ETag> <Size >44 </ Size > <Owner > <ID>af0af9137ff66f0aeeeb68dd1e50a91... usw... </ID> <DisplayName >christianbaun </ DisplayName > </ Owner > <StorageClass >STANDARD</ StorageClass > </ Contents >... </ ListBucketResult > Dr. Christian Baun 12.Vorlesung Cluster-, Grid- und Cloud-Computing Hochschule Mannheim WS /46

43 Dr. Christian Baun 12.Vorlesung Cluster-, Grid- und Cloud-Computing Hochschule Mannheim WS /46 Liste der Verfügbarkeitszonen in EC2 anfordern (REST) Anfrage des Clients GET /? AWSAccessKeyId = AKIAI4QECP523R4SGJJQ & Action = DescribeRegions & SignatureMethod = HmacSHA256 & SignatureVersion =2 & Timestamp = T11 %3 A55 %3 A28 & Version = & Signature = Hnb / IQO5zPmcZKCYaF34KaknlRLVGCRH0j1 / si563cg %3 D HTTP /1.1 Host : us -east -1. ec2. amazonaws. com Accept - Encoding : identity User - Agent : Boto /1.8 d ( linux2 )

44 Dr. Christian Baun 12.Vorlesung Cluster-, Grid- und Cloud-Computing Hochschule Mannheim WS /46 Liste der Verfügbarkeitszonen: Antwort von EC2 HTTP / OK Server : Apache - Coyote /1.1 Content -Type : text /xml ; charset=utf -8 Transfer - Encoding : chunked Date : Fri, 29 Oct :55:28 GMT <? xml version=" 1.0 " encoding="utf -8"?> <DescribeRegionsResponse xmlns="http :// ec2. amazonaws.com /doc / / "> <requestid>eaeb7fcd -0bb b cbc9f63</ requestid> < regioninfo > <item > <regionname>eu -west -1</ regionname> <regionendpoint >ec2.eu -west -1. amazonaws.com</ regionendpoint > </ item > <item > <regionname>us -east -1</ regionname> <regionendpoint >ec2.us -east -1. amazonaws.com</ regionendpoint > </ item > <item > <regionname>us -west -1</ regionname> <regionendpoint >ec2.us -west -1. amazonaws.com</ regionendpoint > </ item > <item > <regionname>ap - southeast -1</ regionname> <regionendpoint >ec2.ap - southeast -1. amazonaws.com</ regionendpoint > </ item > </ regioninfo > </ DescribeRegionsResponse >

45 Dr. Christian Baun 12.Vorlesung Cluster-, Grid- und Cloud-Computing Hochschule Mannheim WS /46 Ende

46 Dr. Christian Baun 12.Vorlesung Cluster-, Grid- und Cloud-Computing Hochschule Mannheim WS /46 Nächste Vorlesung Nächste Vorlesung: