Web Services Architecture: Stakeholder s Perspective

Transkript

1 Web Services and Semantic Web Web Services Architecture: Stakeholder s Perspective Verfasser Roman Rädle Roman.Raedle@uni-konstanz.de Universität Konstanz Abgabe

2 2 Web Services Architecture: Stakeholder s Perspective Abstrakt Inhaltlich werden verschiedene Perspektiven der Web Service Architecture durchleuchtet. Jede dieser Perspektiven stellt eine kohärente Sicht der Architektur dar. Die Hauptperspektiven beinhalten Service Oriented Architecture (SOA), Web Service Technologies und ihre Anwendung, Web Service Discovery, Semantics, Sicherheit, Zuverlässigkeit, Management und Interaktion. Abstract - (English) This presentation examines the web services architecture from various perspectives, each perspective representing one coherent view of the architecture. The main perspectives include the Service Oriented Architecture (SOA), web services technologies and usage, web service discovery, semantics, security, reliability, management, and interaction.

3 Inhaltsverzeichnis 1 Motivation Verteilte Systeme Web Services und Architectural Style SOA - Service Oriented Architecture Technologien Grundlagen für den Datenaustausch - XML SOAP - Service Oriented Architecture Protocol Web Services Description Language - WSDL Verwendung eines Web Services UDDI - Verwaltung von Web Services Discovery Approach Index Approach Peer-to-Peer - P2P Semantics Security Integrität der Transaktionen Zuverlässigkeit Message Reliability Service Reliability Management

4 4 Web Services Architecture: Stakeholder s Perspective 1 Motivation Mit Aufkommen des World Wide Web wurde ein Plattform geschaffen die es ermöglicht auf einfachste Art und Weise auf Information zuzugreifen. Heutzutage ist die Verwendung weit verbreitet und es gibt keine Altersbeschränkung. Sowohl die junge als auch die ältere Generation sind sehr gut damit vertraut und haben die anfänglichen Hemmungen abgebaut. Aufgrund dieser Popularität wuchs das System schon in den ersten Jahren und erstreckt sich heutzutage in allen erdenklichen Kategorien. Schon bald waren erste Suchmaschinen auf dem Markt, denn ohne ein solches Hilfsinstrument war es sehr schwer an die gewünschten Informationen zu gelangen. 2 Verteilte Systeme Dies können sowohl unterschiedliche oder getrennte Systeme sein als auch unterschiedliche und getrennte Systeme sein die zusammen arbeiten. Sie arbeiten zumeist nicht auf der selben Umgebung und müssen deshalb über Hardware und/oder Software Protokoll Stacks arbeiten. Dabei sind sie meist nicht so verlässlich und arbeiten weniger schnell wie jene, welche direkt Code aufrufen oder mit Shared Memory arbeiten (unvorhersehbare Latenzzeit bei Remote Zugriff). Entwickler müssen sich zusätzlich Gedanken um konkurrierende Zugriffe und die Möglichkeit auftretender Fehler kümmern. Dennoch kann es zu unvorhersehbaren Latenzzeiten bei Remote Access kommen. Das ist ein Trade-Off der dennoch in Kauf genommen wird. 3 Web Services und Architectural Style Nicht häufig treten bei Distributed Object Systemen Probleme auf die zu unvorhersehbaren Latenzzeiten und zu Unzuverlässigkeit der Systeme führen können. Zurückzuführen ist dies auf den darunterliegenden Transport Layer. [IM07] Weitere Mängel treten Aufgrund des fehlenden Shared Memory zwischen Caller und Object (bspw. entfernter Methodenaufruf mittels RPC 1 ) auf. Teilweise gescheiterte Szenarien und/oder ausgeführte Operationen bergen Nachteile. Zuletzt muss ein gleichzeitiger Zugriff auf entfernte Resourcen effektiv und effizient verwaltet werden. Von all diesen Faktoren hängt es ab, ob ein Distributed Object System in COM/CORBA 2 oder Web Services Technologie implementiert ist. Die Tabelle 1 zeigt einen kurzen Vergleich von CORBA und SOAP/Web Services 3. Item Web Services CORBA Protocol SOAP, HTTP, XML, Schema IIOP, GIOP Location identifiers URLs IORs, URLs Interface spec WSDL IDL Naming, directory UDDI Naming Service, Interface Repository, Trader service Tabelle 1. Vergleich CORBA / Web Services Dennoch kann man kann CORBA und SOAP nicht wirklich vergleichen. SOAP ist ein Teil des Protokolls des RPC Mechanismus. Vielmehr müsste man IIOP 4 und SOAP vergleichen, denn IIOP ist ein Protokoll für CORBA. Im Normalfall sind SOA und Web Services speziell für Anwendungen angebracht, die über ein Netzwerk (z.b. das Internet) agieren sollen. An Spots, an denen: 1 Remote Procedure Call 2 COM/CORBA - Common Object Request Broker Architecture 3 SOAP - Service Oriented Architecture Protocol. Darauf wird später ausführlich eingegangen. 4 General Inter-ORB Protocol

5 Web Services Architecture: Stakeholder s Perspective 5 Zuverlässigkeit und Geschwindigkeit nicht garantiert werden müssen, nicht die Möglichkeit besteht, ein Deployment bereitzustellen, welches Requesters 5 und Providers 6 gleichzeitig upgraded, eine vorhandene Anwendung für eine Verwendung ins Netzwerk aufbereitet werden soll und als Web Services gewrapped werden kann, werden Web Services eingesetzt. 4 SOA - Service Oriented Architecture Service Oriented Architecture, ist eine Form der Distributed System Architecture. Sie ist charakterisiert durch eine abstrakte logische Sicht, welche auf aktuelle Programme, Datenbanken, Geschäftsprozesse gerichtet ist. Typischerweise wird dabei eine geschäfts-level Operation 7 ausgeführt. Diese Operationen bedürfen einer weiteren Basis, den sogenannten Messages, welche zwischen Provider Agents und Requester Agents ausgetauscht werden. Wichtig dabei ist, dass diese Nachrichten keine Information über Programmiersprache, Prozessstruktur oder Datenbankstruktur besitzen. Damit solche Messages interdisziplinär verwendet werden können bedürfen sie einer strikten Vereinbarung. Der sogenannten Description. Sie ist in einer maschinen-verarbeitbaren Sprache beschrieben. Desweiteren sind dort nur öffentliche und wichtige Details festgehalten, welche für die Benutzung des Services, beispielsweise die Web Services Semantics, wichtig sind. Die Anzahl möglicher Operationen wird sehr klein gehalten, dafür können sie aber relativ groß ausfallen und überproportional komplex sein. Sie beschreiben somit eine typische Granularität einer SOA. Zumeist tendiert die Anwendung von Service Oriented Architectures auf netzwerkorientierte Systeme. Der Verlust an Performance wird hierbei durch Plattformunabhängigkeit mehr als ausgeglichen und kann mittels plattformunabhängigen und standardisierten Formaten, wie z.b. XML, erreicht werden 4.1 Technologien Web Service Architecture verbindet vielschichtige und verknüpft bereits existierende und bewährte Technologien zu einer mächtigen Einheit. Die Abbildung 1 zeigt die Schichten-Architektur, den sogenannten Web Services Architecture Stack. Er beinhaltet SOAP und dessen Erweiterungen für Reliability, Correlation, Transactions und darüber aufgebaut die Descriptions und dann die eigentlichen Prozesse. Als Basis dient ein Communications Layer. Wie auch schon die 7 OSI Layer, so ist dieser Stack als vielschichtige Architektur aufgebaut. Dies erlaubt einen Austausch eines Layers ohne die anderen Schichten ebenfalls austauschen zu müssen oder gar neu zu implementieren. Die Web Service Security und das Web Service Management umschließen das System und stützen optimal diese Einheit. 4.2 Grundlagen für den Datenaustausch - XML XML steht für Extensible Markup Language und für Flexibilität, Austauschbarkeit und Universalität. Man findet XML quasi überall, es ist das Format der Wahl für Dokumente in den verschiedensten Anwendungen, von Konfigurationsdateien bis zu Nachrichten zwischen Computern. [SL06] Es ist sehr flexibel einsetzbar, um Information geeignet zu verpacken und kann dennoch menschenlesbar gestaltet werden. Darüberhinaus ist es leicht erweiterbar, man bedenke bspw., dass das XML Schema selbst auf XML aufgebaut ist und keiner weiteren Syntax bedarf. 5 Der Requester beschreibt einen Actor, welcher Daten oder Information anfrägt 6 Der Provider bietet einen Service an, welcher Informationen bereitstellt oder manipuliert. 7 Auf einem entfernten Rechner wird bspw. eine Operation ausgeführt, welche sowohl atomare Änderungen an Datenbanksätzen vornimmt und aufbauend auf diesen das berechnete Ergebnis zurückliefert.

6 6 Web Services Architecture: Stakeholder s Perspective Abbildung 1. Technologie [WSA]

7 Web Services Architecture: Stakeholder s Perspective SOAP - Service Oriented Architecture Protocol Dieses Protokoll bietet ein standardisiertes und erweiterbares Framework um XML Messages zu packen und auszutauschen. Es bietet desweiteren die Möglichkeit externe Quellen zu referenzieren wird aber meist nur in Headern verwendet. Das große Plus von SOAP Messages ist: Sie können über eine weite Vielfalt von Netzwerk Protokollen versendet werden. Hierbei ist zu beachten, dass SOAP nicht als Transport Layer des 7 Layer OSI eingestuft werden darf, sondern eine eigene Position innerhalb des Web Services Architecture Stack einnimmt. Der SOAP Request POST /InStock HTTP/1.1 Host: Content-Type: application/soap+xml; charset=utf-8 Content-Length: nnn <?xml version="1.0"?> <soap:envelope xmlns:soap=" soap:encodingstyle=" <soap:body xmlns:m=" <m:getstockprice> <m:stockname>ibm</m:stockname> </m:getstockprice> </soap:body> </soap:envelope> Eine SOAP Response HTTP/ OK Content-Type: application/soap+xml; charset=utf-8 Content-Length: nnn <?xml version="1.0"?> <soap:envelope xmlns:soap=" soap:encodingstyle=" <soap:body xmlns:m=" <m:getstockpriceresponse> <m:price>34.5</m:price> </m:getstockpriceresponse> </soap:body> </soap:envelope> 4.4 Web Services Description Language - WSDL Web Services Definitions können auf jede Programmiersprache, jede Plattform, jedes Objektmodell oder jedes Messaging System abgebildet werden. Diese liegt als XML-Spezifikation und ist zur Beschreibung von Netzwerkdiensten zum Austausch von Nachrichten einsetzbar. Folgender Ausschnitt zeigt den ungefähren Aufbau der WSDL. Eine genauere Spezifikation bekommt man auf der Webseite des W3C Konsortiums oder auf W3Schools syntax.asp

8 8 Web Services Architecture: Stakeholder s Perspective <wsdl:definitions name="nmtoken"? targetnamespace="uri"> <import namespace="uri" location="uri"/> <wsdl:documentation... />? <wsdl:types>? <wsdl:documentation... />? <xsd:schema... /> </wsdl:types> <wsdl:message name="ncname"> <wsdl:documentation... /> <part name="ncname" element="qname"? type="qname"?/> </wsdl:message> <wsdl:porttype name="ncname"> <wsdl:documentation... /> <wsdl:operation name="ncname"> <wsdl:documentation... /> <wsdl:input message="qname"> <wsdl:documentation... /> </wsdl:input> <wsdl:output message="qname"> <wsdl:documentation... /> </wsdl:output> <wsdl:fault name="ncname" message="qname"> <wsdl:documentation... /> </wsdl:fault> </wsdl:operation> </wsdl:porttype> <wsdl:servicetype name="ncname"> <wsdl:porttype name="qname"/> </wsdl:servicetype>... </wsdl:service> </wsdl:definitions> 4.5 Verwendung eines Web Services Anhand eines kleinen Beispiel-Szenarios wird nun beschrieben, wie ein Web Service angesprochen werden kann, um folgend mit diesem zu kommunizieren und die gewünschten Daten auszutauschen. Als Basis für dieses Szenario dient die Abbildung 2 und nachfolgende Erläuterung. 1. Die Requester und Provider Entities lernen sich kennen. (a) Im Normalfall ist der Requester der Initiator. i. Er hat die Adresse des Provider Agents direkt von der Provider Entity. ii. Er bekommt die Adresse evtl. von einem Discovery Service. (b) In den anderen Fällen ist der Provider Agent der Initiator um Nachrichten auszutauschen. (Wie dies geschieht ist nicht festgelegt und irrelevant für diese Architektur) 2. Die Requester Entity und die Provider Entity stimmen der Service Description und den Service Semantics zu, welche die Interaktion zwischen beiden leiten. (a) Dies muss nicht undbedingt heißen, dass sie kommunizieren. (b) Sie müssen nur das gleiche Verständnis der Service Description und der Service Semantics haben. i. Requester und Provider kommunizieren direkt und einigen sich. ii. Provider bietet Service Description und Service Semantics bereits im Voraus an als take-itor-leave-it. iii. Standard welcher von einer Organisation definiert und für Provider und Requester bereitgestellt wird.

9 Web Services Architecture: Stakeholder s Perspective 9 Abbildung 2. Geläufige Vorgehensweise zum Aufbau eines Web Service [WSA]

10 10 Web Services Architecture: Stakeholder s Perspective iv. Requester bietet mittels take-it-or-leave-it Ansatz Providern an diese zu verwenden. 3. Service Description und Service Semantics sind Input oder bereits implementiert in Requester und Provider Agents. Es ist nicht weiter spezifiziert, wie genau das geschehen muss. z.b. könnte ein Agent hard-coded sein und bestimmte Service Descriptions und Service Semantics implementieren. oder ein Agent könnte genereller implementiert sein und den Input dynamisch verwerten. 4. Requester Agent und Provider Agent tauschen Nachrichten im Namen ihrer Besitzer aus. 5 UDDI - Verwaltung von Web Services Der Zugriff und die Verwendung eines Web Services ist nun bekannt. Aber woher bekommt letztenendes der Anwender die Information über einen Web Service? Über ein Suchmaschine wie etwa Google? Über DNS 9 Zugriff? Geregelt wird dies wieder über ein gemeinsames Format, auch UDDI[UDDI] 10 genannt. Wie das alles funktionieren kann wird im Folgenden erläutert. [FM07] 5.1 Discovery Approach Eine zentral verwaltete Bibliothek erlaubt es Providern sich zu registrieren und darin aufgenommen zu werden. Der eigentliche Verwaltungsakt wird vom Besitzer dieser Bibliothek vorgenommen. Er entscheidet, wer Zugang bekommt und Informationen einfügen und/oder ändern darf. Auch entscheidet er, welche Informationen in der Bibliothek verwaltet werden. Die UDDI ist meist als Beispiel für den Registry Ansatz oder den Index Approach 11 anzusehen. 5.2 Index Approach Der Index Approach kann als eine Art Broschüre eingestuft werden. Die manuelle Zusammenstellung der Information über Web Services bildet eben dieses Resultat. Ein Provider hat keinen Einfluß auf die Veröffentlichung seines Web Services und nimmt bis auf die Freigabe im Web eine passive Rolle ein. Jedem ist es erlaubt einen solchen Index zu erstellen. So können beispielsweise Spiders eingesetzt werden um diese freigegebenen Services zu finden und nachträglich zu einem Index zusammenzustellen. Großer Nachteil hierbei ist es natürlich, dass diese Information veraltet sein kann. Abhilfe leisten Pointer zu authorativen Informationen, die es erlauben eine Verifikation vor der Verwendung auszuführen. Der Hauptunterschied zum Registry Approach ist die Verwaltung und Steuerung der Informationen. Wer verwaltet was? Wie werden Service Descriptions gesucht? Im Registry Approach ist es der Besitzer der dies kontrolliert. Bei Indexen - jeder kann einen Index erzeugen - wird mittels Marktforschung herausgefunden, welche Index populär werden könnten. Google ein viel zitiertes Beispiel hierfür. 5.3 Peer-to-Peer - P2P Im Vergleich zum Registry Approach basiert diese Bibliothek auf einem dezentralen Netzwerk. Ein Web Service ist ein Knoten in diesem Netzwerk von Peers. Anfragen werden über das ganze Netzwerk verbreitet und liefern zum Schluß die Antwort, in Form eines Web Services, an den Client zurück. Dies bedarf einer Terminierungs-Regel, um völlige Überbelastung des Systems bei Nichtauffinden der gewünschten Information auszuschließen - simples Beispiel hierfür ist ein Hop-Count. Der große Vorteil ist, es gibt keinen Single Point of Failure, da es dezentral verwaltet ist und ein Ausfall eines Knotens kompensiert werden kann. Dennoch ist es keine Garantie, dass eine Anfrage über das gesamte Netzwerk ausgebreitet wird. Performance-Einbußen werden für eine hohe Verfügbarkeit in Kauf genommen. 9 Domain Name System 10 Universal Description Discovery and Integration 11 Index Approach wird nachfolgend erklärt.

11 Web Services Architecture: Stakeholder s Perspective 11 6 Semantics Es werden eine Vielzahl an Voraussetzungen benötigt um Computer Programme miteinander kommunizieren zu lassen. So muss eine physische Verbindung zwischen Beiden bestehen, damit Daten von einem zum anderen Prozess gelangen können. Im Vorfeld muss ein Abkommen über das Datenaustauschformat existieren. Desweiteren muss strikt festgelegt sein, welchen Inhalt die Daten beschreiben - so könnte der Inhalt eine HTML Seite oder ein Bankkonto-Saldo repräsentieren. Zuletzt muss es ein Abkommen geben, das besagt, wie die gesendeten Daten behandelt werden. Es würde keinen Sinn machen eine Bestellung als Kontostands-Anfrage zu behandeln. 7 Security Mit Aufkommen jedes Systems gibt es Sicherheitslücken, die von findigen Geschäftemachern oder kriminellen Gestalten genutzt werden um an geheime oder vertrauliche Informationen zu gelangen. So beispielsweise, das aus dem Online-Banking bekannte Phishing 12. Message Alteration Angreifer versuchen, die in der Nachricht enthaltene Information zu löschen, ändern oder schädliche Information anzufügen. Angreifer versuchen Anhänge der Nachricht zu löschen, ändern oder weitere anzufügen. Dies kann sowohl den Header - als auch den Body - Part einer Nachricht betreffen. Confidentiality - Man-in-the-middle Als Mann in der Mitte versucht sich der Angreifer Zugang zu vertraulicher Information zu beschaffen. Beispielsweise Kreditkartennummern, etc. Denial of Service (DoS) Hält berechtigte Benutzer davon ab, einen Service zu nutzen. Bekanntes Beispiel hierfür war die Attacke gegen einen größeren Suchmaschinen-Konzern.... diese Liste kann beinahe endlos weitergeführt werden und ständig werden neue Sicherheitslücken entdeckt und geschlossen. Ohne Mechanismen die den Anwender vor solchen Attacken schützen wäre ein solcher Service heutzutage nicht mehr denkbar. So gibt es Authentifizierungs- und Authorisierungsmechanismen, die vorab den Provider gegebenüber dem Requester authentifizieren (gleiches gilt auch umgekehrt) und nur gewollte Resourcen den Beteiligten freigeben (Authorisierung). Es gibt auch Verfahren, die es erlauben nachzuprüfen, ob Daten während der Übertragung verändert wurden. Mittels Signaturen kann sichergestellt werden, dass diese Informationen auch nur von den gewünschten Parteien geöffnet werden können. 8 Integrität der Transaktionen Nicht nur Angriffe von Dritten verursachen Probleme und bedürfen weiterer Sicherheit. Integrität der Transaktionen ist hier ein Schlüsselwort. Operationen, die mit Hilfe eines Web Services angestoßen wurden, können plötzlich oder abrupt mit einem Fehler beenden. Was geschieht nun mit den bereits verarbeiteten Werten? Werden die bereits ausgeführten Berechnungen nicht rückgängig gemacht, so kann das gesamte System in einen inkonsistenten Zustand geraten. Transaktionen, wie sie beispielsweise aus Datenbanksystemen bekannt sind, sichern dagegen ab. So werden nicht atomare Berechnungen - mehrere Berechnungen bilden eine Operation - verfolgt und bei einem Fehler automatisch zurückgerollt. Der Benutzer oder auch Requester wird in Kentniss gesetzt und kann selbst wiederum geeignet reagieren. Somit bleibt das System jederzeit in einem konsistenten Zustand. 12 Als Phishing werden Versuche genannt, über gefälschte WWW-Adressen an Daten eines Internet-Benutzers zu gelangen

12 12 Web Services Architecture: Stakeholder s Perspective 9 Zuverlässigkeit Nicht nur Syntax Errors oder schlecht geschriebener Code sind Basis für unzählig auftretende Fehler. Auch Netzwerkverbindungen, die unterbrochen sind oder Server die während einer Übertragung aus- und angeschaltet werden, sind häufige Fehlerquellen. Der Mensch selbst kann durch unsachgemäße Bedienung Fehler herbeirufen - Eingabe falscher oder inkorrekter Daten. 9.1 Message Reliability Um auf der Ebene von Nachrichten deren Gütigkeit festzustellen hat der Sender die Option zu eruieren, ob die Nachricht vom Empfänger empfangen wurde und dies auch nur ein Mal geschah. Das gibt dem Sender die Freiheit, die Nachricht nochmal zu senden sollte er einen Fehler festgestellt haben. Techniken wie byte-counts, check-sums, digital signatures erlauben es zu überprüfen inwieweit die Nachricht richtig empfangen wurde. XML selbst bietet durch Validierungsverfahren (valide gegen ein Schema, well-formed XML Struktur) weitere Unterstützung. Die Web Service Architecture selbst verfügt nicht über die Möglichkeit einer Message Reliability, gibt aber in der aktuellen Spezifikation [WSA] Anleitung wie dies erreicht werden kann. 9.2 Service Reliability Transaktions-Management erlaubt es die Zuverlässigkeit des Services zu steigern. Wie weiter oben bereits beschrieben können nur teilweise ausgeführte Operationen wieder zurückgerollt werden und halten das gesamte System in einem konsistenten Zustand. 10 Management Ein Web Service der Management Tools zur Verfügung stellt wird als manageable eingestuft. Werkzeuge wie Monitoring 13, Controlling 14 und Reporting der Service Qualität und Nutzung fallen darunter. Als bekanntes Beispiel bietet der Application Server JBoss TM [JBoss] eine Konsole an, mit der sich Web Services administrieren lassen und unter Zuhilfenahme von Widgets, sogenannten managed beans (kurz: MBean), verwalten lässt. 13 Monitoring ist ein Überbegriff für alle Arten der unmittelbaren systematischen Erfassung, Beobachtung oder Überwachung eines Vorgangs oder Prozesses 14 Controlling (von englisch: to control für steuern, regeln ) ist ein umfassendes Steuerungs- und Koordinationskonzept zur Unterstützung des Web Services

13 Web Services Architecture: Stakeholder s Perspective 13 References [WSA] W3C: WSA - Web Service Architecture - W3C Working Group Note 11 February (2008) [SOAP] W3C: SOAP - Service Oriented Architecture - Version (2008) [UDDI] UDDI - Universal Description Discovery and Integration (2008) [JBoss] JBoss Application Server (2008) [SL06] Saint Laurent, S.: XML kurz und gut. O Reilly; Auflage: 3. A. (Januar 2006) [IM07] Melter, I.: Service-orientierte Architekturen mit Web Services. Spektrum Akademischer Verlag; Auflage: 2. A. (April 2007) [FM07] Meyer, F.: UDDI - Universal Description Discovery and Integration: Grundlagen und Datenstrukturen