Falk Sippach OIO Orientation in Objects GmbH

Java-EE-Komponenten sind in den letzten Versionen immer leichtgewichtiger geworden und lassen sich daher sehr gut mit Unit-Tests auf Korrektheit prüfen.

Im Vergleich zur modernen, aufstrebenden Microservices-Bewegung wirken Applikationsserver etwas angestaubt. Viele Unternehmen möchten den neuen Architekturstil einsetzen, können und wollen aber weder auf Application Server noch auf das jahrelang angehäufte Wissen zum Java-Enterprise-Standard verzichten. WildFly Swarm wagt den Brückenschlag und erleichtert das Erstellen von Microservices-Architekturen auf Basis von Java EE. Der Application Server verschwindet dabei nicht ganz, er wird vielmehr restrukturiert und in die Anwendung mit eingepackt.

Klassische Java-Enterprise-Anwendungen – egal ob als Laufzeitmonolith oder in Form von Microservices – baut man gegen eine Vielzahl von APIs aus dem Java-EE-Standard und installiert dann das schlanke Deployment-Artefakt (enthält keine Dependencies) in einen recht schwergewichtigen Applikationsserver, der alle notwendigen Bibliotheken mitbringt. Um Isolations- und Ressourcenkonflikten aus dem Weg zu gehen, wird aber typischerweise je Server genau nur eine Anwendung deployt. Dieses Vorgehen ist aufwendig und unflexibel. Außerdem wird dem Betrieb die Arbeit unnötig erschwert. In Zeiten von Continuous Delivery und DevOps ist die zusätzliche Installation von Anwendungscontainern tatsächlich ein fragwürdiges Vorgehen. Im Fall von Microservices enthält der vollständige Application Server zudem viel mehr Funktionalität als die Anwendung überhaupt benötigt.

Die Konkurrenz in Form von Spring Boot und Dropwizard hat es vorgemacht. Sie verpackt die Anwendung mitsamt den notwendigen Bibliotheken und einem Servlet-Container in ein ausführbares Fat JAR und bietet zudem diverse zusätzliche Dienste, um die Herausforderungen der Microservices-Architektur zu meistern.

Fat JAR

Ein Fat JAR oder Uber JAR ist ein Java-Archiv, das neben den Klassen und Ressourcen des Projekts auch alle notwendigen Bibliotheken und den zur Ausführung notwendigen Applikationscontainer enthält. Die typischen Build-Management-Tools (Maven, Gradle) bieten Plug-ins an, die die deklarierten Dependencies entsprechend aufbereiten und in das JAR integrieren. Im Fall von WildFly Swarm werden die Abhängigkeiten als internes Maven Repository abgelegt und zur Laufzeit aufgelöst.

Mit WildFly Swarm hat nun auch Red Hat/JBoss diesen Weg eingeschlagen. Die Besonderheit: Hier lässt sich der volle Java-EE-Stack nutzen. Im Gegensatz zu der sonst üblichen Integration von Tomcat oder Jetty kommt mit WildFly sogar ein vollwertiger Application Server zum Einsatz. Genau genommen wurde WildFly für Swarm in seine Bestandteile zerlegt. Über diverse Konfigurationsmöglichkeiten kann man steuern, wie viel App-Server man tatsächlich in seiner Anwendung verpacken möchte. Mit WildFly Swarm kann man also genau die APIs auswählen, die gebraucht werden (Abb. 1). Das spart Ressourcen und ermöglicht einen schlanken Betriebsprozess.

Abb. 1: WildFly-Swarm-Anwendung, die nur JAX-RS, CDI und JPA nutzt

Abb. 1: WildFly-Swarm-Anwendung, die nur JAX-RS, CDI und JPA nutzt

Konfiguration: Alles läuft über Fractions

WildFly Swarm bindet die notwendigen Abhängigkeiten über so genannte Fractions ein, die sich entweder als Maven Dependencies oder programmatisch hinzufügen und konfigurieren lassen. Zum Erstellen des Fat JARs muss dabei zunächst nur der Build-Prozess angepasst werden. Das präferierte Vorgehen verwendet Maven (mindestens in der Version 3.3.x). Gradle wird zwar auch unterstützt, erhält aber nicht so viel Aufmerksamkeit seitens der Swarm-Entwickler und ist derzeit nicht so stabil. Um bereits existierende JARs oder WARs als Fat JAR zu verpacken, gibt es außerdem noch das Kommandozeilenwerkzeug swarmtool.

Den vollständigen Artikel lesen Sie in der Ausgabe:

Java Magazin 12.16 - "Serverless: Der Code im Nichts?"

Alle Infos zum Heft
298931Microservices in JavaEE mit WildFly Swarm
X
- Gib Deinen Standort ein -
- or -