OSGi Service Platform | |
---|---|
Basisdaten
| |
Entwickler | OSGi Alliance |
Erscheinungsjahr | Mai 2000[1][2] |
Aktuelle Version | 7[3][4] |
Betriebssystem | Java |
Programmiersprache | Java |
Kategorie | Standard |
Lizenz | OSGi Specification License (OSGi Core Release 7) |
www.osgi.org |
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.
Im Jahr 2021 übertrug die OSGi Alliance ihre Aufgabe an die OSGi Working Group der Eclipse Foundation.[5][6][7]
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.
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 wurde 2007[8] 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.
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.
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.
Zusammensetzung des „Board of Directors“ in alphabetischer Ordnung (nach repräsentierten Unternehmen) (Stand: Oktober 2019)[9]:
Die aktuelle OSGi-Spezifikation nennt sich „OSGi Service Platform Release 5“, adressiert J2ME/CDC Java-Plattformen, und steht – einschließlich älterer Versionen und Errata – auf der OSGi-Website zur Verfügung:
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.
Die Referenzimplementierung der OSGi Alliance ist nicht für den Produktiveinsatz gedacht, sondern dient lediglich als Vorlage für andere Implementierungen.
Produktivtaugliche OSGi-Frameworks sind von verschiedenen Anbietern erhältlich, einerseits als kostenlose, frei verfügbare Open-Source-Lösungen, andererseits als kommerzielle Produkte. Beide Varianten haben Vor- und Nachteile.
Kommerzielle bzw. Closed Source Frameworks sind in der Regel zertifiziert, stärker anwendungsbezogen ausgerichtet (bzw. dahingehend optimiert) und beinhalten neben dem eigentlichen Framework in der Regel weitere optionale Softwarepakete – letztere bilden häufig die Basis für kundenspezifische Auftragsarbeiten, die sich auch in anwendungsbezogen optimierten Framework-Varianten niederschlagen können (z. B. für den Mobilbereich). Inwieweit die Nichtverfügbarkeit des Quellcodes hier Nachteile bietet, ist im Einzelfall unterschiedlich zu gewichten, zumal über Verschwiegenheitserklärungen häufig Zugriff ermöglicht wird.
Kommerzielle R4 zertifizierte OSGi Service Platforms (Frameworks) sind folgende (Stand Februar 2010):
Open-Source-Frameworks sind in der Regel weniger anwendungsbezogen ausgerichtet – oder im Gegenteil stark auf eine bestimmte Anwendung fokussiert (siehe Equinox) und/oder von einem einzelnen Unternehmen dominiert, das sein früheres kommerzielles Produkt auf diesem Wege ausgekoppelt hat oder von Anfang an als OSS-Produkt pflegt. Teilweise werden auch aufgewertete OSS-Lösungen kommerziell vertrieben. Inwieweit die Quellcodeverfügbarkeit hier Vorteile bietet, ist im Einzelfall unterschiedlich zu gewichten.
Liste der OSS OSGi-Frameworks:
Relevante RFCs und Java-Standards
Relevante RFCs und Java-Standards