Freie App-Server im Vergleich

Tomcat vs. Geronimo vs. JBoss vs. GlassFish

10.09.2008 von Markus Franz
Application-Server sind das Herzstück professioneller Geschäftsanwendungen. Hier werden die Open-Source-Lösungen Tomcat, Geronimo, JBoss und GlassFish verglichen.

In den vergangenen Jahren haben sich Java und die Java Enterprise Edition (Java EE) als Standard massenhaft durchgesetzt. Die große Verbreitung von Java EE hat auch einige erfolgreiche Open-Source-Projekte hervorgebracht: JBoss von RedHat, GlassFish von Sun Microsystems und BEA WebLogic sind die bekanntesten Application-Server. Die Apache Foundation ist mit Tomcat und Geronimo gleich mit zwei Angeboten dabei, die als Basis für viele Produkte von Drittherstellern dienen. Im proprietären Lager haben IBM mit WebSphere und der Oracle Application Server eine bedeutende Rolle. SAP ist nur bei großen Unternehmen oder für Speziallösungen eine wichtige Plattform. Grundsätzlich gilt jedoch für Application-Server, dass sie eine direkte Schicht über der eigentlichen Laufzeitumgebung der Programmiersprache bilden, auf der dann betriebsspezifische Software aufsetzt.

Geschichte kurz gefasst

Obwohl sich die Java Standard Edition (Java SE) auf dem Desktop nicht durchsetzen konnte, ist Java EE auf dem Server ein großer Erfolg geworden. Sun hat aber erst vor knapp zwei Jahren damit begonnen, Java vollständig als Open Source freizugeben - bis dahin war die Laufzeitumgebung und der Sun-eigene Java Application Server eine rein proprietäre Lösung.

Nachdem die Open-Source-Projekte und JBoss sowie die Apache Foundation Sun dazu gedrängt haben, Java unter dem Projektnamen OpenJDK zu öffnen, hat der Hersteller seinen Application-Server in das Projekt GlassFish überführt. Um Kunden, die vor allem auf Lizenzkosten achten müssen, nicht an die jeweilige Community zu verlieren, bieten inzwischen auch IBM und Oracle die Einstiegsvarianten ihrer Application-Server kostenfrei an - allerdings ohne Zugang zum Quelltext.

Im Moment sieht es so aus, als würde das Geschäft um die Application-Server weniger von der Software, als vielmehr vom Support- und Wartungsgeschäft getragen. Da die Java Virtual Machine (JVM) nun komplett unter einer freien Lizenz verfügbar ist, dürften spezifische JVM-Implementierungen wie BEA JRockit oder Apache Harmony langsam verschwinden und Java SE wieder als Runtime-Plattform für Java-EE-Server dienen.

Aufbau der Application Server

Im Java Community Process arbeiten Sun, RedHat, Oracle und viele andere Unternehmen an gemeinsamen Standards für die Java-Welt. Im Laufe der Jahre haben sich dabei sechs Java-EE-Spezifikationen herausgebildet - die letzte, Java EE 5, wurde im Mai 2006 veröffentlicht. Der Nachfolger Java EE 6 hatte einige Anlaufschwierigkeiten, wird nun aber wohl irgendwann in den nächsten zwei Jahren erscheinen. Java EE 5 definiert als Laufzeitumgebung eine gemeinsame Infrastruktur für alle Application-Server. Folgende Komponenten der Java-EE-Architektur haben sich dabei als besonders wichtig herauskristallisiert:

Der Web-Container

Jeder Application-Server muss einen Web-Container enthalten, in dem Java-Servlets oder JSP-Sites veröffentlicht werden können. Dieser Container muss besonders schnell und stabil sein, da er oft die einzige Schnittstelle einer Java-EE-Anwendung zur Außenwelt darstellt. Gleichzeitig sollte sich eine Web-Anwendung, die im Web-Container ausgeführt wird, in einem Cluster ebenso wohl fühlen und problemlos Threads für viele Anfragen verarbeiten. Neben reinen Servlets oder JSPs kommen auch Java Server Faces (JSF) zum Einsatz: Damit lassen sich, ähnlich wie mit den Swing-GUI-Elementen in Java SE, Web-Oberflächen aus Bausteinen zusammenklicken.

Umgang mit Javabeans

Die zweite wichtige Komponente neben dem Web-Container, an der sich jeder Application-Server messen lassen muss, sind die Enterprise Javabeans (EJB). Sie bilden die Geschäftslogik eines Unternehmens ab und sind quasi zentrale Bausteine, die zwischen Interface und Datenbank vermitteln. Ein guter Application-Server sollte für Javabeans die Möglichkeit bieten, diese direkt auf eine Datenbank zu mappen, ohne umfangreiches SQL schreiben zu müssen. So entsteht das Gefühl, mit einer Objektdatenbank zu arbeiten, obwohl im Hintergrund ein relationaler Datenbank-Server läuft. Auch die Java Persistence API definiert ein zentrales Gedächtnis für Java-Objekte, die in Datenbanken abgelegt werden.

Neben diesen beiden zentralen Komponenten gibt es eine ganze Reihe weiterer Standards, die mehr oder weniger gut für die diversen Java-EE-Projekte passen. Sinnvoll sind jedenfalls Web-Services - Java EE definiert hier einen Standard, über den Schnittstellen zu EJBs im Application-Server laufen können. Die JAX-Standards definieren, wie eine Java-EE-Umgebung mit XML-Dokumenten und XML-Diensten umgehen soll. Das Java Naming and Directory Interface (JNDI) arbeitet als zentraler Dienst im Application-Server, der anderen EE-Komponenten einen zentralen Namens- und Verzeichnisdienst anbietet. Im geschäftlichen Umfeld sind zu guter Letzt die Standards Java Mail und JMS (Java Message Service) noch wichtig.

Die Wartung

Von zentraler Bedeutung für Application-Server ist auch die Frage nach der Wartung: Jeder Server sollte nicht nur über Java Management Extensions (JMX) verfügen, über die EE-Anwendungen und Komponenten verwaltet werden. Ferner muss ein Application-Server ein gutes Web-Interface enthalten, mit dessen Hilfe sich die gesamte Laufzeitumgebung und alle Container pflegen lassen. Hilfreich für Programmierer sind Plug-ins, die (Web-)Anwendungen direkt aus der Entwicklungsumgebung in einen Container auf dem Server schieben - Application Deployment genannt.

Die Mutter aller Container: Apache Tomcat

Die Apache Software Foundation arbeitet seit vielen Jahren intensiv im Java-Umfeld mit. Noch bevor Java als Open Source freigegeben war, hatte Sun mit einer Referenzimplementierung für Java-Servlet und Java-JSP begonnen. Das Projekt wurde dann ab Version 3 komplett von der Apache Foundation übernommen und wird heute von vielen Mitgliedern aktiv weiterentwickelt. Tomcat ist heute der beliebteste Servlet-Container und wird von vielen anderen Application-Servern ebenfalls als Ausgangsbasis genutzt.

Derzeit gibt es Apache Tomcat in Version 6.0. Sie arbeitet mit den aktuellen Standards JSP 2.1 sowie Servlet 2.5 und wird für produktive Umgebungen empfohlen. Der Download des Tomcat-Containers ist mit 6,3 MB angenehm klein, knapp 1 MB kommt für den Tomcat-Deployer hinzu. Tomcat wird einfach in einem beliebigen Verzeichnis entpackt und benötigt nur ein Java Development Kit (JDK) gemäß Java SE 5 oder höher. Unter Unix/Linux muss unbedingt die Umgebungsvariable JAVA_HOME auf das JDK gesetzt werden, damit Tomcat die Java-Installation auch findet. Die Variable CATALINA_HOME muss auf das Verzeichnis, in dem Tomcat entpackt wurde, zeigen. Wer nicht Unix-Derivate, sonder lieber Windows (Server) einsetzt, erhält einen komfortablen Installer: Dieser nimmt alle notwendigen Änderungen am System vor und kann Apache Tomcat auch als Dienst in Windows einbinden.

Um eine Web-Anwendung im Container auszuführen, legt man einfach den WAR-File in das Verzeichnis "webapps" - Tomcat erkennt selbstständig eine neue oder überarbeitete Anwendung und spielt diese in den Container. Alternativ bieten der Tomcat-Deployer beziehungsweise das Web-Interface eine komfortable Möglichkeit, eine WAR-Applikation einfach hochzuladen. Alle anderen administrativen Aufgaben erledigt man in den XML-Konfigurationsdateien, mit denen Tomcat arbeitet. Damit ist Tomcat einerseits genial einfach, wenn man lediglich reine Servlets oder JSPs veröffentlichen möchte, andererseits bietet es auch nur diese Features und nichts weiter.

Das Deployment direkt aus der Entwicklungsumgebung ist kompliziert und nur mit Plug-ins lösbar, die vor allem in NetBeans gut funktionieren. Die Integration in Eclipse ist noch verbesserungsbedürftig. Da die IDE-Plug-ins nicht direkt von der Apache Foundation entwickelt werden, hinken sie bei der Unterstützung aktueller Tomcat-Versionen immer etwas hinterher. Tomcat kann durch zusätzliche Bibliotheken so erweitert werden, dass Java Server Faces möglich sind. Klarer Sieger ist Tomcat als Web-Container bei der Performance - auch wenn man auf richtiges Java EE verzichten muss.

Apache Geronimo als AppServer

Die Apache Foundation hat neben Tomcat natürlich auch einen ausgewachsenen Application-Server im Programm: Apache Geronimo 2.1.1, der im April 2008 freigegeben wurde. Das Projekt wird aktiv von IBM unterstützt, dessen WebSphere-Application-Server in der Community Edition auf Apache Geronimo basiert. Andere Application-Server sind als monolithische Software konzipiert, nicht so Geronimo: Alles dreht sich um einen Kernel, der die Grundlage für die GBean-Komponenten bietet. An diese modulare Architektur können leicht andere Projekte der Apache Foundation andocken und so einen kompletten Java-EE-AppServer formen.

Über das Web-Interface von Geronimo erfolgt die komplette Wartung.

Neben Tomcat als Web-Container hat man die Wahl, auch den freien Container Jetty zu installieren. Als EJB-Container dient immer OpenEJB. Apache Geronimo bietet einige besonders leistungsfähige Merkmale: Die ausgereiften Bibliotheken Apache Axis und verwandte Libraries sind der Grundstein für Web-Services in diesem Application Server. Mit Apache Derby beinhaltet Geronimo direkt eine eigene SQL-Datenbank, die für einfache Aufgaben durchaus eine gute Alternative zu einem eigenen Datenbank-Server bildet.

Nach dem Download der knapp 70 MB genügt zum Start der Befehl "geronimo run". Die Web Administration Console verwaltet alle Dienste und kann neue Web-Anwendungen oder EJB-Projekte verteilen. Gleichzeitig gibt es direkt von der Geronimo-Community ein Eclipse-Plug-in, das ständig verfeinert wird und im Test sehr gut funktionierte. Damit ist Geronimo klarer Sieger beim Zusammenspiel mit den IDEs auf dem Desktop. Apache Geronimo wurde über Sun gemäß Java EE 5 zertifiziert und ist somit auf dem neuesten Stand.

JBoss AS und Middleware

Der unangefochtene Big Player unter den Application-Servern in der Open-Source-Gemeinde ist JBoss. Das gleichnamige Unternehmen, das neben dem Application-Server eine ganze Middleware-Infrastruktur anbietet, gehört seit einiger Zeit zu RedHat. Somit sind Spezialisten für Linux-Distributionen und Middleware-Produkte unter einem Dach verfügbar - für mittlere und große Unternehmen ein wichtiges Argument. Die aktuelle Ausgabe 4.2 ist noch nicht vollständig nach Java EE 5 zertifiziert - hier hinkt JBoss unnötig dem neuesten Standard hinterher, obwohl bereits große Teile der EJB-Infrastruktur aktuell implementiert sind. JBoss AS 5.0, das vollständig Java EE 5 unterstützen wird, liegt derzeit als Release Candidate vor und wird irgendwann im Herbst erscheinen.

JBoss AS benötigt ähnlich wie Tomcat ein JDK 5 - mit älteren Ausgaben funktionieren einige Module nicht. Nachdem man das knapp 95 MB große Paket heruntergeladen hat, liegt der beste Application-Server der Open-Source-Community vor einem: Das Web-Interface zur Wartung und Administration ist nur bei Sun ähnlich gut gelungen. Gleichzeitig bietet JBoss nicht nur den reinen Application-Server mit seinen Containern, sondern mit Hibernate auch den besten Objekt-Mapper für Datenbanken. Das Projekt JBoss Seam integriert verschiedene Java-Standards zu einem einheitlichen Framework, was die Entwicklung von Web-2.0-Diensten schneller und einfacher macht. Für Unternehmen interessant dürfte auch sein, dass man mit JBoss jBPM komplexe Geschäftsprozesse auf eine Java-Umgebung abbilden kann.

Neben den attraktiven Support-Angeboten für JBoss, die von RedHat als jährliche Subscription-Pakete angeboten werden, ist JBoss Developer Studio die ideale IDE für den Desktop, sofern auf dem Server das Gegenstück läuft. Als Basis dient Eclipse, das Deployment der Web-Anwendungen ist konkurrenzlos stabil. Im Test war JBoss AS zwar ebenfalls stabil, aber nicht unbedingt einer der schnellsten Server: Der Application-Server genehmigt sich mehr Ressourcen als Geronimo oder GlassFish.

Sun mit GlassFish und Java System

Das Web-Interface von GlasFish bietet eine übersichtliche Aufgabenansicht.

Der schärfste Konkurrent von JBoss ist GlassFish beziehungsweise der Sun Java System Application Server. Immer noch ist Sun mit diesem Produkt der klare Markführer, nirgendwo sind die Standards so exakt und effizient implementiert. GlassFish zählt neben NetBeans und OpenJDK zu den Open-Source-Produkten, die Sun vormals als proprietäre Lösungen angeboten hatte. Hinzu gesellt sich seit einiger Zeit mit MySQL noch ein Datenbank-Server, sodass ein kompletter Application-Stack entsteht. GlassFish nutzt eine überarbeitete Fassung von Tomcat als Web-Container, die konsequent auf Geschwindigkeit optimiert wurde. GlassFish v2 UR2 gibt es daher in separaten Paketen für Solaris (Sparc und x86), Linux, Windows, MacOS und AIX - für jedes Betriebssystem steht ein eigener Installer bereit, der auf ein korrekt installiertes JDK prüft und alles für GlassFish einrichtet.

Mit knapp 50 MB ist die Linux-Ausgabe der schlankste vollwertige Application-Server mit komplettem Support für Java EE 5. Das Web-Interface ist sehr gut und reagiert am schnellsten - wenn es auch manchmal einen unnötigen Neustart des Application-Server durch hängende Prozesse im Web-Interface verursacht. Ähnlich Geronimo integriert der Application-Server selbst eine Datenbank-Lösung, die JavaDB. Diese ist aber kein komplett eigenständiges Produkt, sondern nur ein Derivat von Apache Derby. Interessant ist an GlassFish beziehungsweise dem Sun-Pendant auch das TopLink-Framework, mit dem die Persistenz von Objekten auf Datenbanken und in (XML-)Dateien erreicht wird. Es wurde von Oracle zum Projekt beigesteuert und wird aktiv weiterentwickelt.

Seitenblick auf LAMP und Zope

Die Geschäftswelt liebt Java, aber in bestimmten Arbeitsbereichen erfreuen sich auch Skriptsprachen wie PHP, Python, Ruby oder Grails großer Beliebtheit. Mit dem LAMP-Stack gibt es seit Jahren eine professionelle Umgebung, die meist aus Linux, dem Apache Web-Server (nicht zu verwechseln mit Apache Tomcat), der Datenbank MySQL und Zend PHP als Programmiersprache ausgestattet ist. Attraktiv ist diese Plattform für Einsteiger oder Anwender, die lediglich eine Website anbieten wollen und dabei auf Clustering, Datenbank-Mapping und Transaktionen verzichten können. Ebenso fehlt dieser Umgebung ein einheitliches Interface zur Web-gestützten Wartung. Deployment direkt aus der Entwicklungsumgebung heraus und Web-Services sind nur mit großem Aufwand möglich. Verbreitung hat der LAMP-Stack aber dennoch auch bei großen Unternehmen und Shopping-Portalen gefunden.

Die wachsende Verbreitung der objektorientierten Programmiersprache Python hat den Zope Application Server hervorgebracht. Zope besteht im Gegensatz zu LAMP nicht aus mehreren, komplett getrennten Applikationen, sondern aus einer einzigen Anwendung. An diese docken Komponenten und Plug-ins für den jeweiligen Bedarf an. Beliebt ist Zope vor allem für Web-Anwendungen, da es von Grund auf mit dem Ziel guter Skalierbarkeit aufgebaut wurde - der gesamte Application-Server verarbeitet problemlos Threads auch in seinen Erweiterungen. Reizvoll ist aber besonders das Schmuckstück von Zope: Eine integrierte Objektdatenbank, die ZODB. Wer sich hier einmal eingearbeitet hat, verzichtet gerne auf eine relationale Datenbank.

Fazit