Webservices mit Java EE 6: JAX-WS und RESTful Services

Trotz Hinwendung zu Dokumenten- beziehungsweise Message-Zentrierung und einem klaren Contract-first-Design war der Funktionsumfang von "Java EE 5"-Webservices im Vergleich zu anderen Plattformen unvollständig. Eine Lücke, die mit Java EE 6 endgültig geschlossen ist.

In Pocket speichern vorlesen Druckansicht
Lesezeit: 17 Min.
Von
  • Jens Schumann
Inhaltsverzeichnis

Mit JAX-WS 2.0 erfolgte schon bei Java EE 5 die längst überfällige Generalüberholung der Java-Webservices: Weg von Webservices im RPC-Stil hin zu Dokumenten- beziehungsweise Message-Zentrierung und einem klaren Contract-first-Design. Doch im Vergleich zu anderen Plattformen war auch der Funktionsumfang von "Java EE 5"-Webservices unvollständig. Eine Lücke, die nun mit Java EE 6 endgültig geschlossen ist.

Aus Entwicklersicht hat sich die Java-Webservices-Welt seit vielen Jahren kaum verändert: Ausgestattet mit einem Webservice-Framework der Wahl war und ist das Bereitstellen beziehungsweise Anbinden von Webservices mit Java eine Leichtigkeit. Dabei übernimmt das Framework lästige Aufgaben wie das Generieren serverseitiger Webservice-Klassen oder von Webservice-Client-Code, mit dem sich auf bereitgestellte Dienste zugreifen lässt. Zu den wirklich nennenswerten Veränderungen der letzten Jahre zählte daher nur die Verschiebung der Machtverhältnisse innerhalb der Framework-Landschaft: Galt jahrelang Apache Axis in der Java-Community als der Platzhirsch, haben mittlerweile Apache CXF und andere, in umfassendere Techniken integrierte Webservice-Stacks wie Spring Web Services oder JBoss WS deutlich an Gewicht gewonnen.

Mehr Infos

Quo vadis Java EE 6?

Das Bereitstellen von Webservices über die standardisierte "Java EE"-Plattform hingegen spielte – trotz der Verfügbarkeit seit J2EE 1.4 – eine eher untergeordnete Rolle. Die Ursachen dafür sind vielschichtig. Zu den
wesentlichsten gehören sicherlich die zähen Standardisierungsbestrebungen, da J2EE 1.4 erst Jahre nach dem Erscheinen kommerzieller und freier Frameworks ein Angebot für Java-Webservices bot. Dummerweise führte der dann formulierte Ansatz, Methoden von Enterprise JavaBeans (EJB) als Webservices bereitzustellen, nicht automatisch zu überschwänglicher Begeisterung in der Java-Community. Im Gegenteil: Neben den sowieso damals leicht in Verruf geratenen EJBs stellte sie vor allem die Interoperabilität derartig formulierter Webservices in Frage. Zu Recht, wie mittlerweile die Abkehr von diesen sogenannten Code-first-Webservices belegt.

Spätestens seit der mit Java EE 5 spezifizierten Java API for XML Web Services 2.0 JAX-WS haben sich die Vorzeichen wieder deutlich zugunsten des Standards verschoben. Die Gründe für einen expliziten Einsatz eines Frameworks zum Bereitstellen von Webservices wurden schlagartig verringert, wenn auch bis dahin Java EE nur klassische und nicht datenzentrierte Webservices unterstützte. Mit Java EE 6 wurde nunmehr auch diese Lücke geschlossen, sodass sich mit dem heutigen Enterprise-Java portable, service- oder datenorientierte Webservices umsetzen lassen. Die Portabilität umfasst dabei sowohl Java-Applikationsserver als auch -Webservice-Frameworks, sofern diese die derzeit gültigen Webservice-APIs implementieren.

Grundsätzlich unterscheidet die Webservices-Community – vor allem außerhalb der Java-Gemeinde – zwei Arten von Webservices: Auf der einen Seite befinden sich die klassischen Services, die die Informationen auf Basis eines zwischen Client und Server festgelegten Vertrags austauschen. Ein derartiger Vertrag wird in einer formalen Sprache – der Web Services Description Language (WSDL) – definiert, die sich wiederum zu großen Teilen der Formalismen von XML Schema (XSD) bedient. Die andere Form von Webservices hingegen legt den Fokus nicht auf einen formalen Vertrag, sondern ausschließlich auf das Bereitstellen und Aktualisieren beliebiger Daten über ein einfaches und definiertes Transportprotokoll. Technisch gesehen setzen die beiden Ansätze somit entweder auf SOAP- oder aber auf RESTful-Services. Beide Ansätze genügen dabei den Anforderungen an Interoperabilität, wobei im Falle von SOAP die zugrunde liegenden Spezifikationen und im Falle von RESTful-Services der Anbieter der Dienste den Grad der Interoperabilität festlegen.