|
|
|
Dina Winkler
Der WebSphere Application Server gewinnt für das Entwicklungsumfeld von IBM immer mehr an Bedeutung. Von den Änderungen profitieren nicht nur IBM-Produkte wie z.B. WebSphere Portal oder WebSphere Commerce, die auf dem WebSphere Application Server aufsetzen, sondern vor allem Kunden, die das Produkt für selbst implementierte oder auch gekaufte J2EE-Anwendungen einsetzen. Der Artikel behandelt ausgewählte Neuerungen des Produkts und vermittelt einen Überblick über die neue Funktionalität.
Wie schon die Vorläuferversion ist auch die neue Generation des WebSphere Application Servers in verschiedenen Ausprägungen erhältlich. In der Grundfunktionalität der einzelnen Editionen hat sich bei Version 6 jedoch einiges geändert. Beispielsweise bietet in der Version 6 auch die Express Edition des WebSphere Application Servers die volle Unterstützung für J2EE 1.4 und deckt damit auch die Entwicklung von EJBs mit ab. Ergänzt wurde die Express Edition außerdem um Programming Model Extensions, welche früher in den höheren Editionen angesiedelt waren. Nach wie vor unterscheidet sich die Express Edition von der nächsthöheren Edition des WebSphere Application Servers (welche auch „Base“ genannt wird) hinsichtlich Lizenzierung sowie im Umfang der unterstützten Plattformen. Für die Mehr-Server-Umgebung mit Cluster-Fähigkeit ist nach wie vor der WebSphere Application Server Network Deployment (ND) zuständig. Im Laufe des Jahres soll die Palette um das Produkt WebSphere Business Integration Server Foundation (WBISF) erweitert werden, welches in der Version 5.0 noch den Namen WAS Enterprise trug, sowie um WebSphere Extended Deployment (XD), das als Basis WAS Network Deployment voraussetzt.
Abb.1: Produkteditionen des WebSphere Application Servers V6
Profile
Das neue Konzept für die Ressourcenverteilung des WebSphere Application Servers, die so genannten Profile, erleichtern nicht nur Installation und Wartung, sondern auch die Administration von Application-Server-Instanzen. Dabei werden alle Ressourcen, die zum Betrieb eines Application Servers sowie weiterer Komponenten wie z.B. Deployment Manager oder Node Agent notwendig sind, in zwei Gruppen aufgeteilt. Die eine Gruppe beinhaltet diejenigen Produktkomponenten, die jede Installation des Application Servers benötigt, wie beispielsweise gemeinsam genutzte Bibliotheken, und bildet damit die statische Komponente des Produkts. Die zweite Gruppe wird als Profil bezeichnet und umfasst diejenigen Ressourcen, die individuell für eine bestimmte Installation sind, wie Konfigurationsdateien, installierte Applikationen, Log-Dateien usw.
Werden also auf einem Rechner mehrere Application Server betrieben, greifen diese auf die gleichen Bibliotheken zu, verfügen aber andererseits über individuelle Profile mit den dazugehörigen Applikationen sowie Konfigurationsdateien. Zu den Vorteilen von Profilen zählt nicht nur der geringe Plattenplatzverbrauch, falls mehrere Komponenten bzw. Application Server auf einem Rechner laufen, sondern vor allem die vereinfachte Aktualisierung des Produkts, da in diesem Fall die zu aktualisierenden Komponenten an einem Platz zu finden sind.
Dem Administrator stehen zur Verwaltung von Profilen entsprechende Werkzeuge zur Verfügung, wie z.B. Profile Creation Tool. Außerdem erhält man mit der Installation Vorlagen zur Erstellung von Profilen für einen Stand-alone Application Server, Deployment Manager sowie einen leeren Knoten, der vom Deployment Manager verwaltet wird.
Abb.2: Verwendung von Profilen
Auch wenn das Konzept von Profilen auf den ersten Blick die administrativen Aufgaben zu verkomplizieren scheint, beeinflussen Profile die Installationszeit nur geringfügig und beanspruchen darüber hinaus kaum Administrationsaufwand.
Administration
Das Erscheinen der neuen Application-Server-Generation bedeutet nicht unbedingt eine sofortige Migration eines bestehenden Systems auf die neue Version. Schließlich ist jede Migration mit Zeitaufwand und Kosten verbunden. Der Umstieg wird jedoch erleichtert durch den Deployment Manager Version 6, mit dem sich auch gemischte Knoten verwalten lassen. Damit können Knoten der Vorversion mit den neu aufgesetzten Knoten koexistieren und zu einem späteren Zeitpunkt migriert werden.
Die Administration von Servern wurde nicht nur durch gemischte Knoten erweitert. Neu ist auch die Verwaltung von Web-Servern in der Administrationskonsole einer Mehr-Server-Umgebung. Hier wird noch unterschieden, ob der Web-Server auf einem durch den Deployment Manager administrierten Knoten läuft oder nicht. Wurde der Web-Server auf einem verwalteten Knoten (Managed Node) installiert, kann für den betroffenen Web-Server beispielsweise das WebSphere-Plug-in über die Administrationskonsole aktualisiert werden. Besonderen Luxus genießt der IBM HTTP Server. Dieser kann von der Oberfläche aus gestoppt bzw. gestartet werden.
Die Administrationskonsole an sich hat nicht nur ihr Äußeres geändert. Sie gehört wie auch FileTransfer zu den Systemapplikationen, die seit der neuen Version getrennt von den benutzerdefinierten Applikation gepflegt werden und daher auch nicht mehr in der Liste der installierten Applikationen enthalten sind.
WebSphere Configuration Archive
Zu den häufigen administrativen Aufgaben gehört unter anderem die identische Konfiguration von mehreren Application-Server-Instanzen. Mit Hilfe des Configuration Archives können Konfigurationen der einzelnen Application Server oder auch des gesamten Clusters exportiert werden. Dabei werden systemabhängige Informationen wie z.B. Hostname entfernt, sodass die exportierte Konfiguration als eine Art Template für die Konfiguration von anderen Application Servern eingesetzt werden kann. Importiert wird das neue Template dann entweder in einen Application Server oder aber auch einen Knoten, woraufhin in diesem Knoten eine Server-Instanz neu angelegt wird.
WebSphere Rapid Deployment (WRD)
WebSphere Rapid Deployments umfasst die automatische Installation, Deinstallation und Aktualisierung von Applikationen bzw. den einzelnen Applikationsmodulen auf dem Application Server im laufenden Betrieb. Die Basis dieses Konzeptes bildet ein so genanntes Hot Directory – ein Verzeichnis, das vom Application Server überwacht wird. Werden Änderungen an den Dateien in diesem Verzeichnis erkannt, wird eine inkrementelle Änderung der betroffenen Applikation durchgeführt. Dieses Verzeichnis bzw. dieser Workspace kann nicht nur fertig paketierte Applikationen und/oder Applikationsmodule enthalten. Wird das Verzeichnis als ein free-form Project konfiguriert, so können dort vielmehr auch einzelne Ressourcen (wie z.B. Java-Klassen, JSPs, HTML-Seiten usw.) platziert werden. Der WebSphere Application Server übernimmt in diesem Fall das Erstellen der notwendigen Artefakte, wie z.B. Deployed Code für EJBs, sowie das Paketieren von Modulen.
Rund um Applikationen
Die inkrementelle Änderung einer Applikation durch die Mechanismen des WebSphere Rapid Deployments basiert auf der Möglichkeit eines feingranularen Updates einer Applikation – einer weiteren Neuerung des WebSphere Application Servers in der Version 6. Im Unterschied zur Vorversion können nun nicht nur die einzelnen Module einer Applikation, sondern auch die einzelnen Ressourcen (z.B. Java-Klassen, JSPs) aktualisiert oder auch entfernt werden. Sollen mehrere Ressourcen gleichzeitig durch eine neuere Version ersetzt werden, können diese verpackt in eine zip-Datei z.B. über die Administrationskonsole eingespielt werden. Früher musste nach einer Änderung die Applikation neu gestartet werden. Seit der neuen Version reicht es, lediglich die betroffenen Module neu zu starten.
Wie bereits erwähnt unterstützt die Version 6 des WebSphere Application Servers J2EE 1.4 vollständig. Da außerdem die älteren J2EE-Versionen 1.2 sowie 1.3 unterstützt werden, ist die Migration von Applikationen auf die neue Version nicht zwingend. Hat man sich zur Migration entschlossen, kann diese auch partiell erfolgen, da die neue J2EE-Version auch Applikationen mit gemischten Modulen erlaubt.
Die neue WAS-Version bringt außerdem neue Sichtbarkeitsbereiche für Ressourcen mit sich. Die bereits bestehenden Sichtbarkeitsbereiche Cell, Node und Server wurden um zwei neue Bereiche erweitert – Cluster und Application. Somit ist es nun möglich, anwendungsspezifische Ressourcen (wie z.B. Data Source) im Sichtbarkeitsbereich einer Applikation zu definieren. Davon profitieren vor allem die so genannten Enhanced EARs, welche zusätzlich zu der paketierten Applikation weitere anwendungsspezifische Deployment-Informationen bzw. Einstellungen wie z.B. Data Source, Classloader-Optionen, Umgebungsvariablen, usw. enthalten. Anhand dieser Informationen werden bei der Installation einer Enhanced EAR entsprechende Ressourcen automatisch im Sichtbarkeitsbereich einer Applikation erstellt und beim Aktualisieren oder Löschen einer Applikation ebenfalls geändert bzw. entfernt.
Cluster-Umgebung
Der Data Replication Service (DRS), der in der Vorversion bereits für HTTP-Sessions eingesetzt wurde, wurde in der Version 6 auch auf Stateful Session Beans erweitert, sodass Stateful Session Beans nun auch clusterfähig sind.
War bisher für die Aktualisierung einer Applikation in einer Cluster-Umgebung der vollständige Stopp des Clusters notwendig, kann dies in der neuen Version durch ein partielles Update vermieden werden. Das Rollout Update in der Administrationskonsole bewirkt die sequenzielle Aktualisierung der einzelnen Application Server im Cluster, ohne die Verfügbarkeit der Applikation zu gefährden.
Ein guter Schritt in die Richtung der angestrebten Hochverfügbarkeit von 99.999% ist die Ausfallsicherheit der Steuerung der Lastverteilung. Diese beim Deployment Manager angesiedelte Steuereinheit war bisher ein Single Point of Failure. D.h. wenn der Deployment Manager ausfiel, war damit automatisch auch die Steuerung der Lastverteilung nicht mehr verfügbar. Gesichert wird die Verfügbarkeit der Steuerung nun durch einen Service, der vom Deployment Manager unabhängig ist und beim Ausfall des Deployment Managers auf einen verfügbaren Server verschoben wird. Überwachung und Steuerung der Verfügbarkeit dieses Services übernimmt der in der Version 6 eingeführte High Availability Manager.
High Availability Manager
Ziel des High Availability Managers ist es, die für die Laufzeitumgebung entscheidenden Services am Leben zu erhalten. Zu diesen Services zählen unter anderem Transaktionsmanager und Messaging, welche seit der neuen Version keinem bestimmten Server mehr zugeordnet sind. Dadurch kann der High Availability Manager beim Ausfall eines Servers die davon betroffenen Services auf einem anderen verfügbaren Servern starten. Diese möglichen „Ausweichserver“ bilden die so genannte Core Group und können für eine Peer-to-Peer-Recovery eingesetzt werden.
Sicherheit
Mit J2EE 1.4 hat Java Authorization Contract for Containers (JACC) auch im WebSphere Application Server Version 6 Fuß gefasst. Diese Spezifikation ermöglicht den Einsatz von Sicherheitsmodulen von Drittherstellern im WAS, welche z.B. die Autorisierung von Zugriffen auf EJBs sowie Web-Ressourcen übernehmen. Das beste Beispiel für einen JACC Provider ist Tivoli Access Manager (TAM), der im neuen WebSphere Application Server integriert ist. Durch den Einsatz von TAM ergeben sich viele Vorteile, wie die Verwendung von Account und Password Policies. Damit kann z.B. ein Account nach mehreren Fehlangaben gesperrt oder die Gültigkeit eines Accounts auf Geschäftszeiten reduziert werden. Außerdem kann die Tabelle mit Zugriffsregeln dynamisch zur Laufzeit modifiziert werden, ohne einen Neustart der Applikation zu erzwingen. Letztendlich kann durch die Positionierung des Reverse Proxy WebSEAL von TAM auch die Authentifizierung der Benutzer bereits in der DMZ erreicht werden.
Fazit
Nachdem die Version 5 des WebSphere Application Servers gegenüber der Version 4 viele architekturelle Änderungen erfahren hat und neue Begriffe wie Node Agent, Deployment Manager usw. eingeführt hat, behielt die neue Version 6 die bewährte Architektur bei. Mit dem High Availability Manager wurden Ziele wie Ausfallsicherheit und hohe Verfügbarkeit in Angriff genommen, die das Produkt von der Konkurrenz abheben. Annerkennung verdient auch die Unterstützung der aktuellen, oft erst vor kurzem verabschiedeten Spezifikationen sowie das Bestreben nach standardisierten Schnittstellen. WebSphere Application Server repräsentiert in der Version 6 eine ausgereifte Laufzeitumgebung für J2EE-Applikationen und bietet durch die Vielfalt an Editionen nicht nur unterschiedliche Lizenzmodelle, sondern auch anspruchsvolle Produkte für individuelle Aufgaben.
Über die Autorin
Dina Winkler ist Consultant und Trainerin bei der ARS Computer und Consulting GmbH (www.ars.de) in München und ist im Unternehmensbereich Application Development und Java-Technologien tätig.
Steckbrief
WebSphere Application Server V6
| Editionen | Funktionalität |
| WebSphere Application Server | Stand-alone Application Server |
| WebSphere Application Server Express | Stand-alone Application Server (Unterschiede zum WAS im Lizenzierungsmodell) |
| WebSphere Application Server Network Deployment | Mehr-Server-Umgebung, Clusterfähigkeit, Work Load Management, Hochverfügbarkeit |
Unterstützte Technologien:
· J2EE 1.4 (Servlets, JSPs, EJBs, Web Services, JMS, JSF usw.)
· SDK 1.4.2
· SDO
· Struts
Unterstützte Plattformen:
· Linux (z/Linux wird von WAS Express nicht unterstützt)
· AIX
· Windows
· Solaris
· HP/UX
· OS/400 und i5/OS
· z/OS (wir von WAS Express nicht unterstützt)
Die Liste mit den genauen Angaben zu den unterstützten Plattformen finden Sie hier:
http://www-306.ibm.com/software/webservers/appserv/doc/v60/prereqs/was_v60.htm
Link:
http://www-306.ibm.com/software/webservers/appserv/was/
|
ARS Systemhaus
Application Development
IT Infrastruktur
Lizenzen
Training