Zugangsmechanismen beim Cloud-Computing

Zugangsmechanismen beim Cloud-Computing SOAP-/RESTful-Webservices und Service- Orientierte Architekturen Semesterbegleitende Prüfungsleistung im Fach: Kommunikations- und Rechnernetze 2 an der Fachhochschule Dortmund im Fachbereich 04 im Studiengang Informatik Autor: Andreas Beckers Matrikel-Nr: 7079059 Erstprüfer: Prof. Dr. Eren Datum: 27. Januar 2011

Inhalt II Inhalt Inhalt... II 1 Einleitung... 1 1.1 Was ist Cloud-Computing... 1 1.2 Motivation... 1 1.3 Zielsetzung... 1 2 Service-Orientierte Architekturen... 3 2.1 Definition... 3 2.2 SOA meets Cloud-Computing... 3 3 Zugangsmechanismen... 5 3.1 Webservice Allgemein... 5 3.2 SOAP-Webservices... 5 3.2.1 WSDL - Webservice Description Language... 5 3.2.2 SOAP... 6 3.3 RESTful-Webservices... 7 3.4 SOAP oder REST... 8 4 Umsetzungsmöglichkeiten... 10 4.1 SOAP-Webservices mit WSDL-Datei... 10 4.2 RESTful-Webservices... 11 4.3 Alternative Umsetzungen durch APIs und Frameworks... 12 5 Fazit... 13 Abbildungsverzeichnis... 14 Codeausschnittverzeichnis... 15 Literaturverzeichnis... 16

1 Einleitung 1 1 Einleitung 1.1 Was ist Cloud-Computing Der Begriff Cloud ergibt sich, historisch gesehen, aus Diagrammen von Computernetzwerken. Mit einer Wolke wird typischerweise die Schicht zwischen zwei Netzwerken dargestellt, die miteinander verbunden sind. Die Wolke stellt das unbekannte Netz des Providers dar, meistens das Internet. Hinter dem Begriff Cloud-Computing verbirgt sich ein großes, komplexes und unbekanntes System also die Wolke die, wie ein normaler Rechner, bestimmte Aufgaben übernimmt. Damit ist ein riesiges zusammengeschlossenes Rechnersystem gemeint, das eine enorme Rechenleistung und eine hohe Verfügbarkeit gewährleistet. Wenn einer der tausenden Rechner ausfällt, bemerkt der eigentliche Nutzer davon nichts. Das Management übernimmt der Anbieter, letztendlich soll der Anwender ja nur die unbekannte Wolke vor Augen haben. Eine weitere, wichtige Eigenschaft für den Endnutzer ist die Skalierbarkeit. Als bekanntes Beispiel dient hier das Weihnachtsgeschäft. Ein Web-Shop wird in der Regel passabel genutzt; es werden nicht viele Ressourcen benötigt. Liegt dieser Shop bei einem Cloud-Anbieter, wird das System auf entsprechend nur das Nötigste gedrosselt. Der Shop-Besitzer muss dementsprechend wenig zahlen. Zu Weihnachten jedoch, wo der Kaufandrang enorm steigt, werden durch den Cloud- Anbieter die Computer-Ressourcen so angepasst, dass die Performance des Systems jederzeit gut ist. Würde der Shop-Anbieter die Anwendung selbst hosten, müsste er entweder das ganze Jahr über starke, teure Hardware und eine schnelle Leitung bezahlen, wobei nur ein Teil benutzt wird, oder aber er hätte zu Weihnachten ein Problem, weil die Auslastung zu hoch ist. Ein Nutzer könnte die Anwendung nicht adäquat einsetzen. 1.2 Motivation Zurzeit ist Cloud-Computing zum richtigen Hype geworden. Jeder will sich damit beschäftigen und sucht nach einem angemessenen Szenario für seine Anwendung. Wie wird Cloud-Computing aber technisch umgesetzt? Über welchem Weg kommuniziere ich mit einem Cloud-Anbieter? In dieser Arbeit wird auf diese Fragen näher eingegangen. 1.3 Zielsetzung Zu allererst werden in Kapitel 2 die Begriffe Cloud-Computing und Service- Orientierte Architektur miteinander verglichen und unterschieden. Sie unterscheiden sich sehr, wobei sie aber einiges gemeinsam haben.

1 Einleitung 2 Anschließend werden die beiden gängigen Zugangsmechanismen SOAP- und RESTful-Webservices aufgezeigt, nachdem nochmal allgemein das Thema Webservices erläutert wird. In Kapitel 3.2 wird das Austauschformat SOAP vorgestellt, und wie man SOAP-basierte Webservices mittels der Webservice Description Language entwirft. Das Ganze wird mit einem Beispiel aus der Amazon Elastic Computing Cloud abgerundet. Dieses Beispiel wird auch in Kapitel 3.3 fortgeführt, in dem auf die REST- Technologie eingegangen wird. Amazon bietet nämlich beide Zugangsmechanismen für ihre Cloud an. In Kapitel 3.4 werden die beiden zuvor erläuterten Webservice Techniken verglichen und sollen einen Überblick bieten, welche der beiden denn nun für die eigene Anwendung in Frage kommt. Im anschließenden Kapitel wird erläutert, wie diese Techniken für die eigene Anwendung umgesetzt werden können.

2 Service-Orientierte Architekturen 3 2 Service-Orientierte Architekturen 2.1 Definition Eine Service-orientierte Architektur ist im eigentlichen Sinne gar keine Architektur sondern eher ein Paradigma oder ein bestimmter Ansatz, der beim Entwurf einer Software-Architektur hilft, konkrete Entscheidungen zu treffen. Letztlich muss SOA, wie jedes IT-Konzept, helfen, fachliche Anforderungen besser zu erfüllen. Um qualitative Lösungen rechtzeitig zu liefern, ist Flexibilität erforderlich. Damit Flexibilität nicht zu Chaos führt, braucht man aber eine klare Organisation, klare Rollen und klare Prozesse. Aus diesem Grund hat SOA auch mit all diesen nichttechnischen Aspekten zu tun. [Josu08, S. 17] In konzeptioneller Sicht gibt es Anbieter, die bestimmte Services zur Verfügung stellen, Konsumenten, die diese beanspruchen wollen und schließlich eine Registrierung, bei der Services angemeldet und erfragt werden können. In Abbildung 1 wird dieser Zusammenhang veranschaulicht. Abbildung 1: Konzept einer SOA Der Anbieter veröffentlicht seinen Service zum Beispiel durch eine WSDL-Datei in der Registrierung. Der Konsument stellt eine Anfrage und erhält schließlich diese WSDL-Datei, mit der er mittels SOAP oder REST Zugriff auf den Service bekommt. Auf die Themen WSDL, SOAP und REST wird in Kapitel 3 näher eingegangen. 2.2 SOA meets Cloud-Computing Eine SOA stellt Policen, Prinzipien und ein Framework bereit und illustriert somit, wie bestimmte Services von Enterprise Anwendungen genutzt werden können um bestimmten fachlichen Nutzen zu erhalten. Services in einer SOA dienen bestimmten Geschäftsfällen wie zum Beispiel das Aktualisieren eines Service-Level- Agreement zwischen dem Unternehmen und einem Kunden. Rein technische

2 Service-Orientierte Architekturen 4 Funktionalitäten, wie das Updaten eines Eintrags in der Datenbank, sind jedoch keine Services im Sinne einer SOA. Auf einem höheren Level gesehen kann SOA als verbessertes Verwaltungsmanagement für Geschäftsfälle betrachtet werden. Dieses Konzept erlaubt uns, Geschäftsprozesse feingranular aufzuteilen, diese als Services bestimmten Anwendungen zur Verfügung zu stellen und somit eine Wiederverwendung von vorhandenen Anwendungsfällen zu ermöglichen. Der Vergleich zwischen SOA und Cloud-Computing kann in erster Sicht ein wenig verwirrend sein. Beides ist sich sehr ähnlich aber dennoch gibt es grundlegende Unterschiede. Webservices einer SOA werden von Unternehmensanwendungen für spezielle andere Applikationen angeboten wohingegen Services des Cloud- Computing Anbieters einem Endkunden angeboten werden um zum Beispiel Software oder Hardware zur Verfügung zu stellen. Cloud-Service Provider wie Amazon oder Force.com haben für die Architektur ihrer Services nutzen aus dem SOA-Konzept gezogen und um einige Dinge verbessert. Die angebotenen Dienste werden in die für den Kunden unergründliche Wolke gesteckt und können erweitert und genutzt werden, wann immer ein Bedarf danach besteht. In einer SOA hingegen ist das erweitern von Services schwierig und ein teures Vorgehen. [Ritt10, S. 70-72]

3 Zugangsmechanismen 5 3 Zugangsmechanismen 3.1 Webservice Allgemein Ein Webservice stellt die Form eines Nachrichtenaustauschs zwischen zwei Systemen dar. Mit dem Wort Web ist hierbei gemeint, dass als Übertragungsprotokoll das Hypertext Transfer Protokoll (HTTP), das auch für Zugriffe auf Webseiten zuständig ist, eingesetzt wird. Der Vorteil gegenüber anderen Mechanismen wie RPC, RMI und CORBA ist, dass keine weiteren Firewallregeln im Unternehmen definiert werden müssen, da aufgrund des HTTP-Ports 80 die Verbindungen üblicherweise durchgelassen werden. Die Übertragung der Daten über HTTP wird durch SOAP oder REST geregelt. Diese beiden Mechanismen werden in Kapitel 3.2 und Kapitel 3.3 erläutert. 3.2 SOAP-Webservices Die erste Möglichkeit, Zugriff zu Cloud-Computing Anbieter zu bekommen, ist der SOAP Webservice. Grundlegend dafür ist die WSDL-Datei, die die einzelnen Services auflistet und beschreibt, welche Parameter und Rückgabewerte die einzelnen Services besitzen. In Kapitel 3.2.1 wird auf den Aufbau der WSDL-Datei eingegangen. In Kapitel 3.2.2 wird der SOAP-Aufbau erläutert und anhand eines Beispiels gezeigt, wie ein neues Image (AMI) in der Amazon EC2 angelegt werden kann. 3.2.1 WSDL - Webservice Description Language WSDL steht für Web-Services Description Language und stellt die Grundlage der SOAP-Webservices dar. Mit ihr kann auf standardisiertem Wege die Schnittstelle zwischen Service-Anbieter und Konsument definiert werden. WSDL wird durch die Spezifikation des World Wide Web Consortium (W3C) definiert. Zurzeit existieren zwei wesentliche Versionen. Die am weitesten verbreitete und in diversen Werkzeugen und Technologien eingesetzte Version ist 1.1. Eine neuere Version, die sich zum Zeitpunkt dieser Arbeit aber noch nicht richtig durchsetzen konnte, ist die Version 2.0. Diese verfügt über einige Verbesserungen und Erweiterungen. WSDL-Dokumente sind grundsätzlich bottom-up aufgebaut. Das heißt, dass die konkreten Eigenschaften am Ende aufgeführt werden und die benötigten Details darüber stehen. In Abbildung 2 ist der Aufbau dargestellt.

3 Zugangsmechanismen 6 Abbildung 2: Aufbau eines WSDL1.1 Dokuments (vgl. [Josu08, S. 262]) Mit service und port wird der Service durch die genaue Adresse in Form einer URL mit dazugehörigem Port angegeben. Durch das binding werden dann die verschiedenen Operationen an den Service gebunden. Des Weiteren wird hier das genaue Übertragungsprotokoll festgelegt. Innerhalb des porttype wird die Verknüpfung zwischen Operationen und Requestund Responseparametern hergestellt. Mit message können schließlich allgemeine Datenpakete deklariert werden, die durch types mit Hilfe der XML-Schema Spezifikation exakt beschrieben werden. Hier werden einzelne Attribute benannt, die Häufigkeit des Auftretens sowie die Variablentypen. Es besteht auch die Möglichkeit, die XML-Schema Typenspezifikation auszulagern und innerhalb des WSDL-Dokuments zu importieren. 3.2.2 SOAP Die Spezifikation von SOAP (Simple Object Access Protocol) beschreibt in erster Linie den Aufbau und das Format der Nachrichten, die bei einem Service-Aufruf zwischen Konsument und Serviceprovider ausgetauscht werden. Die zu übertragenden Daten werden in einen speziellen Umschlag eingebettet, wie in Abbildung 3 zu sehen ist. class SOAP SOAP-Envelope SOAP-Header Soap-Body Abbildung 3: Aufbau einer SOAP-Nachricht Dabei wird innerhalb eines Umschlags (soap:envelope) ein Header (soap:header) und ein Body (soap:body) eingefügt. Syntaktisch wird das Austauschformat mit Hilfe

3 Zugangsmechanismen 7 der Extensible Markup Language (XML) beschrieben. In Codeausschnitt 1 ist eine leere Nachricht im XML-Format dargestellt. <?xml version="1.0"?> <soapenv:envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"> <soapenv:header> </soapenv:header> <soapenv:body> </soapenv:body> </soapenv:envelope> Codeausschnitt 1: Beispiel einer leeren SOAP-Nachricht Als praktisches Beispiel wird in Codeausschnitt 2 eine SOAP-Request Nachricht aufgezeigt, die zum Anlegen eines neuen Images in der Amazon Elastic Compute Cloud dient. <?xml version="1.0"?> <soapenv:envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns="http://ec2.amazonaws.com/doc/2010-08-31/"> <soapenv:header/> <soapenv:body> <ns:createimage> <ns:instanceid>i-10a64379</ns:instanceid> <ns:name>standard-web-server-v1.0</ns:name> <ns:description>standard Web Server v1.0</ns:description> <ns:noreboot>false</ns:noreboot> </ns:createimage> </soapenv:body> </soapenv:envelope> Codeausschnitt 2: SOAP-Request zum Anlegen eines Images in der Amazon EC2 Übermittelte Werte sind hier unter anderem der Name des Images, eine eindeutige ID und eine optionale Beschreibung. Der Aufbau der Nachricht lässt sich aus der offiziellen WSDL-Datei von Amazon ableiten [Amaz10]. 3.3 RESTful-Webservices Neben SOAP gibt es noch die REST-Webservices. REST steht für Representational State Transfer. Architekturen, die REST-Webservices nutzen werden auch als RESTful bezeichnet. Die Prinzipien dieser Technik werden schon längst, wenn auch vielleicht nicht bekannt, im Internet eingesetzt. Ressourcen und Methoden werden über einen Uniform Resource Identifier (URI) angesprochen, also quasi wie der Aufruf einer Webseite. Dabei kommen die Standard HTTP-Methoden GET, POST, PUT und DELETE zum Einsatz. REST-Webservices können als Kollektion von Ressourcen angesehen werden. Jede dieser Ressourcen ist durch eine Basis URI zu erreichen, gefolgt von einer eindeutigen ID, die die gewünschte Ressource identifiziert. Ein Web-Service, der eine Liste von Autos bereitstellt, könnte folgendermaßen aussehen: http://example.de/ressourcen/autos Wenn dieser Service das Autokennzeichen als eindeutige ID nutzt, könnten die Informationen über ein bestimmtes Auto folgendermaßen abgerufen werden: http://example.de/ressourcen/autos/do-fh-123

3 Zugangsmechanismen 8 Für ein komplexeres Beispiel wird der SOAP Amazon EC2 Service zum Anlegen eines neuen AMI aus dem vorherigem Kapitel als REST-Lösung in Codeausschnitt 3 dargestellt: https://ec2.amazonaws.com/?action=createimage &Description=Standard+Web+Server+v1.0 &InstanceId=i-10a64379 &Name=standard-web-server-v1.0 &NoReboot=false Codeausschnitt 3: REST-Anfrage zum Anlegen eines AMI in der Amazon EC2 Wie zu sehen ist, ist der Service-Aufruf wie ein Webseitenaufruf aufgebaut. Benötigte Werte werden als Parameter angefügt. Die Antwort auf ein REST- Request ist, ebenfalls im XML-Format oder auch in JSON, aber nicht eingepackt in einem SOAP-Umschlag, sondern lediglich mit einem standardisierten HTTP- Header. Die Antwort auf die CreateImage-Anfrage könnte folgendermaßen aussehen: HTTP/1.1 200 OK x-amz-id-2: id x-amz-request-id: request_id Date: date Content-Type: type Content-Length: length Connection: close Server: AmazonEC2 <CreateImageResponse xmlns="http://ec2.amazonaws.com/doc/2010-11-15/"> <requestid>59dbff89-35bd-4eac-99ed-be587example</requestid> <imageid>ami-4fa54026</imageid> </CreateImageResponse> Codeausschnitt 4: Beispiel Response auf REST-Anfrage von Amazon EC2 Dieses Beispiel stammt aus der Amazon EC2 API Referenz [Ama10]. Noch fehlt es an einem standardisierten Deskriptor für RESTful Webservices. Es existieren aber bereits einige Ansätze. Einer ist zum Beispiel die Web Application Description Language (WADL), konnte sich aber bisher noch nicht klar durchsetzen. Eine weitere Möglichkeit ist die WSDL-Datei in der Version 2.0, die, wenn es von dem Web-Service Framework unterstützt wird, die Services hinreichend beschreibt [Rub07]. 3.4 SOAP oder REST Die Frage, welchen Webservice-Mechanismus man einsetzen sollte, kann nicht pauschal beantwortet werden. Zuallererst sollte evaluiert werden, welche Methoden von welchem Cloud-Anbieter unterstützt werden. Falls aber zum Beispiel ein Anbieter beide Möglichkeiten anbietet, wie es zum Beispiel die Amazon Elastic Computing Cloud macht, ist eine genauere Überlegung sinnvoll. SOAP-Webservices sind weit verbreitetet und es gibt zahlreiche Tools und Frameworks, um diese zu designen und umzusetzen. Des Weiteren gibt es viele Beispiele, die einem die eigene Umsetzung erleichtern können. Dennoch wurde

3 Zugangsmechanismen 9 diese Technologie von REST überholt. REST ist vor allem leichter zu benutzen, denn der Entwickler muss sich mit weniger Protokollen auseinandersetzen. Des Weiteren muss zum Nutzen der Services keine individueller Client installiert werden. Der Aufruf von REST ist ein normaler http-aufruf, wie auch der Aufruf einer Web- Seite [Mark10, S. 50]. Aber auch Performance-Vorteile sind durch REST gegeben. Der Server, der die Webservices zur Verfügung stellt, hat durch REST eine geringere Last als wenn er SOAP-Webservices anbieten würde. Die Antwortzeit auf eine Anfrage ist ebenfalls schneller [Ritt10, S. 199 f]. Anhand der Nutzungsstatistiken der Amazon Elastic Computing Cloud kann man feststellen, dass auch die Entwickler die Vorteile von REST ernst nehmen. 85% der Webservice Aufrufe dort geschehen über REST [ORei03].

4 Umsetzungsmöglichkeiten 10 4 Umsetzungsmöglichkeiten 4.1 SOAP-Webservices mit WSDL-Datei Um auf SOAP-Webservices zugreifen zu können, ist die WSDL-Datei des Cloud- Anbieters notwendig. Um nun aus der XML-basierten Datei einen Aufruf zu starten, ist es notwendig, sich sogenannte Client-Stubs oder auch Artefakte zu erzeugen. Diese Stubs sind gewöhnliche Klassen, die die Informationen, wie Datentypen und Services, in entsprechenden Klassen und Methoden aufteilen. Um solche Klassen zu bekommen, bedarf es einem Code-Generator. Über die Kommandozeile oder aber auch über Build-Skripte werden schließlich durch Angabe der WSDL-Datei diese Stubs erzeugt. Diese Code-Generatoren sind durch verschiedene Frameworks umgesetzt worden. Im Java Bereich sind die bekanntesten Vertreter Apache Axis [Axis10] und JAX-WS (Java API for XML-Web Services mit Generator wsimport). Im.net Bereich ist bereits ein Generator enthalten (wsdl.exe). Am Beispiel des Apache Axis2 Frameworks wird nun erläutert, wie der oben bereits erwähnte Service createimage() der Amazon EC2 implementiert werden kann. Mit Hilfe des Generators müssen zuerst die Client-Stubs aus der WSDL-Datei erzeugt werden. Dazu muss die WSDL-Datei lokal gespeichert werden und mit dem wsdl2java-generator ausgeführt werden. In Codeausschnitt 5 ist der notwendige Kommandozeilenaufruf zu sehen. wsdl2java s l java d xmlbeans o c:/stubs uri AmazonEC2.wsdl Codeausschnitt 5: Generatoraufruf zum Erzeugen der SOAP Client-Stubs Als Parameter werden die WSDL-Datei angegeben, die Programmiersprache, das Data-Binding Framework und schließlich den Pfad, wohin die Dateien gespeichert werden sollen. Das Data-Binding Framework bestimmt die Art und Weise, wie XML- Daten zu Datenobjekten konvertiert werden bzw. andersrum. Zusätzlich kann mit dem Parameter t auch ein JUnit Test erstellt werden. Die nun erzeugten Klassen können in das eigene Projekt eingebunden werden. Zusätzlich müssen noch die Libraries des Apache Frameworks in den Classpath hinzugefügt werden. Im Codeausschnitt 6 ist zu sehen, wie mit den generierten Klassen der Serviceaufruf implementiert wird. // Stub zum Aufruf der Services AmazonEC2Stub stub = new AmazonEC2Stub(); // Vorbereiten des Aufrufs (Request erstellen) CreateImageDocument createimagerequest = CreateImageDocument.Factory.newInstance(); CreateImageType data = createimagerequest.addnewcreateimage(); // Requestdaten füllen data.setdescription("standard Web Server v1.0"); data.setinstanceid("i-10a64379"); data.setname("standard-web-server-v1.0");

4 Umsetzungsmöglichkeiten 11 data.setnoreboot(false); // Aufruf des Services und extrahieren der Daten CreateImageResponseDocument response = stub.createimage(createimagerequest); CreateImageResponseType responsedata = response.getcreateimageresponse(); System.out.println( "Image ID : " + responsedata.getimageid() ); System.out.println( "Request ID: " + responsedata.getrequestid() ); Codeausschnitt 6: Aufruf des SOAP-Services mittels der generierten Klassen von Axis2 Zuerst muss ein stub initialisiert werden, über den die eigentlichen Services, die in der WSDL-Datei definiert wurden, aufgerufen werden können. Die benötigten Parameter (Requestparameter) werden in für jeden Service generierte Datentypen gekapselt (hier: CreateImageType). Ebenfalls für den Rückgabewert des entfernten Methodenaufrufs wurde ein eigener Datentyp generiert, der schließlich zur Weiterverarbeitung ausgelesen werden kann. Diese Vorgehensweise ist praktisch für alle Cloud-Anbieter gleich, die SOAP- Webservices durch eine WSDL-Datei bereitstellen. Die WSDL-Dateien müssen konform aufgebaut sein. Das einzige, was sich zwischen den Anbietern ändert, sind die Servicenamen, die Request und Responseparameter sowie natürlich die unterschiedlichen Fachlichkeiten, die durch die Services erreicht werden sollen. 4.2 RESTful-Webservices Auch für RESTful-Webservices gibt es mehrere Implementierungsmöglichkeiten. Da ein Service wie eine Website zu erreichen ist, kann zum Beispiel in der eigenen Anwendung ein HTTP-Aufruf mit der gewünschte URL umgesetzt werden. Allerdings muss die erhaltene Antwort selbst geparst werden, um an benötigte Informationen zu gelangen. Alternativen stellen wieder diverse Frameworks dar. Eine davon ist zum Beispiel Jersey, die Open-Source Implementierung von JAX-RS [Jers10]. Zum besseren Verständnis, wie dieses Framework eingesetzt werden kann, wird im Codeausschnitt 7 dargestellt, wie auf den Amazon Service RESTful zugegriffen wird. Client client = Client.create(); // URL des WebServices WebResource wr = client.resource("https://ec2.amazonaws.com"); // Parameter für WebService MultivaluedMap< String, String > params = new MultivaluedMapImpl(); params.add("action", "CreateImage"); params.add("description", "Standard Web Server v1.0"); params.add("instanceid", "i-10a64379"); params.add("name", "standard-web-server-v1.0"); params.add("noreboot", "false"); CreateImageResponse response = wr.queryparams(params).accept(mediatype.application_xml_type).get(new GenericType< CreateImageResponse >() {}); //Ergebnis ausgeben System.out.println("Request ID: " response.getrequestid()); System.out.println("Image ID: " response.getimageid()); Codeausschnitt 7: RESTful Zugriff mittels Jersey JAX-RS Implementierung

4 Umsetzungsmöglichkeiten 12 Ähnlich wie bei der Implementierung des SOAP-Webservices wird zuerst ein Client- Stub initialisiert über den dann später der Service Aufruf erfolgt. Dem Client von Jersey muss allerdings die Web Ressource des REST-Services bekanntgegeben werden. Dazu wird die URI angegeben sowie die nötigen Parameter, die der Cloud- Anbieter durch seine API vorgibt. Der Response Datentyp ist eine selbst erstellte Klasse, die die definierte Antwort des Service-Anbieters repräsentiert. Durch die Anntotation @XmlRootElement wird das Mapping deklariert. Diese Notation gebührt der Java-Erweiterung JAXB, die für das sogenannte Unmarshalling von XML zu normalen Objekten zuständig ist. Als Beispiel ist die Response Klasse des CreateImage-Services ohne Getter-Methoden in Codeausschnitt 8 zu sehen. @XmlRootElement public class CreateImageResponse { private String requestid; private String imageid; Codeausschnitt 8: XML-Mapper für den Response eines REST-Aufrufs durch Jersey 4.3 Alternative Umsetzungen durch APIs und Frameworks Cloud-Anbieter wie Salesforce.com oder Amazon bieten Zugriff zu einer WSDL- Datei oder stellen HTTP-basierte REST-Webservices bereit, um ihre Lösungen dynamisch konfigurierbar zu machen. Bei Anbietern wie Google Apps Engine oder Windows Azure können ebenfalls (bei Azure) eigens entwickelte Applikationen gehostet werden. Darin können dann Services nach dem SOA-Prinzip bereitgestellt werden, die gewünschte Fachlichkeiten übernehmen und nach dem Cloud- Computing Prinzip effizient und skalierbar aufgerufen werden können. Bei diesem Szenario ist es aber einem selbst überlassen, den Webservice, diesmal als Server oder Codeseitig als Server-Skeleton, zu implementieren. Dazu werden oftmals eigene Schnittstellen oder aber auch Frameworks von Drittanbietern angeboten. Restlet für Google Apps Engine (www.restlet.org) Ein Beispiel wäre Restlet für die Google Apps Engine (GAE). Applikationen für diese Cloud haben nur einen eingeschränkten Zugriff auf Bibliotheken. Somit sind nur die Standard Java Bibliotheken verfügbar. Restlet als jar-bibliothek ergänzt die eigene Anwendung um REST-Funktionalität, so dass von der Cloud aus, als Client, weitere Services genutzt werden können, oder aber in der Cloud ein REST-Server eingerichtet wird, der es eben ermöglicht, aus anderen Anwendungen auf die GAE- Applikation in der Cloud zuzugreifen, um bestimmte Fachlichkeiten hochskalierbar durchzuführen. Microsoft.WindowsAzure.StorageClient [MsCe10] Der StorageClient der Windows Azure SDK ist eine vorgefertigte Bibliothek die es dem Entwickler vereinfacht, die REST-Operationen der Storage Cloud zu nutzen. Dieser Client abstrahiert die Schnittstelle in dem er ein gekapseltes closed-source Interface zur Verfügung stellt. Diese Lösung versteckt die komplexeren inneren Abläufe der Web-Services, die einem Entwickler meistens nicht interessieren. Amazon Web Services (AWS) Java /.Net / PHP Library [AWSAPI10] Auch Amazon stellt eine vorgefertigte Bibliothek zur Verfügung, die es ermöglicht, auf dessen Services zuzugreifen und hebt die Komplexität auf, selbst den Zugriff zu den Web Services erstellen zu müssen.

5 Fazit 13 5 Fazit In dieser Arbeit wurde, nachdem im kleineren Umfang Cloud-Computing erläutert wurde, dieser Ansatz mit der Service-Orientierten Architektur verglichen. Es hat sich herausgestellt, dass sich beide Methoden sehr ähneln, sich aber dennoch grundlegend differenzieren. Eine SOA dient dem feingranularen Aufteilen von Geschäftsprozessen, die schließlich wiederverwendbar sind und von anderen Anwendungen genutzt werden können. Cloud-Computing hingegen wird genutzt, um Software, Hardware oder Betriebssysteme hochverfügbar und skalierbar zur Verfügung gestellt zu bekommen. Schließlich wurden die beiden gängigsten Zugangsmechanismen SOAP- und RESTful-Webservices vorgestellt. Bei SOAP-Webservices spielt die WSDL-Datei die entscheidende Rolle, da darin alle Services und Austauschformate deklariert werden. Die eigentlichen Nachrichten werden im XML-Format innerhalb eines SOAP-Umschlags versendet. RESTful-Webservices werden über die Standard- HTTP Messages POST, PUT, GET, und DELETE ausgeführt. Angesprochen werden sie, wie bei einem Webseitenaufruf, durch ihre Uniform Resource Identifier. In einem anschließenden Vergleich zwischen SOAP und REST hat sich herausgestellt, dass die RESTful-Webservices bei den Entwicklern aufgrund der leichteren Bedienung und ihrer effizienteren Arbeitsweise beliebter sind und bei einer modernen Anwendungen vorzuziehen sind, wenn der gewünschte Cloud- Anbieter diesen Mechanismus unterstützt. Mit der Hilfestellung, wie solche Web-Services selbst implementiert und integriert werden können, wird ein näheres, praktischeres Verständnis für diese Thematik vorgezeigt.

Abbildungsverzeichnis 14 Abbildungsverzeichnis Abbildung 1: Konzept einer SOA... 3 Abbildung 2: Aufbau eines WSDL1.1 Dokuments (vgl. [Josu08, S. 262])... 6 Abbildung 3: Aufbau einer SOAP-Nachricht... 6

Codeausschnittverzeichnis 15 Codeausschnittverzeichnis Codeausschnitt 1: Beispiel einer leeren SOAP-Nachricht... 7 Codeausschnitt 2: SOAP-Request zum Anlegen eines Images in der Amazon EC2... 7 Codeausschnitt 3: REST-Anfrage zum Anlegen eines AMI in der Amazon EC2... 8 Codeausschnitt 4: Beispiel Response auf REST-Anfrage von Amazon EC2... 8 Codeausschnitt 5: Generatoraufruf zum Erzeugen der SOAP Client-Stubs... 10 Codeausschnitt 6: Aufruf des SOAP-Services mittels der generierten Klassen von Axis2... 11 Codeausschnitt 7: RESTful Zugriff mittels Jersey JAX-RS Implementierung... 11 Codeausschnitt 8: XML-Mapper für den Response eines REST-Aufrufs durch Jersey... 12

Literaturverzeichnis 16 Literaturverzeichnis [Josu08] Nicolai Josuttis: SOA in der Praxis (dpunkt.verlag, Heidelberg, 2008). [Mark10] Eric A. Marks, Bob Lozano: Executive's Guide to Cloud Computing (John Wiley & Sons, Inc., New Jersey, 2010). [Ritt10] John W. Rittinghouse, James F. Ransome: Cloud Computing - Implementation, Management, and Security (CRC Press, Boca Raton, 2010). Onlinequellen [Ama10] Amazon Web Services LLC: Amazon Elastic Compute Cloud API Reference (2010) [http://docs.amazonwebservices.com/awsec2/latest/apireference/apireference-query- CreateImage.html] (Zugriff: 4. Januar 2011). [Amaz10] Amazon: Amazon EC2 WSDL-Datei () [http://s3.amazonaws.com/ec2-downloads/ec2.wsdl] (Zugriff: 19. 12 2010). [AWSAPI10] amazon web services: AWS SDK for Java (2010) [http://aws.amazon.com/sdkforjava/] (Zugriff: 27. Januar 2011). [Axis10] The Apache Software Foundation: Apache Axis2 (2010) [http://axis.apache.org/axis2/java/core/] (Zugriff: 2011. Januar 11). [Baye02] Thomas Bayer: OiO - REST Web Services (2002) [http://www.oio.de/public/xml/rest-webservices.htm] (Zugriff: 4. Januar 2011). [Jers10] Java.net: Jersey 1.4 User Guide (2010) [http://jersey.java.net/nonav/documentation/latest/user-guide.html#client-api] (Zugriff: 12. Januar 2011). [MsCe10] Ms Certs.net: Windows Azure Storage : REST API (part 2) - Storage Client APIs (2010) [http://mscerts.net/windows/windows%20azure%20storage%20%20%20rest%20api%20%28part%2 02%29%20-%20storage%20client%20apis.aspx] (Zugriff: 2011. Januar 12). [ORei03] Tim O'Reilly: REST vs. SOAP at Amazon (2003) [http://www.oreillynet.com/pub/wlg/3005] (Zugriff: 4. Januar 2011). [Rub07] Daniel Rubio: WADL: The REST answer to WSDL (2007) [http://searchsoa.techtarget.com/tip/wadl-the-rest-answer-to-wsdl] (Zugriff: 4. Januar 2011). [Stei07] Thomas Steiner: Automatic Multi Language Program Library Generation for REST APIs (2007) [https://docs.google.com/doc?id=dgdcn6h3_38fz2vn5] (Zugriff: 19. 12 2010).