BEA über Spring
In
diesem Post schreibt Andy Piper, einer der Köpfe hinter BEA WebLogic, seine Meinung zu Spring und gibt Gründe dafür, warum BEA an Spring und Spring-OSGi interessiert ist. Letztendlich geht es darum, dass man mit Spring ein technologie-unabhängiges Programmiermodell hat - was gerade bei innovativen Ansätzen jenseits des "offiziellen" Java EE ein kaum zu überschätzender Vorteil ist.
Labels: Andy Piper, BEA, Spring, Spring-OSGi
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: Adrian Colyer, Costin Leau, Spring, Spring-OSGi, SpringOne
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: JAX, Spring, Spring Day, Spring-OSGi
