Selbstständigkeitserklärung

Transkript

1 TECHNISCHE UNIVERSITÄT DRESDEN FAKULTÄT INFORMATIK INSTITUT FÜR SYSTEMARCHITEKTUR PROFESSUR FÜR RECHNERNETZE PROF. DR. RER. NAT. HABIL DR. H. C. ALEXANDER SCHILL Großer Beleg Entwicklung einer generischen Softwarekomponente zur Kommunikation mit verschiedenen RESTful Web Services Stephan Zepezauer (Mat.-Nr.: ) Betreuer: Dipl.-Medien-Inf. David Urbansky Dresden, 1. Juni 2011

2 Aufgabenstellung Während Inhalte im World Wide Web in der Vergangenheit hauptsächlich für Menschen angeboten wurden, ist seit einigen Jahren der Trend zu maschinenlesbaren Inhalts- und Funktionsangeboten im Web mithilfe von Web Services erkennbar. Durch den geringeren Overhead von RESTful Web Services gegenüber SOAP basierten Services haben sich diese in jüngster Vergangenheit stark verbreitet. Diese Services erlauben es Anwendungsentwicklern auf strukturierte Daten und Funktionen der Serviceprovider zuzugreifen. Leider muss sich der Anwendungsentwickler trotz ähnlichem Funktionsumfangs mehrerer Services jedesmal einarbeiten und Programmlogik für jeden Service neu anpassen. Ziel der Arbeit ist es daher eine generische Komponente zu konzipieren und zu programmieren, die mitfhilfe einfacher Servicebeschreibung auf die Services unterschiedlicher Provider zugreifen kann und deren Ergebnisse aggregiert.

3 Selbstständigkeitserklärung Hiermit erkläre ich, dass ich die von mir am heutigen Tag dem Prüfungsausschuss der Fakultät Informatik eingereichte Belegarbeit zum Thema: Entwicklung einer generischen Softwarekomponente zur Kommunikation mit verschiedenen RESTful Web Services vollkommen selbstständig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel benutzt sowie Zitate kenntlich gemacht habe. Dresden, den 1. Juni 2011 Stephan Zepezauer

4 1 Inhaltsverzeichnis 1 Einleitung Motivation Ziel Anwendungsszenario Aufbau der Belegarbeit Grundlagen Verteilte Systeme Zielsetzung Technologien SOA Dienste Entwurfsprinzipien einer SOA Bestandteile auf technischer Ebene Rollen Serviceanbieter Servicekonsument Verzeichnisdienst Aktionen REST Entwurfsprinzipien Ressourcen mit eindeutiger Identifikation Hypermedia Standardmethoden Unterschiedliche Repräsentationen Statuslose Kommunikation Web Services Was ist ein Web Service? SOAP Web Services SOAP Struktur und Inhalt einer SOAP-Nachricht WSDL Überblick Abstrakte Beschreibung Konkrete Beschreibung

5 UDDI UDDI Prinzipien UDDI Datenstrukturen RESTful Web Services und State-of-the-Art Beschreibungssprachen Web Application Description Language HTML for RESTful Services Semantische Annotationen Dienstsuche und -komposition Zusammenfassung und Diskussion Konzeption Anforderungen Funktionale Anforderungen Nicht-funktionale Anforderungen Systemarchitektur im Überblick Dienstbeschreibung Grundlegende Dienstbeschreibung Erweiterte Dienstbeschreibung Ausschreibung nicht-funktionaler Dienstmerkmale Mapping von funktionalen Dienstmerkmalen Interne Verarbeitung der Dienstbeschreibungen Registry Communicator Wrapper Manager Die Benutzung von RESTator Verwaltung und Darstellung der registrierten Services Dienstnutzung über die RESTator API Zusammenfassung und Abgrenzung Implementierung Grundlegende Bestandteile der Softwarekomponente Ausgewählte Bestandteile der Softwarekomponente Discoverer Communicator Spezifikation der auszutauschenden Daten Einzelner Dienstaufruf Aggregierte Dienstaufrufe Fazit Benutzung Erstellung der Beschreibungsdokumente Verlinkung von WADL und XSD

6 3 6.2 Benutzung der graphischen Benutzeroberfläche Das Programm-Menü Registrierung eines Dienstes Modifizierung eines Dienstes Mapping eines Dienstes Löschen eines Dienstes Die Sichten der Registry White Page Green Page Yellow Page Wrapper Page Methoden des Application Programming Interface Evaluierung Umsetzung des Anwendungsszenarios Analyse der Dienstressourcen Analyse der Anfrageparameter Analyse der Antwortfelder Auswertung der Resultate Zusammenfassung Zusammenfassung und Ausblick 88 Literaturverzeichnis 89 Abbildungsverzeichnis 92 Tabellenverzeichnis 94 A Anhang A - Analyse der Antwortfelder 95

7 1. EINLEITUNG 4 1 Einleitung 1.1 Motivation Mit der Weiterentwickung des World Wide Web hat sich die Bereitstellung von Informationen bzw. Daten gegenüber den Konsumenten geändert. In der Anfangsphase des World Wide Web wurden die Informationen von den Produzenten der Online-Anwendungen auf statischen Webseiten präsentiert. Dadurch war es kaum möglich Informationen zwischen verschiedenen Produzenten mithilfe automatisierte Prozesse auszutauschen. Heutzutage, in Zeiten des Web 2.0 und der zunehmenden Vernetzung von Benutzern und Informationen, ist es möglich die technische Architektur eines Online-Angebots um ein sogenanntes Application Programmable Interface (API) bzw. eine Web-API zu erweitern. Eine Web-API ist eine Schnittstelle, mit der verschiedene Daten eines bestimmten Online-Angebotes für Benutzer, Entwickler und externe Anwendungen verfügbar gemacht werden können. Beispielsweise kann ein Entwickler verschiedene Programmiersprachen verwenden, um mit einer Web-API zu kommunizieren, Daten abzurufen und diese weiterverarbeiten. Weiterhin kann unter Einsatz einer solchen Schnittstelle auch die Übertragung von Daten an die Online-Anwendung erfolgen. Diese Art der Bereitstellung von Informationen und der Übermittlung von Daten wird auch als Web Service bezeichnet. Bei der Umsetzung von Web Services werden zunehmend die Architekturprinzipien des Representational State Transfer (REST) angewandt. Anhand dieses Prinzips ist es möglich die Infrastruktur einer Online-Anwendung so zu entwerfen, dass die Daten durch Ressourcen repräsentiert werden. Wenn ein Web Service mittels REST realisiert ist, spricht man auch von einem RESTful Web Service. In Abhängigkeit von den gelieferten Informationen eines RESTful Web Services lassen sich die zugehörigen Web-APIs in bestimmte Kategorien, wie z.b. Search, Photos, Videos, Social, etc. einordnen. Innerhalb dieser Kategorien unterscheiden sich Web-APIs durch die Angabe verschiedener Aufrufparameter und durch die Verwendung unterschiedlicher MIME-Typen (JSON, XML, YAML, etc.), die das Format der übertragenen Daten bestimmen. Dies führt dazu, dass jeder Web Service anders behandelt werden muss. Falls ein Entwickler bei seiner Implementierung mit mehreren Web- APIs kommunizieren möchte, muss jede API einzeln angesprochen werden. Dieses Vorgehen führt im Endeffekt dazu, dass sich die Implementierungszeit erhöht und die Kosten steigen. 1.2 Ziel Das Ziel der Belegarbeit ist die Modellierung und prototypische Entwicklung einer generischen Softwarekomponente, mit welcher die Aufrufe an verschiedene RESTful Web-APIs gekapselt werden, wodurch eine Trennung zwischen Entwickler und den eigentlichen Web-API-Aufrufen erreicht werden soll. Dabei soll die Flexibilität der Softwarekomponente in der Weise erhöht werden, dass die

8 1. EINLEITUNG 5 Aufrufe verschiedener RESTful Web Services durch eine minimierte Anzahl von Operationen erfolgen kann und das Format der übertragenen Information aus einer Menge vorgegebener MIME-Typen bestimmt werden kann. Da die Verbreitung von RESTful Web-APIs ein Trend ist und stetig steigt, muss es möglich sein neue Web-Service-Schnittstellen zu registrieren, zu modifizieren oder zu löschen. Dieses Verhalten soll von der Softwarekomponente durch eine eigene Schnittstelle unterstützt werden. Die Implementierung der Softwarekomponente soll in der Programmiersprache Java und die Beschreibung der Web-APIs mittels einer XML-basierten Auszeichnungssprache erfolgen. Folgende Ziele und Teilaufgaben werden angestrebt: Darstellung des Standes der Forschung und Technik im Bereich der Kommunikation mittels Web Services und Untersuchung von Forschungsansätzen zur Erstellung generischer Anwendungen zum Austausch von Daten mit verschiedenen Web Services. Analyse und Auswertung der auszutauschenden Daten bei der Kommunikation mit bestimmten Web Services und die Darstellung der Grenzen eines generischen Ansatzes. Spezifikation der Datenaustauschschnittstelle der zu entwickelnden Softwarekomponente. Konzeption einer generischen Softwarekomponente zum Austausch von Daten zwischen verschiedenen Web Services und der zu entwickelnden Softwarekomponente. Prototypische Umsetzung und Test wesentlicher Aspekte des entwickelten Konzeptes. 1.3 Anwendungsszenario Für das bessere Verständnis über die Funktionalität der zu entwickelnden Softwarekomponente wird einleitend ein Anwendungsszenario beschrieben. Dieses Anwendungsbeispiel basiert auf einem realen Hintergrund, nämlich der Einordnung der Arbiet in ein Teilgebiet des Toolkits Palladian. Palladian ist ein Toolkit der Forschungsgemeinschaft IIR Group 1 und beinhaltet eine Sammlung von Algorithmen auf dem Gebiet des Text Processing, welche durch eine einheitliche Schnittstelle angeboten werden. Ein Teilgebiet von Palladian ist das Information Retrieval, das für die Informationsbeschaffung aus unterschiedlichen Quellen zuständig ist und damit auch die Kommunikation mit Web-APIs ermöglichen soll. Genau an dieser Stelle knüpft die hier vorliegende Arbeit an. Die zu entwickelnde Softwarekomponente wird in diesem Szenario als RESTful API Aggregator (RE- STator) bezeichnet. Der Entwickler Max Mustermann möchte eine Applikation erstellen, in der Informationen von verschiedenen Suchmaschinen (mittels REST APIs) kategorisiert werden. Anstatt die Kommunikation mit jeder Quelle einzeln zu programmieren, nutzt er das Werkzeug RESTator, um sich seine Informationen zu beschaffen. RESTator bietet eine visuelle Übersicht über nutzbare Services, deren Eigenschaften und Verhalten. Max Mustermann durchstöbert die Übersicht der Services und stellt fest, dass in der Kategorie Suchdienste nur zwei nutzbare Services aufgelistet sind. Diese möchte er für die Informationsbeschaffung nutzen und zusätzlich noch einen dritten, um den Informationsbestand seiner Applikation zu erhöhen. Dazu erstellt er die Beschreibung der konkreten REST API des dritten Services und übergibt diese an RESTator. RESTator erstellt daraufhin ein Formular, in 1 TU Dresden, Department of Systems Engineering, Chair Computer Networks, IIR Group

9 1. EINLEITUNG 6 dem der Benutzer das Verhalten des Services entsprechend dem Kategoriensystem von RESTator annotiert und durch eine Bestätigung die Servicebeschreibung an die Registry des Werkzeuges übergibt. In der Kategorie Suchdienste sind dadurch drei Services zu erkennen. Max Mustermann erstellt als nächstes einen programmtechnischen Aufruf an die RESTator-Schnittstelle, in dem er folgende Werte übergibt: die Kategorie Suchdienste, die Methode Suche sowie die Aufrufparameter der Methode. Daraufhin werden als Antwort Informationen von den drei Services der Kategorie Suchdienste geliefert. Diese Antwort kann der Entwickler programmtechnisch auswerten lassen, indem er die Ausschreibung zum Antwortformat der aufgerufenen Methode, die auf der zutreffenden Übersichtsseite von RESTator zu finden ist, in seiner Applikation anwendet. Als nächstes stellt Max Mustermann fest, dass er bei der Beschreibung der REST API eine wichtige Ressource außer Acht gelassen. Er fordert demzufolge die Beschreibung mittels der RESTator Schnittstelle an, modifiziert diese durch Angabe der zusätzlichen Ressourceninformationen und gibt sie zurück. Die ergänzte Ressource kann danach durch einen entsprechenden Methodenaufruf zur Informationsbeschaffung beitragen. Des Weiteren kommt es zu der Situation, dass ein Dienstanbieter seinen Service nicht mehr anbietet. Um unnötige Anfragen an diesen obsoleten Service zu vermeiden, löscht Max Mustermann den Service aus der Registry und benutzt auch hierfür wieder die RESTator Schnittstelle. Eine Konkretisierung des Anwendungsszenarios mit realen REST APIs wird in der Evaluation dieser Arbeit zu finden sein. Der Grund dafür liegt in der Dynamik auf diesem Gebiet, das durch einen schnellen Wandel geprägt ist. Damit wird verhindert, dass durch eine modifizierte oder nicht mehr vorhandene REST API das Szenario am Ende der Arbeit obsolet ist. 1.4 Aufbau der Belegarbeit

10 2. GRUNDLAGEN 7 2 Grundlagen Die Einleitung hat verdeutlich, dass für die Bereitstellung von Daten im Internet zunehmend RESTful Web Services zum Einsatz kommen. Dieser Einsatz beruht auf den standardisierten Technologien und Protokollen des Internet, welches ein verteiltes System ist und dessen bekannteste Anwendung das World Wide Web (WWW) ist. In diesem Kapitel werden Architekturprinzipien und Technologien für die Umsetzung von verteilten Systemen eingeführt und wichtige Begriffe für die Arbeit vorgestellt. 2.1 Verteilte Systeme Am Anfang der Entwicklung von Computersystemen standen den Nutzern einzelne Rechner zur Verfügung, die eine Vielzahl an Aufgaben für mehrere Nutzer abarbeiteten. Die Aufgaben wurden in einem so genannten Batch Processing abgewickelt, bei dem die Aufträge sequentiell abgearbeitet und die Ergebnisse jeweils anschließend an die Auftraggeber weitergereicht wurden. Im Laufe der Entwicklung kam mehr Interaktivität in die Computeranwendungen. Dadurch war es möglich, dass mehrere Benutzer einen Computer gleichzeitig nutzen konnten. Im Gegensatz zu dem Ansatz des Batch Processing wurden die einzelnen Aufträge nun in kleinere Einheiten unterteilt. Diese Aufteilung ermöglichte den Time-Sharing-Betrieb, wodurch es möglich war einen kleinen Teil eines Autrags abzuarbeiten und dann zum nächsten zu springen. Zu Beginn der achziger Jahre des letzten Jahrhunderts verteilte sich die Rechenleistung von einem zentralen Computer auf einzelne Arbeitsplatzrechner, so genannte Desktop-PCs. Den Nutzern standen nun individuelle Rechenleistung zur Verfügung. Weiterhin kam es zu der Entwicklung von Anwendungen, die die Bearbeitung und Durchführung von Arbeitsabläufen unterstützten. Jeder Mitarbeiter/in konnte somit einen Teil der anstehenden Aufträge individuell am Arbeitsplatz bearbeiten. Mit der Weiterentwicklung der Arbeitsplatzcomputer, kam auch der Wunsch nach Vernetzung auf. Daraufhin wurden verschiedene Netzwerktopologien entwickelt. Das Netzwerkprotokoll TCP/IP hat sich letztendlich, durch eine klare Konzeption und der Möglichkeit es auf allen Hardwareplattformen einzusetzen, zu einem De-facto-Standard entwickelt und bildete somit auch die Grundlage für die Entwicklung des Internets. Durch sinkende Kosten bei der Chip-Herstellung und leistungsfähigere Netzwerktechnologie entstand Anfang der neunziger Jahre des letzten Jahrhunderts der Trend, Informationsverarbeitung mittels verteilter Systeme durchzuführen [EF03]. Dabei wurden die autonomen Arbeitsplatzrechner beispielsweise mit zentralen Datei-, Datenbank- und Applikations-Server zu einer großen Einheit verbunden. Ab diesem Zeitpunkt war es möglich, dass Organisationen ihre Rechner und Server auf lokaler Ebene zusammenschließen konnten, um Aufgaben gemeinsam abzuarbeiten. Es bot sich allerdings auch die Möglichkeit weltweite Verbundsysteme zu entwickeln. Das bekannteste Beispiel hierfür ist das allgegenwärtige Internet.

11 2. GRUNDLAGEN Zielsetzung Die Zielsetzung Verteilter Systeme ist es, mehrere unabhängige Systemkomponenten zu einem Gesamtsystem zu vereinen [SS07]. Die Funktionalität des Gesamtsystems ergibt sich aus der Kooperation und Integration der einzelnen Komponenten, die über Rechnergrenzen und meistens auch räumlich getrennt miteinander gekoppelt werden. Somit können gemeinsame Ressourcen von verschiedenen Komponenten des Systems genutzt werden. Beispielsweise können Daten aus gemeinsam genutzten Datenbanken verwendet und bearbeitet werden. Die Anschaffung redundanter Peripheriegeräte erübrigt sich. Ein Druck-Server kann die Druckäufträge entgegennehmen und an einen gemeinsam genutzten Drucker weiterleiten. Wie bereits erwähnt ist es möglich, dass jede Komponente eines verteilten Systems mit einer anderen kommunizieren und auf deren Ressourcen zugreifen kann. Verteilte Anwendungen nutzen diese Architektur um eine in Komponenten aufgeteilte Gesamtanwendung auf die Systemkomponenten des zugrundeliegenden verteilten Systems zu übertragen. Damit die verteilte Anwendung funktioniert, werden Informationen zwischen den einzelnen Komponenten ausgetauscht. Die Komponenten verfügen über klar definierte Schnittstellen, die die Kommunikation ermöglichen. Die Verteilung der Komponenten wird dabei meistens verborgen bzw. transparent gehalten. Ein Client, der mit einer verteilten Anwendung über eine Schnittstelle kommuniziert, wird somit sehr wenig darüber erfahren, welche Systemkomponenten im Einzelnen für die Erfüllung seiner Aufgaben zuständig sind. Der Einsatz von Verteilten Systemen unterstützt einen gemeinsamen Ressourcenzugriff, die Parallelisierung von Prozessen, einen Lastausgleich zwischen verschiedenen Instanzen, die Skalierung des Systems und die Verfügbarkeit von Ressourcen Technologien Im Laufe der Zeit haben sich verschiedene Technologien für die Umsetzung von verteilten Anwendungen herausgebildet. Je nachdem wie gut sich diese Technologien an bestehende Infrastrukturen anpassen konnten und wie effizient deren Lösung von architektonischen und funktionalen Problemen waren, erfolgte eine flächendeckende Einführung und Standardisierung. In den folgenden Abschnitten werden die wichtigsten Technologien für die Implementierung von verteilten Anwendungen kurz vorgestellt. Hierbei handelt es sich um Middleware, die entfernte Prozeduraufrufe ermöglicht und sich um die komplizierten Details der Kommunikation zwischen den Rechnern kümmert [EF03]. Die Anordnung der Technologien ist durch eine zeitliche Einordnung gegeben, beginnend mit dem Remote Procedure Call. RPC: Der Remote Procedure Call (RPC) ermöglicht die synchrone Übergabe des Kontrollflusses zwischen zwei Prozessen mit unterschiedlichen Adressräumen auf Ebene der Programmiersprache [SS07]. Das bedeutet, dass Prozeduren von entfernten Computern aufgerufen und ausgeführt werden können. Diese entfernten Aufrufe sollten sich von den lokalen nicht bedeutsam unterscheiden. In der Abbildung 2.1 ist die grundlegende Architektur und der typische Ablauf in einem RPC-System verdeutlicht. Der Server stellt eine bestimmte Funktionalität zur Verfügung, die er über eine Schnittstelle zugänglich macht. Die Schnittstelle wird durch die Interface Definition Language (IDL) in einer ein-

12 2. GRUNDLAGEN 9 heitlich Notation beschrieben. Mithilfe der Schnittstellenbeschreibung werden für den Client und den Server so genannte Stubs generiert. Diese sorgen u.a. dafür, dass entfernte Funktionalität eines Servers so angesprochen werden kann, als wäre diese lokal vorhanden, auch bekannt unter dem Begriff Zugriffstransparenz. Die Stubs auf der Seite des Client sind für die Konvertierung des Aufrufs und der Aufrufparameter in das verwendete Übertragungsformat (Marshalling) verantwortlich. Auf der anderen Seite findet die umgekehrte Konvertierung in das Format des Servers statt (Unmarshalling). Bei einem Prozeduraufruf des Client wird zuerst der Client-Stub aktiviert, wodurch die Datenkonvertierung erfolgt und anschließend wird das Laufzeitsystem mit der Datenübertragung beauftragt. Auf Serverseite wird der Aufruf entgegengenommen und mit dem Server-Stub in das Zielformat dekodiert. Der Aufruf wird zur Ausführung an ein Anwendungsprogramm übergeben und die Antwort wird anschließend an den Client zurückgeschickt. Auch hierbei wird wieder ein Marshalling ausgeführt und die Laufzeitumgebung mit dem senden beauftragt. Nachteilig bei RPC-Systemen ist die Übergabe der Parameter als Wert (call-by-value). Falls ein solcher Parameterwert serverseitig geändert wird, muss der Client seine lokalen Daten anpassen. Der Client selbst ist also für die Konsistenzsicherung zwischen dem lokalen und dem modifizierten serverseitigen Parameterwert zuständig. Unvorteilhaft ist auch die Beschränkung auf eine Kommunikation zwischen grobgranularen Prozessen, was bei komplexen Anwendungen zu Problemen führen kann [SS07]. Abbildung 2.1: Architektur eines RPC-Systems [SS07] CORBA: Mit der Common Object Request Broker Architecture (CORBA) wird im Gegensatz zum prozeduralen Modell des RPC ein objektorientiertes Modell eingeführt. Das verteilte objektorientierte Modell zeichnet sich dadurch aus, dass der Zugriff auf Daten direkt über Objekte erfolgt und nicht wie beim RPC indirekt über einen RPC-Server. Wegen einer Datenübergabe mit Referenzparametern können komplexe Verarbeitungsvorgänge mit parallelem Zugriff auf Objekte besser modelliert werden. Die Abhängigkeit von einer zu restriktiven Wertparameter-Semantik wurde somit überwunden. Im Vergleich zum prozeduralen Ansatz verfügen die verteilten Objekte über eine beliebige Granularität

13 2. GRUNDLAGEN 10 und ermöglichen damit eine weitaus komplexere Modellierung der Objektinstanzen. CORBA ist keine Technologie im herkömmlichen Sinne, sondern ein objektorientierter, herstellerübergreifender Standard der Object Management Group (OMG), aus dem sich viele Implementierungen entwickelt haben (Orbix 1, VisiBroker 2, Teil von WebLogic 3, Teil von WebSphere 4 ). Historisch bedingt ist CORBA in Verbindung mit Unix-Betriebssystemen entstanden [HH10]. Die an der Kommunikation beteiligten Objekte werden durch eine Schnittstellenbeschreibung, formuliert in der COR- BA IDL, definiert und teilen dem Client mit, welche Daten und Methoden in einer bestimmten Anwendung zur Verfügung stehen. Aus der Schnittstellenbeschreibung werden ähnlich wie bei dem RPC Client- und Server-Stubs generiert, die den Merkmalen der jeweiligen CORBA-Implementierung unterliegen. Das objektorientierte Kommunikationsprotokoll Internet Inter-Object Request Broker Protocol (IIOP) stellt einen einheitlichen Aufrufmechanismus zur Verfügung, wodurch es möglich wird, dass heterogene Systeme miteinander kommunizieren können und dabei verschiedene Programmiersprachen verwenden. Für die Typisierung der Aufrufe existieren zwei Möglichkeiten. Zum einen statisch zur Compile-Zeit, zum anderen dynamisch zur Laufzeit. Zum Grundkonzept von CORBA gehören auch die so genannten Common Services [EF03]. Für diese Dienste ist die Schnittstelle und das Verhalten im Standard definiert. Der wichtigste Service ist hier der Name Service. Dieser Service ermöglicht dem Nutzer auf komplexe Adressen mittels einfacher Namen zuzugreifen. Da aber gleichzeitig dem URI-Modell 5 des Internets der Durchbruch gelang, erlangte diese Name-Service-Lösung keine so stark verbreitete Anerkennung. Die Programmiersprachen- und Plattformunabhängigkeit ist nur unter Verwendung einer verteilten CORBA-Landschaft gegeben, über dessen Grenzen hinweg keine Kommunikationspfade vorhanden sind. Die verschiedenen Implementierungen für die CORBA-Kommunikationskomponenten, jeweils auch Object Request Broker (ORB) genannt, unterscheiden sich durch herstellerspezifische Erweiterungen sehr stark in der Performance, Skalierbarkeit und Implementierung. Da die Kommunikationsprotokolle der verschiedenen ORBs nicht kompatibel zueinander waren, wurde in CORBA das General Inter-ORB Protocol (GIOP) eingeführt, das die Kommunikation zwischen den ORBs definiert. CORBAs aufwendige Integration, die schlechte Performance und eine komplizierte Architektur brachte ihm anfangs einen schlechten Ruf ein. Zumindest die Performance von CORBA steigerte sich auf ein Niveau vergleichbar mit Technologien wie RMI und ist in erster Linie von der Bandbreite und der Latenz des Netzwerkes abhängig [HH10]. Die Komplexität der Spezifikation führte immer wieder dazu, dass inkompatible Lösungen entstanden. COM/DCOM: Distributed Component Object Model (DCOM) 7 ist als Gegenpol zu CORBA für die Windows-Welt zu verstehen. Es erweitert die von Microsoft entwickelte Technologie Component Object Model (COM) um die Erstellung und Aktivierung von Objekten, den Umgang mit Objektreferenzen, den Lebenszyklen von Objekten, sowie die Spezifikation von Anfragen an die Objektschnittstelle. COM als Basis ist für die Vermittlung von Daten zwischen Prozessen verantwortlich und 1 Implementation einer OMG CORBA Spezifikation der Firma Progress Software. 2 CORBA ORB Infrastruktur-Produkt von Borland. 3 Oracle-Produktlinie für Unternehmensanwendungen. 4 Produktlinie der Firma IBM für Anwendungsintegration. 5 Universal Resource Identifiers (http : // Overview.html)

14 2. GRUNDLAGEN 11 nicht für die Netzwerkkommunikation geeignet bzw. konzipiert. Eine bekannte Technologie, die auf DCOM aufsetzt ist ActiveX. DCOM findet heute kaum noch Verwendung und wurde durch COM+ ersetzt [HH10]. RMI: Wie CORBA ermöglicht auch Remote Method Invocation (RMI) die Kommunikation mit entfernten Objekten unter Verwendung eines objektorientierten Modells. Die Kommunikation findet zwischen feingranularen Objekten statt, die sich auf Computern in einem verteilten System befinden und innerhalb von Betriebssystemprozessen eingesetzt werden. Ein Vorteil gegenüber dem RPC besteht darin, dass es durch die Modellierung mit einheitlichen Objekten zu keiner Trennung zwischen kommunizierende Betriebssystemprozessen und den übertragenen Datenstrukturen kommt. Die Kommunikation zwischen verteilten Objekten erfolgt durch eine Parameterübergabe per Objektreferenz [SS07]. Die Vorteile der Referenzparameter-Semantik wurden bereits in dem Abschnitt CORBA genannt. RMI ist in die Programmiersprache Java eingebettet (Java RMI) und Bestandteil der Java Standard Edition. Die IDL wird in Java mit dem interface-konstrukt definiert. Unter Einsatz des RMI- Compilers rmic werden Client- und Server-Stubs generiert. Die Stubs können über das RMI-IIOP- Protokoll miteinander kommunizieren [EF03]. Um die Methoden der Schnittstellenbeschreibung aufzurufen, muss ein Server diese anbieten. Ein entferntes Objekt wird in der Java Virtual Machine (JVM) aufgerufen, die auf dem gleichen bzw. einem entfernten Computer installiert ist. In der Abbildung ist beispielhaft dargestellt, was bei einem entfernten Methodenaufruf mit RMI passiert. Das Szenario beschreibt die Auswahl einer Service Beschreibung aus einer Liste von Service Beschreibungen. Der Client erstellt zuerst ein Objekt I, mit dessen Hilfe er die Methoden eines Server Objektes L ansprechen kann, um auf die Liste zuzugreifen. Der Client wählt in diesem Beispiel eine Service Beschreibung aus und erhält daraufhin vom Server eine Referenz auf ein Objekt, das die gewählten Beschreibung repräsentiert. Dieses Objekt muss nicht wie in der Abbildung auf dem gleichen Server positioniert sein, sondern kann sich auch auf einem entfernten Server befinden. Nachdem durch den Class Loader möglicherweise fehlende Klasseninformationen nachgeladen wurden, kann das Objekt I die Methoden von S aufrufen und beispielsweise die Adresse oder Authentifizierung gegenüber dem Services erfragen. COM+: COM+ ist die Weiterentwicklung der COM- und DCOM-Technologie. Die erste Referenzimplementierung ist in Windows 2000 integriert und in allen neueren Windows-Betriebssystemen zu finden. Gegenüber den älteren Technologien wurden das Load Balancing, Security und Transaktionen verbessert. 2.2 SOA Eine erste Definition für SOA wurde bereits am Ende des Kapitels 2.1 vorgestellt. Eine weitere Definition [Mel07] beschreibt Serviceorientierte Architekturen als das abstrakte Konzept einer Software- Architektur, in deren Zentrum das Anbieten, Suchen und Nutzen von Diensten über ein Netzwerk steht. Die Abstraktion ist ein wesentlicher Aspekt der Serviceorientierung und hat das Ziel, mög- 8 Die Abbildung unterliegt geringfügigen Änderungen gegenüber dem Original.

15 2. GRUNDLAGEN 12 Client Server 1. Aufruf 2. Antwort mit Referenzparameter L Server-Objekt Liste mit Service Beschreibungen Objekt für Benutzerinteraktion I 3. Laden von Klasseninformationen zu S 4. Aufruf von S 5. Antwort S Server-Objekt Service Beschreibung Abbildung 2.2: Entfernter Methodenaufruf mit RMI [SS07] lichst viele interne Details eines Services zu verbergen. Dadurch ist es möglich die Abhängigkeiten zwischen Serviceanbietern und -konsumenten zu reduzieren und eine lose Kopplung von Services zu gewährleisten. SOA ist als Modell einer Architektur zu verstehen, die unabhängig von einer speziellen Technik der Realisierung oder einer speziellen technischen Plattform ist. Eine ausführlichere Beschreibung der Aspekte einer SOA wird in dem Kapitel vorgestellt Dienste Der zentrale Gegenstand der serviceorientierten Architektur ist der Dienst (Service). Der Dienst ist der kleinste fachlich wiederverwendbare Bestandteil einer serviceorientierten Architektur [HH10] und kann durch ein Programm oder eine Softwarekomponente realisiert werden, welche lokal oder über ein Netzwerk von anderen Komponenten genutzt wird. Damit eine Nutzung überhaupt stattfinden kann, wird der Dienst durch eine Schnittstelle und die ausgeübte Funktionalität beschrieben. Der Zugriff bzw. die Anfrage an den Dienst ist aussschließlich über die beschriebene Schnittstelle zulässig. Die Beschreibung des Dienstes ist unabhängig von der verwendeten Technologie, mit der der Dienst realisiert ist. Die Implementierung des Dienstes ordnet sich der Funktionalität unter und wird normalerweise verborgen. Es findet anders ausgedrückt eine Kapselung der Funktionalität nach dem Prinzip des Information Hiding statt. Diese Zusammenhänge sind zum besseren Verständnis in der Abbildung 2.3 visualisiert. Innerhalb der SOA muss ein Dienst über bestimmte Eigenschaften verfügen. Diese Eigenschaften in der Praxis einzuhalten ist ein geteilter Pfad, der durch viele Kompromisse zu begehen ist. Im folgenden werden diese Eigenschaften kurz vorgestellt [HH10]:

16 2. GRUNDLAGEN 13 Dienst Dienstnutzer Anfrage an den Dienst Implementierung (wird vollständig vor dem Dienstnutzer verborgen) Schnittstelle Antwort vom Dienst Abbildung 2.3: Dienst im Überblick [HH10] Der Dienst beschreibt eine eigenständige Funktionalität. Die beschriebene Funktionalität des Dienstes wird vollständig implementiert. Der Dienst bzw. die Implementierung kann weitere Dienste nutzen. Eine öffentliche Schnittstelle ist verfügbar. Durch eine Beschreibung des Dienstes bzw. Service Description kann der Dienstnutzer die Kommunikation zum Dienst aufnehmen. Die Beschreibung enthält Angaben wie die Adresse des Dienstes, Nachrichten und die Schnittstelle. Diese Beschreibung muss hersteller-, plattform- und technologieneutral sein. Jeder Dienst ist ein eigenständiges Artefakt. Da ein Dienst als eine unabhängige Einheit zu verstehen ist, kann er theoretisch jederzeit durch eine andere Implementierung ersetzt werden. Kenntnisse der Interna des Dienste sind nicht notwendig. Für die Nutzung des Dienstes wird eigentlich nur die Beschreibung der öffentlichen Schnittstelle gebraucht. In der Praxis kann die Unabhängigkeit der Dienste allerdings nicht immer umgesetzt werden oder ist in einigen Anwendungsfällen nicht sinnvoll. Falls beispielsweise mehrere Dienste mit dem gleichen Datenbestand arbeiten, ist eine Unabhängigkeit zumindest teilweise nicht mehr gegeben. Einige dieser Eigenschaften werden im nächsten Abschnitt im Zusammenhang mit den Entwurfsprinzipien einer SOA zur weiteren Erklärung verwendet Entwurfsprinzipien einer SOA Ein Prinzip ist eine allgemein anerkannte Vorgehensweise um ein gemeinsames Ziel zu erreichen. Im Kontext der Lösungserarbeitung ist ein Entwurfsprinzip eine empfohlene Richtlinie, um die Lösungslogik auf eine bestimmte Art und im Hinblick auf bestimmte Ziele zu erreichen(buch Erl). Die nachfolgenden Entwurfprinzipien einer SOA sind durch exakt festgelegte Regeln bestimmt, mit deren Hilfe sich eine Logik zerlegen lässt und in verteilbare Einheiten geformt werden kann. Da der Themenkomplex SOA sehr umfangreich ist und ganze Bücher füllt, wird an dieser Stelle nicht auf eine detailierte Beschreibung der einzelnen Prinzipien eingegangen. Vertiefende Informationen sind beispielsweise in der Literatur [Mel07] und [Erl08] zu finden. Verwendung von Standards: Damit ein Konsument einen Service eines Anbieters verstehen und nutzen kann, ist es wichtig die Serviceschnittstelle mittels offener Standards zu beschreiben. Damit wird gleichzeitig eine breitere Akzeptanz für die Architektur gewährleistet. Ein Schnittstelle sollte

17 2. GRUNDLAGEN 14 in maschinenlesbarer Form beschrieben werden, um von Anwendungen verstanden zu werden. Im folgenden ist von sogenannten Serviceverträgen die Rede. Diese beziehen sich auf Servicebeschreibungsdokumente, die von Anwendungen zur Laufzeit verarbeitet werden und beinhalten die Pflichten, die technischen Einschränkungen und Anforderungen, sowie semantische Informationen eines Services. Lose Kopplung: Eine Kopplung stellt eine Verbindung zwischen zwei Entitäten her und ist als eine Abhängigkeit zwischen diesen zu verstehen. Bei bidirektionalen Abhängigkeiten ist die Kopplung so gestaltet, dass jede Anwendungen das Vorhandensein der jeweils anderen benötigt, um richtig funktionieren zu können. Im Falle der unidirektionalen Kopplung besteht die Abhängigkeit nur in eine Richtung. Beispielsweise ist eine Anwendung von einer Datenbank abhängig, aber nicht umgekehrt. Mit der Reduktion der Kopplung in und zwischen Services, also der losen Kopplung, wird das Ziel angestrebt, die Abhängigkeit von Serviceverträgen zu ihren Implementierungen zu verringern und Services unabhängiger voneinander zu machen. Somit ist es möglich, dass Services bei Bedarf dynamisch gesucht, gefunden und eingebunden werden können. Abstraktion von Diensten: Abstraktion ist ein Konzept, bei dem Anwendungsinformationen, die andere Instanzen nicht unbedingt benötigen, verborgen werden. Der Servicevertrag sollte bei der Angabe von Informationen über Technologie, Logik und Funktionen möglichst knapp gehalten werden. Damit lässt sich eine enge Abhängigkeit zwischen einem Service und deren Konsumenten verhindern und implementierungsspezifische Daten werden versteckt. Bei der Abstraktion der Programmlogik werden interne Details einer Anwendung absichtlich nicht veröffentlicht. Der Zugriff der Konsumentenanwendung ist auf die bereitgestellten öffentlichen Funktionen einer API begrenzt. Interne Informationen, wie beispielsweise Routinen, Algorithmen und Ausnahmebehandlungen sind somit nicht einsehbar und können unter Berücksichtigung der vertraglich vereinbarten Funktionalität ausgetauscht werden. Wiederverwendung: Die Wiederverwendung bezieht sich auf die Programmlogik eines Services. Indem die Servicelogik wiederholt wird, zahlen sich die Anfangsinvestitionen bei der Erstellung des Services gewinnbringender aus. Es wird eine agile Anwendungsentwicklung gefördert, die zukünftige Automatisierungsanforderungen, unter Zuhilfenahme zum Teil bestehender Services, durch Servicekompositionen effektiver umsetzen kann. Programmteile, die für mehr als einen einzigen Zweck nützlich sind, stellen somit einen wiederholten Mehrwert dar und steigern den maximalen Gewinn einer Software. Die Logik eines wiederzuverwendeden Services unterstützt viele Einsatzzwecke unterschiedlicher Typen von Servicekonsumenten und fällt somit hochgradig generisch aus. Bei der Erstellung von Serviceverträgen ist auf genügend Flexibilität zu achten, die die Definition der unterschiedlichen Ein- und Ausgabenachrichten ermöglicht. Verzeichnisdienst: Ein Verzeichnisdienst unterstützt die Suche nach einzelnen Einheiten einer Lösungslogik. Das Suchen und Finden einer Lösungslogik in einer bestimmten Umgebung wird als Discovery bezeichnet. Die Idee der gelben Seiten spielt hierbei eine wesentliche Rolle. Für das Discovery müssen demnach drei notwendige Voraussetzungen erfüllt sein: der Zugriff auf eine Instanz der gelben Seiten muss möglich sein, man muss wissen unter welcher Kategorie eine gesuchte Lösungslogik zu finden ist und die entsprechende Logik muss sich im verwendeten Suchkatalog registriert haben. Sowohl die Einträge in einem Verzeichnisdienst als auch die Serviceverträge müssen Metainforma-

18 2. GRUNDLAGEN 15 tionen zu den Merkmalen der Auffindbarkeit und Interpretierbarkeit einzelner Services enthalten. Die Interpretation eines Services ist der Prozess des Verstehens von dessen Zweck und Fähigkeiten. Die Basis einer SOA bilden die offenen Standards, Sicherheit und Einfachheit. Die beiden letzten Punkte, Sicherheit und Einfachheit, stellen keine wirklichen Entwurfsprinzipien dar. Sie sind vielmehr die notwendigen Voraussetzungen für die Entwicklung einer SOA und bestimmen die Akzeptenz von der Benutzerseite. Darauf aufbauend wird eine SOA anhand der beschriebenen Entwurfsprinzipien umgesetzt Bestandteile auf technischer Ebene Eine serviceorientierte Architektur lässt sich in verschiedene Ebenen unterteilen, deren Verhalten durch Prozesse charakterisiert ist und auf Basis von Diensten abläuft. Die eigentliche Leistung bei der Entwicklung einer SOA ist die Erfassung und Modellierung von Prozessen oder auch Geschäftsabläufen. Dieser Teil bleibt oft auch hinter der Präsentationsebene verborgen, weil externe Partner die internen Details unzureichend kennen bzw. aus bestimmten Gründen nicht immer kennen sollen [Mel07]. In Abbildung 2.4 sind die Ebenen und die wichtigsten Bestandteile einer SOA dargestellt. Benutzer- Schnittstelle Benutzer- Schnittstelle Präsentation Prozess Prozess Prozess Orchestration Dienst Dienst Basic Service Daten Daten Abbildung 2.4: Prozesse und Dienste in einer SOA [HH10] Presentation Layer: Die Nutzung von Prozessen wird durch die Bereitstellung einer Benutzerschnittstelle gewährleistet. Die Realisierung einer solchen Benutzerschnittstelle kann durch ein Portal, einen Rich-Client oder eine Weboberfläche erfolgen. Orchestration Layer: Diese Ebene unterstützt die Modellierung von Geschäftsprozessen und stellt den dynamischen Teil einer serviceorientierten Architektur dar. Für die Modellierung der Geschäftsprozesse existieren verschiedene Kompositionssprachen. Beispiele hierfür sind BPML 9, WS-CDL 10 oder BPEL4WS Business Process Modeling Language 10 Web Services Choreography Description Language 11 Business Process Execution Language for Web Services

19 2. GRUNDLAGEN 16 Service Layer: Die verwendeten Dienste sind in der Serviceebene angesiedelt. Sie sollten unabhängig voneinander modelliert sein und finden Verwendung bei verschiedenen Geschäftsprozessen. Die Basisdienste stellen die Daten einer serviceorientierten Architektur bereit und enthalten eine eigenständig funktionierende Einheit einer Geschäftslogik. Das Ebenenmodell aus Abbildung 2.4 stellt ein idealisiertes Abbild einer SOA-Umsetzung dar. Bei der praktischen Umsetzung ist allerdings der Einsatz von Services nicht auf eine Ebene beschränkt. Vielmehr werden Dienste auf mehreren Ebenen verteilt und es besteht die Möglichkeit, dass ein Dienst mehrere andere Dienste aufruft. Aus diesem Grund kann zwischen den Ebenen Basic Service und Orchestration noch eine vierte Ebene, die Ebene Intermediate Service, eingeführt werden. In dieser Ebene fungieren die Dienste als Adapter, Fassade oder auch Gateway zu weiteren Services oder Technologien [HH10] Rollen Das wichtigste Element einer SOA ist der Service. Bei dem Erstellen von und dem Kommunizieren mit Services können den beteiligten Instanzen drei verschiedenen Rollen zugeordnet werden. Zum einen gibt es einen Anbieter, der den Zugriff auf den Service ermöglicht und zur Nutzung eine öffentliche Servicebeschreibung bereitstellt. Weiterhin gibt es die Rolle des Nutzers. Dieser greift auf den Service zu und nimmt die angebotene Funktionalität in Anspruch. Bei der dritten Rolle handelt es sich um einen Vermittler, der die Kommunikation zwischen Anbieter und Nutzer ermöglicht. In den folgenden Abschnitten werden die genannten Rollen genauer vorgestellt. Eine Übersicht der Rollen und deren Verhalten ist in Abbildung 2.5 dargestellt. In den folgenden Abschnitten wird das Verhalten der Rollen beschrieben. Verzeichnisdienst Verweis auf Dienst suchen veröffentlichen Serviceanbieter Abfrage der Beschreibung Nutzung Servicenutzer Abbildung 2.5: Grundlegender Ablauf in einer SOA Serviceanbieter Der Serviceanbieter muss mindestens einen Service bereitstellen. Dieser Service muss nicht unbedingt vom Anbieter selbst entwickelt und implementiert worden sein. Es besteht auch die Möglichkeit,

20 2. GRUNDLAGEN 17 dass der Anbieter andere Services eines Verteilten Systems nutzt bzw. einen vereinfachten Zugriff auf diese ermöglicht und anbietet. Der Anbieter ist also in der Lage eine Kombination von verschiedenen Services durchzuführen. Hierbei werden zwei grundlegende Ansätze unterschieden [SS07]. Bei der Orchestrierung wird ein zusammengesetzter, komplexer Service durch die Kombinationen von vorhandenen Services erstellt. Die Funktionalität des neuen Services ergibt sich somit aus der Komposition der einzelnen Services. Die Orchestrierung unterstützt die Kapselung von einzelnen Services und sorgt dafür, dass diese nach Außen verdeckt gehalten werden. Der zweite Ansatz wird als Choreographie bezeichnet und verwendet einzelne Services, die zu einem Geschäftsablauf zusammengesetzt werden. Es wird eine Ablaufbeschreibung angeboten, die die Kommunikation mit verschiedenen Services einbezieht und die Sichtbarkeit der Services nach Außen unterstützt. Allgemein betrachtet ist die Aufgabe des Serviceanbieters eine Plattform zur Verfügung zu stellen, deren Betrieb kontinuierlich aufrecht gehalten wird und somit die Verfügbarkeit der angebotenen Services ermöglicht [Mel07]. Wichtige Aufgaben hierbei sind die Datensicherung, die Wartung der Plattform und die Einhaltung von Quality of Service -Eigenschaften. Es muss auch möglich sein, dass die Identität eines Servicekonsument überprüft wird und Rechte für die Nutzung von bestimmter Funktionalität vergeben werden. Somit sollte der Serviceanbieter Mechanismen zur Authentifizierung und Authentisierung unterstützen. Um einen Service zu veröffentlichen kann der Serviceanbieter diesen bei einem Verzeichnisdienst registrieren Servicekonsument Der Servicekonsument nutzt die angebotene Funktionalität des Serviceanbieters. Zwischen diesen Rollen besteht eine lose Bindung, bei der dem Konsumenten eigentlich egal ist, welcher Anbieter die gesuchte Funktionalität anbietet. Weil die Services meist zur Laufzeit ausgewählt werden, beispielsweise im Zusammenhang mit einem Verzeichnisdienst, ist es für den Konsumenten vor allem wichtig, dass offene Standards verwendet werden. Diese unterstützen die Suche, den Aufruf und die Kommunikation mit verschiedenen Anbieter durch den Gebrauch der selben Protokolle Verzeichnisdienst Bei der Rolle des Verzeichnisdienstes, auch als Registry bekannt, handelt es sich um die Umsetzung des gleichnamigen Entwurfsprinzips, dessen Merkmale bereits vorgestellt wurden. Weiterhin ist zu sagen, dass der Verzeichnisdienst eine Klassifizierung der Services nach bestimmten Kriterien unterstützen muss. Dies setzt voraus, dass bestimmte Arten von Informationen, die über einen Service bekannt sind, abstrahiert werden können. Hierbei handelt es sich somit um eine Metaabstraktion [Erl08], also eine Abstraktion der Metainformationen eines Services. Die wichtigsten Typen von Metainformationen werden folgend kurz beschrieben [Erl08]: Technologische Informationen - beschreiben die technische Implementierung der zugrunde liegenden Servicelogik, Funktionale Informationen - beschreiben die Fähigkeiten des Services,

21 2. GRUNDLAGEN 18 Programmlogikinformationen - beschreiben, wie der Service seine Fähigkeiten ausführt, Informationen über Servicequalität - beschreiben das Verhalten, die Beschränkungen und die Interaktionsanforderungen des Services. Die Benutzung des Verzeichnisdienstes bzw. die Suche nach Services sollte auf die gleiche Art und Weise erfolgen, wie die Benutzung anderer Services. Dadurch wird zusätzlicher Kommunikations- Overhead vermieden und die Akzeptanz der Service-orientierten Architektur nicht beeinträchtigt Aktionen Durch die Bestimmung der Rollen einer SOA ist es nun möglich die wichtigsten Aktionen zwischen den Rollen exakt zu bestimmen. Diese wurden zum Teil schon im Text zuvor verwendet und sollen an dieser Stelle betonend herausgestellt werden. Um die Veröffentlichung eines Services vorzunehmen, reicht es nicht aus diesen bei einem Verzeichnisdienst anzumelden. Der Service muss als erstes auf einem Server installiert sein, was auch als Deployment bezeichnet wird und von Außen erreichbar sein. Erst danach ist eine Registrierung bei einem Verzeichnisdienst sinnvoll. Durch die Veröffentlichung kann ein Client, der nur den Namen eines bestimmten Dienstanbieters kennt, auch die physikalische Adresse der gewünschten Dienste erfahren und auf diese zugreifen. Bei dem Suchen nach Services wird davon ausgegangen, dass Beschreibungen für einen Service auf der Basis von Taxonomien und Ontologien erstellt werden. Eine derartige Suche kann man sich wie die Suche nach Webseiten im Internet vorstellen. Allerdings erfolgt das Durchforsten der Quellen auf eine unterschiedliche Art und Weise. Eine genau Beschreibung dieser Abläufe ist an dieser Stelle leider nicht möglich. Eine vereinfachte Erklärung wurde bereits mit dem Vergleich zu den gelben Seiten gegeben. Die Dienste werden kategorisiert und jede Kategorie enthält eine Liste von möglichen Diensten. Die Interaktion mit Diensten erfolgt entweder direkt, wobei der Dienstnutzer den Dienstanbieter bereits kennt, oder indirekt über ein Discovery-Tool, das entweder beim Anbieter, dem Nutzer oder einer dritten Instanz angesiedelt ist [EF03]. Falls sich Dienstnutzer und -anbieter kennen, müssen sich beide zuerst über die Syntax und die Semantik ihrer Interaktion verständigen. Die Syntax wird mithilfe des Formates der Dienstbeschreibung ausgedrückt und die Semantik umfasst die Funktion und die Bedeutung aller Ein- und Ausgabeparameter, die für die Nutzung des Dienstes erforderlich sind. Der Nuzter kann dann die Dienstbeschreibung manuell anfordern, z.b. per Mail-Verkehr, oder dynamisch durch eine Software vom Dienstanbieter abrufen. Anschließend kann der Dienst unter der Kenntniss der Semantik genutzt werden. Falls der Dienstnutzer den Anbieter nicht kennt und es mehrere Anbieter gibt, kann der Nutzer den gewünschten Dienst manuell auswählen oder automatisch auswählen lassen. Unter der Voraussetzung, dass eine Vereinbarung über die Semantik abgeschlossen wurde, liefert das Discovery-Tool nun direkt die Dienstbeschreibung oder die Adresse des Anbieters, von dem die Dienstbeschreibung angefordert werden kann. Weiterhin ist es möglich, dass anhand der Semantik das Discovery-Tool einen passenden Service für den Nutzer automatisch auswählt. Für die Nutzung eines Dienstes bestehen möglicherweise bestimmte Voraussetzungen. Dabei kann es

22 2. GRUNDLAGEN 19 sich um Zertifikate oder Vereinbarungen über die Authentifizierung handeln. Diese Voraussetzungen werden durch Richtlinien kenntlich gemacht und vertraglich vereinbart. Falls eine Einigung erfolgt ist, spricht man von einer erfolgreichen Bindung an den Dienst. 2.3 REST Representational State Transfer (REST) ist ein Architekturstil für verteilte Hypermediasysteme, der in der Dissertation [Fie00] von Roy Thomas Fielding aus dem Jahre 2000 beschrieben wird. Fielding war von Anfang an in die Standardisierung der entwickelten Webprotokolle involviert. Ursprüglich konzipierte er ein Modell mit dem Namen HTTP Object Model, das er während der Standardisierung von HTTP 1.0 und der Weiterentwicklung zu HTTP 1.1 als Rahmen für das Design von REST verwendete und bei aufkommenden Veränderungen erweiterte [Til09]. Das Ziel des ursprünglichen Modells war die Definition eines einheitlichen Konzeptes für statische Inhalte und dynamisch berechnete Informationen, die zusammen ein globales Informationssystem bilden. In seiner Dissertation abstrahierte Fielding von der konkreten Syntax und den Details des Protokolldesigns, die HTTP mit sich bringt. REST ist somit eine Stufe abstrakter als die HTTP-Architektur und könnte theoretisch auch mit einem anderen Satz von Protokollen umgesetzt werden. Oftmals ist es aber so, dass REST als Protokoll ausgelegt wird, obwohl es weder ein Produkt noch einen Standard beschreibt. Ein Grund dafür ist die Entstehung von REST auf der Basis von HTTP [HH10]. Eine konkrete Ausprägung des Architekturstils REST ist derzeit ausschließlich durch die Web-Standards gegeben. Damit sich der moderne Architekturstil REST aus der traditionellen Web-Architektur entwickeln konnte, mussten bestimmte grundlegende Bedingungen erfüllt sein. Die Untersuchung dieser Bedingungen ermöglichte die Identifizierung der Eigenschaften des Web und damit die Entwicklung einer neuen und modernen Web-Architektur. Die erste Bedingung beinhaltet die Trennung von Verantwortlichkeiten durch die Anwendung einer Client-Server-Architektur, die das User-Interface von der zugrundeliegenden Datenbank trennt. Dadurch kann das User-Interface auf mehrere Plattformen verteilt werden. Die Serverkomponenten können vereinfacht und voneinander getrennt entwickelt werden. Dies fördert die Skalierbarkeit des Systems, einschließlich der unabhängigen Web-Domänen. Die Kommunikation dieser Client-Server-Architektur erfolgt zustandslos und wird in Abschnitt noch genauer betrachtet. Aus Effizienzgründen sollten Antworten zwischengespeichert werden. Dies kann durch einen Cache geschehen und erspart beispielsweise wiederholende Anfragen an einen Serviceanbieter in einem bestimmten Zeitintervall. Eine der wichtigsten Bedingungen ist die Bereitstellung einer einheitlichen Schnittstelle zwischen den Komponenten. Die Standardisierung des Interfaces ist für einzelne spezielle Anwendung zwar nicht effektiver, weil die einzelnen Bedürfnisse der Anwendungen dabei nicht individuell berücksichtigt werden können. Aber für den Einsatz eines breitgefächerten hypermedialen Datentransfers ist diese Vorgehensweise sehr viel vorteilhafter. Die einheitliche REST-Schnittstelle ermöglicht eine Vereinfachung der Komponenten, die Sichtbarkeit von Interaktionen und die Entkopplung von Service-Implementierungen, wodurch eine unabhängige Komponentenentwicklung und -verteilung gewährleistet ist. Eine weitere Bedingung ist das Vorhandensein einer hierarchischen Schichtenarchitektur. Den einzelnen Schichten werden Verantwortlichkeiten anvertraut, wie beispielsweise die Kapselung existierender Software durch Adapter, die Aus-

23 2. GRUNDLAGEN 20 stattung des Client mit Vorverarbeitungsfunktionen oder die Verteilung komplexer Arbeitsabläufe auf mehrere Server. Die Funktionalität lässt sich gezielt zwischen den Schichten verschieben und verbessert damit die Lastverteilung, die Fehlertoleranz und die parallele Verarbeitung. Bei der letzten Bedingung handelt es sich um die Technologie Code-On-Demand, die optional eingesetzt werden kann. Durch Code-On-Demand werden Programme von einem Server zu einem Client geschickt und dort ausgeführt. REST erlaubt dem Client somit seine Funktionalität zu erweitern, indem die entsprechenden Programme heruntergeladen und auf dem Client ausgeführt werden. Derartige Programme sind beispielsweise Applets, Skripte oder Widgets [Fie00]. Im nächsten Abschnitt werden die Kernprinzipien vorgestellt, die das Gesamtbild von REST vervollständigen werden Entwurfsprinzipien In Kapitel wurden die Entwurfsprinzipien einer Serviceorientierte Architektur vorgestellt. Für den Architekturstil REST existieren ebenso wie für SOA bestimmte Regeln um ein System in verteilbare Einheite zu untergliedern. Wenn diese Regeln bei dem Entwurf und der Implementierung eines verteilten Hypermediasystems eingehalten werden, bezeichnet man die in diesem System integrierten Webanwendungen und Dienste als RESTful Web Services. Mit der Einschränkung von REST auf die wichtigsten Regeln, bilden sich die folgenden fünf Kernprinzipien heraus [Til09]: Ressourcen mit eindeutiger Identifikation Hypermedia Standardmethoden Unterschiedliche Repräsentationen Statuslose Kommunikation Diese Kernprinzipien müssen somit bei der Umsetzung der Gesamtarchitektur und der verteilten Komponenten eingehalten werden. In den folgenden Abschnitten werden diese Prinzipien genauer betrachtet. Dabei werden zur Verdeutlichung der Zusammenhänge die bekannten Webstandards als eine Ausprägungsform des REST Architekturstils herangezogen Ressourcen mit eindeutiger Identifikation Eine mögliche Definition für Ressourcen ist die folgende: A resource is a conceptual mapping to a particular entity or entity set that you want your service to be able to work with. [Fla08] Eine Ressource ist ein fundamentales Element der Web-Architektur. Es handelt sich dabei um eine Quelle, die an einer beliebigen Stelle im Web positioniert ist und sowohl eindeutig als auch standardisiert durch URIs oder URLs 12 identifiziert wird. Informationen, Ansammlungen von Daten, beispielweise eine Liste mit Informationen, aber auch Bilder und Audiodateien werden durch Ressourcen 12 Uniform Resource Locator

24 2. GRUNDLAGEN 21 repräsentiert. Es ist weiterhin möglich die unterschiedlichen Komponenten einer Web-Applikation durch Ressourcen darzustellen. Diese Komponenten werden auch als Entitäten eines Domänenmodells bezeichnet [HH10] und können anderen Anwendungen bzw. Clients zur Verfügung gestellt werden. Die Nutzung von Ressourcen erfolgt durch das Protokoll HTTP 13. HTTP stellt für die Kommunikation zwischen den Kommunikationsteilnehmern bestimmte Standardmethoden zur Verfügung, die in der HTTP-Spezifikation beschrieben sind. Die Standardmethoden von HTTP werden später noch genauer betrachtet Hypermedia Mit Hypermedia ist das Verknüpfen und die Nutzung von Ressourcen untereinander zu verstehen. Dieses Prinzip wird als HATEOAS bezeichnet, welches formal beschrieben für Hypermedia as the engine of application state steht. Der Hypermedia-Ansatz funktioniert anwendungsübergreifend und aufgrund des globalen Namensschemas lassen sich theoretisch alle Ressourcen des Web miteinander verknüpfen. Eine Ressource wird durch eine URI eindeutig identifiziert und kann eine Verknüpfung zu einer anderen Ressource enthalten. Hinter der Zielressource einer Verknüpfung können sich beispielsweise Daten einer andere Anwendung, eines anderen Servers oder einer Ressource einer anderen Domain verbergen. Anwendungen können diese Verknüpfungen auswerten oder an andere Anwendungen weiterleiten. Noch wichtiger ist allerdings die Steuerung des Applikationszustandes über Hypermedia. Indem der Link einer Anwendung verfolgt wird, ändert sich der Zustand der Anwendung in den nächsten. Über Links wird dem Client mitgeteilt, welche Zustandstransitionen möglich sind und welche Aktionen ausgeführt werden können Standardmethoden Die bereits erwähnte einheitliche Schnittstelle wird von allen Ressourcen mit dem gleichen Satz an Methoden unterstützt. Unter der Voraussetzung, dass alle Kommunikationsteilnehmer die gleiche Schnittstellendefinition verstehen, weiß jeder Dienstnutzer welche Methoden er benutzen muss, um Daten von einem Dienstanbieter zu erhalten. Es können alle von der Schnittstelle zur Verfügung gestellten Methoden verwendet werden. Falls ein Client eine spezifische Ressource eines Dienstanbieters mit einer Methode aufruft, die von dem Dienstanbieter nicht unterstützt wird, bekommt der Client als Antwort eine entsprechende Fehlermeldung. Das HTTP-Protokoll unterstützt genau diese Vorgehensweise und bietet zur Kommunikation die Operationen GET, POST, PUT, DELETE, HEAD und OPTIONS an, die somit bei einer REST- Kommunikation verwendet werden. Als Nächstes wird die Funktionsweise dieser Methoden beschrieben [HH10], [Til09], [Bur09]: GET: GET ist eine Leseoperation. Die Operation dient dazu Informationen, die durch eine URI identifiziert werden, von einem Server zu erfragen. GET ist als sicher (safe) und idempotent definiert. Idempotent bedeuted, dass die Operation beliebig oft aufgerufen werden kann und jedesmal die gleichen Seiteneffekte bewirkt. In diesem Fall bleibt die Antwort des Servers jedesmal 13 Hypertext Transfer Protocol

25 2. GRUNDLAGEN 22 die gleiche, außer es findet eine serverseitige Änderung statt. Durch das Lesen der Repräsentation einer Ressource wird somit die Ressource nicht verändert. Im Zweifelsfall besteht also die Möglichkeit zur Wiederholung einer Operation ohne dass die Ressource beeinflußt wird. Wenn eine Operation sicher ist, dann hat die Operation keinen Einfluß auf den Zustand des Servers. Entscheidend ist hierbei, dass der Client nicht explizit eine Zustandsänderung anfordert. PUT: Die Operation PUT bewirkt, dass eine Ressource erzeugt wird oder falls die Ressource schon besteht, aktualisiert wird. Informationen, die für eine Ressource bestimmt sind, werden im Body der HTTP-Nachricht verschickt. Der Server kann dann anhand des Content-Type- Header das Format dieser Informationen bestimmen. Der Client muss bei einem PUT die URI der Ressource angeben, die er neu anlegen oder verändern möchte. PUT ist idempotent. Falls eine Ressource mit den gleichen Informationen mehrmals hintereinander verändert wird, bleibt der Zustand der Repräsentation der gleiche. POST: Auch POST kann zum Anlegen neuer Ressourcen verwendet werden. Der Client gibt aber nicht die URI der Ressource an, die neu erstellt werden soll, sondern die URI der für das Anlegen zuständigen Ressource. Die URI wird vom Server bestimmt und über einen Location- Header der HTTP-Antwort an den Client zurückgeschickt. Die Operation ist weder idempotent noch sicher und es ist nicht möglich Antworten zu cachen. Weiterhin kann POST eingesetzt werden, wenn es keine andere Operation gibt, die eine beliebige Verarbeitung bzw. Funktionalität auf Seiten des Servers anstoßen kann. Diese Funktionalität wird dann in den übertragenen Daten codiert. DELETE: Mit DELETE wird eine Ressource gelöscht, deren URI im Request übertragen wird. Weil beim mehrmaligen Löschen einer Ressource das gleiche passiert wie beim einmaligen, ist diese Operation idempotent. Bei dem Vorgang des Löschens kann für die interne Datenrepräsentation ein entsprechendes Attribut gesetzt werden, das die Ressource als gelöscht markiert. Da der Client nur das nach außen sichtbare Verhalten wahrnimmt, ist für ihn diese Ressource nicht mehr verfügbar. HEAD: HEAD ist annähernd die gleiche Operation wie GET. Der einzige Unterschied besteht darin, dass nicht die Repräsentation der Ressource zurückgeliefert wird, sondern nur die Metadaten einer Ressource, die in dem HTTP-Header übertragen werden. Es werden die gleichen Metadaten zurückgeliefert wie bei einem GET auf die gleiche URI. Damit kann der Client beispielsweise das Vorhandensein einer Ressource prüfen und das Format oder die Kodierung der gelieferten Daten feststellen. OPTIONS: Die Operation OPTIONS wird verwendet um Informationen über die Kommunikation mit einem Server zu erfahren. Im Allow-Header der HTTP-Antwort werden Metadaten übertragen, die Auskunft über die von einer Ressource unterstützten Operationen geben. OPTI- ONS wird von einem Server fakultativ eingesetzt. Ein Client kann sich nicht darauf verlassen, dass die Operation unterstützt wird. Weiterhin kann die Operation als sicher und idempotent ungestuft werden. Der Client kann die Antwort nur cachen, falls explizit die entsprechenden Cache-Header gesetzt sind. In Tabelle 2.1 sind die wichtigsten Eigenschaften dieser Methoden noch einmal übersichtlich darge-

26 2. GRUNDLAGEN 23 stellt. Dabei meint die Spalte identifizierbare Ressource, dass die aufgerufene URI mit der Ressource, auf die sich die Methode bezieht, identisch ist. Die Spalte sichtbare Semantik stellt dar, bei welcher Methode die Infrastruktur eine Erkennung der Bedeutung der Methode nachvollziehen kann. Es ist erkennbar, dass POST keine Garantien mit sich bringt. Somit kann es immer dann verwendet werden, wenn für eine beliebige Bearbeitung keine andere Methode zutreffend ist. Methode sicher idempotent identifizierbare Cache-fähig sichtbare Ressource Semantik GET X X X X X HEAD X X X X X PUT X X X POST OPTIONS X X O X DELETE X X X Tabelle 2.1: Eigenschaften der HTTP-Methoden [Til09] Unterschiedliche Repräsentationen REST-Komponenten führen Aktionen auf Ressourcen aus. Der Web-Browser stellt beispielsweise Informationen dar, die bei einer zuvor ausgeführten Anfrage von einem Service geliefert wurden. Der Service wird dabei von einem Server angeboten, der für die jeweilige Ressource eine Anzahl von Bytes in einem spezifischen Dateiformat an den Client ausliefert. Das ist die Repräsentation der Ressource. Repräsentationen werden dazu verwendet den Zustand einer Ressource auszudrücken und diesen unter Umständen zwischen den Komponenten auszutauschen. Eine Repräsentation besteht aus Daten und Metadaten, die die Daten beschreiben. Metadaten bestehen aus Name-Wert-Paaren, wobei der Name einen Standard festlegt, der die Struktur des Wertes bestimmt. Antwortnachrichten können Metadaten für die Repräsentation und die Ressource beinhalten. Das Datenformat einer Repräsentation ist als Media-Type bekannt. Die Representation kann mit einer Nachricht verschickt werden und durch Angabe des Media-Type vom Empfänger der Nachricht verarbeitet werden Statuslose Kommunikation Aus Gründen der Skalierbarkeit, Lastverteilung, Ausfallsicherheit, etc. findet die Kommunikation bei dem REST-Ansatz zustandslos statt. Bei der Kommunikation zwischen Client und Server wird der Sitzungszustand nicht vom Server gehalten. Der Zustand wird entweder vom Client gehalten oder vom Server in einen Ressourcenstatus umgewandelt. Das bedeuted, dass bei einer Anfrage alle Informationen enthalten sein müssen, die der Server zum Verarbeiten der Anfrage benötigt. Dadurch muss der Server keine Systemressourcen (z.b. Hauptspeicher, Datenbanken, etc.) zur Verfügung stellen, die durch Speicherung des Sitzungszustandes erforderlich wären. Die Bearbeitung von aufeinanderfolgenden Anfragen muss auch nicht durch die gleiche Serverinstanz erfolgen, wodurch die Kopplung zwischen Client und Server verringert wird.

27 3. WEB SERVICES 24 3 Web Services In Kapitel 2 wurde die Zielsetzung von verteilten Systeme beschrieben. Dabei geht es im Wesentlichen um die Verteilung von anwendungsspezischer Funktionalität, die von räumlich entfernten Anwendungen genutzt werden kann. Bei der Umsetzung von verteilten Systemen kam es immer wieder zu der Entstehung von Middleware-Lösungen, die die Nachteile und Einschränkungen früherer Technologien verbesserten und die komplizierten Details der Kommunikation zwischen den Rechner verbergen konnten. Ergänzend zu dem prozeduralen Modell (RPC) und dem objektorientierten Modell (CORBA, Java RMI), welche in Kapitel erklärt wurden, werden in diesem Kapitel zwei Ansätze für die Umsetzung der Kommunikation in serviceorientierten Architekturen vorgestellt. Einleitend wird erklärt was ein Web Service eigentlich ist und wie es zur Entstehung dieser Technologie kam. In Abschnitt 3.2 erfolgt anschliessend ein kurze Einführung in die SOAP Web Service. In Abschnitt 3.3 werden dann die Verfahren und Technologien für die Umsetzung und Nutzung von RESTful Web Services präsentiert und miteinander in Zusammenhang gebracht. 3.1 Was ist ein Web Service? Der Begriff Web Service wird im Umfeld von verteilten Anwendungen sehr häufig verwendet. Leider kommt es dabei häufig vor, dass die Bedeutungen der einzelnen Begriffserklärungen voneinander abweichen. Eine Definition, die sehr genau beschreibt wie ein Web Service funktioniert, ist die des World Wide Web Konsortium (W3C): A Web service is a software application identified by a URI, whose interfaces and binding 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. [ABG02] Diese Definition hebt hervor, dass ein Web Service eine softwarebasierte Anwendungen ist, die wie eine Internetseite durch das gängige Format der Uniform Resource Identifier (URI) eindeutig identifiziert werden kann. Somit kann ein Web Service unverwechselbar durch eine Adresse aus dem Internet adressiert werden. Ein Web Service besitzt eine oder mehrere Schnittstellen, welche in der extensible Markup Language (XML) beschrieben sind. Dadurch ist es dem Serviceanbieter möglich, einen Web Service zu definieren und diesen von den Servicenutzern suchen und konsumieren zu lassen. Durch die Verwendung von XML können Anwendungen, die diese Sprache verstehen, auf eine automatisierte Art und Weise mit den angebotenen Web Services verfahren. Die Kommunikation zwischen den Web Services und anderen Softwareanwendungen kann direkt mittels XML-basierten Nachrichtenaustausch über standardisierte Internetprotokolle erfolgen. Der Ansatz der Web Services entstand in einem industriellen Umfeld, das durch eine verstärkte Vernetzung von weltweit agierenden Unternehmen und der damit verbundenen Neuentstehung von

28 3. WEB SERVICES 25 Kommuniationsszenarien gekennzeichnet war. Web-Anwendungen waren zu Beginn ihrer Entstehung Business to Consumer (B2C) Anwendungen. Die bereitgestellten Dienste konnten durch die zur Verfügung stehende Infrastruktur des Internet angegesprochen und dargestellt werden. Wichtig hierbei war die adäquate Anpassung der Benutzerschnittstelle an die Bedürfnisse des Benutzers. Aufgrund der verstärkten Zusammenarbeit der Unternehmen kam es Ende der 90er Jahre zu der Entwicklung von Business to Business (B2B) Anwendungen. Es wurden marktwirtschafliche Strategien, wie Supply Chain Management (CRM) und Customer Relationship Management (CRM), eingeführt, die die vielschichtigen Beziehung zwischen Serviceanbieter und -nutzer bzw. Lieferant und Kunde abbildeten. Weiterhin entstanden elektronische Marktplätze, auf denen die Unternehmen branchenunabhängig und -spezifische ihre Dienste anbieten konnten. Wenn beispielsweise eine Lagerverwaltung eines Unternehmens nicht mehr über ein bestimmtes benötigtes Produkt verfügt, kann die Verwaltung auf dem elektronischen Marktplatz dieses Produkt suchen, Preise verschiedener Anbieter vergleichen und eine bestimmte Anzahl des entsprechenden Produktes bestellen. Eine Steigerung der Effizienz solch eines Prozesses kann durch automatisierte Geschäftsabläufe erfolgen und dadurch Kosten verringern. Aber nicht nur zwischen den Unternehmen, sondern auch innerhalb von Unternehmen kam es zu neuen Herausforderungen. Die Konsolidierung von unternehmensspezifischen Anwendungen versprach einen Gewinn hinsichtlich der anfallenden Bearbeitungszeit und den entstehenden Kosten. Das Problem hierbei war, dass bestehende Anwendungen über sehr verschiedene Rahmenbedingungen verfügten. Es ist nicht ungewöhnlich, wenn eine Legacy-Anwendung 1 in einer anderen Programmiersprache entwickelt wurde oder ein anderes Betriebssystem zum Einsatz kam, als dies bei aktuelleren Anwendungen der Fall ist. Der Ansatz der Enterprise Application Integration (EAI) versucht dieses Problem zu lösen und integriert die verschiedenen unterschiedlichen Anwendungen in neue Geschäftsprozesse oder kapselt diese zu einer einzelnen homogenen Anwendung. Die vorhandene Technologien konnten dieses Problem allerdings nicht effektiv lösen, was dazu führte, dass die existierenden EAI-Lösungen sehr komplex und sehr teuer waren [EF03]. Aus den vorgestellten Szenarien der B2B-Anwendungen und des EAI-Ansatzes ist ersichtlich, dass die serviceorientierten Technologien für die Lösung der Probleme interoperabel und damit unabhängig von der Programmiersprache und der Systemumgebung sein müssen. Organisatorische und technische Restriktionen, wie Firewalls und Sicherheitsrichtlinien, sollten bei der Umsetzung auch keine Probleme verursachen [SS07]. Mithilfe dieser Erkenntnisse versuchten nun einige Firmen einfache und kostengünstige Technologien zu entwickeln. Microsoft begann 1997 mit der Entwicklung des Simple Object Access Protocol (SOAP), das eine Vereinfachung der Kommunikation mit entfernten Objekten ermöglichen sollte. Dieses Protokoll wurde später vom W3C standardisiert. Zusammen mit IBM und Ariba (später HP) versuchte man eine Möglichkeit zu finden, Dienste global anzubieten und auffindbar zu machen. Aus dieser Idee entwickelte sich schließlich der Verzeichnisdienst Universal Description, Discovery and Integration (UDDI). Durch den Erfolg von SOAP und UDDI wurden diese Technologien zu Basistechnologien für Web Services [EF03]. Als weitere grundlegende Technologie kam noch die Web Service Description Language (WSDL) hinzu. Eine andere Ausprägung von Web Services entstand auf der Grundlage von REST. REST ist ein Architekturstil für verteilte Systeme, der die Informationen von Diensten auf Ressourcen verteilt und 1 Eine ältere Anwendung, die eine bestimmte noch benötigte Funktionalität liefert.

29 3. WEB SERVICES 26 hauptsächlich im WWW angewendet wird. Eine Einführung in die REST Architektur wurde bereits in Kapitel 2.3 gegeben. Dabei wurde anhand verschiedener Prinzipien gezeigt, was bei der Erstellung einer Web-Applikation beachtet werden sollte. Zur starken Ausbreitung von REST APIs kam es vorallem dadurch, weil diese leicht verständlich sind und relativ unkompliziert für die Beschaffung von Informationen genutzt werden können. Ein Vorteil von Seiten der Entwickler ist die gute Skalierbarkeit und damit verbunden der geringere Änderungsaufwand derartiger Anwendung. Die öffentlichen REST APIs zeichnen sich durch textuelle Beschreibungen für den Dienstzugriff aus und obwohl es verschiedene Ansätze für Beschreibungssprachen gibt, konnte sich bisher keine auf diesem Gebiet durchsetzen. Dies erschwert die Nutzung von RESTful Web Services in automatisierten Prozessen. Von einer anderen Seite betrachtet ist die Einfachheit aber auch eine Chance, so viele Nutzer wie möglich, für die Benutzung der einzelnen Dienste, zu gewinnen. Um API Beschreibungen von RESTful Web Service im Internet zu finden, können Webseiten wie ProgrammableWeb 2 bei der Suche helfen. ProgrammableWeb ermöglicht u.a. das Registrieren von und das Suchen nach APIs. Zum Zeitpunkt der Erstellung dieser Arbeit waren 2964 APIs registriert 3. Bei 482 APIs handelte es sich um SOAP Web Services und 2142 APIs wurden unter der Kategorie REST Protokoll aufgelistet. Diese Zahlen zeigen, mit Einschränkung auf die Webseite ProgrammableWeb, dass die Verbreitung öffentlicher REST Services wesentlich höher ist als die Verbreitung öffentlicher SOAP Services. 3.2 SOAP Web Services Dieser Abschnitt beschreibt die Basistechnologien der sogenannten SOAP Web Services SOAP Das Simple Object Access Protocol (SOAP) wurde ursprünglich von Microsoft entwickelt und wird in verteilten Systemen eingesetzt um strukturierte Daten auszutauschen. Die Nachrichten und die darin enthaltenen Daten werden durch XML-Dokumente beschrieben und können über verschiedene Transportprotokolle übertragen werden. Bei der Wahl des Transportprotokolls spielen bestimmte Anforderungen, wie Verfügbarkeit und Sicherheit, eine Rolle. Für eine weltweite Verfügbarkeit von Services kann HTTP für den Nachrichtentransport verwendet werden. Durch die Nutzung von XML ist SOAP plattform und -programmiersprachenunabhängig. Das SOAP-Nachrichtenformat ist unabhängig von der Anwendung, die die Nachricht empfängt. Die Anwendung kann die empfangene Nachricht und die mitgelieferten Daten anwendungsspezifisch auswerten. Das W3C begann 1999 mit der Weiterentwicklung von SOAP. In der Version 1.0 war SOAP auf das Transportprotokoll HTTP beschränkt. Die darauffolgende Version (SOAP 1.1, Mai 2000) unterstützte in Hinblick auf den Transport einen generischen Ansatz und bot damit die Möglichkeit verschiedene Transportprotokolle zu verwenden. Am 24. Juni 2003 wurde SOAP 1.2 vom W3C standardisiert und liegt auch heute noch in dieser Version vor. Gegenüber der Vorgängerversion werden in SOAP 1.2 die Angabe der Zahlen vom

30 3. WEB SERVICES 27 Protokollbindungen detailierter vorgestellt und das SOAP Encoding optional angeboten [ACKM04]. Weiterhin entfiel die Benutzung von SOAP als Akronym für Simple Object Access Protocol, weil diese Beschreibung nicht die eigentliche Idee hinter SOAP wiedergeben konnte Struktur und Inhalt einer SOAP-Nachricht Eine SOAP-Nachricht ist ein XML-Dokument dessen Wurzelelement der SOAP-Envelope (wörtlich: (Brief-)Umschlag) ist. In ihm befinden sich zwei weitere Teile, und zwar der SOAP-Header und der SOAP-Body. Der Aufbau einer SOAP-Nachricht ist in Quellcode 3.1 zu sehen: <?xml version =" 1.0 "?> <s : Envelope xmlns : s=" h t t p : / / www. w3. org /2003/05/ soap envelope " > <s : Header> </ s : Header> <s : Body> </ s : Body> </ s : Envelope > Quellcode 3.1: Struktur einer SOAP Nachricht Bei der Festlegung der zu verwendenden SOAP-Spezifikation muss ein URI angegeben werden. In diesem Beispiel lautet die URI Dadurch wird dem Empfänger der Nachricht mitgeteilt, dass die SOAP-Spezifikation Version 1.2 benutzt wird. Gleichzeitig wird durch den URI ein eigener Namespace für alle Tags, die zu den Basiselementen des Envelope gehören, festgelegt [Mel07]. Der SOAP-Header ist ein optionales Element, das entweder einmal oder gar nicht in der SOAP- Nachricht vorkommt. Typische Anwendungsfälle sind das Übertragen von sicherheitsrelevanten Information, wie kodierte Informationen über die Rechte des Absenders oder Token zur Identifikation des Absenders. An einer SOAP-Interaktion können mehr als zwei Knoten beteiligt sein. Zwischen Sender und Empfänger der SOAP-Nachricht liegen dann weitere Knoten bzw. Zwischenstationen, die als Intermediaries bezeichnet werden. Ein Anwendungsfall wäre zum Beispiel das Signieren der Nachricht von einer Zwischenstation, bevor diese an den Empfänger übermittelt wird. Dazu müssen die Zwischenstationen die Header-Elemente verstehen und verarbeiten können. Das ist durch die Angabe von Attributen in den Header-Elementen möglich. Es gibt maximal drei Attribute (role, mustunderstand, relay), die die Zwischenstationen interpretieren müssen, um die Header-Elemente weiterverarbeiten zu können. role: Dieses Attribut beschreibt, ob das Header-Element für einen bestimmten Knoten relavant ist. Dafür existieren drei vordefinierte Rollen und weitere können frei definiert werden. Die betroffenen Knoten sind die Zwischenstationen und der Empfänger. mustunderstand: Wenn dieses Attribut vorhanden ist, dann muss der adressierte Knoten das Header-Element verarbeiten oder kann es ignorieren. Die Werte des Attributes können auf true oder false gesetzt sein. Falls entsprechende Header-Elemente bearbeitet wurden, müs-

31 3. WEB SERVICES 28 sen diese aus der SOAP-Nachricht entfernt oder modifiziert werden. relay: Falls die Zwischenstation das Header-Element aus einen bestimmten Grund nicht verarbeitet, kann das ursprüngliche Element trotzdem weitergeleitet werden, wenn das relay-attribut auf true gesetzt ist [EF03]. Im Gegensatz zum SOAP-Header muss der SOAP-Body vorhanden sein, denn in ihm werden die Informationen zwischen den Kommunikationspartnern ausgetauscht. Diese Nutzdaten werden auch als Payload bezeichnet, deren inhaltliche Struktur anwendungsspezifisch ist und von den Vertragspartner zuvor vereinbart wurde. Bei dem Inhalt kann es sich beispielsweise um HTML-Seiten, Verträge oder Bestellformulare handeln. Der Inhalt des SOAP-Body muss ein wohl geformtes XML-Dokument ohne Prolog sein. Auf diese Weise ist es möglich die übertragenen Daten unter Verwendung von Parsern auszulesen und für die weitere Verarbeitung zu nutzen. In dem Quellcode 3.2 ist der Payload einer SOAP Nachricht dargestellt. Das Wurzelelement payload enthält die eigentliche Nachricht, die für den Empfänger bestimmt ist. In diesem Fall wird ein Text übermittelt. <s : Body> <b : payload xmlns : b=" h t t p : / / www. example. org /2011/01/ soap body " > <b : message> Ein b e l i e b i g e r Text f ü r den Empfänger. </b : message> </b : payload > </ s : Body> Quellcode 3.2: Beispiel für einer SOAP Body Falls es bei der Auswertung der SOAP-Nachricht zu Problemen kommt, kann in dem Body der Antwortnachricht ein Fault Block an den Sender zurückgeschickt werden. In dem Fault Block müssen bestimmte vordefinierte Elemente auftauchen, auf die hier nicht näher eingegangen wird. Weiterhin gibt es auch die Möglichkeiten Binärdaten mit den Nachrichten zu verschicken. Dies ist dann sinnvoll, wenn die Transformation von Anwendungsdaten in XML-Dokumente unbequem, überflüssig oder unwirtschaftlich ist. Für die Übertragung der Binärdaten gibt es verschiedene Wege [Sal02]: ein URL wird als Link eingesetzt oder die Daten werden als Attachments an die Nachricht angehängt, wie dies beispielsweise bei Direct Internet Message Encapsulation (DIME) der Fall ist [Gai02] WSDL Dieser Abschnitt beschäftigt sich mit der Frage wie eine Anwendung die anwendungsspezifischen Nachrichten, die innerhalb einer SOAP-Nachricht übermittelt werden, beschreiben kann. Die Web Service Description Language (WSDL) ist ein XML-Format zur Beschreibung von Web Services. Durch sie ist es möglich Schnittstellen mit ihren Operationen abstrakt zu beschreiben und technische Informationen, die zum Aufruf des Services nötig sind, festzuhalten. Der abstrakte Teil einer WSDL beschreibt den Namen des Services und die Nachrichten, die ein Servicekonsument aufrufen kann und die er als Antwort erhält. In dem konkreten Teil der WSDL werden die technischen Informationen beschrieben. Wichtig ist dabei die Festlegung der Protokollbindung und die Adresse des Dienstes.

32 3. WEB SERVICES 29 Die Sprache entstand aus der Zusammenführung zweier Vorgängersprachen, angetrieben von Microsoft, IBM und Ariba. Am 15. März 2001 wurde die Version 1.1 der WSDL-Spezifikation als W3C Note veröffentlicht. Diese Version wird standardmäßig bei der Entwicklung von Web Services verwendet. Die Weiterentwicklung von WSDL führte zu der Version 2.0, die am 26. Juni 2007 als W3C Recommendation veröffentlicht wurde. Diese Version ist allerdings in realen Systemen noch nicht sehr weit verbreitet. Trotzdem wird in den nächsten Abschnitten die Sprache WSDL 2.0 vorgestellt. Die Begründung für diese Entscheidung liegt darin, dass RESTfull Web Service mit Hilfe von WSDL 2.0 angesprochen werden können Überblick Zuvor wurde bereits angesprochen, dass eine WSDL-Beschreibung aus einem abstrakten und einem konkreten Teil besteht. Wie diese Trennung vollzogen wird, ist in Abbildung 3.1 zu erkennen. Zur Beschreibung des Dienstes stehen u.a. die dargestellten Elemente zur Verfügung, die einerseits die Funktionalität des Dienstes im abstrakten Teil und andererseits die technischen Details im konkreten Teil beschreiben. Description abstrakt konkret Interface Operation Message Exchange Pattern Binding Service Endpoint Abbildung 3.1: Elemente der WSDL-Beschreibung Bei der Anordnung der Elemente existiert die Regel, dass das description-element als Wurzelelement an erster Stelle des XML-Dokumentes angegeben wird. Dieses Element enthält alle weiteren Elemente der WSDL-Beschreibung als Kind-Elemente. Die Reihenfolge der anderen Elemente kann beliebig erfolgen und ist an keine feste Anordnung gebunden. Als nächstes werden die wichtigsten Elemente kurz vorgestellt [Mel07]: Interface: beschreibt die abstrakte Funktionalität des Services und kann aus mehreren Operationen zusammengesetzt sein. Operation: beschreibt wie die Nachrichten einer Operation in einer SOAP-Nachricht übertragen werden sollen. MEP: Message Exchange Pattern (MEP) beschreibt die Semantik der Abfolge der Nachrichten einer Operation [EF03].

33 3. WEB SERVICES 30 Binding: beschreibt wie der Service aufgerufen wird und assoziert ein Protokoll und ein Datenformat mit den Operationen eines Interfaces. Service: kann mehrere Endpoints enthalten und beschreibt somit wo sich der Service befindet. Endpoint: ist mit einer Bindung und einer Adresse, unter der der Service erreichbar ist, assoziert. Als nächstes werden die abstrakten und konkreten Teile einer WSDL-Beschreibung etwas genauer betrachtet Abstrakte Beschreibung Der abstrakte Teil der WSDL besitzt die Elemente interface, operation und types. Das Element interface wird in WSDL 1.1 als porttype bezeichnet und stellt eine Schnittstelle dar, die die grundlegende Funktionalität des Web Services beschreibt. In dem Quellcode 3.3 ist ein interface-element zu sehen, das einer Operation definiert, die aus einer Eingangs-, Ausgangs und Fehlernachricht zusammengesetzt ist. Jede Schnittstelle kann aus mehreren Operationen und fault- Elementen zusammengesetzt sein. Ein Element fault wird dann eingesetzt, wenn eine der kommunizierenden Parteien eine Operation nicht ausführen kann oder die Kommunikation beenden möchte 4. Das Element operation enthält weitere Elemente, die die Art der Eingabe- bzw. Ausgabenachrichten bei einem Operationsaufruf zwischen Serviceanbieter und- konsument bestimmt. Jede Operation enthält ein Attribut pattern, über welches verschiedene Message Exchange Patterns (MEPs) referenziert werden können, die in WSDL 2.0 definiert sind. Die Verwendung der Eingabebzw. Ausgabenachrichten wird dann durch das referenzierte pattern festgelegt. Falls bei der Kommunikation ein Fehler auftritt, kann über die Kind-Elemente infault und outfault auf einen bestimmten Fehler verwiesen werden, der wie bereits erwähnt in dem Interface durch fault definiert ist. < i n t e r f a c e name=" answerport " > < f a u l t name=" exception " element=" ans : invalidrequest " / > <operation name= " opanswer" p a t t e r n " h t t p : / / www. w3. org /2004/03/ wsdl / in out " > < i n p u t messagelabel= " In " element= " ans : answerrequest " / > <output messagelabel= " Out " element= " ans : answerresponse " / > < o u t f a u l t r e f = " tns : exception " messagelabel=" Out " / > </ operation > </ i n t e r f a c e > Quellcode 3.3: Definition der Operation eines interface-elementes Um einfache und komplexe Datentypen einer Nachricht zu definieren, gibt es in WSDL das Element types. Bei dieser Art von Datentypdefinition wird XML Schema verwendet. Die element- Attribute aus dem Quellcode 3.3 beziehen sich auf die in types definierten Datentypen. Da durch das types-element alle Nachrichtentypen zentral definiert werden, kann eine leichte Wiederverwendung in verschiedenen Operationen erfolgen [Mel07]. 4 Weitere Informationen zu dem Interface Fault sind unter zu finden.

34 3. WEB SERVICES Konkrete Beschreibung Im Gegensatz zu der abstrakten Schnittstellenbeschreibung wird mit den Elementen binding und service das konkrete Nachrichtenprotokoll, die physische Adresse des Web Service, sowie Detailinformationen hinsichtlich Transport und Kodierung der Nachricht, festgelegt. In dem Quellcode 3.4 ist ein binding-element dargestellt, dass mit dem zuvor dargestellten Interface (Quellcode 3.3) referenziert ist. Ein style-attribut bestimmt das Nachrichtenformat, das in diesem Fall SOAP ist. Das Transportprotokoll dieser SOAP-Bindung ist HTTP und wird durch das Attribut wsoap:protocol festgelegt. Ein Interface kann durch mehrere Bindungen näher beschrieben werden. Damit könnte auch ein anderes Nachrichtenformat als SOAP benutzt werden, was in der Praxis allerdings selten vorkommt. Um ein Message Exchange Pattern (MEP) für die Operation aus dem Interface zu spezifizieren, wird in dem Element operation eine Referenz angegeben und mit dem Attribut wsoap:mep das Pattern bestimmt. Im Falle eines Fehlers bei der Nachrichtenübermittung vom Sender zum Empfänger verweist das fault-element auf das passende fault-element des Interfaces. <binding name=" answersoap" i n t e r f a c e =" tns : answerport " > type=" h t t p : / / www. w3. org /2004/08/ wsdl / soap12 " wsoap : p r o t o c o l = " h t t p : / / www. w3. org /2003/05/ soap / bindings /HTTP/ " <operation r e f = " tns : opanswer" wsoap :mep=" h t t p : / / www. w3. org /2003/05/ soap / mep/ request response " / > < f a u l t r e f =" tns : exception " wsoap : code=" soap : Sender " / > </ binding > Quellcode 3.4: Definition eines binding-elementes Letzendlich muss noch die Adresse, unter der der Dienst zu erreichen ist, angegeben werden. In dem Element service aus dem Quellcode 3.5 wird dafür das Kindelement endpoint definiert. Dieses Element hat einen Namen, beschreibt eine Adresse und legt mit dem Attribut binding die zuvor definierte SOAP-Bindung fest. < s e r v i c e name=" answerservice " > <endpoint name= " answerport " binding =" tns : answersoap" > address l o c a t i o n = " h t t p : / / example. org / Answer/ > </ service > Quellcode 3.5: Definition eines service-elementes Mit dieser WSDL-Beschreibung wird zum einen vertraglich festgehalten wie ein Client mit dem Dienst interagieren kann und welche Daten gesendet bzw. empfangen werden. Der Vertrag bestimmt weiterhin welche Operation ein Client aufrufen und mit Hilfe welcher Nachrichtenformate und - protokolle der Aufruf erfolgen soll. Zum anderen kann die WSDL-Beschreibung an entsprechende Stub-Compiler übergeben werden, um die für eine Anwendung notwendigen Client- und Server-Stubs zu generieren [Mel07].

35 3. WEB SERVICES UDDI In Abschnitt wurde der Verzeichnisdienst (Registry) als eine wichtige Rolle innerhalb einer SOA vorgestellt. Ein Verzeichnisdienst speichert Informationen über Dienste in einem Netzwerk und ermöglicht eine lose Kopplung zwischen den Diensten und den Benutzern bzw. den Applikationen, die die Dienste nutzen. Die wesentlichen Merkmale dabei sind das dynamische Suchen, Finden und schließlich die Nutzung der angebotenen Dienste. Zwei der wichtigsten Verzeichnisdienste für eine SOA mit Web Services sind Web Service Inspection Language (WS-Inspection) und Universal, Description, Discovery and Integration (UDDI). Der Verzeichisdienst WS-Inspection arbeitet mit mehreren dezentralisierten Verzeichnissen und kann im Gegensatz zu UDDI eigenständig nach Services suchen, um diese zu registrieren. Weitere Informationen zu WS-Inspection finden Sie beispielsweise in [Mel07]. Die erste UDDI Spezifikation wurde durch Ariba, IBM, und Microsoft ins Leben gerufen und erschien im September Die folgenden Versionen wurden der unabhängigen Standardisierungsorganisation Advanced Open Standards for the Information Society (OASIS) übergeben. Im Mai 2003 erlangte die UDDI Version 2.0 den Status eines OASIS Standards. Die UDDI Version 3.0 ist seit Februar 2005 OASIS Committee Draft [oas] UDDI Prinzipien Um das in Abschnitt genannte Discovery von Web Services zu ermöglichen, werden die Dienste auf verschiedene Weise beschrieben. Diese Beschreibungen werden veröffentlicht und ein Entwickler erhält auf der Suche nach einem passenden Web Services bestimmte Informationen, die die Web Services beschreiben. Mit diesen Informationen können Anwendungen geschrieben werden, die mit den Services interagieren. Darüber hinaus kann eine Anwendungen eine bestimmte Kategorie von Web Services mit bestimmten Eigenschaften definieren. Anhand dieser Beschränkungen kann die Suche nach Web Services auf eine bestimmte Zielgruppe mit den gesuchten Eigenschaften gerichtet sein und nicht auf einen konkreten Web Service. Diese Auswahl wird als dynamisches Binden bezeichnet [ACKM04]. Die Interaktion mit der UDDI efolgt durch eine Schnittstelle, die UDDI API. Diese Schnittstelle ist durch WSDL und SOAP beschrieben und kann wie jeder andere Web Service angesprochen werden. Demzufolge ist eine Maschine-Maschine-Kommunikation möglich, bei der Anwendungen auf UDDI zugreifen, nach Diensten suchen, diese konsumieren und die gelieferten Daten weiterverarbeiten. Eine andere Möglichkeit mit UDDI zu Interagieren ist der Zugriff über einen Web-Browser. Hierbei handelt es sich um eine Mensch-Maschine-Kommunikation. Wie im Bereich der Telekommunikation, gibt es auch bei UDDI verschiedene Ansätze, wie Informationen, in diesem Fall Informationen über Web Services, kategorisiert werden können. Diese Ansätze werden in der folgenden Auflistung beschrieben [ACKM04]: White Pages: Es werden Unternehmen aufgelistet, die Web Services anbieten und Kontaktinformationen über sich veröffentlichen. Der Web Service Nutzer entscheidet sich für einen Web

36 3. WEB SERVICES 33 Services, indem er nach einem Unternehmen sucht. Yellow Pages: Hierbei werden die Web Services anhand ihrer zugehörigen Branche bzw. Funktionalität kategorisiert. Der Nutzer kennt die Branche für den Dienst, den er sucht und erhält eine Liste mit allen Unternehmen bzw. Anbietern nach Branchen gruppiert. Green Pages: Die Green Pages enthalten die Beschreibungen, die darüber informieren wie ein Web Service aufgerufen werden kann. Dabei handelt es sich meistens um Verweise auf Schnittstellenbeschreibungen, die sich ausserhalb der Registry befinden, z.b. bei dem Serviceanbieter. Weiterhin ist eine textuelle Beschreibung der Dienstsemantik abrufbar. Service Type Registration: Enthält die Beschreibungen für einen Service in maschinenlesbarer Form [Mel07] UDDI Datenstrukturen UDDI Datenstrukturen werden verwendet um interne Einträge darzustellen und Informationen über diese Einträge zwischen Clients und den UDDI-Knoten auszutauschen. UDDI-Knoten sind Bestandteile der UDDI Busines Registry (UBR), die sozusagen aus einzelnen verteilten UDDI-Registries zusammengesetzt ist und von IBM, Microsoft und SAP entwickelt wurde 5. Jeder Knoten verwaltet dabei die gleichen Einträge, wodurch einerseits eine Synchronisierung nötig ist und andererseits eine Lastverteilung innerhalb der UDDI stattfinden kann. [Mel07] Die folgenden Datenstrukturen bilden die Basis des UDDI-Modells [ACKM04]: businessentity: Ist ein übergeordnetes Element, dass das Unternehmen, welches verschiedene Web Services anbietet, beschreibt. Es werden Namen, Adressen, Aufgaben, Ziele, etc. aufgelistet. Über einen businesskey ist das Element eindeutig identifizierbar. Die einzelnen Dienste werden durch verschiedene businessservice-datenstrukturen gespeichert. businessservice: Beschreibt eine Gruppe von Web Services, die durch eine businessentity angeboten werden. Diese Dienste gehören einer Kategorie an und sind durch verschiedene Adressen, Versionen und Technologiedetails gekennzeichnet. Ein businessservice gehört zu genau einem businessentity und kann mehrere Kinder des Elementes bindingtemplate und Referenzen auf tmodels enthalten. bindingtemplate: Dieses Element beschreibt die technischen Details, die es ermöglichen einen Dienst auzurufen. Eine wesentliche Angabe ist die Adresse des Dienstes, typischerweise dessen URI. Es kann weiterhin Referenzen auf verschiedene tmodels enthalten. tmodel: Der Name dieses Elementes steht für technical model und es handelt sich dabei um einen generischen Container, der ein bestimmtes Konstrukt verkörpert. Beispielsweise könnte eine bstimmte Spezifikationen, eine WSDL Schnittstelle, eine Klassifikation, ein Interaktionsprotokoll oder die Semantik einer Operation damit dargestellt werden. Ein solches Modell kann eine Datentyp-Beschreibung für gleichartige Dienste verkörpern und unterstützt 5 Die Arbeiten am UBR wurden im Januar 2006 eingestellt. Weiter Informationen hierzu finden Sie unter

37 3. WEB SERVICES 34 damit die Wiederverwendung von Diensten. Weiterhin können durch das tmodel Dienste auf technischer Ebene verglichen und dynamisch zur Laufzeit ausgewählt werden. Das Modell ist nicht in die Relation Elternteil-Kind einzuordnen. Es stellt eine Referenz dar, mit der ein Entity seine Eigenschaften beschreiben kann. Für die Veröffentlichung von Services in einer UDDI muss zuerst ein Satz von tmodels erstellt werden, die die charakteristischen Eigenschaften der Services beschreiben. Danach wird in dem businessentity darüber informiert, um was für einen Serviceanbieter es sich handelt. Die Beschreibung der einzelnen Services kann anschliessend durch die businessservices erfolgen. Für diese können verschiedene bindingtemplates erstellt werden, die die unterschiedlichen Implementationen und Endpunkte veröffentlichen und damit die technische Beschreibung liefern. Die Einzelheiten der technischen Ebene werden nun in den bindingtemplates durch Referenzen auf verschiedene tmodels dargestellt. 3.3 RESTful Web Services und State-of-the-Art In diesem Abschnitt wird eine weitere Möglichkeit für die Realisierung von Web Services vorgestellt. RESTful Web Services basieren auf dem Architekturstil REST und zeichnen sich durch eine hohe Skalierbarkeit und Interoperabilität aus. Im Gegensatz zu SOAP Web Services erfolgt die Schnittstellenbeschreibung von RESTful Web Services meistens in textueller Form auf den Webseiten der Serviceanbieter. Dort werden die URLs sowie die Ein- und Ausgabedaten beschrieben. Eine große Sammlung an RESTful Serviceanbieter ist auf den Internetseiten von ProgrammableWeb 6 zu finden. Da die textuelle Beschreibung der Services für die maschinelle Verarbeitung nicht ausreichend ist, werden in den folgenden Abschnitten Ansätze vorgestellt, die versuchen dieses Problem zu lösen Beschreibungssprachen Die Kommunikation mit RESTful Web Service gestaltet sich auf den ersten Blick recht einfach. Der Servicekonsument muss dazu auf die Internetseite des Serviceanbieters gehen und die Beschreibung der API ausfindig machen. Meistens findet er hier eine textuelle Beschreibung der API, welche Informationen über die URI, Aufruf- und Antwortparameter, Parameterwerte und -beschreibungen in textueller Form darstellt. Ein konkreter API Aufruf gestaltet sich durch die Konkatenation dieser Informationen und kann im einfachsten Fall mit Hilfe eines beliebigen Web Browsers aufgerufen werden. Um die gelieferten Serviceinformation weiterzuverarbieten, empfiehlt es sich allerdings eine Programmierumgebung zu verwenden, die die Netzwerkkommunikation mittels HTTP unterstütz. Die Programmiersprache Java bietet hiefür das Package java.net an. Der Programmierer kann damit beispielsweise eine Ressource mit der HTTP Methode GET aufrufen und die strukturierte Antwort gezielt mit einen geeigneten Parser auswerten lassen. Dieses Szenario ist für einen einzelnen leichtgewichtigen Service problemlos durchführbar. Sobald aber mehrere Services angesprochen werden sollen, erhöht sich der Programmieraufwand, weil die Programmkonstrukte in ähnlicherweise auf jeden Service angewendet werden müssen. Eine Lösung dieses Problems bietet eine Schnittstellen- 6

38 3. WEB SERVICES 35 beschreibung in Form einer einheitlichen Beschreibungssprache. Leider gibt es auf diesem Gebiet keinen Standard, der sich bisher durchsetzen konnte. Deswegen werden hier zunächst einmal die wichtigsten Ansätze vorgestellt. Die naheliegenste Lösung zur Beschreibung der Dienstschnittstelle bietet HTML mit den Elementen link und form. In HTML5 7 unterstützt das Element form mit dem Attribut method auch die HTTP-Methoden PUT und DELETE, wodurch eine Verfügbarkeit aller wichtigen HTTP-Methoden gewährleistet ist. Die Nachteile sind die geringe Flexibilität im Umgang mit Datentypen der Anfrage und die fehlenden Optionen zur strukturellen Beschreibung der konkreten Inhalte der Antwortnachrichten [LG10]. Es existieren einige Lösungen, die bestimmte Teilaspekte der Beschreibung abdecken und damit nicht vollständig sind. Dazu zählen die Web Resource Description Language (WRDL, Word-dul ) [Pre02], der Simple Message Exchange Descriptor (SMEX-D) [Bra05] und die Web Description Language (WDL) [Orc]. Diese Lösungen sind schon etwas älter und wurden seit längerer Zeit nicht mehr aktualisiert. Sie zeichnen sich dadurch aus, dass alle jeweils ein XML Dokument für die Servicebeschreibung verwenden. Mit der WRDL können Ressourcen beschrieben werden (Ein- und Ausgabeparameter, Header-Informationen, MIME-Typen, etc.). Die WRDL Engine erstellt Objekte von den Ressourcen und verlinkt diese miteinander. Das macht diesen Ansatz weniger URI orientiert und verdeutlicht das Prinzip der verlinkten Ressourcen. Der Ansatz SMEX-D ermöglicht die Beschreibung von REST und SOAP Services. Hierbei werden REST Anfragen mittels Name-Wert-Paaren ausgedrückt. Leider wurde nicht beschrieben wie die HTTP Methoden, Header- und Antwort Parameter spezifiziert werden können. Der Ansatz Web Description Language (WDL) wurde von Dave Orchard entwickelt und ermöglicht die Auflistung von Ressourcen, wobei jeder Ressource eine location zugeordnet wird. Jede Ressource kann operation Elemente enthalten, die als Container für input, ouput und fault Elemente dienen. Weiterhin werden HTTP-Header, Statuscodes und spezifische Konfigurationen, wie Authentifizierung und Kodierung der Ein- und Ausgabedaten, unterstützt. Eine XML-basierte Sprache für eine Schnittstellenbeschreibung, die sowohl eine Dienstbeschreibung als auch eine Dienstkomposition und -weiterentwicklung anbietet, ist die Resource oriented Interface Description and Declaration Language (RIDDL) [MBS10]. Die Funktionalität der Dienstbeschreibung lässt sich aus einzelnen Bausteinen zusammensetzen. Während der Evolution der Dienstbeschreibung kann somit jeder Entwicklungsstufe ein solcher Baustein zugeordnet werden. Die aktuelle Dienstbeschreibung entsteht durch das Zusammenfügen aus den vorhergehenden Versionen. Eine Nachricht wird in einem Element message beschrieben und kann von Ressourcenelementen über einen Namen referenziert werden. Die Struktur der Parameter kann rekursiv dargestellt werden und ist an die RELAX NG Spezifikation 8 angelehnt. Das Verarbeiten von HTTP-Headern der Ein- und Ausgabenachrichten wird unterstützt. In Kapitel wurde erwähnt, dass mit WSDL 2.0 auch Schnittstellen für RESTful Web Service beschrieben werden können. Dies geschieht dadurch, dass der Typ des binding-elementes auf den Wert gesetzt wird und somit das Protokoll für die Kommunikation nicht SOAP, sondern HTTP ist. Für die verschiedenen Operationen einer Bindung können 7 HTML5 befindet sich seit dem 3. Februar 2011 im Status Editors Draft des W3C, 8

39 3. WEB SERVICES 36 nun die HTTP-Methoden GET, PUT, POST und Delete angegeben werden. In der Operation des Interfaces kann beschrieben werden, ob eine Operation idempotent und damit beliebig wiederholbar ist [Man08]. Um die Parameter einer Anfrage mittles GET zu setzen, muss das style-attribute der Interface-Operation den Wert beinhalten (WSDL 2.0 Part 2 Abschnitt 4.2), der auf den IRI-Style 9 verweist. Die Parameterwerte müssen allerdings zuvor in XML-Schema definiert werden und können dann von der Operation durch die Angabe des zutreffenden XML-Schema-Elementes referenziert werden. Die Behandlung von HTTP-Header und die HTTP-Authentifizierung wird durch WSDL 2.0 ermöglicht. Weitere Informationen über die HTTP- Binding-Erweiterungen sind unter [res07] zu finden Web Application Description Language Die Web Application Description Language (WADL) [resf] ist ein XML-basiertes Vokabular, mit dem im Wesentlichen die möglichen HTTP Requests, die an einen Web Service geschickt werden, beschrieben werden können. Dabei ist es möglich die URIs eines Web Service, die übermittelten Daten an die URIs und die das Format der gelieferten Daten zu spezifiziert. Die Sprache wurde von dem ehemaligen Sun Microsystems Mitarbeiter Dr. Marc J. Hadley entwickelt [Ste07]. Hadley forschte auf dem Gebiet der Java und der Web Service Architektur und ist beteiligt an den Spezifikationen JSR und JSR Die Web Application Description Language befindet sich seit dem 31. August 2009 in dem Member Submission Status des W3C. WADL unterstützt generative URIs und alle wichtigen HTTP-Methoden (GET, POST, PUT, HEAD, DELETE). Es können Header-Parameter für HTTP-Requests und HTTP-Responses deklariert werden. Der Entwickler kann das Format einer Repräsentation durch XML Schema bzw. RelaxNG näher bestimmen. Dadurch können beispielsweise auch aus XML-Antwortdokumenten gezielt Informationen extrahiert werden. Eine einfachere Definition für strukturierte Antworten besteht darin, einem response-element die entsprechenden param-elemente als Kinder zu übergeben. Der Quellcode 3.6 zeigt einen Ausschnitt einer WADL Datei zum Aufrufen einer bestimmten Ressource des Yahoo!Answers 12 Web Service. Das Element application stellt das Wurzelelement dar und beinhaltet alle weiteren Elemente sowie die Namespace-Deklarationen. Die Abbildung der Ressourcen erfolgt durch eine hierarchische Strukturierung, bei der die Ressourcen durch ein resources- Element gruppiert werden, das mit dem Attribut base die Basis-URI für die Ressourcen deklariert. Eine Ressource enthält das Attribut path, das den Pfad der Ressource relativ zur Basis-URI beschreibt. Jede Ressource besteht aus Methoden, die durch request und response-elemente näher bestimmt werden. In dem Quellcode 3.6 werden für das Request zwei param-elemente angegeben. Dabei wird vorgeschrieben, dass jedes param-element ein Namen haben muss. Falls der Typ nicht gesetzt ist, wird für den Parameter der Default-Wert xsd:string verwendet. Das style- Attribut in diesem Beispiel ist query und drückt aus, dass es sich bei dem Parameter um einen Request-Parameter handelt. An dieser Stelle könnte aber auch ein Header-Parameter bestimmt wer- 9 Internationalized Resource Identifiers (IRIs)

40 3. WEB SERVICES 37 den. Dann müsste das Attribut type den Wert header annehmen. Ob ein bestimmter Parameter bei einem Request angegeben werden muss, wird schließlich mit dem Attribut required beschrieben. Die Anwort kann entsprechend des gesendeten HTTP-Statuscodes deklariert werden. In diesem Beispiel ist der Status der Antwort 200, was bedeutet, dass die Anfrage erfolgreich bearbeitet wurde und das Ergebnis in der Antwort übertragen wird. Um dieses Ergebnis zu spezifizieren wird ein representation-element verwendet, das u.a. den Typ des Ergebnisses festlegt. Mit Hilfe des Attributes element kann auf ein Element in einer XML Schema Datei referenziert werden, um damit die Struktur der Repräsentation zu bestimmen. <?xml version =" 1.0 "?> < a p p l i c a t i o n xmlns : x s i = " h t t p : / / www. w3. org /2001/XMLSchema instance " xmlns : xsd= " h t t p : / / www. w3. org /2001/XMLSchema" xmlns=" h t t p : / / research. sun. com/ wadl /2006/10 " xmlns : qs= " urn : yahoo : answers " > <resources base= " h t t p : / / answers. yahooapis. com / AnswersService / V1 / " > <resource path= " questionsearch " > <method name= "GET" > <request > <param name=" query " type=" xsd : s t r i n g " s t y l e =" query " required = " t r u e " / > <param name=" search_in " type= " xsd : s t r i n g " s t y l e = " query " / >.... </ request > <response s t a t u s = " 200 " > < r e p r e s e n t a t i o n mediatype=" a p p l i c a t i o n / xml " element=" qs : ResultSet " / > </ response> </method> </ resource >.... </ resources > </ a p p l i c a t i o n > Quellcode 3.6: Definition eines binding-elementes Die Verwendung der Beschreibungssprachen WADL erfolgt in verschiedenen Programmierumgebungen. Die Java API for RESTful Web Services (JAX-RS bzw. JSR133) ist eine API für die Programmiersprache Java, die eine einfache und intuitive Erstellung von RESTful Web Services anbietet. JAX-RS basiert auf Annotationen, durch die der Programmieraufwand verringert wird. Durch die Annotationen werden Client-Requests auf Klassenmethoden abgebildet und die Request-Daten auf die Parameter der Methoden gemappt. Ausführliche Anwendungsbeispiele sind in [Bur09] zu finden. Für die JAX-RS-Spezifikation wurden unterschiedliche Referenzimplementierungen entwickelt, die u.a. die automatische Generierung von WADL-Dokumenten zur Laufzeit anbieten. Zu diesen Implementierungen zählen Jersey [resd] und Apache CXF [resb]. Eine weitere Möglichkeit zur Generierung von WADL-Dokumenten ist durch eine von Thomas Steiner entwickelte Applikation gegeben ([Ste07], [Ste]). Die Applikation besteht aus den Modulen REST Describe und REST Compile. Mit REST Describe kann der Benutzer über eine graphische Oberfläche eine RESTful Web Service Schnittstelle beschreiben. Durch Textfelder gibt der Benutzer die URIs an und spezifiziert die Parameter. Daraufhin kann das WADL-Dokument angezeigt und gespeichert werden. REST Compile ermöglicht im Anschluß die Codegenerierung für verschiedene Sprachen (PHP5, Ruby, Python, Java). Ein weiteres

41 3. WEB SERVICES 38 Werkzeug zur Codegenerierung auf der Basis von Java ist wadl2java [WAD]. Dieser Codegenerator wird in einem Package angeboten und beinhaltet ein Kommandozeilenprogramm, ein Ant-Plugin 13 sowie ein Maven-Plugin 14 zur Erzeugung von clientseitigen Stubs durch Einlesen eines WADL- Dokumentes. Mithilfe des OpenSource Werkzeuges soapui [ab] kann über eine graphische Benutzeroberfläche ein WADL-Dokument eingelesen und der Quelltext generiert werden, vorausgesetzt wadl2java wurde installiert. Eine einfache Programmierbibliothek zum Einlesen und Verarbeiten von WADL-Dokumenten wurde von Leonard Richardson in der Programmiersprache Ruby entwickelt [Ric]. Da für die Schnittstellenbeschreibung auch die menschenlesbare Dokumentation eine wichtige Rolle spielt, wäre es vorteilhaft aus einem WADL-Dokument ein HTML-Dokument zu generieren, welches die Ressourcen (URIs, Parameter und -Parameterwerte) aussagekräftig beschreibt. Die WADL-Spezifikation ermöglicht dieses Vorgehen durch das Element doc, das Elementen zugeordnet werden kann und für die textuelle Beschreibungen von Elementen dient. Unter [rese] wird ein XSL-Dokument 15 für eine Transformation von WADL- in HTML-Dokumente für die Dienstdokumentation bereitgestellt HTML for RESTful Services HTML for RESTful Services (hrests) [KGV08] ist ein Mikroformat 16 für die maschinenverarbeitbare Beschreibungen von Web APIs. Für die Auszeichnung relevanter Dokumenteninhalte werden bestehende XHTML Attribute wie class und rel verwendet. Die Werte der Attribute entsprechen einem Objektmodell, das den Service in seine Methoden, Adressen, Ein- und Ausgaben aufteilt. Beispielsweise enthält ein Element mit dem class-attribut service ein Element mit dem class- Attribut label, das den Namen des Services festlegt und ein weiteres Element mit dem class-attribut operation, das die ausgezeichneten Methoden enthält. Durch eine XSL-Transformation wird bei diesem Ansatz das XHTML-Dokument in eine RDF-Form 17 überführt. Der Aspekt der Verlinkung von Ressourcen ist durch die Abbildung der Links auf die Operationen gegeben. Somit ist eine Beschreibung der Relation von Ressourcen möglich. Eine Beschreibung der Ein- und Ausgabetypen ist an dieser Stelle allerdings noch nicht vorgesehen. Dazu muss hrests um semantiche Mechanismen erweitert werden, die in Kapitel vorgestellt werden. Die Auszeichnung der Servicedokumente führt aufgrund der verteilten Dokumentationsseiten dazu, dass mehrere Dokumente bearbeitet werden müssen, wodurch die Beschreibung erschwert wird. Ein Nachteil ist auch die Vermischung von Funktionalität und Präsentation. Dadurch verringert sich die Übersichlichkeit und die klare Strukturierung der Servicebeschreibung. Ein browserbasiertes Werkzeug für die Auszeichnung von HTML mit hrests-tags ist SWEET. SWEET ist eine JavaScript Application, die eine HTML-Dokumentation eines Service einlesen kann und durch Selektion der relevanten HTML Teile sowie der Verknüpfung mit dem hrests Objekt- 13 Ant ist ein in Java programmiertes Werkzeug der Apache Software Foundation zur automatisierten Erstellung von ausführbaren Computerprogrammen aus Quelltexten. 14 Maven ist ein auf Java basierendes Build-Management-Tool der Apache Software Foundation. 15 Extensible Stylesheet Language (XSL) 16 Unter Mikroformaten versteht man Markup-Formate zur semantischen Annotation von HTML/XHTML. Diese dienen Programmen zur Extraktion von Informationen. Weitere Informationen finden Sie unter 17 Resource Description Framework (RDF)

42 3. WEB SERVICES 39 modell, ein von hrests annotiertes HTML-Dokument generiert Semantische Annotationen Die globale Suche nach adäquaten Web Services im WWW und deren Einbindung in automatisierte Prozesse übersteigt die Möglichkeiten eines Kategoriensystems einer Registry. Deshalb ist es nötig semantische Erweiterungen vorzunehmen, die das Auffinden und Wiederverwenden von Diensten ermöglichen. An dieser Stelle werden kurz Ansätze vorgestellt, die sich mit der semantischen Beschreibung von RESTful Web Services auseinandersetzen. Wie bereits im Abschnitt zuvor erwähnt wurde, muss hrests um semantische Annotationen erweitert werden, damit eine Automatisierung des Discovery und der Komposition erfolgen kann. Für diese Erweiterung kann MicroWSMO [MKP09], das basierend auf SAWSDL 18 entwickelt wurde, verwendet werden. SAWSDL ist wiederum die Grundlage für die semantische Annotation von Dienstbeschreibungen auf Basis von WSDL. Dabei können drei XML-Attribute, die äquivalent zu den Eigenschaften von RDF sind, definiert werden. Auf die gleiche Weise kommen auch bei MicroWSMO drei Elemente(model, lifting, lowering) zum tragen, die hierbei das semantische Konzept und die Transformation von XML- nach RDF-Beschreibungen bestimmen. Für die Beschreibung des Inhaltes der Annotationen wird schließlich, genauso wie bei SAWSDL, die WSMO-Lite Ontologie verwendet. WSMO-Lite spezifiziert vier Aspekte für semantische Services: das Informationsmodell, die Funktionssemantik, die Verhaltenssemantik und die nichtfunktionalen Eigenschaften. Aus der Tatsache, dass es möglich ist, RESTful Web Services als auch WSDL Web Services mittels WSMO-Lite semantisch zu beschreiben, entsteht die Schlussfolgerung, dass beide Web-Service-Ansätze für das Discovery und die Komposition herangezogen werden können. Dafür bedarf es aber weiterer Integrationstechnologien, auf die an dieser Stelle nicht weiter eingegangen wird. Für das werkzeuggestützte Erstellen von semantischen Annotationen mit MicroWSMO bietet auch an dieser Stelle das Werkzeug SWEET seine Dienste an. Mit SWEET können nun auf der Basis des Suchdienstes Watson 19, der eine Schlagwortsuche nach Ontologien anbietet, die Diensteigenschaften, wie bspw. Nachrichtenparameter, durch entsprechende Ontologien ergänzt werden. Das resultierende HTML-Dokument ist schließlich mittels MicroWSMO annotiert und kann durch eine XSL- Transformation in ein aussagekräfiges RDF-Dokument konvertiert und gespeichert werden. Eine weitere Möglichkeit, HTML-Dokumenten mit semantischen Informationen anzureichern, bietet der SA-REST [SGL07] Ansatz. Dieser Ansatz ist auch für eine Erweiterung von hrests geeignet [LG10]. Ebenso wie bei MicroWSMO erfolgt auch hier die Annotations durch Modellreferenzen auf Grundlage von SAWSDL. SA-REST schreibt nicht vor welche Art von Ontologie bzw. konzeptuelles Modell verwendet wird, aber es erlaubt die Nutzung von RDF, um Ontologien zu repräsentieren. Dabei verwendet dieser Ansatz RDFa und Gleaning Resource Descriptions from Dialects of Languages (GRDDL) für die Annotation. Es ermöglicht vor allem MashUp-Entwicklern das automatisierte Durchsuchen von Web-API-Beschreibungen nach bestimmten Facetten, wie Datenformate und Programmiersprache

43 3. WEB SERVICES 40 Semantic Bridge for Web Services (SBWS) [BB08] ist ein Java Werkzeug zur Integration bestehender Web Services in das semantische Web. Mit SBWS kann WADL um semantische Beschreibungen für Ein- und Ausgabedaten erweitert werden. Dabei kommen drei Annotationen zum Einsatz. Die modelreference Annotation beschreibt die OWL Klasse eines Parameters. Das für einen Parameter verwendete Datenobjekt des verwendeten Modells wird durch valueproperty definiert. Die schema- Mapping Annotation gibt für einen Ausgabeparameter an, wie die Konvertierung von XML nach RDF zu erfolgen hat. Eine Anfrage wird durch SPARQL 20 initialisiert und an SBWS übergeben. Dann entscheidet SBWS auf der Grundlage der Annotationen welche Operationen bzw. Kombination von Operationen für die Erfüllung der Anfrage zu verarbeiten sind. SBWS kann also als ein SPARQL-Endpoint betrachtet werden Dienstsuche und -komposition Bevor ein Dienst genutzt werden kann, muss er zuerst einmal gefunden werden. Für SOAP-basierte Dienste bietet sich dafür die in Kapitel vorgestellte Technologie UDDI an. UDDI ist eine Registry, die Informationen über die eingetragenen Dienstanbieter, deren verfügbare Dienste und die technischen Informationen über die Dienste bereitstellt. Für RESTful Web Services gibt es in diesem Sinne keine Registry. Man kann einerseits Webseiten wie ProgrammableWeb nutzen, um für die eigenen Zwecke die passende API zu finden oder aber man durchforstet die Webseiten von populären Dienstanbietern wie Google oder Yahoo!. ProgrammableWeb ermöglicht die Suche durch Angabe bestimmter Eigenschaften der Dienste. Diese Angaben können Schlagwörter, Kategorien, Anbieter, Protokolle und Datentypen enthalten. Als nächstes werden Arbeiten vorgestellt, die sich mit der Komposition von RESTful Web Services beschäftigen. Dies geschieht aus dem Grund, dass die Komposition auch die Beschreibung der Dienste erforderlich macht. Die verwendeten Beschreibungsverfahren können dann für die Konzeption der in dieser Arbeit zu entwickelnden Softwarekomponente herangezogen werden. BPEL for REST wurde in dem Artikel RESTful Web service composition with BPEL for REST [Pau09b] vorgestellt. Ziel dieser Arbeit ist es verschiedene RESTful Web Services für Servicekompositionen zu verwenden. Der Autor möchte anhand der Kompositionssprache BPEL zeigen, dass prozeß-orientierte Kompositionssprachen neben den traditionellen WSDL-basierten Services auch RESTful Web Service in die Komposition einbinden können. Da BPEL 2.0 nur WSDL 1.1 unterstützt und damit die Beschreibung von RESTful Services sehr begrenzt ist, musste eine andere Lösung gefunden werden. Dabei wird für die Beschreibung der Dienste keine spezifische Sprache verwendet, stattdessen wird BPEL mit Erweiterungen versehen, die ein Mapping auf Dienstressourcen ermöglichen. Diese Erweiterungen erlauben es URI-Adressen zur Laufzeit einzubinden, Payloads für die Requests und Responses zu definieren, die HTTP-Header zu verarbeiten, auf HTTP-Statuscodes zu reagieren und Antworten für eine spätere Verarbeitung zwischenzuspeichern [Pau09b]. ActiveVOS ist ein graphisches Werkzeug für das Management von Geschäftsprozessen. Die Ausführung von Prozessen basiert auf BPEL 2.0 und unterstützt die Interaktion mit RESTful Services. Ein Prozess kann REST-Requests senden und empfangen. Dazu muss allerdings eine spezielle WSDL- 20 SPARQL Protocol and RDF Query Language (SPARQL) ist eine Anfragesprache für RDF.

44 3. WEB SERVICES 41 Datei verwendet werden, die die Operationen und Nachrichten für das Senden und Empfangen von REST-Requests definiert. Falls ein Prozess ein REST-Request empfängt, konvertiert der ActiveVOS Server diesen in eine WSDL-Nachricht. Möchte ein Prozess einem RESTful Service eine Nachricht senden, wird zuvor eine WSDL-Nachricht in ein REST-Request konvertiert. Neben der Definition des Inhalts des Payloads wird auch die Verarbeitung von HTTP-Header und HTTP-Statuscodes unterstützt [resa]. JOpera 21 ist eine graphisches Werkzeug für die Komposition von Diensten unter Eclipse. Neben der Möglichkeit SOAP- und RESTful Services aufzurufen, können auch Interaktionen mit Human Activities und Grid Services stattfinden. Für die Kommunikation mit RESTful Services können Adapter eingesetzt werden. Weiterhin gibt es Adapter, die basierend auf XSLT, XPath und Java Snippets die Transformation von Daten ermöglichen. Der Aufruf von RESTful Services wird durch vier Parameter modelliert: Method, URI, Body und optionale HTTP-Header [Pau09a]. Apache ODE (Orchestration Director Engine) ist ein Werkzeug, dass Geschäftsprozesse auf der Grundlage von WS-BPEL 2.0 ausführt. Für die Kommunikation mit RESTful Web Services wurde WSDL 1.1 um weitere Funktionalitäten durch Einführung eines eigenen Namespaces ergänzt. Dadurch ist es möglich eine HTTP-Methode je Operation zu definieren (anstatt zuvor einer je Bindung), URI Templates für Operationen zu erstellen, HTTP-Header zu verarbeiten und eine Fehlerbehandlung entsprechend der HTTP-Statuscodes zu erlauben [resc]. Weitere graphische Werkzeuge für die manuelle Komposition von RESTful Services, auf die an dieser Stelle nicht näher eingegangen wird, sind Yahoo!Pipes 22 und Intel Mash Maker 23. In [BB08] wird das weiter oben vorgestellte Werzeug, SBWS, mit dem Semantic Query Decomposer (SQD) kombiniert, um Anfragen für eine verteilte Architektur mit unterschiedlichen Datenquellen zu ermöglichen. SBWS wird hierbei als Wrapper für individuelle RESTful Web Services verwendet, der stellvertretend für den Dienst als semantische RDF Datenquelle genutzt wird. Der Wrapper enthält Annotationen für die Parameter eines Services, die damit auf Elemente einer zugrundeliegenden Ontologie gemappt werden können. SQD stellt einen SPARQL Anfrageknoten dar, der die verschiedenen Ontologien zu einer Domänenontologie kapselt. Eine komplexe Anfrage in der Sprache der Domänenontologie wird nun von einem Sender an SQD übermittelt, anhand der Ontologien in kleinere Einheiten unterteilt und an die verschiedenen Datenquellen weitergeleitet. Die einzelnen Antworten werden anschießend von SQD zusammengeführt und in der Sprache der Domänenontologie an den Sender übertragen. Für den Sender ist SQD somit ein SPARQL-Endpoint. Ein auf Semantics of Business Vocabulary and Business Rules (SBVR) [res08] basierender Ansatz wird in [MK09] vorgestellt. SBVR unterstützt die Erstellung von semantischen Metamodellen von Geschäftsinventaren und -regeln. Bei diesem Ansatz werden die relevante Ressourcen von verschiedenen Providern in einem Repository gespeichert. Jede Ressource wird durch ein Vokabular und verschiedenen Regeln beschrieben. Weiterhin müssen Regeln für die Komposition von Ressourcen festgelegt werden. Ein Anfragemechanismus entkoppelt die Serviceanfragen von dem Benutzer, wodurch der Benutzer keine weiteren Informationen bei einem Request anzugeben braucht

45 3. WEB SERVICES Zusammenfassung und Diskussion Dieser Abschnitt bietet eine Zusammenfassung der wichtigsten Informationen des Kapitels 3. Dabei werden die vorgestellten Technologien verglichen, um darauf aufbauend deren Eignung für die Umsetzung der Softwarekomponente RESTator zu diskutieren. In diesem Kapitel wurde Anfangs eine Begriffsklärung darüber gegeben, was ein Web Service ist. Weiterhin wurde beschrieben wie es zu dieser Ausprägung einer softwarebasierten Anwendung überhaupt gekommen ist und warum eine starke Verbreitung von RESTful Web Services zu verzeichnen ist. Das Unterkapitel 3.2 stellte die Technologien in Bezug auf die SOAP Web Services vor. Hierbei wurde gezeigt wie mittels WSDL ein Service beschrieben werden kann. Dazu musste das Interface des Services und dessen Operationen definiert werden, wodurch der prozessorientierte Charakter dieser Sprache ersichtlich wurde. Bei dem Austausch von Nachrichten wird vorrangig das Protokoll SOAP verwendet, es besteht allerdings keine Beschränkung darauf. Die Veröffentlichung von und das Suchen nach Diensten ist durch UDDI möglich, dessen Prinzipien und Datenstrukturen vorgestellt wurden. Darauffolgend behandelte das Unterkapitel 3.3 die wichtigsten Technologien und Verfahren im Zusammenhang mit RESTful Web Services. In Abschnitt erfolgte die Darstellung der Ansätze, die eine Beschreibung von RESTful Web Services ermöglichen. Der überwiegende Teil dieser Ansätze orientiert sich an XML-basierten Beschreibungssprachen. In dem Ansatz hrests wird die Beschreibung direkt in der HTML-Dokumentation des Services vorgenommen. Nachteilig dabei ist u.a. die unzureichende Beschreibung der Datentypen. Die übermittelten Daten können nämlich nicht mit hrests beschrieben werden. Dafür bedarf es zusätzlicher Hilfsmittel. Verglichen mit WADL ist das ein Nachteil, weil es mit WADL möglich ist auf Schemas, wie XML- und RelaxNG-Schema, zu referenzieren. Demgegenüber sind die Beschreibungssprachen WADL und WSDL sehr ähnlich. Ein wesentlicher Unterschied ist, dass WSDL 2.0 einen starken Interface-orientierten Charakter besitzt und WADL sich durch einen ressourcen-orientierten Charakter auszeichnet. Ein weiterer Unterschied besteht darin, dass WADL keine Optionen für den Umgang mit Sicherheit (HTTP-Authentifizierung) anbietet. Die Autoren des Artikels [TMK + 08] beschreiben den Unterschied beider Sprachen folgendermaßen: Sie schreiben, dass WADL zwar einfach ist, aber etwas eingeschränkt und WSDL 2.0 eine hohe Komplexität besitzt, aber über kein wahres ressourcen-orientiertes Modell verfügt. In Bezug auf das Anwendungsfeld ist noch zu erwähnen, dass die Eignung von WSDL 2.0 für RESTful Web Service in der Literatur umstritten ist. Dabei wird die geringe Verbreitung von WSDL 2.0 für RESTful Web Service auf das fehlende ressourcen-orientierte Modell und die hohe Komplexität zurückgeführt ([MBS10], [MKP09], [MK09]). Thomas Steiner hat während der Verfassung seines Artikels [Ste07] die Nutzung von Beschreibungssprachen für RESTful Web Services als rückläufig eingestuft. Dabei bezieht er sich auf die Benutzeraktivitäten innerhalb von Mailing Listen, die sich mit Beschreibungssprachen für RESTful Web Services auseinandersetzen. Demnach war in den Jahren 2005 und 2006 ein Rückgang an Postings zu dieser Thematik um mehr als die Hälfte zu verzeichnen. Als mögliche Gründe für den Rückgang des Interesses gibt er an, dass einerseits REST zu einfach ist, um es in einer Sprache auszudrücken und

46 3. WEB SERVICES 43 andererseits RESTful Web Services häufig gegen die REST Prinzipien verstoßen. Aktuelle Diskussion zu dieser Thematik behandeln die Frage ob REST überhaupt eine Beschreibungssprache braucht. Auch hier gehen die Meinungen auseinander. Festzustellen ist, dass die RESTful Web Service, die durch ProgrammableWeb gefunden werden können, hauptsächlich durch eine textuelle Beschreibung auf deren Anbieterseiten gekennzeichnet sind. Das ist ein Indiz dafür, dass es eine mangelnde Bereitschaft für die Verwendung von maschinenverarbeitbaren Sprachen im Kontext der öffentlichen REST APIs gibt. Für die zu entwickelnde Softwarekomponte RESTator spielt es oberflächlich betrachtet keine Rolle ob eine Beschreibungssprache für die zu aggregierenden Dienste genutzt wird. Und zwar aus dem einfachen Grund, weil von öffentlichen REST API Anbietern nur textuelle Beschreibungen angeboten werden. Der API Nutzer muss die Beschreibung somit in Eigenregie übernehmen. Somit könnte für RESTator eine individuelle Datenstruktur entwickelt werden, die der Nutzer dann mit relevanten Informationen für die Kommunikation mit den Diensten anreichert. Dieser Ansatz wäre allerdings nicht sehr weitsichtig, weil er einen Austausch der Dienstbeschreibungen verhindert und die bestehenden Technologien für die Erzeugung bzw. Verarbeitung von Beschreibungsdokumenten ignoriert. Aus diesem Grund wird die Verarbeitung von Dienstmerkmalen der RESTator-Komponente auf der Basis einer Dienstbeschreibung erfolgen. Die Dienstbeschreibung wird mit WADL umgesetzt, weil WADL eine höhere Akzeptanz unter den API Entwicklern hat, ressourcenorientiert ist und weniger Komplexität als WSDL aufweist. In Abschnitt wurden Verfahren und Werkzeuge vorgestellt mit denen Beschreibungssprachen um semantische Informationen erweitert werden können. MicroWSMO und SA-REST sind ähnliche Ansätze, die hrests um semantische Annotationen erweitern und für die Beschreibung RDF einsetzen. SBWS ermöglicht das Aufsuchen von annotierten Services durch die Sprache SPARQL. In Abschnitt wurde erwähnt, dass ProgrammableWeb bei der Suche nach öffentlichen RESTful Web Service eine wichtige Rolle spielt. Weiterhin wurden Ansätze und Werkzeuge für die Komposition von Diensten kurz beschrieben. Da keine funktionalen Beschreibungen öffentlicher RESTful Web APIs von den Anbieter zur Verfügung gestellt werden, ist zu vermuten, dass ein ähnliches Verhalten auch bei semantische Beschreibungen zu beobachten ist. ProgrammableWeb bietet keine Optionen an nach semantischen Web Services zu suchen und während der Recherche zu der vorliegenden Arbeit wurden mit Programmable- Web auch keine gefunden. Somit ist der Einsatz semantischer Sprachen für das Entwicklerwerkzeug RESTator nicht vorgesehen. Die Aggregation von Services in der Softwarekomponente RESTator soll durch eine Registry ermöglicht werden, die die Services in ein Kategoriensystem, ähnlich dem von UDDI, einordnet. Der Enwickler, aus dem in der Einleitung beschriebenen Anwendungsszenarios, hat somit die Aufgabe die Services zu annotieren, damit diese kategorisiert werden können.

47 4. KONZEPTION 44 4 Konzeption Die in diesem Kapitel vorgestellte Konzeption geht auf die wesentlichen Bestandteile der zu entwickelnden Softwarekomponente RESTator ein. Um die Entscheidungen für die vorliegende Konzeption der Systemarchitektur zu verdeutlichen, werden zunächst einmal die Anforderungen beschrieben, die die Softwarekomponente zu erfüllen hat. Anschließend wird die Systemarchitektur der Softwarekomponente im Überblick kurz vorgestellt. Im weiteren Verlauf des Kapitels wird auf die wichtigsten Anforderungen eingegangen, die sich bei der Analyse der Aufgabenstellungen ergeben haben und die Konzeption von RESTator wesentlich beeinflussten, sowie auf das notwendige Verhalten der ermittelten Einzelkomponenten. 4.1 Anforderungen In diesem Unterkapitel werden die funktionalen Anforderungen definiert, die zu der Konzeption von RESTator beigetragen haben. Diese bilden die wesentliche Grundlage für die getroffenen Designentscheidungen. Weiterhin wird auf die nicht-funktionale Anforderungen eingegangen, die für die Benutzung und die Weiterentwicklung von RESTator ausschlaggebend sind Funktionale Anforderungen Folgende funktionale Anforderungen werden an die Softwarekomponente RESTator gestellt: Mithilfe einfacher Dienstbeschreibung soll der Zugriff auf unterschiedliche Dienste möglich sein und deren Ergebnisse aggregiert werden. Anhand von Mappings sollen Dienste kategorisiert werden können. Die zu entwickelnde Systemarchitektur soll Programmen die Möglichkeit bieten, Informationen von RESTful Web Services zu beziehen. Es sollen Dienste angesprochen werden, die ihre Daten mittels XML und JSON übermitteln. Die Informationen der verschiedenen Dienste sollen von der zu entwickelnden Softwarekomponente in XML ausgeliefert werden. Über eine graphische Benutzeroberfläche (GUI) soll der Nutzer Dienste registrieren und wieder löschen können.

48 4. KONZEPTION Nicht-funktionale Anforderungen Die nicht-funktionalen Anforderungen sind wie folgt definiert: Bei der Umsetzung der zu konzipierenden Systemarchitektur soll - in Bezug auf die Einordnung dieser Arbeit in das Toolkit Palladian - die Programmiersprache Java verwendet werden, wodurch auch eine Plattformunabhängigkeit geboten wird. Weiterhin sollte bei der Informationsbeschaffung ein Ergebnis innerhalb von fünf Sekunden geliefert werden oder eine entsprechende Fehlermeldung ausgegeben werden. 4.2 Systemarchitektur im Überblick User Interface Wrapper Manager Registry PDeveloper Application Programming Interface Communicator Service A Service B Service Z Abbildung 4.1: Komponenten der RESTator Architektur Die Umsetzung der Aufgabenstellung erfordert die Kommunikation zwischen einem Entwickler bzw. einem vom Entwickler erstellten Programm und verschiedenen RESTful Web Services. Auf der einen Seite muss es dem Entwickler möglich sein, eine Dienstbeschreibung an die Softwarekomponente RESTator zu übergeben, damit diese auf der Grundlage einer Beschreibung mit einem Service kommunizieren kann. Eine Dienstbeschreibung soll aus grundlegenden Merkmalsangaben, wie der Beschreibung der Ressourcen, der Methoden und der Ein- und Ausgabeparameter, bestehen und weiterhin eine Beschreibung erweiterter Merkmalsangaben enthalten, wie die Ausschreibung nichtfunktionaler Dienstmerkmale (Angabe des Dienstanbieters, Beschreibung des Services, Authentifizierung) und die semantische Zuordnung der grundlegenden Merkmalsangaben. Detailierte Angaben zur konzeptionellen Darlegung der zu verwendenden Dienstbeschreibung sind in Abschnitt 4.3 zu finden. Auf der anderen Seite befinden sich jene Dienste, die der Entwickler für seine Informationsbeschaffung nutzen möchte. In der Abbildung 4.1 ist das Zusammenspiel zwischen dem Entwickler aus dem Anwendungsszenario, der Softwarekomponente RESTator und den Diensten verdeutlich. Entsprechend dem funktionalen und nicht-funktionalen Verhalten, das für die Kommunikation mit verschiedenen RESTful Web Services notwendig sein wird, wurde die Softwarekomponente RESTator in fünf Komponenten aufgeteilt. Unter nicht-funktionalem Verhalten sind die Angaben zu dem

49 4. KONZEPTION 46 Servicenamen, des Providers, der Servicebeschreibung, aber auch des Developerkeys zu verstehen. Welche Aufgaben die Komponenten übernehmen und wie die Realisierung der Anforderungen in diese Komponenten zu integrieren ist, wird in den nächsten Unterkapitel erklärt. 4.3 Dienstbeschreibung Eine Beschreibung des Dienstes ist die Voraussetzung für die maschinelle Verarbeitung von Diensteigenschaften und bildet die Grundlage, aus der RESTator seine Informationen für die Kommunikation mit verschiedenen Services bezieht. Die Diskussion am Ende des Kapitels 3 lieferte bereits die Begründung für den Einsatz der Beschreibungssprache WADL. Im weiteren Text wird geklärt welche Informationen aus einer WADL-Beschreibung für die Softwarekomponente von Bedeutung sind. Darauffolgend werden die notwendigen Erweiterungen vorgestellt, welche das Discovery und die Kommunikation mit den Services mit sich bringen Grundlegende Dienstbeschreibung Mithilfe von WADL ist es auf einfache Art und Weise möglich, Ressourcen von Web Services durch die Angabe der Adresse, der Methoden sowie der Nachrichtenparameter näher zu beschreiben. Ein Beispiel für die Beschreibung einer Ressource mittels WADL und die dabei verwendeten Elemente wurde in Abschnitt vorgestellt. Ein noch nicht weiter erwähntes Element ist <doc>, das dazu dient die Elemente einer WADL textuell zu beschreiben. Jedes Element in der WADL kann mehrere <doc>-elemente als Kinder besitzen. Somit ist es möglich die Ressourcen, deren Methoden und die Parameter in der WADL textuell zu beschreiben. Die Beschreibung der Parameter wird eine hohe Priorität zugeordnet, weil diese neben den Parameternamen und den Datentypen auf den Providerseiten textuell beschrieben werden und wichtige Erkenntnisse über das Verhalten des Services vermittelt. Die Struktur der Antwortnachricht kann genauso wie bei der Anfrage mittels Parametern ausgedrückt werden. Im Fall von WADL ist auf diese Weise eine flache Struktur möglich. Die Verwendung von verschachtelte Antworten ist mit Referenzen auf XML-Schema Dateien möglich (siehe Abschnitt ). Für die Registrierung von Services muss der Entwickler eine WADL Datei erstellen und wenn nötig auch entsprechende XML-Schema Dateien und diese an RESTator übergeben. Diese Informationen sollen ausgelesen und an die Registry-Komponente von RESTator weitergeleitet werden. Von dort aus können sie für das Discovery verwendet werden. Für das Discovery sind diese Informationen allerdings nicht ausreichend, weil Informationen über den Anbieter, die Kategorie und die Einordnung der möglichen Aktionen (Mapping) eines Web Services fehlen. Weiterhin soll es auch möglich sein die Authentifizierung gegenüber eines Services in Form eines Developer Keys anzugeben. Wie diese Erweiterungen gegenüber der grundlegenden Dienstbeschreibung formuliert werden, wird im nächsten Abschnitt geklärt.

50 4. KONZEPTION Erweiterte Dienstbeschreibung Die angesprochenen Erweiterungen werden unter Zuhilfenahme einer ergänzenden Beschreibung vollzogen. Das soll heißen, dass neben dem WADL-Dokument noch ein weiteres XML-Dokument für die Dienstbeschreibung zuständig ist und die Erweiterungen enthält. Weil dieses Dokument zusätzliche Beschreibungen von Elementen des WADL-Dokumentes in Form von Mapping-Attributen beinhaltet, wird es als WADLDescription bezeichnet. Die Begründung für die Trennung liegt in der besseren Übersichtlichkeit - bspw. wird das Mapping der Parameter in dem WADLDescription Dokument vollzogen, dass auf die wesentlichsten Serviceangaben beschränkt ist - und der Austauschbarkeit des WADL-Dokumentes mit anderen Entwicklern, die nicht mit den hier verwendeten Erweiterungen arbeiten. Ein direktes Arbeiten des Entwicklers mit dem WADLDescription Dokument wird nicht gefordert. Die Inhalte werden dem Nutzer graphisch in der Form eines Formulars angezeigt und sollen von ihm ausgefüllt werden. Nach einer Bestätigung werden diese Angaben in das WADLDescription Dokument geschrieben und für die weitere interne Verarbeitung verwendet. < s e r v i c e name="chacha " > / / e n t h ä l t a l l e weiteren Elemente des WADLDescription Dokumentes </ service > Quellcode 4.1: Das Wurzelelement <service> Das Wurzelelement des WADLDescription Dokumentes ist in Quelltext 4.1 dargestellt. Es enthält alle weiteren Elemente, die die Erweiterungen beschreiben und in den folgenden Abschnitten vorgestellt werden. Um den Service später identifizieren zu können, muss für den Wert des Attributes name der Name des Dienstes gesetzt sein Ausschreibung nicht-funktionaler Dienstmerkmale Das Element <provider> aus dem Quelltext 4.2 enthält den Namen des Serviceanbieters. Durch die Bestimmung einer Identifikationsnummer, die in dem Element <id> festgehalten wird, ist ein Service eindeutig identifizierbar. Eine Beschreibung des Services ist durch das <description> Element aus Quelltext 4.3 gegeben. <provider >ChaCha Search, Inc. < / provider > Quellcode 4.2: Das Element <provider> < d e s c r i p t i o n > With the ChaCha API you can ask a question or..... </ d e s c r i p t i o n > Quellcode 4.3: Das Element <description> < a u t h e n t i c a t i o n a c t i v a t e d = " t r u e " > <type >header param </ type > </ a u t h e n t i c a t i o n >

51 4. KONZEPTION 48 Quellcode 4.4: Das Element <provider> Die Authentifizierung eines Benutzers gegenüber einem konkreten Web Service wird überlicherweise über einen Developerkey geregelt. Dazu muss sich der Dienstnutzer bei dem Provider registrieren und erhält einen eindeutigen Key. Der Key wird dann bei Ressourcenaufrufen eines Dienstes als Wert eines bestimmten Parameters gesetzt. Das Toolkit Palladian bietet bereits eine Datei an, die verschiedene Developerkeys speichert. Diese Datei soll für die Ermittlung der zu verwendenden Keys herangezogen werden. Der Nutzer muss unter der Voraussetzung, dass der Key bereits in der Datei registriert ist, bei der Registrierung eines Dienstes den entsprechenden Developerkey angeben. Damit die Softwarekomponente den Key für den richtigen Parameter setzen kann, muss der Mappingwert für den entsprechenden Parameter auf developerkey gesetzt werden. Weiteres zum Thema Mapping wird in dem nächsten Unterabschnitt erklärt. In Quelltext 4.4 ist das Element <authentication> dargestellt, welches die Authentifikation beschreibt. Falls keine Authentifizierung nötig ist, ist der Wert des Attributes activated auf false gesetzt. In diesem Beispiel ist allerdings eine Authentifizierung gefordert und somit muss auch deren Art beschrieben werden. Dabei sollen die üblichen Authentifizierungsarten, die von RESTful Web Services gefordert werden, möglich sein. Das Attribut <type> enthält den Text header param, was heißt, dass der Parameter und der Key von dem dafür zuständigen Objekt in den Header des HTTP-Aufrufs geschrieben werden soll. Weitere Elemente des WADLDescription Dokumentes sind <created> und <last_modified>. Damit kann einerseits das Datum, an dem der Service in der Registry registriert wurde, gespeichert werden und andererseits das Alter der letzten Änderung festgehalten werden. <category mapping= " search / p i c t u r e / people " / > Quellcode 4.5: Das Element <category> Um einen Service anhand einer bestimmten Kategorie zu suchen wird eine weiteres Element eingeführt. Dies ist das Element <category> (siehe Quelltext 4.5). Wie in dem Quelltext zu sehen ist enthält es das Attribut mapping, das aus einem String besteht, der die Kategorie des Services beschreibt. Die Beschreibung kann aus mehreren Schlagworten zusammengesetzt sein, die durch einen Bindestrich voneinander getrennt werden. In dem dargestellten Beispiel handelt es sich um einen Service mit dem nach Bildern gesucht werden kann, auf denen Menschen dargestellt sind. Dieser Zusammenhang kann als Teilmenge dargestellt werden: people picture search. Dabei steht people für Bilder, auf denen Menschen abgebildet sind und ist somit eine Teilmenge von picture, das für alle möglichen Arten von Bildern steht. Das Schlagwort search steht für die Internetsuche in allen erdenkbaren Kategorien. In dem Beispiel bezieht sich die Suche auf die Kategorie Bilder und somit ist picture eine Teilmenge von search. Die allgemeinste Obermenge wird demnach am Anfang des Strings festgehalten. Es ist leicht zu sehen, dass durch dieses Vorgehen ein Baum aufgespannt werden kann. Eine Möglichkeit für eine weitere Verzweigung stellt beispielsweise der String search/picture/animals. Hierbei handelt es sich somit um einen Suchservice mit dem nach Tierbildern gesucht werden kann. Falls nun mehrere Services mit diese Kategorisierung in der Registry eingetragen sind, kann RESTator diese Gruppieren und in die Kommunikation einbeziehen. Dies geschieht dadurch, das von dem Entwickler aus dem Anwendungsszenario die Kategorie und die aus-

52 4. KONZEPTION 49 zuführende Aktion an die Softwarekomponente übergeben wird. Die Kategorisierung des Services ansich ist noch nicht ausreichend für die automatisierte Kommunikation mit ähnlichen Services. Der Grund dafür liegt darin, dass die einzelnen Services aus verschiedenen Ressourcen bestehen, die unterschiedliche Aktionen ermöglichen und für die Anfrage bestimmte Parameter voraussetzen. Dafür werden weitere Mappingschritte benötigt. Eine genauere Erklärung wird in dem nächsten Abschnitt vorgestellt Mapping von funktionalen Dienstmerkmalen Das Mapping der funktionalen Dienstparameter bezieht sich auf die konkreten Ressourcen eines Web Services und dessen Anfrage- und Antwortparameter. Dadurch ist es möglich die Parameter einer Nachricht auf bestimmte Werte abzubilden, die von verschiedenen Serviceressourcen geteilt werden. Für die Umsetzung wird das Element <actions> eingeführt, das in Quelltext 4.6 dargestellt ist. Dieses Element kann mehrere <action> Elemente enthalten, die jeweils ein Attribut namens mapping beinhalten. Es ist für das Ressourcenmapping zuständig und beinhaltet die Begriffe, die vom Benutzer der Softwarekomponente für die Beschreibung der Dienstressource angegeben wurden. Da es sich bei dem Mapping um die Angabe von Schlagworten handelt und es möglich ist einer Ressource mehrere Schlagwörter zuzuordnen, können die Begriffe in einem einzigen String gespeichert und mit einem Komma voneinander getrennt werden. Mit dem <action> Element kann genau eine Ressource eines Web Services beschrieben werden. Wie zu sehen ist beinhaltet die Beschreibung die Adresse des Web Services, die durch die Elemente <resources> und <resource> ausgedrückt wird und die Angabe der HTTP-Methode in dem Element <method>. Weiterhin werden die Aufrufparameter mithilfe des Elementes <params> dargestellt. Einen Aufrufparameter wird das Element <param> verkörpern und die für das Mapping relevanten Information beinhalten. Das ist zum einen der Name des Parameters (Attribut name) und zum anderen die Bezeichnung auf die der Aufrufparameter abgebildet werden soll (Attribut mapping). <actions > < a c t i o n mapping= " answer, questionsearch " > <resources base=" h t t p : / / query. chacha. com/ " / > <resource path= " answer / search. json " / > <method>get</ method> <params> <param name= " query " mapping=" query " / > <param name= " pagesize " mapping= " pagesize " / > </ params> <response> </ response> </ action > </ actions > Quellcode 4.6: Das Element <actions> und seine Kindelemente Um die Struktur und das Mapping der Antwortnachricht festzuhalten, müssen die entsprechenden <response> Elemente der WADL und die Elemente der XML-Schema Dateien, falls vorhanden, ausgelesen und in die WADLDescription Datei überführt werden. Die Struktur spielt deshalb eine Rolle, weil sie auf den Übersichtseiten der Registry (zum Beispiel der Yellow Page) ersichtlich sein

53 4. KONZEPTION 50 soll, um den Entwickler aus dem Anwendungsszenario bei der maschinellen Auswertung der Serviceantworten zu unterstützen. Ein Beispiel für das <response> Element einer WADLDescription Datei ist in Quelltext 4.7 zu sehen. Die hierarchische Struktur der Antwort wird durch verschiedene Elementen des Typs <field> dargestellt. Diese Felder sind durch jeweils einen Namen gekennzeichnet, der auch in den textuellen Beschreibungen auf den Providerseiten vorkommt. Ein Mapping wird an den Parametern vollzogen, die einen Informationsgehalt haben, beispielweise eine bestimmte Textausgabe liefern, und kann durch ein Schlagwort gekennzeichnet werden. Das Attribut format des <response> Elementes enthält das Format der Antwortnachricht und ermöglicht die Extraktion einzelner Elemente. <response format = " xml " > < f i e l d name=" qvpresults " > < f i e l d name=" answer " > < f i e l d name= " i d " mapping= " answerid " / >.... </ f i e l d > < f i e l d name=" question " > < f i e l d name= " i d " mapping= " q u e s t i o n i d " / >.... </ f i e l d > < f i e l d name=" type " mapping= " " / > </ f i e l d > < f i e l d name=" success " mapping= " success " / > < f i e l d name=" path " mapping=" path " / > </ response> Quellcode 4.7: Das Element <response> und seine Kindelemente Die durch einen Benutzer angebrachten Mappings müssen nicht vollständig für jeden Parameter erstellt werden. Der Grund dafür liegt darin, dass die Antwort unter bestimmten Umständen auch sehr komplex ausfallen kann. Wenn in diesem Fall zu der strukturellen Beschreibung der Antwort noch ein vollständiges Mapping gefordert wäre, würde der Arbeitsaufwand zu groß werden. Deshalb soll es möglich sein auch mit wenigen Mappings eine Antworten geliefert zu bekommen. Daraus folgt aber auch, dass die Mappings einer Antwortnachricht eindeutig sein müssen, sonst könnten die einzelnen Elemente bzw. Felder nicht ermittelt werden Interne Verarbeitung der Dienstbeschreibungen Ein Service soll mit Hilfe von maximal drei Dokumenttypen beschrieben werden. Wie bereits zuvor erklärt, handelt es sich dabei um WADL-, XSD- und WADLDescription Dokumente. Das WADL- Description Dokument wird aus den anderen Dokumenten generiert. Alle Dokumente eines Dienstes werden intern gespeichert und für die Erstellung der Übersichtsseiten der Registry herangezogen. Die für einen Dienstaufruf relevanten Informationen werden durch Parser zur Verfügung gestellt, die auf die Dokumente zugreifen und im Falle des WADLDescription Dokumentes auch das schreiben ermöglichen sollen.

54 4. KONZEPTION Registry Die Registry ist für Speicherung der Dienstinformationen nach bestimmten Kriterien zuständig. Hierbei sollen die Prinzipien von UDDI (siehe Abschnitt ) angewendet werden. Demnach unterteilt sich die Registry von RESTator in die Kategorisierungtypen: White Page, Green Page und Yellow Page. Für die Darstellung von aggregierten Dienste muss eine weitere Seite eingeführt werden, die es ermöglich, durch eine einfache Darstellung, die nötigen Informationen für den Aufruf von mehreren Diensten bereitzustellen. Diese Seite wird im Kontext von RESTator als Wrapper Page bezeichnet. Der Informationsgehalt der einzelnen Seiten wird in der folgenden Auflistung definiert: White Page: Die White Page von RESTator enthält grundlegend alle registrierten Dienste. Für jeden Dienst ist der Anbieter, die textuelle Beschreibung des Dienstes, das Datum der Registrierung und Änderung des Dienstes ersichtlich. Green Page: Mithilfe der Green Page kann sich der Benutzer darüber informieren, wie die registrierten Dienste aufgerufen werden können. Hierbei soll die Dienstadresse, die Methode des Dienstes sowie die Beschreibung der Aufruf- und Antwortnachrichten dargestellt werden. Auf Grundlage dieser Informationen soll es möglich sein, eine Ressource eines Dienstes aufzurufen und die Anwort auszuwerten. Yellow Page: Die Kategorisierung der Dienste ist auf der Yellow Page zu sehen. Das zuvor beschriebene Mapping eines Dienstes wird auf die Yellow Page übertragen und somit wird ein Dienst entsprechend seiner Katetegorisierung und dem Mapping in die Yellow Page eingeordnet. Falls vom Benutzer das Mapping des Dienstes, insbesondere das Mapping der Ressourcen bzw. der Aktionen, nicht vollzogen wurde, wird der Dienst auch nicht in der Yellow Page aufgelistet. Da sich das Mapping bis auf die einzelnen Ressourcen der Dienste ausbreitet, wird ein Baum aufgespannt, dessen Blätter aus den Ressourcen der Dienste bestehen. Da ein Dienst aus mehreren Ressourcen bestehen kann, kann ein Dienst also auch in mehreren Blättern vertreten sein. Diese Ansicht bietet die wichtigsten Informationen zu der Nutzung einer bestimmten gemappten Ressource und ermöglicht einen direkten Vergleich mit der Wrapper Page. Wrapper Page: Unter der Wrapper Page werden nur Informationen entsprechend des Mappingverhaltens präsentiert. Genauer gesagt werden auf dieser Seite nicht mehr die eigentlichen Ressourcen und deren Aufruf- und Antwortparameter dargestellt, sondern die gemappte Aktion und die vorhandenen gemappten Aufruf- und Antwortparameter. Die Angabe einer Adresse für den Aufruf eines Web Service ist für eine derartige Aggregation nicht mehr nötig. Die Services können durch die Kategorie, die Aktion auf einer bestimmten Ressource und die entsprechenden Parameter identifiziert werden. Durch die Angabe dieser Information ermitteln interne Verarbeitungsmechanismen die eigentlichen Dienste, die auf eine bestimmte Aktion gemappt wurden und ermitteln die für einen Aufruf nötigen Informationen. Weiterhin sollen für jede angeführte Aktion diejenigen Services aufgelistet werden, die bei einem Aufruf angesprochen werden. Da die Hierarchie der Wrapper Page und der Yellow Page die gleiche ist und nur die Informationen innerhalb einer Aktion unterschiedlich dargestellt werden ist ein Vergleich bei-

55 4. KONZEPTION 52 der Seiten durch den Nutzer möglich. Schaut sich der Nutzer beispielsweise eine Aktion auf der Wrapper Page an, sieht er auf den ersten Blick die gemappten Parameter, hinter denen sich aber Parameter verschiedener Service verbergen können. Um die eigentlichen Aufrufparameter eines Services zu erfahren, wählt er sich den entsprechenden Service aus der genannten Liste der aufgeführten Dienste, geht in die entsprechende Aktion der Yellow Page, sucht den Service und begutachtet deren Parameter und das Mappingverhalten. Neben dieser Darstellung von Dienstinformation sollen Dienste registriert, modifiziert und gelöscht werden können. Bei der Registrierung eines Dienstes sind Informationen über den Provider, den Dienst ansich und die Dienstbeschreibungen gefordert. Durch Angabe dieser Information ist ein Dienst in der White Page und der Green Page sichtbar. Ein Dienst muss nicht gemappt werden. Für aggregierte Dienstaufrufe ist das Mapping allerdings obligatorisch. Im Falle eines Mappings soll ein Dienst zusätzlich zu den anderen Seiten auch auf der Yellow Page und der Wrapper Page ersichtlich sein. Weiterhin soll die Registry für das Erzeugen und Modifizieren der Übersichtsseiten zuständig sein und Parser für deren Verarbeitung bereitstellen. 4.5 Communicator Die Komponente Communicator hat die Aufgabe die verschiedenen RESTful Web Services einzeln als auch gruppiert anzusprechen. Dabei werden ihr die notwendigen Informationen, die für einen Dienstaufruf erforderlich sind, zur Verfügung gestellt. Für gruppierte Dienstaufrufe - also jene Gruppen von Diensten, die einer bestimmte Kategorie angehören und mehr als einen Dienst umfassen können - werden die einzelnen Antworten der Dienste zusammengefasst und innerhalb einer Nachricht an den Wrapper Manager weitergeleitet. Darüber hinaus hat die Komponente die Aufgabe die Antwortnachrichten der Dienste nach bestimmten Vorgaben zu Filtern. Die Vorgaben beziehen sich auf XML-Elemente der Antwortnachricht und sollen die Auslieferung einzelner zu einem Dienst gehörender Elemente der Antwortnachricht ermöglichen. Dabei soll es möglich sein mehrere Elemente der Antwortnachricht herauszufiltern. 4.6 Wrapper Manager Wie in Abbildung 4.1 zu sehen ist befindet sich der Wrapper Manager im Zentrum der RESTator Architektur. Er hat die Aufgabe die Informationen, die durch das User Interface und die Programmierschnittstelle generiert werden, an die Registry und den Communicator zu übermitteln. Die Pfeile in der Abbildungen zeigen, dass die Kommunikation bidirektional ausgerichtet ist und somit die aufbereiteten Informationen von dem Backend (Registry, Communicator) an das Frontend (User Interface, API) übermittelt werden sollen. Der Wrapper Manager soll als Vermittler agieren, der Anfragen bezüglich der Registrierung, der Modifikation und dem Löschen von Diensten sowie die Anfragen an Dienste entgegennimmt, weiterleitet und letzendlich die angeforderten Informationen bereitstellt. Dabei muss er die Beschreibungsdokumente eines Dienstes (siehe Abschnitt 4.3.2) auf ihre Korrektheit

56 4. KONZEPTION 53 hin überprüfen und im Fehlerfall entsprechend reagieren. Unter der Bedingung, dass die Dokumente korrekt sind, initialisiert er die Generierung des WADLDescription Dokumentes, in dem die erweiterten Diensteigenschaften gespeichert werden. Im Gegensatz zu der Registry, die die Übersichtsseiten den Dienstinformationen speichert, ist der Wrapper Manager für die persistente Speicherung der einzelnen Dienstbeschreibungen zuständig und leitet im Falle eine Änderung die entsprechenden Informationen weiter. Das Verhalten des Wrapper Manager bei der Registrierung und dem Mapping von Diensten ist in dem Sequenzdiagramm 4.2 zu erkennen. Wie zu sehen ist, fordert die GUI bei dem Mapping eines Dienstes die WADLDescription Beschreibung von dem Wrapper Manager an. Diese Beschreibung stellt die Grundstruktur mit den Grundelementen des Dienstes dar. Damit kann das User Interface dynamisch erstellt werden. Für die Anforderung und Darstellung weiterer Informationen zu den Diensten kann die GUI die bereitgestellten Methoden des Wrapper Managers nutzen. Um die Funktionalität des Wrapper Manager übersichtlich zu gestalten, wurden drei Bereiche identifiziert, die eng mit dem Wrapper Manager zusammenhängen. Die Funktionalität dieser Komponenten wird in der folgenden Auflistung beschrieben: Service Manager: Dieser Manager soll die Aufgabe haben die Beschreibungsdokumente eines Services zu parsen und deren Informationen bereitstellen. Transformers: In diesem Bereich werden die Klassen zusammengefasst, die bestimmete Dokumenttransformationen durchzuführen haben. So soll es beispielsweise einen Transformator geben, der die vorliegenden Beschreibungsdokumente in das WADLDescription Dokument überführt. Weitere Transformatoren können für die Erstellung von visuellen Übersichtsseiten der Registry zum Einsatz kommen. Discoverer: Wie bereits in Abschnitt 4.4 beschrieben, wird die Wrapper Page durch die ausgeschriebenen Mapping-Angaben gebildet. Für das Auffinden der Dienste, die sich hinter diesen Mappings verbergen, ist die Komponente Discoverer zuständig. 4.7 Die Benutzung von RESTator Nachdem in den Abschnitten zuvor die Ausschreibung, die Verarbeitung und Bereitstellung der unterschiedlichen Dienstinformationen und -funktionalitäten besprochen wurde, geht es in diesem Kapitel darum, in welcher Art und Weise es dem Benutzer der Softwarekomponente RESTator ermöglicht werden soll auf die Informationen und Funktionalitäten des Backends und des Wrapper Managers zuzugreifen Verwaltung und Darstellung der registrierten Services Die Verwaltung der Dienste basiert zunächst einmal auf der Registrierung von Diensten. Der Nutzer, der RESTator verwendet, erhält über eine graphische Oberfläche eine Eingabemaske, in die er den Namen, den Anbieter und eine Beschreibung des Dienstes eingeben kann. Er muss mindestens eine WADL Datei angeben und optional weitere XML Schema Dateien, die die Antworten des Dienstes beschreiben. Weiterhin muss die Authentifizierung festgelegt werden. Wenn die Angaben getätigt

57 4. KONZEPTION 54 und auf ihre Vollständigkeit sowie Korrektheit hin überprüft wurden, wird der Dienst in die Yellowund die Green-Page eingetragen und alle Angaben, sowie die übergebenen Dienstbeschreibungen intern gespeichert. Dieses Vorgehen ist in dem Sequenzdiagramm 4.2 dargestellt. Dadurch soll bereits eine Nutzung des registrierten Dienstes möglich sein. Da aber noch keine Mappings der Parameter der Anfrage- und Antwortnachrichten und keine Kategorisierung des Dienstes bzw. der Ressourcen getätigt wurden, kann zu diesem Zeitpunkt keine Filterung der Antwort vorgenommen werden. Es wird dementprechend die Gesamtantwort geliefert. Diese noch fehlenden Angaben kann der Nutzer ergänzen, indem er einen einen Dienst für das Mapping auswählt und die ihm präsentierte Eingabemaske ausfüllt (siehe 4.2). In dieser Eingabemaske können nun folgende Angaben gemacht werden. Es kann die Kategorie des Services und die Einordnung der Ressource, genauer gesagt die Aktion des Dienstes, durch Schlagwörter angegeben werden. Weiterhin soll es möglich sein die Parameter der Anfrage und der Antwort zu mappen. Da die Antwort eines Dienstes einer hierarchische Struktur unterliegen kann, soll dem Benutzer diese Struktur angezeigt werden. Dies kann beispielsweise durch einen XML-Baum visualisiert werden. Durch Bestätigung der Angaben wird das WADLDescription Dokument des Dienstes aktualisiert. Es müssen auch die entsprechenden Seiten der Registry neu erstellt werden. Dies betrifft vorallem die Yellow-Page, die die Dienstressourcen entsprechend ihrer Kategorisierung und Aktion einordnet und die Wrapper-Page, die die Einordnung anhand der Mappings, der Kategorisierung und der Aktion vornimmt. Um Angaben bezüglich eines Services zu ändern, soll es möglich sein die bei der Registrierung gemachten Angaben abzuändern. Ein Service kann zum Beipiel einen neuen Namen bekommen, falls dieser nicht schon vergeben ist. Im Falle einer Veränderung der Schnittstelle eines Dienstes, sollte es möglich sein eine neue WADL hochzuladen. Damit an dieser Stelle nicht alle Mappings verloren gehen, kann ein Vergleich zwischen der alten und der neuen WADLDescription angestellt werden, um die weiterhin gültigen Parameter mit ihren Mappings zu erhalten. Weiterhin sollte es möglich sein die Mappings zu ändern bzw. vollständig zurückzusetzen. Dienste sollen auch gelöscht werden können. Nach dem Löschen müssen alle Seiten der Registry aktualisiert werden und alle zu dem Dienst gehörenden Dokumente entfernt werden. Die Darstellung der registrierten Dienste erfolgt durch die visuelle Präsentation der Übersichtsseiten der Registry, die in Abschnitt 4.4 vorgestellt wurden. Es sollte möglich sein Kategorien und Aktionen der Yellow Pages anzulegen. Damit kann der Nutzer bzw. Entwickler ein Grundgerüst für die Einordnung seiner Dienste erstellen. Dieser Vorgang ist durch Löschung der entsprechenden Kategorie oder Aktion wieder rückgangig zu machen Dienstnutzung über die RESTator API Die in Abbildung 4.1 dargestellte Komponente Application Programming Interface(API) ist für die Weiterleitung und Beantwortung von Dienstaufrufen verantwortlich. Der Entwickler kann entweder gezielt einzelne RESTful Web Service aufrufen oder eine Gruppe von Diensten ansprechen, die die gleiche Schnittmenge an Mappings aufweisen. Bei dem Aufruf von einzelnen RESTful Web Services müssen der Providername, der Dienstname und die für einen Ressourceaufruf notwendigen Information übergeben werden. Daraufhin wird die Gesamtantwort geliefert. Der Aufruf von grup-

58 4. KONZEPTION 55 Abbildung 4.2: Registrierung und Mapping eines Services

59 4. KONZEPTION 56 pierten Diensten erfolgt durch Angabe der ausgewählten Kategorie, der Aktion sowie der gemappten Anfrage- und Antwortparameter. Dabei soll es möglich sein, dass entweder die jeweilige Gesamtanwort der angesprochenen Services zusammengefasst geliefert wird oder es findet zuvor eine Filterung anhand der gemappten Antwortparameter statt, durch die dann nur die gefilterten Elemente der jeweiligen Gesamtantwort übermittelt werden. Die Informationen, die bei einem Aufruf der API übergeben werden sollen, sind auf den Übersichtseiten der Registry zu finden und müssen entsprechend angegeben werden. Für einen gruppierten Dienstaufruf müsste sich der Entwickler somit auf der Wrapper Page der Registry umschauen. Für beide Aufrufvarianten gielt, dass im Falle eines Fehlers von Seiten des Dienstanbieters, die erhaltene Fehlermeldung weitergeleitet wird. 4.8 Zusammenfassung und Abgrenzung In diesem Kapitel wurde das Konzept für die Softwarekomponente RESTator für den Aufruf von verschiedenen RESTful Web Services vorgestellt. Eingangs (siehe Kapitel 4.1) wurden die Anforderungen an die Softwarekomponente genannt und deren konteptionelle Umsetzung in den darauffolgenden Abschnitten vorgestellt. Zum besseren Verständnis der Zusammenhänge wurde in Kapitel 4.2 ein Überblick der Gesamtarchitektur der Softwarekomponente präsentiert. Das Kapitel 4.3 befasste sich mit der grundlegenden und der erweiterten Dienstbeschreibung sowie dem Mapping von Dienstmerkmalen, die als notwendige Voraussetzung für den Zugriff auf die Services zu betrachten sind. Für das Suchen nach registrierten Diensten wurde in Kapitel 4.4 der Aufbau der Registry vorgestellt, der sich an den Prinzipien von UDDI orientiert. Die Wrapper Page der Registry hat die Funktion die registrierten Dienste anhand ihrer Mapping-Parameter darzustellen und dadurch zu gruppieren. Durch dieses Vorgehen wird dem Entwickler die Möglichkeit geboten, Informationen für die API-Aufrufe zu beziehen und mehrere Dienste mit einem API-Aufruf anzusprechen. Für die interne Kommunikation mit den eigentlichen Dienste wurden in Kapitel 4.5 einfache und gruppierte Dienstaufrufe angesprochen. Die Vermittlung von Informationen aus dem Frontend (User Interface, Application Programming Interface) in das Backend (Registry, Communicator) und umgekehrt findet über den, in Kapitel 4.6 vorgestellten, Wrapper Manager statt. Daraufhin wurde in Kapitel das Konzept für die Nutzung der Softwarekomponente präsentiert. RESTful Web Services bieten die Möglichkeit auf domainenspezifische Informationen zuzugreifen, deren Beschaffung durch Zugriffsrechte eingeschränkt sein kann und deren Informationsdarstellung durch unterschiedliche Formate dargestellt wird. Aus diesem Grund wird an dieser Stelle darauf angegangen, welche Abgrenzungen, in Bezug auf den Zugriff und die Informationsdarstellung von Diensten, für die Softwarekomponente vorgesehen sind. Der Zugriff auf, das Anlegen oder das Löschen von benutzerbezogene Information ist üblicherweise für den Benutzer eines Dienstes erlaubt. Um auch Anwendung den Zugriff auf benutzerbezogene Informationen zu erlauben - ohne das diesen das Geheimnis eines Benutzers preisgegeben wird - bedarf es zusätzlicher Protokolle. Eine Authorisierung in diesem Sinne ist durch das Protokoll OAuth 1 möglich und wird in der Praxis für RESTful Web Services eingesetzt, um den Gebrauchswert von Anwendungen zu steigern. Um Informationen auf diesem Wege zu beziehen bräuchte der Entwickler 1

60 4. KONZEPTION 57 eine Benutzer-Community, deren Mitglieder den Zugriff autorisieren. Da aber für die Umsetzung des Konzeptes die direkte Kommunikation und damit auch das Beschaffen von öffentlich zugänglichen Informationen im Vordergrund steht, wird für das Konzept auf die Umsetzung des OAuth-Protokolls verzichtet. Damit die Softwarekomponente die Antwortnachrichten der Dienste filtern kann, wird bei diesem Konzept vordergründig das Format XML zum Einsatz kommen. Antwortnachrichten von Diensten, deren Inhalte in XML notiert sind oder die sich in XML konvertieren lassen, können somit verarbeitet werden.

61 5. IMPLEMENTIERUNG 58 5 Implementierung In diesem Kapitel wird eingangs das Zusammenspiel der wichtigsten Bestandteile der implementierten Softwarekomponente vorgestellt. Weiterhin werden ausgewählte Bestandteile der entwickelten Softwarekomponente erklärt. Das ist zum einen die Klasse Discoverer, die bei einem WrapperRequest die originalen Parameter einer Serviceressource bestimmt und zum anderen das Packet Communicator, welches die Kommunikation mit den verschiedenen Services abwickelt. Für die programmtechnische Nutzung der Softwarekomponente wird in Kapitel 5.3 die Spezifikation der Datenaustauschschnittstelle vorgestellt. Wie bereits in den Anforderungen des Konzeptes erwähnt wurde die Softwarekomponente in der Programmiersprache Java entwickelt. Anhand der Anforderungen der Aufgabenstellung wurden die Beschreibungen der Dienste mittels XML ausgedrückt und verarbeitet. Die Speicherung und Bearbeitung der registrierten Dienste erfolgt ebenfalls auf der Grundlage von XML. Somit sind die jeweiligen Inhalte der Übersichtsseiten der Registry in XML-Dateien gespeichert. Für die Bearbeitung dieser XML-Dateien kam die java-basierte API JDOM 1 zum Einsatz. Diese ermöglicht einen einfachen und schnellen Zugriff auf Informationen der XML-Dateien. Die graphische Benutzeroberfläche ist mit der Grafikbibliothek Swing (Java) umgesetzt wurden. Diese bietet eine reichhaltige Palette an Funktionalitäten für das Darstellen von GUI-Elemente und gewährleistet eine plattformübergreifende Funktionstüchtigkeit. Bei der Implementierung wurden zwei Klassen verwendet, die ein Copyright der Firma Oracle besitzen und unter minimalen Bedingungen frei verwendet werden dürfen. Beide Klassen sind in dem Packet ws.palladian.retrieval.wrapper.gui.components zu finden. Die Klasse SpringUtilities.java ist für die Anordnung des Layouts bei der Dienstregistrierung zuständig. Die Klasse Filter.java ist für das Anzeigen bestimmter Dateitypen beim Hochladen der Dienstbeschreibungen verantwortlich. 5.1 Grundlegende Bestandteile der Softwarekomponente Die Komponenten, die im Entwurf für die Verteilung der Anwendungsfunktionalität identifiziert wurden, sind in der Phase der Implementierung durch Software-Packete bzw. selbständige Klassen umgesetzt wurden. Die wichtigsten sind in Abbildung 5.1 dargestellt. Im Zentrum dieser Abbildung befindet sich die Klasse WrapperManager, die die Erstellung des Dienstbeschreibungsdokumentes WADLDescription initialisiert (siehe Kapitel 4.3.2), Services hinzufügt und löscht, die Mappings in das WADLDescription Dokument überführt und die Anfragen der API entgegennimmt und weiterleitet. Für die Erstellung des WADLDescription Dokumentes nutzt der WrapperManager die Klasse 1

62 5. IMPLEMENTIERUNG 59 WADL2Descr aus dem Packet ws.palladian.retrieval.wrapper.transformers, die wiederum auf Klassen aus dem Packet ws.palladian.retrieval.wrapper.manager. service zugreift, um die Dienstinformationen in das WADLDescription Dokument zu überführen. Dabei ist die Klasse ServiceManager für das parsen und die Informationsbeschaffung aus der WADL Datei eines Services zuständig. Die Klasse ResponseManager extrahiert die Informationen aus den, in XML Schema beschriebenen, strukturierten Serviceantworten. Abbildung 5.1: Vereinfachte Darstellung der implementierten Systemarchitektur Die Klassen RegisterServiceView und MapServiceView aus dem Packet ws.palladian. retrieval.wrapper.gui.components erstellen die graphischen Oberflächen für die Registrierung und das Mapping der Kategorie sowie der jeweiligen Ressourcenparameter eines Services. Die jeweiligen Informationen, die in der GUI angegeben wurden, werden an den WrapperManager übermittelt. Im Falle der Registrierung werden dann die Dienstbeschreibungsdokumente der einzelnen Services in separaten Ordnern gespeichert (Projectfolder files services) und das Update der White- und GreenPage der Registry eingeleitet. Falls an einem Dienst ein Mapping vollzogen wird, muss eine Aktualisierung der Yellow- und der GreenPage erfolgen. Erst wenn die Parameter der Ressourcen von dem Mapping betroffen sind, kommt es zu einer Aktualisierung der WrapperPage. Für das Update bzw. die Aktualisierung der Registry-Seiten sind die Manager-Klassen des Packetes ws.palladian.retrieval.wrapper.registry.manager

63 5. IMPLEMENTIERUNG 60 zuständig. Jeder Registry-Seite liegt jeweils eine XML Datei zugrunde, die durch neue Dienste bzw. Mappings erweitert werden bzw. aus denen, durch das Löschen von Diensten oder dem widerrufen von Mappings, bestimmte Teile entfernt werden. Für die visuelle Darstellung der Inhalte dieser XML Dateien werden XSL 2 Transformationen verwendet, welche die Informationen in HTML Dokumente schreiben und damit in der GUI angezeigbar sind. Um Dienste aufzurufen bietet die Klasse RESTatorAPI zwei Methoden an. Mit der Methode servicerequest() können einzelne Dienste angesprochen werden. Dazu muss der Name, der Provider sowie die Parameter und -werte an die Methode übergeben werden. Für die aggregierte Informationsbeschaffung von mehreren Services wird der Methode wrapperrequest() die Kategorie, die Aktion sowie die gemappten Parameter und -werte übergeben. In dem Kapitel 5.3 wird schließlich gezeigt, wie das Antwortformat der Softwarekomponente, das die Informationen der Dienste beinhaltet, strukturiert ist. 5.2 Ausgewählte Bestandteile der Softwarekomponente In diesem Abschnitt wird gezeigt wie mithilfe einfacher Aussagen bezüglich des Kategoriensystems (Kategorie, Aktion, Mapping-Name) eine Gruppe von Diensten angesprochen werden kann. Dazu wird in Abschnitt der Algorithmus zum Bestimmen der in Frage kommenden Dienste beschrieben und in Abschnitt das Zusammenspiel der für die Kommunikation zuständigen Klassen erklärt Discoverer An dieser Stelle wird der Algorithmus für das Auffinden der Dienste durch Angabe von Mappingwerten erläutert. Der Algorithmus ist in dem Quelltext 5.1 dargestellt und der Methode reversemapping() der Klasse Discoverer aus dem Packet ws.palladian.retrieval.wrapper.discoverer zuzuordnen. Da die in Frage kommenden Dienste bereits durch die Zuordnung zu einer Kategorie und Aktion gegeben sind, besteht die Hauptaufgabe dieses Algorithmus darin, diejenigen Dienste auszuwählen, welche ein bestimmtes Mapping vollzogen haben. Folgende Werte werden der Methode reversemapping() übergeben: requestmappingparams: gemappte Parameter und deren Werte für eine bestimmte Aktion (Beschreibung einer Ressource). yellow_srvs: die Ressourcen derjenigen Services, die dieser Aktion angehören. Für jede übergebene Ressource eines Dienstes wird der Providername, der Dienstname sowie die Parameter-Elemente ermittelt (Zeile 10-12). Danach wird für jeden Parameter einer Dienstressource der Name sowie der Mapping-Name bezogen (Zeile 15-16). Anschließend werden die Keys - darunter sind die gemappten Parameter-Namen der übergebenen HashMap zu verstehen - ermittelt (Zeile 18) und über diesen iteriert (Zeile 20). Falls ein Key einem Mapping-Namen eines Parameters 2

64 5. IMPLEMENTIERUNG 61 entspricht (Zeile 23), wird der Parameter-Name sowie der aus der übergebenen HashMap ermittelte Parameter-Wert in die zu speichernde HashMap (parammap) übernommen (Zeile 24). Die HashMap parammap speichert also die Parameter und deren Werte, die bei einem Ressourcenaufruf an die Aufrufadresse angehängt werden. Falls durch die Mapping-Namen einer Ressource mindestens ein Parameter-Namen ermittelt werden könnte (Zeile 29) werden alle für einen Ressourcenaufruf relevanten Daten in einem Objekt gespeichert und der Rückgabeliste hinzugefügt. Die Objekte werden später in der Klasse WrapperRequest dazu verwendet einzelne Dienste aufzurufen. 1 p u b l i c HashMap reversemapping ( HashMap requestmappingparams, L i s t <Element > yellow_ srvs ) { 2 3 L i s t <RequestObject > requests = new A r r a y L i s t ( ) ; 4 5 for ( Element srv : yellow_srvs ) { 6 7 RequestObject requestobject = new RequestObject ( ) ; 8 HashMap parammap = new HashMap ( ) ; 9 10 S t r i n g providername = srv. getchildtext ( " p r o v i d e r " ) ; 11 S t r i n g servicename = srv. g e t A t t r i b u t e V a l u e ( "name" ) ; 12 L i s t <Element > params = srv. getchild ( " params " ). getchildren ( ) ; for( Element param : params ) { 15 S t r i n g yellow_mapping = param. g e t A t t r i b u t e V a l u e ( " mapping " ) ; 16 S t r i n g yellow_name = param. g e t A t t r i b u t e V a l u e ( "name" ) ; C o l l e c t i o n c = requestmappingparams. keyset ( ) ; 19 I t e r a t o r i t r = c. i t e r a t o r ( ) ; 20 while( i t r. hasnext ( ) ) { 21 Object key = i t r. next ( ) ; if ( yellow_mapping. equals ( key ) ) { 24 parammap. put ( yellow_name, requestmappingparams. get ( key ) ) ; 25 } 26 } 27 } if ( parammap. size ( ) > 0 ) { 30 requestobject. p r o v i d e r = providername ; 31 requestobject. s e r v i c e = servicename ; 32 requestobject. address = extractservic ep at h ( srv ) ; 33 requestobject. params = parammap ; requests. add ( requestobject ) ; 36 } 37 } 38 return requests ; 39 } Quellcode 5.1: Algorithmus zum Auffinden der Dienste Communicator Ein Packet der Softwarekomponente RESTator gewährleistet die Kommunikation mit den verschiedenen Diensten und ist in den Quellen der Implementierung unter ws.palladian.retrieval.wrapper.communicator zu finden. Eine Klasse dieses Packetes ist für den Aufruf eines Dienstes zuständig und leitet die ihr

65 5. IMPLEMENTIERUNG 62 übergebenen und notwendigen Informationen an den Service weiter. Diese Aufgabe übernimmt die Klasse ServiceRequest (siehe Klassendiagramm 5.2). Nach einem Dienstaufruf bekommt das instanziierte Objekt dieser Klasse eine Antwort von dem Dienst, die in dem Objekt ServiceResponse gespeichert wird. Diese beiden Klassen werden für einfache Dienstaufrufe eingesetzt und können auch ohne gesetzte Mappings verwendet werden. Für Aufrufe, deren Inhalte auf Informationen der Wrapper Page basieren, ist die Klasse WrapperRequest zuständig sein. Das instanziierte Objekt dieser Klasse bekommt als Eingabe die für eine bestimmte Kategorie und Aktion ermittelten Dienste und bereitet die notwendigen Informationen auf, die für Kommunikation mit den einzelnen Diensten erforderlich sind. Daraufhin wird für jeden Dienst ein ServiceRequest Objekt erstellt, das die Informationen an den eigentlichen Dienst weiterleitet und als Antwort ein ServiceResponse Objekt übermittelt. Diese Antworten werden von der Klasse WrapperRequest anhand der angegebenen Antwortparameter gefiltert und stehen dann zur weiteren Verarbeitung in einem WrapperResponse Objekt zur Verfügung. Weiterhin ist es bei einer derartigen Wrapperanfrage auch ermöglich, die von den Services gelieferte Gesamtantwort zurückzugeben. Abbildung 5.2: Klassen für die Kommunikation mit Diensten 5.3 Spezifikation der auszutauschenden Daten In diesem Abschnitt wird gezeigt was für Daten und auf welche Weise diese Daten zwischen einer Anwendung und der Klasse RESTatorAPI.java(Packet ws.palladian.retrieval.wrapper) ausgetauscht werden. In dem Kapitel 5.1 konnte man bereits sehen welche Methoden für Dienstaufrufe zur Verfügung stehen. Als Antwort wird ein in XML formatierter String zurückgegeben, dessen Format von der aufgerufenen Methode abhängt und entweder die Informationen der Dienste enthält

66 5. IMPLEMENTIERUNG 63 oder aber eine von der Softwarekomponente generierte Fehlernachricht. In den folgenden Unterabschnitten werden die auszutauschenden Daten spezifiziert Einzelner Dienstaufruf Durch dem einzelnen Dienstaufruf kann genau ein Service angesprochen werden. Als Ergebnis wird die Gesamtantwort des Dienstes als String übergeben. Folgende Daten werden der Methode servicerequest() übergeben: provider: der Name des Dienstanbieters (String). service: der Name des Dienstes (String). address: die Adresse des Dienstes, einschließlich der aufzurufenden Ressource (String). parameters: die Parameter und -werte für die Resource (HashMap). Eine erfolgreiche Antwort auf eine Anfrage ist in Quelltext 5.2 dargestellt. Das Element response beinhaltet die Antwort des Dienstes in XML und identifiziert den Dienst über die Attribute provider und service. <serviceresponse > <response p r o v i d e r=".... " s e r v i c e =".... " > / / diexml AntwortdesDienstes </ response> </ serviceresponse > Quellcode 5.2: Antwort einer Einzelanfrage Im Falle eines Fehlers gegenüber der Softwarekomponente gibt das Element error (siehe Quelltext 5.3) den Fehler an. Hierbei können die folgenden Fehler auftreten: der Provider ist nicht vorhanden. der Service ist nicht vorhanden. die Adresse ist dem Service nicht zugeordnet. ein HTTP-Fehler während der Kommunikation, geliefert durch java.net.urlconnection. Falls eine Fehlermeldung von dem Dienst empfangen wird, so wird diese in dem response-element aus dem Quelltext 5.2 dargestellt. <serviceresponse > <error > The s e r v i c e was not found i n the r e g i s t r y. Please choose an a v a i l a b l e s e r v i c e! </ error > </ serviceresponse > Quellcode 5.3: Fehlermeldung bei Einzelanfrage

67 5. IMPLEMENTIERUNG Aggregierte Dienstaufrufe Im Gegensatz zu dem einzelnen Dienstaufruf kann mit dem aggregierten eine Vielzahl an Diensten aufgerufen werden. Hierbei kommt es darauf an, dass die einzelnen Dienstressource und deren Parameter die gleichen Mappings haben. Die Antworten werden gebündelt und durch den in Quelltext 5.4 dargestellte XML-String als Ergebnis zurückgegegeben. Folgende Daten werden der Methode wrapperrequest() übergeben: category: eine Kategorie der WrapperPage (String). action: eine Aktion (Beschreibung einer Ressource) der WrappperPage (String). parameters: die gemappten Parameter und -werte für die Resourcen (HashMap). (fields:) optional, die ausgewählten gemappten Felder der Antwortnachricht (HashMap). Die Antworten der Dienste werden in dem Element responseitems aus dem Quelltext 5.4 dargestellt. Das response-element ist wie bei den einzelnen Dienstaufrufen (Abschnitt 5.3.1) aufgebaut, kann aber auch gefilterte Dienstantworten beinhalten. <wrapperresponse category = ".... " a c t i o n =".... " > <responseitems> <response p r o v i d e r=".... " s e r v i c e= ".... " > / / diexml AntwortdesDienstes </ response> </ responseitems> </ wrapperresponse > Quellcode 5.4: Antwort auf einen aggregierten Dienstaufruf Im Falle eines Fehlers gibt das Element error (siehe Quelltext 5.5) den Fehler an. Hierbei können die folgenden Fehler auftreten: die Kategorie ist nicht vorhanden. die Aktion ist nicht vorhanden. ein HTTP-Fehler während der Kommunikation, geliefert durch java.net.urlconnection (wird angegeben in dem response-element des Dienstes). Falls eine Fehlermeldung von einem Dienst empfangen wird, so wird diese in dem entsprechenden response-element aus dem Quelltext 5.4 dargestellt. <wrapperresponse category = ".... " a c t i o n =".... " > <error > The category was not found i n the r e g i s t r y. Please choose an a v a i l a b l e category! </ error > </ wrapperresponse > Quellcode 5.5: Fehlermeldung bei einem aggregierten Dienstaufruf Bei einer Anfrage, in der auch die gemappten Felder (fields) übergeben werden, um diese gefiltert auszugeben, werden die originalen Dienstfelder zurückgegeben. Dadurch wird allerdings die Relati-

68 5. IMPLEMENTIERUNG 65 on zu dem Elternelement des entsprechenden Fields aufgehoben. Es wäre also besser ein bestimmtes gemapptes Element, welches die gewünschten Information in Form weiterer Elemente enthält, auszuwählen und bei dem Aufruf zu übergeben. Dann kann, nachdem ein Element des Dienstes erhalten wurde, mit Hilfe der Übersichtseiten der Registry die Kindelemente und deren Information extrahiert werden. Beispielhafte Anfragen sind in der Klasse TestAPI.java des Packetes ws.palladian.retrieval.wrapper zu finden. Die Gesamtantworten und die gefilterten Antworten sind auf der Abgabe-CD in dem Testordner des Projektes zu finden. 5.4 Fazit In diesem Kapitel wurde die Implementierung der in Kapitel 4 vorgestellten Konzeption einer Softwarekomponente zur Kommunikation mit verschiedenen RESTful Web Services vorgestellt. Dabei konnte der Leser/in in Abschnitt 5.1 erfahren, wie die Zusammenarbeit der wichtigsten Klassen und Packete umgesetzt wurde. In Abschnitt 5.2 wurde anhand der Implementierung eines Algorithmus gezeigt, wie durch die Angabe von Mapping-Werten die eigentlichen Aufrufparameter bestimmt werden. Anschließend erfolgte die Darstellung derjenigen Klassen, welche für die Kommunikation, individuell als auch gruppiert, mit den Diensten verantwortlich sind. In Abschnitt 5.3 wurde schließlich gezeigt, wie die Funktionalität der Softwarekomponente programmtechnisch zu nutzen ist und welche aufrufbaren Funktionen für die Nutzung implementiert wurden. Die Implementierung auf der Grundlage des Konzeptes ergab als Endprodukt eine umfangreiche Anwendung mit der Dienste verwaltet, kategorisiert und angesprochen werden können. Durch die Benutzung der implementierten Softwarekomponente kann der Entwickler aus dem Anwendungsszenario aus Kapitel 1.3 nun auf einfache Weise auf verschiedene RESTful Web Services zugreifen und deren Anfrageergebnisse in einer aggregierten Antwort erhalten. Somit konnte gezeigt werden, dass das Problem der Aufgabenstellung lösbar und programmtechnisch umsetzbar ist. Das folgende Kapitel beschreibt die Benutzung der Softwarekomponente. Da die RESTator-API, also die programmtechnische Nutzung, bereits in Abschnitt 5.3 erklärt wurde, wird in dem nächsten Kapitel der Fokus auf der Nutzung der Softwarekomponente mittels des grafischen User Interfaces liegen.

69 6. BENUTZUNG 66 6 Benutzung 6.1 Erstellung der Beschreibungsdokumente Bevor die Registrierung eines Dienstes (siehe Kapitel 6.2.2) erfolgt, müssen die Beschreibungsdokumente des Dienstes erstellt werden. Es muss mindestens eine WADL-Datei erstellt werden, die die Dienstressourcen beschreibt. Die XSD-Dateien, die die Beschreibung der Antwortnachricht beinhalten, sind für die Registrierung zwar nicht erforderlich, sie sollten allerdings für die visuelle Darstellung und die Filterung der Antwort auch erstellt und registriert werden. In den folgenden Abschnitten wird erklärt, was bei der Erstellung der WADL-Dateien zu beachten ist. Falls die Antwort einer Ressource von einem Aufrufparameter abhängig ist, gibt es zwei Möglichkeiten dies auszudrücken. Bei der ersten Variante muss für den Typ des Parameters der Wert fixedvalue (6.1) gesetzt werden. Der fixe Wert des Parameters wird dann in dem Kindelement option übergeben. Dies ist zum Beispiel bei dem Eventdienst 5gig (Kategorie: Music Events) der Fall, der unter den mitgelieferten Diensten der Abgabe-CD zu finden ist. Es sei auch darauf hingewiesen, dass solch eine Parameter nicht auf den Übersichtsseiten der Registry erscheint. Somit können auch Usernamen und zugehörige Passwörter beschrieben werden, die dann nicht global sichtbar sind. Allgemein müssen die Aufrufparameter als Kinder von dem Element method angegeben werden. Die zweite Variante führt einen derartigen Parameter gar nicht mehr als Parameter eines request- Elementes an, sondern schreibt diesen direkt in den Pfad der Ressource(Quelltext 6.2). Bei dieser Variante muss das Fragezeichen, das die Ressource von den Parametern trennt, angegeben werden. Da der Parameter die Ressource betrifft, ist dieser dann auf den Übersichtsseiten der Registry zu sehen. Ein Beispiel für dieses Vorgehen ist der Suchdienst Bing (Kategorie: Search), der unter den mitgelieferten Diensten der Abgabe-CD zu finden ist. <param name= " method " type= " xra : fixedvalue " s t y l e =" query " > <option value=" a r t i s t. getevents " / > </ param> Quellcode 6.1: Fixer Typ für die Bestimmung der Antwortnachricht (Variante 1) <resource path="? xmltype =elementbased " >... </ resource > Quellcode 6.2: Fixer Typ für die Bestimmung der Antwortnachricht (Variante 2) Der Parameter für das Format der Antwortnachricht kann mit einer der zwei Varianten ausgedrückt werden, weil das Mappen dieses Parameters nicht besonders sinnvoll ist. Falls der Wert dieses Parameters modifiziert werden soll, ist es ratsam die erste Variante zu verwenden, wodurch die Werte

70 6. BENUTZUNG 67 der bereits gemappten Parameter erhalten bleibt. Da die Softwarekomponente automatisch erkennt ob XML oder JSON übergeben wurde, kann das Format auch weggelassen werden. Falls eine Ressource eines Dienste einen Ressourcenparameter enthält, muss dieser Parameter zuerst in dem Pfad der Ressource auftauchen und anschließend in einem param-element direkt unterhlb des resource-elementes beschrieben werden (siehe Quelltext 6.3). Das style-attribut des param-elementes hat dann den Wert template. Alle Parameter, egal ob Aufrufparameter oder Ressourcenparameter, müssen eindeutig beschreiben sein bzw. dürfen nicht doppelt vorhanden sein. <resource path=" a r t i c l e / search / { page } / { itemperpage } / { query } / " > <param name=" page " type= " xsd : i n t e g e r " s t y l e = " template " > <docxml : lang=" en " t i t l e = " The r e s u l t page to r e t u r n. " / > </param>... <method name="get" >... </ method> </ resource > Quellcode 6.3: Darstellung von Ressourcen-Parametern Weiterhin muss beachtet werden, dass eine WADL-Datei nur ein resources-element besitzen darf und die Typen (type-element) der Parameter gesetzt sein müssen. In dem nächsten Abschnitt wird beschrieben, was bei der Erstellung der XSD-Dateien zu beachten ist. Die Beschreibung der Antwortnachricht in einer XSD-Datei erfolgt hauptsächlich durch die Element element und complextype. Es ist zu beachten, dass alle complextype-elemente unterhalb des Wurzelelementes stehen müssen. Es sollte das Attribut typ des element-elementes gesetzt sein. Der Name eines element-elementes sollte keinen Namespace enthälten. Hilfreich bei der Beschreibung der Antwortnachricht sind die XSD-Dateien der mitgelieferten Diensten der Abgabe- CD. Diese können mit den konkreten Dienstantworten verglichen werden, die bei dem Testen bzw. der Evaluierung von den Diensten geliefert wurden Verlinkung von WADL und XSD Damit die Repräsentation eines method-elementes der WADL-Datei mit einer XSD-Datei verknüpft werden kann, muss zuerst das Wurzelelement application der WADL um ein Attribut erweitert werden. Angenommen dieses Attribut und dessen Wert sieht folgendermaßen aus: xmlns:rspa= article. Dann ist der Namespace rspa, der zum Beispiel auch in dem element-attribut des representation- Elementes aus der Abbildung 6.4 vorkommt, mit dem Wert article verknüpft. Dieser Wert muss auch in der zugehörigen XSD-Datei vorhanden sein. Das Wurzelelement schema der zugehörigen XSD-Datei muss dann das folgende Attribut enthalten: xmlns= article. Dieses Beispiel ist von dem Nachrichtendienst GolemIT (Kategorie: News) entnommen wurden und ist unter den mitgelieferten Diensten der Abgabe-CD enthalten.

71 6. BENUTZUNG 68 <method name="get" >... <response s t a t u s = " 200 " > < r e p r e s e n t a t i o n mediatype= " a p p l i c a t i o n / xml " element =" rspa : " / > </ response> </ method> Quellcode 6.4: Das Kind-Element representation 6.2 Benutzung der graphischen Benutzeroberfläche Das Programm-Menü Das Menü ermöglicht die Registrierung und Verwaltung von Diensten (siehe Abbildung 6.1). In dem Menüfeld Registry sind die Einträge Service und View zu sehen. Der Eintrag Service führt dabei zu den Funktionen, mit denen eine Dienstregistrierung, eine -modifizierung und das Mapping der Dienste vorgenommen werden kann. Der Eintrag View führt zu den vier Sichten der Registry der entwickelten Softwarekomponente, die die Details und die Kategorisierung der Dienste darstellen. In der folgenden Auflistung werden die Untereinträge der soeben genannten Einträge kurz beschrieben: Service>Registration: Öffnet das Fenster für die Registrierung eines Dienstes. Service>Modification: Öffnet das Fenster für die Modifikation eines Dienstes. Service>Mapping: Öffnet das Fenster, mit dem ein registrierter Dienst kategorisiert werden kann und das Mapping der Dienstparameter vorgenommen wird. View>White Page: Zeigt die registrierten Dienste und deren textuelle Beschreibung an. View>Green Page: Zeigt die Details der Dienstressourcen der jeweiligen Dienste an. View>Yellow Page: Zeigt die Dienstressourcen entsprechend der vorgenommenen Kategorisierung an. View>Wrapper Page: Zeigt die Dienstparameter entsprechend des vorgenommenen Mappings und der Kategorisierung an. Was bei der Registrierung, der Modifikation und dem Mapping der Dienste zu beachten ist, wird in den folgenden Abschnitten genauer erklärt. In Abschnitt wird erklärt welche Informationen den Übersichtseiten der Registry zu entnehmen sind. Ein weiteres Menüfeld, Help, stellt dem Benutzer/in eine textuelle Hilfe für den Umgang mit dem Programm bereit Registrierung eines Dienstes Das Formular für die Registrierung eines Dienstes ist über das Menüfeld Registry>Service>Registration zu erreichen. Es ist in vier Bereiche unterteilt, in denen Angaben zu dem Dienst ausgefüllt bzw. über-

72 6. BENUTZUNG 69 Abbildung 6.1: Das Menü der graphischen Benutzeroberfläche geben werden. In dem Bereich General Information muss der Name des dienstes und des Dienstanbieters angegeben werden. Eine textuelle Beschreibung des Dienstes ist optional. Der Bereich Authentication ermöglicht die Angabe von Zugriffsinformationen, die für die Kommunikation mit einem Dienst unter Umständen benötigt werden. In dem Feld Authentication Type muss angegeben werden, ob der Parameter, der den Entwicklerschlüssel enthält, in der Aufrufadresse oder im Header der Nachricht an den Dienst übergeben werden soll. Der Name des Parameters muss in dem Textfeld Parameter Name angegeben werden. Indem der Name des Dienstanbieters über das Auswahlfeld Developer Key ausgewählt wird, das die Zuordnung von Provider zu einem Entwicklerschlüssel herstellt, kann der Schlüssel gesetzt werden. Die Entscheidung darüber, ob eine Authentifizierung für die Nutzung eines Dienstes benötigt wird kann am unteren Ende des Bereichs gesetzt werden. Falls die Box off markiert ist, werden alle anderen Angaben der Authentifizierung ignoriert. Die Auswahl der Dienstbeschreibungen (WADL- und XSD-Dateien) erfolgt in dem Bereich Description Files. Durch Betätigung des Buttons Import Files öffnet sich ein Fenster, mit dem zu den Beschreibungsdateien navigiert werden kann. Nachdem die Dateien markiert und bestätigt wurden, werden diese unter dem Button angezeigt. Im Fall von fehlerhaften Angabe ist auch möglich eine Datei über den zugehörigen Button aus der Liste wieder zu entfernen. Mit dem Button Reset aus dem letzten Bereich des Formulares können alle Angaben zurückgesetzt werden. Der Abschluß der Registrierung und die damit verbundenen Übergabe der Informationen an die Registry wird durch Betätigung des Buttons Submit ausgelöst. Anschließend ist es möglich die Angaben über den Dienst auf der White Page und der Green Page der Registry einzusehen. Der Abbruch der Registrierung kann durch drücken des Schließen-Buttons erfolgen. Dieser Button befindet sich in dem Kopfteil des Registrierungsfensters und schließt dieses Modifizierung eines Dienstes Um die Angaben zu einem registrierten Dienst zu ändern, kann über das Menüfeld Registry>Service>Modification das entsprechende Formular angezeigt werde. Bei diesem Formular handelt es sich um das gleiche, das auch bei der Dienstregistrierung zu sehen war. Es können alle Angaben geändert werden. Durch das Hochladen von modifizierten Beschreibungsdokumenten ist es möglich die weiterhin bestehenden Angaben über die Kategorisierung des Dienstes bzw. der Ressourcen und das Mapping der Parameter zu übernehmen. Dies trifft für Ressourcen und Parameter zu, die nicht verändert wurden.

73 6. BENUTZUNG 70 Zum durchforsten der Dienste kann der Baum auf der linken Bildschirmseite verwendet werden. Dabei sind zuerst die Provider aufgelistet. Diese enthalten schließlich die einzelnen Dienste. Ein Klick auf einen Dienst generiert das entsprechende Formular. Der Abbruch einer Dienstmodifizierung kann durch Auswahl eines anderen Dienstes erfolgen oder durch drücken des Schließen-Buttons des Fensters ausgelöst werden. Falls ein Parameter direkt in dem Pfad der Ressource (siehe Quelltext 6.2) angegeben wurde und der Wert dieses Parameters geändert wird, führt dieses Verhalten dazu, dass sich die Ressource ändert. Durch die Änderung wird also eine neue Ressource registriert und die alte gelöscht. Das hat auch zur Folge, dass sich die Mapping-Werte nicht erhalten lassen. Weiterhin ist zu beachten, dass bei der Modifikation stets die gesamte Anzahl der zu registrierenden bzw. modifizierenden Beschreibungsdokumente angegegeben werden muss. Das bedeutet, dass eine XSD-Datei die nicht verändert wurde, auch wieder angegeben werden muss Mapping eines Dienstes Über das Menüfeld Registry>Service>Mapping wird der Benutzer/in zu der Mappingansicht geführt. Diese Ansicht besteht aus einem Baum (linke Seite), der in der ersten Ebene die Dienstanbieter darstellt. Die jeweiligen Dienste sind dann auf der zweiten Ebene als Kinder eines Providers zu finden. Die Ressourcenansicht eines Dienstes wird auf der rechten Bildschirmseite generiert, wenn man einen Dienst mit der rechten Maustaste ausgewählt und daraufhin der Eintrag mapping angeklickt wird. Die Ressourcenansicht beinhaltet die Bereiche General Information, Category Mapping und abhängig von der Ressourcenanzahl eines Dienstes verschiedene Resource Mapping Bereiche. General Information zeigt den Name und den Provider eines Dienstes an. In dem Bereich Category Mapping muss für den Dienst eine Kategorie angegeben werden. Falls es sich dabei um eine Unterkategorie handelt, muss der gesamte Pfad zu dieser Kategorie angegeben werden und die einzelnen Kategorien durch einen Slash getrennt werden (z.b. Search/Tiere ). Der Bereich stellt jeweils eine Ressource des Dienstes dar. Feste Werte hierbei sind die URL und die Methode für die Ressource. In dem Feld Action wird die Ressource auf einen Namen gemappt. Da die Dienstantwort für die Ressource verschiedene Informationen enthalten kann, ist es möglich mehrere Werte anzugeben. Diese müssen dann durch ein Komma getrennt werden (z.b. Question, Answer ). Auf der Yellow Page der Registry würde diese Dienstressource dann unter Search/Tiere/Question und Search/Tiere/Answer zu finden sein (siehe auch ). Weiterhin werden in dem Bereich Resource Mapping (siehe Abbildung 6.2) jeweils eine Tabelle für die Parameter des Request und der Response angezeigt. Für die Requestparameter kann in der Spalte Mapping (im Programm gelb markiert) jeweils ein Wert eingetragen werden. Die Spalte Typ stellt den Typ des jeweiligen Parameters dar, der aus der WADL-Datei gewonnen wird. Die Spalte Required gibt mit dem Wert true an, dass dieser Parameter bei einem Dienstaufruf unbedingt übergeben werden muss. In der Spalte Description befinden sich die textuellen Beschreibungen für die jeweiligen Parameter, die aus der XSD-Datei der Antwortbeschreibung ermittelt wurden. Da die Struktur der Antwortnachricht (siehe Response in Abbildung 6.2) hierarchisch sein kann, ist rechts neben der Tabelle für die Response die Struktur der Antwort dargestellt.

74 6. BENUTZUNG 71 Abbildung 6.2: Mapping einer Ressource

75 6. BENUTZUNG 72 Auch hier kann in der Spalte Mapping jeweils ein Wert für einen Parameter eingetragen werden. Weiterhin ist folgendes bei dem Mapping zu beachten. Bei dem Mapping der Kategorie, der Aktionen und den Feldern sollten keine Sonderzeichen angegeben werden. Am besten man beschränkt sich auf Buchstaben. Falls ähnliche Parameter gemappt werden sollen, die sich allerdings in dem Format der übergebenen Werte unterscheiden, müssen diese eindeutig gemappt werden. Eindeutig bedeuted dann, dass diese bei keiner anderen Dienstressourcen dieser Kategorie vorkommen dürfen. Somit kann auch bei einem Wrapperaufruf gezielt ein Wert eines Parameters einer bestimmten Dienstressource an den Dienst übergeben werden Löschen eines Dienstes Ein Dienst kann auf der White Page (Registry>View>White Page) der Registry gelöscht werden. Dazu muss man mit der rechten Maustaste auf einen Dienst der linke Bildschirmseite klicken und anschließend Delete Service mit der linken Maustaste auswählen Die Sichten der Registry In diesem Abschnitt werden die Übersichtseiten der Registry vorgestellt und gezeigt welche Informationen daraus gewonnen werden können White Page Die White Page zeigt die Provider und deren Dienste an und ist über das Menüfeld Registry>View>White Page zu erreichen. Zu jedem Dienst werden die textuellen Beschreibungen dargestellt Green Page Auch auf der Green Page erfolgt die Einteilung der Dienste nach deren Providern. Zu erreichen ist sie über das Menüfeld Registry>View>Green Page. Im Gegensatz zu der White Page werden hier die Ressourcen durch deren URL, Request-Parameter und Response-Parameter beschreiben Yellow Page Die Yellow Page ist über das Menüfeld Registry>View>Yellow Page erreichbar (siehe Abbildung 6.3). Auf der linken Seite der Yellow Page befindet sich der Baum zur Navigation durch die kategorisierten Dienste (siehe auch Abbildung 6.2). Die Elemente des Baumes sind in verschiedenen Farben dargestellt. Damit wird die unterschiedliche Bedeutung der Elemente zum ausdruck gebracht. Ein gelbes Element steht für eine Kategorie, welche in dem Category Mapping Bereich bei dem Mappen eines Dienstes eingetragen wurde (siehe Abbildung 6.2). Ein orangenes Element steht für eine Aktion, die auf einer Ressource ausgeführt wird und die bei dem Mappen einer Dienstressource angegeben wurde (siehe Abbildung Resource Mapping). Eine Kategorie kann mehrere Kategorien

76 6. BENUTZUNG 73 Abbildung 6.3: Die Yellow Page der Registry

77 6. BENUTZUNG 74 und Action-Elemente besitzen und ein Action-Element kann wiederum über mehrere Dienstressourcen von verschiedenen Diensten verfügen. Die Dienstressourcen werden durch ein grünes Element repräsentiert und enthalten keine weiteren Unterelemente. Ein grünes Element des Navigationsbaumes steht somit für eine Ressource eines Dienstes. Auf der rechten Bildschirmseite wird für jede Ressource der Provider, die Aufruf-Url sowie die Request- und Response-Parameter angezeigt. Um die Beschreibung einer Kategorie bzw. einer Aktion hinzuzufügen klickt man mit der rechten Maustaste auf das entsprechende Element des Baumes und wählt Modify Description. Anschließend wird ein Dialog angezeigt, in den man die Beschreibung einträgt und bestätigt. Es ist möglich, dass eine Kategorie bzw. eine Aktion keine Kinderelemente besitzt. Dies ist der Fall, falls für eine bestimmte Aktion alle zuvor kategorisierten Dienste gelöscht werden. Es bleibt somit die Aktion bestehen. Durch einen Klick mit der rechten Maustaste auf eine leere Aktion und der anschließenden Auswahl des Menüeintrages Delete Action wird ein Dialogfenster angezeigt, das durch eine positive Bestätigung die ausgewählte Aktion löscht. Auf ähnliche Weise kann beim Löschen einer Kategorie vorgegangen werden Wrapper Page Über das Menüfeld Registry>View>Wrapper Page gelangt man zu der Wrapper Page der Registry. Auf dieser Übersichtsseite wird in erster Linie von den eigentlichen Diensten abstrahiert - es wird der Pfad der Kategorie und die Aktionen einer Kategorie angezeigt - und vorrangig nur die gemappten Dienstparameter dargestellt (siehe auch 4.4). In der Ansicht werden je Aktion folgende Informationen angezeigt: Description: Die Beschreibung der Aktion. Show Relationship: Durch klicken dieses Links werden die Request- und Responsetabellen um die Spalte Services erweitert. Diese Spalte zeigt die konkreten Dienste an (der Provider wird in den Klammern dargestellt), die einen Parameter der gleichen Aktion auf den gleichen Mappingwert gesetzt haben (siehe Abbildung 6.4). Hide Relationship: Durch klicken dieses Links wird die Spalte Services aus den Tabellen entfernt (siehe Abbildung 6.5). Participating Services: Listet die an dieser Aktion beteiligten Dienste und Provider auf. Request Mapping Parameters: Zeigt die gemappten Request-Parameter einer Aktion an, die die gleiche Bedeutung haben. Weiterhin wird der Typ des Mapping-Parameter dargestellt. Die gargestellten Mapping-Parameter sind mit den eigentlichen Dienstparametern verbunden. Die Anzahl der an einem Parameter beteiligten Dienste wird in der Spalte Amount of Services angezeigt und informiert darüber, wie viele Dienstressourcen einer Aktion diesen Mapping- Parameter für einen Aufruf anbieten. Response Mapping Parameters: Ähnliches Vorgehen wie bei den Request Mapping Parameters.

78 6. BENUTZUNG 75 Abbildung 6.4: Die Wrapper Page ohne Relation zu den Diensten Abbildung 6.5: Die Wrapper Page mit Relation zu den Diensten

79 6. BENUTZUNG Methoden des Application Programming Interface Die programm-technische Benutzung der Softwarekomponente wurde bereits ausführlich in Kapitel 5.3 beschrieben. Generell ist zu sagen, dass der Benutzer die URL von den Übersichtsseiten entnehmen muss, um einen einzelnen Dienstaufruf zu ermöglichen. Bei Wrapperanfragen muss die Kategorie und die Aktion übergeben werden. Im Prinzip ist es möglich die Parameter für jede Dienstressource einer Kategorie einzeln zu übergeben. Dazu müssen die gemappten Werte eines Parameters für eine Aktion einer Kategorie eindeutig bestimmt werden. Dies ist dann von Vorteil falls zwei Ressourcen von der Bedeutung her die gleichen Aufrufparameter haben, aber unterschiedliche Werte übergeben werden müssen. Siehe auch Abschnitt 6.2. Weiterhin ist noch zu ergänzen, dass im Falle einer Übergabe von Ressourcen-Parametern (stehen in der URL vor dem Fragezeichen) diese in geschweiften Klammern übergeben werden müssen (z.b parameters.put( {page}, 2 ) für die Übergabe des Parameterwertes zu der Auslieferung der zweiten Antwortseiten einer Dienstantwort).

80 7. EVALUIERUNG 77 7 Evaluierung In diesem Kapitel soll geklärt werden, inwieweit das Anwendungsszenario aus der Einleitung dieser Arbeit mit der entwickelten Softwarekomponente umsetzbar ist. Weiterhin wird das Verhalten der Softwarekomponente gegenüber aggregierten Dienstaufrufen untersucht. Hierbei soll ein Auswertung darüber erfolgen, wie effektiv die Softwarekomponente durch das Mapping die möglichen Aufrufparameter der Dienste einer Kategorie erfassen kann und inwieweit eine Filterung von den jeweiligen Dienstantworten durchgeführt werden kann. Für die Evaluierung wurden insgesamt 15 Dienste, die zusammen über 21 Resourcen verfügen, registriert. Bei diesen Diensten handelt es sich RESTful Web Service, die entweder die Anwortnachricht in XML oder JSON versenden. Diese Dienste sind auf der Abgabe-CD zu finden. Die Evaluierung wurde von einer Person, dem Verfassser dieser Arbeit, durchgeführt. 7.1 Umsetzung des Anwendungsszenarios Für die Bewertung der Umsetzung des Beispielszenarios wurden drei Dienste aus der Kategorie Websuche ausgewählt. Dabei handelt es sich um die Dienste Bing 1, BOSStranslator 2 und DuckduckGo 3. Es wurde jeweils eine Ressource des Dienstes beschreiben. Für zwei der Dienste wurde ein Parameter in dem Pfad einer Ressource angegeben. Ein Dienst verfügt über Ressourcen-Parameter, die in der URL vor dem Fragezeichen angeführt werden. Die Dienste mit ihren Beschreibungsdokumenten (WADL, XSD) und den Angaben zu dem Dienst (Name, Provider), sowie die Angaben zur Authentifizierung, wurden erfolgreich registriert. Nach der Registrierung konnten die Dienste auf der White Page und der Green Page betrachtet werden. Die Green Page ermöglichte das Vergleichen der Anfrage- und Antwortparameter der jeweiligen Ressourcen. Anschließend wurde das Mapping der Dienste durchgeführt. Für alle drei Dienste wurde die Kategorie Search festgelegt, für die Aktion der jeweiligen Ressource das Schlagwort web gesetzt und die Parameter und Felder der Nachrichten entsprechend ihrer Bedeutung gemappt. Nach dem Mapping der Dienste wurden über die RESTatorAPI (RESTatorAPI.java) zwei Wrapperanfragen an die Kategorie/Aktion Search/web gestellt. Der ersten Anfrage wurden dabei die gemappten Aufrufparametern ohne die gemappten Antwortfelder übergeben. Diese Anfrage lieferte für alle drei Dienste die entsprechende Gesamtantwort der jeweiligen Dienstressource in dem Format, welches

81 7. EVALUIERUNG 78 in Kapitel spezifiziert wurde. Der zweiten Anfrage wurden neben den gemappten Aufrufparametern auch die ausgewählten gemappten Antwortfelder übergeben. Diese Anfrage lieferte für alle drei Dienste die entsprechenden originalen Nachrichtenelemente der jeweiligen Dienstantwort. Die Anfragen und die Antworten sind auf der Abgabe-CD zu finden. Als nächstes wurde die Modifizierung für alle drei Dienste durchgeführt. Dabei wurde pro registrierter Dienstressource ein nicht gemappter Anfrageparameter aus der WADL-Datei und ein Antwortfeld aus der XSD-Datei entfernt. Jedem Dienst wurde eine neue Ressource hinzugefügt. Auf der Green Page waren anschließend die bereits vorhandenene Mappingwerte weiterhin vertreten, die gelöschten Parameter bzw. Felder waren gelöscht und es war jeweils eine neue Ressource vorhanden. Abschließend wurden alle Suchdienste gelöscht. Damit waren sie auf den Übersichtsseiten der Registry nicht mehr ersichtlich. 7.2 Analyse der Dienstressourcen Das Ziel der Analyse der Dienstressourcen ist die Ermittlung der Schnittmenge von Aufrufparametern und Antwortfelder von denjenigen Diensten, deren Ressourcen zu einer bestimmten Aktion einer Kategorie gehören. Diese gruppierten Ressourcen der Dienste sollen im Endeffekt über die Wrapperanfrage der RESTatorAPI angesprochen werden. Die 15 ausgewählten Dienste können in 5 Kategorien unterteilt werden. Da die Mehrzahl der ausgewählten Dienste eine Ressource beschreibt bzw. für unterschiedliche Dienstanfragen die gleiche Ressource präsentiert wird bzw. eine Ressource auf keine weitere der gleichen Kategorie zutrifft, haben vier von fünf Kategorien eine Aktion. Die Kategorie Music verfügt über 3 Aktion, weil bei den zugehörigen Diensten auch entsprechend viele Ressourcen abrufbar sind. Die folgenden Diagramme beziehen sich auf die Anfrageparameter und Antwortfelder der Ressourcen der registrierten Dienste. Die Anzahl der Paramter wurde von den jeweiligen Webseiten der Dienste entnommen. Die Felder wurden teilweise von den Webseiten und teilweise durch die Analyse der konkreten Dienstantworten ermittelt Analyse der Anfrageparameter Bei der Analyse der Anfrageparameter wurden die Parameter für den API-Key und das Format nicht mitgezählt. Der API-Key wird bereits bei der Registrierung angegeben und fällt damit aus dem Mapping heraus. Den meisten Diensten braucht kein Format übergeben zu werden, diese liefern dann entweder die Nachricht in XML oder JSON aus. Das Diagramm 7.1 stellt die Anzahl der gesamten Anfrageparameter von drei Dienstressourcen für die Kategorie Question&Answer dar. Auf der rechten Seite ist die Aktion beschrieben, auf die die jeweiligen Ressourcen gemappt wurden. In diesem Fall lautet die Aktion question_answer. Dadurch, dass die Ressource des Dienstes Chacha nur zwei Parameter benötigt kann die Schnittmenge gleicher Parameter aller drei Dienstressourcen nicht größer als zwei sein. Eine Schnittmengenbestimmung gleicher Parameter der Kategorie Question&Answer ist in dem Dia-

82 7. EVALUIERUNG 79 Abbildung 7.1: Gesamtanzahl an Parametern (Kategorie: Question&Answer) gramm 7.2 zu sehen. Hierbei fällt besonders auf, dass die Dienste Yahoo Answers und Trueknowledge nur über einen gemeinsamen Parameter verfügen, obwohl diese die meisten Parameter haben. Neben der Schnittmenge alle drei Dienstressourcen wurden auch jeweils zwei Dienste betrachtet. Alle Schnittmengen haben den gleichen Parameter für die Übergabe der Frage und die Schnittmenge B beinhaltet noch einen Parameter für die Anzahl der zu übergebenden Resultate. Die Werte der Parameter sind die gleichen. Abbildung 7.2: Schnittmenge der Parameter (Kategorie: Question&Answer) Die Kombination der Dienstressourcen für das Diagramm 7.2: A: ChaCha 4, Yahoo Answers 5, TrueKnowledge 6 B: ChaCha, Yahoo Answers C: ChaCha, TrueKnowledge

83 7. EVALUIERUNG 80 D: Yahoo Answers, TrueKnowledge Das Diagramm 7.3 stellt die Anzahl der gesamten Anfrageparameter von drei Dienstressourcen für die Kategorie Search dar, die auf die Aktion web gemappt wurden. Der Dienst BOSS Translator verfügt mit acht Parametern über die meisten Aufrufparameter. Abbildung 7.3: Gesamtanzahl an Parametern (Kategorie: Search) Die Anzahl gleicher Parameter für die Kategorie Search ist in dem Diagramm 7.4 dargestellt. Die Schnittmenge zwischen den Dienstressourcen fällt ähnlich aus wie bei der Kategorie Question&Answer. Alle Schnittmenge verfügen über einen Parameter für den Suchterm und die Schnittmenge B enthält weiterhin einen Parameter für das zu suchende Dokumentenformat (pdf, etc.). Der Wert des Suchterms ist jeweils URL kodierter String der bei allen Ressourcen gleich behandelt wird. Das Dokumentenformat kann sich allerdings unterscheiden. Abbildung 7.4: Schnittmenge der Parameter (Kategorie: Search) Die Kombination der Dienstressourcen für das Diagramm 7.4: A: Bing 7, BOSS Translator 8, DuckDuckGo

84 7. EVALUIERUNG 81 B: Bing, BOSS Translator C: Bing, DuckDuckGo D: BOSS Translator, DuckDuckGo Das Diagramm 7.5 stellt die Anzahl der gesamten Anfrageparameter von drei Dienstressourcen für die Kategorie News dar, die auf die Aktion article gemappt wurden. Das heißt, dass durch diese Aktion bestimmte Nachrichtenartikel einer Ressource abgefragt werden können. Da der Dienst Guardian UK über 25 Parameter verfügt ist die Differenz zu dem Dienst Golem - mit nur drei Parametern - verhältnismäßig hoch. Abbildung 7.5: Gesamtanzahl an Parametern (Kategorie: News) Eine Schnittmengenbestimmung gleicher Parameter der Kategorie News ist in dem Diagramm 7.6 zu sehen. Weil die drei Parameter des Dienstes Golem auch in den anderen beiden Diensten vorkommen, fallen die Schnittmengen A bis C gleich aus. Wie zu sehen ist, ist die Schnittmenge D relativ hoch. Das bedeutet konkret, dass theoretisch mehr als die Hälfte der Parameter von dem Dienst USA Today mit den Parametern des Dienstes Guardian UK auf die gleichen Werte gemappt werden können. Praktisch würde einer der Parameter für jeden der beiden Dienste individuell gemappt werden müssen. Denn der Wert des Parameters Section, der die Nachrichtensektion einer Ressource bestimmt, fällt dienstabhängig aus. Die Kombination der Dienstressourcen für das Diagramm 7.6: A: Golem 10, Guardian UK 11, USA Today 12 B: Golem, Guardian UK C: Golem, USA Today D: Guardian UK, USA Today Das Diagramm 7.7 stellt die Anzahl der gesamten Anfrageparameter von neun Dienstressourcen für die Kategorie Music dar. Dabei wurden für jeden Dienst drei Ressourcen ausgwählt, die mit den Ressourcen der anderen Dienste in ähnlichen Kategorien eingeordnet werden konnten. Da der Dienst

85 7. EVALUIERUNG 82 Abbildung 7.6: Schnittmenge der Parameter (Kategorie: News) Spotify für jede Ressource nur zwei Parameter anbietet, kann die Schnittmenge der Parameter für alle Aktionen auch nicht höher als zwei betragen. Der Dienst emusic fällt dadurch auf, dass er die größte Anzahl an Parametern für alle drei Aktionen anbietet. Abbildung 7.7: Gesamtanzahl an Parametern (Kategorie: Music) Die Anzahl gleicher Parameter für die Kategorie Search ist in dem Diagramm 7.8 zu sehen. Hierbei fällt auf, dass die Parameter des Dienstes Spotify für die Aktion album und track auch in den anderen Dienstressourcen vorkommt. Weiterhin ist zu sehen, dass die Parameter für die Aktion album des Dienstes LastFM vollständig in der entsprechenden Ressource von dem Dienst emusic enthalten sind. Die Wertebereiche der Parameter Aktionen können gleich behandelt werden. Die Kombination der Dienstressourcen für das Diagramm 7.8: A: LastFM 13, emusic 14, Spotify

86 7. EVALUIERUNG 83 Abbildung 7.8: Schnittmenge der Parameter (Kategorie: Music) B: LastFM, emusic C: LastFM, Spotify D: emusic, Spotify Das Diagramm 7.9 stellt die Anzahl der gesamten Anfrageparameter von drei Dienstressourcen für die Kategorie MusicEvents dar, die auf die Aktion event gemappt wurden. Mit der Gesamtparameteranzahl von sechs und fünf, fallen die Dienste BandsInTown und Jambase sehr ähnlich aus. Abbildung 7.9: Gesamtanzahl an Parametern (Kategorie: MusicEvents) Eine Schnittmengenbestimmung gleicher Parameter der Kategorie MusicEvents ist in dem Diagramm 7.10 visualisiert. Man sieht, dass alle Ressourcen drei gleiche Parameter haben. Es kann allerdings nur der Parameter artist für alle drei Ressourcen gleich behandelt werden. Die Örtlichkeit des Events wird einmal durch das Land bestimmt, dann durch die Stadt und den Staat bzw. das Land und ein drittes mal durch einen amerikanischen Zipcode. Um das Datum festzulegen werden auch drei verschiedene Formate verwendet. Dadurch müssen diese Parameter der Dienstaufrufe einzeln und eindeutig gemappt werden. Bei der Schnittmenge C kann noch der Radius, in dem ein Event stattfinden kann,

87 7. EVALUIERUNG 84 gleich behandelt werden. Abbildung 7.10: Schnittmenge der Parameter (Kategorie: MusicEvents) Die Kombination der Dienstressourcen für das Diagramm 7.10: A: BandsInTown 16, 5Gig 17, Jambase 18 B: BandsInTown, 5Gig C: BandsInTown, Jambase D: 5Gig, Jambase Analyse der Antwortfelder Bei der Analyse der Antwortparameter wurde auf die gleiche Weise vorgegangen wie bei der Analyse der Anfrageparameter. Die Anzahl der Antwortfelder einer Ressource setzt sich aus den Elementen zusammen, die in Form von Attributen bzw. Textinhalten sinnvolle Informationen liefern. Wichtig ist auch zu erwähnen, dass die Struktur der Antwortnachricht von dem Infromationsgehalt der Ressource abhängt. Somit ist es auch möglich, dass weniger Informationen geliefert werden, als auf den Providerseiten angegeben werden. Die Diagramme dieser Analyse sind im Anhang A zu finden. 7.3 Auswertung der Resultate Von den zuvor ermittelten Schnittmengen der Dienstressourcen wird in diesem Abschnitt festgehalten, wieviele der enthaltenen Parameter, abhängig von den Parameterwerten, tatsächlich bei mehreren Dienstressourcen verwendet werden können. Hierbei wurde ermittelt, für welche gleichen Parameter gemeinsame Mappingwerte über drei bzw. zwei Dienstressourcen möglich sind. In der Tabelle 7.1 wird in der Spalte Schnittmenge der Parameter die Anzahl der gleichen Para

88 7. EVALUIERUNG 85 meter für die verschiedenen Kombinationen der Dienste dargestellt. Die Spalte Mapping für Aktion gibt an, wieviele der gemeinsamen Parameter die gleichen Parameterwerte besitzen. Das Verhältnis dieser beiden Werte wird in der Spalte Verhältnis dargestellt und berechnet sich folgendermaßen: Mapping für Aktion V erhältnis = Schnittmenge der Parameter. Der Wert Gesamt stellt den Durchschnitt der Verhälnisse dar. Für die Kategorie Question&Answer können somit alle Parameter einer Schnittmenge mit den gleichen Werten belegt werden und somit auch gleich gemappt werden. Die Tabellen 7.2 bis 7.7 stellen dieses Verhältnis für die anderen Kategorien dar. Schnittmenge der Mapping für Verhältnis Parameter Aktion A B C D Gesamt: 1 Tabelle 7.1: Auswertung des Mappings der Aufrufparametern (Kategorie: Question&Answer Schnittmenge der Mapping für Verhältnis Parameter Aktion A B 2 1 1/2 C D Gesamt: 7/8 Tabelle 7.2: Auswertung des Mappings der Aufrufparametern (Kategorie: Search) Schnittmenge der Mapping für Verhältnis Parameter Aktion A B C D 7 6 6/7 Gesamt: 27/28 Tabelle 7.3: Auswertung des Mappings der Aufrufparametern (Kategorie: News) Der Durchschnitt der Gesamtverhältnisse der sieben Kategorien ergibt ca. 0,89. Das zeigt, dass durch das Mapping die aggregierten Dienstaufrufe mit verhältnismäßig wenigen Angaben zu den Parametern durchgeführt werden können. Denn ein Mapping kann in diesem Fall relativ viele Dienstparameter abbilden. Eine derartige Berechnung wurde für die Antwortfelder bzw. die Filterung der Antwortnachricht nach bestimmten Elementen nicht angestellt. Das hat den folgenden Grund, dass bei einer Filterung einzelner Felder der Antwort die Relation zu anderen Antwortfeldern verloren gehen kann und somit die Informationen nicht mehr brauchbar wären (siehe auch Kapitel 5.3.2). Sinnvoll wäre also nur, indem man nach einem Element filtert oder ein Elternelement auswählt, welches spezifische Informationen

89 7. EVALUIERUNG 86 Schnittmenge der Mapping für Verhältnis Parameter Aktion A B C D Gesamt: 1 Tabelle 7.4: Auswertung des Mappings der Aufrufparametern (Kategorie: Music/artist) Schnittmenge der Mapping für Verhältnis Parameter Aktion A B C D Gesamt: 1 Tabelle 7.5: Auswertung des Mappings der Aufrufparametern (Kategorie: Music/album) Schnittmenge der Mapping für Verhältnis Parameter Aktion A B C D Gesamt: 1 Tabelle 7.6: Auswertung des Mappings der Aufrufparametern (Kategorie: Music/track) Schnittmenge der Mapping für Verhältnis Parameter Aktion A 3 1 1/3 B 3 1 1/3 C 4 2 1/2 D 3 1 1/3 Gesamt: 3/8 Tabelle 7.7: Auswertung des Mappings der Aufrufparametern (Kategorie: MusicEvents)

90 7. EVALUIERUNG 87 enthält. Eine Ungenauigkeit ergibt sich durch die nicht berücksichtigten Attribute der Antwortfelder. Falls die Möglichkeit besteht zwischen JSON und XML zu wählen, sollte deshalb JSON bevorzugt werden. Dieses Format wird intern in ein XML Format umgewandelt, das keine Attribute enthält, wodurch alle Felder auslesbar sind. 7.4 Zusammenfassung In diesem Kapitel wurde gezeigt, dass das eingangs vorgestellte Anwendungsszenario auf die entwickelte Softwarekomponente anwendbar ist. In dem Abschnitt 7.2 wurden die Anfrageparameter der Dienstressourcen und deren Schnittmengen analysiert und auf die Antwortparameter eingegangen. Eine Auswertung des Mappings erfolgte in Abschnitt 7.3.

91 8. ZUSAMMENFASSUNG UND AUSBLICK 88 8 Zusammenfassung und Ausblick In dieser Arbeit wurde anfangs die Grundlage zu verteilten Systemen und deren Realisierungsmöglichkeiten vorgestellt. Dadurch sollte der interessierte Leser in die Thematik eingeführt werden und es sollten die notwendigen Grundlagen, die für das Verständnis der Zusammenhänge des Konzeptes nötig sind, auf diese Weise vermittelt werden. In Kapitel 3 wurden kronkrete Architekturen zur Umsetzung von Web Services vorgestellt. Die Prinzipien der UDDI aus Kapitel konnte in das Konzept übernommen werden. Darauffolgend wurden in Kapitel 3.3 Ansätze für RESTful Web Servie Architekturen vorgestellt. Die dabei zum Einsatz kommenden Sprachen wurden miteinander verglichen. Die Beschreibungssprache WADL hat sich hierbei als am nützlichsten erwiesen und wurde in das Konzept dieser Arbeit übernommen. In dem Konzept wurden schließlich die Anforderungen definiert und die wesentlichen Bestandteile der Softwarekomponente vorgestellt. Das Kapitel hat die grundlegenden und weitere ausgewählte Bestandteile der implementierten Softwarekomponente vorgestellt. Am Ende des Kapitels wurde die Spezifikation der Datenaustauschschnittstelle vorgestellt. Im darauffolgenden Kapitel wurde vorgestellt, wie die Dienstbeschreibungsdokumente erstellt werden und wie das graphische User Interface für die Registrierung und das Mapping von Diensten genutzt werden kann. In dem Kapitel 7 erfolgte schließlich die Evaluierung des umgesetzten Konzeptes. Dabei wurde gezeigt, dass die Schritte des Anwendungsszenarions mit der entwickelten Softwarekomponente durchgeführt werden können. Weiterhin erfolgte die Analyse der Aufrufparameter und der Antwortparameter. Die dabei ermittelten Schnittmengen von Parametern einer bestimmten Aktion (Ressourcenmapping) wurden für die Bestimmung der Genauigkeit, mit der ein Mapping über mehrere Dienstressourcen vollzogen werden kann, herangezogen. Um die Informationsgewinnung effektiver zu gestalten könnte die Softwarelogik um Regeln erweitert werden, die sich darum kümmern, dass bestimmte Antwortinformation zu einer weiteren Anfrage geleitet werden. Dies wäre sinnvoll wenn eine Dienstressource spezifische Identifikationsnummern bei der Anfrage entgegennimmt, die sie in einer anderen Ressource bereitstellt. Weiterhin könnte eine Erweiterung durch die Verarbeitung von semantischen Dienstinformationen eingebracht werden, die Ontologien wie RDF oder WSMO-Lite verarbeiten kann. Damit würde sich der Aufwand für das manuelle Mapping erheblich reduzieren. Eine weitere Möglichkeit der Erweiterung besteht darin, ein Monitoring-Mechanismus einzuführen, mit dem die Dienstaufrufe überwacht werden können. Bei Diensten, die eine Bezahlung vorraussetzen, könnte man somit verausschauend die Entscheidung treffen, ob weitere Dienstaufrufe getätigt werden sollen.

92 Literaturverzeichnis 89 Literaturverzeichnis [ab] [ABG02] EVIWARE SOFTWARE AB: soapui. [letzter Zugriff: ] AUSTIN, Daniel ; BARBIR, Abbie ; GARG, Sharad: Web Services Architecture Requirements - W3C Working Draft 29 April April [letzter Zugriff: ] [ACKM04] ALONSO, Gustavo ; CASATI, Fabio ; KUNO, Harumi ; MACHIRAJU, Vijay: Web Services: Concepts, Archtectures and Applications. Springer-Verlag Berlin Heidelberg, 2004 [BB08] BATTLE, Robert ; BENSON, Edward: Bridging the semantic Web and Web 2.0 with Representational State Transfer (REST). Web Semantics: Science, Services and Agents on the World Wide Web 6, S [Bra05] BRAY, Tim: Simple Message Exchange Descriptor (SMEX-D). Mai [letzter Zugriff: ] [Bur09] BURKE, Bill: RESTful Java with JAX-RS. O Reilly, 2009 [EF03] [Erl08] EBERHART, Andreas ; FISCHER, Stefan: Web Services: Grundlagen und praktische Umsetzung mit J2EE und.net. Carl Hanser Verlag München Wien, 2003 ERL, Thomas: SOA: Entwurfsprinzipien für serviceorientierte Architektur. Addison- Wesley Verlag, 2008 [Fie00] FIELDING, Roy T. Architectural Styles and the Design of Network-based Software Architectures. Doctoral dissertation, University of California, Irvine [Fla08] FLANDERS, Jon: RESTful.NET. O Reilly, 2008 [Gai02] [HH10] [KGV08] GAILEY, Jeannine H. Sending Files, Attachments, and SOAP Messages Via Direct Internet Message Encapsulation HEUSER, Oliver ; HOLUBEK, Andreas: Java Web Services in der Praxis: Realisierung einer SOA mit WSIT, Metro und Policies. dpunkt.verlag GmbH, 2010 KOPECKÝ, Jacek ; GOMADAM, Karthik ; VITVAR, Tomas: hrests: an HTML Microformat for Describing RESTful Web Services. IEEE/WIC/ACM International Conference

93 Literaturverzeichnis 90 on Web Intelligence and Intelligent Agent Technology, 2008 [LG10] LANTHALER, Markus ; GÜTL, Christian: Towards a RESTful Service Ecosystem - Perspectives and Challenges. 4th IEEE International Conference on Digital Ecosystems and Technologies, 2010 [Man08] MANDEL, Lawrence: Describe REST Web services with WSDL Mai [letzter Zugriff: ] [MBS10] MANGLER, Jürgen ; BERAN, P. P. ; SCHIKUTA, Erich. On the Origin of Services - Using RIDDL for Description, Evolution and Composition of RESTful Services. 10th IEEE/ACM International Conference on Cluster, Cloud and Grid Computing [Mel07] MELZER, Ingo: Service-orientierte Architekturen mit Web Services: Konzepte- Standards-Praxis. 2. Spektrum Akademischer Verlag, 2007 [MK09] MARINOS, Alexandros ; KRAUSE, Paul: What, not How: A generative approach to service composition. IEEE Conference on Digital Ecosystems Technologies, 2009 [MKP09] [oas] [Orc] [Pau09a] [Pau09b] [Pre02] MALESHKOVA, Maria ; KOPECKÝ, Jacek ; PEDRINACI, Carlos: Adapting SAWSDL for Semantic Annotations of RESTful Services. OTM 2009 Workshops, LNCS5872, S OASIS UDDI Specification TC. ORCHARD, Dave: Web Description Language (WDL). [letzter Zugriff: ] PAUTASSO, Cesare: Composing RESTful services with JOpera. International Conference on Software Composition 2009, S PAUTASSO, Cesare: RESTful Web service composition with BPEL for REST. Data Knowledge Engineering, S PRESCOD, Paul: Web Resource Description Language ( Word-dul ). August [letzter Zugriff: ] [resa] ActiveVOS ] [letzter Zugriff: [resb] [resc] Apache CXF. note=[letzter Zugriff: ] Apache ODE - User Guide. [letzter Zugriff: ]

94 Literaturverzeichnis 91 [resd] [rese] [resf] [res07] [res08] [Ric] [Sal02] [SGL07] Jersey. [letzter Zugriff: ] WADL Stylesheets. [letzter Zugriff: ] Web Application Description Language. [letzter Zugriff: ] Web Services Description Language (WSDL) Version 2.0 Part 2: Adjuncts. Juni [letzter Zugriff: ] Documents associated with Semantics of Business Vocabulary and Business Rules (SBVR), Version Januar [letzter Zugriff: ] RICHARDSON, Leonard: WADL Programmierbibliothek. [letzter Zugriff: ] SALZ, Rich. Transporting Binary Data in SOAP SHETH, Amit P. ; GOMADAM, Karthik ; LATHEM, Jon: SA-REST:Semantically Interoperable and Easier-to-Use Services and Mashups. IEEE Computer Society, 2007 [SS07] SCHILL, Alexander ; SPRINGER, Thomas: Vereilte Systeme. Springer-Verlag Berlin Heidelberg, 2007 [Ste] [Ste07] [Til09] STEINER, Thomas: RestDescribe. [letzter Zugriff: ] STEINER, Thomas: Automatic Multi Language Program Library Generation for REST APIs. Juni [letzter Zugriff: ] TILKOV, Stefan: REST und HTTP: Einsatz der Architektur des Web für Integrationsszenarien. dpunkt.verlag, 2009 [TMK + 08] TAKASE, Toshiro ; MAKINO, Satoshi ; KAWANAKA, Shinya ; UENO, Ken ; FERRIS, Christopher ; RYMAN, Arthur: Definition Languages for RESTful Web Services: WADL vs. WSDL 2.0. Tokyo Research Laboratory, IBM Research, 2008 [WAD] WADL, Glassfish: wadl2java. [letzter Zugriff: ]

95 Abbildungsverzeichnis 92 Abbildungsverzeichnis 2.1 Architektur eines RPC-Systems [SS07] Entfernter Methodenaufruf mit RMI [SS07] Dienst im Überblick [HH10] Prozesse und Dienste in einer SOA [HH10] Grundlegender Ablauf in einer SOA Elemente der WSDL-Beschreibung Komponenten der RESTator Architektur Registrierung und Mapping eines Services Vereinfachte Darstellung der implementierten Systemarchitektur Klassen für die Kommunikation mit Diensten Das Menü der graphischen Benutzeroberfläche Mapping einer Ressource Die Yellow Page der Registry Die Wrapper Page ohne Relation zu den Diensten Die Wrapper Page mit Relation zu den Diensten Gesamtanzahl an Parametern (Kategorie: Question&Answer) Schnittmenge der Parameter (Kategorie: Question&Answer) Gesamtanzahl an Parametern (Kategorie: Search) Schnittmenge der Parameter (Kategorie: Search) Gesamtanzahl an Parametern (Kategorie: News) Schnittmenge der Parameter (Kategorie: News) Gesamtanzahl an Parametern (Kategorie: Music) Schnittmenge der Parameter (Kategorie: Music) Gesamtanzahl an Parametern (Kategorie: MusicEvents) Schnittmenge der Parameter (Kategorie: MusicEvents) A.1 Gesamtanzahl an Feldern (Kategorie: Question&Answer) A.2 Schnittmenge der Felder (Kategorie: Question&Answer) A.3 Gesamtanzahl an Feldern (Kategorie: WebSearch) A.4 Schnittmenge der Felder (Kategorie: WebSearch) A.5 Gesamtanzahl an Feldern (Kategorie: News) A.6 Schnittmenge der Felder (Kategorie: News) A.7 Gesamtanzahl an Feldern (Kategorie: Music)

96 Abbildungsverzeichnis 93 A.8 Schnittmenge der Felder (Kategorie: Music) A.9 Gesamtanzahl an Feldern (Kategorie: MusicEvents) A.10 Schnittmenge der Felder (Kategorie: MusicEvents)

97 Tabellenverzeichnis 94 Tabellenverzeichnis 2.1 Eigenschaften der HTTP-Methoden [Til09] Auswertung des Mappings der Aufrufparametern (Kategorie: Question&Answer Auswertung des Mappings der Aufrufparametern (Kategorie: Search) Auswertung des Mappings der Aufrufparametern (Kategorie: News) Auswertung des Mappings der Aufrufparametern (Kategorie: Music/artist) Auswertung des Mappings der Aufrufparametern (Kategorie: Music/album) Auswertung des Mappings der Aufrufparametern (Kategorie: Music/track) Auswertung des Mappings der Aufrufparametern (Kategorie: MusicEvents)

98 ANHANG A. ANHANG A - ANALYSE DER ANTWORTFELDER 95 A Anhang A - Analyse der Antwortfelder Abbildung A.1: Gesamtanzahl an Feldern (Kategorie: Question&Answer) Abbildung A.2: Schnittmenge der Felder (Kategorie: Question&Answer)

99 ANHANG A. ANHANG A - ANALYSE DER ANTWORTFELDER 96 Abbildung A.3: Gesamtanzahl an Feldern (Kategorie: WebSearch) Abbildung A.4: Schnittmenge der Felder (Kategorie: WebSearch) Abbildung A.5: Gesamtanzahl an Feldern (Kategorie: News)

100 ANHANG A. ANHANG A - ANALYSE DER ANTWORTFELDER 97 Abbildung A.6: Schnittmenge der Felder (Kategorie: News) Abbildung A.7: Gesamtanzahl an Feldern (Kategorie: Music) Abbildung A.8: Schnittmenge der Felder (Kategorie: Music)

101 ANHANG A. ANHANG A - ANALYSE DER ANTWORTFELDER 98 Abbildung A.9: Gesamtanzahl an Feldern (Kategorie: MusicEvents) Abbildung A.10: Schnittmenge der Felder (Kategorie: MusicEvents)