Fachbereich Informatik

Transkript

1 Diplomarbeit Ein generisches Framework zur grafischen Anbindung von Web-Services Steffen Apfel Dezember 2004 Betreuer: Prof. Dr. Paul Müller Dipl. Inform. Markus Hillenbrand Fachbereich Informatik AG Integrierte Kommunikationssysteme Universität Kaiserslautern Postfach Kaiserslautern

2

3 Ich versichere, dass ich die vorliegende Diplomarbeit selbstständig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel verwendet habe. Kaiserslautern, den (Steffen Apfel)

4

5 Abstract Web-Services interagieren miteinander, um in Service-orientierten, verteilten Umgebungen gemeinschaftlich Aufgaben zu bearbeiten. Web-Services bauen auf vorhandenen XML-basierten Technologien wie u. a. WSDL, SOAP und UDDI auf und verwenden diese, um unabhängig von verwendeter Plattform, Programmiersprache und Transport-Protokoll miteinander zu kommunizieren. Die Web Service Description Language (WSDL) beschreibt die Schnittstelle eines Web-Service und spielt somit eine herausragende Rolle in der Web-Service-Architektur. WSDL kann automatisch maschinell zur Ansprache des transparent dahinter liegenden Web-Service verwendet werden. In dieser Diplomarbeit wird untersucht werden, inwieweit aus WSDL generisch eine grafische Oberfläche (GUI) zur Ansprache von Web-Services erzeugt werden kann. Ausgangsdokument ist lediglich das WSDL-Dokument, aus dem alle relevanten Informationen zum GUI-Aufbau extrahiert werden. Neben einer Analyse von WSDL werden ein Modell und ein Prototyp entwickelt, die die Möglichkeiten und Grenzen der GUI-Generierung aus WSDL herausstellen.

6

7 Einleitung 7 Inhaltsverzeichnis Kapitel 1: Einleitung Motivation Ziele Struktur...13 Kapitel 2: Technologien Web-Services Service-orientierte Architektur Grundlagentechnologie: XML Datenschema: XSD Web Service Description Language 1.1 (WSDL) Aufbau eines WSDL-Dokumentes Modularisierung durch Importieren Vergleich WSDL 1.1 und WSDL Universal Description, Discovery and Integration (UDDI) SOAP Zusätzliche Technologien Zusammenfassung...42 Kapitel 3: Einordnung der Arbeit Apache Axis und WSDL2Java Vergleich von WSDL2Java mit wscompile von Sun Microsystems Binding des Clients Related Work: WSRP von OASIS Zusammenfassung...60 Kapitel 4: Modellbildung Beschreibung des Frameworks Anwendungsfälle Grafische Komponenten Anforderungskatalog Aufbau der GUI WSDL-Komponenten Datentypen in XSD...74

8 Inhaltsverzeichnis 4.4 Einbettung semantischer Informationen Zusammenfassung...93 Kapitel 5: Realisierung Architektur des Frameworks Aufbau der grafischen Komponenten Anordnung der grafischen Komponenten Realisierung des Bindings Zusammenfassung Kapitel 6: Implementierung Gestaltung der grafischen Oberfläche Abbildung der Datentypen auf Java Anzeigen von Dokumentationen Zusätzliche Implementierungsaspekte Kapitel 7: Zusammenfassung und Ausblick Kapitel 8: Anhang Vordefinierte, primitive Datentypen und ihre Fassetten Abgeleitete Datentypen und ihre Fassetten Übersicht: XSD-Datentypen, Java-Datentypen und Swing-Komponenten Modulares WSDL-Dokument durch Importieren Java-Klasse des XSD-Datentyps float Literaturverzeichnis Abbildungsverzeichnis Glossar...151

9 Einleitung 9 Kapitel 1: Einleitung Web-Services haben heutzutage eine fundamentale Bedeutung in der Verwendung des Internets, der Weiterentwicklung verteilter Systeme und bei der Softwareentwicklung eingenommen. Vor einigen Jahren waren die Softwarehersteller stets bemüht, Programme mit größtmöglicher Funktionalität zu entwickeln. Web-Services bieten nun eine völlig neue Perspektive der Programmentwicklung. Innerhalb eines Web-Service kann modular eine überschaubare Funktionalität implementiert werden. Web- Services können zur Bewältigung komplexer Aufgaben orchestriert werden, diese gemeinsam erledigen, und danach in neuer Konstellation weitere Aufgaben erfüllen. Durch diese lose Kopplung je nach Problemstellung, bieten Web-Services ein mächtiges Konstrukt zum problemorientierten Bearbeiten von Aufgaben. Web-Services stellen primär keine neuartigen Dienste zur Verfügung, sondern stellen vielmehr Technologien zur unabhängigen Orchestrierung vorhandener Dienste bereit. Somit können bisher isoliert arbeitende Dienste zur Lösung vorhandener Probleme in einem größeren Wirkungsumfeld zusammengestellt werden. Bislang bestand das Hauptproblem beim Zusammenfügen von verteilten Diensten über Netzwerkgrenzen hinweg in der Inkompatibilität. In den 90iger Jahren fand eine Ausbreitung der Local Area Networks (LAN) statt. Anwendungen konnten nun über Rechnergrenzen hinweg miteinander kommunizieren und Aufgaben bearbeiten. Durch die Vernetzung der Computer gewannen verteilte Anwendungen immer mehr an Bedeutung. Microsoft entwickelte aus dem Component Object Modell (COM) das Distributed COM (DCOM). Bei COM wird die Funktionalität der verwendeten Objekte über Schnittstellenbeschreibungen definiert. Innerhalb einer DCOM-Architektur können Objekte auf Windows-Plattformen verteilt vorliegen und angesprochen werden [CHY+97]. Parallel dazu entwickelte die Object Management Group (OMG) die Common Object Request Broker Architecture (CORBA). CORBA-Programme können unabhängig von Plattform und Programmiersprache miteinander kommunizieren und Objekte austauschen, wobei beide Teilnehmer eine CORBA- Implementierung und Bibliotheken benötigen [OMG04]. Zusätzlich brachte Sun Microsystems Remote Method Invocation (RMI) heraus. RMI ist eine Java-API zur Kommunikation zwischen entfernten, verteilten Java-Objekten in heterogenen Systemen [RMI03]. Allerdings wiesen diese drei Innovationen eine große Schwäche auf: Sie waren nicht miteinander kompatibel. Beim Ansatz von DCOM ist man auf die Windows-Plattform beschränkt. Bei RMI von Sun Microsystems besteht die Abhängigkeit zur Programmiersprache Java und bei CORBA von OMG war man auf der anderen Seite auf die zugrunde liegende Netzwerk-Technologie und Middleware beschränkt, die bei allen Kommunikationsteilnehmern vorhanden sein musste. Somit ist bei diesen drei Lösungen kein Einsatz in einer heterogenen Systemlandschaft gegeben. Web-Services überwinden diese drei Schwächen der Programmiersprachen-, Plattform- und Technologie-Abhängigkeit. Bei Web-Services basieren sämtliche verwendete Technologien auf der Extensible Markup Language

10 10 Einleitung (XML) [BPS+04]. XML wird von jeder Plattform und Sprache unterstützt und schafft somit Interoperabilität. In XML können sämtliche Übertragungsdaten serialisiert werden. Diese werden dann über ein vorhandenes Transport-Protokoll gesendet, hauptsächlich HTTP. Der Empfänger kann die empfangenen Daten in ein für sein Programm verständliches Format deserialisieren. Dadurch können unterschiedliche Programme miteinander kommunizieren und Tätigkeiten zusammen ausführen. Selbst Legacy-Systeme, die wegen der Inkompatibilität mit neueren Standards oft nicht mehr zur Verwendung kamen, können nun in bestehende Systeme integriert werden. Jeder Service arbeitet völlig transparent mit seinen jeweiligen Partnern zusammen. Lediglich die Schnittstelle des Service wird veröffentlicht, um Informationen über Datenformate, Bindungsinformationen und verwendete Nachrichten zu publizieren. Von der dahinter liegenden Service-Realisierung wird abstrahiert. In diesem einleitenden Kapitel soll zunächst die Motivation zur Erstellung dieser Diplomarbeit angeführt werden. Im nächsten Unterkapitel wird das Ziel der Arbeit festgesetzt und dessen Erreichung beschrieben. Abschließend werden die nachfolgenden Kapitel dieser Publikation vorgestellt. 1.1 Motivation In dem Buch XML, Web Services, and the Data Revolution bezeichnet der Autor F. Coyle Web- Services als ein Phänomen [Coy02]. Einerseits hat der Autor sicherlich Recht, dass Web-Services die Benutzung des Internets erweitern und durch die neuartige Benutzung des Internets als ein Phänomen betrachtet werden können. Allerdings ist meiner Meinung nach der Begriff Phänomen falsch verwendet. Web-Services stellen keine revolutionäre, neue Technologie dar, sondern Web-Services beruhen auf bewährten, etablierten Technologien. Diese führen sie in einer neuen Art der Verwendung zusammen. Web-Services schaffen durch ihre Interoperabilität einen wichtigen Schritt zur Integration verschiedener Plattformen wie Java, DCOM und CORBA und abstrahieren von Entwicklungsdetails. Da Web- Services auf offenen, XML-basierten Standards aufsetzen, die von jeder Plattform unterstützt werden, kann man sich einzig und allein auf die Funktionalität von Services konzentrieren. Beim Anbinden eines Services ist lediglich dessen Funktionalität von Interesse und die verwendete Programmiersprache oder Entwicklungsplattform sind transparent. In dieser Eigenschaft liegt ein riesiges Potenzial für die Weiterentwicklung und Verbreitung von Web-Services. Softwareentwickler sind nicht darauf angewiesen, sich beim Entwickeln eigener Software auf eine Programmiersprache oder Plattform mit Kunden oder Geschäftspartnern zu einigen. Stattdessen können sie unabhängig von herrschenden Standards eigene Programme entwickeln und durch Web-Services ihren Kunden zur Verfügung stellen. In der Verwendung und Weiterentwicklung von Web-Services liegt also ein großes Potenzial für die weitere Entwicklung des Internets und die Softwareentwicklung. Zudem können durch Web- Services kostspielige Standards wie z.b.: Electronic Document Interchange (EDI) im Business-to- Business Bereich zur Bestell-, Dokument- und Rechnungsabwicklung umgangen oder gar ersetzt wer-

11 Einleitung 11 den [EDI04]. Web-Services bieten also ein großes Reservoir für zukünftige Softwareerstellung. Im Bereich der verwendeten Technologien arbeiten seit geraumer Zeit große Unternehmen wie Microsoft und IBM oder aber auch Standardisierungsunternehmen wie das von Tim Berners-Lee geleitete World Wide Web Consortium (W3C) und der Organization for the Advancement of Structured Information Standards (OASIS) zusammen und entwickeln ständig neue Versionen der bestehenden Technologien. Web-Services sollen so aufgebaut werden, dass Systeme andere Web-Services selbstständig finden, deren Funktionalität integrieren und zusammen anliegende Aufgaben erledigen. Der automatisierte Datenaustausch ohne menschliche Interaktion und Hilfestellung zwischen Systemen steht dabei im Vordergrund der Weiterentwicklungen. Eine Fragestellung hat allerdings bisher kaum Beachtung bekommen: Wie kann ein Anwender einen Web-Service benutzen? Gibt es eine grafische Oberfläche zum Erstellen der Anfragen an einen Web-Service? Werden einem Anwender Hilfestellungen zum Editieren der erforderlichen Parameter und Benutzung eines Dienstes gegeben? Wie kann eine Oberfläche generisch und somit für alle existierenden Web-Services erzeugt werden? Reichen vorhandene Standards aus oder müssen diese erweitert, bzw. neue Standards entwickelt werden? Nach einschlägiger Literatur- und Netzrecherche wurden nur wenige Ansatzpunkte zur Lösung dieses Problems gefunden. OASIS entwickelt den Standard Web Service for Remote Portlets (WSRP). Durch diesen Standard sollen Web-Service-Anbieter (Provider) zusätzlich zu ihrem Web-Service eine eigene Graphical User Interface (GUI) mit parametrisierten Markup-Fragmenten erstellen. Die Markup- Fragmente werden dann innerhalb eines Portals an das passende Endgerät angepasst und anschließend eine GUI erzeugt. Diese Lösung ist zurzeit auf Portale beschränkt und ein weiterer Nachteil bei dieser Lösung ist allerdings, dass ein Web-Service-Anbieter zusätzlich zu seinem Web-Service die Markup- Fragmente entwickeln muss. Alte, bestehende Web-Services müssten um diese Markup-Fragmente erweitert werden. Ein erheblicher Programmieraufwand würde entstehen, um alle bereits existierenden Web-Services mit diesem neuen Standard konform zu halten. Daher sollte eine Lösung gefunden werden, die auf den bestehenden Standards aufbaut und diese zur Generierung einer GUI verwendet. In der vorliegenden Diplomarbeit wird deshalb untersucht, inwieweit der bestehende Standard zur Schnittstellenbeschreibung eines Web-Service, die Web Service Description Language (WSDL), als Grundlage zur Erzeugung einer grafischen Oberfläche verwendet werden kann. Ein WSDL-Dokument beschreibt die Schnittstelle des Web-Service, legt das Übertragungsprotokoll fest, spezifiziert alle verfügbaren Operationen, definiert alle zu übertragenen Daten und definiert mit der XML Schema Definition Language (XSD) sämtliche verwendete Datentypen [BM04b]. Somit sind alle relevanten Informationen zum Erstellen einer Anfrage an den Web-Service in einem WSDL-Dokument integriert. Aus diesem Grund sollte es möglich sein aus einem WSDL-Dokument generisch eine GUI zu erzeu-

12 12 Einleitung gen, mit deren Hilfe ein Anwender alle Eingaben durchführen kann. Dies ist der zentrale Ansatzpunkt dieser Diplomarbeit. Es wird untersucht, ob die Extraktion der Informationen des WSDL-Dokumentes zur Erzeugung der GUI ausreichen. In diesem Falle wäre die Entwicklung eines neuen Standards, wie z.b. WSRP, in Frage zu stellen. Vielmehr könnte man den Standard WSDL erweitern und vorhandene Schwachstellen neu spezifizieren. 1.2 Ziele Zur Erläuterung des Ziels dieser Diplomarbeit, soll zunächst der Titel der Arbeit näher betrachtet werden: Ein generisches Framework zur grafischen Anbindung von Web-Services. Das Hauptziel der Diplomarbeit ist die Entwicklung eines Modells und Prototypen eines Frameworks zum Ansprechen von Web-Services. Die grafische Oberfläche soll generisch erzeugt werden und für sämtliche Web-Services eine einheitliche GUI erstellen. Diese GUI soll den Anwender intuitiv leiten und Hilfestellung beim Benutzen von Web-Services bieten. Die Benutzung schließt zum einen die Erstellung der Anfrage und zum anderen das Anzeigen der Antwort und evtl. übertragenener Anhänge (Attachments) mit ein. Als Ausgangsdokument zur Generierung der GUI soll ausschließlich die Schnittstellenbeschreibung eines Web-Service, das WSDL-Dokument, dienen. Das WSDL-Dokument enthält vielfältige Informationen, die an dieser Stelle kurz angesprochen werden. WSDL liefert Informationen zum Verbindungsaufbau, Netzwerkadresse, Name des Web-Service und sämtliche Operationen, die ausgeführt werden können. Mit diesen Informationen kann die Verbindung zum Web-Service aufgebaut werden. Des weiteren spezifiziert das WSDL-Dokument alle ausgetauschten Daten und deren Formate, die als XML-Schema angegeben werden. Diese Daten können nun zur Generierung einer Eingabemaske innerhalb der GUI verwendet werden. Für sämtliche Datentypen wird eine spezifische Eingabekomponente generiert, aus denen sich die GUI je nach vorliegendem WSDL-Dokument sukzessive aufbaut. Zusätzlich können die Datentypdefinitionen zu Vailidierungszwecken verwendet werden. Zur Erreichung dieses Ziels der Diplomarbeit, wird ein Schwerpunkt auf die Analyse von WSDL-Dokumenten und darin enthaltene XSD-Datentypen gelegt. In Kapitel zwei und drei werden zunächst die theoretischen Grundlagen aufbereitet. Kapitel vier erklärt das entwickelte Modell zur Realisierung des Projektes und Kapitel fünf geht auf die Realisierung des Frameworks ein. In Kapitel sechs werden einige Implementierungsaspekte bei der Realisierung des Modells vorgestellt.

13 Einleitung Struktur Zur Demonstration einiger Technologien, Verarbeitungsschritte und letztendlich Entwicklung der GUI wurden zwei Anwendungsbeispiele ausgewählt. Im ersten theoretischen Teil der Ausarbeitung veranschaulicht ein Taschenrechner-Web-Service den Aufbau eines WSDL-Dokumentes. Dieser Web- Service bietet zwei Operationen an. Eine Addition addiert zwei Ganzzahlwerte -einfache Datentypenund liefert als Ergebnis die Summe beider Werte. Die Subtraktion nimmt einen komplexen Datentyp, der aus zwei Gleitkommazahlen aufgebaut ist, entgegen und liefert die Differenz beider Werte. Anhand dieses überschaubaren Beispiels kann u. a. der Aufbau eines WSDL-Dokumentes illustriert, das Anbinden des Clients, sowie auf die unterschiedliche Behandlung von komplexen und einfachen Datentypen eingegangen werden. Dieses einfach aufgebaute Demonstrationsbeispiel soll vor allem zum Einstieg in die Beschreibungssprache WSDL dienen. Nachdem das theoretische Grundwissen von WSDL erklärt wurde, soll im zweiten praktischen Teil ein weiterer, komplexerer Web-Service als Anschauungsbeispiel dienen. Ein Bibliotheks-Web-Service bietet zum einen das Speichern neuer Bücher und Publikationen an und zum anderen das Suchen von Büchern oder Autoren. Durch dieses Beispiel soll der Aufbau der GUI erläutert werden, das Senden von Daten oder weitere komplexe Datentypen wie Felder und Aufzählungen beschrieben werden. Insbesondere bietet der entwickelte Prototyp die Möglichkeit bereits verwendete Eingaben erneut zu laden und wiederum einzubinden. Diese Diplomarbeit ist in die fünf Hauptkapitel Technologien, Einordnung der Arbeit, Modellbildung, Realisierung und Implementierung untergliedert. Im zweiten Kapitel werden Web-Services definiert und die wichtigsten Technologien vorgestellt. XML und die XML Schema Definition Language (XSD) werden als Basistechnologien vorgestellt. Im Mittelpunkt dieses Kapitels steht die Betrachtung der Web Service Description Language (WSDL), die als Ausgangspunkt zur Generierung der GUI dient. Neben WSDL werden schließlich die beiden anderen wichtigen Technologien im Zusammenhang mit Web-Services erklärt: Universal Description, Discovery and Integration (UDDI) und SOAP. Nachdem im zweiten Kapitel die theoretischen Grundlagen für diese Arbeit gelegt wurden, beschäftigt sich Kapitel drei mit der Einordnung der Arbeit. Zunächst wird das Projekt Axis der Apache Foundation vorgestellt und dessen Architektur erläutert. Weiterhin wird das Werkzeug WSDL2Java von Apache Axis vorgestellt. Mit Hilfe dieses Werkzeugs werden aus einem WSDL-Dokument Java-Klassen erzeugt, die zur weiteren Verwendung innerhalb des zu erstellenden Prototypen bereitgestellt werden. Da Sun Microsystems auch ein Werkzeug zur Verfügung stellt, findet danach ein Vergleich von WSDL2Java der Apache Foundation und wscompile von Sun Microsystems statt. Unter vorgegebenen Kriterien werden beide Werkzeuge getestet und abschließend bewertet. Nachkommend wird das verwandte Thema WSRP von OASIS vorgestellt, dessen Vorgehensweise geschildert und mit den Ergebnissen dieser Arbeit verglichen und abgegrenzt. Kapitel vier zeigt das entwickelte Modell zur Realisierung dieser Arbeit. Zunächst wird die Architektur des Frameworks erläutert. In diesem Zusammenhang wird auf die Problematik der Komplexität des WSDL-Dokumentes eingegangen. Anschließend werden die verwendeten XSD-Datentypen erklärt

14 14 Einleitung und deren spätere grafische Präsentation festgelegt. Zusätzlich wird eine Möglichkeit zum Einbinden von semantischen Informationen in der GUI modelliert. In Kapitel fünf wird der praktische Teil der Arbeit vorgestellt. Zunächst wird die Architektur des Prototypen durch zwei statische UML-Diagramme beschrieben. Nachfolgend wird der Aufbau der grafischen Oberfläche aus den Informationen des WSDL- und XSD-Dokumentes vorgestellt. Anschließend wird die Realisierung der Anbindung des Clients diskutiert, bevor ausführlich auf die Realisierung des Frameworks Bezug genommen wird. In Kapitel sechs werden diverse Implementierungsaspekte näher vorgestellt. Es werden die Abbildungsvorschriften der XSD-Datentypen auf Java aufgelistet und in diesem Zusammenhang entstehende Namenskollisionen erläutert. Darüber wird gezeigt, wie durch gezieltes Einbinden von Dokumentationen semantisch eindeutige Eingabemasken zur Anfrage an einen Web-Service generiert werden. Nach diesen fünf Hauptkapiteln folgt in Kapitel sieben eine Zusammenfassung der Diplomarbeit und Ausblick auf weitere Entwicklungen.

15 Technologien 15 Kapitel 2: Technologien In diesem Kapitel wird zunächst eine Definition für Web-Services angegeben und erklärt wie Web- Services auf dem Prinzip der Service-orientierten Architekturen (SOA) beruhen. Danach werden die wichtigsten Technologien im Zusammenhang mit Web-Services vorgestellt. Zuerst wird im Unterkapitel 2.2 die Rolle von XML im Bezug auf Web-Services und deren Technologien erläutert. XML dient als Basis für die darauf aufbauenden anderen Technologien. Im Zusammenhang mit XML wird anschließend die XML Schema Definition Language (XSD) vorgestellt, die zur Beschreibung der Datentypen innerhalb der anderen Technologien verwendet wird. XSD wird im vierten Kapitel nochmals aufgegriffen, wenn die grafische Darstellung einzelner Datentypen diskutiert wird. Nach der Beschreibung dieser beiden Basistechnologien werden die drei Haupttechnologien von Web-Services erklärt. Unterkapitel 2.4 beschreibt die WSDL ausführlich und erläutert den Modularisierungs-Mechanismus des Importierens. Da WSDL in unterschiedlichen Versionen vorliegt, Werkzeuge zur automatischen Codegenerierung allerdings nur mit der älteren kompatibel sind, wird ein Vergleich der Versionen vorgenommen. WSDL stellt das Ausgangsdokument zur Erstellung der grafischen Oberfläche dar. Dementsprechend wird der Schwerpunkt in diesem Kapitel auf WSDL gelegt. Unterkapitel 2.5 stellt Universal Description, Discovery and Integration (UDDI) vor. Diese Technologie wird zum Beschreiben und Finden von Web-Services verwendet. Danach wird in Kapitel 2.6 SOAP, ein Protokoll zum strukturierten Datenaustausch, vorgestellt. Kapitel 2.7 erwähnt weitere Technologien, die im Zusammenhang mit Web-Services eine Rolle spielen. Die abschließende Zusammenfassung wiederholt die wichtigsten Aspekte dieses Kapitels. 2.1 Web-Services Das World Wide Web Consortium (W3C) definiert allgemein einen Web-Service wie folgt: A Web service is a software system identified by a URI [RFC2396] 1, whose public interfaces and bindings are defined and described using XML. Its definition can be discovered by other software systems. These systems may then interact with the Web service in a manner prescribed by its definition, using XML based messages by Internet protocols. [ABFG04] In dieser Definition wird herausgestellt, dass ein Web-Service auf dem Prinzip einer Serviceorientierten Architektur (SOA) basiert. Ein Web-Service kann demnach durch andere Softwaresysteme über eine URI gefunden werden und besitzt eine XML-basierte Schnittstellenbeschreibung. Andere Systeme kommunizieren mit dem Web-Service in der Schnittstellenbeschreibung definierten Art. Diese Definition wird im nächsten Unterkapitel nochmals herangezogen, wenn ein Web-Service im Zu- 1 RFC: Request for Comments (öffentliches Diskussionsdokument, siehe Glossar)

16 16 Technologien sammenhang mit der SOA erklärt wird. In einer weiteren Definition des W3C wird bei der Beschreibung eines Web-Service näher auf die verwendeten Technologien eingegangen: A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable 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. [BHM+04] In dieser technischen Definition des W3C wird zum einen darauf hingewiesen, dass Web-Services in automatisierbarer Weise Daten über ein Netzwerk senden. Eine menschliche Interaktion ist nicht zwingend erforderlich und Softwaresysteme können eigenständig miteinander kommunizieren und die Daten austauschen. Zum anderen werden zwei XML-basierte Standards erwähnt: WSDL zum Beschreiben der Schnittstellen eines Web-Service und SOAP als Nachrichtenformat zum Austausch der Daten. Durch die Darstellung und Übertragung der Daten in XML ist ein Web-Service sowohl unabhängig vom Betriebssystem, der Programmiersprache sowie vom Transport-Protokoll. Eine XMLbasierte Datenübertragung über HTTP kann somit über Netzwerk- und Firewallgrenzen hinweg vonstatten gehen. Darin liegt u. a. der fundamentale Vorteil gegenüber beispielsweise CORBA (Transport-Protokoll-abhängig: ORB), RMI (Sprachen-abhängig: Java) und DCOM (Plattform-abhängig: Windows). Die nachfolgende Abbildung 1 zeigt den Protokoll-Stack eines Web-Service und zeigt die vier unterschiedlichen Schichten mit den jeweils eingesetzten Technologien. Service-Discovery & Publishing (UDDI) Service-Beschreibung (WSDL) XML-Messaging (SOAP, XML-RPC) Transport (HTTP,SMTP,FTP,BEEP) Abbildung 1: Übersicht des Protokoll-Stacks eines Web-Service nach [Cer02] Transport-Schicht: Diese Schicht ist für den Transport der Nachrichten über ein Netzwerk verantwortlich. Der darüber liegende Web-Service abstrahiert von dieser Schicht. Somit können in dieser Schicht unterschiedliche Protokolle zum Einsatz kommen, wie z.b. das Hyper Text Transport Protokoll (HTTP) [RFC2616], das Simple Mail Transport Protokoll (SMTP) [RFC821], das File Transfer Protokoll (FTP) [RFC959], oder auch neuere Protokolle, wie das Blocks Extensible Exchange Protocol (BEEP) [RFC3080]. Die Web-Service-Architektur beschreibt in den drei anderen, oberen Schichten die Funktionalität des Web-Service und ordnet in dieser vierten Schicht ein Transport-Protokoll zu.

17 Technologien 17 XML-Messaging-Schicht: Diese Schicht kodiert (verpackt) die Nachrichten in ein gängiges XML-Format, welches von allen Teilnehmern verstanden wird. Es findet eine Serialisierung der Daten in ein XML-basiertes Format statt (in der Literatur auch oft Marshalling genannt bei XML Remote Procedure Call-Aufrufen). Die Nachrichten können mit XML Remote Procedure Call (XML-RPC) und SOAP übertragen werden. SOAP wird in Kapitel 2.7 vorgestellt und RPC im Rahmen des Projekts Axis in Kapitel 3.1. Service-Beschreibung: In dieser Schicht wird mit Hilfe von einer Beschreibungssprache der Web-Service und dessen Schnittstelle (Interface) beschrieben, somit kann von der darunter liegenden Implementierung abstrahiert werden. Die Web Service Description Language (WSDL) bildet den De-facto-Standard zur Beschreibung von Web-Services. Die Autoren des Buches Webservice-Programmierung mit SOAP [STK02] benennen als weitere Beschreibungssprachen Ressource Description Framework (RDF) [BG04] und DARPA Agent Markup Language (DAML) [HHP+01]. Allerdings ist das primäre Einsatzgebiet von RDF der Austausch und das Verwenden von Metadaten im Internet und von DAML das Beschreiben von Objekten und deren Relationen zueinander. Diese beiden Beschreibungssprachen sind daher eher ergänzend als substituierend für WSDL anzusehen. Service Discovery und Publishing: Service-Anbieter (Provider) können mit Hilfe von UDDI ihren Service beschreiben und in einem öffentlichen Verzeichnis publizieren. Anwender benutzen dieses Verzeichnis, um vorhandene Web- Services zu suchen und danach in ihre Verarbeitung und Systeme einzubinden. Im Zusammenhang mit UDDI wird oft die Analogie zu den gelben Telefonbuchseiten gewählt, da beide eine ähnliche Suchfunktion bieten. WS-Inspection ist ein weiterer Mechanismus zum Finden von Web-Services [BEG+03]. Einige Autoren listen auch manchmal fünf Schichten innerhalb des Protokoll-Stacks auf, wie z.b. Kuschke und Wölfel in ihrem Buch Web Service kompakt [KW02] oder Snell et al. in dem Buch Webservice-Programmierung mit SOAP [STK02]. Diese Autoren fügen unterhalb der Transport- Schicht eine Netzwerk-Schicht ein und als Vertreter dieser Schicht das TCP/IP-Protokoll. Allerdings ist diese Beschreibung einer untersten Schicht überflüssig, da Web-Services letztendlich auf höherer Schicht beschrieben werden und von den darunter liegenden abstrahieren. Eine Haupteigenschaft von Web-Services ist gerade die Unabhängigkeit von Transport-Protokollen. Ein Web-Service kann abstrakt beschrieben werden, indem seine Funktionalität ohne konkrete Angaben über das Transport- Protokoll definiert wird. Einem Web-Service wird letztendlich ein Transport-Protokoll über eine Bindung zugeordnet. Also ist für die eigentliche funktionale Beschreibung des Web-Service die Transport-Schicht erst später bei der konkreten Bindung wichtig. Eine weitere Schicht unterhalb der Transport-Schicht ist zur Beschreibung eines Web-Service somit nicht nötig.

18 18 Technologien Web-Services können prinzipiell bei jeder verteilten, Netz-basierten Orchestrierung von Softwaresystemen eingesetzt werden. Einige Beispiele für Web-Services sind u. a. Reservierungsdienste, B2B- Anwendungen, Kostenabrechnungen, E-Commerce-Anwendungen, Sprachübersetzer, Meldedienste (Wetter, Verkehr, Börseninformationen), verteilte Geschäftsprozesse und Rechnungssysteme 1. Nach der Definition von Web-Services und deren Einordnung in den zugrunde liegenden Protokoll- Stack, folgt nun die Einordnung eines Web-Service in die Service-orientierte Architektur Service-orientierte Architektur In diesem Unterkapitel wird zunächst erklärt, was eine Service-orientierte Architektur (SOA) ist, und wie sie definiert wird. Danach wird ein Zusammenhang zu Web-Services hergestellt, da diese eine spezielle Ausprägung und Realisierung der SOA darstellen. SOA basieren auf einem verteilten System, in dem diverse Service-Anbieter Dienste zur gegenseitigen Benutzung zur Verfügung stellen, um eine gemeinsame Aufgabe zu erledigen. Ein Service-Anbieter stellt den anderen Service-Nutzern eine Schnittstelle bereit, um den dahinter stehenden Dienst zu benutzen. Ein Service-Anbieter stellt seine Dienste durch eine Applikation, ein Legacy-System, ein Ausgabegerät oder eine Computereinheit zur Erbringung eines Dienstes bereit. Bei der Bereitstellung eines Dienstes ist lediglich das Interface zur Benutzung für andere Teilnehmer von Interesse, die darunter liegende Implementierung ist transparent gehalten. Somit kann diese beliebig verändert oder gänzlich ausgetauscht werden, solange sich dadurch die Schnittstelle für den Dienst nicht verändert. Die Schnittstelle definiert dabei die Funktionsweise des Dienstes und legt das Format der Nachrichten fest. Sämtliche Anbieter und Nutzer kommunizieren dabei durch Nachrichtenaustausch über Transport-Protokolle miteinander, um die vorliegende Aufgabe zu bearbeiten. In diesem verteilten System entsteht somit eine dynamische Orchestrierung unterschiedlicher Systeme. Je nach vorliegendem Aufgabenproblem arbeiten verschiedene einzelne Services zusammen, die nach Erledigung der Aufgabe wieder in neuer Konstellation zusammen arbeiten können. Aus dieser Definition von SOA wird deutlich, dass ein Web-Service auf dem Prinzip der SOA beruht und diese Architektur erweitert. Bei Web-Services erfolgt der Nachrichtenaustausch in XML-basierten Formaten und daher unabhängig von der jeweils benutzten Plattform und Programmiersprache. Abbildung 2 schematisiert die Zusammenarbeit von Anbietern, Nutzern und Registrierung und stellt die Service-orientierte Architektur übersichtlich dar. In dieses allgemeine Schaubild der SOA wird der Einsatz der Web-Service-Technologien WSDL, UDDI und SOAP eingebettet und somit der Zusammenhang zwischen SOA und Web-Services nochmals verdeutlicht. 1 Internetadresse mit einigen Web-Service-Beispielen:

19 Technologien 19 Service UDDI, Registry WSDL find publish UDDI Service bind Service Requestor SOAP Provider Abbildung 2: Service-orientierte Architektur mit Web-Service-Technologien Der Dienst-Anbieter ( Service Provider in Abb.2) publiziert ( publish in Abb.2) mittels UDDI eine Schnittstellen- und eine Dienstbeschreibung im Service-Verzeichnis ( Service Registry in Abb.2). Der Dienst-Anbieter ist verantwortlich für die Implementierung, Inbetriebnahme und Wartung des angebotenen Dienstes. Ein Dienst-Nutzer (in der Literatur oft als Client bezeichnet, Service Requestor in Abb.2) kann innerhalb des Service-Verzeichnisses nach Diensten und Dienst-Anbietern suchen. Die Suche kann über eine API oder Suchmaske von UDDI erfolgen. Das Service-Verzeichnis, auch Dienst-Makler (Service Broker) genannt, bietet eine Verwaltung und Speicherung der Dienstbeschreibungen für Web-Services an. Findet ( find in Abb.2) ein Dienst-Nutzer einen Dienst, so erhält er in Form eines WSDL-Dokumentes eine Schnittstellenbeschreibung des vorliegenden Service. Der Dienst-Nutzer kann den Service des Dienst-Anbieters direkt in seine Applikationen integrieren und nutzen ( bind in Abb.2). Zum Senden der Nachrichten wird ein Protokoll der XML-Messaging- Schicht verwendet, in der vorliegenden Arbeit wird sich dabei auf SOAP beschränkt. Die Mächtigkeit dieser Architektur besteht darin, dass Aufgaben gemeinschaftlich durch verschiedene Dienst-Anbieter Plattform-unabhängig und über Organisationsgrenzen hinweg verteilt gelöst werden [Bur04]. 2.2 Grundlagentechnologie: XML Die Extensible Markup Language (XML) ist seit 1998 eine W3C-Empfehlung (Recommendation) [BPS+04]. XML ist eine einfache, strukturierte Datenbeschreibungssprache, die von der Standard Generalized Markup Language (SGML) abgeleitet wurde. XML ist eine Markupsprache zur strukturierten, wohlgeformten Darstellung von Daten und dabei unabhängig von Hersteller und Programmiersprachen. An dieser Stelle wird nicht auf die XML-Spezifikation eingegangen, sondern es soll die Bedeutung von XML für die Benutzung von Web-Services herausgestellt werden. Der offene Standard XML ist mehr als nur eine technische Spezifikation, denn XML hat die Entwicklung der vernetzten Welt beeinflusst. Die Entwicklung neuer Technologien (z.b.: WSDL, UDDI und SOAP) bauen dabei

20 20 Technologien auf der Basistechnologie XML auf. Zusätzlich ist XML als Schüsseltechnologie zum Datenaustauschformat zwischen Programmen in verteilten Systemen avanciert. Frank P. Coyle geht in dem Buch XML, Web Services, and the Data Revolution sogar soweit, dass er von drei Revolutionen ausgeht, die XML in den letzten Jahren auslöste [Coy02]: Früher waren Daten stark an das Format einer Applikation gebunden, quasi jedes Programm benutzte sein eigenes Datenformat. XML löste diese spezifischen Datenformate in einer Datenrevolution ab, da XML unabhängig von Programmiersprachen und Betriebssystemen ist. Ferner ist XML unabhängig von Transport-Protokollen und somit müssen Daten nicht an Formate von bestehenden Technologien wie CORBA, RMI und DCOM angepasst werden. Diese Objekt-basierten Systeme sind nicht kompatibel zueinander und erschweren einen Datenaustausch über die Systemgrenzen hinweg. XML ermöglichte also eine Architekturrevolution, da XML als Netzwerk-Protokoll TCP/IP verwenden kann und somit mit jedem verteilten System kommunizieren vermag. Schließlich bewirkte der Einsatz von XML und Web-Services eine Softwarerevolution. Einfache Prozesse, Services, Geschäftsprozesse und sogar Legacy-Systeme können nun kombiniert werden, um zusammen Aufgaben zu bearbeiten. Durch die neue Möglichkeit der Interoperabilität stehen den Entwicklern von Programmen neue Wege offen. XML legte den Grundstein für die Entwicklung neuer Technologien und letztendlich auch zum Etablieren von Web-Services. 2.3 Datenschema: XSD Die XML Schema Definition Language (XSD) ist in der Version 1.0 seit dem eine Empfehlung (Recommendation) des W3C [FW04]. Diese Datenbeschreibungssprache wird im Rahmen dieser Diplomarbeit zum Spezifizieren von Datentypen in WSDL verwendet und daher näher untersucht. In Kapitel 4.3 werden Aufbau und Struktur von XSD vertieft, wenn die Konvertierung von Datentypen in grafische Konstrukte und Validierungskomponenten erklärt wird. Innerhalb der Modellbildung stellt XSD einen zentralen Punkt dieser Diplomarbeit dar. Zum einen wird die GUI anhand der vorliegenden Datentypen dynamisch generiert. Ein Zahlenwert wird z. B. anders grafisch dargestellt als ein selbstdefinierter, komplexer Datentyp. Zum anderen findet eine Validierung der Daten statt, falls Restriktionen für einen Datentypen in XSD durch Fassetten angegeben werden. XSD bietet ein Vokabular um Struktur und Inhalte von Datentypen innerhalb eines WSDL-Dokumentes zu definieren und ist selbst ein XML-Dokument. XSD definiert einerseits eine Reihe von Basisdatentypen (siehe Übersicht der Datentyp-Hierarchie in XSD im Kapitel 4.3) und erlaubt die Definition eigener Datentypen und explizite Behandlung von Namensräumen. Diese neuen Datentypen können aus Basisdatentypen aufgebaut und durch eigene Restriktionen erweitert werden. Somit hat der Entwickler von Web- Services ein mächtiges Instrumentarium zur Verfügung zum Entwickeln Problem-bezogener Datenstrukturen. XML-Daten könnte man auch mit der Document Type Definition (DTD) beschreiben. DTD überprüft genauso wie XSD die Korrektheit und Wohlgeformtheit der XML-Daten. DTD weist

21 Technologien 21 allerdings erhebliche Nachteile im Vergleich mit XSD auf und ist für den Einsatz innerhalb eines WSDL-Dokumentes nicht geeignet. DTD s werden in der Extended Backus Naur Form (EBNF) und nicht in XML-konformer Syntax verfasst. Somit müsste man ein DTD in ein XML-Tag einbetten, um es zusammen mit dem WSDL-Dokument zu versenden. Zusätzlich unterstützt DTD keine Namensräume, somit entstehen durch den Import-Mechanismus Namenskollisionen. Des Weiteren werden keine Deklarationen von eigenen Datentypen unterstützt und DTD definiert selbst nur 10 Datentypen. XSD unterstützt im Gegensatz dazu 44 Datentypen und erlaubt die Bildung von eigenen Datentypen. Aus diesen Gründen ist die Verwendung von DTD sehr ungeeignet. Zur Erstellung des Modells und zur Implementierung des Prototypen wurde deshalb ausschließlich XSD verwendet. 2.4 Web Service Description Language 1.1 (WSDL) Die Web Services Description Language (WSDL) ist eine XML-basierte Schnittstellen- Beschreibungssprache, mit deren Hilfe man Web-Services als eine Menge von Endpunkten beschreiben kann, die untereinander Nachrichten austauschen. Der Austausch und die gesendeten Nachrichten selbst werden abstrakt beschrieben. Danach werden sie an ein konkretes Transport- Protokoll und Nachrichtenformat gebunden, um so einen Endpunkt genau zu definieren. Von Microsoft, IBM und Ariba wurde WSDL entwickelt und das W3C brachte zunächst am 15.März 2001 Version 1.1 [CCMW01] als W3C Note 1 zur Diskussion heraus, bevor am 11.Juni 2003 Version 1.2 [CGMW04] als W3C Working Draft 2 herausgebracht wurde. Zurzeit liegt die Version 2.0 [CGM+04] seit dem 26.März 2004 als W3C Working Draft vor. Zur Diskussionsgrundlage wird in der vorliegenden Arbeit Version 1.1 herangezogen und am Ende des Unterkapitels ein Vergleich mit Version 2.0 durchgeführt. Werkzeuge, die WSDL parsen und Java-Code generieren, unterstützen zurzeit lediglich Version 1.1. Durch den Vergleich von WSDL 1.1 und WSDL 2.0 wird deutlich, dass der Kern der Sprache erhalten bleibt und lediglich an den genannten Stellen erweitert wird. Ein Update von Version 1.1 auf 2.0 würde keine großen Erweiterungen für die prototypische Implementierung des Modells verursachen und die Ergebnisse dieser Diplomarbeit nicht revidieren bzw. beeinflussen. Das W3C definiert WSDL folgendermaßen: The Web Services Description Language WSDL Version (WSDL) defines an XML grammar for describing network services as collections of communication endpoints capable of exchanging messages. WSDL service definitions provide documentation for distributed systems and serve as a recipe for automating the details involved in applications communication. 1 W3C Note: Das vom W3C veröffentlichte Dokument hat einen formellen Zustimmungsprozess durchlaufen und wird veröffentlicht. Von Seiten des W3C gibt es keine Garantie der Weiterbearbeitung 2 W3C Working Draft: Ein vom W3C veröffentlichtes Dokument zur Einsicht und Diskussion durch die Öffentlichkeit, Veränderungen werden vorbehalten.

22 22 Technologien Durch diese Definition wird ein weiterer wichtiger Aspekt von WSDL verdeutlicht, nämlich die automatische Integration durch Applikationen. WSDL ist nicht nur von Benutzern lesbar, sondern auch direkt von Applikationen. Dadurch sind Applikationen in der Lage nach dem Parsen des WSDL- Dokumentes den beschriebenen Service just in time in die eigene Verarbeitung einzubinden und zu nutzen. Dies ist auch der zentrale Ansatzpunkt dieser Diplomarbeit. Der zu entwickelnde Prototyp nimmt ein WSDL-Dokument entgegen und generiert dynamisch daraus die GUI, die der Benutzer zum Editieren der Anfrage und Anzeigen der Antwort verwendet. Bevor im nächsten Unterkapitel der allgemeine Aufbau von WSDL erörtert wird, soll zunächst eine Abgrenzung zwischen WSDL und der Interface Definition Language (IDL) aus der CORBA-Welt herausgestellt werden. IDL, sowie auch WSDL, beschreiben beide die Schnittstelle für einen entfernten Service und dessen Datentypen. Die einzelnen Komponenten der beiden Beschreibungssprachen sind sich sehr ähnlich: IDL-Types entsprechen WSDL-Types, IDL-Methoden korrespondieren zu WSDL-Operationen, IDL-Interfaces zu WSDL-Porttypes und IDL-CORBA- Objekte korrespondieren zu WSDL-Services. IDL ist eine Textdatei, die einen Service mit dessen Methoden und Parametern beschreibt. Diese Beschreibung erfolgt Programmiersprachen-unabhängig. Der Object Request Broker (ORB) nimmt lokale Aufrufe entfernter Objekte entgegen und leitet diese an den Service weiter. Die XML-basierte WSDL bietet ebenfalls eine Datenunabhängigkeit von verwendeten Programmiersprachen, allerdings auch Unabhängigkeit von verwendeter Middleware und Transport-Protokoll, was bei IDL und CORBA nicht gegeben ist. WSDL kann ebenfalls erweitert werden, somit können Nachrichten unabhängig von Protokoll und Format beschrieben werden Aufbau eines WSDL-Dokumentes Der Aufbau eines WSDL-Dokumentes wird nun näher erläutert und die einzelnen Elemente spezifiziert. Sämtliche Informationen sind aus der W3C Note WSDL 1.1 vom 15.März 2001 entnommen [CCMW01]. Zunächst sollen alle Elemente kurz andiskutiert und in Relation zueinander gestellt werden, bevor danach jedes Element im Detail erklärt wird. Ein WSDL-Dokument ist hierarchisch aufgebaut wobei das Definitions-Element (<definitions>) das Wurzelelement bildet und als Container für die anderen Elemente dient.

23 Technologien 23 Die allgemeine Struktur eines WSDL-Dokumentes 1 : <definitions targetnamespace="xs:anyuri" > <documentation />? [ <import /> ]* <types />? [ <message /> <porttype /> <binding /> <service /> ]* </definitions> Das Definitions-Element beinhaltet als Attribute alle Namensraumdeklarationen des WSDL- Dokumentes. Hier werden neben dem Zielnamensraum (targetnamespace) der Elemente auch weitere Namensräume deklariert (u. a. Namensräume der verwendeten XSD-, SOAP-, WSDL- Version und eigene Namensräume) und jeweils einem Präfix zugeordnet. Das nachfolgende Beispiel zeigt die Verwendung von Präfixen und Namensräumen innerhalb des Definitions-Elementes. <wsdl:definitions xmlns:mynamespace1=" xmlns:mynamespace2=" xmlns:xsd=" </wsdl:definitions> In dem obigen Beispiel wird dem Präfix mynamespace1, mynamespace2 und xsd jeweils ein separater Namensraum zugeordnet. Der Präfix xsd steht nun als Stellvertreter innerhalb dieses Dokumentes für den Namensraum des XML-Schemas und mynamespace1 repräsentiert einen selbst festgelegten Namensraum, mynamespace2 analog dazu. Durch Zuordnung von Namensräumen zu einzelnen Elementen wird deren eindeutige Identität gewahrt. Lokale Namen von Elementen können mehrfach vergeben werden. Eine Unterscheidung findet dann über den unterschiedlichen Namensraum statt. Elemente werden aus diesem Grund durch einen qualifizierten Namen (QName) angesprochen. Ein qualifizierter Name stellt einen XML-qualifizierten Namen dar, der eindeutig durch einen Namensraum und einen lokalen Namen spezifiziert ist. Das nächste Beispiel zeigt die Verwendung von qualifizierten Namen zur eindeutigen Ansprache von Elementen. <wsdl:complextype > <xsd:element name="company_address" type="mynamespace1:address"/> <xsd:element name="private_address" type="mynamespace2:address"/> </wsdl:complextype > Innerhalb eines nicht weiter spezifizierten komplexen Datentyps werden zwei weitere komplexe Datentypen referenziert, die beide den gleichen lokalen Namen Address aufweisen. Ohne Verwendung eines qualifizierten Namens wäre eine Unterscheidung der zwei unterschiedlichen Datentypen nicht möglich. Die Eindeutigkeit wird durch die Zuordnung des Namensraumes in Form des Präfixes bewahrt. 1 Informale Syntax: "?" (0 oder 1), "*" (0 oder mehr), "+" (1 oder mehr)

24 24 Technologien Weiterhin können optional Dokumentationen für den Anwender zum besseren Verständnis des WSDL-Dokumentes im Dokumentations-Element (<documentation>) angeführt werden (siehe Kapitel 4.5) und weitere Dokumente durch das Import-Element (<import>) eingebunden werden (nächstes Unterkapitel). Das Datentyp-Element (<types>) wird zum Festlegen komplexer Datentypen verwendet und in Kapitel 4.4 untersucht. Zunächst sollen aber die vier Hauptelemente und deren Kindelemente eines WSDL-Dokumentes näher betrachtet werden. Abbildung 3 zeigt dazu eine schematische Übersicht über diese Elemente und deren Relationen zueinander. WSDL-Dokument Service Port Port Binding Binding Binding konkretes Level Porttype Operation Operation Porttype abstraktes Level Message Message Message Message Abbildung 3: vereinfachter Aufbau eines WSDL-Dokumentes Ein WSDL-Dokument beinhaltet ein Service-Element (<service>). Dieses Element gruppiert alle verwendeten Port-Elemente (<port>) und beinhaltet somit eine Kollektion von einem oder mehreren Ports. Jeder Port wird wiederum durch ein Anbindungs-Element (<binding>) an ein konkretes Transport-Protokoll und Nachrichtenformat gebunden. Neben der Bindung wird jeder Port zusätzlich durch einen Porttyp detailliert beschrieben. Das Porttyp-Element (<porttype>) beinhaltet mehrere Operationen, ohne Angaben über den Transport-Mechanismus anzugeben. Jedes Operations-Element (<operation>) ist letztendlich eine Kollektion von ein- und ausgehenden Nachrichten und legt deren Sequenz und Kardinalität fest. Ein Nachrichten-Element (<message>) stellt die Basis- Kommunikationseinheit dar und beinhaltet die gesendeten Daten. Die einzelnen Elemente können zur besseren Übersicht in zwei Levels unterteilt werden. Im konkreten Level werden das Service-Element (mit dem Port-Element als Kindelement) und das Anbindungs- Element gruppiert. Diese drei Elemente beschreiben wie der Web-Service an ein Transport-Protokoll

25 Technologien 25 gebunden wird und unter welcher Adresse er zu kontaktieren ist. Der Web-Service wird also auf konkreter Ebene beschrieben. Im abstrakten Level (Porttyp- und Nachrichten-Element) wird von der konkreten Realisierung abstrahiert und lediglich die Daten zum Nachrichtenaustausch festgelegt. Zum abstrakten Level werden ebenfalls die optionalen Datentyp-Elemente (<types>) gezählt, die die Parameter der Nachrichten spezifizieren. Datentyp-Elemente werden allerdings nur bei Verwendung von selbst definierten, komplexen Datentypen verwendet und daher in dieser allgemeinen Übersicht nicht berücksichtigt. Während das konkrete Level die Frage Wie wird der Web-Service angesprochen? beantwortet, beschäftigt sich das abstrakte Level nur um das Was der Web-Service leistet?. Anhand des in der Einleitung bereits erwähnten Beispiels des Taschenrechner-Web-Service sollen die einzelnen Elemente nochmals anschaulich beschrieben werden. Bei diesem Beispiel in Abbildung 4 wird nicht auf die interne Darstellung der einzelnen Elemente eingegangen, sondern ein Gesamtüberblick dargestellt und von einigen Details abstrahiert. Innerhalb der einzelnen Elemente mussten zur besseren Übersicht Interna weggelassen werden. Im Anhang 8.4 befindet sich das komplette WSDL- Dokument.

26 26 Technologien <wsdl:definitions targetnamespace=" xmlns:calns=" <wsdl:message name="addrequest"> <wsdl:part name="addend1" type="xsd:int"/> <wsdl:part name="addend2" type="xsd:int"/> </wsdl:message> <wsdl:porttype name="calculator"> <wsdl:operation name="add" parameterorder="addend1 addend2"> <wsdl:input message="calns:addrequest" name="addrequest"/> <wsdl:output message="calns:addresponse" name="addresponse"/> </wsdl:operation> </wsdl:porttype> <wsdl:binding name="calsoapbinding" type="calns:calculator"> <wsdlsoap:binding style="rpc" transport=" /soap/http"/> <wsdl:operation name="add"> <wsdl:input name="addrequest"></wsdl:input> <wsdl:output name="addresponse"></wsdl:output> </wsdl:operation> </wsdl:binding> <wsdl:service name="prototype_service"> <wsdl:port binding="calns:calsoapbinding" name="calculator"> <wsdlsoap:address location=" </wsdl:port> </wsdl:service> </wsdl:definitions> Abbildung 4: WSDL-Dokument des Taschenrechner-Web-Service Das Port-Element repräsentiert den Taschenrechner-Web-Service. Dieser Port kann nun mit mehreren anderen Ports in einem Service-Element spezifiziert werden. Das Service-Element würde somit unterschiedliche Web-Services beinhalten und eine Gruppierung dieser vornehmen. Durch das Anbindungs-Element wird dem Taschenrechner-Web-Service das Transport-Protokoll SOAP zugeordnet. Im Porttyp-Element werden die einzelnen erlaubten Operationen des Services festgelegt. In diesem Beispiel besteht der Web-Service aus den beiden Operationen Addition und Subtraktion. Für die Operation Addition wird dann im Operations-Element die ein- und ausgehenden Nachrichten festgelegt. Diese Operation besteht lediglich aus einer eingehenden Nachricht (beide Summanden als Parameter) und einer ausgehenden (Summe als Parameter). Für beide Nachrichten wird schließlich im Nachrichten-Element die Datentypen der Parameter festgelegt. Für die ausgehende Nachricht wären das zwei Ganzzahlwerte (int).

27 Technologien 27 Nachfolgend werden die wichtigsten Elemente eines WSDL-Dokumentes aufgelistet und detailliert erläutert. Durch das Präfix wsdl wird verdeutlicht, dass es sich um ein WSDL-Element handelt. Die Elemente von Datentyp-Deklarationen in XSD verwenden als Präfix xsd und können somit von WSDL-Elementen unterschieden werden. Sämtliche Elemente können durch ein Dokumentations- Element direkt im WSDL-Dokument näher beschrieben und erläutert werden. <wsdl:documentation> Die Dokumentation erläutert das umschließende Element. </wsdl:documentation> Innerhalb des Tags <documentation> kann eine Erläuterung zum dem Vaterelement angegeben werden. <types> Dieses Element beinhaltet Datentyp-Definitionen zum Spezifizieren der Datentypen innerhalb einer Nachricht. Um Plattformunabhängigkeit zu gewährleisten und eine Standardisierung festzulegen, wird die XML Schema Definition Language zur Definition der Datentypen verwendet. Alternativ könnte man auch andere Datenschemata nehmen, wie z.b. Document Type Definition (DTD), Relax NG 1, Abstract Syntax Notation (ASN.1) 2 oder falls man ausschließlich mit CORBA-Objekten kommuniziert das CORBA-Typsystem. Diese Datenschemata spielen allerdings in der Praxis im Bezug auf Web- Services eher eine untergeordnete Rolle. Die Struktur dieses Elementes: <wsdl:types> <xsd:schema... />* </wsdl:types> Die Verwendung des Datentyp-Elementes ist optional, je nach der Komplexität der verwendeten Datentypen bei einem Web-Service. Benötigt man lediglich einfache Datentypen (z. B. einen Zahlenwert ohne besondere Restriktionen als Parameter), so muss man diesen einfachen Datentyp nicht extra definieren. Einfache Datentypen werden implizit durch den Namensraum von XSD festgelegt. Wird allerdings als Parameter ein komplexerer Datentyp (z. B. eine Adresse bestehend aus Name und Anschrift) verwendet, so muss dieser Datentyp in einem Datentyp-Element näher spezifiziert werden. Diese einfachen und komplexen Datentyp-Definitionen können zum Teil sehr umfangreich werden, da alle sprachlichen Mittel von XSD zur Verfügung stehen. Aus diesem Grund werden die Datentyp- Definitionen im Kapitel 4.3 separat behandelt. 1 weitere Informationen zu Relax NG findet man unter 2 ITU-T Recommendation X.680, weitere Informationen findet man unter