J and I and Me
2007-04-23
  JAX Spring Day - Spring OSGi - Martin Lippert, Gerd Wütherich, Bernd Kolb
Dieser Vortrag hat - nicht ganz zu unrecht - den Untertitel "Plattform der Zukunft". Er beginnt mit einer Einführung in OSGi. OSGi ist ein dynamisches Modul-System für Java. Ein Modul (genannt Bundle) besteht aus mehreren Packages. Es gibt Abhängigkeiten zwischen den Modulen und Module können versioniert sein. Außerdem kann man bestimmte Teile der Bundles (public API) exportieren und damit die Sichtbarkeiten einschränken. So kann man zum Beispiel die Implementierungs-Klassen verbergen und nur die Interfaces exportieren. Dadurch kann man das Chaos, das sonst im Classpath leicht herrscht, lösen.

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: , , ,

 
Bookmark and Share


<< Home
J for Java | I for Internet, iMac, iPod and iPad | Me for me

ARCHIVES
Juni 2005 / Juli 2005 / August 2005 / September 2005 / Oktober 2005 / November 2005 / Dezember 2005 / Januar 2006 / Februar 2006 / März 2006 / April 2006 / Mai 2006 / Juni 2006 / Juli 2006 / August 2006 / September 2006 / Oktober 2006 / November 2006 / Dezember 2006 / Januar 2007 / Februar 2007 / März 2007 / April 2007 / Mai 2007 / Juni 2007 / Juli 2007 / August 2007 / September 2007 / Oktober 2007 / November 2007 / Dezember 2007 / Januar 2008 / April 2008 / Mai 2008 / Juni 2008 / August 2008 / September 2008 / November 2008 / Januar 2009 / Februar 2009 / März 2009 / April 2009 / Mai 2009 / Juni 2009 / Juli 2009 / August 2009 / September 2009 / Oktober 2009 / November 2009 / Dezember 2009 / Januar 2010 / Februar 2010 / März 2010 / April 2010 / Mai 2010 / Juli 2010 / August 2010 / Oktober 2010 / Januar 2011 / Februar 2011 / März 2011 / April 2011 / Mai 2011 / Juni 2011 / August 2011 / September 2011 / November 2011 / Februar 2012 / April 2012 / Mai 2012 / April 2013 / Mai 2013 / Juni 2013 / Januar 2015 / Juli 2015 / Februar 2016 /

Links

Twitter
Google +
Slideshare
Prezi
XING
LinkedIn
Das Spring Buch


Feeds

Feedburner


Impressum
Betreiber und Kontakt:
Eberhard Wolff
Leobschützer Strasse 22
13125 Berlin
E-Mail-Adresse: eberhard.wolff@gmail.com

Verantwortlich für journalistisch-redaktionelle Inhalte:
Eberhard Wolff