Studienarbeit im Fach: Aktuelle Technologien zur Anwendung verteilter Java-Anwendungen

Transkript

1 Studienarbeit im Fach: Aktuelle Technologien zur Anwendung verteilter Java-Anwendungen EINE ABHANDLUNG ZUM THEMA WEBSERVICES Christian Kreipl Hochschule München

2 Inhaltsverzeichniss 1. Einleitung Struktur eines Web Service 3 2. XML 4 3. Web Service Definition Language Struktur einer Web Service Definition Language 5 4. SOAP Aufbau einer SOAP-Nachricht 9 5. Web Services in Java mit JAX-WS Annotationen in JAX-WS Erstellen einer Beispielapplikation mit JAX-WS und NetBeans Benötigte Software und Addons Erstellen des Web Services Erstellen einer Zugriffsapplikation 18 Christian Kreipl / Hochschule München Seite - 1 -

3 Abbildungsverzeichniss 1. Struktur eines Web Service 4 2. Unterschiede WSDL 1.0 WSDL Codebeispiele verschiedener Bindingarten 8 4. Flussdiagram ; SOAP-Protokol 9 5. Aufbau eines SOAP-Dokumentes Aufbau eines SOAP-Dokumentes Codebeispiel Abbildungen; Beispielapplikation JAX-WS 7.1 Ordnerstruktur Web Service Designansicht Parametererstellung in NetBeans Code Web Service Testansicht des Web Service im Browser Ergebnisausgabe Division SOAP-Nachrichten zu Ergebnisausgabe Division Ordnerstruktur Zugriffsapplikation Code Zugriffsapplikation Ergebnisausgabe Zugriffsapplikation 20 Christian Kreipl / Hochschule München Seite - 2 -

4 1. Einleitung TODAY, THE PRINCIPAL USE OF THE WORLD WIDE WEB IS FOR INTERACTIVE ACCESS TO DOCUMENTS AND APPLICATIONS. IN ALMOST ALL CASES, SUCH ACCESS IS BY HUMAN USERS, TYPICALLY WORKING THROUGH WEB BROWSERS, AUDIO PLAYERS, OR OTHER INTERACTIVE FRONT-END SYSTEMS. THE WEB CAN GROW SIGNIFICANTLY IN POWER AND SCOPE IF IT IS EXTENDED TO SUPPORT COMMUNICATION BETWEEN APPLICATIONS, FROM ONE PROGRAM TO ANOTHER. 1 Als in den 1969 bis 1970 die Grundsteine des Internet wie wir es heute kennen- gelegt wurden, waren die Präferenzen an das Netz noch klar gesteckt. Bis heute aber haben wir im Bereich des WorldWideWeb einen großen Fortschritt erlebt. War damals noch die für einen Großteil des Datenvolumens verantwortlich, besteht das Netz heute hauptsächlich aus dynamischen Webseiten mit verschiedensten Inhalten. Eines allerdings hat sich sehr lange Zeit nicht geändert, der Mensch als Konsument der vom Web bereitgestellten Daten. Dies änderte sich mit der Einführung verschiedenster Technologien wie verteilter Architektur, Client-Server-Systemen, Dezentralisierung oder Grid-Computing, die eine immer größere Rolle in der heutigen IT-Landschaft spielen. Es war nötig, ein System im Web zu schaffen, das von Computern und Anwendungen gelesen und verstanden werden konnte. Dies war die Startstunde der Web Services. Heutzutage treffen wir an den verschiedensten Orten auf solche Services. Bei der Bedienung von Geldautomaten tauschen diese sich automatisch mit deren Server aus, um unseren Kontostand zu prüfen. Bei der Online-Flugbuchung tauscht sich die Webseite automatisch mit dem Server der Fluggesellschaft aus, um uns den aktuellen Flugpreis mitzuteilen. Web Services agieren im Hintergrund aber sind aus unserer heutigen Informationsgesellschaft nicht mehr wegzudenken. 1.2 Struktur eines Webservice Ein Webservice ist wie der Name schon sagt, ein Service welcher über ein Netzwerk (hier das Internet) angeboten wird. Der Service wird von einem sog. Service-Anbieter (auch Provider genannt) angeboten. Der Service-Konsument (auch Consumer genannt) kann diesen Service nun abrufen. Ein Webservice arbeitet also nach dem Provider-Consumer-Prinzip. Der Datenaustausch zwischen den Komponenten erfolgt i.d.r. über das Protokoll SOAP, einem auf XML basierendem Standard welcher von dem World Wide Web Consortium (W3C) verwaltet wird. Der Webservice an sich wird per WSDL (Web Service Definition Language) beschrieben. Auch dieser baut auf XML auf und definiert im Wesentlichen die öffentlich zugänglichen Operationen des Services. 1 Auszug aus der W3C XML ProtocolWorking Group Charta ( Christian Kreipl / Hochschule München Seite - 3 -

5 Die Instanz des Service Broker leistet die Vermittlungsarbeit zwischen den Services. Des Weiteren findet man auf dieser Ebene auch das UDDI (Universal Description, Discovery and Integration), einen Verzeichnisdienst verschiedener Webservices. Dieser Dienst wurde unter anderem von Microsoft, SAP und IBM unterstützt und kann als ein internationales, standardisiertes (WebService)Telefonbuch verstanden werden. Ende 2005 sorgte eine Nachricht über die Abschaltung 2 der Business Registry für heftigen Wirbel in der Szene und mancherorts wurde das Projekt WebServices für gescheitert erklärt. 3 Abb. 1 // WebService Struktur // Wikipedia 2. XML XML (Extensible Markup Language) ist eine Auszeichnungssprache zur Darstellung hierarchisch strukturierter Datensätze. XML ist eine Spezifikation, herausgegeben vom W3C. Das Prinzip der Web Services baut stark auf der Sprache XML auf. WSDL, wie auch SOAP sind im Grunde nichts anderes als speziell ausgezeichnete XML Nachrichten. Der Vorteil dieser Methode ist die Entkoppelung der Nachrichten von den erstellenden Programmiersprachen und Betriebssystemen. Das Prinzip der Interoperabilität ist ein wesentlicher Grund, weshalb XML als Auszeichnungssprache für Web Services gewählt wurde. Ein weiterer Vorteil ist der International geltende Standard, der beschreibt, wie eine XML- Nachricht auszusehen hat. Dieser Standard wird von dem World Wide Web Consortium 4 (kurz: W3C) festgelegt und ist bindend für alle Applikationen. 2 UBR Shutdown FAQ ( 3 InfoWorld.com zur Abschaltung von UDDI 4 Webseite des W3C ( Christian Kreipl / Hochschule München Seite - 4 -

6 3. Web Service Definition Language Die Web Service Definition Language (kurz: WSDL) beschreibt die Charakteristik eines Web Services. Sie steht zurzeit in zwei Versionen zur Verfügung. WSDL 1.1 wurde dem W3C im Jahr 2001 zugetragen. Im Jahr 2002 wurde die Web Service Description Working Group 5, mit dem Zweck die WSDL zu standardisieren, gegründet. Im Jahr 2007 verabschiedete das W3C die Version 2.0 des WSDL-Standards 6. Als eine der Neuerungen wird vor allem die nun vollständige Unterstützung vom HTML angepriesen. In vielen Fällen ist WSDL 2.0 einfacher, weniger mächtig aber dennoch besser benutzbar als die Vorgängerversion. Abb. 2 zeigt die wesentlichen Unterschiede im Aufbau beider Versionen der WSDL-Dokumente. 3.1 Struktur einer WSDL Abb. 2 // WSDL1.1 WSDL2.0 Unterschiede 5 Webseite der Web Service Description Working Group: 6 Heise Artikel WSDL2.0 Release ( Christian Kreipl / Hochschule München Seite - 5 -

7 Im Folgenden werden durch eine Auflistung die Elemente eines WSDL-Dokuments beschrieben. (Wir halten uns im Weiteren an Version 1.1, da diese immer noch von vielen Applikationen genutzt wird) Definition (in WSDL2.0 Description) Beinhaltet den Namen des WebService und den Namespace des Dokuments. Type Beinhaltet die Daten Typen welche zwischen Client und Server benutzt werden. Message (in WSDL 2.0 nicht mehr vorhanden) Das Message-Element enthält die Botschaft die der Service zur Verfügung stellt. Eine Message kann aus einer oder mehreren Teilen bestehen, wobei jeder Teil für sich eine Nachricht darstellt. Port Type (in WSDL 2.0 Interface Name) Das Port Type Element kombiniert eine oder mehrere Messages miteinander um eine Operation herzustellen. WSDL 1.1 stellt vier Operationen zur Verfügung. One-Way Repräsentiert eine eingehende Nachricht auf die der Service nicht antwortet. Request-Response Repräsentiert eine eingehende Nachricht auf die der Service antwortet. Solicit-Response Der Service sendet eine Nachricht und erwartet eine Nachricht. Notification Der Service sendet eine Nachricht, ohne eine Antwort zu erwarten. In WSDL 2.0 wurde, im Austausch der oben genannten, das Konzept der Nachrichtenaustauschmuster (Message Exchange Patterns[MEP]) eingeführt. Ein MEP beschreibt eine Vorlage für den Austausch von Nachrichten zwischen zwei SOAP- Knoten. Binding Das Binding Konstrukt gibt an, nach welcher Methode der Service an ein Messaging- Protocol (z.b. SOAP) gebunden werden soll, wie er formatiert wird, wie genau die Kommunikationsdaten zwischen den Kommunikationspartnern ausgetauscht werden. Es gibt zwei Arten von Binding Styles, RPC (Remote Procedure Call) und document. SOAP unterstützt weiterhin die Encoding-Typen literal und encoded, das ergibt vier mögliche Style-Models. Als zusätzliches Model gibt es noch document/literal wrapped, somit also fünf unterschiedliche Models. Auf die Modis RPC/(encoded) und document/literal (wrapped) möchte ich etwas genauer eingehen. Christian Kreipl / Hochschule München Seite - 6 -

8 RPC/(encoded) Bei der Methode RPC/(encoded) wird ein entfernter Prozeduraufruf durchgeführt (wie der Name schon verrät). Der Aufruf wird mit 0 bis n Parametern aufgerufen und gibt 0 oder einen Rückgabewert zurück. Die Codierung RPC/encoded ist nicht Standard der WS-I 7, weshalb es zu empfehlen ist, stattdessen auf RPC/literal umzusteigen. Document/literal Bei der Methode Document/literal wird ebenfalls ein Parameter übergeben, allerdings in Form eines Dokumentes. Die Rückgabe stellt ebenfalls ein Dokument dar, was den Vorteil hat, dass der Rückgabewert beliebig komplex gestaltet werden kann. Die Dokumente sind durch ein XML-Schema exakt beschrieben, dadurch fällt die Codierung sehr komplex aus, ist dafür aber auch sehr mächtig. RPC vs. Document In der Literatur ist man sich einig, dass Document der elegantere Weg ist, Web Services zu kodieren. Dies liegt an der Form der Verpackung der Nachrichten. Bei einem dokumentenorientierten Service wird der gesamte Vorgang in einem Dokument übertragen, d. h. das Dokument enthält alle relevanten Informationen zur Durchführung des Vorgangs, unabhängig davon, in welcher Reihenfolge diese von der Gegenseite bearbeitet wird. Dadurch entsteht eine wesentlich losere Koppelung der Daten. Document Codierungen werden häufig in Bereichen eingesetzt, in denen komplexe Transaktionsmuster bearbeitet werden müssen, z. B. die Abwicklung einer Verkaufsorder. Allerdings liegt hier auch ein Nachteil dieser Codierung, möchte man nämlich nur einen einzelnen(simplen) Wert abfragen, wäre eine Document -Codierung viel zu übertrieben. In diesem Fall ist es von Vorteil auf RPC zu setzten. Document/literal wrapped Document/literal wrapped ist eine Erweiterung der Document/literal Codierung mit dem Ziel, die WSDL Nachricht verständlicher (für den Programmierer) zu machen. Erreicht wird dies durch eine eindeutige Identifizierung der Operationen und Parameter. Dadurch wird die WSDL leichter zu lesen, aber auch umfangreicher was den Platz angeht. In Java ist die Anwendung von Document/literal wrapped der de Facto Standard. 7 Web Service Interoperability Christian Kreipl / Hochschule München Seite - 7 -

9 Beispiel zu den verschiedenen Binding Arten Wir sehen in Abb. 3 eine Implementierung folgender Methode: public void mymethod(int x, float y); Die verschiedenen Implementierungen sollen die Unterschiede der vorgestellten Binding-Formen näher veranschaulichen. An diesem Beispiel kann man gut erkennen, welche Implementierungsformen welchen Aufwand erfordern. Gut erkennen lässt sich der Aufwand, der für eine Implementierung in Document/literal Wrapped aufzubringen ist. WSDL RPC/encoded Document/literal Document/literal Wrapped <message name="mymethodrequest"> <part name="x" type="xsd:int"/> <part name="y" type="xsd:float"/> </message> <message name="empty"/> <porttype name="pt"> <operation name="mymethod"> <input message= "mymethodrequest"/> <output message="empty"/> </operation> </porttype> <binding.../> <types> <schema> <element name="xelement" type="xsd:int"/> <element name="yelement" type="xsd:float"/> </schema> </types> <message name="mymethodrequest"> <part name="x" element="xelement"/> <part name="y" element="yelement"/> </message> <message name="empty"/> <porttype name="pt"> <operation name="mymethod"> <input message="mymethodrequest"/> <output message="empty"/> </operation> </porttype> <binding.../> <types> <schema> <element name="mymethod"> <complextype> <sequence> <element name="x" type="xsd:int"/> <element name="y" type="xsd:float"/> </sequence> </complextype> </element> <element name="mymethodresponse"> <complextype/> </element> </schema> </types> <message name="mymethodrequest"> <part name="parameters" element="mymethod"/> </message> <message name="empty"> <part name="parameters" element="mymethodresponse"/> </message> <porttype name="pt"> <operation name="mymethod"> <input message="mymethodrequest"/> <output message="empty"/> </operation> </porttype> <binding.../ SOAP <soap:envelope> <soap:body> <mymethod> <x xsi:type="xsd:int">5</x> <y xsi:type="xsd:float">5.0</y> </mymethod> </soap:body> </soap:envelope> <soap:envelope> <soap:body> <xelement>5</xelement> <yelement>5.0</yelement> </soap:body> </soap:envelope> <soap:envelope> <soap:body> <mymethod> <x>5</x> <y>5.0</y> </mymethod> </soap:body> </soap:envelope> Abb. 3 // Verschiedene Binding Arten - Unterschiede Christian Kreipl / Hochschule München Seite - 8 -

10 Services Das Service-Element ist der letzte Teil der WebService Beschreibung. Es beschreibt unter welchem Ort der WebService zu finden ist, meistens durch einen URL-Verweis auf den SOAP-Service. 4. Soap SOAP (früher: Simple Objects Access Protokoll, heute einfach nur SOAP) ist ein standardisiertes Packet Protokoll für die von Applikationen versendeten Nachrichten. SOAP ist ein Protokoll der XML Familie, es bezieht sich auf Standards wie etwa XML-Schema oder XML-Namespace. Die Arbeitsweise von SOAP ist vom W3C spezifiziert 8 und liegt momentan in der Version 1.2 vor. Während die WSDL dazu benutzt wird um einen Web Service zu beschreiben, benutzt man SOAP um einen Web Service zu versenden (und natürlich zu empfangen).(abb. 4) Applikation XML SOAP Applikation Abb. 4 Das Verfahren zum Senden und Empfangen von Nachrichten wird auch XML-Messaging genannt, wobei das Wort Nachricht vielleicht etwas zu eng gesteckt ist, da sie viel mehr sein kann als nur blanker Text. Eine Nachricht kann z.b. ein Aktienkurs oder ein Kaufauftrag sein, aber auch die Eingabe in eine Suchmaschine, oder aber auch einfach nur Nummern, Ergebnisse von Kalkulationen. Da XML-Nachrichten nicht an eine bestimmte Applikation, ein bestimmtes Betriebssystem oder eine Programmiersprache gebunden sind, können sie in jedem Umfeld benutzt werden. So kann z.b. ein.net Objekt eine XML-Nachricht erstellen, welche von einer Unix Java Applikation empfangen und verarbeitet werden kann. Interoperabilität ist die fundamentale Idee hinter XML und XML vererbt diese an SOAP. 4.1 Aufbau einer SOAP-Nachricht Eine SOAP-Nachricht ist nach einem bestimmten Schema aufgebaut (Abb. 5). Der Header kann optional ausgewiesen werden, Envelope und Body Elemente sind jedoch Pflicht. 8 Webseite des W3C über SOAP ( Christian Kreipl / Hochschule München Seite - 9 -

11 Abb 5 // Aufbau eines SOAP-Dokumentes Das SOAP-Envelope Element ist das Root-Element einer SOAP Nachricht und umschließt alle weiteren Elemente. Es kennzeichnet ein XML-Dokument als SOAP Nachricht. Im Envelope findet sich der Namespace des Dokuments und optional kann der Decoding Stil deklariert werden. Das encodingstyle-attribut verweist auf Ordnungsregeln für die jeweilige SOAP Nachricht. Diese Regeln werden durch eine Liste von URI s 9 näher spezifiziert. Das Soap-Header Element ist ein Mechanismus zum Erweitern von Nachrichten. Der Header ist das erste direkte Child-Element des Envelope. Das Header-Element wird dezentral benutzt, d.h. die Kommunikationspartner müssen nicht zwangsweise Kenntnis von seiner Existenz haben. Typische Anwendung des Header ist die Authentifizierung oder das Transaktionsmanagment. Mit dem actor-attribut im Header wird festgelegt an wenn die Nachricht bestimmt ist, das macht vor allem Sinn, wenn zwischen Sender und Empfänger mehrere Verarbeitungsstationen passiert werden müssen. Mit dem mustunderstand-attribut wird festgelegt, ob der (durch das actor-attribut) festgelegte Empfänger den Header verarbeiten muss. Die Werte 1 und 0 werden akzeptiert, 0 ist der Default-Wert. Das Header-Element ist eine optionale Angabe. Das Body-Element schließlich trägt die eigentlich zu übertragende Nachricht. Der Body ist ein direktes Child-Element des Envelope. Abb. 6 zeigt einen strukturierten Aufbau einer SOAP-Nachricht. <?xml version="1.0"?> <soap:envelope xmlns:soap=" soap:encodingstyle=" <soap:header> //SOAP- Header Implementierung hier rein. </soap:header> <soap:body> //SOAP-Body Implementierung hier rein. </soap:body> </soap:envelope> Abb 6 // Aufbau einer SOAP-Nachricht 9 Uniform Ressource Identifier / Spezifikation unter Christian Kreipl / Hochschule München Seite

12 5. Web Services in Java mit JAX-WS JAX-WS 10 ist ein Framework zur Erstellung von Web Services unter Java. JAX-WS liegt momentan in der Version 2.2 vor und benötigt >= JDK 5.0 Version 2 sowie ANT zur Ausführung. JAX-WS ist als Nachfolger von JAX-RPC 12 gedacht, enthält ein Vereinfachtes Programmiermodell und eine Optimierung des Data-Binding mit JAXB JAX-WS ist Protokoll und Transportunabhängig. JAX-WS bietet eine Abstrakte Sicht auf die Entwicklung von Web Services ohne genaue Kenntnis über Details wie SOAP oder XML kennen zu müssen. Mit JAX-WS ist eine Code-first 14, wie auch eine Contract-first 15 Implementierung von Web Services möglich. JAX-WS 2.2 unterstützt nachfolgend aufgelistete Standards. Web Services Addressing 1.0 Core 16 Web Services Addressing SOAP Binding 17 Web Services Addressing 1.0 Metadata 18 Web Services Addressing WSDL Binding 19 WS-Addressing - Member Submission 20 SOAP 1.1 und REST 22 und XML/HTTP WS-I Basic Profile WS-I Simple SOAP Binding Profile WS-I Attachment Profile MTOM Annotationen in JAX-WS JAX-WS ist sehr einfach zu benutzen, da es hauptsächlich über Annotationen gesteuert wird. Folgende wichtige Annotationen werden nachgehend im wird benutzt um eine Klasse als Endpoint zu deklarieren. Die Annotation kann über Klassen, Interfaces oder andere Annotationen geschrieben werden (@TARGET({TYPE})). Folgende Parameter können dieser Annotation übergeben: 10 Java API for XML Web Services 11 ANT steht nicht etwa für Ameise, sondern als Akronym für Another Neat Tool (James Duncan Davidson, Entwickler von Apache ANT) 12 Java API for XML based RPC 13 Java Architekture for XML-Binding 14 Code-first. JAVA WSDL Implementierung 15 Contract-first. WSDL JAVA Implementierung 16 Zugehöriger Artikel aus dem W3C ( 17 Zugehöriger Artikel aus dem W3C ( 18 Zugehöriger Artikel aus dem W3C ( 19 Zugehöriger Artikel aus dem W3C ( 20 Zugehöriger Artikel aus dem W3C ( 21 Zugehöriger Artikel aus dem W3C ( 22 Representational State Transfer ( 23 Zugehöriger Artikel der Web Service InteroperabilityOrganisation ( 24 Zugehöriger Artikel der Web Service InteroperabilityOrganisation ( 25 Zugehöriger Artikel der Web Service InteroperabilityOrganisation ( 26 Message Transmission Optimization Mechanism ( Christian Kreipl / Hochschule München Seite

13 name Der Name des WSDL:portType, Default ist der Klassen(Interface) Name. targetnamespace Der XML Namespace für das WSDL Dokument. Per Default wird der Namespace auf das Packet gemappt, welches den Web Service enthält 27 servicename Der Name des Service, wsdl:service. Default ist der Klassenname+ Service portname Der wsdl:portname. Per Default ist das WebService.name + port endpointinterface Der Name des Service Endpoint Interfaces. Wenn dieser Parameter gestezt ist, werden alle anderen Parameter ignoriert, genauso wie alle 181 Annotationen. Kein Default Durch die wird eine Methode als Web Service Operation deklariert. Die Annotation kann nur über einer Methode stehen (@TARGET({METHOD})). Folgende Parameter können übergeben werden: operationname Der Name der dazugehörigen wsdl:operation. Der targetnamespace wird übernommen. Default ist der Methodenname. action exclude Wird benutzt um eine Methode auszugrenzen. Default ist Diese Annotation wird benutzt um einen einzelnen Parameter einer Operation zuzuweisen. Diese Annotation kann nur über einem Parameter angewandt werden (@Target({PARAMETER})). Folgende Parameter können übergeben werden: name Für ein RPC-Binding ist dies der Name der wsdl:part. Für ein Document/literal Wrapped-Binding ist dies der Name des lokalen XML-Elements, welches den Parameter repräsentiert. Per Default wird bei RPC der Wert argx verwendet, wobei das X die Position in der Parameterliste repräsentiert. Für Document/literal Wrapped wird der übergebene Parameternamen verwendet. targetnamespace 27 Gemäß 3.2 der JAX-WS Spezifikation, zu lesen unter ( spec.pdf?authparam= _32016e9a03d4734f5e d714fc0&ticketid=b%2fw4lxwasltmtr1hmlnekwbl&groupname= CDS&FilePath=/ESD5/JSCDL/jaxws/2.2-mrel3/jaxws-2_2-mrel3-spec.pdf&File=jaxws-2_2-mrel3-spec.pdf) Christian Kreipl / Hochschule München Seite

14 Der XML-Namespace für den Parameter. Per Default wird der Namspace des WebService übernommen. mode Gibt die Richtung des Parameters an. Möglich sind IN, INOUT und OUT. header Default ist false. partname Spezifiziert den partname des Parameters. Default wird benutzt um den Rückgabewert einer Methode auf ein WSDL-Dokument zu mappen. Diese Annotation kann nur über Methoden geschrieben werden Folgende Parameter können übergeben werden: name Der Name des Rückgabewertes. Per Default ist dies return targetnamespace Der Namspace des Rückgabewertes. Per Default wird der Rückgabewert des WebService Namespace übernommen. header Default ist false. partname Spezifiziert den partname des Rückgabewertes. Default wird benutzt, um das Binding für ein WSDL Dokument festzulegen. Die Annotation kann nur über eine Klasse geschrieben werden Folgende Parameter können übergeben werden: style Definiert den Style, der in einer WebService Nachricht benutzt wird. Default ist DOCUMENT. use Definiert den Encoding Typ der in einer WebService Nachricht benutz wird. Default ist LITERAL. parameterstyle Definiert wie die Methoden-Parameter im SOAP Body verarbeitet werden. Default ist WRAPPED. Christian Kreipl / Hochschule München Seite

15 5.2 Erstellung einer Beispiel Applikation Zum Abschluss dieser Arbeit werden wir eine kleine Web Service Applikation in NetBeans schreiben. NetBeans bringt, im Vergleich zu Eclipse, bessere Tools zur Erstellung von WebService mit. Das Programm wird einen WebService bereitstellen, der vier arithmetische Funktionen bereitstellt, einen Taschenrechner. Über ein zweites Programm werden wir auf diesen Service zugreifen können. Wir werden verschiedene Werte übermitteln können, welche vom Service verarbeitet werden, wobei dieser die Ergebnisse zurückschickt Benötigte Software und Addons Folgende Programme und Installationen sind für das Beispiel von Nöten. Java (vorzugsweise JDK 6 Update 20) NetBeans Ein Applikation Server (vorzugsweise Glassfish, da von NetBeans schon mitgeliefert) Erstellen des Web Services Wir erstellen zunächst ein neues Projekt und wählen Web Application aus dem Auswahlmenü. Nun erstellen wir in diesem Projekt einen neuen Web Service (Rechtsklick auf das Projekt New WebService). NetBeans fügt das neue File nun automatisch in die Ordnerstruktur ein. (Abb. 7) Abb. 7 Nun öffnen wir das neue File um ein paar Operationen anzulegen. Da unser Service ein Taschenrechner wird, benötigen wir vorerst vier: Addition, Subtraktion, Multiplikation und Christian Kreipl / Hochschule München Seite

16 Abb 8 Division. Hier kommt uns NetBeans durch seine Design-Ansicht sehr zur Hilfe. Das ganze sollte wie folgt aussehen. (Abb. 8) Jeder Bereich steht für eine Operation, als Paramtertypen verwenden wir Int, die Dezimalstellen beherrscht unser Rechner (noch) nicht. Nach einem Wechsel zur Source Ansicht sehen wir den erstellten Code. Noch weiß unser Service nicht was er tun soll, die Methoden müssen erst noch ausformuliert werden. Nach getaner Arbeit sollte unser Code wie folgt aussehen. (Abb. 9) Christian Kreipl / Hochschule München Seite

17 Abb. 9 Nun können wir den Service testen. Dazu deployen wir zuerst das Projekt auf den Application- Server (rechtsklick auf das Projekt Deploy). Sobald wir den Server hochgefahren haben, können wir einen Test durch Eingabe folgender URL durchfühen. (Das Beispiel geht von einer Standardinstallation des Server mit HTML-Port:8080 aus) Wir sollten folgenden Screen erhalten. (Abb. 10) Christian Kreipl / Hochschule München Seite

18 Abb. 10 Wir testen kurz ob unsere Methoden auch die richtigen Ergebnisse (des Platzes wegen nur der Division) liefern. (Abb. 11) Abb. 11 Sehen wir uns zu dieser Abfrage auch die dazugehörigen SOAP-Nachrichten an. (Abb. 12) Christian Kreipl / Hochschule München Seite

19 Soap- Request Soap- Response Abb. 12 Abschließend können wir durch die URL die generierte WSDL aufrufen. (siehe Anhang) Erstellen einer Zugriffsapplikation Nachdem wir uns von der Korrektheit der Ergebnisse überzeugt haben, erstellen wir eine einfache Java Anwendung, welche auf diesen Service zugreifen möchte. Wir erstellen ein neues Java-Projekt mit Namen CalculatorConsumer, danach teilen wir diesem Projekt den eben erstellten Service zu (Rechtsklick auf Projekt new Web Service Client den eben erstellten Service auswählen). Unsere Ordnerstruktur sollte nun wie folgt aussehen. (Abb. 13) Christian Kreipl / Hochschule München Seite

20 Abb. 13 Nun erstellen wir eine Klasse mit Namen RunCalculator. Diese Klasse greift nun auf den vorhin erstellten Webservice zu und ruft jeweils jeden Port einmal auf. Folgender Code muss hierfür geschrieben werden. (Abb. 14) Abb. 14 Nun starten wir die Applikation und prüfen das Ergebnis. (Abb. 15) Christian Kreipl / Hochschule München Seite

21 Abb. 15 Wie wir sehen hat unsere Applikation erfolgreich Daten an den Service geschickt und diese auch erhalten. Christian Kreipl / Hochschule München Seite

22 Anhang JAX-WS Beispiel / WSDL File <!--Published by JAX-WS RI at RI's version is JAX-WS RI 2.2-hudson > <!--Generated by JAX-WS RI at RI's version is JAX-WS RI 2.2-hudson > <definitions targetnamespace=" name="calculatorservice"> <types> </types> <xsd:schema> <xsd:import namespace= schemalocation=" </xsd:schema> <message name="add"> <part name="parameters" element="tns:add"/> </message> <message name="addresponse"> <part name="parameters" element="tns:addresponse"/> </message> <message name="sub"> <part name="parameters" element="tns:sub"/> </message> <message name="subresponse"> <part name="parameters" element="tns:subresponse"/> </message> <message name="mult"> <part name="parameters" element="tns:mult"/> </message> <message name="multresponse"> <part name="parameters" element="tns:multresponse"/> </message> <message name="diff"> <part name="parameters" element="tns:diff"/> </message> <message name="diffresponse"> <part name="parameters" element="tns:diffresponse"/> </message> <porttype name="calculator"> <operation name="add"> <input wsam:action= message="tns:add"/> <output wsam:action= message="tns:addresponse"/> </operation> <operation name="sub"> <input wsam:action= message="tns:sub"/> <output wsam:action= message="tns:subresponse"/> </operation> <operation name="mult"> <input wsam:action= message="tns:mult"/> <output wsam:action= message="tns:multresponse"/> </operation> <operation name="diff"> <input wsam:action= message="tns:diff"/> <output wsam:action= message="tns:diffresponse"/> </operation> </porttype> <binding name="calculatorportbinding" type="tns:calculator"> <soap:binding transport=" style="document"/> <operation name="add"> <soap:operation soapaction=""/> <input><soap:body use="literal"/></input> <output><soap:body use="literal"/></output> </operation> <operation name="sub"> <soap:operation soapaction=""/> <input><soap:body use="literal"/></input> Christian Kreipl / Hochschule München Seite

23 </definitions> <output><soap:body use="literal"/></output> </operation> <operation name="mult"> <soap:operation soapaction=""/> <input><soap:body use="literal"/></input> <output><soap:body use="literal"/></output> </operation> <operation name="diff"> <soap:operation soapaction=""/> <input><soap:body use="literal"/></input> <output><soap:body use="literal"/></output> </operation> </binding> <service name="calculatorservice"> <port name="calculatorport" binding="tns:calculatorportbinding"> <soap:address location=" </port> </service> Christian Kreipl / Hochschule München Seite

24 Quellenverzeichniss Web Service Essentials (O Reilly Media; ISBN: ) Programming Web Services with SOAP (O Reilly Media; ISBN ) Java ist auch eine Insel (Galileo Press; ISBN: ) Net Beans Platform 6 (Galileo Press; ISBN: ) Fusesource.com, Defining the Bindung Properties with Annotations. ( nalsoapbinding.html) Thorsten Horn ( JAX-WS Docu, Java.net ( outline) WSDL-Spezifikation des W3C ( SOAP-Spezifikation des W3C ( XML-Spezifikation des W3C ( Deutsche Wikipedia ( Englische Wikipedia ( Christian Kreipl / Hochschule München Seite

25 Nachwort Für Fragen und Hinweise zu dieser Studienarbeit bin ich unter folgender Mail-Adresse zu erreichen: Christian Kreipl / Hochschule München Seite

26 Dateiname: Studienarbeit_Webservices_Christian_Kreipl_final_auslieferung_Wor d97 Verzeichnis: C:\Dokumente und Einstellungen\Christian Kreipl\Desktop\Studienarbeit_WebServices_Christian_Kreipl\Studienarbeit Vorlage: Normal Titel: Studienarbeit im Fach: Aktuelle Technologien zur Anwendung verteilter Java-Anwendungen Thema: Eine Abhandlung zum Thema Webservices Autor: Christian Kreipl Stichwörter: Kommentar: Erstelldatum: :00:00 Änderung Nummer: 4 Letztes Speicherdatum: :06:00 Zuletzt gespeichert von: Christian Kreipl Letztes Druckdatum: :06:00 Nach letztem vollständigen Druck Anzahl Seiten: 25 Anzahl Wörter: (ca.) Anzahl Zeichen: (ca.)