© Excellent backgrounds/Shutterstock.com
Requirement-Capability-Modell unter Verwendung der Resolver-Spezifikation

OSGi - Resolving


Aufbauend auf dem letzten Teil der Serie bearbeitet dieser Artikel tiefergreifende ­Konzepte zum Thema „Resolver“. Diese werden verwendet, um das „Generic ­Resource Model“ auf seine Konsistenz hin zu prüfen.

Das Generic Resource Model beschreibt die Abhängigkeiten zwischen Ressourcen in OSGi-Umgebungen. Wie bereits dargestellt, kann eine Ressource verschiedene Typen haben, wie zum Beispiel Bundle, Fragment oder auch etwas komplett Abweichendes. In diesem Artikel legen wir dem Begriff der Ressource das Bun­dle zu Grunde. Alle Betrachtungen werden anhand von Bundles durchgeführt, können jedoch auch auf andere Ressourcen umgelegt werden.

Resolving

Resolving [1] und Provisioning sind sehr eng miteinander verzahnt. Resolving beschreibt den Part, der notwendig ist, um sicherstellen zu können, dass alle Requirements von zur Verfügung stehenden Ressourcen mittels Capabilities gedeckt werden können. Auf Basis des generischen Ressourcenmodells versucht OSGi im Schritt des „Resolvings“ alle abhängigen Ressourcen zu finden. Die Prüfung der Konsistenz erfolgt dabei in einer rekursiven Art und Weise. Gefundene Ressourcen werden ihrerseits wiederum auf Konsistenz geprüft. Eine Ressource gilt dann als konsistent im Sinne des Modells, wenn alle Requirements mittels einer Capability befriedigt werden konnten. Kommt es zu dem Fall, dass Abhängigkeiten nicht bedient werden können, gibt OSGi eine Fehlermeldung aus.

Zusätzlich zu den im letzten Artikel beschriebenen Capabilities und Requirements existieren noch zwei weitere Begriffe, die maßgebend für den Resolver sind. Attribute und Deklarativen bestimmen maßgebend, wie der Resolver die Abhängigkeiten zwischen Ressourcen auflöst.

Attribute

Attribute dienen dem Resolver, um die möglichen Capabilities einzuschränken, die ein Requirement befriedigen können. OSGi verwendet Attribute intern, um Beschreibungen zu Ressourcen verwalten zu können. So werden z. B. der Bundle Symbolic Name, die Version und die Lizenz in Form von Attributen abgebildet. Es können beliebig viele weitere Attribute hinzugefügt und als Grundlage für den Resolver verwendet werden.

Das Konzept ist so einfach wie mächtig. Um es veranschaulichen zu können, werden drei Bundles verwendet (Listing 1).

Listing 1

Bundle A: Bundle-SymbolicName: A Bundle-Version: 1.0.0.qualifier Import-Package: org.b; foo="bar" Bundle B_Attribute: Bundle-SymbolicName: B_Attribute Bundle-Version: 1.0.0.qualifier Export-Package: org.b; foo="bar" Bundle B_No_Attribute: Bundle-SymbolicName: B_No_Attribute Bundle-Version: 1.0.0.qualifier Export-Package: org.b

Bundle A definiert ein Import-Package von org.b. Zusätzlich definiert der Import-Header ein Attribut foo="bar". Das bedeutet, dass nur ein Export-Package, das ebenfalls ein Attribut foo="bar" definiert, den Import befriedigen kann.

Bundle B_Attribute exportiert org.b; foo="bar", wobei Bundle B_No_Attribute nur das Package org.b exportiert, ohne dabei ein Attribut zu definieren. Das hat zur Folge, dass das Requirement von Bundle A nur durch den Export von Bundle B_Attribute bedient werden kann. Angesichts der Art...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang