Transaktionskünstler im Wettstreit
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.