J and I and Me
2007-06-22
  SpringOne: OSGi, a New Foundation for Enterprise Apps
Adrian Colyer (CTO von Interface21) sprach dann über OSGi. OSGi ist die Open Service Gateway Initiative. Es definiert Bundles mit fest definierten Sichtbarkeiten und sie können Services anbieten. Die Services werden in der Service Registry registriert und man kann sich an sie binden. Services können zur Laufzeit neu hinzukommen und auch wieder verschwinden. OSGi kommt von der OSGi Alliance. Es kommt eigentlich aus dem Embedded Bereich und war daher leichtgewichtig und dynamisch von Anfang an. Open Source Implementierung sind Equinox (als Basis von Eclipse), Felix (Apache) und Knoplerfish. Neben Eclipse benutzt IBM es in WebSphere und Lotus. BEA und Oracle sowie JOnAS sind darauf basiert. BEA und Oracle hat Committer im Spring OSGi Projekt.

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

 
Bookmark and Share
Comments:
Erstmal vielen Dank für Deine ausführlichen Reports von der SpringOne. Das nächste mal bin ich hoffentlich dabei.

Nun meine Frage: Haben Costin oder Adrian irgendwas zu dem konkreten Zeitplan von Spring-OSGi erzählt? Wann kommt 1.0, wann Web-Support?
 
Danke für dsa Feedback!

Nein, konkrete Termin haben sie nicht genannt. Spring OSGi ist in 1.0M2 und sollte sehr bald draußen sein. Web kommt in 1.1, an das sich Costin dann gleich nach macht, d.h. es sollten dann auch schnell zur Verfügung stehen.
 
Kommentar veröffentlichen

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