Von: Prof. Dr. Alexander Schill, Olaf Neumann, K. Buck
In einer breit angelegten Studie untersuchte die TU Dresden vier Applikationsserver von BEA Systems, Inprise (seit kurzem wieder Borland), IBM und Iona, die auf "Java 2 Enterprise Edition" (J2EE) und "Enterprise Java Beans" (EJB) basieren. Die Produkte mussten zum einen anhand eines komplexen Versicherungsbeispiels ihre Performance unter Beweis stellen. Zum anderen wurde ihre praktische Handhabung einer kritischen Prüfung unterzogen.
Der Applikationsserver von BEA erwies sich in den Tests als das leistungsfähigste Produkt. Knapp dahinter folgte Inprise, mit größerem Abstand IBM. Der Server von Iona nahm an den Performance-Messungen nicht teil, da bislang kein Treiber für die im Test eingesetzte Datenbank "IBM DB2" verfügbar ist (siehe unten). Als Vergleichskriterien dienten nicht nur rein technische Aspekte - diese können in den Datenblättern der Hersteller nachgeschlagen werden. Vielmehr stand die Handhabung und das Verhalten der Server im Praxiseinsatz im Vordergrund. Neben der Installation und Konfiguration der Software wurde auch die Qualität der mitgelieferten Dokumentation bewertet. Ein besonderes Augenmerk galt der Cluster-Fähigkeit, den Load-Balancing- und Failover-Mechanismen sowie dem Deployment der Serverkomponenten.
Weblogic 5.1.0
Der Applikationsserver "Weblogic 5.1.0 (Service-Pack 5)" von BEA Systems lässt sich relativ einfach installieren und konfigurieren. Die Dokumentation leistet dabei eine gute Hilfestellung. Unter Windows NT steht eine Installationsroutine zur Verfügung. Mit anderen Betriebssystemen kann das Setup auch von Hand erfolgen. Die Anleitung hierfür ist ausschließlich auf den Web-Seiten von BEA Systems zu finden. Das Aufspielen des unbedingt erforderlichen Service-Packs ist dagegen nur unzureichend dokumentiert.
Nach der Installation editiert der Administrator die Datei weblogic.properties für die Grundkonfiguration. Die hier hinterlegten Einstellungen sind in der grafischen Konsole des Servers einsehbar. Außerdem definiert diese Datei auch Benutzer und Rollen für einfache Konfigurationen. Die Authentisierung mit beliebigen Systemen erlaubt ein so genanntes "Realm"-Interface. Hinter Realm verbirgt sich eine Java-Klasse, die den Zugriff auf User, Gruppen, Access Control Lists (ACL) und zugehörige Services ermöglicht.
Weblogic setzt alle Standards der J2EE-Spezifikation um. Als einziger Testkandidat bietet der Server schon Funktionen der EJB-Version 2.0 an. Dazu gehören unter anderem der Support für Beans, die durch Messages ausgelöst werden, und XML-Funktionen. In der Behandlung nicht standardkonformer Implementierungen zeigt sich das BEA-Produkt sehr tolerant. Das Clustering von EJBs auf dem Weblogic-Server erfolgt automatisch über "Replica aware Stubs" und ist einfach zu konfigurieren. Diese "Stubs" sind mit einem Software-Router vergleichbar, der die Aufrufe entgegennimmt und an den Cluster weitergibt. Auf den Servern müssen dieselben Beans unter demselben "Java Naming and Directory Interface"-Namen (JNDI) installiert sein. Beim Deployment der Komponenten ist darauf zu achten, dass die Cluster-Fähigkeit der Beans aktiviert wird.
Für das Load-Balancing stehen die Verfahren "Round Robin" (Standard), "Weight Based Round Robin", "Random Based" sowie "Parameter Based" zur Verfügung. Das Deployment kann mit Hilfe eines grafischen Werkzeugs oder über die Kommandozeile erfolgen. Ersteres bietet eine einfache Möglichkeit, die Descriptoren zu erstellen. Allerdings kam es im Test zu gelegentlichen Abstürzen des Tools. Für Routinearbeiten ist das Deployment über die Kommandozeile eine gute Hilfe. Um die Beans beim nächsten Serverstart automatisch zu installieren, muss die Datei weblogic.properties angepasst werden. Es ist zwar prinzipiell möglich, ein Hot-Deployment per Konsole vorzunehmen oder bereits vorhandene Beans zur Laufzeit neu einzurichten. Diese Änderungen gehen jedoch bei einem Neustart des Servers wieder verloren.
Der Weblogic-Server zeichnete sich in den Tests durch sehr gute Performance und hohe Stabilität aus. Diese lässt sich durch Clustering und Failover noch erhöhen. Der Ressourcenbedarf ist mit zirka 70 MByte Hauptspeicher relativ gering. Das Produkt ist vollständig in Java implementiert. Für einige Betriebssysteme sind Performance-Packs in Form von Maschinencode erhältlich. Zusatztools erlauben unter anderem das Caching und die Anbindung objektorientierter Datenbanken. BEA selber bietet die Entwicklungsumgebung "Webgain" (ehemals Visual Cafe) an.
Inprise Application Server 4.1
Die Installation des "Inprise Application Server 4.1" verlief ebenfalls problemlos. Nachdem sich Inprise wieder in Borland zurückbenannt hat, wird die Lösung nun als "Borland Appserver 4.5" vermarktet. Die Online-Dokumentation bietet Hilfe für Standardinstallations- und Konfigurationsschritte, weiterführende Informationen sind jedoch kaum enthalten. Hierfür ist die Newsgroup zu dem Produkt eine gute Adresse.
Nach der Installation kann der Administrator alle Einstellungen über die Konsole vornehmen. Eine Bearbeitung der Konfigurationsdateien erwies sich nicht als zwingend notwendig. Nur bei der Einbindung von Datenbanktreibern ist neben dem Einspielen der Files auch die Änderung von Konfigurationsdateien erforderlich. Borland unterstützt den J2EE-Standard vollständig, verlangt allerdings eine standardkonforme Implementierung der Beans. Der Applikationsserver basiert auf Corba (Common Object Request Broker Architecture) und der "Visibroker"-Technik von Inprise. Sicherheitsanforderungen lassen sich wie bei Weblogic mit einem "Realm"-Interface flexibel umsetzen. Zusätzlich ist es möglich, eine externe Benutzerverwaltung mittels der Corba-Schnittstelle anzubinden.
Das Clustering erfolgt auch bei Inprise über den JNDI-Dienst. Dabei wird nur eine Instanz des Namensservices im zu errichtenden Cluster gestartet. Diese verteilt dann die Client-Anfragen nach der "Round Robin"-Methode auf die beteiligten Serverinstanzen. Voraussetzung ist, dass die Beans auf den einzelnen Servern unter demselben JNDI-Namen ansprechbar sind und die Eigenschaft vbroker.naming.propBindOn auf 1 gesetzt wurde. Inprise unterstützt das Clustering von "Stateless Session Beans" und nach eigenen Angaben mit Hilfe eines zusätzlichen Sessionservices auch das Clustering von "Stateful Session Beans".
Für das Deployment kommt die grafische Konsole zum Einsatz. Dabei kann der Verwalter entscheiden, ob die Einhaltung des J2EE-Standards streng oder weniger streng überprüft wird. Anschließend ist ein Client-Java-Archiv erstellbar, in dem die benötigten Stubs enthalten sind. Wurde ein Bean eingerichtet, ist es auch nach dem Neustart des Servers vorhanden. Um es wieder zu entfernen, muss es explizit gelöscht werden.
Der Hauptspeicherverbrauch des Inprise-Servers liegt mit allen Beans und Diensten bei 133 MByte. Durch ein vermutetes Memory-Leak - das Programm versucht, über den zugewiesenen Speicherplatz hinaus den kompletten Hauptspeicher zu nutzen - steigt der Verbrauch im Betrieb stark an und kann zu OutOfMemory-Fehlermeldungen führen. Im Testbetrieb brach der Inprise Application Server 4.1.0 nach einer Weile mit dieser Meldung ab. Die Recherche in Newsgroups ergab, dass es sich um ein bekanntes Memory-Leak handelt. Bei weiteren Testeinsätzen mit der neuen Version 4.1.1 trat dieser Fehler nicht mehr auf, Newsgroups berichten allerdings immer noch davon.
Die von Inprise angebotene Entwicklungsumgebung "J-Builder Enterprise" erlaubt das direkte Deployment sowohl in den eigenen Applikationsserver als auch in das Weblogic-Produkt. Sie bietet zahlreiche Wizards zum Erstellen von Servlets, Java Server Pages (JSP), Beans, Testanwendungen sowie für die Datenbankanbindung.
IBM Websphere 3.5
Die Serverinstallation des "IBM Websphere 3.5" ließ sich ohne Probleme durchführen. Beim Einspielen des Patches "Fixpack 1"traten dagegen einige Schwierigkeiten auf. Dieser Vorgang wird über Scripts gesteuert und birgt einige Fehlerquellen, deren Ursachen nur ungenügend dokumentiert sind. So war zum Beispiel auf den verwendeten Windows-NT-Servern Deutsch als Standardsprache eingestellt. Das führte dazu, dass das Script den vorhandenen freien Festplattenspeicher falsch berechnete und die Bearbeitung abbrach. Ein weiterer Fehler: Das zur Installation des Fixpacks verwendete Java Development Kit (JDK) wollte sich selbst aktualisieren, was zu "Sharing Violations" (überlappende Dateizugriffe) führte. Die Dokumentation des Websphere-Servers ist unzureichend. Für Konfigurationsschritte, die über das standardmäßige Installieren und Konfigurieren hinausgehen, sind kaum Informationen verfügbar. Eine gute Hilfe bietet dagegen die Websphere-Newsgroup.
Zur Speicherung von Konfigurationsdaten und Laufzeitinformationen verwendet Websphere eine administrative Datenbank. Standardmäßig wird hierfür "IBM DB2" mitgeliefert. Damit ergaben sich jedoch gravierende Performance-Probleme. Besserung brachte der Umstieg auf Oracle. Mit "DB-Upgrade" ist ein Werkzeug für diesen Wechsel auf der IBM-Website zum Download verfügbar. Vor der Umstellung muss der Inhalt der Datenbank mit dem beiliegenden Tool "XML-Config" oder über die Konsole als XML-Datei gesichert werden. Die mitgelieferte Dokumentation ist an dieser Stelle nicht nur lückenhaft, sondern falsch. Dort heißt es, man solle vor dem Export der Konfiguration den administrativen Server stoppen. Richtig wäre es, den Server zu starten, da sonst kein Export vorgenommen werden kann.
Die Konsole erlaubt eine umfassende Konfiguration des Servers sowie das Deployment der Anwendungskomponenten. Hier lassen sich Serverinstanzen individuell oder als Cluster einrichten und Sicherheitseinstellungen festlegen. Die Security-Policies können Betriebssystemfunktionen, LDAP (Lightweight Directory Access Protocol) oder proprietäre Ansätze nutzen. Nimmt der Administrator Änderungen vor, stehen diese nach einem Neustart des Servers automatisch zur Verfügung. Eine Anpassung von Konfigurationsdateien ist nicht nötig. In Cluster-Konstellationen müssen alle beteiligten Server dieselbe administrative Datenbank benutzen. Ein einmal konfigurierter Applikationsserver kann sich über Clones vervielfältigen. Diese lassen sich dann sowohl auf derselben als auch auf anderen Maschinen installieren. Load-Balancing und Failover sind über so genannte Smart-Stubs möglich, die auf den Clients laufen. Zur Anfrageverteilung stehen die Methoden "Round Robin" und "Random" zur Verfügung. IBM unterstützt derzeit das Clustering von "Stateless Session Beans" und Servlets beziehungsweise JSPs.
Die "IBM Websphere Advanced Edition" unterstützt die J2EE-Spezifikation nicht vollständig. Dies wird vor allem beim EJB-1.1-Standard deutlich. Für den Testbetrieb waren dennoch keine Kodeanpassungen notwendig, da weder Collections noch sicherheitsspezifische Operationen von Java 2 verwendet wurden. Ein Message-Dienst steht nur in der Enterprise-Version zur Verfügung.
Das Deployment gestaltet sich bei Websphere sehr träge, sowohl bei der Vorbereitung als auch beim Einrichtungsprozess. Es ist möglich, mehrere Beans gleichzeitig in einem JAR-Archiv einzustellen. Dies hat im Test jedoch nicht funktioniert, wir mussten jede Bean einzeln einbauen. Websphere arbeitet bei der Montage noch mit den Deployment-Descriptoren der EJB-Version 1.0. Dieses Vorgehen beeinträchtigt ein Hauptziel des J2EE-Standards, die Wiederverwendung der Komponenten, in starkem Maße, da der Administrator die Descriptoren neu erzeugen muss. Diese Aufgabe erledigt das interne Deployment-Tool, das allerdings instabil arbeitet und nicht nachvollziehbare Fehlermeldungen hervorbringt. Zudem erfordert das Ändern der Konfiguration ständig den Neustart des Containers respektive der Web-Engine.
Websphere hat unter den Testkandidaten den höchsten Ressourcenbedarf. Allein die administrative Datenbank verbraucht zirka 50 MByte Hauptspeicher. Die zum Betrieb notwendige Konsole nimmt rund 113 MByte in Anspruch, eine Instanz des Applikationsservers benötigt weitere 34 MByte. Hinzu kommt der Web-Server mit nochmals 10 MByte - macht summa summarum 207 MByte. Als Entwicklungsumgebung bietet IBM "Visual Age" an. Damit ist es möglich, Komponenten direkt in Websphere zu installieren. In der Enterprise Edition stehen weitere Tools zur Verfügung, die allerdings nicht Gegenstand der Tests waren.
I-Portal Application Server
Die Basisinstallation des "I-Portal Application Server" von Iona ist unter Windows NT recht einfach durchzuführen. Danach traten aber erste Probleme auf. So mussten wir die mitgelieferte Datei orb.properties per Hand in das entsprechende JDK-Verzeichnis kopieren. Die Setup-Routine fragt die hier hinterlegte Konfiguration des Servers während der Installation ab und liefert einen lauffähigen Server. Die Konsole dient lediglich zum Erstellen der EJB- oder Web-Anwendungen. Eine Anpassung der Serverkonfiguration sowie das eigentliche Deployment ist damit nicht möglich.
Im praktischen Betrieb traten einige Fehler auf. Bei den Testtransaktionen überschrieben gelegentlich neu hinzugefügte Entity-Beans die Primary-Keys bereits vorhandener Beans. Weist man einzelnen Methoden spezielle Transaktionsattribute zu, kommt es zu merkwürdigen Verhaltensweisen: Existieren in einem Bean zwei gleiche Methoden mit unterschiedlichen Parametern, ignoriert Iona die Parameter bei der Transaktionszuweisung und versieht im Deployment-Descriptor nur eine der beiden Methoden mit Transaktionsattributen. Dies führt beim Deployment zwangsläufig zu Fehlermeldungen. Abhilfe ließ sich nur durch das Setzen des Attributes Transaction Required auf alle Bean-Methoden schaffen.
Schwierig war auch das Erzeugen von Web-Applikationen. Hierfür sind alle benötigten Servlets und JSPs in die Konfiguration einzutragen. Das erste Problem ergab sich beim notwendigen Vorkompilieren der Beans. Der Applikationsserver von Iona ist das einzige Produkt im Testfeld, das dies zwingend erfordert. Der dafür nötige Schalter im Deploymenttool ist jedoch nicht dokumentiert. Des Weiteren müssen alle von den Servlets benötigten Klassen in der *.war-Datei eingetragen sein. Obwohl wir die Klassen in der Konsole angegeben hatten, fügte Iona sie nicht zum Web-Archiv hinzu. Wir mussten sie deshalb umständlich per Hand nachtragen. Die fertige Anwendung bringt dann ein Kommandozeilentool auf den Server. Iona unterstützt kein Hot-Deployment, so dass die Beans nur für die Laufzeit verfügbar sind. Der Deployment-Prozess muss also nach einem Neustart des Servers wiederholt werden.
An den Performance-Tests nahm der I-Portal-Server nicht teil, da es unlösbare Probleme bei der Anbindung der DB2-Datenbank gab. Iona verwendet die mitgelieferten Treiber der Firma Merant. Diese sind derzeit nur für Oracle verfügbar. Eine neue Version, die unter anderem auch DB2 unterstützen soll, ist zwar von Merant angekündigt, befindet sich aber noch im nicht öffentlichen Beta-Stadium. Da alle im Test verwendeten Beans mit "Bean Managed Persistence" arbeiten, ließe sich die Datenbankanbindung auch direkt in den Beans vornehmen und somit der Container als Datenbankvermittler umgehen. Diese Konfiguration setzt aber voraus, dass der Container auf Connection-Pooling verzichtet. Dies hätte die Performance negativ beeinflusst und die Vergleichbarkeit der Ergebnisse in Frage gestellt.
Der Applikationsserver von Iona setzt den J2EE-Standard vollständig um. Abweichungen der Beans vom EJB-Standard toleriert das Produkt kaum. Die Sicherheit ist unzureichend, da die Software nur das im EJB-Standard beschriebene Rollenkonzept unterstützt und es nicht möglich ist, andere Sicherheitssysteme einzubeziehen. Das Unternehmen bietet auch in der neuesten Version keinen direkten Clustering-Support. Es besteht lediglich die Möglichkeit, über die Software "Orbix2000" ein Cluster aufzusetzen. Vor dem Hochfahren des Servers sind einige Dienste zu starten. Dazu zählt der Locator-Dienst, der zirka 17 MByte Arbeitsspeicher belegt, sowie der Naming-Dienst, dessen Speicherbedarf bei etwa 14 MByte liegt. Der Applikationsserver selbst verbraucht rund 14 MByte. Mit insgesamt nur 45 MByte hat Iona im Testfeld den geringsten Ressourcenverbrauch. Die Dokumentation liegt zwar in gedruckter Form vor, ist aber völlig unzureichend. Iona bietet keine eigene Entwicklungsumgebung für die Erzeugung von Beans an.
Das Testbeispiel
Das Szenario für den Applikationsserver-Vergleichstest stammt aus dem Versicherungsbereich und bearbeitet Vorgänge zum An- und Abmelden von Arbeitnehmern. Es besteht aus vier Session- und drei Entity-Beans, welche die Business-Logik repräsentieren. Hinzu kommen 14 Java-Server-Pages (JSP) und drei weitere Servlets zur Anzeige. Proxy-Objekte verbessern die Performance. Sie werden von den Entity-Beans erzeugt und liefern alle Daten in einem Objekt, das bei Methodenaufrufen zum Beispiel an eine Session Bean übergeben werden kann. Dies erspart mehrfache, zeitaufwändige Zugriffe, die besonders dann auftreten, wenn von einem Versicherten alle Daten auf dem Bildschirm zu visualisieren sind. Dieser Anwendungsfall tritt im Testbeispiel am häufigsten auf. Es handelt sich also in der Mehrzahl um Lesevorgänge Schreibvorgänge sind aber ebenfalls zu berücksichtigen.
Die Nachbildung des Online- und Batch-Betriebs der Versicherung erfolgt mit zwei Clients. Ein Batch-Client stellt eine größere Menge von Anfragen direkt an die Beans. Ein Online-Client simuliert mehrere Browser, indem er Anfragen an Servlets und JSPs richtet. Die Performance-Tests führten wir ausschließlich mit dem Online-Client durch, da dieser einen komplexen Anwendungsfall abbildet, der gleichzeitig die EJB- und die Web-Schicht anspricht. Um die geforderte Anzahl von Client-Anfragen beantworten zu können, wurden die Server in einem Cluster betrieben. Dieser arbeitet gegen eine DB2-Datenbank, in die wir einen generierten Anfangsdatenbestand per Script importierten.
Für den Performance-Test kamen verschiedene Transaktionen zum Einsatz. Zum Beispiel lasen wir aus der Datenbank einen Vorgang wie das An- und Abmelden oder die Suche eines Versicherten ein. Dieser Ablauf ging als Versicherungsmeldung, welche die entsprechende Operation enthält, an ein Servlet. Dieses ruft Methoden auf den dazugehörigen Session-Beans auf. Dabei beginnt die eigentliche Servertransaktion. Das Session-Bean arbeitet nun verschiedene Funktionen ab, etwa Speicherung einer neuen Meldung und Konsistenzkontrolle. Nach Abschluss dieser Arbeiten empfängt das Servlet die Werte und bereitet sie zur Darstellung auf. Nach einer einstellbaren Pause beginnt der gesamte Vorgang mit dem Auslesen des nachfolgenden Vorgangs aus dem Datenbestand von neuem.
Der Vergleichstest
Die Performance der Applikationsserver wurde an drei Messpunkten ermittelt, um das Verhalten der verschiedenen Komponenten im Gesamtsystem beurteilen zu können:
- Messpunkt A:
Dieser Messpunkt befindet sich auf dem Client. Er bestimmt die gesamte Bearbeitungszeit, die nach dem Auslesen der Operation aus dem generierten Datenbestand für die Verarbeitung auf dem Server benötigt wird - einschließlich dem Empfang der Anzeigedaten. Da die Testtransaktionen eine unterschiedliche Komplexität und somit unterschiedliche Laufzeiten besitzen, wird hier eine Aussage über die Mittelwerte der Messergebnisse getroffen.
- Messpunkt B:
Er ist in den Servlets angebracht, um die Verarbeitungszeit in den Beans zu bestimmen. Dabei handelt es sich um mehrere Messpunkte, die jeweils an den Aufrufen der Beans im Servlet platziert sind. Die Ergebnisse sind anhand eines über alle Messpunkte gebildeten Mittelwerts oder durch eine direkte Gegenüberstellung der einzelnen Messpunkte verbleichbar.
- Messpunkt C
Der dritte Messpunkt ermittelt die Zeit für die Bearbeitung innerhalb der Datenbank. Hierbei handelt es sich um eine Vielzahl von Messpunkten, die anhand des Mittelwerts aller Punkte vergleichbar sind. Dieser Wert sollte bei allen Applikationsservern in etwa identisch sein, da dieselbe Datenbank und derselbe Treiber zum Einsatz kamen.
Alle Messdaten wurden in Dateien geschrieben, jeder Messpunkt erhielt eine extra Datei. Zu Messpunkt B und C gehören mehrere Dateien, aus denen wir für die Auswertung Mittelwerte bildeten. Das gesamte Beispiel basiert auf "Bean Managed Persistence", so dass sich die Zeitmessungen für den Messpunkt C vor und nach den SQL-Anfragen implementieren lassen. Die Entscheidung für BMP fiel aufgrund der Art der Attributabbildung der Entity-Beans auf die Datenbank. Denn bei einigen Entity-Beans liegt keine 1:1-Zuordnung vor, das heißt, ein Bean benötigt für die Speicherung seiner Attribute mehrere Zeilen einer Tabelle. Diese Art der Speicherung unterstützen die Applikationsserver nicht direkt. Somit ist der Einsatz von "Container Managed Persistence" nicht möglich.
Aus Platzgründen beschränken wir uns auf eine Zusammenfassung der Ergebnisse. Eine vollständige Auflistung der bei den verschiedenen Testläufen ermittelten Messwerte finden Sie auf der Web-Seite der NetworkWorld. Bei den Operationen auf der Datenbank (Messpunkt C) ergaben sich erwartungsgemäß keine gravierenden Unterschiede, da alle Testkandidaten mit derselben Datenbank und demselben Treiber arbeiteten. Geringe Abweichungen sind auf unterschiedliches Zugriffsverhalten, Datenbank-Pooling oder Beans-Abarbeitung der EJB-Server zurückzuführen. Zuerst wurde immer ein UPDATE einer Versicherungsmeldung auf der Datenbank gemessen, anschließend ein SELECT, wie es etwa beim Abmelden nötig ist.
Messpunkt B wurde in den Servlets angebracht und bestimmt die Zeit für die Verarbeitung in den Beans. Die nebenstehende Abbildung fasst die Ergebnisse zusammen. BEA und Inprise liegen etwa auf demselben Niveau, wobei Inprise geringfügig mehr Zeit benötigt. IBM Websphere dagegen ist deutlich langsamer. Das bedeutet, dass der Applikationsserver mehr Zeit für die Abarbeitung der Beans-Logik aufwenden muss. Ein ähnliches Bild zeigen die Antwortzeiten des Messpunkts A. Auch hier benötigt IBM konstant mehr Zeit als die anderen beiden Server.
Das Balkendiagramm fasst die durchschnittlichen Messergebnisse des Tests zusammen. Es gibt den Mittelwert über alle Werte am Messpunkt A wieder. Während Websphere knapp viermal so viel Zeit für den Test benötigt wie BEA, liegt Inprise etwa im Bereich von BEA. Die Performance-Messungen wurden für 100 Nutzer durchgeführt. Bereits bei dieser geringen Anzahl traten Fehler auf. Inprise brach die Ausführung regelmäßig mit einer OutOfMemoryException ab. Dies ließ sich auch durch eine Erhöhung des Speichers der Java Virtual Machine nicht beseitigen, was auf ein Speicherproblem innerhalb des Servers hindeutet. IBM konnte einige Transaktionen nicht abarbeiten, da es interne, nicht nachvollziehbare "Open-Servlet-Engine"- Probleme gab. Die Tests wurden auf IBM und BEA auch mit 1000 Nutzern durchgeführt, wobei die Messergebnisse aufgrund der auftretenden Fehler nicht vergleichbar waren.
Fazit
Den vier getesteten Applikationsservern gemeinsam ist, dass sie sich relativ einfach installieren und in einer Basiskonfiguration in Betrieb nehmen lassen. Bis auf das Produkt von Iona unterstützen alle automatisches EJB-Clustering und Load-Balancing. Bei den Performance-Messungen hat BEA die Nase vorn, knapp gefolgt von Inprise (Iona wurde nicht bewertet). Das Deployment der Web-Anwendungen wirft bei jedem Hersteller Probleme auf, mal mehr, mal weniger gravierend. Für die Auswahl des richtigen Applikationsservers entscheidend ist, ob er die von Ihrem Unternehmen geforderten Sicherheitsstandards erfüllt. Große Unterschiede bestehen zwischen den Produkten hinsichtlich der Toleranz gegenüber Abweichungen vom EJB-Standard. Ein Manko bei fast allen Anbietern ist die unzureichende Dokumentation. (cl)
ZUR PERSON
Neben Prof. Dr. Alexander Schill und Dipl.-Inform. Olaf Neumann arbeiteten an der Vergleichsstudie Dipl.-Inform. Thomas Springer und Thomas Müller (Student) mit, die ebenfalls an der TU Dresden im Fachbereich Informatik tätig sind.