Die Applikationsserver JBoss EAP und WildFly werden beide von Red Hat herausgebracht und betreut. Sie dienen denselben Zwecken und damit stellt sich die Frage, wo die Unterschiede und Gemeinsamkeiten genau liegen. Vorab lässt sich feststellen, dass die Gemeinsamkeiten wesentlich umfangreicher als die Unterschiede sind. WildFly ist gewissermaßen der Testbereich für JBoss EAP. Beide implementieren den Standard Jakarta EE.
Was ist Jakarta EE?
Der Name Jakarta ergab sich aus der Beachtung von Namensrechten, die eigentlich passende Bezeichnung wäre immer noch Java. Jakarta EE ist die Spezifikation einer Umgebung für die Ausführung von Java-Anwendungen. Diese sind oft verteilt und webbasiert. Eine Plattform wie Jakarta EE ist ihrer Eigenschaft nach eine Version von Middleware. Sie ist also Software, die zwischen dem Betriebssystem und einer Anwendung angesiedelt ist. Die Komponenten sind in der Programmiersprache Java geschrieben und bestehen aus größeren Teilen, die für Anwendungen vom Entwickler zusammengesetzt werden können. Diese Teile müssen also nicht mehr für jede Anwendung neu geschrieben werden. Jakarta EE liegt auch im engeren Sinn zwischen Betriebssystem und Anwendung, denn die Middleware läuft über der Java Standard Edition. Die Funktionen und Klassen von Java können also für eine Entwicklung genauso wie die Jakarta-spezifischen Teile verwendet werden.
Die Idee hinter einer solche Middleware ist es, Komponenten verschiedener Hersteller verwenden zu können. Dazu sollten diese Komponenten einfach den Standard erfüllen. In der Praxis ist das allerdings nicht immer der Fall. Schon Java selbst wird von einer Java-Engine ausgeführt, die auf verschiedenen Betriebssystemen zur Verfügung steht. Ein Java-Programm sollte also von jeder solchen Java-Engine ausführbar sein, was auch nicht immer der Fall ist. Der Anspruch lautet, etwas einmal zu entwickeln und überall ausführen zu können. Real kann es darauf hinauslaufen, dass man den Code zuerst auf verschiedenen Systemen einem Debugging unterziehen muss. Jakarta EE ist eine der großen Middleware-Plattformen und steht in direkter Konkurrenz zu Microsofts .NET-Plattform.
Welche Umgebung wird von Wildfly und JBoss EAP implementiert?
Beide Implementierungen setzen zuerst ein Client-Server Modell um. Die Funktionalität wird auf einem Server bereitgestellt, auf den die Clients von überall im Netzwerk zugreifen können. Diese Funktionen müssen also auch nur auf einem Server betreut und gewartet werden. Für einen EAP oder Enterprise Application Server kommt noch eine dritte Komponente zur Datenspeicherung hinzu, die üblicherweise von einer Datenbank ausgeführt wird.
In einer solchen Umgebung werden von Middleware wie Jakarta erweiterte Funktionen der Dienste des Betriebssystems bereitgestellt. Während das Betriebssystem nur einen Kommunikationskanal für einen Strom von Bytes zur Verfügung stellen mag, bietet Middleware wie Jakarte EE Dienste für die Kommunikation von Prozessen statt von einzelnen Geräten.
Jakarta EE stellt drei Bereiche von Funktionen zur Verfügung:
- Zugang zum Web für Webbrowser
- Web Services: Diese bieten einen standardisierten Zugang zu Ressourcen und sind vorgesehen für die Kommunikation zwischen Geräten. Dabei kann es sich neben physischen Geräten auch um virtuelle Maschinen handeln.
- Messaging: Diese Funktion bietet den Austausch nicht über eine feste Verbindung, sondern asynchron und daher ohne den Prozessen aufgezwungene Wartezeiten.
Entstehung des von JBoss EAP und WildFly implementierten Jakarta EE
Bis 2017 wurde von der Firma Oracle die Java Platform unter diesem Namen angeboten. Im Jahr 2019 wurde diese von Oracle an die Eclipse Foundation übergeben. Der Übergang stellte sich folgendermaßen dar:
- 2019: Jakarta EE 8 wird veröffentlicht und ist vollkompatibel zur Java Platform 8
- 2020: Jakarta EE Version 9.
- 2021: Jakarta EE Version 9.1
Implementierung von Jakarta EE
Für den Betrieb von Jakarta EE ist als Laufzeitumgebung ein Jakarta EE Application Server erforderlich. Die Referenzimplementierung eines solchen Servers wird von Eclipse zur Verfügung gestellt. Sowohl JBoss EAP und Wildfly sind ihrerseits solche Implementierungen des Standards.
Wirtschaftliche Unterschiede zwischen WildFly und JBoss EAP
Ursprünglich wurde WildFly unter dem Namen JBoss AP angeboten, wobei die Akronyme für „enterprise application platform“ und „application server“ stehen. Die Namensänderung von JBoss AP zu WildFly wurde vollzogen, um die beiden Projekte für die Nutzer klarer auseinanderhalten zu können.
JBoss EAP ist ein Derivat von WildFly. Beide Systeme sind quelloffen, es ist aber WildFly, das von freiwilligen Programmierern weiterentwickelt wird. Wirtschaftlich gesehen ist also der wesentliche Unterschied, dass für WildFly im Gegensatz zu JBoss EAP kein kommerzieller Support verfügbar ist.
JBoss steht für „javaBean open source software“ und wird von Red Hat kommerziell unterstützt. Ursprünglich wurde das System von einer eigenen Firma entwickelt, die im Jahr 2006 von Red Hat übernommen wurde.
Technische Unterschiede zwischen JBoss EAP und WildFly
Die unterschiedliche Art der Weiterentwicklung führt zu bestimmten Differenzen der beiden Systeme. WildFly kann man als das Experimentierfeld für JBoss EAP sehen. In WildFly werden also zuerst neue Funktionen eingebaut und getestet. Bewähren sie sich, werden sie mit einiger Verzögerung in JBoss EAP übernommen. Praktisch bedeutet das auch, dass WildFly in einem viel schnelleren Release-Zyklus als JBoss EAP veröffentlicht wird.
Geht es also um das Ausprobieren der neuesten Version, ist WildFly ganz sicher die richtige Wahl. Traut man sich den Betrieb ohne Support zu, kommt WildFly auch dafür in Frage. Ein markanter technischer Unterschied besteht in der Integration einer MicroProfile API, die in WildFly verfügbar ist. In JBoss EAP sind also nicht die neuesten Funktionen verfügbar, man kann aber annehmen, dass das System stabiler funktioniert. Die dort verfügbaren Teile haben sich im Experimentierfeld WildFly bewährt. Klarerweise führt diese Art der Entwicklung dazu, dass JBoss EAP weniger oft in einer neuen Version herausgebracht wird.
Im Gegensatz zu WildFly ist ein MicroProfile API nicht von Anfang an integriert, man muss aber trotzdem nicht darauf verzichten. Es ist nur notwendig, diese API eigens zu installieren. Auch dafür kann man sich auf den kommerziellen Support stützen.
Was sind die Gemeinsamkeiten von WildFly und JBoss EAP?
Beide Systeme sind zertifiziert und das bedeutet, dass beide den Jakarta EE Standard korrekt umsetzen. Das sollte Kompatibilität über verschiedene Hersteller garantieren. Ob das tatsächlich der Fall ist, sollte aber im Einzelfall überprüft werden. Beide Systeme werden von der Firma Red Hat betreut. Beide Systeme werden unter derselben Lizenz veröffentlicht, bei der es sich um die LGPL handelt.
Die Art der Beziehung zwischen den beiden Systemen bedeutet schließlich und endlich, dass der Quellcode der beiden Systeme sehr ähnlich ist. Die in JBoss EAP verfügbaren Funktionen werden üblicherweise vom selben Quellcode implementiert wie in WildFly.
