Bundles automatisch installieren

OSGi - Provisioning

Florian Pirchner


Project Jigsaw

Im letzten Artikel wurde die Art und Weise, wie OSGi die Abhängigkeiten zwischen Bundles auflöst, betrachtet. Dieser Artikel soll eine Übersicht geben, wie die „Repository-Service-Spezifikation“ [1] den Vorgang des „Resolvings“ unterstützt, um Abhängigkeiten auch mittels Bundles aus externen Repositories auflösen zu können.

ArtikelserieTeil 1: Beschreibung von Abhängigkeiten auf Basis des Requirement-and-Capability-ModellsTeil 2: Requirement-Capability-Modell unter Verwendung der Resolver-SpezifikationTeil 3: Provisioning-SpezifikationTeil 4: Coordinator-Spezifikation

Repository

Ein Repository ist ein physikalischer Ort, an dem Bun­dles verfügbar gemacht werden. OSGi definiert nicht, in welcher Form Bundles abgelegt werden bzw. wie ein Index für den Zugriff aufgebaut sein muss, sondern beschreibt nur einen Vorschlag in der Spezifikation.

Der OSGi Service Repository ist so einfach wie möglich aufgebaut und bietet nur eine Methode an. Diese hat den Charakter einer Abfragemethode: Dem Repository wird eine Menge an Requirements übergeben und das Repository liefert eine Menge an Capabilities für jede Resource zurück:

interface Repository { Map> findProviders(Collection extends Requirement> requirements);}

Die Art und Weise, wie die Repository-Implementierung die Anfrage bearbeitet, ist nicht Teil der Spezifikation, sondern wird der Implementierung überlassen. Die Spezifikation definiert folgende OSGi Service Properties am Repository-Service:

service.pid – die eindeutige ID des Serviceservice.description – der Name/die Beschreibung repository.url – eine oder mehrere URLs des Repositorys

Resource

Konnten zu einem gegebenen Requirement passende Capabilities gefunden werden, dann ist die Frage berechtigt, wie die damit verbundene Resource ermittelt werden kann. Wie im letzten Artikel zu „Resolving“ beschrieben, ist eine Capability immer mit einer Resource verbunden, welche diese Fähigkeit zur Verfügung stellt. Somit kann die Resource mittels der Methode getResource() von der Capability abgefragt werden. Da der Repository-Service alle Capabilities zu einem Requirement liefert, kann ein Requirement natürlich auch von verschiedenen Resources befriedigt werden.

Von der Resource zum Bundle

Eine weitere Besonderheit von Resources, die vom Repository geliefert werden, ist, dass sie das Interface RepositoryContent implementieren:

interface RepositoryContent { InputStream getContent();}

Über die Methode getContent() kann d...

Bundles automatisch installieren

OSGi - Provisioning

Florian Pirchner


Project Jigsaw

Im letzten Artikel wurde die Art und Weise, wie OSGi die Abhängigkeiten zwischen Bundles auflöst, betrachtet. Dieser Artikel soll eine Übersicht geben, wie die „Repository-Service-Spezifikation“ [1] den Vorgang des „Resolvings“ unterstützt, um Abhängigkeiten auch mittels Bundles aus externen Repositories auflösen zu können.

ArtikelserieTeil 1: Beschreibung von Abhängigkeiten auf Basis des Requirement-and-Capability-ModellsTeil 2: Requirement-Capability-Modell unter Verwendung der Resolver-SpezifikationTeil 3: Provisioning-SpezifikationTeil 4: Coordinator-Spezifikation

Repository

Ein Repository ist ein physikalischer Ort, an dem Bun­dles verfügbar gemacht werden. OSGi definiert nicht, in welcher Form Bundles abgelegt werden bzw. wie ein Index für den Zugriff aufgebaut sein muss, sondern beschreibt nur einen Vorschlag in der Spezifikation.

Der OSGi Service Repository ist so einfach wie möglich aufgebaut und bietet nur eine Methode an. Diese hat den Charakter einer Abfragemethode: Dem Repository wird eine Menge an Requirements übergeben und das Repository liefert eine Menge an Capabilities für jede Resource zurück:

interface Repository { Map> findProviders(Collection extends Requirement> requirements);}

Die Art und Weise, wie die Repository-Implementierung die Anfrage bearbeitet, ist nicht Teil der Spezifikation, sondern wird der Implementierung überlassen. Die Spezifikation definiert folgende OSGi Service Properties am Repository-Service:

service.pid – die eindeutige ID des Serviceservice.description – der Name/die Beschreibung repository.url – eine oder mehrere URLs des Repositorys

Resource

Konnten zu einem gegebenen Requirement passende Capabilities gefunden werden, dann ist die Frage berechtigt, wie die damit verbundene Resource ermittelt werden kann. Wie im letzten Artikel zu „Resolving“ beschrieben, ist eine Capability immer mit einer Resource verbunden, welche diese Fähigkeit zur Verfügung stellt. Somit kann die Resource mittels der Methode getResource() von der Capability abgefragt werden. Da der Repository-Service alle Capabilities zu einem Requirement liefert, kann ein Requirement natürlich auch von verschiedenen Resources befriedigt werden.

Von der Resource zum Bundle

Eine weitere Besonderheit von Resources, die vom Repository geliefert werden, ist, dass sie das Interface RepositoryContent implementieren:

interface RepositoryContent { InputStream getContent();}

Über die Methode getContent() kann d...

Neugierig geworden?


    
Loading...

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