Seite 2: OSGi

Inhaltsverzeichnis

OSGi und Java – ein Traumpaar

1999 wurde die OSGi Alliance (damals Open Services Gateway Initiative) gegründet, mit dem Ziel, die stetig wachsende Komplexität und stärkere Vernetzung von Systemen in den Griff zu bekommen. Die 15 Gründungsmitglieder, darunter Alcatel, Ericsson, IBM, Motorola, Oracle, Philips, Sun Microsystems und Toshiba, fokussierten sich zunächst auf die Spezifikation eines Java-Komponentensystems für sogenannte Service Gateways zur Realisierung des intelligenten Heims.

Das OSGi Framework ist das Kernelement der Spezifikationen. Es dient als Laufzeitumgebung für Softwarekomponenten und orientiert sich stark an den Prinzipien der serviceorientierten Architektur (SOA). Das Framework lässt sich gut mit den folgenden Eigenschaften beschreiben: modular, offen, dynamisch und erweiterbar.

Wie in Abbildung 2 dargestellt, ist das OSGi Framework in mehrere Schichten aufgeteilt. In der Modulschicht wird das Format der Module definiert, in OSGi-Terminologie werden sie als Bundles bezeichnet. OSGi Bundles setzen sich aus Java-Klassen und anderen Ressourcen (z. B. HTML-Dateien und Bilder) zusammen. Es ist möglich, mehrere Bundles gleichzeitig in einem JVM-Prozess ausführen zu lassen. Bundles können sich Packages untereinander zur Verfügung stellen, diese bei Bedarf aber auch voreinander verstecken. Jedes Bundle verfügt über eine Manifest-Datei, die zusätzliche Metainformationen bereitstellt. Das bedeutet Informationen wie Bundle-Name, -Version und -Hersteller, aber auch Abhängigkeiten zu anderen Bundles via Import und Export.

Über den Lifecycle Management Layer lässt sich der Lebenszyklus von Bundles kontrollieren. Diese können beispielsweise über eine lokale Konsole oder über ein Management-System aus der Ferne installiert, gestartet, gestoppt und deinstalliert werden. Das Bundle bekommt bei der Installation einen eindeutigen Identifier zugeordnet. Sofern Abhängigkeiten zu anderen Bundles bestehen sollten, sind diese zunächst aufzulösen, bevor ein Bundle gestartet werden kann. Somit lassen sich unerwünschte Nebeneffekte, zum Beispiel unerklärliche Abstürze, vermeiden.

Der Service Layer führt das Programmiermodell der serviceorientierten Architektur nach dem "Publish-Find-Bind"-Modell ein. Ein OSGi-Service wird in Form eines Java-Objekts repräsentiert, das sich über eine Java-Schnittstelle bei der OSGi Service Registry an- beziehungsweise abmelden kann. Die OSGi Service Registry fungiert als Bindeglied, wobei hier die Laufzeitdynamik zu beachten ist, da Bundles jederzeit kommen und gehen können.

Mit standardisierten OSGi-Mechanismen, zum Beispiel dem ServiceTracker, kann der Bundle-Lifecycle überwacht werden. Die Sicherheitsschicht ist optional und setzt auf der Java-2-Sicherheitsarchitektur auf, um mit digitalen Signaturen den Ursprung von Softwarekomponenten authentifizieren zu können.

Im Mai 2000 wurde die erste Spezifikation der OSGi Alliance veröffentlicht. Es wurden zunächst nur das eigentliche Framework und Dienste zur Geräteverwaltung für Home Gateways, Set-Top-Boxen und DSL-Modems spezifiziert. Seitdem kamen zahlreiche weitere Spezifikationen hinzu. Derzeit wird am sechsten Release gearbeitet, das Neuerungen für die Entwicklung von Enterprise-/Cloud-Anwendungen, aber auch für Home Gateways enthalten wird.

Im August 2013 wurde der Entwicklungsprozess der OSGi Alliance erneuert, der es nun der Entwickler-Community ermöglicht, die Spezifikationsarbeiten zu verfolgen und zu kommentieren. Hierzu wurde ein GitHub-Repository eingerichtet, in dem die aktuellen Dokumente zur Verfügung stehen.

Im Internet der Dinge gesetzt

Der Kern der OSGi-Spezifikation wurde stetig so generisch gehalten, dass er in nahezu allen Umgebungen zum Einsatz kommen kann. Bei eingebetteten Systemen hat sich OSGi als Standard für modulare Softwarearchitekturen in Home-Gateways durchgesetzt. Darüber hinaus ist die Eclipse-Entwicklungsumgebung sicherlich eines der bekanntesten Beispiele für den Einsatz von OSGi. Mittlerweile basieren außerdem nahezu alle Java-Enterprise-Applikationsserver auf OSGi (darunter WebSphere, JBoss, WebLogic und NetWeaver).

Die Bereiche Gesundheit, Energie, Fahrzeugtelematik, Transport und Logistik, aber auch die industrielle Automatisierung (Industrie 4.0) verändern sich derzeit aufgrund der Entwicklung bei M2M beziehungsweise dem Internet der Dinge grundlegend. OSGi wurde hier als eine der Kerntechniken identifiziert, wie eine Umfrage von Bosch Software Innovations im Mai 2013 zeigte. OSGi war hier mit 46 Prozent die wichtigste Technik für das Internet der Dinge.

Aufgrund vieler Vorteile werden heute nahezu alle komplexen Softwaresysteme modularisiert. Im Vordergrund stehen die Time-to-Market und die Reduzierung der Entwicklungskosten durch größtmögliche Wiederverwendung von Softwarekomponenten. Bei serviceorientierten Architekturen haben Studien gezeigt, dass die Wiederverwendung von Softwarekomponenten kurzfristig zu Einsparungen von 5 bis 10 Prozent führen kann und über einen längeren Zeitraum sogar bis zu über 40 Prozent.

Durch die daraus resultierende Komplexitätsreduktion lassen sich Projektrisiken minimieren, während gleichzeitig die Qualität steigt. Bei eingebetteten Systemen lassen sich mit Java und OSGi noch höhere Einsparungen erreichen, da hier eine Vielzahl unterschiedlicher Prozessoren und Betriebssysteme zum Einsatz kommen.

OSGi existiert bereits seit 15 Jahren und hat sich in vielen Umgebungen bewährt. Es gibt derzeit kein weiteres standardisiertes Modulsystem für Java. Oracle beziehungsweise Sun haben mit dem Projekt Jigsaw versucht, einen eigenen Weg zur Modularisierung für Java zu finden. Die Java- und OSGi-Community zeigte sich von dieser Entwicklung allerdings bis dato nur wenig begeistert. Nach mehreren gescheiterten Versuchen wurde im letzten Jahr entschieden, dass das Projekt Jigsaw nicht vor Java 9, also vermutlich nach 2015, eingeführt wird.