Die OSGi Alliance (früher Open Services Gateway initiative) spezifizierte eine hardwareunabhängige dynamische Softwareplattform, die es erleichtert, Anwendungen und ihre Dienste per Komponentenmodell („Bundle“/„Service“) zu modularisieren und zu verwalten („Service Registry“). Die OSGi-Plattform setzt eine Java Virtual Machine (JVM) voraus und bietet darauf aufbauend das OSGi-Framework.
Hintergründe Im Jahr 2021 übertrug die OSGi Alliance ihre Aufgabe an die OSGi Working Group der Eclipse Foundation.Dan Bandera: , in: blog.osgi.org, 19. Oktober 2020 (englisch)
Von OSGi existieren inzwischen verschiedene Generationen, die allesamt von der OSGi Alliance, einem Industriekonsortium, spezifiziert wurden. Die Allianz besteht aus Großunternehmen wie IBM, Deutsche Telekom, NTT und Oracle, aber auch aus vielen kleineren Unternehmen, u. a. aus dem Open-Source-Software-Bereich (OSS-Bereich). Der gemeinsam definierte OSGi-Standard steht daher allen Interessenten offen, und es existiert gleichfalls ein entsprechend liberales Patent-Gesetzeswerk.
Die OSGi Alliance selbst spezifizierte hierbei lediglich die Programmierschnittstellen (APIs) und Testfälle für OSGi-Implementierungen von dritter Seite und stellte im Rahmen dessen auch eine Referenzimplementierung zur Verfügung. Diese ist nicht für den Produktiveinsatz gedacht, sondern dient lediglich als Vorlage für kommerzielle und OSS-Alternativen.
Die im Ergebnis herstellerunabhängige, generische OSGi-Softwareplattform kann zur Steuerung oder Vernetzung aller Arten von Geräten eingesetzt werden – z. B. in der Automobilindustrie, in Handys, in der Gebäudeautomation, zur intelligenten Fernsteuerung von Hausgeräten oder im Bereich „Assisted Living“. Besonders im Heimbereich spielt das Gateway-Prinzip eine große Rolle, d. h. hier wird häufig nicht unmittelbar ein OSGi-Framework auf den jeweiligen Geräten installiert, sondern auf sogenannten Residential Gateways – sie können als eingebettetes System verstanden werden, das (vergleichbar einem DSL-Router) einzelnen Geräten den Zugriff auf bestimmte Dienste vermittelt oder von außen den abstrakten Zugriff auf bestimmte Geräte ermöglicht. Anders kommen OSGi-Frameworks in Autos und Mobiltelefonen zum Einsatz – hier laufen sie ohne zusätzliches Gateway direkt auf der leistungsfähigen eingebetteten Hardware.
Die Spezifikation der OSGi Service Platform definiert eine Java-basierte Laufzeitumgebung oberhalb der JVM und deren Basisdienste. Ein bedeutendes Merkmal der Service-Plattform ist die Möglichkeit, dynamisch und kontrolliert Service-Anwendungen (sogenannte Bundles) zur Laufzeit einzuspielen und – vor allem – auch zu aktualisieren und wieder zu entfernen. Das Modell der OSGi-Service-Plattform gibt damit die Möglichkeit, verschiedene weitgehend unabhängige und modulare Anwendungen parallel in derselben virtuellen Maschine laufen zu lassen und diese während des gesamten Lebenszyklus der Anwendung (fern-) zu administrieren und zu aktualisieren. Dabei werden Abhängigkeiten zwischen Bundles automatisch aufgelöst, und ein intelligentes Versionsmanagement steht zur Verfügung.
Die einzelnen Implementierungen der jeweiligen Hersteller bestehen meist aus dem OSGi-Framework und idealerweise einer großen Anzahl von Service-Bundles (Packages), die aufgrund der modularen Architektur ebenfalls dynamisch hinzugefügt werden können.
Definition: OSGi-Framework Ein OSGi-Framework ist eine offene, modulare und skalierbare „Service Delivery Platform“ auf Java-Basis. Es handelt sich um ein Komponentenmodell mit Komponenten-Registry (= „Service-Registry“). Der „Service“-Begriff, der im OSGi-Kontext oft fällt, geht dabei kaum über den allgemeinen „Schnittstellen“-Begriff einer Komponente hinaus.
Während serviceorientierte Architekturen als Paradigma zur unternehmensweiten Strukturierung von Systemlandschaften Ortstransparenz und Zugriffstransparenz erfordern, sind die Möglichkeiten zur Programmierung verteilter Systeme nicht integraler Bestandteil des OSGi-Frameworks, welches seinen Ursprung in eingebetteten Systemen hat. Im OSGi-Framework steht die Komponente (= „Bundle“) im Vordergrund, die ihre Schnittstelle (= „Service“) per Registry (= „Service-Registry“) JVM-lokal veröffentlicht und das Re/Deployment per Komponenten-Lebenszyklus unterstützt. Das OSGi-Framework als zugrundeliegendes Komponentenmodell einer SOA in einer Java-Umgebung zu verwenden ist trotzdem letztlich möglich.
Sie ermöglicht in ihrer Ausprägung als Software-Basisplattform für eingebettete Geräte die Vernetzung von intelligenten Endgeräten durch nachträgliche Auslieferung und Installation von Webservices zur Laufzeit. Dies schließt somit die Aufgabe der klassischen Fernsteuerung, Ferndiagnose und -wartung dieser Geräte mit ein. Weiterhin wird die Verteilung von Informationen und multimedialen Unterhaltungsinhalten an diese Geräte über geeignete Protokolle ermöglicht.
In ihrer Ausprägung als Applikationscontainer im Enterprise-Bereich ermöglicht sie die Realisierung einer SOA-Plattform über ihre entsprechenden feingranularen service-basierten Java-Spezifikationen. Die auf den einzelnen Clients laufenden Anwendungen können gleichfalls per Remote Management über geeignete Protokolle administriert werden.
OSGi im JCP OSGi wurde 2007 als „JSR-291: Dynamic Component Support for Java SE“ im Rahmen des Java Community Process (JCP) als offizielles dynamisches Komponentenmodell für Java angenommen – neben „JSR 232: Mobile Operational Management“, das sich auf mobile Umgebungen unter Java ME bezieht. JSR-232 (bzw. JSR-232, 246, 248/9) korrespondiert dabei mit der R4 Mobile Spezifikation (MEG) und JSR-291 korrespondiert mit OSGi R4.1. Des Weiteren gibt es inhaltliche Berührungspunkte zu JSR-277 und JSR-294.
Anwendungsbeispiele Der Einsatz von OSGi erfolgt typischerweise in Fahrzeugen (Telematik), mobilen Endgeräten (Handys, PDAs) und im Bereich der Heimvernetzung (Residential Gateways, Router) – dort wiederum in den Bereichen Smart Grid, Assisted Living oder der Gebäudeverwaltung (Facilitymanagement). Darüber hinaus kommt es auch in industriellen Automatisierungslösungen oder völlig anders gearteten eingebetteten Systemen (Aviation, Parksysteme etc.) zur Anwendung, häufig auch im Zusammenspiel mit passenden Remote Management-Lösungen.
Ein weiteres Einsatzgebiet von OSGi ist die Integrierte Entwicklungsumgebung (IDE) Eclipse, wo OSGi in Form des Equinox-Frameworks die Rolle des Modul-Systems für die desktop- bzw. enterprise-orientierten Plattform übernimmt und dabei das Rich Client (RCP) Paradigma bedient. Eclipse wurde ursprünglich vom OSGi-Mitglied IBM entwickelt – inzwischen ist Eclipse quelloffen (OSS), und Plugins für Eclipse sind (ab Version 3) OSGi-Bundles. Eclipse selbst ist somit ein Beispiel für eine Enterprise-Anwendung von OSGi, die über die ursprüngliche eingebettete Ausrichtung hinausgeht – dies hat im Umkehrschluss auch Auswirkungen auf die weitere Entwicklung der Spezifikation.
Darüber hinaus wird OSGi heute auch zur Modularisierung von Java (J2EE) basierten Application Servern eingesetzt, wo es als Basis komplexerer Frameworks dient.
Über diverse Aktivitäten im Java Community Process (JSR-232, 246 und 248/9), die federführend u. a. von Nokia und Motorola gesteuert wurden, fand OSGi auch als Teil einer „Mobile Service Architecture“ (MSA) Einzug in Mobiltelefone. Hierfür wurde es speziell für die Erfordernisse in diesen Umgebungen angepasst und mit Standards wie OMA-DM integriert. Diese Entwicklung ist jedoch seit Android und HTML5 in dieser Form überholt.
Im Breitband-Bereich kombinieren bereits viele Produkte ein clientseitiges OSGi-Framework (ggf. mit integriertem TR-069 Client) mit einem OSGi Remote Management Server (oder einem herkömmlichen TR-069 ACS) um einerseits die Fernkonfiguration und Administration von hochbandbreitigem Endanwender-Equipment (z. B. DSL-Router, Set-Top-Boxen, Smart-Meter Gateways, Smart Home Gateways, Energy Management Gateways etc.) und andererseits das Management von lokalen Apps zu in einer ganzheitlichen Ende-zu-Ende-Lösung zu kombinieren. Als alternatives Protokoll für den Telematik-Bereich gilt das analog für OMA-DM-basierte Lösungen.
Durch die Standardisierung als generische Java-Erweiterung (JSR-291) einerseits und durch die Zusammenarbeit mit der HGI (Home Gateway Initiative) sind weitere, neue Anwendungen im Embedded-Umfeld zu erwarten. Die Enterprise-Schiene wiederum wird durch gesteigertes Interesse bei den Anbietern von Application Servern bzw. dem RCP-/Eclipse-Umfeld bedient.
Die OSGi-Website listet zahlreiche weitere Anwendungsbeispiele.
Einordnung: OSGi & System-Schichten 600px
Die Abbildung zeigt den Schichtenaufbau einer typischen OSGi-Architektur. Server bedeutet in diesem Zusammenhang meist ein klassisches eingebettetes System, nicht notwendigerweise einen Enterprise-Server oder Desktop-Client (RCP) – obwohl OSGi sich auch in diese Richtung weiterentwickelt, siehe Eclipse und Equinox.
Organisation Gegründet wurde die OSGi Alliance 1999. Ihr gehören über 100 Unternehmen aus unterschiedlichen Branchen an. Diese Branchen werden innerhalb der Organisation durch verschiedene Arbeitsgruppen, sog. „expert groups“, bedient, die alle an der weiteren Spezifikation des Standards mitwirken und dadurch helfen, dass der Standard industrieübergreifend eingesetzt werden kann. Bei der Mitgliedschaft wird zwischen „Full Members“, „Adopters“ und „Supporters“ unterschieden.
Die Allianz wird von einem Direktorium (Board of Directors) geleitet, das jährlich von seinen Vollmitgliedern gewählt wird. Zusätzlich zu den Unternehmensvertretern, die als „directors“ gewählt werden, gibt es noch sog. „officers“, die innerhalb des Direktoriums bestimmte Aufgaben übernehmen und dem Direktorium zuarbeiten.
Auf der kommerziellen Ebene wird in diversen Komitees (Committees) zusammengearbeitet, während technische Fragen – wie die Weiterentwicklung der Spezifikation, von Release 1 über 2 und 3 bis hin zu Version 4 – von den diversen Arbeitsgruppen vorangetrieben werden. Es existieren derzeit (Stand: Januar 2008) Expert Groups für die Bereiche Residential, Enterprise, Mobile, Vehicle und Core Platform.
Board of Directors Zusammensetzung des „Board of Directors“ in alphabetischer Ordnung (nach repräsentierten Unternehmen) (Stand: Oktober 2019): Carsten Ziegeler, Adobe Inc. Kai Hackbarth, Bosch Software Innovations Dan Bandera, IBM Corporation Ray Auge, Liferay Hiroyuki Maeomichi, NTT Tim Ward, Paremus Prasad Yendluri, Software AG
Spezifikation Die aktuelle OSGi-Spezifikation namens „OSGi Service Platform Release 5“ betrifft J2ME/CDC Java-Plattformen und steht, neben folgenden Altfassungen und Errata, auf der OSGi-Website zur Verfügung: OSGi Release 1 (R1): Mai 2000 OSGi Release 2 (R2): Oktober 2001 OSGi Release 3 (R3): März 2003 OSGi Release 4 (R4): Oktober 2005 / September 2006 Kern-Spezifikation (R4 Core): Oktober 2005 Kern-Erweiterungen (R4 Compendium): Oktober 2005 Mobil-Spezifikation (R4 Mobile / JSR-232): September 2006 OSGi Release 4.1 (R4.1): Mai 2007 OSGi Release 4.2 (R4.2): September 2009 / März 2010 Kern-Spezifikation (R4.2 Core): September 2009 Kern-Erweiterungen (R4.2 Compendium): September 2009 Enterprise-Erweiterungen (R4.2 Enterprise): März 2010 OSGi Release 4.3 (R4.3): April 2011 Kern-Spezifikation (R4.3 Core): April 2011 Kern-Erweiterungen (R4.3 Compendium): Mai 2012 Residential-Spezifikation (R4.3 Residential): Mai 2012 OSGi Release 5 (R5): Juni 2012 Kern-Spezifikation (R5 Core): März 2012 Enterprise-Erweiterungen (R5 Enterprise): März 2012 OSGi Release 6 (R6): Juni 2014 Kern-Spezifikation (R6 Core): Juni 2014 OSGi Release 7 (R7) Compendium Release 7 Specifications: 25. April 2018
Die OSGi Alliance selbst spezifizierte lediglich die Ausführungsumgebung, die APIs und Testfälle für OSGi-Implementierungen von Dritter Seite – und stellte im Rahmen dessen auch eine Referenzimplementierung zur Verfügung.
800px
OSGi-Frameworks