OSGi-Architektur

Die Kernkomponente von OSGi Service Platform definiert eine sichere und verwaltete Serviceplattform, die auf Java™ basiert. Diese Plattform unterstützt die Implementierung erweiterbarer und für den Download verfügbarer Anwendungen, die Bundles genannt werden. Die Spezifikation definiert ein Sicherheitsmodell, ein Verwaltungsmodell für den Anwendungslebenszyklus, eineService-Registry, eine Ausführungsumgebung und Module.

OSGi definiert ein dynamisches Modulsystem für Java. Die Kernkomponente von OSGi Service Platform hat eine geschichtete Architektur und wurde für die Ausführung mit verschiedenen Java-Standardprofilen entworfen. Mit OSGi wird das Konzept eines Bundles als modulare Einheit eingeführt. Die Plattformarchitektur basiert auf den Bundles, die die Implementierungseinheit darstellen. Die OSGi-Architektur setzt sich aus den folgenden Schichten zusammen:
Ausführungsumgebungsschicht
Modulschicht
Lebenszyklusschicht
Service-Registry-Schicht
Weitere Informationen zur OSGi-Architektur finden Sie unter Core OSGi service platform specification.

Ausführungsumgebungsschicht

Die Ausführungsumgebungsschicht gibt die Java-Umgebung an (zum Beispiel Java EE oder Java SE), in der ein Bundle ausgeführt wird. Sie müssen für OSGi-Anwendungen, die in WebSphere Application Server ausgeführt werden, keine Ausführungsumgebung angeben.

Modulschicht

In der Modulschicht verarbeitet das OSGi-Framework die modularen Aspekte eines Bundles. Die Metadaten, mit denen das OSGi-Framework das Bundle verarbeitet, sind in einer Bundlemanifestdatei definiert.

Einer der wesentlichen Vorteile von OSGi ist das Klassenladeprogrammmodell, das die Metadaten in der Manifestdatei verwendet. OSGi hat keinen globalen Klassenpfad. Wenn Bundles im OSGi-Framework installiert werden, werden die Metadaten von der Modulschicht verarbeitet und die deklarierten externen Abhängigkeiten werden mit den versionierten Exporten, die von anderen installierten Modulen deklariert werden, abgeglichen. Das OSGi-Framework ermittelt die Abhängigkeiten mithilfe des Manifests und berechnet den für jedes Bundle unabhängigen erforderlichen Klassenpfad. Dieser Ansatz behebt die Mängel eines reinen Ladens von Java-Klassen, indem sichergestellt wird, dass die folgenden Voraussetzungen erfüllt sind:
  • Nur Pakete, die explizit von einem bestimmten Bundle mithilfe der Metadaten exportiert wurden, sind für andere Bundles für den Import sichtbar.
  • Jedes Paket kann bestimmten Versionen zugeordnet werden.
  • Mehrere Versionen eines Pakets können für verschiedene Clients parallel verfügbar sein.

Lebenszyklusschicht

Die Schicht für das Lebenszyklusmanagement von Bundles in OSGi beseitigt das Problem des Ladens von Java-Klassen und die zur Ausführungszeit auftretenden Ausnahmebedingungen vom Typ Klasse nicht gefunden, bei dem abhängige Klassen nicht geladen werden können, das sie nicht gefunden werden. Bei der Implementierung eines installierten Bundles in das Framework löst das Framework zuerst alle zugehörigen deklarierten Abhängigkeiten auf. Ungelöste Abhängigkeiten werden vom Framework gemeldet und das Bundle wird nicht gestartet.

Bundlelebenszyklus:
  • Bundles sind dynamisch und können unabhängig vom Rest des Frameworks gestartet und gestoppt werden.
  • Jedes Bundle kann einen Bundleaktivator enthalten, den das Framework bei Start- und Stoppereignissen aufruft. Der Bundleaktivator wird im Bundlemanifest deklariert.

Anwendungen müssen in der Regel keinen Bundleaktivator bereitstellen. Wenn jedoch beim Starten und Stoppen des Bundles eine Initialisierung erforderlich ist, kann ein Bundleaktivator erstellt werden.

Service-Registry-Schicht

Die Service-Registry-Schicht in OSGi unterstützt an sich serviceorientierte Architektur (SOA). Bundles veröffentlichen Services in der Service-Registry und andere Bundles können diese Services über die Service-Registry aufspüren.

Diese Services sind das primäre Mittel für die Kooperation zwischen Bundles. Ein OSGi-Service ist ein POJO (Plain Old Java Object), das in der Service-Registry unter einem oder mehreren Java-Schnittstellennamen veröffentlicht wird und optionale Metadaten als angepasste Eigenschaften (Name/Wert-Paare) enthalten kann. Ein Erkennungsbundle sucht in der Service-Registry nach einem Service anhand eines Schnittstellennamens und kann anschließend die Services mithilfe der angepassten Eigenschaften filtern.

Services sind völlig dynamisch und haben in der Regel denselben Lebenszyklus wie das Bundle, das sie bereitstellt.

Symbol das den Typ des Artikels anzeigt. Konzeptartikel
Nutzungsbedingungen für Information Center | Feedback

Symbol für Zeitmarke Letzte Aktualisierung: 29.04.2014

Dateiname: cosgiarchitecture.html