Anwendungsbeispiele einer XML Web Service basierten Service-orientierten Architektur

Diplomarbeit Anwendungsbeispiele einer XML Web Service basierten Service-orientierten Architektur Mathias Habich Matrikelnummer: 205110 Wintersemester 2004/05 Fachbereich Digitale Medien Studiengang Medieninformatik Fachhochschule Furtwangen Betreuer: Prof. Wilhelm Walter Prof. Dr. Christoph Reich

Eidesstattliche Erklärung Ich erkläre hiermit an Eides statt, dass ich die vorliegende Diplomarbeit eigenständig und ohne unzulässige fremde Hilfe angefertigt habe. Alle verwendeten Quellen und Hilfsmittel sind angegeben. Östringen, den 25.02.05 Mathias Habich

Abstrakt zur Diplomarbeit-Thesis WS 2004/2005 03.05.2004 Thema: SOA Service Oriented Architecture vorgelegt von: Mathias Habich (MN 205110) Einführung in die Thematik: Das stetige Voranschreiten der Softwareentwicklung, angefangen bei der sequenziellen Programmierung bis hin zu den heute üblichen objektorientierten Techniken, ist vor allem den stetig wachsenden Ansprüchen an die Software und der Unzufriedenheit der Entwickler mit den ihnen gegebenen Werkzeugen zuzuschreiben. Die immer größer werdende Komplexität des Softwareentwurfs zwang die Softwareentwickler dazu neue Sprachen, Techniken und Architekturen einzuführen. Ziel war/ist es eine Software zu entwickeln, die übersichtlich aufgebaut ist, stabil und sicher läuft, Flexibilität gegenüber Änderungen beweist, möglichst keine Redundanzen aufweist und dadurch einen hohen Grad an Wiederverwendung erreicht. Objektorientierte Techniken erlauben es uns komponentenbasierte Systeme zu entwerfen, die zwischen den einzelnen Modulen eine sog. lose Kopplung und eine hohe Kohäsion derer Schnittstellen aufweisen und dadurch oben genannte Kriterien an eine gute Software erfüllen. Moderne Softwareentwürfe haben aber noch eine andere Hürde zu nehmen. Sie müssen mit der Komplexität und Vielfalt moderner Infrastrukturen zu Recht kommen, d.h., dass ein Softwareentwurf zum Teil verschiedenste Systeme, Plattformen, Protokolle, Geräte, etc. berücksichtigen muss. Die Service-orientierte Architektur (kurz SOA) bietet unter der Zuhilfenahme der sog. Webservices einen Lösungsansatz für genau dieses Problem. Sämtliche Aufrufe an Dienste werden von einer entkoppelten Abstraktionsschicht dem Service-Layer behandelt. Die Trennung dieses Service-Layers von den anderen Schichten der Architektur und die ausschließliche Kommunikation über plattformunabhängige Protokolle wie HTTP, XML, UDDI, WSDL und SOAP, ermöglichen die nahtlose Integration verschiedener Systeme und Applikationen. Ziele und Thesen meiner Diplomarbeit: In meiner Diplomarbeit möchte ich zunächst die Grundlagen für eine Serviceorientierte Architektur aufbereiten. Darauf aufbauend führe ich eine Erörterung der Vor- und Nachteile der SOA durch. Etwaige Fragen zur Erörterung: - Welche Möglichkeiten bietet mir SOA? - Welches sind die Kerneinsatzgebiete von SOA? - Wo liegen die Grenzen? - Gibt es Sicherheitsrisiken? Etc Konzeption und Umsetzung einer Service-orientierten Architektur (wahrscheinlich unter der Zuhilfenahme der.net Entwicklungsumgebung) Am Ende meiner Diplomarbeit möchte ich einen Ausblick auf die Zukunft Serviceorientierter Architekturen geben

Inhaltsverzeichnis I Inhaltsverzeichnis Inhaltsverzeichnis... I Darstellungsverzeichnis...V Listingverzeichnis...V Abkürzungsverzeichnis... VI 1 Einleitung...1 1.1 Ziel der Arbeit...2 1.2 Schwerpunkt der Arbeit...2 1.3 Aufbau der Arbeit...2 2 Dienste...3 2.1 Merkmale eines Dienstes...3 2.1.1 Definition und Abgrenzung eines Dienstes bzgl. der Funktionalität...3 2.1.2 Autonomie eines Dienstes...4 2.1.3 Abrufen eines Dienstes über dessen Schnittstellen...4 2.1.4 Blackbox-Verhalten eines Dienstes...4 2.1.5 Austauschbarkeit eines Dienstes bzgl. der Funktionalität...4 2.2 XML Web Services...5 2.2.1 Definition...5 2.2.2 Standards...6 a) Einheitliches Kommunikationsprotokoll (SOAP)...7 b) Einheitliche Schnittstellenbeschreibung (WSDL)...8 c) Standardisiertes Dienstverzeichnis (UDDI)...8 d) Web Service Spezifikationen (WS-*)...9 2.2.3 Konzepte...9 a) Wiederverwendbarkeit von Funktionalität durch leichtgewichtige Komponenten 9 b) Interoperabilität durch leichtgewichtige Kommunikation...11 c) Skalierbarkeit durch zustandslose Business-Logik...11 2.2.4 Schwachstellen...11 a) Performance...12 b) Geringe Unterstützung von Zusatzstandards...12 c) Fehlende semantische Standards...12 d) Sicherheitsaspekte...13 3 Service-orientierte Architektur...15

II Inhaltsverzeichnis 3.1 Definition... 15 3.1.1 Basismodell einer SOA... 16 a) Service-Konsumenten... 16 b) Service-Anbieter... 16 c) Service-Verzeichnisse... 17 3.2 Komponenten und Aufbau... 17 3.2.1 Die Rolle der Web Services... 17 3.2.2 Die Nachricht als zentrales Element... 18 3.2.3 Der Service-Layer... 19 3.2.4 Service-Fassade... 20 3.2.5 Service-Agent... 20 3.3 Integration bestehender Systeme... 21 3.3.1 Bisherige Integrationsebenen... 21 a) Datenebene... 22 b) Applikationsebene... 22 c) Prozessebene... 23 3.3.2 Service-orientierte Integration... 23 a) Service-Adapter für heterogene Systeme... 23 3.4 Integration und Automatisierung von Prozessen... 24 3.4.1 Automatisierung des Business-Workflows... 24 a) Innerbetrieblich... 24 b) Zwischen verschiedenen Firmen... 25 3.4.2 Broker-Service... 25 3.4.3 Gemeinsames Service-Verzeichnis (shared service-repository)... 26 4 Anwendungsbeispiele Service-orientierter Architekturen... 27 4.1 Beschreibung des Beispielprojekts... 27 4.2 Abgrenzung des Beispielprojekts... 27 4.3 Übersicht über die Vorgehensweise... 27 4.4 Analyse des Unternehmens... 28 4.5 Anforderungsanalyse... 30 4.6 Use-Case Beschreibungen... 31 4.6.1 Use-Case Beschreibung Anmeldeprozess des Intranet-Portals... 31 4.6.2 Use-Case Beschreibung Single Sign-On... 31 4.6.3 Use-Case Beschreibung Bestellung eines Büroartikels über das Intranet... 31

Inhaltsverzeichnis III 4.6.4 Use-Case Beschreibung Nachbestellung eines Büroartikels...32 4.6.5 Use-Case Beschreibung Bestellübersicht für berechtigte Personen...32 4.6.6 Use-Case Beschreibung Intranet als Nachrichtenportal...32 4.7 Definition und Abgrenzung der Teilprojekte...33 4.7.1 Checkliste möglicher Integrationsprobleme der Teilprojekte...33 4.8 Muster für die Erstellung eines Service-orientierten Web Services...35 4.8.1 Schritt 1: Bestimmung der Nachrichten...36 4.8.2 Schritt 2: Typdefinition per XSD-Schema...36 4.8.3 Schritt 3: Erstellung des WSDL-Dokuments...36 4.8.4 Schritt 4: Erstellen einer abstrakten Schnittstellenklasse...37 4.8.5 Schritt 5: Implementierung der Funktionalität...38 4.8.6 Schritt 6: Erstellung eines Clients anhand des WSDL-Dokuments...38 4.9 TP 1: Zentrales Anmeldesystem des Unternehmens...39 4.9.1 Analyse des bestehenden Anmeldesystems...39 4.9.2 Auswahl der geeigneten Integrationsebene...42 4.9.3 Der Service-orientierte Lösungsweg...43 a) Benutzerkonto in XML...43 b) Der Service-Adapter...44 c) Das Herzstück: der Service-Layer...46 d) Sicherheitsaspekte...49 4.9.4 Evaluation des Lösungswegs...50 a) Fragenkatalog Teilbereich 1...50 b) Fragenkatalog Teilbereich 2...52 4.9.5 Alternativer Lösungsansatz...52 4.10 TP 2: Bestell- und Nachbestellsystem für Büroartikel...53 4.10.1 Analyse des Lagerhaltungssystems...53 4.10.2 Auswahl der geeigneten Integrationsebene...56 4.10.3 Der Service-orientierte Lösungsweg...56 a) Bestellung in XML...57 b) Funktionalitätsbeschreibung des Service-Adapters...60 c) Erweiterung des Service-Layers...61 4.10.4 Szenarien einer automatisierten Nachbestellung...62 a) Statische Bindung eines Zulieferer-Services...64 b) Dynamische Bindung eines Zulieferer-Services...65

IV Inhaltsverzeichnis c) Beauftragung eines Broker-Services... 65 4.11 TP 3: Nachrichten-Portal für das Intranet... 66 4.11.1 Einbinden eines externen Nachrichtendienstes... 68 4.11.2 Verwendung eines Service-Agenten... 71 5 Fazit und Ausblick... 74 Beschreibung der beiliegenden CD-ROM... 76 Anhang... 77 Literaturverzeichnis... 83

Darstellungs- und Listingverzeichnis V Darstellungsverzeichnis Abb. 1.1: Evolution der Applikationsarchitekturen Abb. 2.1: Web Service Pyramide Abb. 2.2: The scope of end-to-end versus point-to-point security Abb. 3.1: A conceptual service-oriented architecture solution Abb. 3.2: A service-oriented application architecture including Service-Layer Abb. 3.3: Data-level integration Abb. 3.4: Point-to-point application-level integration Abb. 3.5: Integration layers establishing a service-oriented integration architecture Abb. 4.1: Übersicht über die Firmenstruktur Abb. 4.2: Kommunikation zwischen Client und Service Abb. 4.3: Schichtenmodell der Abteilungsapplikation Abb. 4.4: Klassenmodell der Anmeldung Abb. 4.5: Funktion des Anmelde-Adapter-Services Abb. 4.6: Service-Modell des Anmelde-Services Abb. 4.7: Benutzersicht auf die CAS Redirections Abb. 4.8: Klassenmodell der Lagerhaltung Abb. 4.9: Datendiagramm des Lagerhaltungssystems Abb. 4.10: Service-Modell des Bestellvorgangs Abb. 4.11: Funktion des Service-Adapters Bestellung Abb. 4.11: Service-Modell der Nachbestellung: Statische Bindung Abb. 4.12: Service-Modell der Nachbestellung: dynamische Bindung Abb. 4.13: Service-Modell der Nachbestellung: Broker-Service Abb. 4.14: Service-Modell des NachrichtenServices Abb. A1: Bestellformular des Lagerhaltungssystems Abb. A2: Bestellformular im Intranet Listingverzeichnis Listing 4.1: XML-Schema für ein Benutzerkonto Listing 4.2: Korrektes XML-Dokument nach Schema in Listing 4.1 Listing 4.3: Zuordnungsdokument Benutzername-Abteilung Listing 4.4: Zuordnungsdokument Abteilung-Servicepfad Listing 4.5: XML Schema der Artikelliste Listing 4.6: XML Schema für eine Bestellung Listing 4.7: Erweiterung des XML Schemas Bestellung Listing 4.8: XML Schema einer Nachricht und einer NachrichtenListe Listing 4.9: Verknüpfung der Semantik auf Objekt-Ebene (Programmiersprache C#) Listing A1: HTTP Request für SOAP-Anfrage Listing A2: HTTP Response für SOAP-Anfrage Listing A3: WSDL-Dokument des LoginServices Listing A5: Beispiel für eine abstrakte Schnittstellenklasse in C# Listing A6: Ausschnitt aus der Implementierung des Anmelde-Adapter-Service

VI Abkürzungsverzeichnis Abkürzungsverzeichnis ASP B2B CAS COM CORBA DCOM DPA ESA HTML HTTP HTTPS JSP LDAP OASIS ODBC PHP RDF RFC RMI RPC RSS SMTP SOA SOAP SQL SSL SSO TCP/IP UDDI W3C WS WS-I WSDL XML XSD XSL XSLT Active Server Pages Business to Business Central Authentication Service Component Object Model Common Object Request Broker Architekture Distributed Component Object Model Deutsche Presse Agentur Enterprise Services Architecture Hypertext Markup Language HyperText Transfer Protocol HyperText Transfer Protocol secure JavaServer Pages Lightweight Directory Access Protocol Organization for the Advancement of Structured Information Standards Open DataBase Connectivity Hypertext Preprocessor Resource Description Framework Request For Comments Remote Method Invocation Remote Procedure Call RDF Site Summary Simple Mail Transfer Protocol Service-orientierte Architektur Simple Object Access Protocol Structured Query Language Secure Socket Layer Single Sign-On Transmission Control Protocol / Internet Protocol Universal Description, Discovery and Integration World Wide Web Consortium Web Service Web Services Interoperability Organization Web Services Definition Language extensible Markup Language XML Schema Definition extensible Stylesheet Language XSL for Transformation

Over the years, our industry has tried many approaches to come to grips with the heterogeneity of software. But the solution that has proven consistently effective and the one that yields the greatest success for developers today is a strong commitment to interoperability. Bill Gates The movement toward service-oriented architectures and integration solutions is responsible for a great deal of upheaval in the traditional legacy world much like a political uprising where masses demand change and a new way of thinking. Though I might find it disturbing to think of my Web Services as a band of hippies shouting get get loose in the face of a rigid regime of tightly bound legacy environments, there is some merit to this analogy. Thomas Erl

Einleitung 1 1 Einleitung Die Evolution der Applikationsarchitekturen ist geprägt von drei zentralen Triebkräften: der Verbesserung der Wartbarkeit, der Wiederverwendbarkeit von Software und dem Einsatz von anerkannten Standards mit dem Ziel, die Entwicklung schneller und kostengünstiger zu gestalten. 1 Diese Triebkräfte haben, wenn man die Abbildung zur Evolution der Applikationsarchitekturen (Abb. 1.1) betrachtet, dank der abnehmenden Kopplung und einer höheren Interoperabilität, die Qualität der Architekturen in Bezug auf Flexibilität und Wiederverwendbarkeit stetig gesteigert. Abbildung 1.1: Evolution der Applikationsarchitekturen (Quelle: BÄTTIG) Den neuesten Trend in der Evolution der Applikationsarchitekturen stellen die Serviceorientierten Architekturen (kurz SOA) dar. Diese verteilten Architekturen basieren auf der Komposition loser gekoppelter Komponenten in Form von Diensten. Durch die Repräsentation dieser Dienste durch Standards wie XML Web Services sind SOAs in den Brennpunkt der Softwarearchitekturszene gerückt. 1 BÄTTIG

2 Einleitung 1.1 Ziel der Arbeit Im Rahmen dieser Diplomarbeit verfolge ich das Ziel, XML Web Service basierte Serviceorientierte Architekturen anhand von Beispielprojekten bzgl. ihrer Praxistauglichkeit zu evaluieren. 1.2 Schwerpunkt der Arbeit Der Schwerpunkt der Arbeit liegt auf der Betrachtung der speziellen Architektur einer SOA. Des Weiteren wird die Rolle der Web Services innerhalb dieser Architektur beleuchtet. Das Grundlagenkapitel dieser Diplomarbeit steigt bei der Definition von Diensten und der Erläuterung von XML Web Services ein. Ein Grundlagenverständnis der XML-Technologien, wie XML, XML-Schema, XSLT, etc. wird vorausgesetzt. 1.3 Aufbau der Arbeit In Kapitel 2 sollen zunächst die Grundlagen für eine SOA aufbereitet werden. Es gilt zunächst ein allgemeines Verständnis des Begriffs Dienst und dessen Repräsentation in der Software- Welt dem XML Web Service zu vermitteln. Darauf aufbauend werden der Aufbau und die Konzepte, die hinter XML Web Services stehen, näher betrachtet, sowie die Möglichkeiten und Schwachstellen beleuchtet. In Kapitel 3 werden zunächst das Basismodell einer SOA erläutert und darauf aufbauend komplexere Modelle einer SOA und die dafür benötigten Komponenten vorgestellt. Als Einsatzgebiete einer SOA werden die Themen Integration bestehender Systeme und Automatisierung des Business-Workflows betrachtet. Kapitel 4 veranschaulicht die in Kapitel 2 und 3 behandelten theoretischen Kenntnisse anhand einer praxisnahen Evaluation unter der Zuhilfenahme eins Beispielprojekts. Ein abschließendes Fazit und ein Ausblick sollen die Diplomarbeit thematisch abrunden.

Dienste 3 2 Dienste Services bzw. Dienste bilden die Grundlage einer Service-orientierten Architektur. Im folgenden Kapitel soll zunächst auf die allgemeinen Merkmale eines Dienstes unabhängig vom Softwarekontext eingegangen werden. Darauf aufbauend werden die XML Web Services als Repräsentation eines Dienstes auf Softwareebene vorgestellt. 2.1 Merkmale eines Dienstes A service is a function that is well-defined, self-contained, and does not depend on the context or state of other services. 1 Aus diesem Zitat lassen sich die allgemeinen Merkmale 2 eines Dienstes bzw. einer Dienstleistung ableiten und sollen anhand eines Beispiels aus der realen, nicht Software-bezogenen Welt veranschaulicht werden. Als Beispiel dient hierfür ein Komponenten-basiertes HiFi-Audio System bestehend aus einem CD-Player, einem Kassettendeck, einem FM-Tuner, einem Verstärker und Lautsprecherboxen. Dabei werden die einzelnen Komponenten als Dienste betrachtet, z.b. der CD-Player als CD-Wiedergabedienst, usw. 3 2.1.1 Definition und Abgrenzung eines Dienstes bzgl. der Funktionalität Dienste und Dienstleistungen werden über die Funktionalität, die sie anbieten, definiert und gleichzeitig abgegrenzt. Übertragen auf das Beispiel mit dem HiFi-System bedeutet das, dass der CD-Player dadurch definiert ist, dass er CDs abspielt, der FM-Tuner durch den Empfang und Wiedergabe eines Radiosignals, der Verstärker durch die Verstärkung des Eingangssignals, usw. Ein CD-Player muss keine Kassetten abspielen können, das wird vom Kassettendeck erledigt. Die verschiedenen Funktionen der beiden Geräte grenzen diese bezüglich ihrer Dienstleistung voneinander ab. 1 BARRY, Kapitel 3.1 2 Vgl. BARRY, Kapitel 3; CABRERA; FREIBERGER 3 Vgl. BARRY, Kapitel 3

4 Dienste 2.1.2 Autonomie eines Dienstes Ein einzelner Dienst und dessen Funktionalität stehen nicht in Abhängigkeit eines anderen Dienstes oder dessen Zustand. So funktioniert der CD-Player weiterhin, auch wenn das Kassettendeck ausfallen sollte. 2.1.3 Abrufen eines Dienstes über dessen Schnittstellen Der Abruf der Funktionalität eines Dienstes erfolgt über dessen Schnittstellen. Die Nutzung eines Dienstes setzt die Kenntnis seiner Schnittstellen und deren Wirkung voraus. Für das Abspielen einer CD bedeutet das, dass der Nutzer wissen muss, wie diese ins Gerät eingelegt wird und welcher Knopf das Abspielen startet. Außerdem muss der Nutzer wissen, dass der CD-Player ein Ausgangssignal erzeugt, das an den Verstärker weitergeleitet über die angeschlossenen Boxen wiedergegeben wird. 2.1.4 Blackbox-Verhalten eines Dienstes Für die Nutzung eines Dienstes reicht die Kenntnis der Schnittstellen aus. Ein tieferes Verständnis der internen Vorgänge wird nicht benötigt, bzw. soll bewusst verborgen werden. Übertragen auf das Beispiel Abspielen einer CD, bedeutet das, dass der Nutzer die komplexen Vorgänge beim Drücken auf den Abspielknopf, z.b. Starten der Rotation der CD, Auslesen der Audioinformation über den Laser, etc. nicht kennen muss. 2.1.5 Austauschbarkeit eines Dienstes bzgl. der Funktionalität Ein Dienst lässt sich aufgrund seiner Funktionalität durch einen anderen Dienst, der die gleiche Funktionalität bietet, austauschen. Dabei gilt es nur eventuelle Änderungen der Schnittstellen zu beachten, da die Interna des Dienstes durch das Blackbox-Konzept verheimlicht werden. So kann ein CD-Player innerhalb eines HiFi-Systems problemlos durch einen anderen CD- Player ausgetauscht werden. Dies wird durch einen gemeinsamen Industriestandard ermöglicht, der sowohl die Anschlüsse des CD-Players, z.b. Stromanschluss, Audioausgang, etc., als auch die Benutzerschnittstelle, z.b. Verwendung des gleichen Symbols für den Abspielknopf, beschreibt.

Dienste 5 2.2 XML Web Services Der Einsatz von XML Web Services stellt eine Möglichkeit dar, Softwarefunktionalitäten als Dienste bzw. Dienstleistungen zu repräsentieren. 1 In diesem Abschnitt soll auf die Definition, die Umsetzung der oben aufgeführten allgemeinen Merkmale eines Dienstes, sowie die zu Grunde liegenden Konzepte, aber auch Schwächen eines Web Services eingegangen werden. 2.2.1 Definition In der Literatur kursieren verschiedene Definitionen eines XML Web Services. Die Palette reicht von sehr abstrakten, minimalistischen Ansätzen bis hin zu konkreten Implementierungsvorschriften. 2 Offizielle Konsortien wie das W3C 3, OASIS 4 und die Web Service Interoperability Organization (WS-I) 5, hinter denen namhafte Unternehmen wie Microsoft, IBM, etc. stehen, bemühen sich um eine einheitliche Definition und die Standardisierung der Web Service Thematik. Zunächst soll eine minimalistische Definition eines XML Web Service vorgestellt und bewertet werden: Ein XML Web Service versendet und empfängt Nachrichten im XML Format über webbasierte Protokolle. 6 Diese Definition erlaubt eine sehr freie Auslegung des Begriffs Web Service, denn sie schreibt keine genaue Formatierung des XML Dokuments vor und ermöglicht eine Kommunikation über verschiedene Web-basierte Protokolle 7 wie z.b. HTTP, HTTPS, SMTP, TCP, etc. 1 Die Betonung liegt hier auf eine Möglichkeit, denn die Verwendung von Web Services als Repräsentation eines Dienstes ist nicht zwingend in einer Service-orientierten Architektur (SOA). Wenn gleich XML Web Services aufgrund ihrer Merkmale für einen Einsatz innerhalb einer SOA prädestiniert sind. Vgl. FREIBERGER; ERL, S. 49 2 Vgl. VOGELS 3 Für weitere Informationen über W3C: http://www.w3.org 4 Für weitere Informationen über OASIS: http://www.oasis-open.org 5 Für weitere Informationen über WS-I: http://www.ws-i.org 6 Vgl. ERL, S. 47 7 Ein detailliertes Verständnis dieser Protokolle wird für den weiteren Verlauf dieser Diplomarbeit nicht vorausgesetzt, da sie in der weiteren Thematik eine eher untergeordnete Rolle spielen. Nähere Informationen zu den Protokollen unter: CAULDWELL, S. 59-75

6 Dienste Das Problem an dieser sehr freien Definition ist der Zugriff auf einen Web Service, der nach diesem minimalistischem Paradigma entworfenen wurde. Es fehlt zumindest eine Schnittstellenbeschreibung, die die Struktur der auszutauschenden XML Nachrichten fest und die Funktionen, die der Web Service anbietet, offen legt. Für diese Diplomarbeit soll deshalb folgende Definitionen des W3C hinzugezogen werden: A Web service is a software system designed to support interoperable machine-tomachine interaction over a network. It has an interface described in a machineprocessable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards. 1 In dieser Definition fallen Stichworte wie Interoperabilität, verteilte Netzwerk-basierte Kommunikation, maschinenlesbare Schnittstellenbeschreibung im WSDL-Format, Nachrichten im SOAP-Format, sowie die bereits erwähnten Web-basierten Standards. Diese Stichworte werden nun mit denen im vorherigen Abschnitt beschriebenen allgemeinen Merkmalen eines Dienstes in Bezug gebracht. Dazu werden zunächst die Standards, die bzgl. XML Web Services veröffentlich worden sind, und darauf aufbauend die dahinter stehenden Konzepte erläutert. 2.2.2 Standards Die in Abbildung 2.1 gezeigte Web Service Pyramide umfasst die einzelnen Standards 2, die für einen XML Web Service von Bedeutung sind. Ebenso stellt sie den hierarchischen Aufbau dieser Standards und den Grad der bisherigen Standardisierung dar. Die ersten drei Ebenen bilden die Grundlage für die folgenden Sprachstandards eines Web Services. Das Internet, Intranet und Extranet stellt das Netzwerk dar, über das die Web Servi- 1 BOOTH 2 Diese Standards sollen in dieser Diplomarbeit nur kurz beschrieben werden, da jeder dieser Standards alleine, Material für mehrere Bücher ergeben würde. Weiterführende Informationen entnehmen sie bitte den beigefügten Quellenangaben.

Dienste 7 ces anhand von XML basierten und durch XML Schemata 1 definierte Nachrichten und Protokolle kommunizieren. Abbildung 2.1: Web Service Pyramide (Quelle: KAYE, Kapitel 5.3) a) Einheitliches Kommunikationsprotokoll (SOAP) Als Kommunikationsprotokoll für Web Services wird SOAP 2 (frühere Erweiterung des Akronyms: Simple Object Access Protocoll) 3 verwendet. Dieses Protokoll wurde vom W3C im Jahr 2000 in die Liste seiner Standards aufgenommen und liegt in zwischen in der Version 1.2 vor. CAULDWELL beschreibt SOAP so: SOAP is a simple and extensible computer-to-computer communication protocol that leverages existing Internet standards: XML for message formatting, http and other Internet protocols for message transport. 4 1 Ein XML Schema ist eine grammatikalische Beschreibung eines XML Dokuments, das in seinem Sprachumfang die Möglichkeit einer Typisierung und Strukturierung von XML Nachrichten bietet. Nähere Informationen zu XML Schema unter: http://www.w3.org/xml/schema 2 Die komplette SOAP Spezifikation in der Version 1.2 veröffentlicht vom W3C finden sie unter: http://www.w3.org/tr/soap12-part0/ 3 Dieser Name ist irreführend, da SOAP nichts mit dem Zugriff auf Objekte im objekt-orientierten Sinn zu tun hat. Deswegen wird seit der Verabschiedung der SOAP-Version 1.2 des W3C die Erweiterung dieses Akronyms nicht mehr benutzt. Vgl. VOGELS 4 CAULDWELL, S. 20

8 Dienste Dabei gilt es, besonders die Unabhängigkeit von SOAP bzgl. des Transportprotokolls und die Erweiterbarkeit von SOAP aufgrund der Verwendung von XML als Sprachstandard hervorzuheben. Eine SOAP Nachricht 1 besteht aus drei Komponenten: einem SOAP Envelope, optionalen SOAP Headern und einem SOAP Body. Der Body beinhaltet die eigentlich zu übermittelnde Nachricht, die Header-Elemente bieten zusätzliche Informationen bzgl. dieser Nachricht und der Envelope bildet den umschließenden Rahmen für das Body- und die Header-Elemente. 2 b) Einheitliche Schnittstellenbeschreibung (WSDL) WSDL 3 ist das Akronym für Web Service Definition Language. Es handelt sich dabei wie bei SOAP um einen durch das W3C veröffentlichten XML-basierten Standard in der derzeitigen Version 1.1 zur Beschreibung der Schnittstellen eines XML Web Services. In Form eines WSDL-Dokuments 4 ist es einem Web Service möglich auf standardisierte Weise seine Operationen, die dafür eingesetzten Datentypen und die Adresse unter der der Web Services zu finden ist, zu beschreiben und für potentielle Nutzer offen zu legen. c) Standardisiertes Dienstverzeichnis (UDDI) Das Universal Description, Discovery, and Integration Protokoll (UDDI) 5 beschreibt ein standardisiertes Verzeichnis, dass das Veröffentlichen und Suchen von Web Services ermöglicht. Über diverse Suchkriterien kann ein Dienst programmatisch gefunden und ausgewählt werden. Der Anfrager erhält darauf das WSDL-Dokument des Web Services ausgehändigt. UDDI Verzeichnisse treten in folgenden Variationen auf: 6 öffentlich, global für jedermann weltweit zugänglich privat Zugang für eine geschlossene Benutzergruppe (auch unternehmensübergreifend) intern Zugang nur innerhalb einer lokalen Domäne möglich 1 Listing A1 und A2 des Anhangs zeigen beispielhafte SOAP-Nachrichten unter der Verwendung von HTTP als Transportprotokoll. 2 Vgl. CAULDWELL, S. 22 3 Weiterführende Informationen zu WSDL Version 1.1 unter: http://www.w3.org/tr/wsdl 4 Listing A3 des Anhangs zeigt ein beispielhaftes WSDL-Dokument. 5 Weiterführende Informationen zu UDDI (aktuelle Version 3.0) unter: http://www.uddi.org 6 Vgl. ERL, S. 80

Dienste 9 d) Web Service Spezifikationen (WS-*) Die Web Service Spezifikationen 1 stellen ein Set bestehend aus einzelnen Spezifikationen dar, an dessen Entwicklung Unternehmen wie Microsoft, IBM, BEA Systems und VeriSign zusammenarbeiten. Diese Spezifikationen auch Web Service Spezifikationen der zweiten Generation genannt erweitern die bereits vorgestellten Standards SOAP und WSDL um standardisierte Elemente wie z.b. Sicherheit (WS-Security), Transaktion (WS-Transaction), zuverlässigen Nachrichtenaustausch (WS-Reliable Messaging), etc. Ziel dieser Erweiterung ist es Web Services hinsichtlich ihres Einsatzes in verteilten Business-Applikationen robuster zu gestalten und vor allem die Interoperabiltät der beteiligten Systeme zu gewährleisten. 2 2.2.3 Konzepte Im folgenden Abschnitt sollen die Konzepte von Web Services vorgestellt und die daraus resultierenden Vor- und Nachteile aufgezeigt werden. a) Wiederverwendbarkeit von Funktionalität durch leichtgewichtige Komponenten Wiederverwendbarkeit von Software ist wie bereits im einführenden Zitat der Einleitung erwähnt ein zentrales Qualitätsmerkmal von Applikationsarchitekturen. Designparadigmen wie lose Kopplung (engl. loose coupling), hohe Kohaesion (engl. cohesion) und Modularisierung (Komponentenbildung) sind ein Gradmesser für dieses Qualitätsmerkmal. Definition lose Kopplung: Loose coupling is an approach to the design of distributed applications that emphasizes agility-the ability to adapt to changes. Loose coupling intentionally sacrifices interface optimization to achieve flexible interoperability among systems that are disparate in technology, location, performance, and availability. A loosely coupled applica- 1 Eine Liste gegenwärtiger WS-Spezifikationen findet sich unter: http://msdn.microsoft.com/webservices/understanding/specs/default.aspx 2 Vgl. HASAN, S. 95f

10 Dienste tion is isolated from internal changes in others by using abstraction, indirection, and delayed binding in the interfaces between the applications. 1 Definition hohe Kohaesion: Gute Module haben die Eigenschaft, dass ihre Schnittstellen eine Abstraktion von etwas intuitiv Verständlichem darstellen, welches aber dennoch komplex zu implementieren sein kann. 2 Web Services stellen bezüglich ihrer Funktionalität gekapselte Komponenten dar. Diese Komponenten befinden sich als Repräsentation autonomer Dienste innerhalb eines lokalen oder globalen Netzwerks. Autonom bedeutet hier, dass ein Web Service unabhängig von anderen Web Services besteht. Dieses Charakteristikmerkmal spielt eine zentrale Rolle für die Wiederverwendbarkeit bestehender Funktionalität. Neben dieser Komponentenbildung ermöglichen weitere Service-orientierte Prinzipien die Umsetzung von Designparadigmen wie lose Kopplung und hohe Kohäsion. Diese Prinzipien finden sich teilweise in der Charakteristik von Web Services und den vorherrschenden Web Service Standards wieder, werden teilweise aber auch durch das strikte Einhalten von Implementierungsvorschriften erreicht. Die folgende Auflistung führt diese Charakteristiken, sowie die dazu gehörigen Standards bzw. Implementierungsvorschriften auf: Web Services erlauben eine dynamische Bindung, d.h. Bindung zur Laufzeit. Transportprotokoll-, Plattform- und Programmiersprachenunabhängigkeit durch Einsatz von standardisierten, XML-basierten Protokollen und Dokumenten wie SOAP, WSDL, etc. exakt definierte, aussagekräftige Schnittstelle durch den Einsatz von WSDL (Methodengranularität 3 ) Kapselung von Funktionalität (Information Hiding, Blackbox Verhalten von Diensten) schnittstellenbezogene Programmierung reduziert Implementierungsabhängigkeiten 4 1 KAYE, Kapitel 10 2 WALTER 3 Entscheidung welche Funktionalitäten zusammengefasst und über eine Methodenschnittstelle veröffentlicht werden sollen. 4 Vgl. GAMMA, S. 24-25

Dienste 11 b) Interoperabilität durch leichtgewichtige Kommunikation Der Einsatz von plattformübergreifenden, leichtgewichtigen Protokollen und Sprachstandards wie XML, SOAP, WSDL, UDDI, sowie die zusätzlichen Web Service Spezifikationen, erlauben den Einsatz von Web Services in verteilten heterogenen Systemen. Die Bindung von SOAP an HTTP ermöglicht zu dem das Überwinden von Firmenfirewalls, ohne diese modifizieren zu müssen. HTTP wird standardmäßig über Port 80 übertragen, welcher von Firewalls für den regulären Internetzugang offen gehalten wird. 1 c) Skalierbarkeit durch zustandslose Business-Logik Definition Skalierbarkeit: Ein System bzw. eine Anwendung heißt skalierbar, wenn das Verhalten bei unterschiedlicher Benutzerzahl annähernd gleich bleibt. 2 Jede Nachricht, die ein Nutzer an einen Web Service schickt, beinhaltet alle Informationen, die ein Web Service und die gekapselte Business-Logik brauchen, um diese Nachricht korrekt verarbeiten zu können. Web Services sind aus diesem Grund nicht dafür ausgelegt Zustände über mehrere Anfragen hinweg zwischenzuspeichern und gelten deswegen als zustandslos. Diese zustandslose-, nachrichten-basierte Charakteristik von Web Services ermöglicht eine hohe Skalierbarkeit, da die einzelnen Anfragen mehrerer Benutzer an einen Web Service keine Ressourcen aufgrund der Zwischenspeicherung des Zustands belegen. 3 2.2.4 Schwachstellen Damit der Einsatz von Web Services objektiv betrachtet und beurteilt werden kann, gilt es, sich natürlich auch den Schwachstellen zu widmen. Die folgenden Schwachstellen werden in BÄTTIG aufgeführt. 1 Vgl. ERL, S. 231 2 WEYER, S. 27 3 Vgl. HE