JBoss ist ein sehr weit verbreiteter Application Server, der eigentlich nicht explizit vorgestellt werden muss. Fast jeder hatte irgendwann mal was damit zu tun. (Streng genommen ist JBoss kein Application Server, sondern Name einer Produktfamilie. Genauso wie WebSphere eigentlich kein spezifisches Produkt bezeichnet. Ich werde mir die Struktur der Produktfamilie in einem anderen Blog vornehmen)
Grundsätzlich gibt es die frei verfügbare Version von JBoss und die kostenpflichtige Fassung rund um JBoss EAP (Enterprise Application Plattform). Die freie Version ist EAP quasi immer einen technologischen Schritt voraus. Ein Blick auf JBoss AS 7 zeigt also was in EAP 6 kommen könnte. Da JBoss beim Wechsel auf Version 7 keinen evolutionären sondern einen revolutionären Schritt gemacht hat, möchte ich die wichtigsten Unterschiede hier zusammenfassen.
Es fängt damit an, dass AS7 praktisch komplett neu entwickelt wurde. Die etablierten Bausteine (z.B. Microcontainer) wurden ersetzt und durch eine grundsätzlich andere Architektur ersetzt. Zentraler Unterschied der neuen Architektur ist der modulare Aufbau, dank dem Komponenten erst bei Bedarf gestartet werden. In Profilen kann definiert werden, welche Komponenten anfänglich gestartet werden.
Das Modulsystem nennt sich JBoss Modules und ist ein eigenständiges Projekt, welches auch für andere Projekte eingesetzt werden kann (es geht in die Richtung der für Java 7 versprochenen Modullösung (JSR 294), welche nun bis Ende 2012 als Teil von Java 8 verschoben wurde). Unter Modul wird eine Komponente verstanden, die mit eigenen Ressourcen und Klassen daher kommt und Abhängigkeiten zu anderen Modulen hat. Diese Abhängigkeiten definieren, welche Funktionalitäten von Modul B Modul A sehen kann. Dies entspricht quasi einem 5. Visibility Level in Java, also einer Steigerung von 'public'. Dieser Ansatz löst massenweise Probleme: die Startup-Zeit und der memory footprint wurden massiv verringert. Viel wichtiger ist, dass Module jeweils mit eigenem ClassLoader kommen und die mühseligen ClassPath-Problematiken der Vergangenheit angehören.
JBoss 7 unterstützt Hibernate, Weld, Mojarra und viele weitere opensource Standards. JBoss 7 bietet JavaEE6 Support (Web-Profile; Full Profile folgt in 7.1 später dieses Jahr).
Eine weitere, gut sichtbare Änderung ist das neue GWT-basierte Admin-GUI. Es lässt sich darüber streiten, ob ein solches GUI notwendig war; aber besser aussehen tut's auf jeden Fall ;-)
Neu unterstützt JBoss AS 7 zwei Betriebsmodi: standalone und domain. Stand-alone entspricht ungefähr der bisherigen Betriebsweise. Dabei laufen alle Komponenten (Host Controller und einer oder mehrere managed Application Server auf derselben Maschine). Ein Deployment besteht aus dem Kopieren des WAR-Files nach /standalone/deployments. Dieses Verzeichnis wird vom Deployment Scanner überwacht. Via Filename-Anpassungen wird über den (Miss-)Erfolg von Deployments informiert (neue File-Endung '.deployed' oder '.failed'). Domain unterstützt die Verwaltung mehrerer gemanagte Server (auch auf unterschiedlichen Maschinen). Neben HC und AS kommt bei Domain auch noch ein Domain Controller zum Einsatz, der die einzelnen HCs überwacht. Die einzelnen Application Server werden üblicherweise in Servergruppen zusammengefasst, die betriebliche Funktionen haben (z.B. Test, Integration, Produktion). Diese Servergruppen können mehrere physikalische Server belegen. Applikationen werden in eine Domain geladen und können dann in den verschiedenen Umgebungen deployed werden (Achtung: Konfigurationsdetails wie DB, Log-Settings, ...). Ein Deployment via File copy ist nicht mehr möglich.
Eine weitere spannende Möglichkeit ist die Integration von JBoss in Unit und Integration Tests. Während in vielen Fällen Unit-Tests gar keinen laufenden Application Server mehr benötigen (Stichwort: POJO), gibt es doch noch einige Fälle in denen ein solcher notwendig wäre. Häufig scheitert es daran, dass "professionelle" Application Server nicht sinnvoll in Tests integriert werden können, da sie zu lange zum Starten brauchen, man nicht die entsprechenden Einstellungen mitgeben kann oder eine Integration in einen Testlauf einfach nicht machbar ist. Natürlich gibt es die Möglichkeiten Jetty für gewisse Tests einzubinden, aber der verhält sich wahrscheinlich leicht anders als das System, welches produktiv zum Einsatz kommt. Kurz: man will auf dem Server testen, welcher am Ende des Tages produktiv zum Einsatz kommen wird.
Last but not least, gibt es in JBoss 7 eine Kommandozeile (bin/jboss-admin.sh) für die Administration ohne WebGUI. Mittels Batch-Blöcken lassen sich mehrere Änderungen in einer Transaktion ausführen, um den Server nicht 'unterwegs' in inkonsistente Zustände zu bringen.