Die Erstellung von Webservices unter Java ist seit der Einführung des Java Development Kit in der Version 6 stark vereinfacht worden. Durch die Integration der Libraries des Java Web Services Developer Packs (JWSDP) ist es nun möglich, einen Webservice schneller zu erstellen und mittels der integrierten Laufzeitumgebung auszuführen. Das vorliegende Dokument beschreibt die beispielhafte Implementation eines einfachen Taschenrechners als Webservices unter Verwendung des JDK6.
Das World Wide Web Consortium (W3C) definiert einen Webservices wie folgt:
„A Web service is a software system identified by a URI, 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 conveyed by Internet protocols.”
[1]
Die Definition impliziert die Definition als eine Software-Anwendung, die über einem Uniform Resource Identifier (URI) eindeutig identifizierbar ist. Zusätzlich besitzen die Software-Anwendungen Schnittstellen, die über XML definiert, beschrieben und gefunden werden können. Ein Webservice unterstützt die direkte Interaktion mit anderen Software-Agenten unter Verwendung XML-basierter Nachrichten, die wiederum über internetbasierte Protokolle ausgetauscht werden.
Webservices besitzen einige Merkmale, durch die sich diese von anderer verteilte Software unterscheiden. Im Folgenden werden drei dieser Merkmale beschrieben (vgl. [2]):
Webservices können in unterschiedlichen Standards oder Architekturstilen entwickelt werden, wobei allgemein zwischen den populärsten SOAP (Standard) und REST (Architekturstil) unterschieden wird.
SOAP (Simple Object Access Protocol) ist auf XML-Nachrichten basierendes Framework zum Austausch strukturierter Informationen und unterliegt dem W3C-Standard. Durch SOAP können unter Verwendung von XML Methoden, Services und Objekte auf entfernten Server aufgerufen werden. Eine SOAP-Nachricht muss demnach in XML codiert werden und kann neben HTTP auch über SMTP, FTP und POP3 übertragen werden. SOAP steuert die Abbildung von Daten in der Nachricht und deren Interpretation und gibt
zudem eine Konvention für entfernte Prozeduraufrufe mittels SOAP-Nachrichten vor. Für die Beschreibung von SOAP-Nachrichten verwendet SOAP WSDL (Web Services Description Language), eine plattform-, programmiersprachen- und protokollunabhängige Beschreibungssprache für Webservices zum Austausch von Nachrichten auf Basis von XML. Im speziellen wird eine WSDL-Datei dazu verwendet die Funktionalität und den Aufbau eines Webservices festzulegen und diesen im Internet anzubieten. Ein Client, die die WSDL-Datei abrufen, kann ermitteln,
welche Funktionen und dafür benötigten Datentypen auf dem Server für den Webservice verfügbar sind. Ein Client, der einen Webservice aufruft, kann WSDL lesen, um zu bestimmen, welche Funktionen auf dem Server verfügbar sind. Alle verwendeten speziellen Datentypen sind in der WSDL-Datei in XML-Form eingebunden. Der Client kann aus der WSDL-Datei einen Teil des benötigten Quellcodes generieren um zu entscheiden, wie die Funktionsaufrufe formuliert werden müssen und welche Antworten erwartet werden können. SOAP kann vom Client für die in der WSDL-Datei gelisteten Funktionen aufzurufen.
REST steht für REpresentational State Transfer und beschreibt als Schwerpunkt die Interaktion von zustandsbehafteten Ressourcen. Ressourcen beschreiben in diesem Zusammenhang jede Art von Information, die eindeutig identifiziert werden kann, wie z.B. Textdokumente oder Video- und Audiodateien. REST verfolgt das Grundkonzept jede Ressource über eine eindeutige URI zu identifizieren, was später beispielsweise eine eindeutige URL entsprechen kann. Das Interface ist generisch, sodass keine Protokoll-Konventionen zwischen Client und Server bekannt sein müssen.
Für die Kommunikation wurde die Semantik des HTTP Protokolls übernommen, wodurch die HTTP Methoden GET, PUT, POST und DELETE eine zentrale Rolle einnehmen und eine Ressource abrufen und verändern können.
Im Rahmen dieses Tutorials wurde der Architekturansatz SOAP verwendet.
Um den Webservice zu erstellen, kann im Prinzip jede mögliche Java-Klasse dafür verwendet werden. Die folgende Textbox zeigt die Klasse Calculator, die über Methoden zum Addieren, Subtrahieren, Multiplizieren und Dividieren von zwei Zahlenwerten verfügt.
POJO Java-Klasse:Calculator.java
Attribute einer Klasse müssen entsprechende Getter und Setter besitzen, damit diese später berücksichtigt werden können. Innerhalb dieses Beispiels werden jedoch keine Attribute verwendet.
Um die zuvor erstellte Klasse als Webservice nutzen zu können, sind lediglich die entsprechenden Annotationen notwendig. Das nachfolgende Textbox zeigt die Klasse Calculator mit ergänzten Annotationen.
POJO Java-Klasse mit Annotationen:Calculator.java
Die Annotationen @WebService, @SOAPBinding und @WebMethod sind für die spätere Verwendung zwingend notwendig. Alle weiteren Annotationen können optional verwendet werden.
@WebService wird am Klassenrumpf definiert und dient dazu, eine Klasse als Webservice zu deklarieren. Die Parameter name und serviceName sind optional und überschreiben die in der späteren WSDL-Datei verwendeten Bezeichnungen für den <wsdl:portType>
und den Namen des Service (<wsdl:service>). Falls diese Parameter nicht manuell gesetzt werden, werden die Namen automatisch aus dem unqualifizierten Namen der Klasse bzw. der Schnittstelle ermittelt und genutzt.
Als zweite zwingende Annotation wird ebenfalls im Klassenrumpf @SOAPBinding definiert. Dies gibt an, dass die Klasse per SOAP-Protokoll gebunden werden soll und legt zudem den Stil der Nachrichten fest. Zur Auswahl stehen Document oder RPC. Der Unterschied zwischen den beiden Stil-Varianten wird unter [3] ausführlich erläutert.
Methoden, welche als Operationen eines Webservices zur Verfügung stehen sollen, müssen mit der Annotation @WebMethod entsprechend gekennzeichnet werden. Über den Parameter operationName besteht zusätzlich die Möglichkeit, den Name der Operation für die WSDL-Definition zu verändern. Diese und die folgenden optionalen Annotationen werden innerhalb des Klassenrumpfes oberhalb der Methodensignatur oder als Parameter selbiger deklariert.
Mittels @WebResult können die Ergebnisse des Methodenaufrufes individuell angepasst werden. In der oberen Textbox wird der Name der Rückgabewertes innerhalb der WSDL-Datei verändert, welcher sonst automatisch mit „return” bei RPC und DOCUMENT/WRAPPED sowie in sonstigen Fällen mit „Methodenname + Response“ gesetzt werden würde.
Die letzte innerhalb dieser Beispielsanwendung verwendete Annotation @WebParam ist analog zu @WebResult, bezieht sich jedoch auf die Übergabeparameter einer Methode. Wird auf die Anwendung von @WebResult#name verzichtet, wird für jeden Parameter die Bezeichnung argX verwendet, wobei X mit der Position des Parameters beginnend mit 0 ersetzt wird. Die Verwendung von @WebParam und @WebResult sind optional.
Eine vollständige Übersicht der Annotationen und weitere Parameter können unter [4] eingesehen werden.
Um die Klasse Calculator als Webservice zu veröffentlichen, wird eine weitere Java-Klasse benötigt, welche als Server fungiert und über den integrierten HTTP-Server die Publizierung übernehmen wird. Die nachfolgende Textbox zeigt die implementierte Server-Klasse zum Publizieren des Webservices über den integrierten HTTP-Server.
CalculatorServer-Klasse:CalculatorServer.java
An dieser Stelle besteht die Möglichkeit, den WebService zum ersten Mal zu testen. Dazu muss lediglich der CalculatorServer aus der Entwicklungsumgebung gestartet werden. Wenn der WebService korrekt implementiert wurde, sollte nach Aufruf der URL http://localhost:8080/calculator?wsdl die generierte WSDL-Datei angezeigt werden. Einen Auszug der WSDL-Datei zeigt die folgende Textbox.
Generierte WSDL-Datei
Anmerkung: Es besteht alternativ die Möglichkeit die Publizierung auch innerhalb der Calculator-Klasse durchzuführen. Diese müsste dafür um eine Main-Methode und den Anweisungen aus der Textbox "CalculatorServer-Klasse" ergänzt werden. |
Die WSDL-Datei zeigt außerdem, dass die über Annotationen definierten Bezeichnungen für Funktionsname, Übergabeparameter und Rückgabewerte korrekt interpretiert und übernommen wurden.
Die Entwicklung des Server-Parts ist an dieser Stelle abgeschlossen. Um Zugriff auf den Dienst und die nach außen bereitgestellten Funktionen zu erhalten, wird ein Client benötigt. Bevor mit der Entwicklung des Clients begonnen werden kann, muss zunächst die benötigte Java Stub-Klasse erstellt werden, sodass der Client die Methoden des Webservices wie Methoden einer herkömmlichen eigenen Klasse nutzen kann. Die Klasse dient dazu, die Kommunikation mit dem Webservices herzustellen. Zunächst wird jedoch ein leeres Java-Projekt für den Client angelegt. Im Anschluss wird die Konsole (Linux)
oder die Eingabeaufforderung (Windows) gestartet und mittels des Befehls „wsimport -keep http://localhost:8080/calculator?wsdl“ die benötigten Java Stubs aus der WSDL-Datei generiert. Dieser Befehl muss im Source-Verzeichnis des Client-Projekts ausgeführt werden. Für die Generierung muss der WebService gestartet sein, sodass die WSDL-Datei aufrufbar ist. Durch den optionalen -keep-Parameter werden die Quelldateien nach dem Kompilieren nicht gelöscht.
Nach dem Generieren befinden sich im Source-Verzeichnis des Client-Projekts die folgenden Dateien:
Nun kann unter Verwendung der generierten Java-Klassen mit der Erstellung des Client begonnen werden. Die nachfolgende Textbox zeigt eine beispielhafte Entwicklung.
WebService-Client-Klasse: CalculatorClient.java
Wird der Client ausgeführt, sollte der JUnit-Test erfolgreich durchlaufen werden.
[1] - Web Services Architecture Requirements, W3C Working Group Note 11 February 2004, http://www.w3.org/TR/2004/NOTE-wsa-reqs-20040211, aufgerufen Juli 2012
[2] - M. Kalin: "Java Web Services: Up and Running", O'Reilly Media, Sebastopol, 2009
[3] - Which style of WSDL should I use?, http://www.ibm.com/developerworks/webservices/library/ws-whichwsdl/, aufgerufen Mai 2012
[4] - JavaTM API for XML Web Services Annotations, http://jax-ws.java.net/jax-ws-ea3/docs/annotations.html, aufgerufen Mai 2012.