AngularJS und Java EE - Hochzeit mit Hindernissen

Wer kennt die Aktuellen Trends im Bereich Web-Entwicklung nicht ? JavaScript Client Frameworks für die Verlagerung des Rendering vom Server auf den Client. Komponentenbasierte Entwicklung und Single Page Applications. Im Server geht der Trend zu Microservices und reaktiven Systemen auf Grundlage des reaktiven Manifests.

Kehrt man nun in die echte Realität seiner Projektlandschaft zurück wird man in den seltensten Fällen "grüne Wiese" Projekte vorfinden, in die man derartige Konzepte problemlos einfließen lassen kann. Meistens sieht man sich eher mit Altsystemen konfrontiert, die über Jahre gewachsen sind und in denen die verschiedensten Stile und Architekturen eingeflossen sind.

Der Folgende Artikel zeigt am Beispiel eines Angular JS Web-Client für eine Bestandsapplikation eine Möglichkeit diesen in eine bestehende JavaEE Applikation zu integrieren:

Hat man einen JavaEE konformen Application Server zur Verfügung ( JBoss / Websphere o.ä. ), spricht prinzipiell erstmal nichts dagegen, diesen zusätzlich als simplen Webserver zu nutzen. Somit wird alles was für den HTML-Client nötig ist, in ein war Projekt verlagert.

Dies hat an dieser Stelle zwei interessante Aspekte: Zum einen können die Security-Mechanismen der Middleware verwendet werden um den Zugriff auf den Client zu beschränken, zum anderen besteht auch im Nachhinein ohne größere Probleme die Möglichkeit, dass war Modul herauszulösen und z.B. auf einen Tomcat oder ähnliche Produkte zu deployen, wenn leichtgewichtigere Lösungen gefragt sind. Im einfachsten Fall extrahiert man den entsprechenden Ordner und lässt diesen von einem beliebeigen Webserver ausliefern.

Dank eigenem Build Ökosystem verhält sich die Client Applikation im normalen JavaEE Kontext nicht als Fremdkörper. Prinzipiell kann man den Ordner, der die Angular Inhalte beherbergt, einfach in einer beliebigen IDE importieren, via node.js einen kleinen lokalen Webserver starten und das UI recht autark bearbeiten. Für die Versorgung mit Daten sorgen zur Entwicklungszeit meist statische Dummies. Solange die Schnittstellen und deren Inhalte definiert sind, stellt dies aber erstmal kein Problem dar. Es birgt sogar den Vorteil, dass der Client losgelöst und ohne Netzwerkverbindung entwickelt werden kann.

Wie bringt man die beiden Welten nun zusammen, wenn am Ende des Build-Prozesses ein komplettes, gemeinsames EAR entstehen soll, mit dem eingebetteten .war File des Web-Clients? Dafür gibt es ein praktisches Maven Plugin um Grunt Jobs auszuführen. Das Plugin erledigt automatisiert im Kontext von Maven sämtliche arbeiten, die ein lokales ausführen von Grunt erledigen würde. Während der Bearbeitung werden die Inhalte in ein Arbeitsverzeichnis kopiert. Somit kann man dort z.B. die Tests ausführen lassen, Transpiling durchführen lassen, uns am Ende das mittels "uglify" ein kompaktes, komplettes JavaScript auszuliefern, das mit dem Maven war-plugin im ear verpackt wird und ausgeliefert (deployed) werden kann.

Der Vorteil bei diesem Vorgehen liegt meiner Meinung nach daran, dass es sich sehr nah an monolithischen, bestehenden Build-Strukturen etablieren lässt, aber trotzdem eine ausrechend loose Kopplung besitzt, um ohne größeren Aufwand als einzelnes Projekt / Produkt / Artefakt extrahiert werden zu können.

Ein Beispiel, wie das ganze aussehen könnte, findet man auf Github unter:

angular ear example