Über OSGi wurde in letzter Zeit viel geschrieben und diskutiert. Zurecht, denn die Idee dahinter scheint ein für die Praxis tragfähiges Konzept zu sein: Software lässt sich in Komponenten aufteilen und läuft in Form so genannter Bundles in einem OSGi-konformen Container. Dieser wiederum ist in der Lage, Bundles in verschiedenen Versionen zu verwalten, Abhängigkeiten aufzulösen und sogar einzelne Bundles zur Laufzeit auszutauschen.
Den Ritterschlag erhielt OSGi vermutlich mit seinem Einsatz im Eclipse-Projekt, durch die Implementierung Equinox. Doch dass OSGi auch im Serverbereich, also im Umfeld von JEE, interessant sein kann, das ist ein neuer Trend. Denn gerade beim Einsatz von OSGi auf Serverseite tun sich ganz neue Möglichkeiten auf: Wurden früher JEE-Anwendungen in Form monolithischer EAR- oder WAR-Archive in den entsprechenden Applikationsserver deployt, so lassen sich diese Anwendungen heutzutage mithilfe von OSGi modularisieren und, in Komponenten aufgeteilt, als Bundle oder Satz von Bundles einspielen.
Das eher knorrige EAR- oder WAR-Archiv wird also aufgeweicht, und Einzelkomponenten daraus können zur Laufzeit, ohne dass die Anwendung gestoppt werden muss, ausgetauscht werden. Entsprechende Integration diverser Servlet-Container wie Tomcat oder Jetty in OSGi-Laufzeitumgebungen ist bereits heute verfügbar. Produkte wie der Spring dm Application Server zeigen klar, in welche Richtung wir uns bewegen.
Axis2 und Abhängigkeiten müssen als Bundles vorliegen
Um ebenfalls am aufkommenden OSGi-Markt vertreten zu sein, entschloss man sich, das Axis2-Projekt ebenfalls in Form von OSGi-Bundle(s) auszuliefern. Und obwohl diese Bemühungen gerade erst gestartet wurden, kann man bereits heute erste Ergebnisse sehen und sogar ausprobieren. Einen Haken hat die Sache allerdings noch: Sämtliche Ressourcen (Sourcen, Bundles etc.) muss man sich derzeit selbst mithilfe von Maven bauen. Hierzu muss man zunächst den Axis2-Quellcode mittels Subversion auschecken und einen entsprechenden Build-Prozess starten, an dessen Ende das Axis2-Bundle (org.apache.axis2.osgi.jar) entsteht. Damit ist es allerdings noch nicht getan, denn Axis2 besitzt einige Abhängigkeiten zu externen Bibliotheken, die natürlich ebenfalls in Form von Bundles vorliegen müssen. Hierzu gehören Bibliotheken wie AXIOM und Commons Logging. Einige dieser Bibliotheken liegen glücklicherweise schon als OSGi-Bundle in Maven-Repositories vor, andere müssen wiederum selbst in ein OSGi-konformes Format gebracht werden. Tabelle 1 fasst alle abhängigen Bibliotheken zusammen und zeigt außerdem, welche Bibliothek bereits als OSGi Bundle verfügbar ist. Für diejenigen Bibliotheken, die noch nicht als Bundle zur Verfügung stehen, gibt es ebenfalls die Möglichkeit, mithilfe von Maven einen entsprechenden Build-Prozess zu starten, der die Bundles dann erzeugt. Eine detaillierte Beschreibung zum Build-Prozess findet sich unter anderem hier.
| Bibliothek | Bundle verfügbar | Bundle in Maven2 Repository verfügbar |
|---|---|---|
| Commons Logging | Nein | Nein |
| Servlet API | Nein | Nein |
| Annogen | Nein | Nein |
| Ant | Nein | Nein |
| Axiom | Ja | Nein |
| Commons Codec | Nein | Nein |
| Commons File Upload | Nein | Nein |
| Commons HttpClient | Nein | Nein |
| Geronimo StaX | Ja | Ja |
| Geronimo WS-Metadata | Ja | Ja |
| HttpCore | Nein | Nein |
| Neethi | Ja | Nein |
| WSDL4J | Nein | Nein |
| WSTX-ASL | Nein | Nein |
| XmlSchema | Ja | Ja |
| Commons IO | Nein | Nein |
| Xml APIs (Xerces) | Nein | Nein |
| Wooden | Ja | Nein |
| Geronimo Javamail | Ja | Ja |
| Geronimo Activation | Ja | Ja |
| DOM4J | Nein | Nein |
| Jaxen | Nein | Nein |
Tabelle 1: Abhängige Bibliotheken zum Betrieb von Axis2 in OSGi, die Abhängigkeiten müssen ebenfalls als Bundles vorliegen (Quelle: Axis2 SVN-Repo und SVNApache.org)
