JAX Countdown

Überleben im Java-EE-Dschungel

Hartmut Schlosser

Eines der Hauptanwendungsfelder von Java ist dessen Einsatz im Enterprise-Bereich. Und so ist es logisch, dass auch die JAX 2012 Java Enterprise zu einem Kernthema macht – mit Special Days zu Java EE, Spring, Apache Middleware und zahlreichen Sessions zu Enterprise-Frameworks wie Grails, Vaadin und Wicket. Dem Java-EE-Standard widmen wir uns gleich an zwei Tagen: Am Dienstag gibtÃ82B4s den Java EE Day, an dem Sie sich einen Überblick über den aktuellen Stand der Technologien verschaffen können, am Freitag dann den Java EE Experts Day, an dem wichtige Themen vertieft werden und Experten Rede und Antwort stehen.

In dieser Folge des JAX-Countdown sprechen wir mit Java-EE-Days-Moderator Lars Röwekamp über aktuelle Entwicklungen bei Java EE und über den alten Glaubenskrieg zwischen Spring- und Java-EE-Entwicklern. Außerdem gibt Lars Tipps, wie man sich im Java-EE-Dschungel der Spezifikationen zurecht findet. Sein Motto: Wisse, was du tust!

Java EE auf der JAX

Java EE Day

Dienstag, 17. April 2012

  • No Tier Enterprise Application mit CDI – Lars Röwekamp
  • RESTful Services mit Java EE – Thilo Frotscher
  • Java EE 7: Neues aus EJB 3.2, CDI 1.1, JPA 2, JMS 2 und den Wolken – Adam Bien
  • Java EE 6 Open-Source-Server im Parcours – Peter Roßbach
  • Java Persistence: Standard meets Reality – Arne Limburg

Java EE Experts Day

Freitag, 20. April 2012

  • eXtreme Enterprise Security – Arne Limburg
  • CDI Extensions – Mark Struberg
  • BPM und Java EE : Das perfekte Team für Prozessanwendungen? – Bernd Rücker, Daniel Meyer
  • Lessons Learned: Surviving the Java-EE-Dschungel – Arne Limburg, Bernd Rücker, Daniel Meyer, Lars Röwekamp

Infos: www. jax.de

JAXenter: Java EE 6 gewinnt immer mehr an Zuspruch. Was macht Java EE denn plötzlich so attraktiv, wo es doch lange Zeit den Ruf hatte, kompliziert und schwergewichtig zu sein.

Lars Röwekamp: Mit Java EE 5 und 6 sind völlig neue Paradigmen in die standardisierte Enterprise-Java-Welt eingeflossen. Während in den vorherigen Versionen der Fokus meist auf technologischen Erweiterungen lag – immer mehr, zum Teil schlecht aufeinander abgestimmte APIs -, stehen in Java EE 5 und 6 „Ease of Development“ und „Flexibility“ im Vordergrund. Der Trick dabei ist, dass bei allen APIs von einem Standardverhalten ausgegangen wird, welches im Gegensatz zu früher nicht explizit programmiert bzw. konfiguriert werden muss. Ein Beispiel ist das transaktionale Verhalten einer EJB-Business-Methode. „Convention over Code“ und „Convention over Configuration“ sorgen dafür, dass Enterprise-Anwendungen heute schneller und mit deutlich weniger Code erstellt werden können.

Die Grundidee, die bereits in der ersten J2EE-Spezifikation formuliert wurde – Entwickler sollen sich auf die Umsetzung von Businesslogik konzentrieren können und nicht um die Bereitstellung von Infrastruktur kümmern müssen – wird mit Java EE 5 und 6 endlich Realität.

Da ganz nebenbei eine Reihe technologischer Abhängigkeiten und Vererbungshierarchien weggefallen sind, ist Java EE plötzlich auch testbar geworden. Ein Mehrwert gegenüber den vorherigen Versionen, der häufig unterschätzt wird.

JAXenter: Kürzlich gab es eine ziemlich heftige Diskussion zwischen Spring-Entwicklern und Java-EE-Vertretern – wieder einmal um die alte Frage, was denn nun besser sei. Plötzlich heißt es, Spring sei schwergewichtig und umständlich – oder gar Legacy. Andererseits betonen Spring-Entwickler, dass es schon in der Natur eines Java-Standards wie Java EE liege, immer nur die Probleme von gestern zu lösen. Den neuen Herausforderungen sei gerade Spring besser gewachsen. Kann man das als Evangelisierung abtun, oder steckt da ein wahrer Kern drin?

Lars Röwekamp: Diese Diskussion ist fast genauso alt, wie Spring selbst. Meiner persönlichen Meinung nach werden dabei aus politischen Gründen bewusst Äpfel mit Birnen verglichen. Java EE würde es heute wohl nicht (mehr) geben, wenn vor mittlerweile fast 10 Jahren nicht das eine oder andere alternative Framework aufgekommen wäre – Spring ganz vorne mit dabei. Wenn man nun Spring mit Java EE vergleicht, muss man deutlich zwischen Spring Core und den vielen nützlichen Zusatz-Libraries unterscheiden. Da fast alle positiven Ansätze aus Spring Core in den Standard eingeflossen sind, dabei aber gleichzeitig auch Innovationen aus anderen Frameworks übernommen wurden, macht es heute sicherlich wenig Sinn, ein „Green Field Project“ auf Basis von Spring Core zu starten. Anders dagegen sieht es mit den vielen „Nebenprodukten“ innerhalb der Spring-Welt aus. Hier gibt es nach wie vor so einiges, was wir in der Java EE vergeblich suchen.

Wir als open knowledge gehen die Sache in der Regel ganz pragmatisch an. Wenn nichts gegen den Standard spricht, dann nehmen wir den Standard – denn der Mehrwert, „Standard“ zu sein bringt, in diesem Fall den entscheidenden Vorteil.

Eine viel interessantere Frage ist meiner Ansicht nach, wie man mit den vielen bereits existierenden Spring-Projekten umgehen sollte. Wir bekommen in letzter Zeit vermehrt Anfragen zur Migration hin zu Java EE. Nun stellt sich natürlich die Frage, warum ich etwas migrieren soll, was eigentlich einwandfrei funktioniert. Wenn also – außer dem technologischen Ansatz – keine weiteren Aspekte für eine Migration sprechen, raten wir eher davon ab. Wenn allerdings Spring im Zusammenhang mit anderen, mittlerweile veralteten Frameworks genutzt wurde – Struts 1.x ist hier ein Klassiker – oder aber ein Refactoring aus Gründen stark erweiterter oder geänderter Fachlichkeit unumgänglich ist, dann macht es durchaus Sinn, die Gelegenheit auch zu einem Technologiewechsel zu nutzen.

JAXenter: Dein Spezialthema ist ja auch CDI – Context & Dependency Injection. Ein neues Entwicklungsparadigma hält Einzug, sagst du, das die klassische Mehrschichtwebanwendung ablöst und sogar ein neues Zeitalter einleutet. Was ist denn so revolutionär an CDI in Java EE?

Lars Röwekamp: Zunächst einmal halten dank CDI einige Pattern in die Java-SE- und EE-Welt Einzug, die bisher nur den EJBs vorbehalten waren. Als ein Beispiel wäre hier das Observer Pattern oder Interceptors zu nennen. Zusätzliche bekomme ich mit CDI ein starkes und flexibles Komponentenmodell – inklusive Lifecycle Management und Scoping – an die Hand, welches gleichzeitig extrem leichtgewichitg ist und über alle Schichten hinweg genutzt werden kann. Auch wenn sich EJBs in der Version 3.1 im Extremfall mit einer einzigen Klasse realisieren lassen, bringen sie doch nach wie vor einiges an serverseitigem Overhead mit sich. All die EJB-Vorteile (Transaktionsmanagement, Security, Pooling, Concurrency, … ) haben eben ihren Preis – und den möchte man eigentlich nur dann bezahlen, wenn man diese Features auch wirklich nutzt.

Zusätzlich erhalte ich dank einiger CDI-spezifischen Features (z.B. Producer Methods) die Möglichkeit, meine Anwendung deutlich zu entzerren und so von dem klassischen Schichtenmodell zu abstrahieren. Dabei rückt die umzusetzende Fachlichkeit noch stärker in den Vordergrund. Die so entstehende Architektur fühlt sich zunächst erst einmal ein wenig ungewohnt an, bringt aber – nach einer kurzen Eingewöhnungsphase – durchweg positive Aspekte mit sich. Der wesentliche Mehrwert, den wir aus unseren praktischen Erfahrungen mit den ersten wirklich großen Projekten der letzten 12 Monate gezogen haben, ist die Tatsache, dass sich die Entwickler wesentlich stärker mit der Fachlichkeit identifizieren als bisher. Wer das ganze einmal „live“ erleben möchte, kommt am besten in meinen Talk „No-Tier Enterprise Applications mit CDI“ auf der JAX 2012.

Last but not least ist dann da noch der CDI-Extension-Mechanismus. Mit relativ wenig Aufwand lässt sich das Framework beliebig erweitern, ohne dabei den Standard zu verlassen. Eigene Scopes, annotationsbasiertes und gleichzeitig leichtgewichtiges Transaktionsmanagement für POJOs oder eine Spring-CDI-Bridge sind nur drei der unzähligen Beispiele heute bereits existierender Erweiterungen.

Rein theoretisch ließen sich auf Basis von CDI Extensions – neben den bereits genannten Transaktionen – wahrscheinlich alle „Special-Features“ der derzeitigen EJB-Spezifikation realisieren, so dass diese auch unabhängig von EJB genutzt werden können. Die verschiedenen EJB-Typen selbst wären dann CDI-Stereotypen, die einzelne der Extensions in sich aggregieren. Ein Ansatz, der aktuell bereits in der Java EE und EJB Community diskutiert wird.

Geschrieben von
Hartmut Schlosser
Kommentare

Schreibe einen Kommentar

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