JAX-RS 2.0: Das neue Gesicht der RESTful Web Services - JAXenter
Interview mit Markus Karg

JAX-RS 2.0: Das neue Gesicht der RESTful Web Services

Im Januar 2011 hat der JCP die Arbeit an JAX-RS 2.0 (Java API for RESTful Web Services) aufgenommen. Mitglied der Expertengruppen Markus Karg informiert im Gespräch mit JAXenter über die geplanten Neuerungen und die Roadmap hin zum Release von JAX-RS 2.0 und der Jersey-Referenzimplementierung.

JAXenter: Hallo Herr Karg. Die Expertengruppe hat die Arbeiten an JAX-RS 2.0 aufgenommen. Auf der Liste der Neuerungen steht u.a. ein einheitliches Client API. Was genau ist in diesem Bereich geplant?

Markus Karg: Hallo Herr Schlosser. Die unter JSR 311 erarbeitete Spezifikation JAX-RS 1.1 hat sich ausschließlich auf den Serverbereich konzentriert. Um Clients in Java zu schreiben, welche auf RESTful Web Services zugreifen, gab es bislang keine standardisierte Unterstützung. Die Anwender sind hier bislang genötigt gewesen, sich auf Umwegen zu behelfen, beispielsweise durch die Nutzung der JRE-Klasse HttpURLConnection, was in relativ komplexem Code endet, oder durch die Nutzung von proprietären Produkten wie den Apache Wink Client oder den Jersey Client, was jedoch zu nicht portablen Anwendungen führt.

Um also auf der einen Seite das Schreiben von Clients zu vereinfachen, auf der anderen Seite eine einfache Migration beispielsweise von Wink auf Jersey oder umgekehrt zu ermöglichen, ist es notwendig, auch die Client-Seite zu standardisieren. Hierzu gibt es prinzipiell mehrere Möglichkeiten: Wir könnten uns auf die API eines bestehenden Produktes einigen, was jedoch nur jeweils deren bestimmter Klientel zugute kommt. Wir könnten uns aber auch auf eine komplett neue API einigen, was jedoch viel Aufwand bedeutet und nicht unbedingt einen höheren Nutzen bringt.

Oracle hat vorgeschlagen, zwei APIs parallel anzubieten, eine auf sehr hohem Abstraktionsniveau für den „Normal-Anwender“, und eine komplexere für Sonderfälle. Hier sind prinzipiell noch alle Optionen offen, und wir stehen in der Diskussion erst am Anfang. Wir werden uns die vorliegenden APIs nun im Detail anschauen und prüfen, welcher Weg die für den Anwender beste Option darstellt.

Da aber einerseits Oracle mit Jersey die Referenzimplementierung liefert, andererseits sich Apache komplett aus dem Java Community Process verabschiedet hat, gibt es natürlich gewisse Tendenzen in Richtung Oracle, was aber nicht zwingend pro Jersey spricht, denn in der Expertengruppe sitzen ja auch noch Red Hat (JBoss) und andere, die hier etwas mitzureden haben.

JAXenter: Wie sieht es mit der Unterstützung asynchroner Prozesse aus? Zur Diskussion stand auch, ob WebSocket-Support Teil von JAX-RS 2.0 sein soll.

Markus Karg: COMET und WebSockets unterstützen das Paradigma der asynchronen Nachrichtenzustellung. COMET ist ein in HTTP formulierter Ansatz, WebSockets das Pendant auf HTML-Ebene. Sie erlauben das „Pushen“ von Informationen auf den Client, d. h. der Server sendet dem Client eine Nachricht in dem Moment, wo sie entsteht, unabhängig davon, wann ein Client sein Interesse an einer solchen Benachrichtigung geäußert hat. Dies entlastet das Gesamtsystem Client-Transportschicht-Server von einer Unmenge an mehr oder minder sinnlos vergeudeten Request-Response-Zyklen, wie sie beim „Polling“-Verfahren notwendig sind, und erhöht die Aktualität der Nachricht.

Bekannt ist „Pushing“ hauptsächlich aus dem Bereich der Message-Oriented-Middleware, wie JMS oder AMQP. Diese stützen sich aber oft auf proprietäre Protokolle oder zumindest Protokolle, die nicht dem Web-Layer angehören und daher relativ komplex im Handling sind, z. B. bei der Einrichtung von Firewalls usw.

Es macht Sinn, asynchronen Nachrichtenversand auch in RESTful-Anwendungen zu nutzen: Beispielsweise könnte auf einer Handelsplattform ein Server Preisänderungen asynchron an die Clients verteilen, ohne dass jeder Client ständig nach der kompletten Preisliste fragt, die sich vermutlich gar nicht geändert hat.

Leider konnte sich Oracle nicht dazu durchringen, das Thema bereits in JAX-RS 2.0 anzugehen, und hat sowohl COMET als auch WebSockets auf eine zukünftige Spezifikation verschoben. Ob das heißt, dass es definitiv vom Tisch ist, werden die weiteren Beratungen in der Expertengruppe zeigen. Klar ist, dass Oracle die Referenzimplementierung stellt, und somit die Entscheidung maßgeblich beeinflussen. Über die Gründe des expliziten Ausschlusses dieser Verfahren kann auch ich nur spekulieren, aber sicherlich spielt es eine Rolle, dass auch Oracle nicht über unbegrenzte Java-Ressourcen verfügt.

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.