© DrHitch/Shutterstock.com
Modulare Software entwickeln mit OSGi

2 Requirement-Capability-Modell unter Verwendung der Resolver-Spezifikation


Aufbauend auf dem letzten Kapitel des shortcuts bearbeitet dieses Kapitel 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 Kapitel 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 Kapitel 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 2.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

Listing 2.1

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 bedie...

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

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