Enterprise-Java im Wandel - eine Standortbestimmung
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?
- Lars Röwekamp
- Jens Schumann
- Alexander Neumann
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?
Quo vadis Java EE 6?
- Ăśber den Stand der Dinge im "Java EE 6"-Umfeld
- Convention over Code
- Java EE Profiles beziehungsweise "Java EE light"
- Java Web Services: JAX WS und REST API
- App Server Extensibility: Server-Erweiterungen leicht gemacht
- Java EE Blueprints revisited: Die passende Architektur fĂĽr die neuen APIs
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 beziehungsweise noch mal neu aufgezäumt als JSR 316 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 beziehungsweise Release-Manager Roberto Chinnici mittlerweile 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.
