Java EE 6 Web Profile

EJB 3.1 Lite

Was kann man machen, wenn man nicht auf die – gerade wieder liebgewonnen – Enterprise Java Beans verzichten möchte, gleichzeitig aber von deren Komplexität zur Entwicklungs- und Laufzeit erschlagen wird? Man definiert ein Subset mit den wichtigsten, unverzichtbaren Funktionen und nennt dieses EJB Lite. So oder so ähnlich kann man sich das Vorgehen der EJB Expert Group vorstellen, als über eine effizientere Verwendung von EJBs im Webumfeld nachgedacht wurde. Die Idee ist so einfach wie sinnvoll: Alles was im EJB-Umfeld nicht mit lokaler oder synchroner Kommunikation zu tun hat, gilt als potenzieller Streichkandidat der Lite-Version. Hinzu kommen noch alle APIs, die lediglich aus Gründen der Abwärtskompatibilität Bestandteil der EJB-3.1-Spezifikation sind. Als Resultat ergibt sich eine sehr schlanke EJB-Lösung, wie Abbildung 2 zeigt.

Abb. 2: EJB 3.1 Lite

Ausgangspunkt der Überlegungen ist dabei, dass die wenigsten Webanwendungen remote via EJB kommunizieren und in der Regel auch keine Message-driven Beans, EJB Timer oder durch EJBs zur Verfügung gestellte Web Services benötigen werden. Positiv ausgedrückt geht die EJB Expert Group davon aus, dass die meisten modernen Webanwendungen mit lokalen, synchron aufgerufenen Session Beans (Stateful, Stateless und Singleton), Interceptoren, Container- bzw. Bean-managed Transaktionen sowie deklarativer bzw. programmativer Security auskommen.

WAR statt JAR

Wie bereits weiter oben beschrieben, ist das EJB Lite Subset nur einer von zwei Faktoren auf dem Weg zum gewünschten „Lightway Runtime Environment“. Der zweite Faktor ist zwar auch Bestandteil der EJB-Spezifikation, hat aber weniger etwas mit Technologie als vielmehr mit einem neu unterstützen Packaging-Format für EJBs zu tun. War ein EJB-Entwickler bisher gezwungen, seine EJBs exklusiv in einem ejb-jar-Modul zu verpacken, bietet sich seit Java EE 6 zusätzlich die Möglichkeit an, EJBs direkt innerhalb eines Web Archives zu deployen. In beiden Fällen ist übrigens der ejb-jar.xml Deployment Descriptor (DD) aufgrund der deutlich vereinfachten EJB-3.1-Struktur optional. Möchte man innerhalb eines Webarchivs einen solchen DD nutzen, muss dieser zum Zeitpunkt des Deployments unter WEB-INF/ejb-jar.xml zu finden sein. Die Enterprise-Java-Beans-Klassen selbst werden vom Container direkt in WEB-INF/classes oder als Library (.jar) verpackt in WEB-INF/lib erwartet (Abb. 3).

Abb. 3: Java-EE-6-Deployment-Szenarien

Enterprise Java Beans, die als Libraries innerhalb des WEB-INF/lib-Verzeichnisses deployt werden, sollten nicht mit den eigenständigen EJBs innerhalb eines klassischen ejb-jar Modules verwechselt werden. Während die Originalvariante ein eigenständiges Java-EE-Modul darstellt und u. a. einen eigenen Modulnamen und Namespace definiert, dient das Web Profile EJB .jar lediglich zur besseren Strukturierung und ist semantisch gleichzusetzen mit einem direkten Deployment der EJB-Klassen innerhalb des WEB-INF/classes-Verzeichnisses.

Die reale Welt

Soweit die Theorie. Aber wie sieht es in der Praxis aus. Einen wirklichen Nutzen bringt das neue Web Profile natürlich nur dann, wenn entsprechende Server zur Unterstützung bereitstehen. Derzeit gibt es diese durch verschiedene Anbieter. Mit Oracle’s Glassfish (inklusive Glassfish embedded) steht beispielsweise ein TCK-zertifizierter Container zur Verfügung. Andere Hersteller wie Red Hat (JBoss AS 6), Apache (Geronimo Version 3.0 (Milestone 1)) oder Caucho (Resin 4.x) sind noch nicht ganz so weit. Auch sie bieten bereits Lösungen an, diese sind aber noch nicht zertifiziert.

Apache goes Java EE 6

Die 3.x-Linie des Apache Geronimo ist ganz auf Java EE 6 ausgerichtet. Seit dem Sommer gibt es ein erstes Milestone-Release. Dieser M1 enthält bereits einige Feature des Java EE Web Profiles, allerdings wurde das TCK noch nicht bestanden. Das liegt zum einen daran, dass einige (wichtige) Komponenten fehlen:

  • Context and Dependency Injection for the Java EE Platform und Java Dependency Injection (JSR 299/330)
  • BeanValidation (JSR 303)
  • ManagedBean (JSR 318)

Daneben wird EJB 3.1 nicht vollständig unterstützt, weil der verwendete OpenEJB Container noch weitgehend auf EJB-3.0-Basis läuft. Die Apache OpenEJB-Community arbeitet aber fleißig an einer EJB-3.1-Version. Das bedeutet allerdings nicht, dass ein WAR-File keine EJBs enthalten darf: Mit dem praktischen, aber nicht ganz Java-EE-5-konformen Collapsed-EAR-Konzept, lässt sich auch diese Tücke bereits seit Langem meistern. Der Download enthält, wie gewohnt, zwei Varianten des Application Servers: mit Jetty8 oder Apache Tomcat 7 als verwendete Servlet Engine. Die frühe Version des Geronimo eignet sich nicht unbedingt zum Einsatz in der Produktionsumgebung, allerdings bietet sie gute Möglichkeiten, sich mit den Neuerungen von Apache Geronimo 3.x vertraut zu machen.

JBoss Application Server 6

Auch Red Hat ist voll auf Java EE 6 ausgerichtet, was nicht sonderlich überrascht, denn schließlich war dessen JBoss Division federführend bei der Realisierung des JSR-299. Der JBoss Application Server in der Version 6 ist seit kurzem verfügbar. Interessant ist hier die Tatsache, dass das Hauptaugenmerk derzeit voll auf dem Web Profile liegt. Das default Profile des JBoss AS 6 stellt die Basis dafür bereit. Allerdings kommen neben den klassischen Biblitoheken noch ein paar nützliche Spezifikationen wie JAX-RS oder JMS zum Einsatz. Wichtig ist zu beachten, dass das jbossweb Profile nichts mit dem Java EE Web Profile zu tun hat. Ein vollständiger Java EE Container wird durch das standard Profile angeboten. Dieses JBoss Profile stellt daher im eigentlichen Sinne das historische JBoss standard Profile dar. Die Zeichen bei Red Hat stehen schon in Richtung JBoss AS 7. Das interessante an diesem JBoss Reloaded Server ist, dass er neugeschrieben wird und interessante Erweiterungen wie einen embedded container enthält. Die innovative Ausrichtung bei JBoss Reloaded lässt stark vermuten, dass auch hier das Java EE Web Profile ein Zuhause findet.

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.