© DrHitch/Shutterstock.com
OSGi

3 Eclipse Concierge - OSGi für eingebettete Systeme im IoT


Eclipse Concierge wurde von Jan Rellermeyer als Projekt initiiert, um eine leichtgewichtige Open-Source-Implementierung des OSGi-R5-Standards für eingebettete Systeme bereitzustellen. Das Projekt steht kurz vor der Veröffentlichung einer ersten Version, sodass sich ein Blick auf den aktuellen Stand lohnt.

OSGi hat seinen Einsatz in den letzten Jahren auf dem Desktop und in Serveranwendungen gefunden. Die Implementierungen sind immer umfangreicher und vollständiger geworden, was dem Einsatz dort sehr zugute kommt. Gleichzeitig entsteht zusammen mit dem Trend „Internet of Things“, dem Internet der Dinge, mehr und mehr Interesse, OSGi wieder dort einzusetzen, wo es entstanden ist: in eingebetteten Systemen. Zu diesem Zweck hat Jan Rellermeyer das Eclipse-Projekt Concierge ins Leben gerufen. Seitdem ist fast ein Jahr vergangen. Zeit also für ein Update, in dem wir sehen wollen, wie der Stand des Eclipse-Projekts ist und ob es schon reif für den Einsatz in IoT-Szenarien ist.

Eclipse Concierge [2] ist bei der Eclipse Foundation Teil des neu gegründeten IoT-Top-Level-Projekts. So ist es naheliegend, dass andere IoT-Projekte der Eclipse Foundation Concierge einsetzen. Interesse haben beispielsweise die Projekte Eclipse Kura [3] und Eclipse SmartHome [4] bekundet. Diese Projekte werden häufig auf eingebetteten Systemen wie dem Raspberry Pi oder dem BeagleBone eingesetzt, sodass sich leichtgewichtige Implementierungen aufdrängen.

Eclipse SmartHome als potenzieller Nutzer von Concierge

Eines der Projekte im Eclipse-Top-Level-Projekt IoT ist Eclipse SmartHome. Das von Kai Kreuzer initiierte Projekt hat nach der initialen Contribution Ende 2013 im Herbst 2014 eine erste Version 0.7 veröffentlicht. Eclipse SmartHome wird in einem eigenen p2-Repository bereitgestellt, ist als Framework aber erst im Zusammenspiel mit einer Lösung wie beispielsweise openHAB sinnvoll nutzbar. Zu openHAB 2, das auf Eclipse SmartHome (ESH) basiert, sei auf das Interview mit Kai Kreuzer auf Seite 50 verwiesen. Für dieses Kapitel wird die in [5] erwähnte Eclipse-SmartHome-Alphadistribution verwendet, und hier die „minimal-runtime“ zusammen mit dem alpha2-Release von Concierge. Die Umstellung von openHAB 2 von Equinox auf Concierge ist unter [6] dokumentiert und kann dort nachgelesen werden.

openHAB 2 setzt aktuell auf Eclipse Luna auf und nutzt damit Equinox 3.10, das sogar die neueste OSGi-Spezifikation R6 unterstützt. Die Implementierung von Eclipse SmartHome setzt im Moment lediglich OSGi R4.2 voraus und sollte damit für die Nutzung von Concierge vorbereitet sein.

Bevor man mit der Umstellung von Equinox auf Concierge beginnt, sollte man die Struktur einer Equinox-basierenden Anwendung (am Beispiel openHAB 2) nochmals betrachten (Abb. 3.1).

hiller_1.png

Abbildung 3.1: openHAB-2-Verzeichnisstruktur

Die Dateien runtime/server/eclipse.ini und runtime/server/configuration/config.ini definieren, wie die Equinox-Laufzeitumgebung gestartet werden soll. Insbesondere die zu startenden Bundles werden in config.ini definiert:

# config.ini
osgi.bundles=reference\:file\:ch.qos.logback.classic_1.0.7.v20121108-1250.jar@1\:start,reference\:file\:ch.qos.logback.slf4j_1.0.7.v20121108-1250.jar@4,...
osgi.bundles.defaultStartLevel=4
...

Die Pflege dieser Config-Dateien kann mithilfe von Eclipse-IDE-Werkzeugen vorgenommen werden. Für Concierge gibt es bisher keine solchen Tools. Es bietet stattdessen eine dem Knopflerfish-OSGi-Framework vergleichbare Skriptmöglichkeit an [7], um in so genannten xargs-Dateien das OSGi Framework zu konfigurieren. Dazu stehen Optionen wie -install <bundle-jar-name>, -start <bundle-jar-name>, -Dproperty=value zur Verfügung. Ein Beispiel könnte sein:

# xargs file for loading slf4j bundles with adapters
-Dserver.dir=./runtime/server
-Ddir=${server.dir}/plugins
# start logging bundles, but not fragment
# ch.qos.logback.slf4j will be resolved as fragment automatically
-install ${dir}/org.slf4j.api_1.7.2.*.jar
-install ${dir}/ch.qos.logback.core_1.0.7.*.jar
-install ${dir}/ch.qos.logback.classic_1.0.7.*.jar
-install ${dir}/ch.qos.logback.slf4j_1.0.7.*.jar
-start ${dir}/org.slf4j.api_1.7.2.*.jar
-start ${dir}/ch.qos.logback.core_1.0.7.*.jar
-start ${dir}/ch.qos.logback.classic_1.0.7.*.jar
-istart ${dir}/org.slf4j.jcl_1.7.2.*.jar
-istart ${dir}/org.slf4j.jul_1.7.2.*.jar
-istart ${dir}/org.slf4j.log4j_1.7.2.*.jar

Man sieht in dem Beispiel sinnvolle Erweiterungen zu der Knopflerfish-Notation:

  • Properties können mit –Dprop=value gesetzt werden. Vorhandene Properties können mit ${prop} wiederverwendet werden.
  • Direktiven zur Installation und zum Starten von Bundles unterstützen auch Properties.
  • Direktiven zur Installation und zum Starten von Bundles unterstützen auch Wildcards (mit ?, *). Das ist insbesondere dann von großem Nutzen, wenn man die xargs-Dateien manuell erstellt und dabei nicht jede Build-Version eines Bundles nachpflegen möchte.

Es ist zu beachten, dass beim Starten eines Bundles alle Abhängigkeiten (Import-Package, Require Bundle) aufgelöst werden können, sonst verweigert Concierge den Start des Bundles mit:

Exception in thread "main" org.osgi.framework.BundleException: Resolution failed [BundleRequirement{Import-Package ch.qos.logback.core;version="1.0.7 ... BundleRequirement{Import-Package org.slf4j.spi;version="1.7"}]
at org.eclipse.conc...

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