JBoss AS6: Treffen der sechsten Generationen

Mehr Flexibilität dank JSF-Deployer

Zwar konnte bereits ab der vierten Generation nachträglich auf JSF 2.0 [3] aufgerüstet werden, ganz problemlos ging das allerdings nicht über die Bühne. Im JBoss AS6 ist nun sowohl die Referenzimplementierung Mojarra in der Version 2.0.3 bzw. 1.2.15 als auch Apache MyFaces 2.0.1 enthalten. Dass jetzt gleich mehrere JSF-Implementierungen in beliebigen Versionen parallel im Applikationsserver eingesetzt werden können, und das nicht wie bisher in Bastelei ausartet, sondern sauber getrennt vonstatten geht, ist dem neu geschriebenen JSF-Deployer [4] zu verdanken, der im Verzeichnis

psenv::pushli(); eval($_oclass[„JBOSS_HOME“]); psenv::popli(); ?>

/server/./deployers/jsf.deployer anzutreffen ist und sich dort durch Anpassung der im Unterverzeichnis META-INF abgelegten Datei jsf-integration-deployer-jboss-beans.xml konfigurieren lässt. Zu jeder JSF-Konfiguration wird ein Schlüssel definiert, über den diese bei Bedarf in der web.xml referenziert werden kann. Zur Ausführung der Webanwendung wird dann genau diese JSF-Konfiguration verwendet. Das folgende Beispiel zeigt den relevanten Ausschnitt aus der web.xml, um die Nutzung von Mojarra 1.2 als JSF-Implementierung in Verbindung mit seiner Webanwendung festzulegen:

org.jboss.jbossfaces.JSF_CONFIG_NAMEMojarra-1.2

Neben JSF 2.0 gelangt jetzt auch Servlet 3.0 [5] zum Einsatz, wodurch sich die Servlet-Entwicklung deutlich vereinfacht. Servlet-Klassen können nun ebenfalls annotiert werden und es gibt von Haus aus Unterstützung für die asynchrone Verarbeitung von Anfragen. Des Weiteren lässt sich mittels so genannter Webfragmente die web.xml modular aufbauen.

Keine Einschränkungen bei EJB 3.1

In der 5er-Version konnte der JBoss-Nutzer bereits auf einen EJB-3.0-konformen Container zurückgreifen. Da die Web-Profile-Spezifikation EJB 3.1 Lite vorschreibt, war zu deren Erfüllung eine Weiterentwicklung vonnöten. Die Programmierer haben in Sachen EJB-Container sogar eine Fleißaufgabe gemacht, denn es wird nicht nur die geforderte, abgespeckte Lite-Version geboten, sondern ein vollwertiger EJB-3.1-Container mit all den neuen Features [6]. Als die wichtigsten davon lassen sich nennen:

  • Eine EJB kann mittels @Singleton annotiert werden, wodurch sichergestellt wird, dass zur Laufzeit maximal eine Instanz erzeugt wird. Mittels der Annotationen @Startup und @DependsOn können die Objekt-Erzeugung bei der Initialisierung der Anwendung erzwungen sowie eine Startreihenfolge unter allen Singletons festgelegt werden.
  • Eine Methode einer EJB kann mittels @Asynchronous annotiert werden, wodurch der Client nach dem Aufruf dieser Methode sofort die Kontrolle zurückerhält und nicht bis zur Beendigung der Methode blockiert wird. Die Ergebnisse solcher asynchronen Methodenaufrufe können vom Client in der Java-typischen Art und Weise, und zwar über ein Objekt, welches das Interface Future implementiert, ausgewertet werden.
  • Eine Methode einer EJB kann mittels @Schedule als zeitgesteuert annotiert werden und wird dann zu den spezifizierten Aufrufterminen ausgeführt.
  • Um das Unit-Testen zu vereinfachen, kann ein EJB-Container neuerdings eingebettet erzeugt und verwendet werden.

Bei der Persistierung von Objekten kann sich der Entwickler dank des von JBoss selbstgestrickten Hibernate 3.6.0 nun JPA 2.0 [7] bedienen. Diese Schnittstelle glänzt durch mehr Flexibilität bei der Modellierung, weist Verbesserungen in Sachen Beziehungen auf und bietet dem Entwickler beim Locking jetzt auch das pessimistische Sperrverfahren an. Neben der Erweiterung des Query-API um typsichere Klassen und Methoden ist insbesondere noch das neue Criteria-Query-API zu erwähnen.

Die Bean Validation [8] ermöglicht, dass die Konsistenzbedingungen für ein Objekt direkt in der zugehörigen Klasse annotiert werden können. Eine Validierung gegen sie kann dann zur Laufzeit auf unterschiedlichen Systemschichten erfolgen. Im neuen JBoss AS gelangt als Implementierung der Hibernate Validator 4.1.0 zum Einsatz.

Qual der Wahl bei Abhängigkeiten

Die Dependency Injection hat wohl gute Chancen, bei einer Wahl des bedeutendsten Entwurfsmusters der letzten Jahre ganz oben auf dem Treppchen zu landen. Diese Wichtigkeit hat man auch in der Java-Welt erkannt, und so schreibt die Java-EE-6-Web-Profile-Spezifikation ihren Plattformen gleich drei sich teilweise sogar überschneidende Standards zur Bereitstellung vor: Managed Beans, DI und CDI [9]. Wenig überraschend setzt der JBoss AS6 in Verbindung mit der Dependency Injection auf die CDI-Referenzimplementierung aus dem eigenen Hause, nämlich Weld in der Version 1.1.0 (CR1).

Als die beiden wichtigsten Annotationen lassen sich @Inject und @Named nennen. Erstere definiert eine Injektionsstelle innerhalb einer Bean, die zweite Annotation stellt die damit versehene Bean unter einem bestimmten Namen bereit.

CXF ersetzt native Implementierung

Mit der 5er-Version seines Applikationsservers führte JBoss einen Web-Service-Stack namens JBossWS-Native ein, der die Spezifikation des Java API for XML Web Services (JAX-WS) 2.0 [10] erfüllte. Im neuen JBoss AS steht jetzt eine weitere JAX-WS-Implementierung zur Verfügung. Es handelt sich dabei um JBossWS-CXF 3.4.1, das auf Apache CXF basiert und im JBoss AS6 standardmäßig als Web-Service-Stack installiert ist. Versprochen wird eine verbesserte Performance sowie die Unterstützung von noch mehr WS-*-Features [11]. Für bisher funktionierende Deployments von Web-Service-Endpunkten ist laut JBoss keine Migration erforderlich. Jene sollten also ohne Änderung auch im JBoss AS6 lauffähig sein.

Kommentare

Schreibe einen Kommentar

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