Kurz betrachtet:
IBM Websphere Application Server

Wer einen Application Server sucht, kann mittlerweile aus vielen Möglichkeiten wählen. Eine kurze Betrachtung von IBM Websphere Application Server (WSAS) soll einige hervorstechende Merkmale aufzeigen und als Entscheidungshilfe dienen. In diesem Artikel sprechen wir über die Network Deployment Version des WSAS.

Die Adminstrationsoberfläche

Der WSAS bringt eine browsergestützte Oberfläche mit. Diese bietet Zugriff auf alle Komponenten und deren Einstellung. Der Administrator einer Webspherefarm hat somit einen zentralen Anlaufpunkt und findet alles unter einem Dach wieder (siehe Abbildung 1).

Von der Definition von Datasources bis zum Deployment von Enterprise Applications ist alles innerhalb der Oberfläche möglich. Auch wenn die Oberfläche durch die vielen Möglichkeiten zunächst etwas unübersichtlich erscheint, ist sie nach einer kurzen Eingewöhnungsphase sehr gut zu bedienen.

Neben dieser Oberfläche bietet das Kommandozeilenprogramm wsadmin die Möglichkeit, auch Skripte zu erstellen, um Monitoring oder tägliche Aufgaben effizient und ohne ständigen Zugriff auf ein GUI zu erledigen.

Der Ressourcenhunger

Unter findet man die Hardwareanforderungen des WSAS. Diese sollte man, besonders was den Hauptspeicher angeht (256 MB empfohlen), respektieren bzw. an dieser Stelle besser sogar mehr Speicher als gewünscht "spendieren".

Kleines Beispiel: Der Hauptspeicherbedarf belief sich auf einem Win2K Testsystem mit der Network Deployment Version, einem Application Server und lediglich einer Test-JSP bereits auf ca. 400 MB. Das gleiche Setup, jedoch als Cluster mit zwei Application Servern sorgte dann für einen Bedarf von ca. 750 - 800 MB. Hintergrund dieses Ressourcenhungers ist die Architektur des WSAS, die wir uns im nächsten Abschnitt ansehen.

Die Architektur

Aus Sicht des WSAS entspricht eine Hardwareplattform jeweils einer Node. Nodes können mehrere Application Server enthalten (siehe Beispiel in Abbildung 2).

Auf einer Maschine läuft zusätzlich noch der Deployment Manager, der die Verwaltung der Nodes übernimmt.

Für die Kommunikation läuft auf jeder Node ein Node Agent. Dessen Aufgabe ist es, die vom Deployment Manager kommunizierten Einstellungen auf den Nodes umzusetzen. Der oben erwähnte Ressourcenhunger ergibt sich nun aus der Tatsache, dass alle Komponenten jeweils in einer eigenen JVM laufen. Eine Node mit zwei Application Servern und einem Nodeagent benötigt also bereits drei JVMs.

Die Sessions

Oftmals bereiten Sessioninformationen in geclusterten Webanwendungen Probleme. Die Sessions werden in einer bestimmten JVM erzeugt, und stehen nur dort zur Verfügung.

Mit Hilfe von Cookies oder SSL-Session-Tracking wird dann sichergestellt, dass die eingehenden Anfragen immer zur passenden JVM gelangen. Problematisch wird es aber, wenn nun eine Maschine ausfällt. Da die zugeordneten Sessions nur auf diesem Knoten vorlagen, sind diese unwiederbringlich verloren.

WSAS bietet für dieses Problem das Konzept der Sessionreplikation. Hierbei werden die Sessioninformationen in eine Datenbank geschrieben und sind somit unabhängig von der jeweiligen JVM. Es können also alle Instanzen alle Clients wahlfrei bedienen und ein Ausfall einer Maschine bleibt für den User transparent.

Resümee

Websphere bietet für den Administrator einer großen Umgebung viele Vereinfachungen, allem voran die Administrationsoberfläche sowie die Möglichkeit zur zentralen Steuerung einer ganzen Farm von Maschinen. Falls nötig vereinfacht die Sessionreplikation den Aufbau der Infrastruktur sowie die Konfiguration vorgeschalteter Loadbalancer. Wer für diese Features Verwendung (und die nötige Hardware zur Verfügung) hat, sollte Websphere durchaus in die engere Wahl ziehen.

Seitenanfang

Seite drucken

Seite weiterempfehlen