OSGi Grundlagen

---

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 (siehe dazu OSGi Wikipediaartikel). Darüber hinaus wird mit dem JSR-291 der Versuch unternommen, OSGi in den Java Standard zu integrieren.

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