Was gibt es uns also? Zum Beispiel Management der Sichtbarkeit von Services: EIn Bundle ist eine Black Box, man kann nicht hineingucken, auch nicht mit Reflection oder Class-Loading-Tricks. Also muss man explizit entscheiden, welche Packages man exportiert, auch optional mit Versionierung. Dadurch kann man Anwendungen grobgranular aufteilen z.B. in MVC-Bundles, Service-Bundles, Repository-Bundles usw. Die kann man dann individuell updaten und neue hinzufügen. Und man kann auch mehrere Versionen gleichzeitig aktiv haben.
Für den Betrieb kann man alle Bundles sehen und über die OSGi-Console adminstrieren. Man kann zur Laufzeit neue Typen haben oder Services.
Ein Bundle ist im wesentlichen ein JAR. Es hat kein komplexes Packaging, die Konfiguration ist einfach in META-INF/MANIFEST.MF . Es gibt Support für das Build und Bundling nutzten in Maven 2. Mit Export-Package kann man besimmte Pakages exportieren. Um welche zu nutzen, muss man Import-Package verwenden. Per Default bekommt man dann die neuste Version dieser Package. Man kann auch Packages als optional markieren.Die Bundles haben einen einfachen Lifecycle. Beim Aktivieren kann man mit einem Bundle-Activator definieren, welcher Code beim Startup ausgeführt wird. Außerdem zeigte Adrian die API der Service Registry.
OSGi ist eine gute Basis für Enterprise-Anwendungen - aber es sollte einfach sein. Innerhalb eines Bundles gibt es feingranulare Komponenten, die zusammengebracht werden müssen und zum Beispiel dekoriert werden müssen. Und auch de Services, die von Bundles angeboten werden, müssen irgendwie zugreifbar sein - und man muss irgendwelche Dinge als Serivces exortieren. Und man muss OSGi-Komponenten in Servern wie Tomcat, WebSphere, WebLogic oder Oracle Application Server.
Dann übernahm Costing Leau, der Spring-OSGi-Chef-Entwickler. Ziel ist es, die Vorteile von OSGi einfach für Enterprise-Anwendungen zur Verfügung zu stellen. Mit Spring sollen die Bundles konfiguriert werden, d.h. die Aufteilung in Bundles sollte änderbar sein. Es soll außerdem helfen, Services anzubieten oder zu verwenden. Spring-OSGI soll daher ein POJO-Programmiermodell auf Basis von OSGi bieten. Neben Interface21 sind auch BEA und Oracle Committer. Es gibt außerdem Input von der OSGi-Alliance, von BEA, Oracle und IBM sowie Eclipse Equinox oder Felix.
Die Module des Spring-Frameworks werden als OSGi-Bundles installierbar sein. Mit dem OsgiApplicationContext gibt es einen speziellen ApplicationContext für OSGi. Dieser bietet zum Beispiel die Möglichkeit, Ressourcen mit den richtigen Techniken einzulesen. Außerdem gibt es passende Aware-Interface zum Beispiel für den Bundle Context. Der ApplicationContext kann deklarativ erzeugt werden, d.h. man muss ihn nicht explizit erzeugen.
Bundles können in einer beliebigen Reihenfolge installiert werden. Dabei kann es passieren, dass ein Bundle erstmal warten muss, bis ein anderes Bundles zur Verfügung steht. Erst wenn die Abhängigkeiten zur Verfügung stehen, wird die Anwendung starten. In diesem Prozess werden keine Threads blockiert.
Es ging dann um Service Dynamics. Services können aktiviert werden und verschwinden - was tut man dann? Wie sieht der Code dafür aus? Zunächst kann man Services einfach durch eine Deklaration exportieren. Analog kann man auch Services als POJOs importieren. Das ist im Prinzip dasselbe wie ein Exporter und eine ProxyFactoryBean für eine Technologie wie Hessian. An den References zu den Services kann man auch definieren, an wieviele Instanzen man sich binden will. Wenn man mehrere Instanzen eines Service hat, findet automatisches Rebindung statt, d.h. wenn eine Instanz ausfällt, wird automatisch eine andere genutzt. Hier gibt es auch noch spannende Probleme: Wenn man mehrere Service-Instanzen hat, muss man eine Collection verwenden, der dynamisch Elemente hinzugefügt oder entfernt werden können - weil sich eben die Mege der Services ändert. Sowas gibt es im JDK nicht, was ein Problem ist. Außerdem gibt es ja zustandsbehaftete Services - wie geht man damit um? Wenn die Instanz ausfällt, muss man dann etwas tun. Dazu kann man einen Listener definieren, der aufgerufen wird, wenn ein Service auftaucht oder entfernt wird. Dieser Listener kann auch ein POJO sein, es muss nur Methoden haben, die passende Parameter übernehmen.
OSGi hat einige definierte Services wie Logging zum Beispiel. Aus der Administrations-Konsole kann man zum Beispiel auch Konfiguration dynamisch ändern, was dann in die Spring-Konfiguration eingeführt werden können.
Im Bereich des Testing gibt es das Problem, dass die Bundles und der OSGi-Container gestartet werden muss, was dauern kann. Es gibt daher den ConfigurableBundleCreatorTests, der den OSGi-Container startet usw. Innerhalb des Tests kann man zum Beispiel Maven-Dependencies in dem OSGi-Container installieren lassen.
Wie geht es weiter? Erstmal wird 1.0 releast. Dann gibt es Web-Support mit Spring MVC und Spring Web Flow Support, also erst nach 1.0. Ein weiteres Thema ist die Integration von Repositories wie zum Beispiel mit Maven oder Ivy. Natürlich soll es dann noch enge JMX-Integration geben, um zum Beispiel Komponenten dynamisch hinzuzufügen oder zu entfernen.
In der Zusammenfassung sprach Adrian noch über Class-Loading-Probleme zum Beispiel mit Hibernate und es gibt eine OSGi-Enterprise-Expert-Group, die OSGi für typische Enterprise-Szenarien und damit Spring-Szenarien optimieren soll.
Labels: Adrian Colyer, Costin Leau, Spring, Spring-OSGi, SpringOne
¶ 11:04
