serverseitiges OSGi

Java EE Komponentenbasierte Geschäftsanwendungen und EAI mit Java EE
Java SE Java Grundlagen
EJB Enterprise Java Beans
Servlets & JSP Webbasierte Anwendungen mit Servlets und JSP
JCA Resource Adapter EIS Integration mit Resource Adapter
JPA Java Persistence API Persistenz mit Java
AWT und Swing Entwicklung moderner grafischer Oberflächen
WebServices Serviceorientierte Architekturen mittels WebServices
Konfiguration mit Ant, Eclipse und Subversion
Architektur Entwurf und Pflege tragender Architekturen
Eclipse Runtime Plugin-basiertes Entwicklungsmodell mit der Eclipse Runtime

Einleitung
Classloading
Server Profiling
Server Clustering
Java EE Module
JNDI Ressourcen
OSGi im Server
Internationalisierung
Logging

OSGi

Beinahe axiomatisch lässt sich der Nachweis erbringen, dass saubere Architekturen nicht ohne Dependency Injection auskommen. Architekturen, die Dependency Injection realisieren, lassen sich leicht selber bauen oder sind als Frameworks in großer Vielfalt mit jeweils unterschiedlichen Fokus umgesetzt. Komplizierter wird es, wenn man Modularisierung in großen, heterogenen Teams betreibt. Hier muss man für die einzelnen Module ein Dependency- und Lifecyclemanagement etablieren und technisch unterstützen. OSGi ist ein speziell für Java entwickelter Standard, der das leistet.

Offene OSGi Implementierungen gibt es reichlich. Die momentan populärste ist vielleicht Eclipse Equinox, nicht zuletzt weil die Eclipse IDE und Eclipse RCP auf dieser Implementierung basiert. Es ist aber nicht die einzige wie folgende Tabelle zeigt:

Produkt	Beschreibung
Eclipse Equinox	große Popularität, weit verbreitet, Basis für Eclipse RCP und Eclipse IDE und ProSyst Open Source mBedded Server
Apache Felix
FUSE ESB 4	OSGi kompatible ESB Implementierung
Knopflerfish	offener OSGi Kernel mit prof. Support für kommerzielle Produkte
Newton Project

Darüber hinaus wird mit dem JSR-291 der Versuch unternommen, OSGi in den Java Standard zu integrieren.

Java EE EJB und OSGi

Laut EJB Spezifikation erfolgt die Modularisierung auf Basis der EJB Komponenten und ist damit eher fachlich getrieben. Der EJB Container ist aus diesem Grund praktisch nicht mit OSGi zu verheiraten. Generell sind zwei Ansätze denkbar, es dennoch zu versuchen:

Jede EJB wird ein OSGi Kernel. So könnte man wenigstens für jede EJB separat eine Modularisierung umsetzen. Aus gutem Grund besitzt eine EJB nur sehr eingeschränkte Möglichkeiten, mit ihrer Umgebung zu interagieren. Eine OSGi Implementierung ohne Manipulation des Classloaders, ohne Nebenläufigkeit, ohne lokale Leserechte etc. ist jedoch aussichtlslos.
Der EJB Container ist gleichzeitig ein OSGi Kernel. Nichts liegt näher, jedoch bedeutet eine solche Umsetzung die Abkehr von der EJB Spezifikation. So ist beispielsweise nicht denkbar, dass ein EJB Container gleichzeitig und ohne Widerspruch EJB konform Deploymentdeskriptoren und OSGi konform Plugindeskriptoren verarbeiten kann. Auch ist nicht zu vernachlässigen, dass Java EE Spec und OSGi ganz unterschiedliche Problemsphären adressieren (die eine eher fachliche, das andere eher technische).

Java EE Webtier und OSGi

Für Java EE Webcontainer sind zufällig OSGi konforme Lösungen möglich. Im Java EE Webcontainer gibt es keine spezifizierte fachliche Modularisierung, zusätzlich genießen Servlets in ihrer Umgebung wesentlich mehr Rechte als die Beans im EJB Container (der Classpath ist bekannt und kann untersucht werden, Leserechte für Ressourcen der Webanwendung). Auch hier kann man zwei Ansätze unterschieden:

Ein Servlet übernimmt die Rolle des OSGi Kernels.
Der Webcontainer wird OSGi konform und Java EE konform implementiert.

Beide Ansätze werden gegenwärtig von der Eclipse Community als Server-Side Equinox untersucht.

Referenzen

Sun JCP JSR-291 (Dynamic Component Support for Java SE – OSGi R4.1)
OSGi Alliance
Server-Side Equinox