Konzeption und Realisierung eines plattformübergreifenden Web-Services zur Verwaltung von Nutzerkonten für virtuelle Waren

Technische Universität Ilmenau Fakultät für Informatik und Automatisierung Institut für Theoretische und Technische Informatik Fachgebiet Rechnerarchitekturen Konzeption und Realisierung eines plattformübergreifenden Web-Services zur Verwaltung von Nutzerkonten für virtuelle Waren von Gabriele Frings verantwortl. Hochschullehrer: Prof. Dr.-Ing. habil. Wolfgang Fengler Betreuer: Dr.-Ing. Jürgen Nützel Prof. Dr. phil.-nat. Rüdiger Grimm Diplomarbeit zur Erlangung des akad. Grades Diplom-Informatiker Thema ausgegeben am: 13. Januar 2003 Arbeit eingereicht am: 17. Juni 2003 Inventarisierungsnummer: 2003-07-14/048/IN98/2231

Danksagung Herzlich bedanken möchte ich mich bei allen, die zum Gelingen dieser Diplomarbeit beigetragen haben, besonders bei meinen Betreuern Dr.-Ing. Jürgen Nützel und Prof. Dr. phil.-nat. Rüdiger Grimm sowie bei dem verantwortlichen Hochschullehrer Prof. Dr.-Ing. habil. Wolfgang Fengler. Erklärung Ich versichere, dass ich diese Diplomarbeit selbständig verfasst und nur die angegebenen Quellen und Hilfsmittel verwendet habe. Ilmenau, den 17. Juni 2003................................. (Gabriele Frings) 2003-07-14/048/IN98/2231 I

II 2003-07-14/048/IN98/2231

Thesen 1. Ein Web-Service kann als eindeutig identifizierbares Software-System charakterisiert werden, dessen öffentliche Schnittstellen mit XML beschrieben sind. Die Beschreibung ist allgemein zugänglich und ermöglicht anderen Systemen eine Interaktion über bekannte Internet-Protokolle und Nachrichten-Formate. 2. Der Nachrichtenaustausch von Web-Services erfolgt über SOAP. Dieses Protokoll basiert auf HTTP und nutzt so die vorhandene Infrastruktur des Internets. SOAP-Nachrichten folgen der XML-Syntax. 3. Der Standard zur Beschreibung von Web-Services ist WSDL (Web Service Description Language). Auf XML-Basis können damit Datentypen, Nachrichten, Schnittstellen und Dienste genau spezifiziert werden. 4. Durch die Verwendung von XML und davon abgeleiteten Darstellungen sind Web-Services über Plattform- und Programmiersprachengrenzen hinweg einsetzbar. 5. Ein Geschäftsmodell zum Vertrieb virtueller Waren ist das Potato-System. Durch eine Umsatzbeteiligung für die Nutzer fördert es die Weiterverteilung und schafft so einen Interessenausgleich zwischen Anbieter und Käufer. 6. Die Verwaltung von Nutzerkonten für virtuelle Waren kann durch das Potato-System erfolgen. Über einen Web-Service können Kooperationspartner damit interagieren. 7. Der Axis-Toolkit von Apache bietet Werkzeuge, um aus der WSDL-Beschreibung einen Rahmen von Java-Klassen zu generieren. Seine SOAP-Engine kann in einen Servlet Container wie Tomcat integriert werden, um den Web-Service bereitzustellen. 8. Die Nutzer des entwickelten Web-Service können verschiedene Clients einsetzen. Kooperationspartner greifen über eigene Software, sog. Potato Jackets, darauf zu. Peer-to-Peer (P2P)-Netzwerke werden über ein spezielles Applet, den P2P-Client, angebunden. 9. Zur Verwaltung von Nutzerkonten wurde nach den Ideen der Liberty Alliance ein eigenes Konzept für das Potato-System erstellt. Nutzer können so ihre verschiedenen Konten 2003-07-14/048/IN98/2231 III

verknüpfen, um den Anmeldevorgang über einen Alias zu vereinfachen. Persönliche Nutzerdaten werden nicht ausgetauscht und die jeweilige Verwaltung kann getrennt weitergeführt werden. 10. Durch den Web-Service kann den Nutzern die Funktionalität des Potato-Systems über verschiedene Partner angeboten werden. Diese können ihre Web-Präsenz mit verschiedenen Programmiersprachen erstellen und nach dem jeweiligen Corporate Design gestalten. Ilmenau, den 17. Juni 2003................................. (Gabriele Frings) IV 2003-07-14/048/IN98/2231

Inhaltsverzeichnis 1 Einleitung 1 1.1 Ziele........................................... 1 1.2 Kapitelübersicht.................................... 2 2 Web-Services 3 2.1 Charakterisierung.................................... 3 2.2 Architektur....................................... 4 2.2.1 Komponenten.................................. 4 2.2.2 Rollen...................................... 5 2.2.3 Operationen................................... 5 2.2.4 Erweiterungen................................. 5 2.3 Schichtenmodell..................................... 8 2.3.1 Kommunikationsschicht............................ 8 2.3.2 Beschreibungsschicht.............................. 9 2.3.3 Entdeckungsschicht............................... 11 2.3.4 Gesamtbild und Querschnittsaufgaben.................... 12 2.3.5 Beziehungen zur Architektur......................... 13 2.4 Technologien...................................... 14 2.4.1 XML....................................... 14 2.4.2 SOAP...................................... 15 2.4.3 WSDL...................................... 17 2.4.4 UDDI...................................... 22 2.5 Was ist anders?..................................... 27 2.5.1 Interoperabilität................................ 27 2.5.2 Just-in-time-Integration............................ 27 2.5.3 zukünftige Entwicklungen........................... 28 3 Potato-System 29 3.1 Grundidee........................................ 29 3.2 Prototypen....................................... 29 3.2.1 Begriffswelt................................... 30 3.2.2 Verkaufsablauf................................. 30 3.3 Weiterentwicklung................................... 32 3.3.1 Neue Begriffe.................................. 32 3.3.2 Veränderter Verkaufsablauf.......................... 33 2003-07-14/048/IN98/2231 V

Inhaltsverzeichnis 4 Nutzerverwaltung 35 4.1 Liberty Alliance..................................... 35 4.2 Passport......................................... 37 5 Konzeption 39 5.1 Zielsetzung....................................... 39 5.2 Nutzerverwaltung.................................... 40 5.3 Abrechnung....................................... 42 5.4 Dienstangebot...................................... 43 5.5 Protokolle........................................ 44 5.5.1 Kostenpflichtiger Download.......................... 44 5.5.2 Bezahlen.................................... 45 5.5.3 P2P-Kauf.................................... 46 5.5.4 Login prüfen.................................. 46 5.5.5 Nochmaliger Download............................ 48 6 Implementierung 49 6.1 Vorgehensweise am Beispiel.............................. 49 6.2 Vorgehensweise am Potato-System.......................... 52 6.2.1 Installation................................... 52 6.2.2 Erstellung der WSDL-Beschreibung..................... 53 6.2.3 Generierung der Java-Klassen......................... 54 6.2.4 Umsetzung des Web-Service.......................... 54 6.2.5 Offene Punkte................................. 55 7 Zusammenfassung und Ausblick 57 A Realisierung 59 A.1 Operationen....................................... 59 A.1.1 Accounts verknüpfen.............................. 60 A.1.2 ActivationCode einsetzen........................... 61 A.1.3 ActivationCodes erwerben........................... 62 A.1.4 Besitz prüfen.................................. 63 A.1.5 Dateien überprüfen............................... 64 A.1.6 Datei-Liste abrufen............................... 65 A.1.7 Datei registrieren................................ 66 A.1.8 Download-Informationen abrufen....................... 67 A.1.9 Guthaben abfragen............................... 68 A.1.10 Handle aktualisieren.............................. 69 A.1.11 Handle ermitteln................................ 70 A.1.12 Informationen abrufen............................. 71 A.1.13 Kaufen über einen P2P-Client........................ 72 A.1.14 Kaufen über ein Jacket............................ 73 A.1.15 Login...................................... 74 A.1.16 Login per Handle................................ 75 VI 2003-07-14/048/IN98/2231

Inhaltsverzeichnis A.1.17 Logout...................................... 76 A.1.18 Matching.................................... 77 A.1.19 Nutzerdaten ändern.............................. 78 A.1.20 Nutzerdaten anzeigen............................. 79 A.1.21 Nutzer registrieren............................... 80 A.1.22 P2P-Tauschbarkeit prüfen........................... 81 A.1.23 P2P-Transfer.................................. 82 A.1.24 P2P-Übertragbarkeit prüfen.......................... 83 A.1.25 Providerdaten ändern............................. 84 A.1.26 Providerdaten anzeigen............................ 85 A.1.27 Provider registrieren.............................. 86 A.1.28 TAN ermitteln................................. 87 A.1.29 Transaktionen anzeigen............................ 88 A.1.30 Verknüpfung lösen............................... 89 A.2 Datentypen....................................... 90 A.2.1 einfache Datentypen.............................. 90 A.2.2 komplexe Datentypen............................. 91 A.2.3 Felder...................................... 93 A.3 Datenbank-Schema................................... 94 Literatur 97 Empfehlungen...................................... 97 Alle Quellen alphabetisch............................... 98 2003-07-14/048/IN98/2231 VII

VIII 2003-07-14/048/IN98/2231

Abbildungsverzeichnis 2.1 Bestandteile eines Web-Service............................ 4 2.2 Service-orientierte Architektur............................ 4 2.3 Architektur-Varianten................................. 7 2.4 Kommunikationsschicht................................ 8 2.5 Beschreibungsschicht.................................. 9 2.6 Entdeckungsschicht................................... 11 2.7 Schichtenmodell zum Web-Service.......................... 12 2.8 Beziehungen zur Architektur............................. 13 2.9 Struktur der Nachricht nach [W3C02a]........................ 15 2.10 Struktur eines WSDL-Dokumentes nach [STK02, S. 94].............. 22 2.11 Entwicklung des UDDI-Datenmodells nach [Som03a]................ 24 3.1 Verkauf und Weiterverkauf im Potato-System.................... 32 3.2 Veränderter Verkaufsablauf.............................. 34 4.1 Identity Federation (Verknüpfung zweier Konten)................. 36 4.2 Single Sign-on...................................... 37 4.3 Anmeldung bei Passport................................ 38 5.1 Umgebung des Web-Service.............................. 39 5.2 Beispiel zur systemübergreifenden Nutzerverwaltung................ 41 5.3 Berechnung der Provisionen.............................. 42 5.4 Aktivitätsdiagramm kostenpflichtiger Download................. 45 5.5 Farb-Semantik der Aktivitätsdiagramme....................... 45 5.6 Aktivitätsdiagramm bezahlen............................ 45 5.7 Aktivitätsdiagramm P2P-Kauf........................... 46 5.8 Aktivitätsdiagramm Login Prüfen......................... 47 5.9 Aktivitätsdiagramm Nochmaliger Download.................... 48 6.1 Aufruf von TestPOS mit Ergebnis.......................... 51 6.2 Architektur und Weg der Anfrage........................... 55 A.1 Werte und Bedeutung................................. 90 A.2 Erweitertes Datenbank-Schema............................ 95 2003-07-14/048/IN98/2231 IX

X 2003-07-14/048/IN98/2231

Tabellenverzeichnis 5.1 Dienstangebot...................................... 43 6.1 Software der Entwicklungsumgebung......................... 52 A.1 Operation Accounts verknüpfen.......................... 60 A.2 Operation ActivationCode einsetzen........................ 61 A.3 Operation ActivationCodes erwerben........................ 62 A.4 Operation Besitz prüfen............................... 63 A.5 Operation Dateien überprüfen........................... 64 A.6 Operation Datei-Liste abrufen........................... 65 A.7 Operation Datei registrieren............................ 66 A.8 Operation Download-Informationen abrufen.................... 67 A.9 Operation Guthaben abfragen........................... 68 A.10 Operation Handle aktualisieren........................... 69 A.11 Operation Handle ermitteln............................. 70 A.12 Operation Informationen abrufen.......................... 71 A.13 Operation kaufen über einen P2P-Client...................... 72 A.14 Operation kaufen über ein Jacket.......................... 73 A.15 Operation Login................................... 74 A.16 Operation Login per Handle............................ 75 A.17 Operation Logout.................................. 76 A.18 Operation Matching................................. 77 A.19 Operation Nutzerdaten ändern........................... 78 A.20 Operation Nutzerdaten anzeigen.......................... 79 A.21 Operation Nutzer registrieren............................ 80 A.22 Operation P2P-Tauschbarkeit prüfen........................ 81 A.23 Operation P2P-Transfer............................... 82 A.24 Operation P2P-Übertragbarkeit prüfen...................... 83 A.25 Operation Providerdaten ändern.......................... 84 A.26 Operation Providerdaten anzeigen......................... 85 A.27 Operation Provider registrieren........................... 86 A.28 Operation TAN ermitteln.............................. 87 A.29 Operation Transaktionen anzeigen......................... 88 A.30 Operation Verknüpfung lösen............................ 89 A.31 einfache Datentypen.................................. 90 A.32 Feldtypen........................................ 93 2003-07-14/048/IN98/2231 XI

XII 2003-07-14/048/IN98/2231

Listings 2.1 Ausschnitt aus einem XML-Dokument........................ 14 2.2 XML Schema zu Listing 2.1.............................. 14 2.3 SOAP Nachricht nach [W3C02a]........................... 16 2.4 Grundgerüst eines WSDL-Dokumentes........................ 18 2.5 Definition der Datentypen im WSDL-Dokument.................. 19 2.6 Bildung von Arrays zu Datentypen.......................... 19 2.7 Definition von Nachrichten aus Datentypen im WSDL-Dokument......... 20 2.8 Definition eines Port-Typs aus Operationen im WSDL-Dokument......... 20 2.9 Definition der Bindung im WSDL-Dokument.................... 20 2.10 Definition des Services im WSDL-Dokument..................... 21 2.11 Nutzung von UDDI über in HTTP eingebettetes SOAP.............. 26 6.1 Port-Definition für Apache Axis............................ 49 6.2 PurchaseOrderBindingImpl.java............................ 50 6.3 TestPOS.java...................................... 51 6.4 Nachrichten zur Operation Login.......................... 53 6.5 Port-Definition für den Web-Service des Potato-Systems.............. 54 A.1 Datenstruktur BuyInfo................................. 91 A.2 Datenstruktur CodeInfo................................ 91 A.3 Datenstruktur DownloadInfo............................. 91 A.4 Datenstruktur FileInfo................................. 91 A.5 Datenstruktur FileLink................................ 92 A.6 Datenstruktur Match.................................. 92 A.7 Datenstruktur ProviderData.............................. 92 A.8 Datenstruktur TransactionInfo............................ 92 A.9 Datenstruktur TransactionRestrictions........................ 93 A.10 Datenstruktur UserData................................ 93 A.11 Datenstruktur UserInfo................................ 93 2003-07-14/048/IN98/2231 XIII

XIV 2003-07-14/048/IN98/2231

1 Einleitung Im Informationszeitalter gewinnt die Vernetzung bisher eigenständiger Systeme zunehmend an Bedeutung. Basierend auf den Grundgedanken des Internets bieten Web-Services eine Architektur zur plattformunabhängigen Kommunikation. So können verschiedenste Dienste durch das Zusammenspiel mehrerer Maschinen erbracht und dem Nutzer über ein Web-Interface zugänglich gemacht werden. Durch den Einsatz von Web-Services können Systeme flexibler gestaltet werden. So kann beispielsweise ein Online-Shop nicht nur verschiedene Systeme zur Bezahlung anbinden, sondern auch Dienste und Nutzerverwaltung eines Kooperationspartners einblenden. In dieser Diplomarbeit wird ein Web-Service zur Verwaltung von Nutzerkonten für virtuelle Waren entwickelt. Der Web-Service soll plattformunabhängig den Zugriff auf das sog. Potato-System ermöglichen. Das Potato-System ist ein Geschäftsmodell zum Vertrieb virtueller Waren. Durch eine Umsatzbeteiligung für die Nutzer schafft es einen Interessenausgleich zwischen Anbieter und Käufer. 1.1 Ziele Als erstes Ziel dieser Diplomarbeit ist die Darstellung der Grundlagen zu nennen. Das Konzept der Web-Services wird anhand von Technologien und Standards näher gebracht. Da sich diese Arbeit auf das Potato-System bezieht, ist dieses vorzustellen. Auf Basis der zu Beginn vorliegenden Version soll eine Zukunfts-Vision beschrieben werden. Diese dient als Leitlinie für die Weiterentwicklung. Die Verwaltung von Nutzerkonten kann anhand zweier konträrer Ansätze eingeführt werden. Daraus ist eine realisierbare Variante für das Potato-System abzuleiten. Diese wird zusammen mit weiteren Bausteinen für den Web-Service in der Konzeption fixiert. Ein Überblick zu Dienstangebot und Protokollen soll angeboten werden. Die Umsetzung des Web-Service mit den ausgewählten Hilfsmitteln (Toolkits, Produkte) ist zu skizzieren. Dies soll einen Einblick in den praktischen Teil dieser Arbeit geben. Vorrangiges Ziel ist hier der Web-Service selbst. Die Implementierung dazu benötigter Funktionen kann ggf. 2003-07-14/048/IN98/2231 1

Kapitel 1. Einleitung auch später erfolgen. Details zur Realisierung (z. B. Operationen und Datenstrukturen) sind im Anhang darzustellen. 1.2 Kapitelübersicht Die Struktur der Kapitel orientiert sich an den Ziel-Vorgaben. Nach diesem einleitenden Kapitel werden die Grundlagen zu Web-Services, zum Potato-System und zur systemübergreifenden Nutzerverwaltung vorgestellt. Auf dieser Basis kann die Konzeption erläutert werden. Ausgehend von der Zielsetzung und Umwelt des zu entwerfenden Web-Service wurden Strategien zur Nutzerverwaltung und Abrechnung erarbeitet. An deren Darstellung schließt sich der Überblick über das Dienstangebot und eine Beschreibung der wichtigsten Protokolle an. Der Anhang beleuchtet die Details der Schnittstelle und die Änderungen am Datenbank-Schema. Die Implementierung wird an Beispielen beschrieben. Als Abschluss kann ein Blick in die Zukunft dienen. Ansatzpunkte für die weitere Entwicklung können im letzten Kapitel aufgezeigt werden. 2 2003-07-14/048/IN98/2231

2 Web-Services Dieses Kapitel bietet eine kurze Einführung in das Thema Web-Services. Da keine Definition allgemein akzeptiert ist, wird der Begriff charakterisiert. Anschließend wird die Basis-Architektur von Web-Services vorgestellt. Diese kann konzeptuell auch als Schichtenmodell betrachtet werden. Den einzelnen Ebenen sind Technologien zugeordnet. Diese werden im Anschluss daran erläutert. Den Abschluss des Kapitels bildet ein Vergleich mit bisher angewandten Techniken. 2.1 Charakterisierung Zum Schlagwort Web-Service existiert keine einheitliche Terminologie [Sta01]. Eine Sammlung von Definitionen, verbunden mit einer Diskussion zur korrekten Schreibweise, findet man bei [Jec02]. Im Rahmen dieser Arbeit wird der Begriff in Anlehnung an das W3C [W3C02d] verwendet. Ein Web-Service besitzt folgende Kennzeichen: 1. ein Software-System, das eindeutig durch eine URI (Uniform Resource Identifier, z. B. URL) identifizierbar ist 2. öffentliche Schnittstellen, die klar definiert und beschrieben sind durch XML 3. eine Beschreibung, die für andere Software-Systeme zugänglich ist 4. andere Systeme können mit dem Web-Service interagieren (wie in der Schnittstellen- Beschreibung festgelegt) 5. die Kommunikation erfolgt über ein Nachrichten-Format auf XML-Basis 6. zur Übertragung werden Internet-Protokolle genutzt, z. B. HTTP, FTP,... Abbildung 2.1 zeigt die Bestandteile im Zusammenspiel. Vereinfachend kann man sich einen Web-Service wie eine Schnittstelle zum entfernten Prozedur- oder Methodenaufruf vorstellen. Das Besondere an dieser Schnittstelle ist die Abstraktion von der genutzten Plattform oder Programmiersprache. 2003-07-14/048/IN98/2231 3

Kapitel 2. Web-Services 3. 2. XML 6. z. B. HTTP 5. 4. URI 1. Abbildung 2.1: Bestandteile eines Web-Service 2.2 Architektur Die Basis-Architektur von Web-Services bezeichnet man auch als Service-orientierte Architektur (SOA). Sie umfasst den Lebenszyklus eines Web-Services und identifiziert dabei drei Rollen und Operationen. Diese beziehen sich auf zwei Artefakte: das Software-Modul und seine Beschreibung. Anhand von Abbildung 2.2 soll die Web-Service-Basis-Architektur in Anlehnung an das W3C [W3C02d] erläutert werden. Verzeichnis XML Beschreibung finden veröffentlichen XML interagieren Dienst Nutzer Anbieter Abbildung 2.2: Service-orientierte Architektur 2.2.1 Komponenten Dienst (Service): Die Implementierung, also das Software-Modul, wird als Dienst bezeichnet und über ein Netzwerk zugänglich gemacht. Seine Schnittstelle ist der Web-Service. 4 2003-07-14/048/IN98/2231

2.2. Architektur Dienst-Beschreibung (Service Description): Die Beschreibung der Schnittstelle umfasst neben Angaben zu Datentypen und Operationen auch Informationen über die Netzwerk-Adresse. Sie kann auch Meta-Daten zur Kategorisierung des Web-Service beinhalten. Veröffentlicht wird sie meist über ein Verzeichnis. 2.2.2 Rollen Nutzer (Service Requestor): Die Anwendung, die einen Web-Service nutzt, kann von einem Menschen oder einer Maschine (z. B. von einem anderen Web-Service) dazu angestoßen worden sein. Anbieter (Service Provider): Der Eigentümer eines Web-Service bzw. die Plattform, auf der er bereitgestellt wird, ist der Anbieter dieser Dienstleistung. Verzeichnis (Registry): Hier kann man die Dienst-Beschreibungen finden. Wie bei Web-Seiten sind zwei Verfahren möglich: entweder trägt der Anbieter den Dienst ein oder aber eine Art Suchmaschine durchsucht das Web nach Diensten und übernimmt die Katalogisierung. Man bezeichnet diese Rolle auch als Gelbe Seiten oder Suchmaschine. Im Englischen sind Service Broker und Discovery Agency ebenfalls üblich. 2.2.3 Operationen veröffentlichen (publish): Ein Anbieter muss seinen Dienst erst den potentiellen Nutzern zugänglich machen. Deshalb veröffentlicht er die Beschreibung, so dass die Nutzer sie finden können. finden (find): Die publizierte Beschreibung eines Dienstes erhält ein Nutzer entweder direkt vom Anbieter oder über das Verzeichnis. Das Auffinden erfolgt zur Entwicklung der Client- Anwendung und zur Nutzung des Web-Service, also zur Laufzeit. interagieren (interact): Soll ein Web-Service mit seinem Nutzer interagieren, so muss dieser ihn über die Dienst-Beschreibung finden und aufrufen. 2.2.4 Erweiterungen Die Web-Service-Basis-Architektur kann um zusätzliche Funktionalität erweitert werden. Denkbar sind Erweiterungen zu folgenden Themen: Sicherheit, Authentisierung, d. h. Sicherstellung der Authentizität wie in [Eck01, S. 5] definiert, 2003-07-14/048/IN98/2231 5

Kapitel 2. Web-Services Vertraulichkeit, Verlässlichkeit, Integrität, Transaktionen (im Sinne von Datenbank-Transaktionen, aber auch solche mit langer Laufzeit), Management, Attachment (Anhänge von z. B. Binärdaten), Choreographie des Nachrichtenaustausches (z. B. request/response oder Einweg-Nachrichten), Session und Routing. Auch Entwicklungen hin zu a) einem Peer-to-Peer-Pattern (P2P), b) direkter Interaktion zwischen Anbieter und Nutzer ohne Verzeichnis, c) indirektem Austausch über einen Vermittler zwischen Nutzer und Anbieter oder d) eine Änderung der Interaktion, z. B. mit Einweg-Nachrichten ähnlich wie bei Newslettern, sind denkbar. Abbildung 2.3 zeigt die Möglichkeiten. 6 2003-07-14/048/IN98/2231

2.2. Architektur Verzeichnis XML XML finden veröffentlichen finden veröffentlichen XML Nutzer Anbieter XML interagieren Anbieter Dienst Nutzer Dienst (a) P2P Verzeichnis XML finden veröffentlichen Verzeichnis XML veröffentlichen Anbieter XML Nutzer interagieren XML Dienst Nutzer Vermittler Anbieter Dienst (b) direkt (c) indirekt Verzeichnis XML finden veröffentlichen XML Nutzer Dienst Anbieter Nutzer (d) Einweg Abbildung 2.3: Architektur-Varianten 2003-07-14/048/IN98/2231 7

Kapitel 2. Web-Services 2.3 Schichtenmodell Wie in vielen anderen Fällen lässt sich auch die Web-Service-Architektur konzeptuell als Schichtenmodell oder Stack beschreiben. Die einzelnen Schichten (Kommunikation, Beschreibung und Entdeckung) zerfallen ihrerseits wieder in Ebenen und besitzen so einen eigenen Stack. Aus technischer Sicht ergibt sich ein ähnliches Bild, bei dem die einzelnen Komponenten oft als Standards bezeichnet werden. Dazu ist anzumerken, dass die Standardisierung der unteren Schichten weiter fortgeschritten ist (teilweise sind es wirklich Standards). Auch die Technologien sind in diesen Ebenen besser erprobt und weiter verbreitet. Die Erläuterungen folgen hier ebenfalls dem W3C [W3C02d]. 2.3.1 Kommunikationsschicht Diese Schicht wird im Englischen mit dem Wort Wire bezeichnet und umfasst Techniken, die den physikalischen Datenaustausch betreffen. Dazu sind der Transport zwischen Nutzer und Anbieter im Netzwerk, das Nachrichtenformat und Erweiterungen davon zu zählen. Abbildung 2.4 veranschaulicht die Schichten im Stack der Kommunikation. Kommunikation Erweiterungen Verpackung Transport Abbildung 2.4: Kommunikationsschicht Als Transportprotokoll wird meist HTTP eingesetzt. Aber auch andere Internet-Protokolle wie FTP (Dateiaustausch) oder SMTP (e-mail) können nach Anwendungsgebiet des Web-Service eingesetzt werden. Nachrichten müssen vor dem Senden verpackt und nach dem Empfang wieder ausgepackt werden. Als Nachrichtenformat kommt XML oder eine davon abgeleitete Darstellungsform wie SOAP zum Einsatz. Als Erweiterungen des Nachrichtenformats können zusätzliche Informationen wie Kontext, Session oder Routing übertragen werden. Dazu fügt man z. B. bei SOAP spezielle Header in die Nachrichten ein. Für diese müssen auch Regeln zur Kodierung und Formatierung festgelegt werden. 8 2003-07-14/048/IN98/2231

2.3. Schichtenmodell 2.3.2 Beschreibungsschicht Auch in der Beschreibungsschicht wird wieder XML (oder Nachfahren davon) als Dokumentenformat eingesetzt. Auf dieser Ebene findet sich eine Sammlung von Dokumenten zur Beschreibung (engl. Description) von Web-Services. Die unteren fünf Teilschichten (XML Schema, Schnittstellen-Beschreibung, Beschreibung der Implementierung, Politik, Präsentation) beschreiben einen einzigen Web-Service. Darüber liegen Zwischenebenen (Instrumentation, Komposition, Dienstvereinbarungen, Geschäftsvereinbarungen), die Beziehungen zwischen Web-Services umfassen. Abbildung 2.5 zeigt die Beschreibungsschicht. Beschreibung Geschäftsvereinbarungen Dienstvereinbarungen Komposition Instrumentation Präsentation Politik Beschreibung der Implementation Schnittstellen-Beschreibung XML Schema Abbildung 2.5: Beschreibungsschicht Unter XML Schema [BEG + ] versteht man das für ein XML-Dokument gültige Schema, also eine Art Dokument-Typ-Definition. Es spezifiziert, welche Elemente zur Auszeichnung in diesem Dokument verwendet werden dürfen. Aufbauend auf XML Schema wird die Schnittstelle beschrieben. Dazu werden die Methoden und ihre Parameter detailliert aufgeführt. Dies erfolgt meist in WSDL, einer eigenen Sprache zur Beschreibung von Web-Services auf Basis von XML. 2003-07-14/048/IN98/2231 9

Kapitel 2. Web-Services Auch die Implementierung wird in WSDL beschrieben. Informationen über die Nachrichten, ihre Codierung und die Anlaufstelle sind hier versammelt. Unter dem Namen Politik (engl. policy) finden sich Informationen über Geschäftskontext, Sicherheits- und Managementanforderungen. Dazu kann eine Kombination von verschiedenen Dokumenten verwendet werden. Als Web-Service-Verzeichnis kommt oft UDDI (Universal Description, Discovery and Integration) zum Einsatz, das unter anderem eine Angabe des Geschäftskontextes ermöglicht. Zusammen mit WSDL könnte die Festlegung der Politik erfolgen. Spätestens ab der Präsentation-Schicht wird der Übergang zwischen nutzbaren Standards und zukunftsweisenden Konzepten klar. In diesen höheren Schichten zeigt sich ein Mangel an Technologie-Konzepten, wie die Beschreibungen auf Basis von XML umgesetzt werden könnten. Die Präsentation der Nachrichten auf verschiedenen Endgeräten soll in einem weiteren Dokument beschrieben werden. Dazu nennt das W3C jedoch keine mögliche Sprache. Ab der Instrumentation beginnt die Beschreibung von Beziehungen zwischen Web-Services. Auf dieser Ebene werden die gegenseitigen Aufrufe von Web-Services beschrieben, um eine mehrstufige Transaktion durchzuführen. Momentan kann zur Beschreibung BPEL4WS (Business Process Execution Language for Web Services) eingesetzt werden. Alternativen dazu befinden sich in der Entwicklung. Da hier noch kein Standard absehbar ist, wird an dieser Stelle nicht näher darauf eingegangen. Ein neuer Web-Service kann als Komposition von bereits bestehenden erzeugt werden. Diesen Sachverhalt beschreibt man ebenfalls mit BPEL4WS oder ähnlichen Sprachen. Eine andere Art der Beziehung stellen Vereinbarungen dar. Zu ihnen gehören die obersten zwei Schichten. Dienst-Vereinbarungen sind ähnlich wie Verträge zu betrachten und können rechtlich bindend sein. Sie betreffen Eigenschaften des Dienstes. Auch Geschäftsvereinbarungen sind ähnlich realen Verträgen möglich. Eine Sprache, um diese auszudrücken, wurde wie bei Dienstvereinbarungen nicht vorgeschlagen. 10 2003-07-14/048/IN98/2231

2.3. Schichtenmodell 2.3.3 Entdeckungsschicht Diese Schicht beschäftigt sich mit allen Aspekten (Inspektion, Veröffentlichung, Entdeckung) im Zusammenhang Suchen und Finden eines Dienstes (engl. Discovery). Abbildung 2.6 zeigt dieses Schichtenmodell. Entdeckung Entdeckung Veröffentlichung Inspektion Abbildung 2.6: Entdeckungsschicht Unter Inspektion versteht man einen dezentralen Mechanismus zur Entdeckung von Web- Services. Dabei stellt der Anbieter eine Art Link-Liste zu den Beschreibungsdateien seiner Web- Services bereit. Als Format kommt wieder ein XML-Nachfahre, nämlich WSIL (Web Service Inspection Language), zum Einsatz. Es existieren auch Konventionen, wie die Datei benannt werden soll und wo sie abzulegen ist. Eine ähnliche Vorgehensweise findet man bei Web-Seiten mit den sog. Robotern. Bei der Veröffentlichung sind viele Wege denkbar: ein firmeninternes Verzeichnis, ein unternehmensweites Portal, ein Katalog von Partnern, ein Verzeichnis von elektronischen Marktplätzen oder ein Geschäfts-Verzeichnis ähnlich der Gelben Seiten. Die Geschäftsfelder können beispielsweise mittels UDDI (siehe Unterabschnitt 2.4.4) durch Auswahl von Kategorien angegeben werden. Alternativ könnte man einen Dienst über die Semantik, z. B. mit DAML-S (DARPA Agent Markup Language Service), bekannt machen. Unter der eigentlichen Entdeckung versteht man das Auffinden und Beziehen der Web-Service- Beschreibung. Dies kann direkt vom Anbieter erfolgen, über Inspektion oder durch ein Verzeichnis. 2003-07-14/048/IN98/2231 11

Kapitel 2. Web-Services 2.3.4 Gesamtbild und Querschnittsaufgaben Aus den einzelnen Schichten (Kommunikation, Beschreibung und Entdeckung) mit ihren eigenen Stacks ergibt sich das in Abbildung 2.7 dargestellte konzeptionelle Gesamtbild. Entdeckung Entdeckung Veröffentlichung Inspektion Beschreibung Geschäftsvereinbarungen Dienstvereinbarungen Komposition Instrumentation QoS Sicherheit Management Präsentation Politik Beschreibung der Implementation Schnittstellen-Beschreibung XML Schema Kommunikation Erweiterungen Verpackung Transport Abbildung 2.7: Schichtenmodell zum Web-Service Auch hier existieren Querschnittsaufgaben, die alle Ebenen betreffen. Die Bereiche Quality-of- Service (QoS), Sicherheit und Management werden durch die Politik- und Präsentationsschicht maßgeblich festgelegt. Ihre Umsetzung erstreckt sich jedoch über den Querschnitt aller Ebenen. 12 2003-07-14/048/IN98/2231

2.3. Schichtenmodell 2.3.5 Beziehungen zur Architektur Abbildung 2.8 stellt die Beziehungen zwischen dem Schichtenmodell und der service-orientierten Architektur dar. Der Kommunikations-Stack deckt die Interaktion zwischen Nutzer und Anbieter ab. Die Beschreibung des Dienstes findet ihre Entsprechung in der gleichnamigen Schicht. Der Stack der Entdeckung repräsentiert die Veröffentlichung und das Auffinden im Verzeichnis. Beschreibung Geschäftsvereinbarungen Dienstvereinbarungen Komposition Instrumentation Präsentation Politik Beschreibung der Implementation Schnittstellen-Beschreibung XML Schema Entdeckung Entdeckung Veröffentlichung Inspektion Verzeichnis XML Beschreibung finden veröffentlichen XML interagieren Dienst Nutzer Anbieter Kommunikation Erweiterungen Verpackung Transport Abbildung 2.8: Beziehungen zur Architektur 2003-07-14/048/IN98/2231 13

Kapitel 2. Web-Services 2.4 Technologien Im Schichtenmodell kamen Technologien wie XML, SOAP, WSDL und UDDI bereits zur Sprache. In diesem Abschnitt werden sie erläutert und mit Beispielen illustriert. Die Ausführungen orientieren sich an der Darstellung in [New02]. 2.4.1 XML Die extensible Markup Language (XML) dient als Format zur Beschreibung, Speicherung und zum Transport von Daten. Im Vergleich zu HTML (Hypertext Markup Language) ermöglicht XML die Definition eigener Elemente und Attribute. Listing 2.1 zeigt einen Ausschnitt aus einem einfachen XML-Dokument über Geschäftskunden. <Customer> <CustumerNumber>12345</CustumerNumber> <CustumerName>Joe s Boots</CustumerName> <CustumerAddress>500 High Street</CustumerAddress> </Customer> Listing 2.1: Ausschnitt aus einem XML-Dokument nach [New02, S. 49] Die Trennung der Daten von der Formatierung wird durch die Assoziation eines XML-Dokumentes (der Daten) mit einem Schema (dem Format) möglich. Das Schema enthält Typ- und Strukturinformationen und ermöglicht die Validierung der Daten. Zum vorherigen Ausschnitt gehört das in Listing 2.2 dargestellte Schema. <xsd:schema xmlns:xsd="http://www.w3.org/2001/xmlschema"> <xsd:element name="customer" type="customertype" /> <xsd:complextype name="customertype"> <xsd:sequence> <xsd:element name="customernumber" type="xsd:integer" /> <xsd:element name="customername" type="xsd:string" /> <xsd:element name="customeraddress" type="xsd:string" /> </xsd:sequence> </xsd:complextype> <xsd:schema> Listing 2.2: XML Schema zu Listing 2.1 nach [New02, S. 50] Weiterhin legt das Schema die Transformation von Daten in XML und umgekehrt fest. Schemas sollen die früher verwendeten DTDs (Document Type Definitions) ablösen. DTDs sind weniger mächtig, aber dafür einfacher zu erlernen und kommen deshalb noch häufig zum Einsatz. XML ermöglicht Unabhängigkeit, z. B. von einer Programmiersprache, durch die Darstellung der Daten innerhalb eines beschreibenden Elements, eines sog. Tags. Die Verknüpfung von Datentypen und Programmiersprache kann so durchbrochen werden. 14 2003-07-14/048/IN98/2231

2.4. Technologien Die Verarbeitung von XML-Dokumenten erfolgt durch einen Parser. Für seinen Aufbau sind zwei Modelle möglich. Das eine ist eine Implementierung der Simple API for XML (SAX). Dabei durchläuft der Parser das Dokument einmal. Durch Ereignisse können die erkannten Elemente weiter verarbeitet werden. Das andere Modell folgt der Document Object Model (DOM) API. Hier ist eine mehrfache Traversierung möglich. Das Dokument wird durch eine Baumstruktur repräsentiert. Zur Transformation von Dokumenten in andere Formate, z. B. zur Darstellung, kann XSL (extensible Stylesheet Language) eingesetzt werden. XSL umfasst XSL-FO (Formatting Objects) und XSLT (Transformation). XSL-FO dienen zur Präsentation von XML-Dokumenten in unterschiedlichen Medien wie auf dem Bildschirm, in Papierform oder als gesprochenes Wort. XSLT Implementationen nennt man XSLT Prozessoren. Sie werden eingesetzt, um ein XML-Format in ein anderes zu überführen. Die Umformungsregeln werden in XSLT style sheets abgelegt. XSLT Prozessoren benötigen einen DOM- oder SAX-konformen Parser. Um Eindeutigkeit der frei wählbaren Bezeichner zu gewährleisten, kommen Namensräume (Namespaces) zum Einsatz. Es wird empfohlen, Namensräume durch URIs zu referenzieren. Namensräume grenzen den Gültigkeitsbereich der Bezeichner ein. Ein Beispiel ist der Namensraum xsd in Zeile 1 von Listing 2.2. Er verweist auf die Definition von XML Schema beim W3C. Alle folgenden Bezeichner, die das Präfix xsd: tragen, sind in diesem Namensraum, also in XML Schema, eindeutig definiert. 2.4.2 SOAP SOAP ermöglicht den Austausch von XML- Dokumenten über das Web. Neben der Bindung an das Transportprotokoll (meist HTTP) definiert SOAP ein Nachrichtenformat und Regeln zur Kodierung. Eine SOAP-Nachricht besteht aus drei Teilen: dem Umschlag (envelope), optionalen Angaben im sog. Header und der eigentlichen Nachricht (body). Die letzten beiden Teile sind in den Umschlag eingebettet. Listing 2.3 zeigt ein Beispiel für eine SOAP-Nachricht. Die zugehörige Struktur zeigt Abbildung 2.9. SOAP Umschlag <env:envelope/> SOAP Header <env:header/> Header Block: reservation Header Block: passenger SOAP Body <env:body/> Element: itinerary Element: lodging Abbildung 2.9: Struktur der Nachricht nach [W3C02a] 2003-07-14/048/IN98/2231 15

Kapitel 2. Web-Services <?xml version= 1.0?> <env:envelope xmlns:env="http://www.w3.org/2002/12/soap-envelope"> <env:header> <m:reservation xmlns:m="http://travelcompany.example.org/reservation" env:role="http://www.w3.org/2002/12/soap-envelope/role/next" env:mustunderstand="true"> <m:reference>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d</m:reference> </m:reservation > <n:passenger xmlns:n="http://mycompany.example.com/employees" env:role="http://www.w3.org/2002/12/soap-envelope/role/next" env:mustunderstand="true"> <n:name>peter Pan</n:name> </n:passenger> </env:header> <env:body> <p:itinerary xmlns:p="http://travelcompany.example.org/reservation/travel"> <p:departure> <p:departing>new York</p:departing> <p:arriving>los Angeles</p:arriving> <p:departuredate>2001-12-14</p:departuredate> </p:departure> <p:return> <p:departing>los Angeles</p:departing> <p:arriving>new York</p:arriving> <p:departuredate>2001-12-20</p:departuredate> </p:return> </p:itinerary> <q:lodging xmlns:q="http://travelcompany.example.org/reservation/hotels"> <q:preference>none</q:preference> </q:lodging> </env:body> </env:envelope> Listing 2.3: SOAP Nachricht nach [W3C02a] Zum Umschlag (envelope) gehört der Namensraum env. Dieser verweist per URI auf die zugehörige Definition beim W3C. Anhand dieser Referenz erfolgt die Unterscheidung der SOAP- Versionen. Hier weist der Link http://www.w3.org/2oo2/12/soap-envelope auf Version 1.2 hin. Die SOAP-Version ist von der XML-Versionsangabe (hier Version 1.0) in Zeile 1 zu unterscheiden. In diesem Umschlag ist der optionale Header env:header vorhanden. Er muss als erstes Kind-Element des Umschlages auftreten und kann mehrere Blöcke enthalten. Der SOAP-Header ist ein Erweiterungsmechanismus, um Steuerungsinformationen mit den Daten zu transportieren. Hier wurden Angaben zu reservation und passenger eingetragen. Neben der Zuordnung von Namensräumen sind die Attribute env:role und env:mustunderstand vorhanden. Das erste macht Angaben über die Rolle, die ein SOAP-Knoten auf dem Weg zum Empfänger bzgl. der Verarbeitung einnehmen soll. Der Wert zeigt an, dass die beiden Blöcke an den nächsten Knoten auf dem Nachrichten-Pfad gerichtet sind. Als Knoten betrachtet man Sender, Empfänger und Vermittler. Die hier angegebene Rolle gehört zum Standard-Repertoire und muss von jedem 16 2003-07-14/048/IN98/2231

2.4. Technologien SOAP-Knoten erfüllt werden. Es ist auch möglich, eigene Rollen zu definieren, die nur spezielle Knoten einnehmen können. [W3C02a] Das zweite Attribut, env:mustunderstand, mit dem Wert true bestimmt, dass die Blöcke vom Knoten nicht nur weitergeleitet, sondern verarbeitet werden müssen. Ist der Knoten dazu nicht in der Lage, so muss er mit einer Fehlermeldung (fault) antworten. In SOAP 1.2 wurde dafür das Header-Element env:notunderstood eingeführt. [W3C02a] Die Behandlung einer SOAP-Nachricht in einem Knoten erfordert zusätzlich zum Protokoll- Listener (z. B. HTTP-Listener) einen sog. SOAP-Prozessor. Dieser kann SOAP-Nachrichten validieren und für die Verarbeitung in der angekoppelten Software aufbereiten. SOAP stellt also die Brücke für den Austausch von Daten bereit, nicht aber die Implementation des Dienstes. Dabei kann man zwischen einem dokumentenorientierten Ansatz und einem im Stil von Remote Procedure Calls (RPC) wählen. Die in Listing 2.3 gezeigte Nachricht ist dokumentenorientiert. Im verpflichtenden Hauptteil (body) der Nachricht wird das auszutauschende XML-Dokument eingebettet. Danach ist im Umschlag kein Element mehr erlaubt. Der Inhalt von env:body ist nur für den Austausch zwischen Sender und Empfänger, nicht für dazwischen liegende Knoten, konzipiert. Im Beispiel enthält der Hauptteil die applikationsspezifischen Elemente itinerary und lodging mit Angaben zur Reise und Unterbringung. Bei RPC-ähnlichem SOAP steht im Hauptteil nur ein Element, nämlich die Serialisierung des Methodenaufrufes [W3C02c]. Dieses verweist durch das Attribut env:encoding Style mit dem Wert "http://www.w3.org/2002/12/soap-encoding" auf das verwendete Schema. Das Element trägt den Namen der aufzurufenden Funktion und schließt die serialisierten Parameter ein. Treten bei der Verarbeitung der Nachricht Fehler auf, so besteht die Antwort im Hauptteil aus einer Fehlerbenachrichtigung (fault), env:fault. Diese muss die zwei Elemente env:code und env:reason zur Angabe des Grundes mit einem kurzem Text umfassen. Der Code kann durch die Kind-Elemente env:value (verpflichtend) und env:subcode (optional) genauer spezifiziert werden. 2.4.3 WSDL Ein wesentlicher Unterschied von Web-Services zu herkömmlichen Anwendungen ist ihre Fähigkeit, sich selbst zu beschreiben [STK02, S. 89]. Als de-facto-standard zur Beschreibung von Web-Services gilt WSDL (Web Service Description Language). Ziel ist die Festlegung der Formate und Protokolle zur Nutzung der Web-Service-Schnittstelle. 2003-07-14/048/IN98/2231 17

Kapitel 2. Web-Services Der strukturierte Ansatz von WSDL vereinfacht die Erstellung, Pflege und Nutzung von Diensten. Aus einer WSDL-Datei kann der Client dynamisch erstellt werden. Dadurch entstehen weniger Fehler und eine Anpassung bei Änderungen des Web-Services geht automatisch von statten. [STK02, S. 90] WSDL-Dokumente können aus der Implementation des Dienstes durch Tools generiert werden. Neben diesem bottom-up-ansatz ist auch die top-down-variante möglich: Aus einer WSDL- Beschreibung generiert man ein Gerüst. In diesem Rahmen kann dann der Code für die Anwendung entwickelt werden. [W3C03b] Im Folgenden wird der Aufbau eines Dokumentes Schritt für Schritt erläutert. Setzt man alle Einzelteile in das Grundgerüst ein, so ergibt sich eine komplette WSDL-Beschreibung. Das Beispiel wurde aus [New02] entnommen und modifiziert. Die Struktur eines WSDL-Dokumentes besteht aus der XML-Versionsangabe und dem Wurzelelement definitions wie in Listing 2.4. Hier werden üblicherweise auch Abkürzungen für Namensräume eingeführt. <?xml version="1.0"?> <definitions name="purchaseorderservice" targetnamespace="urn:purchaseorderservice" xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:soap-enc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:tns="urn:purchaseorderservice" xmlns:xsd="http://www.w3.org/2001/xmlschema" xmlns:xsi="http://www.w3.org/2001/xmlschema-instance">... </definitions> Listing 2.4: Grundgerüst eines WSDL-Dokumentes Nun müssen die Datentypen für die Nachrichten definiert werden. Hier zeigt sich die implizite Erweiterbarkeit des WSDL-Konzeptes. Das Typsystem legt grundlegende Datentypen wie int oder String und ihre Darstellung fest. Generell wird das Typsystem von XML Schema benutzt, es kann aber auch jedes andere verwendet werden. Die Angabe eigener Datentypen ist sowohl im Hauptdokument als auch durch Referenzierung anderer Dokumente möglich. Die Informationen zum Typsystem werden benötigt, um eine Transformation der XML Daten in das Format des Dienstes vor der Dienstausführung zu gewährleisten. Diesen Vorgang nennt man auch Mapping. Zu beachten ist, dass hier nur Angaben zu den Nutzdaten, nicht jedoch über SOAP-Umschlag, -Header oder -Fehlernachrichten gemacht werden dürfen [New02, S. 94]. Listing 2.5 zeigt die Datentypen des Beispiels. Es verwendet komplexe Typen, die aus einfachen Typen wie xsd:string oder xsd:int zusammengesetzt werden. 18 2003-07-14/048/IN98/2231

2.4. Technologien <types> <schema targetnamespace="urn:purchaseorderservice" xmlns="http://www.w3.org/2001/xmlschema" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"> <complextype name="purchaseorder"> <all> <element name="companyname" type="xsd:string"/> <element name="items" type="tns:arrayofitem"/> <element name="address" type="tns:address"/> </all> </complextype> <complextype name="item"> <all> <element name="price" type="xsd:float"/> <element name="partid" type="xsd:string"/> <element name="description" type="xsd:string"/> <element name="quantity" type="xsd:int"/> </all> </complextype> <complextype name="address"> <all> <element name="state" type="xsd:string"/> <element name="postalcode" type="xsd:string"/> <element name="city" type="xsd:string"/> <element name="line2" type="xsd:string"/> <element name="country" type="xsd:string"/> <element name="line1" type="xsd:string"/> </all> </complextype> </schema> </types> Listing 2.5: Definition der Datentypen im WSDL-Dokument Der vorhergehende Ausschnitt ist noch nicht ganz vollständig, denn PurchaseOrder benötigt den Typ von Items. Dieser Typ entsteht dadurch, dass aus dem Typ Item ein Array gebildet wird wie Listing 2.6 zeigt. Ebenso kann ein Array-Typ zu PurchaseOrder erzeugt werden. <complextype name="arrayofitem"> <complexcontent> <restriction base="soap-enc:array"> <attribute ref="soap-enc:arraytype" wsdl:arraytype="tns:item[]"/> </restriction> </complexcontent> </complextype> <complextype name="arrayofpurchaseorder"> <complexcontent> <restriction base="soap-enc:array"> <attribute ref="soap-enc:arraytype" wsdl:arraytype="tns:purchaseorder[]"/> </restriction> </complexcontent> </complextype> Listing 2.6: Bildung von Arrays zu Datentypen 2003-07-14/048/IN98/2231 19

Kapitel 2. Web-Services Aus den eben definierten Datentypen bildet man nun Nachrichten. Listing 2.7 ergänzt das Beispiel um diesen Bestandteil. <message name="postsinglepurchaseorder_in"> <part name="order" type="tns:purchaseorder"/> </message> <message name="postsinglepurchaseorder_out"> <part name="return" type="xsd:float"/> </message> <message name="postpurchaseorders_in"> <part name="order" type="tns:arrayofpurchaseorder"/> </message> <message name="postpurchaseorders_out"> <part name="return" type="xsd:float"/> </message> Listing 2.7: Definition von Nachrichten aus Datentypen im WSDL-Dokument Die Nachrichten müssen nun nach einem Austauschmuster in Operationen gruppiert werden. Die wichtigsten Austauschmuster sind request/response und one-way (ohne Antwort). Sogenannte Port-Typen fassen wiederum eine Gruppe von Operationen ähnlich einer Schnittstelle zusammen. Listing 2.8 zeigt den entsprechenden Ausschnitt. <porttype name="purchaseorderinterface"> <operation name="postsinglepurchaseorder"> <input message="tns:postsinglepurchaseorder_in"/> <output message="tns:postsinglepurchaseorder_out"/> </operation> <operation name="postpurchaseorders"> <input message="tns:postpurchaseorders_in"/> <output message="tns:postpurchaseorders_out"/> </operation> </porttype> Listing 2.8: Definition eines Port-Typs aus Operationen im WSDL-Dokument Nun kann die Schnittstelle über konkrete Protokolle an ihre Implementierung gebunden werden. Dazu wird das Element binding definiert. Von porttype unterscheidet es sich durch Angaben zur Verpackung, z. B. mit SOAP. Listing 2.9 setzt das Beispiel fort. <binding name="purchaseorderbinding" type="tns:purchaseorderinterface"> <soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http/"/> <operation name="postsinglepurchaseorder"> <input> <soap:body use="encoded" encodingstyle= "http://schemas.xmlsoap.org/soap/encoding" namespace="purchaseorderservice"/> </input> <output> <soap:body use="encoded" encodingstyle= "http://schemas.xmlsoap.org/soap/encoding/" 20 2003-07-14/048/IN98/2231

2.4. Technologien namespace="purchaseorderservice"/> </output> </operation> <operation name="postpurchaseorders"> <input> <soap:body use="encoded" encodingstyle= "http://schemas.xmlsoap.org/soap/encoding/" namespace="purchaseorderservice"/> </input> <output> <soap:body use="encoded" encodingstyle= "http://schemas.xmlsoap.org/soap/encoding/" namespace="purchaseorderservice"/> </output> </operation> </binding> Listing 2.9: Definition der Bindung im WSDL-Dokument Als letzter Baustein fehlt noch die Angabe, wo ein Web-Service installiert ist. Dazu wird eine Bindung mit einer Netzwerkadresse in einem Port verknüpft. Ein Service fasst mehrere Ports zusammen. Listing 2.10 schließt das Beispiel ab. <service name="purchaseorderservices"> <port name="purchaseorder_port_java" binding="tns:purchaseorderbinding"> <soap:address location="http://localhost:8080/soap/servlet/rpcrouter"/> </port> <port name="purchaseorder_port_net" binding="tns:purchaseorderbinding"> <soap:address location="http://localhost/purchaseorder.asmx"/> </port> </service> Listing 2.10: Definition des Services im WSDL-Dokument Im oben angesprochenen Ausschnitt wird der Dienst an zwei Ports gebunden. Jeder Port ist dabei an eine andere Netzwerkstelle gebunden [STK02, S. 101]. Der erste Port ist mit dem Proxy für Java verbunden. Das Servlet rpcrouter aus dem Apache SOAP-Paket implementiert die Verpackung der SOAP-Nachrichten und das Dispatching. Es nimmt also Requests über SOAP entgegen, entpackt sie, leitet den Aufruf an den bereitgestellten Dienst, empfängt die Antwort, verpackt sie und gibt sie zurück. Zum Nachrichtenaustausch wird ein sog. Listener für das Transportprotokoll benötigt, z. B. ein Web-Server. Damit der Proxy mit der Anwendung interagieren kann, muss sie ihm bekannt gemacht werden. Die Bereitstellung kann über verschiedene Mechanismen erfolgen, z. B. über eine Oberfläche zur Verwaltung und Pflege der Dienste. Apache Axis ist der Nachfolger des SOAP-Paketes und in 2003-07-14/048/IN98/2231 21