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.
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:
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.
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.
Alle Rezensionen aus dem Linux-Magazin
Im Insecurity Bulletin widmet sich Mark Vogelsberger aktuellen Sicherheitslücken sowie Hintergründen und Security-Grundlagen. mehr...
