© VGstockstudio/Shutterstock.com
Mit Galleon WildFly provisionieren

WildFly ganz schlank, Galleon zum Dank!


Auch WildFly entwickelt sich in Richtung Cloud. In diesem Artikel zeigen wir, wie man mit dem neuen Werkzeug Galleon maßgeschneiderte WildFly-Instanzen nach einem Baukastenprinzip erzeugt – bis hin zum boot-fähigen JAR, das WildFly und das eigene Softwareprodukt in sich vereint.

Die Entwickler bei Red Hat werden nicht müde: Mit Quarkus haben sie ein sogenanntes Microservices Framework am Start, das zurzeit sehr viel Aufmerksamkeit genießt. Der zugehörige Werbespruch „Supersonic Subatomic Java“ klingt zwar ein bisschen überzogen, dennoch handelt es sich dabei um ein höchst innovatives Projekt, das sich anschickt, Teile von Java EE möglichst schlank, performant und mit schnellen Startzeiten in die Cloud zu bringen.

Dabei konkurriert es mit anderen Java Frameworks wie Spring Boot, Payara Micro, Micronaut und Helidon. All diese Frameworks sind darauf fokussiert, den MicroProfile-Standard zu unterstützen. Dieser wiederum nimmt sich aus der Java Enterprise Edition (Jakarta EE) einige wichtige Teilspezifikationen, wie zum Beispiel JAX-RS, CDI, JSON-P und JSON-B, heraus und erweitert diese noch um zusätzliche Funktionen, die nicht im Jakarta-EE-Standard enthalten sind. Die Metrics-Erweiterung hilft beispielsweise bei der Überwachung eigener Services, OpenAPI basiert auf Swagger und unterstützt Nutzer bei der Dokumentation, und mit JWT Authentication bekommt man ein Werkzeug an die Hand, um Authentifizierung und Autorisierung von REST-Aufrufen auf Basis von JSON Web Tokens (JWT) zu realisieren. MicroProfile kommt vorrangig bei der Entwicklung von REST-basierten Anwendungen zum Einsatz und die zuvor genannten Microservices Frameworks sind allesamt sehr stark in diesem Bereich.

WildFly wird „cloud-native“

Doch was ist mit dem eher konservativen Java-Entwickler, der vielleicht die eine oder andere Spezifikation mehr aus dem Jakarta-EE-Universum einsetzen muss oder einsetzen will? Was ist mit den Leuten, die noch für (meistens ältere) Anwendungen verantwortlich sind, die auf EJB, JSF, JSP oder gar Servlets basieren? Diese Gruppe, und so klein dürfte die Anzahl der betroffenen Entwickler gar nicht sein, benötigt nach wie vor einen Applikationsserver. Schließlich wird potenziell das gesamte Portfolio von Jakarta EE benötigt und nicht nur ein Teil daraus. Damit ist man wieder beim WildFly-Server angekommen. Doch das Problem ist: WildFly ist ein vollständiger Applikationsserver, der nicht nur alle Aspekte von Jakarta EE abdeckt, sondern auch das MicroProfile im Schlaf beherrscht. Und das hat seinen Preis. Eine WildFly-Installation ist entsprechend groß, mit 200 MB aufwärts muss man rechnen. Das passt leider nicht so recht mit dem Einsatz in der Cloud zusammen. Die resultierenden Container sind viel zu groß und die Startzeiten, aufgrund der Mächtigkeit und des Umfangs von WildFly, entsprechend hoch. Erschwerend kommt auch noch die Tatsache hinzu, dass die Entwicklung Cloud-nativer Java-Anwendungen (die REST Services bereitstellen) auf klassischem Wege viel zu umständlich geworden ist: Mit Maven eine Webanwendung bauen, ein WAR erstellen und dann in den WildFly-Applikationsserver deployen ...

Wie gesagt, es gibt Anwendungsfälle, bei denen man entweder bei WildFly bleiben muss – entweder, weil es die eigene Anwendung erfordert oder, weil man Quarkus und Co. einfach noch nicht so recht über den Weg traut. Sowas soll es ja auch geben. Bei Red Hat selbst scheint es übrigens ähnliche Überlegungen gegeben zu haben, denn neben Quarkus bemüht man sich, auch WildFly entsprechend auf Stand zu halten. Ganz klar zu erkennen: WildFly soll Cloud-nativ werden.

Völlig uneigennützig macht Red Hat das natürlich nicht. Das hauseigene Cloud-Angebot OpenShift soll im Java-Umfeld schließlich nicht nur in der Lage sein, MicroProfile-Anwendungen zu unterstützen, sondern jede Form von Jakarta-EE-Anwendung. Aus diesem Grund ist es Red Hat wichtig, den eigenen Applikationsserver WildFly in Richtung Cloud zu entwickeln.

Mit Galleon wird WildFly zum Baukastensystem

Grundidee dabei ist es, WildFly nicht mehr nur als Komplettpaket zu betrachten, sondern als Baukastensystem. Theoretisch könnte man einen kompletten WildFly-Server nehmen, hat aber nun die Möglichkeit, sich über sogenanntes Provisionieren nur die Teile herauszupicken, die man für den Betrieb der eigenen Anwendung benötigt. Das macht einen WildFly-Server nicht nur schlan...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang