Java EE 7: Web Services

Einführung in XML Web Services

LinkedIn Learning kostenlos und unverbindlich testen!

Jetzt testen Alle Abonnements anzeigen
Dieser Film erläutert die Grundlagen von XML Web Services: SOAP, WSDL und UDDI. Außerdem lernen Sie, wie die Kommunikation von und zum Server stattfindet und welche Daten dabei übertragen werden.

Transkript

XML Web Services sind heutzutage aus modernen verteilten Applikationen überhaupt nicht mehr wegzudenken. Grund genug für uns, in diesem Video einmal die Frage aufzuwerfen, was XML Web Services überhaupt sind und was da technologisch dahintersteht. Generell sind XML Web Services eine Spezifikation. Diese Spezifikation existiert aus Java-Sicht auf zwei Ebenen. Nämlich einmal auf der Ebene von Java selber. Dort gibt es in der aktuellen Version 2.0 JAX-WS, spezifiziert im JSR 2224. Zum anderen gibt es auch noch die ganz generische Web Services-Spezifikation, die vom World Wide Web Consortium verwaltet und vorangetrieben wird. Im World Wide Web Consortium, in der Webservices-Gruppe, sind große Firmen, unter anderem Oracle, IBM und Microsoft, engagiert. XML Web Services, so wie sie dort plattformübergreifend spezifiziert sind, sind letztlich ein XML-basiertes Protokoll oder ein XML-basierter Ansatz, der aufgrund dieser Standardtechnologien plattformübergreifend funktioniert. Das bedeutet: Wenn Sie einen Web Service bereitstellen, kann der in aller Regel auch von einem Client, der auf einer anderen Plattform, auf einem anderen Betriebssystem, läuft, konsumiert werden. In aller Regel folgen alle Webservices dem sogenannten Contract-First-Ansatz. Das bedeutet, es gibt zunächst einen Vertrag, der dann vom Client, meist vollautomatisch, erfüllt wird, indem ein sogenannter Proxy definiert wird. Damit das Ganze funktionieren kann, muss der Vertrag letztlich alle Informationen beinhalten, die der Client benötigt, um seinerseits sämtliche Logik automatisch erzeugen zu können, um mit dem Webservice kommunizieren zu können. Die Kommunikation mit dem Webservice als solches findet dabei über SOAP statt. SOAP ist das Datenaustauschformat von XML Web Services. Wie der Name XML Web Services bereits andeutet, ist SOAP selber nichts anderes als ein einfacher XML-Dialekt. Die Beschreibung eines Web Services, also das, was ein Client benötigt, wen er mit einem Web Service kommunizieren möchte, ist in WSDL verfasst. WSDL steht für Web Services Description Language und ist selber seinerseits auch nur ein XML-Dialekt. Im WSDL selber sind verschiedene Komponenten definiert. Da ist letztlich drin enthalten, welche Methoden der Web Service bereitstellt, welche Parameter diese Methoden erwarten was sie zurückgeben und wie die eigentlich zu übertragenden Daten aussehen. Wir sind so in der Lage, die Richtung von XML Web Services und von ihnen zurückkommend auch komplexe Objekte auszutauschen und das Ganze, wie bereits erwähnt, plattformübergreifend Die dritte Technologie, die Ihnen im Umfeld vom Web Services häufig über den Weg laufen wird, ist UDDI. UDDI steht für Universal Description, Discovery and Integration. und beschreibt einen Mechanismus, mit dessen Hilfe ein Server oder der Anbieter eines Services Informationen zum Service bereitstellen kann. Diese Informationen, meistens die WSDL-Beschreibung, gerne auch zusätzliche Informationen, werden dann vom Client abgerufen. So kann der Client erfahren, welcher Server welchen Service bereitstellt und kann, falls dies noch nicht geschehen ist, den entsprechenden Code, um mit dem Service zu kommunizieren, automatisch generieren. Nachdem das geschehen ist, kann der Client auf dem Server und dem Service seine Operationen ausführen. Dabei werden die Nachrichten über SOAP ausgetauscht. Der ganze Prozess funktioniert auch ohne UDDI. Das ist das, was man eigentlich häufiger antrifft. UDDI ist oft bei großen Firmen im Einsatz. Bei kleineren Applikationen wird darauf gern verzichtet. Hier haben wir letztlich nur eine direkte Kommunikation zwischen Client und Server. Der Client kann zum Erstellen des Proxys Informationen zum Service abrufen. Ihm wird also das WSDL geliefert. Der Server kann dann darauf warten, dass der Client seine Operationen ausführt und dem Client entsprechend die Rückgabe generieren. Sehen wir uns im Folgenden einmal an, wie so ein WSDL aussieht und wie die Kommunikation mit Hilfe von SOAP in Richtung eines Web Services und als Antwort von einem Web Service stattfinden kann. Wir sehen hier eine WSDL-Definition. Diese WSDL-Definition beinhaltet alle Informationen, die ein potentieller Client, also eine nutzende Komponente, benötigt, um mit dem Web Service zu arbeiten. Dieses WSDL-Dokument ist in sich selber komplett. Wir finden hier also alle Informationen zu Datentypen und Methodenaufrufen, die uns interessieren müssen. Im oberen Bereich befindet sich ein WSDL-Types-Element. Hier sind die eigentlichen Datentypen definiert. Nun mag man sich fragen, warum sollte man einfache Datentypen wie zum Beispiel Zeichenketten darin definieren? Der Hintergrund ist ie Plattformunabhängigkeit. Denn nicht jede Plattform kann mit allen Standard-Datentypen, die wir zum Beispiel aus Java heraus kennen, arbeiten. Aus dem Grund werden hier generische Datentypen definiert, die dann vom Client automatisch in Datentypen umgesetzt werden, die die jeweilige Zielplattform auch versteht. Weiter unten in diesem Dokument sind dann definiert, welche Operationen ausgeführt werden, welche Parameter dabei entgegengenommen werden können und welche Rückgaben es geben wird. Ganz am Ende ist der sogenannte WSDL-Port definiert. Hier befindet sich die Information über die eigentlich anzuspringende Operation mit ihrer jeweiligen Adresse. Diese Informationen werden dann vom Client genutzt, um mit dem Web Service zu arbeiten. Es ist wie gesagt nicht unbedingt einfach, so einen Client selber zu bauen. Das könnte man zwar tun, anhand dieser Informationen geht das, aber in der Regel haben die verschiedenen Web Services Frameworks der verschiedenen Plattformen bereits Mechanismen integriert. Um Ihnen zu demonstrieren, wie Sie mit so einem Web Service arbeiten können, verwenden wir hier erst einmal den sogenannten Membrane SOAP Client. Das ist eine Open-Source-Komponente, die zwar nicht besonders schickt ist, die aber genau das macht, was wir wollen, nämlich mit einem Web Service zu arbeiten und uns die Kommunikation direkt verfolgen zu lassen. Ich werde nun den Membrane SOAP Client starten. Nachdem der Client gestartet ist, können wir über den grünen Button New WSDL einen Verweis auf eine WSDL-Datei hinzufügen. Das kann entweder die URL direkt auf dem Server sein oder eine heruntergeladene WSDL-Datei. Ich trage nun hier einmal die Adresse des WSDL-Files auf dem Server ein. Ganz wichtig dabei: Die Adresse entspricht eigentlich dem Aufruf des Web Services selber. Hintendran ist per ?WSDL notiert, dass wir am WSDL interessiert sind. Das funktioniert plattformübergreifend. Das ist also eine Konvention, die alle Web Services Frameworks so verstehen. Ein Klick auf OK lädt dann das WSDL herunter und nun kann uns der SOAP-Client anhand der Informationen sagen, welche Methoden uns bereitgestellt werden. Uns interessiert hier die Methode sayHello, deswegen mache ich dort einmal einen Doppelklick drauf. Nun öffnet sich das Request-Fenster. In diesem Fenster sehe ich die Endpoint-Adresse, also die Adresse, die ich aufrufen muss, um mit dieser Methode zu kommunizieren. Ich habe jetzt hier verschiedene Reiter. Mich interessiert erstmal der Form-Reiter, über den ich der Methode einen Parameter übergeben kann. Wie viele Parameter es hier gibt, hängt tatsächlich von der Methodensignatur ab und ist in WSDL beschrieben. Ich übergebe hier den Parameter world. Wenn ich jetzt auf die Schaltfläche oberhalb der Adresse klicke, wird die Abfrage ausgeführt. Bevor wir uns die Antwort genauer anschauen, wechseln wir noch einmal zurück in den Request-Reiter und schauen uns einmal im Bereich Wir werden feststellen können, dass Web Service-Anforderungen in aller Regel HTTP-Requests sind. Denn was wir hier sehen, ist ein einfacher HTTP-Request. Web Services kommunizieren in aller Regel über HTTP oder HTTPS als Transportprotokoll. Allerdings ist das auch eher eine Gewohnheit als eine technische Gegebenheit. Sie können Web Services theoretisch auch schreiben, die per E-Mail oder übers Dateisystem kommunizieren. In jedem Fall erwartet so ein Web Service beim Aufruf die Angabe des SOAP-Dokumentes. Das habe ich hier einmal markiert. Das gehen wir etwas schöner im Bereich SOAP. Dann sehen wir, dass dieses SOAP-Dokument aus mehreren Komponenten besteht. Uns interessiert eigentlich nur dass wir einen Aufruf auf die Methode sayHello machen und den Parameter world als ersten Parameter übergeben. Die Antwort des Servers selber ist eine ganz normale HTTP-Antwort. Sie besteht aus Headern und dem eigentlichen Body. Der Body ist seinerseits auch wieder nur ein SOAP-Dokument. Das sehen wir hier im Reiter SOAP etwas schöner. Auch hier wird nur ein XML-Dokument in einem spezifischen Format ausgetauscht. Und das steht eigentlich hinter den Grundlagen von Web Services. Einfache XML-Dokumente, die in einem bekannten Format verfasst sind, die vom Server verarbeitet werden können und die dann vom Client bei der Rückgabe auch automatisch verarbeitet werden können Alles, was unter der Haube passiert, also HTTP-Requests, Serialisierung von Daten und ähnliche Sachen interessiert uns als Java-Entwickler normalerweise nicht. Wir sind über JAX-WS davon entkoppelt. In diesem Video haben wir uns einmal mit den Grundlagen von XML Web Services auseinandergesetzt. Wir haben kurz geklärt, was XML Web Services sind. Wir haben uns angeschaut, wie das WSDL aussieht. Wir haben uns ebenfalls ein SOAP-Dokument angeschaut, was zwischen Server und Client ausgetauscht wird. Ebenfalls haben wir über die Infrastruktur gesprochen und haben so eine gute Grundlage für das Verständnis von XML Web Services gelegt.

Java EE 7: Web Services

Steigen Sie ein in die Java-Enterprise-Welt und lernen Sie, wie Nachrichten ausgetauscht und Dienste definiert werden.

5 Std. 13 min (30 Videos)
Derzeit sind keine Feedbacks vorhanden...

Dieser Online-Kurs ist als Download und als Streaming-Video verfügbar. Die gute Nachricht: Sie müssen sich nicht entscheiden - sobald Sie das Training erwerben, erhalten Sie Zugang zu beiden Optionen!

Der Download ermöglicht Ihnen die Offline-Nutzung des Trainings und bietet die Vorteile einer benutzerfreundlichen Abspielumgebung. Wenn Sie an verschiedenen Computern arbeiten, oder nicht den ganzen Kurs auf einmal herunterladen möchten, loggen Sie sich auf dieser Seite ein, um alle Videos des Trainings als Streaming-Video anzusehen.

Wir hoffen, dass Sie viel Freude und Erfolg mit diesem Video-Training haben werden. Falls Sie irgendwelche Fragen haben, zögern Sie nicht uns zu kontaktieren!