Generisches Ressourcenmodell

OSGi at your Service


Viele kennen OSGi als eine dünne Schicht über Java, um modulare Software zu entwickeln. OSGi übernimmt dabei die Prüfung, ob Abhängigkeiten einzelner Module in sich konsistent sind und das System somit wie gewünscht funktioniert. Ein Blick hinter die Kulissen, wie OSGi Abhängigkeiten beschreibt, lohnt sich allemal.

Dieser Artikel zeigt, wie OSGi auf Basis des generischen Requirement-and-Capability-Modells Abhängigkeiten zwischen Bundles beschreibt. Konzepte wie OBR (OSGi Bundle Repository), Resolving und Provisioning werden in der OSGi-Welt immer wichtiger. Finales Ziel ist, dass OSGi auf Basis dieses Modells alle Abhängigkeiten erkennt und mittels definierter Bundle Repositories automatisch installiert. Auf Resolving und Provisioning wird in diesem Artikel nicht eingegangen. Details hierzu folgen in den nächsten Artikeln dieser Serie.

Artikelserie

Teil 1: Generisches Ressourcenmodell. Beschreibung von Abhängigkeiten auf Basis des Requirement-and-Capability-Modells

Teil 2: Requirement-Capability-Modell unter Verwendung der Resolver- und Provisioning-Spezifikation

OSGi in Kürze

OSGi basiert auf der Grundidee, Java-Applikationen in Module zu unterteilen. Jedes dieser Module (Bun­dle genannt) kapselt Funktionen. Ein Bundle wird durch seinen Symbolic Name und die Version eindeutig bestimmt. Im Gegensatz zu herkömmlichen JAR-Files definiert ein Bundle Schnittstellen.

Aufgrund von Einträgen im MANIFEST.MF definiert ein Bundle, welche Java-Packages nach außen sichtbar sein sollen. Ebenfalls muss ein Bundle definieren, welche sichtbaren Java-Packages es von anderen Bundles konsumieren möchte. Auf den ersten Blick scheint dies etwas umständlich. Es ergibt bei genauerer Betrachtung allerdings sehr viel Sinn. Durch diesen Mechanismus erkennt OSGi, welche Java-Packages zur einwandfreien Ausführung eines Bundles benötigt werden. Benötigt Bundle A bspw. das Package org.foo, das von OSGi jedoch nicht gefunden werden kann, wird Bundle A nicht korrekt ausgeführt, und OSGi reagiert mit einem Fehler darauf.

Die Definition von Abhängigkeiten erfüllt noch einen weiteren Zweck: Laut Java-Spezifikation darf eine Klasse nur einmal von einem Classloader geladen werden. Im klassischen SE-Ansatz, in dem die Context-Klassen immer vom gleichen Classloader geladen werden, bedeutet das, dass eine Klasse, die einmal geladen wurde, nicht wieder ausgetauscht werden kann. Die OSGi-Spezifikation umgeht dieses Problem, indem jedes Bundle seinen eigenen Classloader verwendet und Klassen ei...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang