zurück zum Artikel

Heute wirkt eine industrielle Spezifikation für eine Softwareplattform wie ein schwerfälliges Monster. Gilt das auch für die demnächst erscheinende neue Version der Java Enterprise Edition?

In einer Zeit, in der die Open-Source-Community in vielen Java-Bereichen die innovative Federführung übernommen hat, wirkt ein industrieller Spezifikationsprozess für eine Softwareplattform wie ein schwerfälliges Monster. Zu langsam in der Formulierung, zu viele Kompromisse, zu wenig auf die Bedürfnisse der Anwender ausgerichtet. Gilt die Kritik auch für die neue Version der Java Enterprise Edition, die in Kürze erscheinen soll?

Auf den ersten Blick scheint die Java Enterprise Edition 6 (Java EE 6) alle Vorurteile zu bestätigen: Gestartet im Jahr 2007 als Java Specification Request (JSR) 313 [1] beziehungsweise noch mal neu aufgezäumt als JSR 316 [2] sollte die Spezifikation 2008 abgeschlossen sein. Den ersten wichtigen öffentlichen Milestone (Public Review Ballot) gab es jedoch erst in diesem Frühjahr. So überrascht es nicht, dass Paul Hinz – Director of Java EE/GlassFish – von einem Veröffentlichungsdatum nicht vor Herbst 2009 ausgeht [3] beziehungsweise Release-Manager Roberto Chinnici mittlerweile [4] gar von November 2009 spricht. In der Zwischenzeit diskutiert die Java-Entwicklergemeinde mehr oder minder lebhaft in den einschlägigen Foren die bisher bekannten Details, wobei – wie in der Vergangenheit – vor allem die Kritiker vergleichsweise laut Position ergreifen.

Wie ist es wirklich um Java EE 6 bestellt? Ist die Kritik an den Ergebnissen der Expertenkommission, der vor allem die "Java EE Application Server"-Hersteller angehören, gerechtfertigt? Oder ist der schlechte Ruf von Java EE einfach nur die Folge der in den letzten Jahren stattgefundenen Polarisierung innerhalb der Enterprise-Java-Welt?

Um es gleich vorwegzunehmen: Die Java EE, speziell Version 6, ist deutlich besser als ihr Ruf. Eine detaillierte Begründung der Aussage bedarf jedoch eines genaueren Blicks hinter die Kulissen, dessen sich die hier startende sechsteilige Artikelserie zur neuen Spezifikation annimmt. Besonderes Augenmerk legen die Beiträge auf die Verbesserungen und Vereinfachungen für den "Java EE"-Entwickler und den -Einsteiger. Auch architektonische, integrative und releaseprozessrelevante Aspekte sollen nicht zu kurz kommen.

Der erste Beitrag gibt einen allgemeinen Überblick über die "Java EE 6"-Spezifikation. Die Teile zwei bis fünf betrachten ausgewählte technische Bereiche der Spezifikation. Der letzte Artikel fasst das bis dahin identifizierte Neue und/oder Verbesserte in einer Betrachtung aus Softwarearchitektur-Sicht zusammen.

Auf den ersten Blick: alles beim Alten

Vergleicht man die ersten Sätze der "Java EE 6"-Spezifikation mit denen ihrer Vorgänger, hat sich scheinbar nichts geändert. Im Wesentlichen versucht Java EE ein standardisiertes Rahmenwerk für die Entwicklung mehrschichtiger "Enterprise Services" bereitzustellen. Darunter versteht man hochverfügbare, sichere und skalierbare Dienste, die unternehmenskritische Funktionen übernehmen. Es sollen sich – so steht es auf dem Papier gänzlich ohne Bezugsgröße – die Komplexität und die Kosten der Entwicklung spürbar reduzieren lassen.

Etwa 200 Seiten legen anschließend das Entwicklungs-, Deployment- und Laufzeitmodell fest. Zentrale Bestandteile bilden weiterhin eine standardisierte "Java EE"-Plattform mit Kompatibilitäts-Test-Suite, eine Referenzimplementierung sowie die Java EE Blueprints, die die Spezifikation um Architekturansätze und Best Practices ergänzen. Die wesentlichen technischen Details sucht man im Rahmenwerk jedoch vergebens.

Das liegt vor allem daran, dass die "Java EE"-Spezifikation – wie ihre Vorgänger – ein sogenannter Umbrella JSR ist. Diese übernehmen die Aufgabe, bestehende Spezifikationen zu einer aufeinander abgestimmten Spezifikation zu verbinden und die Interaktion untereinander zu regeln beziehungsweise gegebenenfalls einzuschränken. In Summe existieren somit in etwa 30 Spezifikationen, die Java EE 6 ausmachen.

Erste sichtbare Unterschiede zu früheren Versionen finden sich erst in den Zielen der Spezfikation. Standen dort früher Asynchronität, Verteiltheit und Hochverfügbarkeit, finden sich heute dort die Stichworte Codereduzierung, Verringerung der Komplexität, verbesserte Integration sowie Erweiterbarkeit.

Reduktion

Weniger ist mehr

Die Version 6 führt die Ansätze und Ideen von Java EE 5 konsequent weiter. Getreu dem Motto "weniger ist mehr" setzt die Spezifikation verstärkt auf ein metadatengetriebenes Entwicklungsmodell mit sinnvollem Default-Verhalten. Statt jegliche Details wie in Zeiten von J2EE 1.4 grundsätzlich durch Klassen beziehungsweise Interfaces und deklarativ in XML-Dateien beschreiben zu müssen, kommt man heute mit wenigen Metadaten in Form von Java-Annotationen aus. In der Regel versieht der Entwickler dazu Klassen oder Interfaces mit einfachen Annotationen. Die Bereitstellung des sinnvollen grundsätzlichen Verhaltens ist anschließend die Aufgabe der Laufzeitumgebung, genannt Java EE Container.

Folgendes Beispiel verdeutlicht das metadatengetriebene Modell. Setzt man ein Java Servlet, das sich mit Deployment in einen Java EE Web Container automatisch unter der URL http://{server}/{context}/foo ansprechen lässt, gemäß Java EE 6 um, reicht die Angabe einer einfachen Java-Annotation im Servlet. Eine zusätzliche Konfiguration in XML-Deskriptoren entfällt.

@WebServlet("/foo")
public class Simple30Servlet extends HttpServlet {
 ...
}

Weichen nun die Anforderungen vom vordefinierten Verhalten der Plattform ab, lassen sich die Abweichungen relativ leicht mit zusätzlichen Eigenschaften einer Annotation, durch weitere Annotationen oder alternativ in XML beschreiben. Das folgende Code-Fragment aktiviert die asynchrone Kommunikation für ein HTTPServlet.

@WebServlet("/foo", asynchSupported=true)
public class Simple30Servlet extends HttpServlet {
 ...
}

Zugegebenermaßen hat sich dieses Entwicklungsmodell in vielen anderen Plattformen unter dem Stichwort "Convention over Code" längst etabliert. Umso erfreulicher ist es, das das Muster nun das grundsätzliche Paradigma der Java EE ist. Die wesentlichen Neuerungen der metadatengetriebenen Entwicklungen beleuchtet der zweite Teil der Artikelserie.

Häppchenweise Entwicklerkost

Jedoch scheint die Verwendung von Metadaten nur einen Teil der Komplexität der Plattform zu verringern. Was bleibt, ist weiterhin die Tatsache, dass 30 Spezifikationen auf mehreren tausend Seiten unzählige Vorgaben, Designmuster und APIs definieren. Vergleicht man daher Java EE mit anderen Techniken wie Spring oder Ruby on Rails, scheint fraglich, wie Enterprise-Java die eingangs versprochene Reduktion von Komplexität und Kosten der Entwicklung jemals einhalten will.

Die Expertenkommission hat das Problem erkannt und versucht durch sogenannte Java EE Profiles und durch Pruning sich des Themas anzunehmen. Mit den Profiles kann Java EE 6 ausgehend von einem Basisprofil unterschiedliche Techniken zu einer Konfiguration zusammenstellen. Die Untermengen an Techniken definieren den Rahmen der Laufzeitumgebung, in dem sich ein Anwendungsentwickler bewegen muss.

Das Basisprofil umfasst laut Spezifikation unterschiedliche Lebenszyklus-Annotationen, die Java Transaction API (JTA) und einen kleinen Teilbereich des Java Naming und Directory Interfaces (JNDI). Darüber hinaus definiert die Spezifikation keine Java EE Profiles. Vielmehr sollen Profile außerhalb von ihr entstehen. Ein Beispiel dafür ist das Java EE Web Profile, das parallel mit der "Java EE 6"-Spezifikation erscheint. Weitere Ideen wären Portlet Profile oder Telco Profile, die zurzeit im Gespräch sind. Die weitergehende Betrachtung der Java EE Profiles und des Java EE Web Profile inklusive der Beziehung zu einem Konzept namens EJB Lite erfolgt im dritten Teil der Artikelserie.

Vorbereitung zum Frühjahrsputz

Im Verlauf der "Java EE"-Weiterentwicklung haben die Experten die Spezifikation der Plattform kontinuierlich ergänzt und erweitert. Gleichzeitig stellte jede Release sicher, abwärtskompatibel zu sein. Als Konsequenz trägt sie heute Ballast mit sich, der im praktischen Einsatz keine oder nur noch eine geringe Relevanz besitzt. Wie von einem industriellen Standardisierungsprozess nicht anders zu erwarten, werden mit Java EE 6 nicht einfach Techniken und Funktionen gestrichen. Stattdessen schafft die neue Version mit dem Pruning die Möglichkeit, Funktionen der Plattform in einem zweistufigen Prozess zu entfernen.

In der ersten Stufe sind zu beseitigende Funktionen zu identifizieren und durch die Expertenkommission in einer Java EE Release N aufzunehmen. Die Streichung der Komponenten erfolgt jedoch erst in der zweiten Stufe mit der Release N+1. Zu den Kandidaten zählt aktuell die Container Managed Persistence der Enterprise JavaBeans (EJB). Weitere wie JAX-RPC sind nicht auszuschließen.

Technik-Upgrade

Technik- und API-Upgrade

Von besonderer Bedeutung sind die technischen Neuerungen, die die neue Version ausmachen. Wie in der Tabelle Technik-Update [5] 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.

Fazit

Fazit

Glaubt man Rod Johnson – CEO von SpringSource und gleichzeitig konstruktiver Kritiker der gesamten "Java EE"-Welt –, macht "es Java EE 6 richtig [6]". Auch wenn er die Aussage im Wesentlichen auf Java EE Profiles bezieht, kann man sie durchaus auf viele andere Bereiche ausweiten. Insbesondere die Profiles vereinfachen den Einstieg in die Plattform deutlich. Verbunden mit dem verbesserten Programmiermodell aus Java EE 5, das mit der neuen Version noch an einigen Stellen überarbeitet wurde, sinkt die Komplexität der Entwicklung deutlich.

Ein wesentlicher Schlüssel zum Erfolg scheint die Abkehr der Expertenkommission von der Spezifikation am Reißbrett hin zur aktiven Beobachtung der Trends und Ideen der Java-Community zu sein. Getreu der Devise "evaluieren statt diktieren" finden so die Innovationen der kreativen Java-Community Einzug in eine standardisierte Welt. Dass das durchaus gut gelingen kann, zeigen die verbleibenden fünf Teile der Artikelserie.

Lars Röwekamp
ist Gründer des IT-Beratungs- und Entwicklungsunternehmens OpenKnowledge GmbH und beschäftigt sich mit der eingehenden Analyse und Bewertung neuer Software- und Techniktrends.

Jens Schumann
ist CTO des IT-Beratungs- und Entwicklungsunternehmens OpenKnowledge GmbH und beschäftigt sich seit der Java Servlet API mit dem Entwurf und der Realisierung von Enterprise-Java-Anwendungen – mit und ohne Java EE.

Links & Literatur

1. Zurückgezogener Java EE 6 JSR [7]
2. Aktueller Java EE 6 JSR [8]
3. Interview mit Paul Hinz zu Java EE 6 [9]
4. Rod Johnson: "Java EE 6 Gets it Right" [10]

Technik-Update Java EE 6

[11]Technik-Update Java EE 6

* Stand Java EE 6 Public Review Ballot; ** Offiziell existiert keine Versionsnummer; *** Status inoffiziell fraglich; **** Ausschluss wird diskutiert (ane [12])

URL dieses Artikels:
https://www.heise.de/-403669

Links in diesem Artikel:
[1] http://jcp.org/en/jsr/detail?id=313
[2] http://jcp.org/en/jsr/detail?id=316
[3] http://www.internetnews.com/dev-news/article.php/3825056/Where+Is+Java+EE+6.htm
[4] https://www.heise.de/news/Dependency-Injection-in-Java-EE-6-finale-Verabschiedung-verschiebt-sich-749837.html
[5] #l1-u4
[6] http://blog.springsource.com/2007/07/03/java-ee-6-gets-it-right/
[7] http://jcp.org/en/jsr/detail?id=313
[8] http://jcp.org/en/jsr/detail?id=316
[9] http://www.internetnews.com/dev-news/article.php/3825056/Where+Is+Java+EE+6.htm
[10] http://blog.springsource.com/2007/07/03/java-ee-6-gets-it-right/
[11] 
[12] mailto:ane@heise.de

Copyright © 2009 Heise Medien