|
|
|
Gib mir noch mal 5 – oder 5²
Die aktuelle Version 5 des IBM WebSphere Application Servers
von Walter Schilder
Mit dem Erscheinen des Entwicklungswerkzeugs IBM WebSphere Studio Application Developer in seiner aktuellen Form ist es nun auch an der Zeit für den Auftritt der passenden Version der Laufzeitumgebung. Mit der Version 5 des IBM WebSphere Application Servers können Enterprise-Applikationen jetzt noch besser und einfacher ihren vollen Leistungsumfang entfalten.
Wer die Wahl hat, hat die Qual, denn wie schon von den vorherigen Versionen gewohnt, präsentiert sich der neue WebSphere Application Server in einer Vielzahl von unterschiedlich zusammengestellten Ausstattungspaketen (siehe Abbildung 1). Angeführt wird diese Reihe von der „Einstiegsversion“ – dem IBM WebSphere Application Server Express. Unter diesem Namen verbirgt sich ein Produkt, welches ausschließlich den Betrieb von reinen Web-Applikationen auf einer einzelnen physikalischen Maschine unterstützt. Technisch gesehen handelt es sich hierbei also um einen Application Server der um den EJB-Container reduziert wurde. Für Applikationen, in welchen zudem auch noch Enterprise JavaBeans zum Einsatz kommen, ist die nächsthöhere Variante erforderlich. Sie wird schlicht IBM WebSphere Application Server genannt und kann neben den klassischen Web-Komponenten (Servlets und JSPs) auch noch alle Arten von EJBs betreiben. Diese Ausführung des Application Servers ist derzeit auch noch als kostenreduzierte Developer Edition erhältlich, welche dann aber natürlich nicht in Produktivsystemen eingesetzt werden darf. Die nächste Ausbaustufe des Application Servers vollzieht den Sprung vom Single Server zum Server Cluster. Mit weiteren Bausteinen, wie etwa dem so genannten Deployment Manager oder den Edge Components, ist der IBM WebSphere Application Server Network Deployment um Merkmale, wie Ausfallsicherheit bzw. Lastverteilung und Caching im Multi-Server-Betrieb ergänzt. Den Abschluss dieser Reihe bildet die derzeit noch nicht verfügbare Enterprise Edition, welche, wie schon aus der Version 4 gewohnt, zusätzlich noch IBM-spezifische Erweiterungen beinhaltet.
Abb. 1: Packaging des WebSphere Application Servers
Verwaltungsaufbau
Wie schon in der Version 4 wird in der neuen Version 5 des WebSphere Application Servers das Konzept einer gemeinsamen Codebasis weiterverfolgt. Dieses Vorgehen wird besonders an einem Merkmal sichtbar, das mit der Version 5 jetzt alle Editionen des Application Servers gemeinsam haben. Zur Speicherung der Server-Konfiguration wird nun keine Datenbank mehr verwendet. Stattdessen werden alle Einstellungen als XML-Dateien im Dateisystem abgelegt. Der Wegfall einer Datenbankinstanz als Repository steigert nicht nur die Performanz, sondern ermöglicht es auch, zum Anpassen der Konfiguration anstatt der Web-Konsole lediglich einen einfachen Texteditor zu verwenden. Die Distribution der Konfiguration erhöht ferner die Ausfallsicherheit des gesamten Systems. Bis zur Version 5 war die Konfiguration über XML-Dateien ein alleiniges Merkmal des WebSphere Application Servers Single Server V4.
Auch die Bezeichnung der Verwaltungseinheiten hat sich grundlegend geändert (siehe Abbildung 2). Die unterste Verwaltungseinheit stellt der so genannte Managed Process, oder einfacher gesagt der eigentliche Server-Prozess, dar. Jeder logische Server läuft dabei in einer eigenen JVM. Auf einem physikalischen Server werden ein oder mehrere Server-Prozesse vom Node Agent kontrolliert und gesteuert. Wird ein Cluster von Application Servern aufgebaut, so übernimmt der so genannte Cell Manager als zentrale Steuereinheit die Verwaltung des ganzen verteilten Systems. Von diesem wird die Konfiguration an alle Knoten der logischen Administrationsdomäne (Cell) weitergeleitet. Die Verwaltungseinheiten des Application Servers haben sich technisch gesehen also kaum bzw. gar nicht geändert, aber die Terminologie ist mit der neuen Version 5 wieder komplett überarbeitet worden.
Abb. 2: Verwaltungsaufbau des WebSphere Application Servers
Unterstützung neuer Standards
Mit der neuen Version des WebSphere Application Servers haben auch die aktuellen Standards der J2EE-Architektur Einzug gehalten. Zu den wesentlichen Eckdaten des unterstützten J2EE-Standards 1.3 zählen JDK 1.3.1, JSP 1.2, Servlet API 2.3, sowie EJB 2.0.
Zu den Neuheiten der Enterprise JavaBeans gehören beispielsweise die Local Interfaces für die optimierte Kommunikation zwischen EJBs innerhalb eines EJB Containers. Ebenfalls verbessert und erweitert wurde der Persistence Manager, so dass nun Beziehungen zwischen Entity Beans durch den Container (Container Managed Relationships, CMR) verwaltet und die Daten effizienter auf nicht relationalen Back-End-Systemen abgespeichert werden können. Als neue Abfragesprache kommt die EJB Query Language (EJB QL) zum Einsatz. Das Home Interface einer EJB kann jetzt um spezielle Business-Methoden (EJB Home Methods) ergänzt werden, deren Ausführung nicht an eine spezielle Bean-Instanz gebunden ist. Der asynchrone Nachrichtenaustausch wurde ebenfalls durch spezielle Komponenten, die Message Driven Beans, ermöglicht.
Eine der hervorstechenden Neuerung des aktuellen JSP API 1.2 ist, dass JSPs jetzt in XML-Notation hinterlegt werden können. An die Stelle der Klasse TagExtraInfo sind entsprechende Einträge im Tag Library Descriptor getreten, wodurch sich die Implementierung von Custom Tags noch einmal vereinfacht. Der Einsatz von Filtern ist mit der Unterstützung des Servlet API 2.3 nun ebenfalls möglich. Zudem lassen sich Zustandsänderungen in ServletContext- und HttpSession-Objekten durch den „Application and Event Listener“ besser verfolgen.
Neben den aktuellen Technologien lassen sich aber natürlich auch alle Applikationen, die auf älteren Versionen des J2EE-Standards basieren, mit der neuen Version 5 des WebSphere Application Servers betreiben.
Weitere Verbesserungen
Nicht nur bei der Unterstützung der aktuellen Standards, sondern auch hinsichtlich seiner inneren Werte hat sich der Application Server weiterentwickelt. Die Administration des Servers ist beispielsweise nunmehr rollenbasiert, wodurch kritische Bereiche der Server-Konfiguration besser geschützt werden. Zudem werden nun die in Java 2 definierten Sicherheitsmechanismen verwendet, so dass die Zugriffsrechte auf die unterschiedlichen Ressourcen – wie etwa auf Ebene der Enterprise-Applikationen, der Resource Adapter, der Java-Bibliotheken oder von JDBC, JavaMail und JMS – angewendet werden können. Neben diesen statischen Sicherheitsrichtlinien wird durch den Java Authentication and Authorization Service (JAAS) dynamisch eine kontextabhängige Autorisierung durchgeführt. Damit ein Verbund von Application Servern noch besser skaliert werden kann, ist der Namensraum nun auf die einzelnen Knoten verteilt, wobei jeder Knoten den identischen Namensdienst betreibt und auch der Wurzelknoten des Namensdienstes (InitialContext) bei allen Servern gleich ist. Für die interne Verwaltung kommen jetzt neu die Java Management Extensions (JMX) zum Einsatz (siehe Abbildung 3). Jede Ressource inklusive dem Application Server wird über ein eigenes Framework modifiziert. Dabei erfolgt der Zugriff nicht direkt, sondern über gewöhnliche JavaBeans, die so genannten Managed Beans (MBeans). Diese laufen in einem speziellen Teil der JVM, dem MBean Server, ab, welcher auch alle MBeans im System registriert. Die externen Applikationen greifen dann auf die registrierten MBeans über spezielle Connectoren/Adapter zu. Beispiele für MBeans sind etwa Cell, Node, AppServer, EJB, und viele mehr. Durch diesen Wechsel auf JMX erfolgt die Administration jetzt auf einem standardisierten Weg, so dass der Application Server auch mit anderen System-Management-Werkzeugen verwaltet werden kann.
Abb. 3: Zugriff auf Verwaltungsressourcen über JMX
Neben der neuen Art der Konfiguration bietet der WebSphere Application Server V5 auch noch einen internen JMS Provider, der für den Nachrichtenaustausch zwischen den Komponenten der Enterprise-Applikationen innerhalb eines Server Clusters genutzt wird, nicht jedoch zur Kommunikation mit externen JMS Providern wie WebSphere MQ. Für die sich immer mehr an Bedeutung gewinnenden Web Services stellt der WebSphere Application Server V5 eine eigene UDDI Registry zur Verfügung, damit bei Intranet-Anwendungen nicht auf Ressourcen außerhalb des Firmennetzes zugegriffen werden muss.
IBM-Erweiterungen
Wie bei jeder bisherigen Version des WebSphere Application Servers stellt IBM dem Entwickler eine Reihe von Erweiterungen (Programming Model Extensions) der J2EE-Standards zur Verfügung. Wie die Vergangenheit gezeigt hat, finden solche Erweiterungen oftmals Einzug in die nächsten offiziellen J2EE-Spezifikationen. Ein Beispiel hierfür ist das Common Connector Framework aus VisualAge for Java, dessen Konzepte sich in der Java2 Connector Architecture widerspiegeln. Eine der besonders interessanten Programming Model Extensions sind die Startup Beans. In den meisten J2EE-Applikationen sind beim Start einer Anwendung sehr viele Initialisierungen durchzuführen. Auch beim Beenden sollte die Anwendung kontrolliert heruntergefahren und alle offenen Ressourcen geschlossen werden. Genau für diesen Zweck sind die Startup Beans gedacht. Sie ermöglichen es dem Entwickler, die Initialisierung von beliebigen Ressourcen zur Startzeit seiner Anwendung durchzuführen. Eigentlich handelt es sich bei den Startup Beans um Stateful Session Beans, welche um eine Methode start() und stop() erweitert wurden. Pro Enterprise-Applikation oder EJB-Modul können mehrere Startup Beans spezifiziert werden, wobei auch eine Startreihenfolge vergeben werden kann.
Eine gängige Problemstellung in der Softwareentwicklung ist, dass in regelmäßigen Intervallen und zu bestimmten Zeiten gewisse Aktionen, wie etwa die Abfrage eines E-Mail-Kontos, durchzuführen sind. Da eine eigene Thread-Verwaltung zur Triggerung von Ereignissen besonders im Mehr-Server-Betrieb sehr komplex und unsicher ist, bietet der so genannte Scheduler einen wesentlich komfortableren und vor allem Cluster-fähigen Weg, diese Vorgänge durchzuführen. Dieser Scheduler ist ein Dienst des WebSphere Application Servers, der entweder eine Stateless Session Bean aufrufen oder eine JMS-Nachricht versenden kann. Als Intervalle sind hierbei auch typische business-orientierte Termine wie etwa Geschäftsjahre, Arbeitstage, Projektpläne usw. möglich. Die gesetzten Termine werden persistent abgelegt und überdauern somit auch den Neustart eines Servers. In diesem Kontext benötigt der Entwickler oftmals auch eine Komponente, die asynchron angesprochen werden kann. Bisher gibt es im J2EE-Standard als asynchrone Elemente nur die Message Driven Beans. Um nicht von einem Nachrichtendienst abhängig zu sein und trotzdem die Möglichkeit zu haben, unabhängige Threads anstoßen zu können, stellt IBM dem Entwickler die Asynchronous Beans zur Verfügung. Als ausführende Komponente agiert hierbei der so genannte Work Manager. Die eintreffenden Aufrufe werden von speziellen Threads asynchron bearbeitet und vom Work Manager in einem eigenen Pool verwaltet. Als Ausführungskontext kommt dabei jeweils der J2EE-Kontext des Aufrufers zum Einsatz.
Eine andere IBM-Erweiterung ist der Dynamic Query Service (DQS). Der DQS ist eine Erweiterung zur EJB 2.0 Query Language und zu den grundlegenden Abfragemöglichkeiten des WebSphere Application Servers. Der Dynamic Query Service besteht aus einer Query Bean und einer Query Engine und erlaubt im Gegensatz zu EJB QL die Erzeugung und Auswertung von Abfragen zur Laufzeit. Diese Abfragen müssen also nicht statisch im Deployment Descriptor deklariert werden. Ein EJB Client ist somit nicht mehr auf die schon vorgegebenen Abfragen beschränkt, sondern wesentlich flexibler in seiner Abfragegestaltung geworden. Die Zahl der sehr selten genutzten, aber für die Applikationslogik dennoch notwendigen Finder-Methoden einer Entity Bean kann also unter Umständen gesenkt werden. Im Gegensatz zu EJB QL erlaubt diese Erweiterung auch, dass nicht nur eine einzelne Objektreferenz oder ein CMP/CMR-Feld als Ergebnis der Abfrage zurückgeliefert werden darf, sondern die Ergebnismenge auch aus mehreren Elementen oder Ausdrücken im SELECT-Teil der Abfrage bestehen kann.
Die letzte hier vorgestellte IBM-Erweiterung ist der Mechanismus Dynamic Access Intent. Im EJB-Programmiermodell hat der Entwickler zwar schon die Möglichkeit, zum Zeitpunkt des Deployments zu deklarieren, welche Art von Zugriffen er für eine EJB für wahrscheinlich hält. Problematisch ist bei diesem Vorgehen jedoch, dass diese Einstellung für alle Instanzen einer EJB gilt. Falls es nur einen einzigen Fall gibt, in dem die Daten einer Entity Bean geändert werden, muss diese als updateable deklariert werden, mit allen damit verbundenen Performanzeinbußen. Beim Dynamic Access Intent wird die Information über die Zugriffsart für jede EJB und Methode dagegen pro Anwendung deklariert. Ferner kann diese bei einer BMP EJB zudem noch vom Container oder auch vom Entwickler zur Laufzeit geändert werden. Somit kann der Zugriff optimal gestaltet und die Performanz gesteigert werden.
System Management
Wenn man auf die Versionen 3.5 oder auch 4 des WebSphere Application Servers zurückblickt, stellt man fest, dass pro Knoten im verteilten System ein eigener so genannter Admin Server-Prozess ablaufen muss. Die Konfiguration für die einzelnen Application Server wird in einem gemeinsamen Repository abgelegt, auf welches der Admin Server-Prozess zugreift. Jede Anwendung wird allein durch den Admin Server-Prozess gesteuert, d.h. gestartet, gestoppt und konfiguriert und wird pro Knoten installiert. Die Konfiguration kann nur über die Java GUI Admin-Konsole oder die Kommandozeilenwerkzeuge XMLConfig und WSCP (WebSphere Control Program) verändert werden. Mit der Version 5 des WebSphere Application Servers ändert sich dieses Szenario grundlegend (siehe auch Abschnitt Verwaltungsaufbau). Die alten WSCP-Skripten und die mit XMLConfig erstellten XML-Konfigurationen müssen migriert werden, da die alten Werkzeuge nicht mehr benutzt werden können. An ihre Stelle tritt das Pogramm Wsadmin.
Die Konfiguration ist nun auf jeden Knoten des Clusters verteilt, so dass beim Start eines Prozesses dessen Konfiguration schon lokal vorliegt (siehe Abbildung 4). Speichermedium ist nun keine zentrale Datenbank mehr, sondern das lokale Dateisystem mit XML-Dateien. Die Verteilung und Synchronisation der Konfigurationsdateien übernimmt dabei der Cell Manager. Er hat die Rolle eines Master Repositories und verteilt die aktuelle Konfiguration an alle zugeordneten Knoten. Diese zentrale Verteilung wird aber nicht nur bei der Konfiguration angewendet. Auch die Applikationsdateien werden vom Master aus verteilt. Durch diesen Verteilungsmechanismus können durch lokale Änderungen im Knoten die Konfiguration und/oder die installierten Anwendungen vom Master abweichen, bis wieder eine Synchronisation durchgeführt wird. Änderungen am Knoten sind also temporär, während Änderungen am Master permanent sind.
Abb. 4: System Management des WebSphere Application Servers
Die Synchronisation wird dabei durchgeführt, wenn eine neue Anwendung installiert wurde, der Anwender sie explizit anstößt oder der Node Agent startet bzw. sie in periodischen Abständen anfordert. Durch die lokale Verfügbarkeit der Konfiguration sind nun keine Startabhängigkeiten mehr gegeben. Es kann also beispielsweise ein Managed Process ohne laufenden Node Agent gestartet werden und umgekehrt. Startet jedoch eine Komponente, versucht sie die Kommunikation zu den anderen möglicherweise laufenden Prozessen aufzubauen, um Informationen auszutauschen.
Generell hat sich die Handhabung der einzelnen Knoten in einem Cluster bei Workload Management geändert. Mit der Version 5 repräsentiert jeder am Cluster teilnehmende Knoten einen identischen Klon mit dem gleichen Satz von Enterprise-Applikationen (.ear). Grundsätzlich sorgt das neue System Management dafür, dass jede Komponente nur noch minimal von einem zentralen Repository oder einem Admin-Prozess abhängig ist. Da zum Zugriff auf die Komponenten JMX verwendet wird, können die unterschiedlichsten Protokolle, angefangen bei HTTP über RMI/IIOP bis JMS, zum Einsatz kommen. So können nun auch theoretisch Management-Anwendungen von Drittherstellern verwendet werden. Standardmäßig wird jedoch die Browser-basierte Administrationskonsole (siehe Abbildung 5) oder das neue Kommandozeilenwerkzeug Wsadmin verwendet, über welche die gesamte Administration des Clusters abgewickelt wird. Die hinter der browser-basierten Administrationskonsole stehende Admin Web-Applikation entspricht dabei dem J2EE 1.3 Standard. Der abgefragte Benutzername dient zum Nachvollziehen und Speichern von benutzerspezifischen Informationen, wie etwa noch nicht abgespeicherten Eingaben und der Zuordnung von einzelnen Rollen bei der Administration.
Abb. 5: Admin-Konsole des WebSphere Application Servers
Fazit
Mit der Version 5 hat sich der IBM WebSphere Application Server wieder ein Stück weiterentwickelt. An die Stellen mit proprietären Ansätzen sind praktisch überall Lösungen getreten, die auf den aktuellen Java-Technologien basieren. Der Wegfall der Datenbank als Konfigurations-Repository spart zum einen Ressourcen und mindert zum anderen die Abhängigkeit von einer zentralen Komponente. Die einzelnen Komponenten funktionieren auch isoliert noch vollständig. Die geplanten Enterprise Extensions geben einen guten Ausblick auf die zukünftigen Standards und helfen dem Entwickler schon heute bei der Implementierung effizienter Anwendungen. Die Produktfamilie ist mit der Express Edition auch wieder vervollständigt worden. So findet sich für jeden Anwendungsfall die passende Laufzeitumgebung. Auch ältere Anwendungen laufen dank des Kompatibilitätsmodus ebenfalls problemlos. Nachdem sich die Performanz des IBM WebSphere Application Servers auch noch einmal verbessert hat, steht dem Erfolg der Version 5 nichts mehr im Wege.
Walter Schilder ist Leiter des Unternehmensbereiches Application Development und Java Technologien der ARS Computer und Consulting GmbH (www.ars.de) in München. Mit seinem Kollegen Stefan Schäffer ist er zudem Autor des Buches „Enterprise Java mit IBM WebSphere“ (ISBN 3-8273-1898-X), welches seit Mitte2002 im Buchhandel erhältlich ist.
Links & Literatur
|
ARS Systemhaus
Application Development
IT Infrastruktur
Lizenzen
Training