Zurück zum Ursprung von OSGi

OSGi für eingebettete Systeme
Kommentare

Als OSGi 1999 initiiert wurde, war es das erklärte Ziel, dynamische Verwaltung von Softwarekomponenten auf Geräten mit geringem Speicher und Ressourcen zu ermöglichen. Der große Erfolg von OSGi auf dem Desktop und der Serverseite hat dazu geführt, dass heutige Implementierungen der neusten Revisionen deutlich höhere Ansprüche an die Ressourcen haben und schwieriger in eingebetteten Systemen zu verwenden sind. Concierge wurde entwickelt, um dies zu ändern.

Eingebettete Systeme sind traditionell ressourcenarme, abgeschlossene Systeme, die für einen bestimmten festgelegten Zweck entwickelt worden sind. Einmal im Einsatz, unterlagen sie oft nur wenigen, grundlegenden Aktualisierungen, zum Beispiel in Form von Firmware-Updates. Software für solche Geräte wurde typischerweise sehr hardwarenah entwickelt, um maximale Effizienz zu erreichen. Die Beschränktheit der Ressourcen drückte sich aber nicht nur in der Software aus, sondern auch die Hardware selbst war häufig spartanisch gehalten, zum Beispiel beim Prozessor oder dem Display. In den letzten Jahren hat sich die Landschaft der eingebetteten Systeme in mehrerlei Hinsicht geändert. Fortschritte sowohl bei der Hardware als auch bei der Software ermöglichen neuartige Anwendungen, die weitaus reichhaltiger und dynamischer in ihrer Natur sind und dadurch vermehrt kontinuierliche Aktualisierungen benötigen.

Smartphones weisen den Weg für die Zukunft der eingebetteten Geräte

Zum einen hat sich die Hardware stark weiterentwickelt. Während früher oft aus Kosten- und Energieeffizienzgründen einfache Mikroprozessoren verwendet wurden, ist es mittlerweile möglich, Technologie einzusetzen, wie sie zum Beispiel auch in Smartphones verwendet wird. Dies hat dazu geführt, dass nun für die Anwendungen Programmiersprachen und -methoden eingesetzt werden können, die bisher vor allem größeren Geräten vorbehalten waren. Zum anderen hat sich aber auch die Erwartungshaltung der Benutzer verändert. Unter dem Einfluss der rasanten Entwicklung im Bereich von Mobiltelefonen mit ihren verbesserten Benutzerschnittstellen wie zum Beispiel den Touchbildschirmen, erwarten immer mehr Benutzer eine ähnlich flüssige Interaktion mit eingebetteten Systemen wie sie es von ihren Smartphones gewöhnt sind. Insbesondere im Zusammenspiel mit dem Internet und der Cloud eröffnen sich neue Möglichkeiten, um eingebettete Systeme untereinander und mit den Endgeräten des Benutzers zu vernetzen. Immer mehr Hersteller entwickeln ihre Systeme auf Basis von Open Source und als offene Plattformen, für die Anwender ihre eigenen Apps entwickeln können, um auf der Welle des Erfolgs der Smartphones mitreiten zu können. Ein Beispiel aus den USA ist der Nest Thermostat, der in einer klassischen Domäne der einfachen mikroprozessorgesteuerten eingebetteten Systeme nicht nur durch sein „i-Device“-ähnliches Äußeres inklusive Touchbenutzerschnittstelle auffällt, sondern auch via WLAN in der Cloud die Fernsteuerung und Überwachung der Thermostatfunktionen von außerhalb des Hauses erlaubt, beispielsweise mithilfe des Mobiltelefons.

Viele solcher Anwendungen benötigen kontinuierliche Aktualisierungen und die Möglichkeit, Erweiterungen zur Laufzeit in das System einbringen zu können. Dies ist eine der großen Stärken der OSGi-Laufzeitumgebung, wie sich am Beispiel der Eclipse IDE und ihrer Plug-in-Architektur zeigt. Interessanterweise waren es Szenarien der Heimautomatisierung, die 1999 zur Entwicklung der ersten OSGi-Standards führten. Doch während bis zur Revision 3 der Funktionsumfang des OSGi-Frameworks bewusst schmal gehalten wurde, um eine gute Einsatzfähigkeit auf ressourcenbeschränkten eingebetteten Systemen zu gewährleisten, hat der zunehmende Erfolg in Desktopanwendungen wie der Eclipse IDE oder RCP sowie auf der Serverseite dazu geführt, dass sowohl der Funktionsumfang als auch die Größe und Ressourcenanforderungen der Implementierungen stark gestiegen sind.

OSGi R3 in 86 Kilobytes

Concierge begann 2006 als Forschungsprojekt an der ETH Zürich (Jan S. Rellermeyer und Gustavo Alonso: Concierge: A Service Platform for Resource-Constrained Devices. ACM) als Antwort auf die Frage, wie klein und effizient sich der OSGi-R3-Core-Standard implementieren lässt und wie gering man den Overhead für Laufzeitmodularität und dynamische Komponentenverwaltung auf der JVM halten kann. Die Implementierung kam mit gerade einmal etwa 86 kB aus und lief auf den damals üblichen eingebetteten JVMs wie dem J2ME-CDC-1.0-Profil für Geräte mit nur wenigen Megabyte an freiem Hauptspeicher. Ein spezieller Zielpunkt für die Entwicklung von Concierge war, dass viele der damals in mobilen und eingebetteten Systemen eingesetzten JVMs keine Just-In-Time Compilation unterstützten und daher eine konsistente Leistung nur durch konsequente Optimierung des Programmcodes zu erreichen war. Concierge wurde als Open-Source Projekt auf sourceforge.net publiziert und kam unter anderem in der originalen Version der Bug Platform kommerziell zum Einsatz, in der die physischen Erweiterungsmodule durch OSGi Services in Concierge abgebildet und für Anwendungen dynamisch verfügbar gemacht wurden.

Da eingebettete Systeme in der Vergangenheit in den meisten Fällen entweder völlig isoliert oder durch Netzwerkprotokolle von Servern entkoppelt waren, schien es ausreichend, eine einfache Version eines OSGi-Frameworks wie Concierge auf dem Gerät laufen zu lassen, um die Vorteile der Modularisierung von Anwendungen zu bekommen ohne einen zu großen Preis zahlen zu müssen. Im Zuge der allgemeinen Entwicklung bei mobilen und eingebetteten Systemen wird es allerdings immer populärer, denselben Softwarestack auf dem Gerät und auf der Serverseite laufen zu lassen. Zum Beispiel hat sich bei Webapplikationen JavaScript zunehmend auch auf dem Server etabliert, nicht zuletzt in Form von Node.js. Im Falle von OSGi bedeutet dies, dass Entwickler eine aktuelle Version der Laufzeitumgebung auf dem Gerät bevorzugen, um dieselben Bibliotheken und Komponenten verwenden zu können, die sie bereits auf der Serverseite einsetzen.

Zurück in die Zukunft von Mobile und M2M

Die Laufzeitumgebungen, die den aktuellen Funktionsumfang von OSGi R5 Core implementieren, zeigen häufig ein wenig befriedigendes Laufzeitverhalten auf eingebetteten Systemen. Equinox zum Beispiel ist für die Ausführung der Eclipse IDE ausgerichtet und daher für Situationen optimiert, in denen die Abhängigkeiten von vielen hundert Anwendungsbundles effizient zur Startzeit aufgelöst werden müssen. Daher ist es bestrebt, möglichst viele Zwischenresultate zu puffern, was zu einem höheren Speicherbedarf führt, der sich in kleineren Anwendungen nicht auszahlt. Darüber hinaus empfinden manche Anwender Equinox als problematisch für die Verwendung in puren OSGi-Anwendungen, da es urpsrünglich nicht primär als alleinstehendes OSGi-Framework konzipiert war und daher manche Aspekte der Konfiguration nicht unbedingt intuitiv und benutzerfreundlich ausfallen.

Im Anschluss an die letztjährige EclipseCon Europe gab es deshalb Diskussionen, eine neue OSGi-Laufzeitumgebung unter dem Dach der Eclipse Foundation zu entwickeln, die speziell für den Einsatz in mobilen und M2M-Anwendungen abgestimmt und optimiert ist. Die naheliegende Idee war, auf der Basis von Concierge als der kleinsten und leichtgewichtigsten Implementierung aufzubauen und das Projekt auf den aktuellen Stand der R5-Core-Spezifikationen zu bringen, ohne dabei das spezielle Augenmerk auf Einfachheit und Effizienz zu verlieren. Nun, fast ein Jahr später, ist das Eclipse-Concierge-Projekt offiziell eingerichtet und hat seine Arbeit aufgenommen, um möglichst bald eine erste R5-konforme Implementierung fertigzustellen. Neben seiner eigentlichen Bestimmung soll es auch als Experimentierfeld dienen, um neue Funktionen für OSGi schneller zum Zwecke der Evaluierung implementieren zu können, und die Hoffnung ist, dass sogar Teile der Concierge-Implementierung verwendet werden können, um Equinox auf breiterer Ebene zu optimieren. Daher ist Concierge keinesfalls als Konkurrenzprodukt zu Equinox zu sehen, sondern als komplementärer Ansatz, von dem man sich durchaus Synergieeffekte erhoffen darf.

Der (lange) Weg von OSGi R3 zu R5

In OSGi R3 war das Bild der OSGi-Welt vorherrschend, dass jedes Bundle und im Regelfall auch jedes Java-Package im System nur in einer einzigen Instanz existieren würde. Die größte Errungenschaft von OSGi R4 war folgerichtig die Einführung der Versionierung und damit verbunden die Möglichkeit, verschiedene Versionen von Packages und Bundles koexistent im System verwalten und benutzen zu können, solange jedes einzelne Bundle nie mit mehr als einer Version gleichzeitig durch eine Abhängigkeit verbunden war, um die Konsistenz in Bezug auf Class Loading zu gewährleisten. Dies war die Voraussetzung, um OSGi in einer Umgebung wie Eclipse einsetzen zu können, wo die Unit-Test-Funktionalität für Java-Projekte in der Praxis oft das Vorhandensein von JUnit 3 und 4 erfordert. Zum anderen ebnete es aber auch den Weg, um als Kern von Application-Servern eingesetzt werden zu können, in denen einzelne Anwendungen verschiedene Versionen der gleichen Bibliotheken benutzen können müssen. Letzteres brachte OSGi erstmals in Berührung mit Enterprise-Java, und die speziellen Anforderungen dieses Bereichs führten dazu, einzelnen Bundles, z. B. Extender Bundles, mehr Kontrolle über die Abläufe innerhalb des Frameworks geben zu wollen, um die Sichtbarkeit von Services gegenüber ausgewählten anderen Bundles einschränken zu können. Realisiert wurde dies mit den verschiedenen Hooks, die Bundles im Sinne des Whiteboard-Musters als Services registrieren können, um dadurch Callbacks ins System einzuführen, die die Abläufe des Frameworks gezielt beeinflussen können. Mit R5 wurde ein weiterer Schritt zur Verallgemeinerung gemacht, indem nun Bundles durch generische Requirements und Capabilities auch Abhändigkeiten oder das Vorhandensein von Ressourcen signalisieren können, die nicht als Code oder Dateien in Java-Packages abgebildet werden sollen oder können. Dies ist insbesondere hilfreich, um von Plattform und Umgebung abstrahieren zu können oder die Abhändigkeit einer Ressource vom Vorhandensein eines bestimmten Extenders im Systems modellieren zu können.

Viele dieser neuen Fähigkeiten können zweifelsfrei auch in eingebetteten Systemen von Nutzen sein. Die Herausforderung für das Concierge-Team ist es, trotzdem den Fokus auf Effizienz zu behalten. Speziell die höhere Komplexität im Bereich der Auflösung von Abhändigkeiten, die das neue Requirement-/Capability Modell mit sich bringt, benötigt daher besondere Aufmerksamkeit, da der Auflösungsprozess kritisch für die Aufstartgeschwindigkeit der Applikationen ist. Das Hauptaugenmerk bei der Implementierung der neuen Funktionalitäten liegt daher darauf, den generischen Fall zuzulassen ohne die Optimierungen für die speziellen und sehr häufigen Fälle der Auflösung von Abhängigkeiten von Bundles und Packages sowie das Finden von Services zu verlieren.

Da bereits die Klassen und Schnittstellen des OSGi-Core-APIs selbst im Vergleich zum R3-Release signifikant gestiegen sind, wird die Eclipse-Concierge-Implementierung nicht mehr in der gleichen Liga von unter 100 kB spielen können. Nach aktuellem Stand ist jedoch das Ziel, volle R5-Kompatibilität bei einer Größe von etwa 350 kB zu behalten und auch trotz der Einführung von Generics weiterhin für Java-1.4-Ziele kompilierbar zu bleiben, da entsprechende VMs immer noch in eingebetteten Systemen eingesetzt werden und sich dies bis mindestens zur Einführung und Marktetablierung der Java-8-Profile nicht so schnell ändern wird. Komplementiert wird das neue Framework durch eine REST-Schnittstelle, die es ermöglicht, Laufzeitoperationen einfach im Webbrowser oder durch Skripte auf einem Steuerungsrechner ausführen zu können und so beispielsweise neue Bundles installieren oder vorhandene aktualisieren zu können. Die Standardisierung einer REST-Schnittstelle ist aktuelles Thema in der OSGi Enterprise Expert Group, wo sie ursprünglich für die Cloud vorgeschlagen und entwickelt worden ist. Da jedoch Cloud und eingebettete Systeme nicht nur durch ihre inhärente Ressourcenbeschränktheit (im Gerät quasi im Designprinzip verankert, in der Cloud durch das Teilen von Resourcen unter mehreren Nutzern) Ähnlichkeiten aufweisen, sondern auch zunehmend durch eine symbiotische Beziehung zueinander finden, kann es von Vorteil sein, beide bequem durch dasselbe Protokoll steuern zu können. Da die REST-Schnittstelle aber natürlich ordentlich modularisiert in Form eines OSGi-Bundles entwickelt wird, wird sie selbstverständlich auch unabhängig von Concierge auf jedem anderen Framework eingesetzt werden können.

Dieser Beitrag stammt aus dem Entwickler Magazin Spezial Vol. 1: Internet of Things.

Aufmacherbild: Green sprout growing from seed via Shutterstock / Urheberrecht: Grisha Bruev

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -