© Excellent backgrounds/Shutterstock.com
In welche Richtung bewegt sich Java EE?

Not your Father’s Java EE


Noch vor wenigen Jahren galt Java EE als der unumstrittene Platzhirsch im Umfeld des Java-basierten Enterprise Computings. Ausgereifte APIs und Runtimes machten das Framework sowohl zur Entwicklungs- als auch zur Laufzeit zu einer sicheren Wahl. Mittlerweile aber gibt es Tendenzen am Markt, die sich scheinbar nicht wirklich mit dem technologischen Schwergewicht Java EE vereinbaren lassen: Fokussierung auf Fachlichkeit (Domain-driven Design), Multi-Channel-Anwendungen, Verlagerung von Logik in Richtung HTLM5 and Friends via clientseitiger JavaScript-Frameworks und nicht zuletzt natürlich die Wunderwaffe Microservices. Für einen Java-EE-Entwickler stellt sich da unweigerlich die Frage: „Darf ich noch mitspielen oder bin ich schon legacy?“.

Java-EE-Entwickler sind es gewohnt, dass „Architekten“ schichtenbasierte Frameworks oder Generatoren inklusive eigener DSLs bauen, anstatt sich um fachlich getriebene Modularisierung oder fachliche Basiskomponenten zu kümmern. Und auch die einzelnen Teams orientieren sich mit ihren jeweiligen Spezialisten in der Regel eher an den verschiedenen Schichten, wie User Interface, Businesslogik und Persistenz, anstatt sich „cross functional“ aufzustellen.

Spätestens seit Conway’s Law wissen wir aber, dass dieses Vorgehen zu unnötig komplexen Systemen führt, die nur wenig – sehr wenig – Flexibilität mit sich bringen (Abb. 1): „Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.“ (Conway’s Law, [1]).

roewekamp_javaee_1.tif_fmt1.jpgAbb. 1: Conway’s Law

Wie also sind wir in dieses Dilemma geraten? Und was können wir dagegen tun? Fakt ist, dass Java EE mittlerweile eine sehr ausgereifte Basis für die Entwicklung von Enterprise-basierten Systemen – verteilt oder nicht – darstellt. Dies gilt sowohl für die APIs als auch für die Runtimes. Wie können oder müssen wir uns also bewegen, um dieses Potenzial auch sinnvoll auszunutzen und so dem sich stetig wandelnden Anforderungen des Markts gerecht zu werden?

Geschichtsunterricht

Um es gleich vorweg zu nehmen: Früher war alles besser. Viel besser! In den guten alten Zeiten von J2EE reichte es zur Wahrung seiner Position als Enterprise Developer vollkommen aus, sich den lieben langen Tag mit den umfangreichen Pattern-Katalogen [2] aus dem Hause Sun (J2EE Blueprints) zu beschäftigen und möglichst viele der dort aufgeführten „Schmankerl“ in das Firmenframework einzubauen. Das hauseigene Framework war natürlich trotz J2EE Pf...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang