Leistungsanalyse Websphere

Aus Winfwiki

Wechseln zu: Navigation, Suche
Namen der Autoren:     Michael Simon, Andre Casper
Titel der Arbeit:     Leistungsanalyse WebSphere
Hochschule und Studienort:     Fachhochschule für Oekonomie und Management in Essen



Inhaltsverzeichnis


1 Abkürzungsverzeichnis

Abkürzung Bedeutung
JavaEE Java Platform, Enterprise Edition
WAS WebSphere Application Server
IBM International Business Machines Corporation
EJB Enterprise JavaBeans
JVM Java Virtual Machine
JSP Java Server Pages
JDBC Java Database Connectivity
SQL Structured Query Language
ODBC Open Database Connectivity
SOA Service-Oriented Architecture
XML Extensible Markup Language
SOAP Simple Object Access Protocol
WSDL Web Services Description Language
WSIL Web Services Inspection Language
UDDI Universal Description, Discovery
WLM Workload Management
HTTP Hypertext Transfer Protocol
PMI Performance Monitoring Infrastructure
WSWS WebSphere Studio Workload Simulator
HAManager High Availability Manager


2 Abbildungsverzeichnis

Abbildung 1: Aufbau EJB Architektur
Abbildung 2: Aufbau JDBC
Abbildung 3: WebSphere system HA level 1
Abbildung 4: WebSphere system HA level 2
Abbildung 5: WebSphere system HA level 3
Abbildung 6: WebSphere system HA level 4


3 Tabellenverzeichnis

Tabelle 1: Application Server Marktanteile
Tabelle 2: Übersicht der Prozessor-Value-Units pro Kern
Tabelle 3: EJB Architektur Komponenten


4 Einleitung

"Die deutschen Konsumenten haben im vergangenen Jahr für rund 13,6 Milliarden Euro Waren im Internet gekauft. 
Insgesamt legte der E-Commerce-Umsatz mit einem Plus von 19 Prozent deutlich zu." [1]

Anhand dieser Aussagen erkennt man, wie wichtig der E-Commerce für die Wirtschaft und die Kunden geworden ist. Der Erfolg ist zum Teil der Bequemlichkeit und der einfachen Handhabung zu verdanken. Man muss nur den Browser öffnen, sein gewünschtes Produkt wählen, die Kreditkarteninformationen eingeben und auf die gewünschte Ware warten. Wie wird dieser einfache Prozess technisch realisiert? Ein Online-Shop muss Eingaben aufnehmen, verarbeiten und speichern. Durch das E-Commerce und die dadurch entstandenen Technologien entwickelte sich auch der Application Server.

Folgend soll erläutert werden was ein Application Server ist, mit Bezug auf das Produkt WebSphere Application Server. Wobei es das Ziel dieser Fallstudie ist, die Leistung dieses Produktes zu analysieren. Hierzu haben wir die Fallstudie unterteilt in eine qualitative und eine quantitative Analyse. Die qualitative Analyse soll aufzeigen, welche Technologien und Funktionen dem WebSphere Application Server zur Verfügung stehen. Bei der qualitativen Analyse sollen Wege aufgezeigt werden, wie man die Leistungsfähigkeit des Websphere Application Servers testen könnte.

5 Grundlagen

5.1 Application Server

Ein Server bietet in einem Netzwerk verschiedenste Dienste an. Andere Rechner in diesen Netzen, sogenannte Clients, können auf diese Dienste zugreifen. Es gibt verschiedene Arten von Servern, wie z.B. die File Server, die den Clients Dateisysteme zur Verfügung stellen, Print Server, die das Verwalten von Druckaufträgen übernehmen oder es gibt die im Folgenden zu behandelnden Application Server. Die Aufgabe eines Servers ist es, Anfragen der Clients entgegenzunehmen, diese zu verarbeiten und ein protokollkonformes Ergebnis auszugeben. Dieses System der zentralisierten Datenhaltung entspringt dem Client-Server-Prinzip.[2][3]


Ein Application Server, auch Anwendungsserver genannt, ist eine Software, die es erlaubt, Anwendungen für andere Netzwerkteilnehmer zur Verfügung zu stellen. Ein Application Server bietet eine Laufzeitumgebung an, in der verschiedenste Anwendungen gestartet werden können. Hierbei werden der Anwendung verschiedene Dienste zur Verfügung gestellt:


  • Transaktionen: Ausführung von mehreren aufeinander folgenden Operationen in einer logischen Einheit
  • Authentifizierung: Überprüfung der Zugangsberechtigung
  • Verzeichnisdienste: Zugriff auf eine zentrale Sammlung von Daten
  • Datenbanken: definierte Schnittstellen zum Zugriff auf Datenbanken[4]


Durch die genannten Funktionen resultieren Vorteile für Anwendungen, die auf einem Application Server betrieben werden. So benötigen die Benutzer keine lokal laufende Software auf ihren Rechnern, bis auf einen Webbrowser. Durch diese Tatsache wird kein lokaler Support benötigt, noch muss eine Erweiterung oder Aktualisierung der Software auf allen lokalen Instanzen vorgenommen werden. Die Anwendung wird nur zentral auf dem Application Server gepflegt und verwaltet. Das Merkmal der Zentralität hat außerdem den Vorteil, dass mehrere Benutzer gleichzeitig mit einer Anwendung arbeiten können, wobei der Zugriff auch auf bestimmte Benutzergruppen beschränkt werden kann.[5]


Anwendungen, die auf einem Application Server betrieben werden sollen, können die bereits beschriebenen Dienste und Funktionen nutzen, aber die Anwendungen müssen für den jeweiligen Typ des verwendeten Application Servers entwickelt werden. Es gibt mehrere Typen wie z.B. JavaEE, .NET oder SAP Web Application Server, wobei sich aber der Typ JavaEE größtenteils durchgesetzt hat und der Begriff Application Server als Synonym für den JavaEE Typ verwendet wird. „Java Platform, Enterprise Edition“, kurz JavaEE, ist eine bestimmte Art von Softwarearchitektur, die zur Ausführung von Java-basierten Transaktionen dient. Diese Spezifikation bietet ein Framework, auf dem die in Java entwickelten Anwendungen aufbauen können. Der Sinn liegt darin, durch klar definierte Schnittstellen zu ermöglichen, dass unterschiedliche Softwarekomponenten, wie z.B. Datenbanken, von unterschiedlichen Anbietern miteinander kommunizieren können. Innerhalb des sogenannten Java Community Process werden diese Spezifikationen erarbeitet und letztendlich veröffentlicht.[6]


Warum hat sich gerade der Typ JavaEE durchgesetzt? Es liegt an der starken Verbreitung der Programmiersprache Java. Java ist unabhängig von einzelnen Herstellern und auch von den Plattformen, auf denen die Anwendung laufen soll. Java wurde von vornherein für moderne Anwendungen in Netzwerken entwickelt und kann sowohl für Client- als auch für Server-Anwendungen genutzt werden.[7]


Application Server werden von mehreren Unternehmen angeboten, z.B. Glassfish Enterprise Server oder der hier behandelte IBM WebSphere. Neben diesen kommerziellen Produkten gibt es aber auch Open-Source Produkte oder Application Server, die ohne Lizenzkosten betrieben werden können. Hierzu gehören z.B. Apache Tomcat oder Jboss. Die Unterschiede dieser verschiedenen Produkte kann man besonders an den nicht standardisierten Funktionen ausmachen. So gibt es z.B. Unterschiede bei der Anbindung von Datenquellen, der Verwaltung von Clusterfunktionen oder dem Monitoring der ganzen Umgebung. Aber auch hier sind die Unterschiede eher gering, so das die Unternehmen sich größtenteils durch Preis und Service differenzieren.[8]

5.2 Java Platform, Enterprise Edition

Bei der Java Platform, Enterprise Edition (kurz JavaEE oder früher auch J2EE) handelt es sich um eine Spezifikation für Softwarearchitektur mit besonderem Augenmerk auf Web-Anwendungen.

Als Programmiersprache steht Java im Fokus.


Im Rahmen dieser Spezifikation soll gewährleistet werden, dass Software verschiedener Hersteller in gemeinsamen Umgebungen ohne großen Anpassungsaufwand zusammen arbeitet.


Die erste Version der JavaEE erschien im Dezember 1999 und die aktuellste (Version 6) erschien im Dezember 2009.


Besonders im Bereich Middleware, dem Haupteinsatzgebiet der JavaEE, steht man in starker Konkurrenz zu Microsofts .NET-Plattform.[9]

5.3 WebSphere

WebSphere ist eine Produktlinie von IBM und umfasst unterschiedliche Software für Anwendungsintegration, Infrastruktur sowie eine integrierte Entwicklungsumgebung.


Dank offener Standards können alle Bausteine unabhängig vom Hersteller integriert werden, die ein Anwender für die Umsetzung seiner Applikation benötigt.

Ein weiterer Vorteil von WebSphere-Lösungen ist die Skalierbarkeit.


Der WebSphere Application Server (kurz WAS) bildete den Kern der WebSphere-Plattform. Wobei es sich um ein von IBM entwickeltes Softwaresystem rund um die Entwicklung und den Betrieb von Web-Anwendungen handelt.[10]


5.3.1 Historie

Historisch gesehen war die erste Veröffentlichung das im Juni 1998 erschienene IBM WebSphere Performance Pack.

Ursprünglich war Websphere einen Lösung für Unternehmen die mit ihrer Entwicklungsumgebung ins Web gehen wollten. Im Laufe seiner mittlerweile zehnjährigen Geschichte ist das WebSphere-Portfolio um immer neue Middleware- bzw. Integrationslösungen gewachsen.[11]

Die aktuelle Version 7.0 des Systems erschien im September 2008 in Verbindung mit der Version 5 der JavaEE und Version 6 des Java Development Kit.[12]


5.3.2 Rolle am Markt

Für das Jahr 2007 konnten folgende Zahlen, was die Verbreitung von Java EE-Web-Application-Servern angeht, ermittelt werden. Die Zahlen beziehen sich jeweils auf die Anzahl von Unternehmen, die Lizenzen der jeweiligen Server erworben bzw. (im Falle von JBoss) einen Wartungsvertrag abgeschlossen haben.

Von JBoss wird geschätzt, dass es in diesem Zeitraum insgesamt etwa 10.000 Nutzer der JBoss Enterprise Application Platform gibt.


Java-EE-Server Anzahl Nutzer
IBM WebSphere
75000
Oracle Application Server
32000
BEA WebLogic
15000
SAP NetWeaver Application Server
12000
SUN Sun Java System Application Server
3000
JBoss Application Server
1000

Tabelle 1: Application Server Marktanteile[13]


Im Rahmen dieser Tabelle ist sehr schön zu sehen, wie bedeutend der WebSphere Application Server im Vergleich zu anderen JavaEE basierten Servern am Markt ist.[14]

5.3.3 Vertriebsform

Die Lizenzierung des WebSphere Application Servers erfolgt direkt über die Firma IBM.


Die Höhe der Lizenzgebühren wird über so genannte Prozessor-Value-Units errechnet.

Einem Prozessorkern wird je nach Leistungsfähigkeit eine bestimmte Menge dieser Prozessor-Value-Units zugerechnet. Danach wird die Gesamtzahl der Prozessor-Value-Units aller im System verbauten Prozessoren addiert. Auf diese Weise ergibt sich die Gesamtsumme der zu lizenzierenden Prozessor-Value-Units .

Der Wert von bei der Erstellung dieser Arbeit aktuell im Einsatz befindlicher Prozessoren liegt zwischen 30 und 120.

Die jeweilige Lizenzierung erfolgt inklusive eines zwölfmonatigen Software-Maintenance-Vertrages, der sich zu den jeweils aktuellen Konditionen um ein weiteres Jahr verlängern lässt.


Hierbei ist zu beachten, dass es unterschiedliche Angebote für unterschiedliche Unternehmensgrößen gibt (z.B. Rabatte für kleine und mittelständische Unternehmen).[13]


Tabelle 2: Übersicht der Prozessor-Value-Units pro Kern
Tabelle 2: Übersicht der Prozessor-Value-Units pro Kern[15]



6 Qualitative Analyse

Im folgenden Kapitel werden die wichtigsten Komponenten des Websphere Application Servers beschrieben und ihre Funktion erläutert.

6.1 EJB-Architektur

Enterprise JavaBeans (EJB) ist eine Architektur für Java-Anwendungen, die auf einem Application Server betrieben werden. Seit der Einführung hat diese Architektur stark an Bedeutung gewonnen. Diese Tatsache ist zu erklären durch die entstandene Vereinfachung der Anwendungsentwicklung. EJB Server verringern die Komplexität der Entwicklung, indem systemnahe Arbeiten, wie z.B. Transaktionen, Security oder Datenbankverbindungen, größtenteils übernommen werden. Der Vorteil für die Entwickler ist, dass sie sich auf die Entwicklung der Businesslogik konzentrieren können.

EJB ist ein von mehreren Unternehmen entwickelter Standard. Durch die Standardisierung ist es Entwicklern verschiedener Unternehmen möglich die Architektur zu nutzen. Ein weiterer Vorteil ist es, dass die entwickelten Anwendungen portierbar sind, d.h. sie sind unabhängig vom darunter liegenden System und können auch auf einem beliebigen anderem System betrieben werden, solange es die EJB Technologie unterstützt.

6.1.1 Aufbau

Die EJB Architektur besteht aus sechs verschiedenen Komponenten, die in der Abbildung 1 dargestellt werden.


Abbildung 1: Aufbau EJB Architektur
Abbildung 1: Aufbau EJB Architektur[16]


EJB Server Hierbei handelt es sich um einen Teil des WebSphere Application Servers selbst, der aus mehreren EJB Containern bestehen kann und allen EJBs die primären Dienste zur Verfügung stellt.
EJB Container Diese Komponente bildet die Schnittstelle zwischen dem Server und den EJBs, wobei auch die Laufzeitumgebung für die EJBs zur Verfügung gestellt wird.
EJB Component Hier wird die eine einzelne EJB selbst dargestellt
EJB interfaces Hierbei handelt es sich um eine Schnittstelle für die Clientapplikation
EJB Deployment Descriptor Diese Komponente gibt der EJB die Konfigurationseinstellungen bei der Initialisierung mit.
EJB Client Dies ist ein Client, der auf die EJB zugreift

Tabelle 3: EJB Architektur Komponenten[17]

6.1.2 Arten

Es gibt drei verschiedene Arten von EJBs. Entity beans werden zur Nachbildung der Businesslogik verwendet. Für gewöhnlich repräsentieren sie Daten aus einer Datenbank. Session beans hingegen repräsentieren einen Arbeitsschritt. Zudem werden sie zur Koordination zwischen den verschiedenen EJBs genutzt. Message-driven beans sind den session beans sehr ähnlich, repräsentieren aber auch Aufgaben. Diese EJB reagiert auf Nachrichten innerhalb des Systems.[18]

6.2 JDBC

Java Dastabase Connectivity (JDBC) ist eine von der Firma SUN entwickelte Schnittstelle, die Zugriffe auf Datenbanken standardisieren und vereinfachen soll. Hierbei wurden drei Hauptziele ausgegeben:


  • die Schnittstelle soll Befehle, die von in Java programmierten Anwendungen abgesetzt werden, in SQL Abfragen umwandeln. Diese Abfragen werden dann auf der jeweiligen Datenbank ausgeführt und die Ergebnisse werden als Java Objekte zurückgegeben.
  • Die Schnittstelle soll auf bereits bestehenden Schnittstellen aufbauen. JDBC wurde beeinflusst von Schnittstellen wie „X/OPEN SQL Call Level Interface“ oder ODBC, welches sich als allgemeiner Standard nicht durchsetzen konnte.
  • Die Schnittstelle soll so einfach wie möglich sein, aber trotzdem dem Entwickler die höchstmögliche Flexibilität geben. So werden für einfache Aufgaben auch nur einfache Schnittstellen verwendet, wobei es für außergewöhnliche Aufgaben auch spezialisierte Schnittstellen gibt.


Abbildung 2: Aufbau JDBC
Abbildung 2: Aufbau JDBC[17]


JDBC bildet die Schnittstelle zwischen der Anwendung und den jeweiligen Datenbanksystemen. Für jedes Datenbanksystem gibt es so genannte JDBC Driver, die zur Anbindung von Datenbanksystemen verschiedenster Anbieter dienen. In der Abbildung Abb. 12 ist dieser Aufbau dargestellt.[19]

6.3 SOA

Service-oriented architecture (SOA) ist eine Architektur, die sich grundsätzlich dadurch auszeichnet, dass die Businesslogik eines Unternehmens in einzelne Dienste unterteilt wird. Diese Dienste sind mittels eines Workflows verbunden, der die entsprechende Businesslösung darstellt. Diese Dienste können nur auf einem Application Server untergebracht werden. Da Application Server meist auch mit einem Web-Server verbunden sind, oder selbst einen beinhalten, werden die Dienste auch im Intranet verfügbar gemacht und die Clients benötigen keine zusätzlichen Programme oder Daten, nur einen Webbrowser. Diese Tatsache führte zur Erfolgsgeschichte der hier beschriebenen Architektur.[20]


6.4 Webservices

Angelehnt an das Thema SOA werden jetzt die Webservices betrachtet, die die SOA-Architektur umsetzen. Webservices sind Dienste, die Internetprotokolle und Standards benutzen. Das Hauptaugenmerk bei Webservices liegt darauf, Anwendungen über das Internet zugreifbar zu machen, wobei diese unabhängig von der jeweiligen Plattform oder Programmiersprache sind. Webservice sind modular aufgebaut und können über das Internet beschrieben, veröffentlicht, gefunden oder aufgerufen werden. Webservices nutzen die folgenden Technologien


  • XML – Extensible Markup Language ist eine generische Sprache, die Daten in einer strukturierten Weise verwaltet.
  • SOAP – Simple Object Access Protocol ist eine Netzwerk-, Transport- und Programmiersprache, die das XML Format verwendet.
  • WSDL – Web Services Description Language ist eine auf XML basierende Schnittstelle und wird verwendet um Funktionen eines Webservices zu spezifizieren und die Zugriffsdaten zu veröffentlichen.
  • WSIL – Web Services Inspection Language ist ebenfalls XML-basiert und dient zum Auffinden von Webservices.
  • UDDI – Universal Description, Discovery, and Integration wird auf der Client- und Serverseite implementiert und dient zum Informationsaustausch.


zur Kommunikation mit Clients oder anderen Diensten. Außerdem haben Webservices die folgenden Eigenschaften:


  • Eigenständig – Der Client oder Dienst der den jeweiligen Webservice nutzt, benötigt in den meisten Fällen nur einen HTTP Client.
  • Selbstbeschreibend – die Definition des Nachrichtenformates wird immer mitgesendet.
  • Modular – einzelne einfache Webservices können miteinander verbunden werden und komplexe Businesslogiken ausführen.
  • Generell offen und standardisiert – Es werden gültige Standards wie XML und HTTP genutzt und ein großer Teil an Webservices wurde im Rahmen von open source Projekten erstellt.
  • Dynamisch – Webservices können aktualisiert oder verändert werden, ohne das der Client etwas davon mitbekommt.
  • Zielorientierte Zugriffe – Webservice haben keine Schnittstellen, daher müssen Benutzer die Schnittstellen kennen. Sie müssen aber nicht wissen, wie der Dienst implementiert ist.[21]


6.5 Monitoring

Um die Lauffähigkeit von Geschäftsprozessen zu bewahren, ist es für IT-Komponenten unabdingbar ein Monitoring zu installieren. Der Websphere Application Server bietet einige Werkzeuge um eine Monitoring-Strategie umzusetzen und die Leistungsfähigkeit des Application Servers aufzuzeigen.

Da Applikationen, die auf einem WebSphere Application Server installiert sind, aus verschiedenen Komponenten bestehen und eine Anfrage von mehreren Komponenten bearbeitet wird, kann das Monitoring sehr komplex sein.

Durch das Monitoring kann man ein Verständnis für die Basis-Leistungsfähigkeit bekommen, um in Zukunft Abweichungen von Applikationen oder Komponenten zu erkennen. Es kann ebenfalls dazu beitragen, die Ursachen für Fehler zu finden oder um Flaschenhälse, die die Leistungsfähigkeit beeinträchtigen, ausfindig zu machen.

Beim WebSphere Application Server gibt es 2 Strukturen, die Informationen für das Monitoring sammeln:


  • PMI – Performance Monitoring Infrastructure sammelt statistische Daten mit Hilfe von Agenten, die auf dem ganzen Application Server verstreut eingesetzt werden um Leistungsdaten zu sammeln.
  • Request metrics sind eine Sammlung von Agenten, die zur Zeitmessung für die Bearbeitung von Anfragen in den verschiedenen Application Server Komponenten benötigt werden.

Um die so gesammelten Daten lesbar zu machen, bietet der WebSphere Application Server ein eigenes Werkzeug an. Im TPV – Tivoli Performance Viewer können verschiedenste Einstellungen für das Monitoring vorgenommen werden und natürlich auch bestehende Daten angezeigt und ausgewertet werden.

Durch das Monitoring kann beispielsweise in Erfahrung gebracht werden, ob Datenbankzugriffe schnell genug sind, ob die Datenbankverbindungen auch korrekt gehalten und geschlossen werden oder ob genug Speicher allokiert wurde und inwieweit dieser ausgelastet ist.[22]


6.6 Verfügbarkeit

Die Verfügbarkeit ist die Fähigkeit eines Systems auf Anfragen zu reagieren, egal unter welchen Umständen. Um eine Hochverfügbarkeit zu realisieren, muss das System redundant ausgelegt sein. Durch die Redundanz werden Probleme oder Ausfälle in einzelnen Komponenten abgefangen und das System ist weiterhin lauffähig. Die Redundanz kann vertikal aufgebaut werden, indem mehrere Application Server auf eine Hardware installiert werden. Da jetzt aber der Server, also die Hardware, der „single point of failure“ ist, muss für eine Hochverfügbarkeit auch der horizontale Aufbau, also die Verteilung der Application Server auf mehrere Server, berücksichtigt werden. Um solch eine Redundanz zu ermöglichen, bietet der WebSphere Application Server die Möglichkeit einen Cluster aus mehreren Application Servern aufzubauen. Dieser Cluster kann aus mehreren Instanzen auf einem Server bestehen oder aber verteilt über mehrere Server.

6.6.1 Workload Managment

Das Werkzeug IBM WebSphere Application Server Network Deployment bietet eine Funktion zum verteilen von Lasten. Anfragen an eine Anwendung, die auf einem Cluster läuft, werden zu dem Clustermitglied geleitet, welches fähig ist darauf zu antworten. Eine Anwendung, die auf solch einem Cluster installiert wurde, läuft auf allen Clustermitgliedern gleichzeitig. Das Workload Management (WLM) verteilt die Last auf die einzelnen Clustermitglieder anhand einer vorgegeben Gewichtung. Durch diese Methode ist es möglich Servern mit mehr Leistung auch mehr Anfragen zuzusenden.

Eine weitere Funktion des WLM ist es, bereits existierende Anfragen, die auf einer gerade ausgefallenen Instanz bearbeitet wurden, auf eine andere funktionierende Instanz umzuleiten. So kann verhindert werden, dass Anwender etwas von dem Ausfall mitbekommen. Diese Funktion wird durch den HAManager, der auf jedem Clustermitglied installiert ist, gesteuert. Eine weitere Funktion ist, dass anschließende Anfragen nicht mehr an diese Instanz geleitet werden, sondern auf die anderen lauffähigen Clustermitglieder verteilt werden. Da in diesem Fall die anderen Instanzen eine höhere Last zu verarbeiten haben, muss das Design des Systems diese benötigte Extraleistung mit eingeplant haben. Diese Funktion ermöglicht es auch, Aktualisierungen oder Modifikationen an der Anwendung während des Betriebes durchzuführen, ohne einen Ausfall der Anwendung hinzunehmen. Sollten die Instanzen des Clusters nicht ausreichen, können jederzeit neue Instanzen hinzugefügt werden.


6.6.2 Kosten

Verfügbarkeit ist auch immer verbunden mit Kosten. Je mehr Geld man investiert, desto weniger Ausfälle wird man haben, bzw. desto niedriger ist die Ausfallwahrscheinlichkeit. Daher ist es wichtig zu wissen wie viel Schaden bei einem temporären Ausfall des WebSphere Application Servers entstehen würde, wobei der Schaden nicht nur aus dem finanziellen Gesichtspunkten beachtet werden sollte. Ausfälle können auch für Unternehmen einen Imageschaden zur Folge haben oder zu Vertrauensverlust führen. Ein Beispiel für Anwendungen, die ein hoch verfügbares System benötigen, sind Finanzdienste, die bei kurzen Ausfällen schon einen Schaden in Millionenhöhe verursachen können.


6.6.3 Ebenen

Auf Basis der bereits beschriebenen Möglichkeiten zur Erhaltung der Erreichbarkeit eines Systems wurden die fünf Ebenen der Hochverfügbarkeit eines WebSphere Application Servers entwickelt.


WebSphere system HA level 1 wird auf der Abbildung 3 dargestellt. Es sind die drei Komponenten HTTP Server, WebSphere Application Server und Datenbank zu sehen. Sobald eine dieser Komponenten ausfällt, ist die Anwendung nicht mehr erreichbar.

Abbildung 3: WebSphere system HA level 1
Abbildung 3: WebSphere system HA level 1[23]


WebSphere system HA level 2 wird auf der Abbildung 4 dargestellt. Im Unterschied zur vorherigen Ebene wird hier ein Cluster genutzt, der auf einem Server läuft. Sollte hier ein Application Server ausfallen ist die Anwendung noch immer erreichbar. Bei den anderen Komponenten verhält es sich wie in der vorherigen Ebene erläutert.

Abbildung 4: WebSphere system HA level 2
Abbildung 4: WebSphere system HA level 2[24]


WebSphere system HA level 3 wird auf der Abbildung 5 dargestellt. Hier wird das System aus der zweiten Ebene dupliziert und die Zugriffe über einen Boadbalancer verteilt. Zusätzlich werden die Daten der Datenbank auf einem separaten Storageserver gelagert, wo beide Systeme drauf zugreifen können. Sollte auf dieser Ebene der Loadbalancer oder die Datenbank ausfallen, ist die Anwendung nicht mehr erreichbar.

Abbildung 5: WebSphere system HA level 3
Abbildung 5: WebSphere system HA level 3[25]


WebSphere system HA level 4 wird auf Abbildung 6 dargestellt. Im Gegensatz zur vorherigen Ebene gibt es hier auch für den Loadbalancer und die Datenbank eine Redundanz. Auf dieser Ebene gibt es keine Komponente mehr, die bei einem Ausfall die Anwendung unerreichbar macht.

Abbildung 6: WebSphere system HA level 4
Abbildung 6: WebSphere system HA level 4[26]


WebSphere system HA level 5 ist die letzte Ebene und hier wird das komplette System vor dem Katastrophenfall geschützt. Das ganze System muss nach diesem Ansatz in einem anderen Rechenzentrum identisch aufgebaut werden. Sollte das eigentliche Rechenzentrum einer Katastrophe, wie z.B. einem Feuer, zum Opfer fallen, kann das Backup-System die ankommenden Anfragen bearbeiten.[27]

6.7 Sicherheit

Auch das WebSphere Sicherheits-Konzept spiegelt den grundsätzlichen Aufbau der WebSphere-Plattform wieder. Es ist kompatibel zu allen gängigen Standards, lässt dem Anwender aber auch die Möglichkeit, die nötigen Komponenten selber zu erstellen und zu erweitern, sollte dies nötig sein.

So ist es zum Beispiel bei der Benutzerverwaltung möglich, sowohl auf die Nutzerdatenbank eines zugrundeliegenden Betriebssystems zuzugreifen als auch auf die Daten einer separaten LDAP-Implementierung. Sollte dies beides nicht ausreichen, so ist es immer noch möglich, innerhalb der WebSphere Application Servers eine eigene Benutzerverwaltung zu implementieren.

Um eine sichere Kommunikation zwischen dem WebSphere Application Server und den Clients zu gewährleisten wird auf die weit verbreitete Kombination aus SSL und TLS gesetzt.

Um den Anwendern die Möglichkeit zu geben, eigene Anwendungen zu schreiben, die auf die Benutzerdatenbank des Application Servers zurück greifen und diese für die Bestätigung der Zugriffsrechte der Nutzer zu nutzen, wird vom WebSphere Application Server der Java Authentication and Authorization Service (kurz JAAS) unterstützt.

Des Weiteren wird vom Konzeptionellem zwischen der administrativen und der Anwendungssicherheit unterschieden, die sich auch wiederum separat voneinander schalten lassen.

Auf der Ebene der administrativen Sicherheit geht es in erste Linie darum, die Möglichkeiten von Seiten des Nutzers her das System anzugreifen zu minimieren bzw. zu verhindern, dass das System über die Administrationswege kompromittiert werden kann.

Bei der Anwendungssicherheit beschäftigt man sich mit der Frage, wie man den Application Server vor Zugriffen aus der Software heraus schützen kann. (Hierbei wird z.B. darauf gesetzt, dass einzelne Instanzen von Applikationen isoliert voneinander ausgeführt werden.)[28]

7 Quantitative Analyse

An dieser Stelle soll anhand von Beispielen aufgezeigt werden, wie mögliche Systemtests aussehen könnten. Hierzu wollen wir uns einmal drei mögliche Arten von Testszenarien raus greifen.


7.1 Unit Testing

Beim "Unit Testing" werden einzelne Komponenten des Softwaresystem getestet. Diese Tests finden in einer Entwicklungsumgebung statt. Mit dieser Art von Tests soll sichergestellt werden, dass sich die einzelnen Komponenten schon vor dem Zusammenfügen des Gesamtsystems so verhalten, wie es ihrer Leistungsbeschreibung entspricht.


Im Rahmen des Tests eines Websphere Application-Servers wäre es zum Beispiel möglich in einem Shopsystem die einzelnen Teile des Bestellvorgangs als einzelne Units zu definieren und so unabhängig voneinander zu testen.


An dieser Stelle wollen wir einige Beispiele für mögliche Tests anführen:


1. Schnittstellen-Test.


Im Rahmen des Tests einer Plattform für einen Online-Shop soll die Schnittstelle zwischen dem auf der Plattform selber ablaufenden Bestellprozess und der Anwendung eines Drittanbieters für Finanztransaktionen zur sicheren Online-Bezahlung getestet werden. Hierzu ist natürlich die Kooperation des entsprechenden Partners (in diesem Fall des Finanzdienstleisters) nötig.


  1. Vorbereitung von Performance-Tests


Eine weitere Möglichkeit für den Einsatz von Unit-Tests ist die Vorbereitung von Performance-Tests. Hierbei werden die einzelnen Teile der Applikation vorab getestet um herauszufinden, wie hoch die jeweilige Anforderung an die Hardware ist. Mit den Ergebnissen dieser Tests lässt sich dann ein entsprechendes Soll-Ergebnis für die Performance-Tests konstruieren und danach im Rahmen des Tests des gesamten Systems gegen testen.[29]


7.2 Performance Testing

Von "Performance Testing" spricht man, wenn Tests durchgeführt werden, die es zum Ziel haben zu erfahren, wie sich eine Software oder eine Webseite unter Last verhalten. Dies wird in der Regel dadurch erreicht, dass Benutzerzugriffe simuliert werden, deren Taktung sich beliebig steigern lässt.

Hiermit ist es zum einen möglich voraus zu sagen, wie sich das System verhalten wird, wenn es zu Lastspitzen im Einsatz kommt, zum anderen versetzt es die Testenden in die Lage, das System im Zusammenspiel mit möglichen anderen Komponenten zu beurteilen.

Hier wäre z.B. ein Benchmark auf einer Hardware-Plattform denkbar, auf der die Software zum Einsatz kommen soll um abzusehen, ob es überhaupt wie geplant möglich ist, ob es bei stärkerer Belastung zu Performance-Flaschenhälsen kommt oder ob und wenn wie gut die Skalierbarkeit des Systems unter Last ist.[30]


Die IBM WebSphere Produktfamilie bietet eigens hierfür ein eigenes Tool. Hierbei handelt es sich um den "WebSphere Studio Workload Simulator" (kurz WSWS), welches eine Großzahl von Funktionen zur Simulation von Systemlast für Webumgebungen und der Analyse des aufgetretenen Verhaltens mit sich bringt.


Der Einsatz einer WebSphere Application Server lohnt aufgrund der anfallenden Kosten erst ab einer gewissen Menge an zu erwartenden Usern.

Daher ist es im jedem Fall sinnvoll, das System vorab unter der erwarteten Last zu testen.


Mögliche Performance-Tests im Rahmen eines solchen WebSphere-Einsatz wären:


1. Mechanismen zur Skalierung


Da es immer wieder zu Situationen mit besonderen Lastspitzen kommt, ist es sinnvoll die Mechanismen zur Skalierung des Systems vorab unter möglichst hoher Last zu testen. Dies ist gerade deshalb notwendig, um sicher zu stellen, dass das System die Verteilung von Anfragen oder das Verlagern von einzelnen Diensten auf andere Maschinen auch im ausgelasteten Zustand durchführen kann, ohne dass es zu Problemen kommt.


2. Erkennung von Problemen im Zusammenspiel von Komponenten


Im Zusammenspiel von Komponenten kann es vorkommen, dass es zu Problemen kommt, die so vorab nicht abzusehen sind und auch in Einzeltests nicht näher hervortreten. Die Gründe hierfür können vielfältig sein, zum Beispiel zeitgleiche Zugriffe von verschiedenen Bestandteilen des Systems auf die gleiche Hardware.


3. Servercluster


Ein weiteres Beispiel für einen Einsatz von Performance-Tests ist, wenn die WebSphere Plattform auf einem Servercluster betrieben werden soll.

In dieser Umgebung sollte vor Produktivschaltung der Plattform getestet werden, ob alle erforderlichen Dienste korrekt weiterarbeiten, wenn es zum Ausfall eines der Clusterknoten kommt. Grade diese Mechanismen sollten durchaus auch unter Last getestet werden.[31]


7.3 Operational Testing

Unter "Operational Testing" verstehen wir in diesem Sinne einen "Test durch den Endverbraucher". Hierbei handelt es sich nicht um ein Test unter vorab klar definierten Rahmenbedingungen.


In der Regel werden diese Tests in Form so genannter Beta-Tests durchgeführt.

Der aktuelle Gesamtbestand des Systems wird einer Gruppe von Endverbrauchern zur Verfügung gestellt. Hierbei kann es sich entweder um eine offene oder um eine geschlossene Gruppe von Testern handeln.

Auf diese Weise ist es möglich die Software von einer breiten Masse unter verschiedensten Voraussetzungen testen zu lassen. Des Weiteren wird mit diesem Verfahren Rechnung getragen, dass in der Regel der Endanwender eine völlig andere Art und Weise des Herangehens an ein System hat als es bei einem geschulten Test-Team der Fall ist.


Diese Form des Testens ist bei Webapplikationen nicht ganz so üblich wie bei herkömmlicher Software, wird aber auch immer wieder eingesetzt.[32]


8 Fazit

Die Arbeit hat gezeigt, dass der WebSphere Application Server ein sehr umfassendes Produkt ist, das im Rahmen seines Anwendungsbereiches wie auch im Vergleich mit anderen Application Servern sehr erfolgreich ist.

Der Meinung der Autoren nach ist einer der Gründe für den Erfolg der WebSphere Application Servers das besonders umfangreiche Paket an zusätzlicher Software sowie Wartungs- und Testmechanismen, die von IBM im Rahmen der WebSphere Plattform angeboten werden.

Ein weiterer Grund für den Erfolg des Marktführers im Bereich der JavaEE basierten Application Server ist die konsequente Umsetzung quell-offener Standards. Dies ermöglicht eine besonders hohe Kompatibilität zu Software anderer Hersteller, die sich auf diesem Weg bestens in das bestehende Konstrukt einbinden lässt. (Was ja z.B. auch besonders dann eine gute Grundlage bildet, wenn man verschiedene bereits produktive System miteinander verschmelzen möchte, z.B. im Rahmen einer Unternehmensübernahme oder Fusion) Wobei wir auch der Meinung sind, dass es sich bei diesem Punkt eher um ein "Must-Have" und somit um eine Grundvoraussetzung für den Erfolg eines Application Servers handelt als um ein wirkliches Abgrenzungsmerkmal.

Des Weiteren sind die Autoren der Meinung, dass der eigentliche Grund für den großen Erfolg der WebSphere Plattform am Markt in den von IBM rund um diese Plattform angebotenen Dienstleistungen liegt. Hier ist es dem Hersteller wirklich gelungen, sich von den Konkurrenten am Markt abzugrenzen.

Allerdings bleibt an dieser Stelle ganz eindeutig noch einmal darauf hinzuweisen, dass es sich bei dem WebSphere Application Server um ein sehr aufwendiges System handelt, dass sich erst ab einem recht hohen Systemumfang einzusetzen lohnt und bei dem man sich sehr genau überlegen sollte, ob man nicht mit einer weniger komplexen Lösung besser bedient währe.

9 Fußnoten

  1. GfK Gruppe (2009) passim
  2. Vgl. Stark, Thomas (2005), S. 214
  3. Vgl. Kreidler, Volker (2004), S. 12
  4. Vgl. Andresen, Andreas (2003), S. 261
  5. Vgl. Cao, Jiannong (2004), S. 451
  6. Vgl. Mukhar, Kevin (2006), S. 2
  7. Vgl. Flanagan, David (2003), S. 6
  8. Vgl. Ebel, Nadin (2005), S. 351
  9. Vgl. Evans, Ian (2006), S. 2
  10. Vgl. Schäffer, Stefan (2002), S. 44
  11. Vgl. Fiedler, David (1998) passim
  12. Homepage IBM (2010) passim
  13. 13,0 13,1 Vgl. Rymer, John R. (2007) passim
  14. Vgl. Rymer, John R. (2007) passim
  15. Homepage IBM (2010) passim
  16. Weiss, Martin (2003), S. 36
  17. 17,0 17,1 Weiss, Martin (2003), S. 36
  18. Vgl. Weiss, Martin (2003), S. 1
  19. Vgl. Reese, George (2000), S. 25
  20. Vgl. Burbiel, Herbert (2007), S. 262
  21. Vgl. Whyley, Chris (2005), S.1
  22. Vgl. Veser, Jörg-Ulrich (2009), S. 537
  23. Vgl. Schmitt, Michael (2005), S. 19
  24. Vgl. Schmitt, Michael (2005), S. 20
  25. Vgl. Schmitt, Michael (2005), S. 21
  26. Vgl. Schmitt, Michael (2005), S. 24
  27. Vgl. Schmitt, Michael (2005), S. 3
  28. Vgl. Winters, Paul (2006), S. 4
  29. Vgl. Sandler, Corey (2004), S. 91
  30. Vgl. Pitt, David (2003), S. 352
  31. Vgl. Moore, Dennis (2004), S. 5
  32. Vgl. Frühauf, Karol (2006) S. 77


10 Literatur- und Quellenverzeichnis

Andresen, Andreas (2004) Andresen, Andreas: Komponentenbasierte Softwareentwicklung mit MDA, UML 2 und XML, Hanser Verlag, 2004

http://books.google.de/books?id=h8FuzfwXE30C&pg

Burbiel, Herbert (2007) Burbiel, Herbert: SOA & Webservices in der Praxis, Franzis Verlag, 2007

http://books.google.de/books?id=hA7ZG9um22gC&pg

Cao, Jiannong (2004) Cao, Jiannong: Parallel and distributed processing and applications: second international symposium, Springer, 2004

http://books.google.de/books?id=aV7tzhEtbxsC&pg

Ebel, Nadin (2005) Ebel, Nadin: WebSphere/Domino Workplace Administration, Pearson Education, 2005

http://books.google.de/books?id=c6gXX-RCJEEC

Evans, Ian (2006) Evans, Ian / Jendrock, Eric / Ball, Jennifer / Carson, Debbie: The Java EE 5 tutorial: for Sun Java system application server platform edition 9, Prentice Hall PTR, 2006

http://books.google.de/books?id=t707HcfW014C

Fiedler, David (1998) Fiedler, David: Artikel „IBM Introduces WebSphere Performance Pack“ 17.06.1998, Abgerufen am 11.012.2009 von Site:

http://www.internetnews.com/dev-news/article.php/54161/IBM+Introduces+WebSphere+Performance+Pack.htm

Flanagan, David (2004) Flanagan, David: Java in a nutshell: deutsche Ausgabe für Java 1.4, O'Reilly Germany, 2003

http://books.google.de/books?id=bsiKrwBi8XgC&pg

Frühauf, Karol (2006) Frühauf, Karol / Ludewig, Jochen / Sandmayr, Helmut: Software-prüfung: Eine Anleitung zum Test und zur Inspektion, vdf Hochschulverlag AG, 2006

http://books.google.de/books?id=YJIMPiSbzZcC

GfK Gruppe (2009) o. V., GfK Gruppe: Artikel „E-Commerce-Umsatz wächst weiter“, Abgerufen am 19.12.2009 von Site:

http://www.gfk.com/group/press_information/press_releases/003717/index.de.html

IBM (2008) o. V., ibm.com: Artikel „WebSphere V7.0 Open Beta Announced at Impact 2008“, 22.04.2008, Abgerufen am 14.12.2009 von Site:

https://www.ibm.com/developerworks/mydeveloperworks/blogs/webspherefoundation/entry/imact_2008?lang=en

IBM (2009) o. V., ibm.com: Artikel „Capacity based licensing“, Abgerufen am 20.12.2009 von Site:

http://www-01.ibm.com/software/lotus/passportadvantage/about_software_licensing.html#pvu

Kreidler, Volker (2004) Kreidler, Volker: Internet-basierte Produktions-dienstleistungen für Werkzeugmaschinen, Vulkan-Verlag GmbH, 2004

http://books.google.de/books?id=6zymqxmI8NEC&pg

Moore, Dennis (2004) Moore, Dennis / Kalman, Balazs: Overview of WebSphere Studio Application Monitor and Workload Simulator, ibm.com/redbooks, April 2004

http://www.redbooks.ibm.com/redbooks/pdfs/sg246073.pdf

Mukhar, Kevin (2006) Mukhar, Kevin / Zelenak, Chris / Weaver, James L. / Crume, Jim: Beginning Java EE 5: from novice to professional, Apress, 2006

http://books.google.de/books?id=VA85R10as0IC&pg

Pitt, David (2003) Pitt, David / Brown, Kyle / Craig, Gary / Hester, Greg: Enterprise Java programming with IBM WebSphere, Addison-Wesley, 2003

http://books.google.de/books?id=KBlXQPNGOmIC

Reese, George (2000) Reese, George: Database programming with JDBC and Java, O'Reilly Media, Inc., 2000

http://books.google.de/books?id=E8lNgTkPMfcC

Rymer, John R. (2007) Rymer, John R. , Forrester Research: Application Server Platforms, The Forrester Wave, 11.06.2007

http://www.forrester.com/rb/search/results.jsp?N=133001+70203

Schmitt, Michael (2005) Schmitt, Michael / Roehm Birgit / Chun, Adeline / Joly, William / Klubertanz, Tim / Lee, Li-Fang / Min, Hong / Nakajima, Yoshiki / Nunna, Nagaraj / O'Brien, Terry / Peterson, Kristi / Rathgeber, Jens: WebSphere Application Server Network Deployment V6: High Availability Solutions, ibm.com/redbooks, Oktober 2005

http://www.redbooks.ibm.com/redbooks/pdfs/sg246688.pdf

Stark, Thomas (2005) Stark, Thomas: Jetzt lerne ich J2EE: der einfache Einstieg in die Programmierung mit der Java 2 Enterprise Edition, Pearson Education, 2005

http://books.google.de/books?id=YrER3iYldCUC&pg

Veser, Joerg-Ulrich (2009) Sadtler, Carla / Albertoni, Fabio / Blunt, Leonard / Connolly, Michael / Kwiatkowski, Stefan / Shanmugaratnam, Thayaparan / Sjostrand, Henrik / Tanikawa, Saori / Ticknor, Margaret: WebSphere Application Server V7 Administration and Configuration Guide, ibm.com/redbooks, Juli 2009

http://www.redbooks.ibm.com/redpapers/pdfs/redp4579.pdf

Weiss, Martin (2003) Weiss, Martin / Wahli, Ueli / Denayer, Wouter / Schunk, Lars / Shaddon, Deborah: EJB 2.0 Development with WebSphere Studio Application Developer, ibm.com/redbooks, Oktober 2005

http://www.redbooks.ibm.com/redbooks/pdfs/sg246819.pdf

Whyley, Chris (2005) Whyley, Chris / Wahli, Ueli / Kjaer, Thomas / Robertson, Brett / Satoh, Fumiko / Schneider, Franz-Josef / Szczeponik, Witold: WebSphere Version 6 Web Services Handbook Development and Deployment, ibm.com/redbooks, Juli 2005

http://www.redbooks.ibm.com/redbooks/pdfs/sg246461.pdf

Wiley, John (2004) Wiley, John: The art of software testing, John Wiley and Sons, 2004

http://books.google.de/books?id=86rz6UExDEEC

Winters, Paul (2006) Winters, Paul / Credle, Rufus / Chen, Tony / Kumar, Asish / Walton, James: IBM WebSphere Application Server V6.1 Security Handbook, ibm.com/redbooks, Dezember 2006

http://www.redbooks.ibm.com/redbooks/pdfs/sg246316.pdf

Persönliche Werkzeuge