Abb. 2: Die Orion Admin-Console.

Während manche Zeitgenossen freiwillig und nur für begrenzte Zeit einen Container aufsuchen, können EJBs nur innerhalb von Containern leben. Anhand von drei Beispielen zeigen wir, wie die Container installiert werden und wie eine Beispielanwendung darin konfiguriert wird.

Im letzten Coffee-Shop ging es um die Programmierung von EJBs. Die nötigen Klassen für eine Entity-Bean wurden dabei vorgestellt und diskutiert. Wer genau gelesen hat, war vielleicht verwundert, wo denn die Main-Methode geblieben ist. Die Antwort ist einfach: Keine Bean implementiert eine Main-Methode. Das ist gewissermaßen ein Paradigmenwechsel zur klassischen Programmierung. Während dort der Entwickler das Hauptprogramm unter der Zuhilfenahme von Bibliotheken schreibt, schreiben EJB-Autoren die Bibliotheken. Das Hauptprogramm ist der EJB-Container.

Wo ist das Hauptprogramm?

Auch wenn die meisten Anwendungen aus einer ganzen Sammlung von EJBs bestehen, behandelt doch der Container jede Bohne als eigenes Objekt. Es muss mit dem erwähnten Deployment-Descriptor beschrieben werden, damit der Container weiß, was damit zu tun ist. Die große Anzahl der verfügbaren Container-Implementationen sollte dabei nicht darüber hinwegtäuschen, dass ein EJB-Container ein hochkomplexes Programm ist. Ein kleines Beispiel soll dies erläutern.

Ein Container ist die Heimat möglicherweise sehr vieler Bohnen von unterschiedlichen Herstellern. Wenn es auch Namenskonventionen für Package- und Klassennamen gibt, besteht durchaus die Gefahr, dass es hier Überschneidungen gibt. Außerdem sollte eine fehlerhafte Bohne nicht den gesamten Container herunterziehen.

Dieser Artikel will sich aber nicht mit den Problemen beschäftigen, einen guten EJB-Container zu schreiben. Wer daran Interesse hat, sollte sich in eines der Open-Source-Projekte einklinken. Mir geht es vielmehr darum, anhand von drei Beispielen zu zeigen, wie man eine Applikation in einem Container installiert und betreibt. Zur Auswahl stehen drei Container:

• JBoss, ein Open-Source-Container, der schon kurz im vorletzten Linux Magazin vorgestellt wurde (siehe [1]).
• Der Orion Application Server, ein kommerzieller Server, dessen Anwendung für nicht kommerzielle Projekte kostenlos ist.
• Enhydra Enterprise 4, ebenfalls Open Source, das Nachfolgeprodukt des bekannten Enhydra-Applikations-Servers (siehe [2]).

Die Container sind mit Ausnahme von Enhydra prinzipiell sowohl mit dem JDK 1.2.2 als auch mit dem JDK 1.3 zu benutzen. Doch gibt es unter Linux ein kleines Problem mit dem JDK 1.2.2. In dieser Version gab es die Klasse javax.rmi.PortableRemoteObject noch nicht. Die Methode narrrow() dieser Klasse ist aber notwendig, um mit dem RMI-IIOP-Protokoll übertragene Objekte in einen vorgegebenen Typ umzuwandeln ( narrow() ist gewissermaßen ein verallgemeinerter Typ-Cast). IIOP ist ein vom CORBA-Standard bekanntes Protokoll. Die untersuchten Container verwenden zwar nur klassisches RMI, so dass man ohne PortableRemoteObject auskäme, aber dann wäre der Code nicht portabel.

Wer unbedingt mit dem JDK 1.2.2 unter Linux arbeiten will, muss basteln. Die J2EE-Edition des JDK für Linux stellt die entsprechende Klasse bereit, man muss sie nur aus dem Jar-Archiv j2ee.jar extrahieren. Die Sache ist aber nicht ganz einfach, da eine Reihe weiterer Klassen benötigt wird. Aus meiner Sicht lohnt der Aufwand jedoch nicht, da es inzwischen ja drei Versionen des JDK 1.3 (von Blackdown, Sun und IBM) gibt.

Wer die Download-Mühen nicht scheut, sollte aber trotzdem das J2EE-SDK für Linux herunterladen, denn darin ist nicht nur eine Referenzimplementation eines kompletten J2EE-kompatiblen Servers (einschließlich EJB-Containers) enthalten, sondern auch eine Reihe nützlicher Tools sowie eine ausführliche Dokumentation und Beispiele.

Der Testparcour

Jeder Server muss sich den Disziplinen Download, Dokumentation, Installation, Konfiguration, Entwicklung und Betrieb stellen. Der Punkt Entwicklung meint dabei, wie der Entwickler/Deployer bei der Installation seiner Bohnen unterstützt wird. Beim Betrieb interessieren dagegen einerseits die Managementfunktionen, andererseits auch Möglichkeiten wie Hot-Deployment.

Als Versuchsobjekt dient dabei die Beispielanwendung, also das Raumreservierungssystem (siehe [3]). Anwendung ist dabei fast schon zu viel gesagt. Zur Entity-Bean aus dem letzten Coffee-Shop ist eine Reihe weiterer Beans gekommen, so dass zwar prinzipiell inzwischen die Unterstützung der grundlegenden Business-Logik existiert, aber zu einer Anwendung fehlt aber noch einiges.

Die Bohnen (mehrere Entity-Beans und Session-Beans) verwenden eine Reihe von Funktionalitäten, die nicht im EJB-Standard 1.1 definiert sind (besonders eigene finder-Methoden im Home-Interface), so dass auch die Unterschiede in den Container-Implementationen sichtbar werden.

Aussagen zur Performance sind dagegen sehr schwer zu machen. Das Beispiel enthält zwar Testprogramme, die auch jeweils eine Zeitmessung durchführen. Aber schon diese Testprogramme zeigen, dass eine effiziente Programmierung (etwa Session-Beans statt Entity-Beans) mehr herausholt als die Container. Außerdem prüfen sie jeweils genau eine Funktionalität, so dass keine Aussagen über das Verhalten im Allgemeinen (bei wechselnden Zugriffen auf verschiedene Beans von unterschiedlichen Clients aus etc.) möglich sind.

JBoss

JBoss (Download über [4]) lag mir für die Tests in der Version 2.0-Final vor. Inzwischen gibt es im CVS auch die Version 2.1Pre, beim Erscheinen des Artikels ist diese Version vielleicht schon verfügbar.

JBoss enthält nicht alle vom J2EE-Standard vorgeschriebenen Komponenten, an einer Integration wird aber Stück für Stück gearbeitet. Will man die EJBs über Webseiten (insbesondere JSPs oder über Servlets) ansprechen, bietet sich der Download eines JBoss/Tomcat- oder JBoss/Jetty-Bundles an.

Wer Tomcat bereits auf seiner Festplatte hat, kann auch JBoss getrennt herunterladen, das Paket ist dann 3,5 MByte groß. Ich muss allerdings zugeben, dass ich es nicht geschafft habe, den Tomcat im Embedded-Modus innerhalb von JBoss zum Laufen zu bringen, so dass es wahrscheinlich doch besser ist, sich das Bundle zu holen.

Die Dokumentation, die mit JBoss auf den Schreibtisch kommt, ist sehr mager. Auf der JBoss-Website gibt es allerdings eine große Anzahl HOWTOs und Einführungen, so dass letztlich alle Infos verfügbar sind, die man sucht. Leider fehlt eine Möglichkeit alle Dokumente gesammelt herunterzuladen, so dass dabei ziemlich viel geklickt werden muss. Die bessere Alternative ist es daher, gleich zu Wget zu greifen.

Eine weitere sehr nützliche Dokumentationsquelle sind die Archive der Mailinglisten. Sich in diese Listen eintragen zu lassen sollte gut überlegt sein, da hier sehr viel los ist und dann Unmengen von Mails eintrudeln. Andererseits ist das natürlich auch das Merkmal für eine sehr aktive und hilfsbereite Community mit allen Vorzügen.

01: <jboss>
02:   <enterprise-beans>
03:     <entity>
04:       <ejb-name>Room</ejb-name>
05:       <jndi-name>rrsystem/Room</jndi-name>
06:     </entity>
07:     <session>
08:       <ejb-name>RoomManager</ejb-name>
09:       <jndi-name>rrsystem/RoomManager</jndi-name>
10:     </session>
11:     <entity>
12:       <ejb-name>IDGenerator</ejb-name>
13:       <jndi-name>rrsystem/IDGenerator</jndi-name>
14:     </entity>
15:     <entity>
16:       <ejb-name>Reservation</ejb-name>
17:       <jndi-name>rrsystem/Reservation</jndi-name>
18:     </entity>
19:   </enterprise-beans>
20: </jboss>

Installation und Konfiguration

Die Installation von JBoss beschränkt sich auf das Auspacken des komprimierten Tar-Archivs. Im Unterverzeichnis bin findet sich dann das Startskript run.sh, das leider von diesem Verzeichnis aus aufgerufen werden muss. Die Konfiguration selbst befindet sich in dem Unterverzeichnis conf/default, und über die Datei jboss.conf können verschiedene Aspekte des Containers eingestellt werden, etwa die oben erwähnte Tomcat-Integration.

Die Konfiguration geschieht über so genannte MBeans, das sind standardisierte Komponenten für das Management von Java-Anwendungen (innerhalb des Java Management Extension-Frameworks, kurz JMX, definiert). JBoss verwendet hier also modernste Technologie.

Als Datenbank nutzt JBoss standardmäßig die Pure-Java-Datenbank Hypersonic. Allerdings existieren Mappings für eine Reihe weiterer Datenbanken, selbst für eher exotische Vertreter wie DB2/400. In einer produktiven Umgebung würde ich mit Sicherheit zuerst die Datenbank-Schicht austauschen – letztlich eine Sache von wenigen Minuten. Für eine Entwicklungsumgebung ist der Default aber nicht schlecht, da der Ressourcenverbrauch von Hypersonic sehr gering ist.

Abb. 1: Der EJX-Editor von JBoss.

Entwickeln mit JBoss

Neben einem EJB-1.1-konformen Container bietet JBoss nur wenige Tools zur Unterstützung des Entwicklers. Es gibt zwar einen XML-Editor (EJX – Enterprise Java XML-Editor, siehe Abbildung 1) für den Deployment Descriptor (DD), aber der Status ist eher als frühes Betastadium zu bezeichnen. Einige interessante Funktionalitäten sind aber implementiert, so können Jar-Archive direkt gelesen werden und der Editor verifiziert die Angaben gegen die im Archiv vorhandenen Klassen.

Meine persönliche Erfahrung ist allerdings, dass ein grafisches Tool für die Erstellung des Deployment Descriptors nicht notwendigerweise die Produktivität steigert. Mit Hilfe eines leistungsstarken Editors kopiert man sich nämlich aus einem Beispiel einen eigenen DD schneller zusammen als mit einer GUI, in der man sich durch zig Menüs und Panels arbeiten muss.

Neben den durch den EJB-Standard vorgegebenen Angaben im DD (der Datei ejb-jar.xml) sind in jeder Umgebung noch herstellerspezifische Konfigurationen notwendig, insbesondere die Definition der JNDI-Namen und der Datenbankmappings. Für JBoss sind dafür zwei weitere XML-Dateien zu erstellen: jboss.xml enthält Container-spezifische Informationen, während jaws.xml das Mapping für die Datenbank und die Definition der finder-Methoden enthält.

Beide Dateien werden wie ejb-jar.xml in das META-INF-Verzeichnis des Jar-Archivs kopiert. Die Dateien müssen nur die Angaben enthalten, die vom Standard abweichen, und sind deshalb recht kompakt. In den Listings 1 und 2 sind die entsprechenden Dateien aus dem Beispiel aufgeführt. Die Struktur ist dabei bewusst an das DD-Format angelehnt, die in den Dateien definierten EJB-Namen müssen natürlich übereinstimmen.

Der Betrieb eines JBoss-Servers

Hat man die EJB-Klassen und -Interfaces geschrieben sowie die drei beschreibenden XML-Dateien erzeugt, muss man nur noch ein Jar-Archiv erzeugen. Dies wird dann einfach in das Unterverzeichnis deploy kopiert. Das ist auch bei einem laufenden JBoss-Server möglich – als so genanntes Hot Deployment. Man erhält dann eine Reihe von Meldungen (welche Beans aus dem Jar-Archiv wurden installiert) über den Fortgang des Deployments.

Die Datenbank-Tabellen werden automatisch angelegt, wenn man es in der Datei jaws .xml nicht anders definiert hat. War die Anwendung schon einmal installiert, wird sie durch die neuere Version ersetzt. Der Inhalt der alten Tabellen wird dabei übernommen, falls dies ohne Konflikte möglich ist. Alles in allem ein einfacher und gradliniger Vorgang, der genau tut, was man erwartet.

Ein laufender, leerer JBoss-Server hat einen vergleichsweise geringen Memory-Footprint von 17 MByte (gemessen mit dem JDK 1.3 des Blackdown-Ports). Stabilitätsprobleme sind bei mir nie aufgetreten. Neben diesen positiven Aspekten gibt es aber auch einige Schattenseiten beim Betrieb. So fehlt momentan die Möglichkeit zum Clustern von JBoss-Servern (zumindest gibt es keine Informationen darüber). Selbst eine so eine einfache Aktion wie das saubere Herunterfahren des Servers ist unmöglich.

Das oben erwähnte Shell-Skript run.sh dient zum Starten des Servers. Nach einem Skript für das geordnete Herunterfahren habe ich aber vergeblich gesucht. Letztlich habe ich im Unterverzeichnis client die Datei stop.jar gefunden und mit etwas Ausprobieren auch die richtigen Aufrufparameter entdeckt. Damit lässt sich der Server aber nur fast komplett herunterfahren, vor einem Neustart müssen die übrig gebliebenen Prozesse etwa mit einem killall java beendet werden. Laufen außer JBoss noch andere Java-Prozesse, wird die Sache noch deutlich komplizierter.

Auch das Management des laufenden Servers ist nur rudimentär gelöst. Es gibt ein per Web-Schnittstelle zu bedienendes Management-Interface, das aber wahrscheinlich nur von den Autoren der entsprechenden MBeans wirklich verstanden wird.

Am Schluss bleibt ein gemischtes Gefühl: Auf der einen Seite modernste Technologie und ein stabiler Server. Denkt man aber an einen produktiven Betrieb, so gibt es doch gravierende Bedenken gegen einen Einsatz. Schön wäre es, wenn bei der künftigen Entwicklung weniger auf neue Features – die vorhandenen reichen für viele Einsatzgebiete aus – als auf die Verwendbarkeit in realen Situationen geachtet würde.

Orion Application Server

Der Orion Application Server der Firma Evermind, verfügbar über [5], ist ein kommerzielles Produkt. Damit tritt er prinzipiell gegen die Produkte der großen Konkurrenten an, die in aller Regel über ein besseres Marketing als kleinere Firmen verfügen. Umso wichtiger ist es für deren Produkte, durch Qualität zu überzeugen. Und diese Frage steht auch im Mittelpunkt der Untersuchung.

Der Preis von Orion ist fast lächerlich niedrig für den kommerziellen Bereich. Momentan werden 1500 US-Dollar pro produktivem Server verlangt. Als Vergleich: Für den Preis kann man sich noch nicht mal zwei Tage Software-Entwicklung leisten. Entwicklerlizenzen sind kostenlos, auch das ist eher unüblich bei kommerziellen Produkten. Und auch für den nicht kommerziellen Einsatz muss man nichts bezahlen.

Für die Tests stand die Version 1.4.5 zur Verfügung. Da aber offensichtlich das Produkt sich in stetiger Entwicklung befindet, wird die aktuelle Version beim Erscheinen des Artikels schon weiter sein. Der Download schlägt mit 4,9 MByte zu Buche, ein umfangreiches Dokumentationspaket enthält weitere 5,2 MByte. Dort sind auch alle API-Dokumentationen sowie Spezifikationen rund um J2EE zu finden. Mir persönlich wäre es lieber, wenn diese Teile getrennt zur Verfügung stünden, da ich sie sowieso auf meinem Rechner habe. Andererseits hat das Komplettpaket den Vorteil, alle Dokumente sauber verlinkt zu bekommen.

01: <jaws>
02:   <enterprise-beans>
03:     <entity>
04:       <ejb-name>Room</ejb-name>
05:       <finder>
06:         <name>findWithMinSize</name>
07:         <query>iSize >= {0}</query>
08:         <order>iSize</order>
09:       </finder>
10:     </entity>
11:     <entity>
12:       <ejb-name>Reservation</ejb-name>
13:       <finder>
14:         <name>findByUser</name>
15:         <query>iUser = {0}</query>
16:         <order>iStart DESC</order>
17:       </finder>
18:       <finder>
19:         <name>findByUserAndDate</name>
20:         <query>iUser = {0} AND iStart >= {1} AND iStart <= {2}</query>
43:     </entity>
44:   </enterprise-beans>
45: </jaws>

Installation und Konfiguration

Nach dem Download entpackt man als Root die Archive an geeigneter Stelle und führt das Installationsskript aus. Da Orion offensichtlich auf einem FAT-System entwickelt wird, ist dabei etwas Nacharbeit nötig:

cd /opt
unzip ~/orion-1.4.5.zip
unzip ~/orion-1.4.5-doc.zip
mv orion orion-1.4.5
ln -s orion-1.4.5 orion
cd orion
java -jar orion.jar -install
ln -s $JAVA_HOME/lib/tools.jar tools.jar
find . -type d -exec chmod +x {} ;

Das Skript fragt nach dem Passwort des Server-Administrators admin. Das findet sich dann in der Datei config/prinzipals.xml im Klartext wieder. Bei den obigen Befehlen sind natürlich der mv– und ln-Befehl nicht wirklich notwendig, doch habe ich gerne im Dateinamen auch die Versionsnummer, und ein symbolischer Link erlaubt das einfache Wechseln von verschiedenen Versionen.

Um die Installation abzuschließen, muss noch die Datei config/default-web-site.xml editiert werden. Dort bietet es sich an, den Port des eingebauten Webservers von 80 auf einen anderen Wert zu ändern und auch den Ort des Logs dem File-Hierarchy- Standard gemäß auf var/log/orion/ default-web-access.log zu setzen. Damit ist die grundlegende Konfiguration abgeschlossen und der Server wird mittels

java -jar orion.jar

gestartet. Wenn alles geklappt hat, ist die Default-Seite jetzt unter http:// localhost:8080/ abrufbar.

Wenn auch Orion analog zu JBoss in wenigen Minuten betriebsbereit ist, lohnt sich doch ein Blick in die ausführliche Dokumentation. Viele weitere Aspekte des Servers sind konfigurierbar und für ein produktives System ist es sicher sinnvoll, hier etwas Arbeit zu investieren.

Eine weitere wichtige Informationsquelle sind die Orion-Support-Webseiten (siehe [6]). Dort gibt es eine Reihe von HOWTOs, auch darüber, wie man Orion sinnvollerweise unter Linux laufen lässt (nämlich nicht als Root. ;-) Auch findet sich dort ein Start/Stop-Skript für den Einsatz während der Systeminitialisierung.

Abb. 2: Die Orion Admin-Console.

Orion als J2EE-Server

Orion ist als J2EE-kompatibler Server ausgelegt. Für die Entwickler bedeutet dies, dass es nicht wie bei JBoss genügt, eine Jar-Datei mit den Klassen und dem DD ejb-jar.xml zu erstellen, man braucht komplette J2EE-Applikationen. Details dazu kommen in der nächsten Folge dran, hier nur so viel, dass eine Applikation aus mehreren Modulen besteht, typischerweise EJB-Archiven, Web-Archiven und/oder Client-Archiven. Jedes Archiv wird durch seine eigene XML-Datei beschrieben, ebenso wie die gesamte Applikation. Ein Beispiel ist in Listing 3 zu sehen.

Web-Anwendungen werden natürlich über einen Browser gestartet, der die in den Web-Archiven vorhandenen Servlets ausführt. Für den Start von Anwendungen in den Client-Archiven liefert Orion das Programm applicationlauncher.jar mit. Damit lässt sich eine Anwendung von jedem beliebigen Rechner aus starten.

Die Vorteile liegen auf der Hand: Die Anwendungen müssen nicht auf die Clients verteilt und installiert werden, und außerdem kann man die Security-Mechanismen des Servers verwenden, ohne diese in den Client hineinprogrammieren zu müssen. Für die Erstellung der EJBs und der einzelnen Archive liefert Orion eine Reihe von Tools mit, die aber von unterschiedlicher Qualität sind. Auch hier gilt dasselbe wie bei JBoss: Mit einem Editor ist man schneller.

Analog zu den Dateien jboss.xml und jaws.xml gibt es bei Orion die Datei orion-ejb-jar.xml. Sie wird, falls nicht vorhanden, bei einem Deployment automatisch erstellt. Man verwendet die beim ersten Deployment erstellte Version und passt sie für seine eigenen Zwecke an.

In Listing 4 ist ein Ausschnitt zu sehen. Die Datei enthält alle Informationen, die JBoss auf zwei Dateien verteilt. Letztlich ist das Geschmacksache, ich empfinde aber die JBoss-Dateien als übersichtlicher.

Betreiben eines Orion-Servers

Auch für den Betrieb gibt es eine Reihe von Tools, alle in Java geschrieben und als ausführbare Jar-Dateien mitgeliefert. Zum Teil sind es Swing-Applikationen, wie die grafische Admin-Console (siehe Abbildung 2), die auch eine Remote-Administration erlaubt.

Anwendungen können auch bei laufendem Server deployed werden, allerdings geschieht dies nicht so einfach wie bei JBoss, wo es ein schlichter cp-Befehl tut. Bei Orion erfolgt das Deployment über das Programm admin.jar oder die Konsole.

Weitere wichtige Funktionalitäten in einem kommerziellen Umfeld wie etwa Clustering, SSL-Unterstützung, HTTP-Tunneling oder Virtual-Hosting sind verfügbar und dokumentiert. Als Datenbanken können alle JDBC-konformen Implementationen genutzt werden. Mitgeliefert werden aber deutlich weniger Mappings als bei JBoss, doch ein Mapping für eine eigene DB ist in kürzester Zeit erstellt. Beim Speicherbedarf schneidet dagegen Orion noch etwas besser ab als JBoss.

Im direkten Vergleich mit JBoss ist Orion für den produktiven Einsatz momentan besser geeignet. Trotzdem bleibt ein ungutes Gefühl angesichts der Tatsache, dass der Quellcode nicht verfügbar ist. Zu oft ist es vorgekommen, dass eine kleine Firma mit hochgradigen Spezialisten aufgekauft wurde. Dabei ging es den Käufern nicht um das Produkt, sondern um das Know-how der Mitarbeiter. Das Produkt blieb dabei nicht selten auf der Strecke.

Enhydra Enterprise 4

Die Firma Lutris, die ursprünglich den Enhydra Application Server entwickelt hatte, ist im Vergleich zu Evermind einen Schritt weiter. Sie stellte den Server unter eine freie Lizenz, die Open Public License (OPL). Dadurch entwickelte sich eine rege Community, die an verschiedenen Projekten innerhalb des Enhydra-Frameworks arbeitet.

Der ursprüngliche Enhydra Application Server, aktuell in der Version 3.1, enthält schon viele Komponenten, die analoge Funktionalitäten wie die EJBs bereitstellen. Mit der Version 4 kommt es zu einer grundlegenden Anpassung des Designs, um konform mit den durch die J2EE-Standards vorgegebenen Richtlinien zu sein. Enhydras Ansatz für einen J2EE-konformen Server spielt die Vorteile von Open Source voll aus: Wieso das Rad neu erfinden, wenn funktionierende Lösungen vorhanden sind? So integriert Enhydra den EJB-Container von JOnAS (siehe [7]) und den Webcontainer Tomcat aus dem Apache-Jakarta-Projekt.

Für den Test habe ich die Version 4alpha4 genommen, obwohl laut Mailingliste eine neuere Version kurz vor der Veröffentlichung steht (aber leider stimmen die Release-Termine von SW-Projekten nicht immer mit den Redaktionsschluss-Terminen des Linux Magazins überein). ;-)

Der Download des Tgz-Archivs von [8] dauert seine Zeit, insgesamt sind fast 15,5 MByte zu übertragen. Damit ist Enhydra das größte der hier untersuchten Pakete. Ausgepackt sind es 45 MByte, von denen Dokumentation und Beispiele 27 MByte beanspruchen. Die Release-Notes geben Auskunft über implementierte und fehlende Funktionen. Bei Letzteren sind vor allem JavaMail/JAF, Security und der Deployment-Server zu nennen. Damit wird klar, dass die aktuelle Version nicht für einen produktiven Einsatz zu gebrauchen ist.

Der Grund, warum ich Enhydra trotzdem in diesen Vergleich einbeziehe, ist die Vision von Enhydra, die über die beiden anderen Produkte deutlich hinausgeht. Wer hier an Details interessiert ist, sollte sich das White-Paper auf der Enhydra-Site ansehen.

06: <application>
07:   <display-name>Room Reservation System</display-name>
08:   <module>
09:     <ejb>rrsystem.jar</ejb>
10:   </module>
11:   <module>
12:     <web>
13:       <web-uri>rrsystem.war</web-uri>
14:       <context-root>/rrsystem</context-root>
15:     </web>
16:   </module>
17:   <module>
18:     <java>rrsystem-cli.jar</java>
19:   </module>
20: </application>

Installation und Konfiguration

Installation und Betrieb von Enhydra setzen die Java-Version 1.2.2 voraus. Ds hängt mit der verwendeten Version des EJB-Containers JOnAS zusammen. Nach dem Entpacken wird Enhydra mittels

cd enhydra4.0a4
./configure $JAVA_HOME

konfiguriert (wenn die Variable JAVA _HOME vorhanden ist, sonst muss man das richtige Verzeichnis von Hand angeben). Das configure-Skript trägt in die Startskripte innerhalb von bin die entsprechenden Pfade der Enhydra-Installation sowie des JDK ein. Zudem wird unter conf/servlet die Datei servlet.conf angepasst.

Nach erfolgter Installation wird der Enhydra-Kernel (der so genannte Multiserver) über

cd enhydra4.0a4/bin
./multiserver

gestartet. Nach einiger Zeit (man braucht etwas Geduld) kann die Web-basierte Admin-Console, die sich gegenüber der 3.1-Version nicht wesentlich geändert hat, über http://localhost:8001/ erreicht werden.

001: <orion-ejb-jar>
002:   <enterprise-beans>
003:     <entity-deployment name="Room" location="rrsystem/Room" table="Room">
004:       <ejb-ref-mapping location="rrsystem/Room" name="ejb/rrsystem/Room" />
005:       <finder-method query="$1 <= $iSize ORDER BY $iSize">
006:         <method>
007:           <description>
008:             Find all rooms at least the size of the argument
009:           </description>
010:           <ejb-name>Room</ejb-name>
011:           <method-name>findWithMinSize</method-name>
012:           <method-params>
013:             <method-param>int</method-param>
014:           </method-params>
015:         </method>
016:       </finder-method>
017:     </entity-deployment>
018:
019:     <session-deployment name="RoomManager" location="rrsystem/RoomManager">
020:       <ejb-ref-mapping
021:    location="rrsystem/RoomManager" name="ejb/rrsystem/RoomManager" />
022:     </session-deployment>
023:
099:   </enterprise-beans>
100: </orion-ejb-jar>

Entwicklungstools

Enhydras Schwerpunkt lag stets bei funktionierenden Entwicklungstools. Das ist auch bei der Enterprise-Version nicht viel anders, wie schon an der Alpha-Version zu erkennen ist. Spezielle Tools für EJBs sind aber noch nicht vorhanden, also kommen die JOnAS-Tools zum Zuge.

Mit Kelp steht ein Tool bereit, das die Entwicklung von Enhydra-Anwendungen aus dem JBuilder heraus ermöglicht. CodeGen ist ein Tool, das sowohl als Swing-Anwendung als auch über die Kommandozeile genutzt werden kann, um das Grundgerüst einer Anwendung aufzubauen. Gerade dieses Tool ist sehr nützlich, da es ohne viel Schnickschnack eine sinnvolle Verzeichnishierarchie samt der nötigen Makefiles erzeugt.

Die EJB-Konfiguration erfolgt über die Datei jonas-ejb-jar.xml. Diese Datei enthält zwar etwas andere Tags als die jboss.xml/jaws.xml-Dateien bei JBoss oder die orion-ejb-jar.xml bei Orion, doch grundlegende Unterschiede gibt es nicht, weshalb ich hier auf einen Abdruck verzichte.

Das Deployment sieht aber etwas anders aus, da JOnAS kein Hot-Deployment vorsieht und auch Enhydra hier noch keinerlei zusätzliche Unterstützung bietet. Die Container-Klassen werden bei Enhydra aus den Makefiles heraus mit Hilfe des JOnAS-Tools GenIC erzeugt.

In so frühem Stadium ist zum allgemeinen Betrieb wenig zu sagen. Ein paar Ansätze sind erkennbar: Enhydra setzt wie JBoss auf JMX. Bei der Konfiguration der Funktionalitäten ist aber XML noch nicht überall vertreten. Gefallen hat mir das schon in Enhydra 3 vorhandene Web-Interface für das Management des Servers.

finally{}

Eine abschließende Bewertung fällt schwer. JBoss glänzt mit technologischen Finessen, Orion mit seinem Funktionsumfang, Enhydra bereits jetzt mit umfassender Dokumentation und einer Reihe sinnvoller Tools. Aber jeder Server hat auch seine Schwächen. Besonders das Fehlen des Quellcodes bei Orion bewerte ich – in der heutigen Zeit – als Manko.

Wer einen Server produktiv einsetzen will, sollte entweder JBoss nehmen und bereit sein, zusammen mit dem Systemadministrator etwas zu basteln, oder konsequent auf den J2EE-Standard setzen und Orion wählen. Es gibt aber noch Alternativen, zum Beispiel JOnAS ohne Enhydra.

EJB-Server werden immer wieder als Web-Application-Server verstanden, doch bis jetzt fehlte gerade der Web-Teil. Der J2EE-Standard sieht hierfür etwas lapidar Java-Server-Pages zusammen mit Taglibs vor. Doch für die schnelle Entwicklung von Web-Anwendungen braucht es Frameworks, die die Sache für uns Entwickler vereinfachen. Thema der nächsten Folge sind daher ein paar Lösungen, die genau das versprechen. Einen Schwerpunkt bilden dabei die MVC-orientierten Toolkits. ( uwo)