Anmerkung: Der Text basiert auf einem Artikel, der Anfang Juni 2012 in der Zeitschrift Java aktuell erschienen ist. Er gibt den redaktionellen Stand vom 4. April 2012 wieder.
Update: Für JBoss ist am 20. Juni 2012 die JBoss Enterprise Application Plattform 6.0 erschienen, für die Red Hat in Form von Subskriptionen offiziellen Support anbietet. Die Dauer des Support für diese Version beträgt voraussichtlich sieben Jahre.
Für Java EE 6 gilt der Satz: „Was lange währt, wird endlich gut.“ Die lange Wartezeit zwischen Veröffentlichung der Spezifikation und der Referenzimplementierung vor mehr als zwei Jahren haben die meisten Applikationsserver-Anbieter genutzt, um ihre Produkte auf die Anforderungen der Zukunft auszurichten und dazu komplett umzubauen.
Dieser Wechsel stellt nicht nur für die Hersteller, sondern auch für die Nutzer einige Herausforderungen bereit. Doch der Umstieg auf Java EE 6 lohnt sich. Alle drei hier vorgestellten Applikationsserver verwenden intern OSGi; damit wird nicht nur der Server schlanker, sondern es lassen sich auch flexiblere Anwendungen entwickeln. Ein weiterer gemeinsamer Punkt ist, dass die Administrierbarkeit und die Integration in bestehende System- und Entwicklungs-Umgebungen verbessert wurden. Gerade Betriebsthemen wie Überwachung, Skalierbarkeit und Automatisierbarkeit spielen hier eine große Rolle.
GlassFish: die Referenz-Implementierung
Bei GlassFish handelt es sich um die Java-EE-Referenz-Implementierung. Kein Wunder, dass er immer die aktuellsten Standards unterstützt. Die Zukunft von GlassFish war nach der Übernahme von Sun durch Oracle etwas ungewiss. Doch spätestens nach der Vorstellung von GlassFish 3.1.1 im Februar 2011 legte sich die Aufregung, da dieser endlich die lang ersehnte Cluster-Fähigkeit enthält. Genau ein Jahr später erschien die aktualisierte und fehlerbereinigte Version GlassFish 3.1.2. Neben der Open-Source-Variante bietet Oracle eine gleichnamige kommerzielle Variante mit Support an. Die Hoffnung, dass in GlassFish neben Java auch andere Java-Skriptsprachen ausgeführt werden, hat sich nicht erfüllt und wurde in den aktuellen Versionen nicht mehr unterstützt.
Für die kommende Java-EE-7-Version existiert bereits eine erste Implementierung mit GlassFish 4.0. Doch bevor Java EE 7 erscheint, wird es noch eine Version 3.2 geben. GlassFish 3.1 wird sicher für die nächsten Jahre die am meisten eingesetzte GlassFish-Version bleiben, da im Bundle mit NetBeans oder dem Java EE 6 SDK regelmäßige Aktualisierungen geliefert werden. Ebenso gibt es Erweiterungen wie das Oracle Enterprise Pack für Eclipse, Integrationen in die Fusion-Produktreihe oder Migrationsassistenten für WebLogic. Gerade die Open-Source-Variante ist bei vielen Oracle-Kunden beliebt.
JBoss: der Platzhirsch
JBoss ist der älteste Open-Source-Applikationsserver. Dadurch ist er am Markt weit verbreitet. Technologisch ist er in den letzten Jahren etwas ins Hintertreffen geraten. Das hat sich mit der Zwischenversion 6 und mit der gerade frisch zertifizierten Version 7.1 geändert. Neben einer modernisierten Administrationsoberfläche wurde vor allem unter der Haube mit OSGi einiges geändert. Neben Felix, Tomcat und Aries werden hier einige Apache-Komponenten verwendet. Dadurch, dass man die CDI-Referenz-Implementierung Weld an Apache übertrug und das eigene Web-Service-Framework zugunsten von Apache CXF aufgab, scheint es bei JBoss ein Umdenken hinsichtlich der Zusammenarbeit mit Apache zu geben.
Gerade mit den weiteren JBoss-Produkten wie Hibernate, SEAM, RichFaces, Jgroups, Infinispan, DROOLS, jBPM, HornetQ oder GateIn integriert sich der JBoss- Applikationsserver gut, wenn man die Versionsabhängigkeiten beachtet. Hier bietet JBoss mit seiner Mutter Red Hat einen bunten Strauß von Produkten an.
Die Administrierbarkeit und Überwachung von großen JBoss-Installationen ist mit RHQ möglich. Die Entwicklung wird sowohl durch Werkzeuge wie die Eclipse-JBoss-Tools oder Test-Frameworks als auch durch JSFUnit oder Arquillian gut unterstützt.
Die am meisten eingesetzte Version ist 5.1. Ein Versionswechsel auf 7.1 ist nicht ohne Probleme. Gerade da die EJB-Abwärtskompatibilität recht spät eingebaut wurde, ist hier mit Überraschungen zu rechnen. Eine Einschränkung der Open-Source-Varianten von JBoss bleibt, da die Entwicklung nicht wirklich öffentlich passiert und Anwender keine Fehlerkorrekturen für alte Produkte erhalten.
Etwas kurios mutet die große Lizenzsammlung mit 22 Lizenzen von GPL bis MIT an. Trotzdem zählt Red Hat zu den großen Open-Source-Namen, die sich im Java-Community-Prozess an der Weiterentwicklung von Java EE beteiligen. Fehlerkorrekturen werden immer nur über die aktuellste Community-Version angeboten oder der Kunde muss auf die erst später erscheinende stabile, aber kostenpflichtige Enterprise-Version wechseln. Wer jedoch mit dieser Unsicherheit leben kann, für den ist JBoss immer noch ein gutes Rundum-Angebot. Wobei hier der Schritt auf die nächste Applikationsserver-Version, durch die Architektur und Versionsaktualisierung der verwendeten Komponenten, nicht ohne Stolperfallen ist. Spätestens mit der für Mitte des Jahres geplanten Enterprise-Applikationsserver-Version 6, die wiederum auf der Community-Version 7.1 beruht, sollten die meisten aktuellen Probleme beseitigt sein.
Geronimo: der Nachzügler
Apache Geronimo ist vor allem als freie Herausforderung zu JBoss angetreten. Deswegen setzen viele Entwickler bewährte andere Open-Source-Komponenten ein. So hat es Geronimo seit der Version 1.0 und der Zertifizierung für J2EE 1.4 immerhin als zweiter Open-Source-Server nach GlassFish geschafft, jede JEE-Zertifizierung zu erfüllen. Die am meisten eingesetzte Version ist 2.1.8, wobei bei dieser Version seit der Vorstellung Anfang 2008 immer wieder Fehlerkorrekturen erschienen sind.
Für Geronimo besteht fünf Jahre offizieller Support und weitere drei Support-Jahre sind bei IBM buchbar. Damit bietet Geronimo – typisch Apache – von allen drei Produkten die längsten Support-Zeiträume bei regelmäßigen Weiterentwicklungen, was eine gute Planungssicherheit ergibt. Jedoch darf nicht verschwiegen werden, dass die Entwicklung und die Unterstützung der Community in den letzten Jahren etwas nachgelassen hat. Trotzdem bleibt Geronimo, gerade als Integrationsplattform für die vielen Apache-Java-EE-Projekte, wichtig.
Geronimo bietet gerade für Eclipse und Maven eine gute Integration an. Es gibt viele Möglichkeiten, das Deployment zu automatisieren oder den Server über eine komfortable Oberfläche zu konfigurieren oder zu überwachen.
Wer sich zutraut, selbst Hand anzulegen und sich trotz unvollständiger Dokumentation auf Open Source einzulassen, erhält mit Geronimo einen verlässlichen und innovativen Begleiter. Etwas Konkurrenz im eigenen Haus hat Geronimo durch den ebenfalls zertifizierten Tom-EE-Server und den demnächst geplanten Karaf-EE-Server bekommen. Für die hybride Entwicklung von OSGi und Java-EE-Anwendungen scheint Geronimo eine gute Wahl zu sein, da die Beispiele von Karaf und Aries vom gleichen Hersteller ohne zusätzliche Anpassungen in Geronimo lauffähig sind. Durch die stagnierenden Committer-Zahlen und den Ausstieg von Apache aus dem Java-Community-Prozess sind die Apache-Projekte zwar nicht gefährdet, doch die Weiterentwicklung etwas gebremst. Umso erfreulicher ist, dass große Unterstützer des JCP wie IBM und JBoss sich immer mehr bei Apache-Projekten engagieren und so die Open-Source-Fahne weiter wehen lassen.
Die Unterschiede zwischen den Produkten werden immer geringer. Trotzdem kann die folgende Übersicht bei der ersten Orientierung helfen. Interessant ist auch der Vergleich der Entwicklung der Codegröße der jeweiligen Produkte: Während JBoss bald die 1.286.700 Codelines erreicht hat, liegt GlassFish bei 986.700. Geronimo liegt deutlich dahinter mit "nur" 523.800 Lines. Die Tendenz ist klar: Die Produkte, ähnlich wie der Java-Standard, werden immer größer. Durch die neue Modularität sind die neuen Applikationsserver immer anpassbarer geworden, was sich nicht zuletzt auf das schnelle Startverhalten und den geringen Ressourcen-Verbrauch auswirkt.
Einfach durchstarten
Die Installation erfolgt bei JBoss und Geronimo durch das Installationsformat zip/tar einfach durch Auspacken. Dannach muss nur noch ein aktuelles JDK und die „JAVE_HOME“-Variable gesetzt sein. Bei GlassFish oder bei der auf Geronimo basierenden WebSphere Community Edition geht es etwas komfortabler. Es gibt einen grafischen Wizard für die unterstützten Plattformen, der einem hilft, die Java-Umgebungsvariablen zu setzen und die ersten Einstellungen vorzunehmen. Nach dem Start des Servers muss man nur noch die entsprechende Admin-Konsole mit dem in der Dokumentation beschriebenen Admin-Anmeldung im Browser aufrufen. Für die initiale Verwendung ist erst mal nichts umzukonfigurieren. Viele, aber nicht alle Konfigurationsmöglichkeiten sind über diese Oberfläche möglich.
Der erste Kontakt mit den neuen JavaEE-Servern klappt für Neueinsteiger problemlos, wer jedoch tiefer einsteigen möchte, ist auf eine gute Dokumentation und Erfahrung angewiesen. Gerade was die Bereiche „Hochskalierbarkeit“ oder „Migration“ betrifft, muss sich beim Umstieg etwas einarbeiten.
| GlassFish | JBoss | Geronimo |
Lizenz | CDDL1.1, GPL 2 | LGPL 2.1 | ASF |
Beurteilung | + sehr gute Dokumentation, viele Beispiele + Cluster Support + Migrations-, Upgrade-Unterstützung + gute IDE-, BUILD-Integration + gute Administrier-, Automatisierbarkeit (GUI, CLI) + Supportmöglichkeit + aktuelle Referenzimplementierung + regelmäßige Releases auch ältere mit klarer Roadmap + mittlere Produktgröße 83 MB | + gute Dokumentation + verbesserte Administrierbarkeit + gute Integration in JBoss, Red-Hat-Produkte + gute Cloud-Integration + gute Testbarkeit Arquillian + gute IDE-, BUILD-Integration - Webcontainer: Tomcat - seltenere und unregelmäßige Releases nur für aktuellste Version - große Community, jedoch mit wenig Mitwirkungsmöglichkeiten bei der Produktweiterentwicklung - relative neue Architektur - eingeschränkte Abwärtskompatibilität - Langzeitsupport nur für kommerzielle Variante - größtes Produkt 103 MB | + stabiles, schlankes und gut anpassbares Produkt mit ausgereiften Best-of-Breed-Komponenten + gute IDE-, BUILD-Integration + Langzeitsupport + gute Mitwirkungsmöglichkeit, jedoch kleine Community + regelmäßige Releases auch ältere + hybride Version für OSGi, Jetty/Tomcat, CXF, Axis2 - wenig Dokumentation, Beispiele + kleinstes Produkt mit 74-91MB + sehr freie ASF-Lizenz |
Plattformen | LINUX, Windows, SOLARIS, AIX | LINUX und Windows | LINUX, Windows, SOLARIS, AIX |
Webcontainer | Grizzly | Tomcat | Jetty, Tomcat |
OSGi | Felix | Felix, Karaf | Equinox, Felix, Karaf, Aries |
JSF | Mojarra | Mojarra, Richfaces, SEAM | myFaces,OpenWebBeans |
CDI | Weld | Weld | OpenWebBeans |
JAX-WS, JAX-RS | Metro, Jersey | CXF, RESTEasy | CXF, Axis2, WINK |
JPA | EclipseLink, Hibernate Validator | Hibernate, Hibernate Validator | OpenJPA, BVal |
Tabelle 1: Übersicht und Bewertung
Fazit
Durch die Übernahme von Sun durch Oracle hat Java wieder eine Zukunft. Der aktuelle und der kommende Java-EE-Standard haben zu einer Renaissance der Applikationsserver geführt. Trotzdem weisen die Applikationsserver mit OSGi den Weg zu mehr Modularität. Dadurch, dass der Java-Markt gesättigt ist, wird es hier wenig Bewegung geben. Für viele Projekte steht der Schritt in die Java-EE-6-Zukunft noch bevor.
Ungeachtet vieler Unterschiede bei Lizenz, Support, Architektur und den verwendeten Komponenten, haben die hier vorgestellten Produkte durch den Java-EE-Standard viele Gemeinsamkeiten. Kurz zusammengefasst kann man sagen, dass GlassFish sich etabliert hat und für die Java-EE-Funktionen am weitesten ausgereift ist. JBoss und Geronimo bieten erst seit Kurzem eine volle Java-EE-6-Unterstützung, sodass hier noch einige Fehler schlummern, die im Laufe dieses Jahres behoben sein werden. Als Open-Source-Applikationsserver bieten alle drei Kandidaten interessante und innovative Alternativen zu kommerziellen Anbietern oder reinen Webservern an, die einen Wechsel attraktiv machen. Erste Ansätze, wie der Weg der Applikationsserver in die Cloud aussehen könnte, sind zwar sichtbar, doch noch nicht, wer hier das Rennen machen könnte.
