Module können dynamisch zur Laufzeit installiert, gestartet, gestoppt, deinstalliert und aktualisiert werden. Dadurch gibt es natürlich Probleme, wenn man zum falschen Zeitpunkt auf ein Modul zugreift, zum Beispiel wenn es deinstalliert ist.
OSGi definiert außerdem Services. Bundles können die Services veröffentlichen oder ihn verwenden. Die Services können zur Laufzeit kommen und gehen.
OSGi wird seit 1999 von der OSGi-Alliance betreut. Es hat seinen Fokus auf Leichtgewichtigkeit und Dynamik. Es war früher für Embedded Systeme gedacht, mittlerweile wird es auch für Client- und Server-Systeme genutzt. Es gibt verschiedene Implementierung, so Eclipse Equinox, Apache Felix, Knopflerfish, ProSyst mBedded Server Equinox Edition. Kommerzielle Implementierung gibt es von ProSyst und Knopflerfish Pro.
OSGi wird heute schon bei Eclipse genutzt, bei Server-Side Eclipse und bei eRCP. IBM nutzt es bei WebSphere Application Server 6.1, beim Lotus Notes Client und bei Jazz (Team-Kollaborations-Unterstützung für Eclipse). BEA und Oracle sind interessiert. JBoss hat einen Prototyp für eine OSGi-Umstellung. Und auch Adobe baut an solchen Sachen. Außerdem gibt es einen JSR, der OSGi in der Java-7-Plattform integrieren will.
Spring-OSGi ist eine Brücke zwischen Spring und OSGi. Spring-Anwendungen können dann mit OSGi implementiert werden. Es unterstützt Equinox, Felix und Knopflerfish. Dabei soll man die dynamischen Features von OSGi nutzen können. Spring selber muss man dann auch in OSGi-Bundles aufteilen.
Dabei darf sich die Komplexität nicht erhöhen, es sollte beim POJO-Programmiermodell bleiben. Außerdem muss das OSGi-Service-Modell integriert werden: Spring-Beans sollten zu Services werden können und umgekehrt. Und Testing außerhalb des OSGi-Containers muss natürlich auch möglich sein. Und man muss natürlich auch alle anderen Spring-Features nutzen können.
Bundles haben dabei jeweils einen eigenen ApplicationContext. Der wird von Spring-OSGi beim Aktivieren des Bundles automatisch erzeugt und beim Deaktivieren zerstört. Die Konfiguration liegt im Bundle (einem JAR oder Verzeichnis) im Unterverzeichnis META-INF/spring. Die Spring-Beans können mit dem osgi-XML-Namespace als OSGi-Service exportiert werden und die Services können auch in Spring importiert werden. Dadurch kann man den eigenen Code - schon fast traditionell bei Spring - von der OSGi-API unabhängig halten. Außerdem kann man so "public" Spring-Beans, die als OSGi-Services exportiert werden, und "private" Spring-Beans definieren.
Da OSGi dynamisch ist, kann man mit einem Service-Listener auf das Hoch- oder Runterfahren eines Services reagieren. Und auch Zugriff auf Properties aus einem OSGi-Bundle oder Zugriffe auf Bundles sind machbar.
Es schloss sich ein Beispiel an. Ein OSGi-Bundle ist ein Order-Service, der andere ein Customer-Service. Die haben beide ein einfaches Java-Interface als Schnittstelle. Man kann sie auf der OSGi-Konsole installieren, starten, monitoren usw. Und man kann natürlich die Implementierung zur Laufzeit gegen eine andere austauschen. Die Bundles kann man auch über das Internet herunterladen.
Spring-OSGi 1.0M1 wurde am 5.4.2007 veröffentlicht. Es enthält den osgi-XML-Namespace. Es unterstützt auch die Integrations-Tests. Es fehlt Unterstützung für Web-Anwendungen und es gibt einige Probleme mit ClassPath-Problemen. Das Release soll dann zusammen mit Spring 2.1 kommen.
Man kann mit Spring-OSGi Standalone-Server-Applikatione bauen. Er läuft dann auf Basis von OSGi und kann Jetty als Http-Service und Servlet-Container enthalten. Oder man deployt OSGi als Teil des WARs. Eine Servlet-Bridge sorgt dann dafür, dass Requests an die "richtigen" Bundles weitergeleitet werden.
In beiden Fällen werdne die Anwendungen aus Bundles zusammengesetzt. Spring kann inklusive Remoting usw. genutzt werden. Auch auf dem Client (Eclipse RCP) kann man Spring verwenden. Also zum Beispiel kann man dann Dependency Injection für die Extension Points verwenden und damit Views injecten.
In einem aktuellen Projekt benutzten sie Equinox in einem produktiven System. Der Client basiert auf Eclipse-RCP und Spring. Der Server nutzt Spring und OSGi innerhalb von Tomcat.
Labels: JAX, Spring, Spring Day, Spring-OSGi
¶ 10:19
