Seite 3: Technik-Upgrade

Inhaltsverzeichnis

Technik- und API-Upgrade

Von besonderer Bedeutung sind die technischen Neuerungen, die die neue Version ausmachen. Wie in der Tabelle Technik-Update ersichtlich, erhält Java EE 6 zahlreiche neue Techniken und Funktionen beziehungsweise nimmt sie in überarbeitenden Versionen auf. Erwartungsgemäß finden sich Veränderungen in allen Bereichen, von der Frontend- bis zur Backend-Technik. Die wesentlichen thematisiert der zweite Beitrag der Artikelserie. Ein kleiner Vorgeschmack vorab:

EJB 3.1 erweitert die Enterprise JavaBeans unter anderem um Singleton Beans und asynchrone Methodenaufrufe. Die Java Persistence API 2.0 führt die lange vermisste Criteria API ein und verfeinert nahezu alle in der Version 1.0 enthaltenen Funktionen – angefangen bei Mapping-Strategien über die Query Language bis hin zur Verbesserung der Collection-Unterstützung.

Im Bereich der Webtechniken findet man nun die Servlet API in Version 3.0. Neben dem verstärkten Einsatz von Annotationen sticht bei ihr die Unterstützung asynchroner Request-Verarbeitung hervor.

Den größten Beitrag leisten vermutlich die JavaServer Faces (JSF) 2.0. Die Liste der Änderungen scheint beeindruckend, selbst wenn man mit Facelets, View Params (und damit Bookmark-Fähigkeit), verbessertem Ajax-Support, neuen Scopes und teilweiser Speicherung von View State nur einige wenige Highlights erwähnt.

Mit dem JSR 299 – Java Contexts and Dependency Injection, ehemals Web Beans 1.0 – steht ein weiterer interessanter Ansatz für die Verbesserung der Interaktion zwischen Web- und Backend-Techniken im Raum. Wie die beiden Namen für die gleiche Spezifikation vermuten lassen, versucht die seinerzeit von Gavin King und Christian Bauer entworfene Idee – beide bekannt durch ihre federführende Rolle bei Hibernate – die Verbindung zwischen JSF und EJB 3.x zu schärfen und damit deutlich zu vereinfachen. Interessanterweise hat in den letzten Wochen der JSR 330 – Dependency Injection for Java 1.0 – eine wichtige Hürde genommen. Lange Zeit wurde die Spezifikation, die allgemeine Annonationen zum Abhängigkeitsmanagement zwischen Java-Klassen und -Komponenten einführen soll, von der "Java EE 6"-Expertenkommision und der Java-Community kritisch beäugt. Doch nachdem der JSR 299 nun auf den Annonationen des JSR 330 basiert, scheint der Weg nach Java EE 6 geebnet. Gleichwohl haben Mitglieder der Expertenkommission sowie die Java-Community erhebliche Zweifel an der Ausgereiftheit der JSRs 299 und 330. Sinngemäß argumentieren sie, dass sie ihre Praxistauglichkeit noch nicht bewiesen haben. Am Ende bleibt wohl nichts anderes übrig als auf die finale Release zu warten.

Lange vermisst, endlich da: REST

Im Integrationsbereich halten mit den Updates zur Java API for XML Web Services (JAX-WS) 2.2 und Java API for RESTful Web Services (JAX-RS) 1.1 neue Möglichkeiten der Anbindung von Webservice-Clients Einzug in die Spezifikation. Speziell RESTful-Services gehören zu den lange vermissten Details. Da sich dank JAX-WS 2.2 und JAX-RS 1.1 die Entwicklung von Webservices erheblich vereinfacht, widmet sich de vierte Artikel dem Thema.

Eine wichtige Entscheidung betrifft eine weitere Webservice-Spezifikation: Mit großer Wahrscheinlichkeit landet JAX-RPC auf der Liste der in Zukunft zu entfernenden Techniken. Hintergrund der Entscheidung ist, dass sich alle wesentlichen Aspekte von JAX-RPC mit JAX-WS abbilden lassen. Gleichzeitig liegt nach Auffassung vieler Experten die Zukunft in JAX-WS und JAX-RS, sodass JAX-RPC über kurz oder lang obsolet sein könnte.

Pimp up your App Server

Neben der Liste der Techniken, die Java EE 6 zusammenfasst, sind weitere Verbesserungen geplant, die eine standardisierte Erweiterung eines Application Server ermöglichen. So eröffnet die Servlet API 3.0 einen programmatischen Weg, Servlets oder Filter in einem Web-Container zu registrieren. Aber auch die parallele Verarbeitung von Aufgaben, die sich heute praktisch nur durch Nutzung von JMS (Java Messaging Service) in einem Java EE Container realisieren lässt, unterstützt Java EE 6 durch die Einführung eines sogenannten WorkManagers besser. Da in der Vergangenheit derartige Anwendungsfälle die Umsetzung von eigenen proprietären Lösungen erforderten, betrachtet Artikel 5 die zukünftigen "Erweiterungsfähigkeiten" detailliert.

Definitiv nicht enthalten sein werden Portlet Specification (JSR 168, JSR 286), Java Business Integration (JBI), Content Repository for Java Technology API (JSR 170) sowie jegliche Unterstützung der Modularisierung. Gerade Letzteres ist schade, da ähnliche Plattformen wie die SpringSource Enterprise Plattform durch den Einsatz von OSGi einen deutlichen Schritt weiter sind. Durch die bestehende Konkurrenzsituation zwischen OSGi und dem Java Module System (JSR 277) liegt die Vermutung nahe, dass Java EE erst nach der Release von Java SE 7, die das Java Module System enthalten soll, eine Verbesserung schafft.