Kunden und Entwickler warten gleichermassen auf das Release von Red Hat JBoss EAP 7, denn Version 7 wird neben voller Java EE 7 Unterstützung auch aktualisierte Versionen diverser Komponenten und zusätzliche Funktionen bringen.
Dieser Artikel betrachtet in welchen Situationen WildFly bis zum Erscheinen von JBoss EAP 7 als Java EE 7 Implementation eingesetzt werden kann und was dabei beachtet werden muss.
Kunden und interne Entwickler interessieren sich vermehrt für Java EE 7. Die Enterprise Edition (EE) 7 von Java wurde Mitte 2013 veröffentlicht. WildFly 8 ist seit November 2014 als Final Release verfügbar – WildFly 9 seit Juli 2015 – beide sind vollumfänglich für Java EE 7 zertifiziert. WildFly ist das Community Projekt, in dem die Weiterentwicklung von JBoss EAP stattfindet. JBoss EAP erweitert WildFly um zusätzliche Qualitätssicherung, einen langen Lebenszyklus (7-10 Jahre) während dem das Produkt mit Sicherheitsupdates und Bugfixes versorgt wird, und unlimitierten Produkte- und Entwicklungssupport. Sowohl WildFly als auch JBoss EAP sind vollständig als Open Source Software lizenziert.
Kein Lifecycle für WildFly definiert
Kunden und Anbietern muss bewusst sein, dass es für WildFly keinen definierten Lifecycle gibt und bestehende Versionen nicht gewartet werden. Kurz gesagt, nur die neuste Version enthält garantiert alle Sicherheitsupdates und Bugfixes. Um einen sicheren Betrieb zu gewährleisten muss man also immer die neuste Version einsetzen, was neben den Migrationsaufwänden für den Wechsel auf eine neue WildFly Version auch Anpassungen in den darauf laufenden Applikationen nach sich ziehen kann. Red Hat bietet für WildFly zudem keinen Entwickler- und Produktesupport an. Aufgrund dieser Tatsachen setzt Puzzle WildFly nicht standardmässig ein und den Kunden muss klar sein, dass gewisse Risiken bestehen. Wir sehen den Einsatz in folgenden Szenarien allerdings als vertretbar an:
Entwicklung von Proof-of-Concepts
Für Machbarkeitsnachweise, oder Proof-of-Concepts, die nicht in Produktion gesetzt werden. Falls dafür Integrations- oder Testserver mit WildFly betrieben werden, sollte der Zugang darauf mittels Passwort eingeschränkt werden, insbesondere wenn mit realen Daten gearbeitet wird.
Isolierte Applikationen
Die Kombination von Java EE 7 und WildFly 9 eignet sich ebenfalls für Applikationen, die in isolierten Netzwerken laufen und nicht vom Internet her erreichbar sind. Um die Angriffsfläche zu minimieren, sollte die Applikation aber Passwortgeschützt und mit HTTPS gesichert sein. Eine andere Möglichkeit ist, die Applikation jeweils auf den neusten WildFly mit unterstütztem und aktuellem JDK zu migrieren.
Notlösung für produktive Applikationen
Produktive Deployments, die vom Internet aus erreichbar sind, sollten nur als temporäre Notlösung mit WildFly betrieben werden. Dabei muss garantiert sein, dass immer die neuste WildFly Version mit einem unterstützten und aktuellen JDK verwendet wird. Dies zieht allerdings Migrationsaufwände unbekannten Ausmasses nach sich, insbesondere wenn eine neue Majorversion von WildFly erscheint. Da es keinen definierten Lifecycle gibt, können die Migrationen entsprechend auch nicht geplant werden.
Falls nicht garantiert werden kann das JDK und WildFly stets aktuell sind, sollte auf den produktiven Einsatz von WildFly verzichtet werden. Grundsätzlich sollte das Ziel sein, auf JBoss EAP zu wechseln sobald Version 7 erscheint.
Wo Puzzle Sie unterstützt
Puzzle unterstützt seine Kunden bei Entwicklung, Betrieb, Wartung und Migration von Java EE 7 Anwendungen auf Java Application Servern diverser Hersteller. WildFly ist einer der wenigen Java Application Server die bereits für Java EE 7 zertifiziert sind und kann unter bestimmten Bedingungen als Übergangslösung für den Betrieb von Java EE 7 Anwendungen dienen. Wir raten aufgrund der Sicherheitsrisiken allerdings zur Vorsicht und empfehlen eine Migration auf JBoss EAP 7 sobald dieser verfügbar ist.