Der (J)Boss wird´s richten ...

Wird heute in einem heterogenen Umfeld eine Anwendung realisiert, die einerseits unterschiedliche Clients bedient und andererseits auf schon vorhandene Alt-Systeme und Datenbanken zugreift, dann ist eine Mehrschichtenarchitektur auf Basis eines Applikationsservers die erste Wahl. In diesem Bereich haben sich Enterprise JavaBeans (EJB) basierte Server, auch J2EE Applikationsserver genannt, durchgesetzt.

Kommerzielle Applikationsserver von IBM, BEA, Oracle usw. sind vielen ein Begriff. Bei näherer Betrachtung stellt man allerdings auch fest, dass mit ihnen in der Regel hohe Lizenzkosten und Wartungsgebühren einhergehen. Eine Alternative stellt hier der Einsatz eines Open Source Applikationsservers wie z. B. JBoss dar. Er ist inzwischen einer der meist eingesetzten Applikationsserver weltweit und kann sich ohne weiteres mit seinen kommerziellen Konkurrenzprodukten messen.

Seit Ende Mai 2003 steht die Produktionsversion JBoss 3.x auf der JBoss-Web-Seite zur Verfügung. Dieser Artikel stellt in Kürze die wichtigsten Features und Verbesserungen des aktuellen Releases 3.2 vor.

Neue JMX-Architektur

Die von Grund auf neu entwickelte Architektur des JBoss-Servers basiert auf der Java Management Extension (JMX). JMX bietet einen Standard zur Verwaltung und Überwachung von verschiedenen Ressourcen (Software- und Hardwarekomponenten) aus Java heraus. JMX bildet das Rückgrat zur Integration und Überwachung aller JBoss-Komponenten, wie Module, Komponenten und Plug-ins (siehe Abbildung 1).

Abb. 1: Die JBoss JMX Architektur mit den darauf aufsetzenden JBoss Komponenten.

Zur Verwaltung und Überwachung werden sogenannte Managed Beans (MBeans) eingesetzt, die mit den jeweiligen Ressourcen assoziiert sind und diese aus JMX-Sicht abstrahieren. Jede MBean muss an einen MBean Server angemeldet sein. Der MBean Server greift zusätzlich auf Services zu, mit denen er die angemeldeten MBeans verwalten kann. Diese können wiederum selbst als MBeans implementiert sein. Der MBean Server und die Services bilden zusammen den JMX Agent.

Die MBeans werden von dem JMX Agent den sogenannten JMX Management Anwendungen zur Verfügung gestellt. Diese kommunizieren mit dem JMX Agent und den MBeans über Kommunikations-Connectoren oder -Adapter. Eine solche JMX Management Anwendung ist beim JBoss die JMX Agent View (JMX Konsole) [http://localhost:8080/jmx-console]. Sie läuft im Browser und dient zur Anzeige und Änderung der aktuellen Konfiguration der JBoss-Komponenten.

Die Web-Konsole liefert u. a. zusätzliche Informationen über die aktuell geladenen EJBs und Deployment-Deskriptoren sowie statistische und dynamische Informationen über die EJB-Nutzung. Kenntnisse über diese Parameter sind während der Entwicklung aber auch später, vor allem bei der Performanceoptimierung, von großer Wichtigkeit.

Unified Class Loader

Früher oder später macht man auch die Bekanntschaft mit einem umstrittenen JBoss-Feature: Die Architektur des Unified Classloaders. Obwohl der EJB-Standard einen Classloader je EJB-JAR vorschreibt, arbeitet der JBoss standardmäßig mit einem übergreifenden Classloader.

Diese Besonderheit wurde eingeführt, um das dynamische Austauschen von Komponenten zur Laufzeit, das sogenannte "Hot Deployment", auch auf die Kernkomponenten des JBoss zu übertragen. War es in JBoss 2.x noch mit Schwierigkeiten verbunden, aus MBeans heraus dynamisch "deployte" J2EE-Komponenten anzusprechen, umfasst das "Hot Deployment" nun auch die MBeans selbst. Somit lassen sich alle Einzelbestandteile des JBoss zur Laufzeit auswechseln.

Die neue Classloader-Architektur bringt es mit sich, dass Klassen in EJB-JARs nicht mehr doppelt vorkommen dürfen. So lassen sich JARs nicht nur nach Zuständigkeiten, sondern auch nach Package-Grenzen bauen. Durch den Wegfall von doppelten Klassen sinkt natürlich auch die Größe der resultierenden JARs. Dies hat den positiven Nebeneffekt, dass sich die Performance der Anwendung spürbar verbessert. Jedoch wäre JBoss nicht JBoss, wenn sich dieses Feature nicht auch so konfigurieren ließe, dass die Classloader-Semantik von JBoss 2.x eingesetzt wird.

Konfigurierbarkeit

Wer JBoss noch aus seinen 2.x Tagen kennt, wird die ersten sichtbaren Änderungen in der Verzeichnisstruktur entdecken. Untergliederten sich die Verzeichnisse bis dato standardmäßig nach ihren funktionalen Aufgaben wie Deployment, Konfiguration etc., wird nun alles in eine wesentlich hierarchischere Struktur gegliedert.

Für jedes Schema ist ein klar definierter "Herrschaftsbereich" vorgesehen. Bestandteile der Konfiguration finden nun auch direkt in den Deployment-Verzeichnissen ihren Platz. Dadurch erweitert sich das "Hot Deployment" des JBoss nun auch um die Skripte zur Datenbankkonfiguration. So lässt sich beispielsweise die zur Laufzeit benutzte Datenbank austauschen.

Messaging mittels JMS

Ein wichtiges Kommunikationsparadigma in J2EE-Anwendungen ist die nachrichtenbasierte (asynchrone) Kommunikation. Zur Realisierung dieser Technik implementiert der JBoss den Dienst Java Messaging Service (JMS) in der Version 1.0.2b.

Das Prinzip dieses Nachrichtenaustausches ist recht einfach. Es gibt drei Instanzen, die beteiligt sind:

1. Sender
2. Empfänger
3. Ein sogenannter MessageBroker

Sender und Empfänger [z. B. MessageDrivenBeans (MDBeans)] kennen sich nicht, kommunizieren nie direkt miteinander und sind somit entkoppelt. Stattdessen werden alle Nachrichten an einen MessageBroker gesendet, wo sie in Queues oder Topics verwaltet werden. Der MessageBroker sendet die Nachrichten an die registrierten Empfänger. Der MessageBroker des JBoss ist der JMS-Provider JBossMQ.

Die Verwaltung und Konfiguration erfolgt auch hier über MBeans. Mit Hilfe der JMX Agent View können verschiedene JMS-Einstellungen vorgenommen und Informationen über den JBossMQ ermittelt werden. Hierzu gehören z. B. das Erzeugen von neuen Queues und Topics oder das Monitoring des Message-Caches (Anzahl der Nachrichten, Performance, etc.).

Container-managed Persistence (CMP) 2.0

Auch die CMP-Engine wurde gegenüber der Vorgängerversion komplett überarbeitet. Sie unterstützt jetzt den Standard CMP 2.0. Eine wichtige Errungenschaft von CMP 2.0 ist das Container Management Relationship. Entwickler müssen die EntityBean-Beziehungen nicht mehr hart kodieren, wie es im EJB 1.0 noch der Fall war.

Der EJB-Container kann 1-1, 1-n und n-m Beziehungen inklusive referenzieller Integrität automatisch verwalten. Dies ist allerdings nur zwischen Local Interfaces, d. h. innerhalb einer JVM möglich. Ein weiteres Merkmal von CMP 2.0 ist die Einführung der EJB Query Language (EJB-QL). Damit lassen sich finder- und ejbSelect-Methoden plattformunabhängig implementieren.

Performance

Die hier vorgestellte Neuimplementierung des JBoss 3.x besticht im Vergleich zum JBoss 2.x vor allem durch seine deutlich gesteigerte Performance. Diese war in einem unserer Kundenprojekte für den Umstieg auf den JBoss 3.x maßgebend.

Fazit

Neben den in diesem Artikel dargestellten neuen Features des JBoss 3.x, sind ausgefeilte Sicherheitsmechanismen auf JTS- und JTA-Basis, Clustering usw. weitere Eckpfeiler des Produkts. Damit ist der JBoss 3.x ein ausgewachsener, performanter und stabiler Applikationsserver.

Die Möglichkeit, diesen auch problemlos auf dem Entwicklerrechner starten zu können, sein "Hot Deployment" und seine leichte Konfigurierbarkeit, machen ihn für alle Phasen eines Softwareprojekts interessant. Auch die Möglichkeiten der JMX- und Web-Konsole zum Monitoring des JBoss und der EJB-Anwendung möchte man schnell nicht mehr missen.

Zukunft

Wir werden Sie auch zukünftig an dieser Stelle auf dem Laufenden halten. Interessant wird vor allem ein Vergleich mit den kommerziellen Wettbewerbsprodukten von IBM, Oracle oder BEA. Natürlich informieren wir Sie in Zukunft auch, was Programmierung und Administration solcher Applikationsserver betrifft. Wer darauf aber nicht warten möchte, meldet sich einfach direkt bei uns unter info@ordix.de.

Seitenanfang

Seite drucken

Seite weiterempfehlen