Ich habe auf Wikipedia und anderen Websites über OSGi gelesen , aber ich sehe nicht wirklich das große Ganze. Es heißt, dass es sich um eine komponentenbasierte Plattform handelt und dass Sie Module zur Laufzeit neu laden können. Das "praktische Beispiel", das überall gegeben wird, ist auch das Eclipse Plugin Framework.

Meine Fragen sind:

1. Was ist die klare und einfache Definition von OSGi?

2. Welche häufigen Probleme löst es?

Mit "häufigen Problemen" meine ich Probleme, mit denen wir jeden Tag konfrontiert sind, wie "Was kann OSGi tun, um unsere Arbeit effizienter / unterhaltsamer / einfacher zu gestalten?"

Welche Vorteile bietet Ihnen das OSGi-Komponentensystem?
Nun, hier ist eine ziemliche Liste:

Reduzierte Komplexität - Entwickeln mit OSGi-Technologie bedeutet Entwickeln von Bundles: den OSGi-Komponenten. Bundles sind Module. Sie verstecken ihre Interna vor anderen Bundles und kommunizieren über genau definierte Dienste. Das Verstecken von Interna bedeutet mehr Freiheit, sich später zu ändern. Dies reduziert nicht nur die Anzahl der Fehler, sondern vereinfacht auch die Entwicklung von Bundles, da Bundles mit der richtigen Größe eine Reihe von Funktionen über genau definierte Schnittstellen implementieren. Es gibt einen interessanten Blog, der beschreibt, was die OSGi-Technologie für ihren Entwicklungsprozess getan hat.

Wiederverwendung - Das OSGi-Komponentenmodell erleichtert die Verwendung vieler Komponenten von Drittanbietern in einer Anwendung. Immer mehr Open-Source-Projekte stellen ihre JARs für OSGi bereit. Kommerzielle Bibliotheken werden jedoch auch als fertige Bundles verfügbar.

Echte Welt -Das OSGi-Framework ist dynamisch. Es kann Bundles im laufenden Betrieb aktualisieren und Dienste können kommen und gehen. Entwickler, die an traditionelleres Java gewöhnt sind, sehen dies als sehr problematisch an und sehen den Vorteil nicht. Es stellt sich jedoch heraus, dass die reale Welt sehr dynamisch ist und dass dynamische Dienste, die kommen und gehen können, die Dienste perfekt für viele reale Szenarien geeignet machen. Ein Dienst könnte beispielsweise ein Gerät im Netzwerk modellieren. Wenn das Gerät erkannt wird, wird der Dienst registriert. Wenn das Gerät nicht mehr verfügbar ist, wird der Dienst nicht registriert. Es gibt überraschend viele reale Szenarien, die diesem dynamischen Servicemodell entsprechen. Anwendungen können daher die leistungsstarken Grundelemente der Dienstregistrierung (registrieren, abrufen, mit einer ausdrucksstarken Filtersprache auflisten und darauf warten, dass Dienste angezeigt und ausgeblendet werden) in ihrer eigenen Domäne wiederverwenden. Dies spart nicht nur das Schreiben von Code, sondern bietet auch globale Transparenz, Debugging-Tools und mehr Funktionen, als dies für eine dedizierte Lösung implementiert worden wäre. Das Schreiben von Code in einer solch dynamischen Umgebung klingt wie ein Albtraum, aber zum Glück gibt es Unterstützungsklassen und Frameworks, die den größten Teil, wenn nicht den ganzen Schmerz davon nehmen.

Einfache Bereitstellung - Die OSGi-Technologie ist nicht nur ein Standard für Komponenten. Außerdem wird festgelegt, wie Komponenten installiert und verwaltet werden. Diese API wurde von vielen Bundles verwendet, um einen Verwaltungsagenten bereitzustellen. Dieser Verwaltungsagent kann so einfach sein wie eine Befehlsshell, ein TR-69-Verwaltungsprotokolltreiber, ein OMA DM-Protokolltreiber, eine Cloud-Computing-Schnittstelle für Amazon EC2 oder ein IBM Tivoli-Verwaltungssystem. Die standardisierte Management-API macht es sehr einfach, die OSGi-Technologie in bestehende und zukünftige Systeme zu integrieren.

Dynamische Updates - Das OSGi-Komponentenmodell ist ein dynamisches Modell. Bundles können installiert, gestartet, gestoppt, aktualisiert und deinstalliert werden, ohne das gesamte System herunterzufahren. Viele Java-Entwickler glauben nicht, dass dies zuverlässig möglich ist, und verwenden dies daher zunächst nicht in der Produktion. Nachdem sie dies jedoch einige Zeit in der Entwicklung verwendet haben, stellen die meisten fest, dass es tatsächlich funktioniert und die Bereitstellungszeiten erheblich verkürzt.

Adaptiv - Das OSGi-Komponentenmodell wurde von Grund auf so konzipiert, dass Komponenten gemischt und angepasst werden können. Dies erfordert, dass die Abhängigkeiten von Komponenten angegeben werden müssen und dass Komponenten in einer Umgebung leben müssen, in der ihre optionalen Abhängigkeiten nicht immer verfügbar sind. Die OSGi-Dienstregistrierung ist eine dynamische Registrierung, in der Bundles Dienste registrieren, abrufen und abhören können. Mit diesem dynamischen Servicemodell können Bundles herausfinden, welche Funktionen auf dem System verfügbar sind, und die von ihnen bereitgestellten Funktionen anpassen. Dies macht Code flexibler und widerstandsfähiger gegenüber Änderungen.

Transparenz - Bundles und Services sind erstklassige Bürger in der OSGi-Umgebung. Die Verwaltungs-API bietet Zugriff auf den internen Status eines Bundles sowie auf die Verbindung mit anderen Bundles. Beispielsweise bieten die meisten Frameworks eine Befehlsshell, die diesen internen Status anzeigt. Teile der Anwendungen können gestoppt werden, um ein bestimmtes Problem zu beheben, oder Diagnosepakete können eingebunden werden. Anstatt auf Millionen von Zeilen Protokollierungsausgabe und lange Neustartzeiten zu starren, können OSGi-Anwendungen häufig mit einer Live-Befehlsshell debuggt werden.

Versionierung - Die OSGi-Technologie löst die JAR-Hölle. JAR Hölle ist das Problem, dass Bibliothek A mit Bibliothek B funktioniert; Version = 2, aber Bibliothek C kann nur mit B arbeiten; Version = 3. In Standard-Java haben Sie kein Glück. In der OSGi-Umgebung werden alle Bundles sorgfältig versioniert und nur Bundles, die zusammenarbeiten können, werden im selben Klassenraum miteinander verbunden. Dadurch können sowohl Bundle A als auch C mit ihrer eigenen Bibliothek arbeiten. Obwohl es nicht ratsam ist, Systeme mit diesem Versionsproblem zu entwerfen, kann dies in einigen Fällen lebensrettend sein.

Einfach - Die OSGi-API ist überraschend einfach. Die Kern-API besteht nur aus einem Paket und weniger als 30 Klassen / Schnittstellen. Diese Kern-API reicht aus, um Bundles zu schreiben, zu installieren, zu starten, zu stoppen, zu aktualisieren und zu deinstallieren. Sie enthält alle Listener- und Sicherheitsklassen. Es gibt nur sehr wenige APIs, die so viel Funktionalität für so wenig API bieten.

Klein - Das OSGi Release 4 Framework kann in einer JAR-Datei mit ca. 300 KB implementiert werden. Dies ist ein kleiner Aufwand für die Menge an Funktionen, die einer Anwendung durch Einbeziehen von OSGi hinzugefügt werden. OSGi läuft daher auf einer Vielzahl von Geräten: von sehr kleinen über kleine bis hin zu Mainframes. Es wird nur die Ausführung einer minimalen Java-VM angefordert und nur sehr wenig hinzugefügt.

Schnell - Eine der Hauptaufgaben des OSGi-Frameworks ist das Laden der Klassen aus Bundles. In herkömmlichem Java sind die JARs vollständig sichtbar und werden in einer linearen Liste platziert. Das Durchsuchen einer Klasse erfordert das Durchsuchen dieser (oft sehr langen, 150 ist nicht ungewöhnlich) Liste. Im Gegensatz dazu verdrahtet OSGi Bündel vor und weiß für jedes Bündel genau, welches Bündel die Klasse bereitstellt. Dieser Mangel an Suche ist ein wesentlicher Beschleunigungsfaktor beim Start.

Faul - Faul in der Software ist gut und die OSGi-Technologie verfügt über viele Mechanismen, um Dinge nur dann zu tun, wenn sie wirklich benötigt werden. Bundles können beispielsweise eifrig gestartet werden, sie können jedoch auch so konfiguriert werden, dass sie nur gestartet werden, wenn andere Bundles sie verwenden. Dienste können registriert, aber nur erstellt werden, wenn sie verwendet werden. Die Spezifikationen wurden mehrmals optimiert, um diese Art von faulen Szenarien zu ermöglichen, die enorme Laufzeitkosten einsparen können.

Sicher - Java verfügt unten über ein sehr leistungsfähiges, feinkörniges Sicherheitsmodell, das sich jedoch in der Praxis nur schwer konfigurieren lässt. Das Ergebnis ist, dass die meisten sicheren Java-Anwendungen mit einer binären Auswahl ausgeführt werden: keine Sicherheit oder sehr eingeschränkte Funktionen. Das OSGi-Sicherheitsmodell nutzt das feinkörnige Sicherheitsmodell, verbessert jedoch die Benutzerfreundlichkeit (und härtet das ursprüngliche Modell aus), indem der Bundle-Entwickler die angeforderten Sicherheitsdetails in einer leicht überprüfbaren Form angibt, während der Betreiber der Umgebung die volle Kontrolle behält. Insgesamt bietet OSGi wahrscheinlich eine der sichersten Anwendungsumgebungen, die ohne hardwaregeschützte Computerplattformen noch verwendet werden kann.

Nicht aufdringlich - Anwendungen (Bundles) in einer OSGi-Umgebung bleiben sich selbst überlassen. Sie können praktisch jede Einrichtung der VM verwenden, ohne dass das OSGi sie einschränkt. In OSGi wird empfohlen, einfache alte Java-Objekte zu schreiben. Aus diesem Grund ist für OSGi-Dienste keine spezielle Schnittstelle erforderlich. Selbst ein Java-String-Objekt kann als OSGi-Dienst fungieren. Diese Strategie erleichtert die Portierung von Anwendungscode in eine andere Umgebung.

Läuft überall - Nun, das hängt davon ab. Das ursprüngliche Ziel von Java war es, überall zu laufen. Offensichtlich ist es nicht möglich, den gesamten Code überall auszuführen, da sich die Funktionen der Java-VMs unterscheiden. Eine VM in einem Mobiltelefon unterstützt wahrscheinlich nicht dieselben Bibliotheken wie ein IBM Mainframe, auf dem eine Bankanwendung ausgeführt wird. Es gibt zwei Probleme, um die man sich kümmern muss. Erstens sollten die OSGi-APIs keine Klassen verwenden, die nicht in allen Umgebungen verfügbar sind. Zweitens sollte ein Bundle nicht gestartet werden, wenn es Code enthält, der in der Ausführungsumgebung nicht verfügbar ist. Beide Probleme wurden in den OSGi-Spezifikationen behoben.

Quelle: www.osgi.org/Technology/WhyOSGi

Ich habe die folgenden Vorteile von OSGi gefunden:

• Jedes Plugin ist ein versioniertes Artefakt mit einem eigenen Klassenladeprogramm.
• Jedes Plugin hängt sowohl von bestimmten Jars ab, die es enthält, als auch von anderen spezifischen versionierten Plug-Ins.
• Aufgrund der Versionierung und der isolierten Klassenladeprogramme können verschiedene Versionen desselben Artefakts gleichzeitig geladen werden. Wenn eine Komponente Ihrer Anwendung von einer Version eines Plug-Ins und eine andere von einer anderen Version abhängt, können beide gleichzeitig geladen werden.

Auf diese Weise können Sie Ihre Anwendung als eine Reihe versionierter Plugin-Artefakte strukturieren, die bei Bedarf geladen werden. Jedes Plugin ist eine eigenständige Komponente. So wie Maven Ihnen hilft, Ihren Build so zu strukturieren, dass er wiederholbar ist und durch eine Reihe spezifischer Versionen von Artefakten definiert wird, von denen er erstellt wird, hilft Ihnen OSGi dabei, dies zur Laufzeit zu tun.

Die Hotplugbarkeit von OSGi-Modulen ist mir (zumindest derzeit) nicht so wichtig. Es ist mehr die erzwungene Modularität. Wenn zu keinem Zeitpunkt Millionen von "öffentlichen" Klassen im Klassenpfad verfügbar sind, wird dies gut vor zirkulären Abhängigkeiten geschützt: Sie müssen wirklich über Ihre öffentlichen Schnittstellen nachdenken - nicht nur in Bezug auf das Java-Sprachkonstrukt "public", sondern auch in Bezug auf Ihre Bibliothek / module: Welche (genauen) Komponenten möchten Sie anderen zur Verfügung stellen? Welche (genauen) Schnittstellen (anderer Module) benötigen Sie wirklich, um Ihre Funktionalität zu implementieren?

Es ist schön, dass Hotplug mitgeliefert wird, aber ich möchte lieber meine üblichen Anwendungen neu starten, als alle Kombinationen von Hotplugability zu testen ...

• Analog können Sie den Motor Ihres Autos wechseln, ohne ihn auszuschalten.
• Sie können komplexe Systeme für die Kunden anpassen. Sehen Sie die Kraft von Eclipse.
• Sie können ganze Komponenten wiederverwenden. Besser als nur Objekte.
• Sie verwenden eine stabile Plattform, um komponentenbasierte Anwendungen zu entwickeln. Die Vorteile sind enorm.
• Sie können Komponenten mit dem Black-Box-Konzept erstellen. Andere Komponenten müssen nichts über versteckte Schnittstellen wissen, sie sehen nur die veröffentlichten Schnittstellen.
• Sie können im selben System mehrere gleiche Komponenten verwenden, jedoch in unterschiedlichen Versionen, ohne die Anwendung zu beeinträchtigen. OSGi löst das Jar Hell-Problem.
• Mit OSGi entwickeln Sie das Denken, um Systeme mit CBD zu entwerfen

Es gibt viele Vorteile (ich habe gerade daran erinnert), die für alle verfügbar sind, die Java verwenden.

aus Gründen der Klarheit bearbeitet. Die OSGi-Seite gab eine einfachere Antwort als meine

Eine einfache Antwort: Eine OSGi Service Platform bietet eine standardisierte, komponentenorientierte Computerumgebung für die Zusammenarbeit von Netzwerkdiensten. Diese Architektur reduziert die Gesamtkomplexität beim Erstellen, Verwalten und Bereitstellen von Anwendungen erheblich. Die OSGi Service Platform bietet die Funktionen zum dynamischen Ändern der Zusammensetzung auf dem Gerät einer Vielzahl von Netzwerken, ohne dass ein Neustart erforderlich ist.

In einer einzelnen Anwendungsstruktur, beispielsweise der Eclipse-IDE, ist ein Neustart bei der Installation eines neuen Plugins keine große Sache. Wenn Sie die OSGi-Implementierung vollständig verwenden, sollten Sie in der Lage sein, zur Laufzeit Plugins hinzuzufügen, die neue Funktionalität zu erhalten, aber Eclipse überhaupt nicht neu starten zu müssen.

Wieder keine große Sache für jeden Tag, kleine Anwendungsnutzung.

Wenn Sie sich jedoch mit verteilten Anwendungsframeworks für mehrere Computer befassen, wird dies allmählich interessant. Wenn Sie für kritische Systeme eine 100% ige Verfügbarkeit benötigen, ist die Möglichkeit, Komponenten zur Laufzeit auszutauschen oder neue Funktionen hinzuzufügen, hilfreich. Zugegeben, es gibt jetzt größtenteils Möglichkeiten, dies zu tun, aber OSGi versucht, alles in einem netten kleinen Framework mit gemeinsamen Schnittstellen zu bündeln.

Löst OSGi häufig auftretende Probleme, da bin ich mir nicht sicher. Ich meine, es kann, aber der Overhead lohnt sich möglicherweise nicht für einfachere Probleme. Aber es ist etwas zu beachten, wenn Sie anfangen, mit größeren, vernetzten Anwendungen umzugehen.

Ein paar Dinge, die mich bei OSGi verrückt machen:

1) Die Implentationen und ihre Kontextlader haben viele Macken und können etwas asynchron sein (wir verwenden Felix innerhalb des Zusammenflusses). Im Vergleich zu einer reinen Feder (kein DM), bei der [main] so ziemlich alles synchronisiert.

2) Klassen sind nach einer heißen Last nicht gleich. Angenommen, Sie haben eine Tangosol-Cache-Schicht im Ruhezustand. Es ist mit Fork.class außerhalb des OSGi-Bereichs gefüllt. Sie laden ein neues Glas heiß und Fork hat sich nicht geändert. Klasse [Gabel]! = Klasse [Gabel]. Es wird auch während der Serialisierung aus den gleichen Gründen angezeigt.

3) Clustering.

Sie können diese Dinge umgehen, aber es ist ein großer Schmerz und lässt Ihre Architektur fehlerhaft aussehen.

Und für diejenigen unter Ihnen, die für das Hotplugging werben. OSGis bester Kunde? Finsternis. Was macht Eclipse nach dem Laden des Bundles?

Es wird neu gestartet.

OSGi macht den Code Wurf NoClassDefFoundErrorund ClassNotFoundExceptionohne ersichtlichen Grund (wahrscheinlich , weil Sie ein Paket in OSGi - Konfigurationsdatei zu exportieren vergessen); Da es ClassLoaders hat, kann es dazu führen, dass Ihre Klasse com.example.Foonicht umgewandelt wird, com.example.Fooda es sich tatsächlich um zwei verschiedene Klassen handelt, die von zwei verschiedenen Classloadern geladen werden. Nach der Installation eines Eclipse-Plugins kann Ihr Eclipse in eine OSGi-Konsole booten.

Für mich hat OSGi nur die Komplexität erhöht (weil es ein weiteres mentales Modell für mich hinzugefügt hat) und Ärger aufgrund von Ausnahmen hinzugefügt. Ich habe die Dynamik, die es "bietet", nie wirklich gebraucht. Es war aufdringlich, da für alle Module eine OSGi-Bundle-Konfiguration erforderlich war. es war definitiv nicht einfach (in einem größeren Projekt).

Aufgrund meiner schlechten Erfahrungen neige ich dazu, mich von diesem Monster fernzuhalten. Vielen Dank. Ich würde lieber unter der Hölle der JAR-Abhängigkeit leiden, da dies viel einfacher zu verstehen ist als die von OSGi eingeführte Hölle des Klassenladeprogramms.

Ich bin noch kein "Fan" von OSGi ...

Ich habe mit einer Unternehmensanwendung bei Fortune 100-Unternehmen gearbeitet. Vor kurzem wurde das von uns verwendete Produkt auf eine OSGi-Implementierung "aktualisiert".

Starten der lokalen CBA-Bereitstellung ... [18.02.14 8: 47: 23: 727 EST] 00000347 CheckForOasis

endgültig bereitgestellt und "die folgenden Bundles werden stillgelegt und dann neu gestartet" [18.02.14 9: 38: 33: 108 EST] 00000143 AriesApplicat I CWSAI0054I: Im Rahmen eines Aktualisierungsvorgangs für die Anwendung

51 Minuten ... jedes Mal, wenn sich der Code ändert ... Die vorherige Version (nicht OSGi) wird auf älteren Entwicklungscomputern in weniger als 5 Minuten bereitgestellt.

auf einem Computer mit 16 Gig RAM und 40 Free Gig Disk und Intel i5-3437U 1,9 GHz CPU

Der "Vorteil" dieses Upgrades wurde als Verbesserung der (Produktions-) Bereitstellungen verkauft - eine Aktivität, die wir ungefähr viermal im Jahr mit möglicherweise zwei bis vier kleinen Fixbereitstellungen pro Jahr durchführen. Wenn ich 15 Personen (Qualitätssicherung und Entwickler) 45 Minuten pro Tag hinzufüge, kann ich mir nicht vorstellen, jemals gerechtfertigt zu sein. Wenn Ihre Anwendung in großen Unternehmensanwendungen eine Kernanwendung ist, ist eine Änderung zu Recht (kleine Änderungen können weitreichende Auswirkungen haben - muss mit Verbrauchern im gesamten Unternehmen kommuniziert und geplant werden) eine monumentale Aktivität - eine falsche Architektur für OSGi. Wenn Ihre Anwendung keine Unternehmensanwendung ist - dh jeder Verbraucher kann sein eigenes maßgeschneidertes Modul haben, das wahrscheinlich sein eigenes Datensilo in seiner eigenen Silodatenbank trifft und auf einem Server ausgeführt wird, auf dem viele Anwendungen gehostet werden, dann schauen Sie sich vielleicht OSGi an. Mindestens,

Wenn für eine Java-basierte Anwendung Module hinzugefügt oder entfernt werden müssen (Erweiterung der Basisfunktionalität der Anwendung), ohne die JVM herunterzufahren, kann OSGI verwendet werden. Wenn die Kosten für das Herunterfahren von JVM höher sind, müssen Sie in der Regel nur die Funktionalität aktualisieren oder verbessern.

Beispiele :

1. Eclipse : Bietet eine Plattform für Plugins zum Installieren, Deinstallieren, Aktualisieren und Abhängigen.
2. AEM : WCM-Anwendung, bei der die Funktionsänderung geschäftlich bedingt ist und sich keine Ausfallzeiten für die Wartung leisten können.

Hinweis : Das Spring Framework unterstützt keine OSGI-Spring Bundles mehr, da dies für transaktionsbasierte Anwendungen oder für einen bestimmten Punkt in diesen Zeilen als unnötige Komplexität angesehen wird. Ich persönlich denke nicht an OSGI, es sei denn, es ist absolut notwendig, etwas Großes wie den Aufbau einer Plattform.

Ich arbeite seit fast 8 Jahren mit OSGi und muss sagen, dass Sie OSGi nur in Betracht ziehen sollten, wenn Sie ein Unternehmen zur Laufzeit aktualisieren, entfernen, installieren oder ersetzen müssen. Dies bedeutet auch, dass Sie eine modulare Denkweise haben und verstehen sollten, was Modularität bedeutet. Es gibt einige Argumente dafür, dass OSGi leichtgewichtig ist - ja, das stimmt, aber es gibt auch einige andere Frameworks, die leichtgewichtig und einfacher zu warten und zu entwickeln sind. Gleiches gilt für Java Bla Bla.

OSGi erfordert eine solide Architektur, um korrekt verwendet zu werden, und es ist ziemlich einfach, ein OSGi-System zu erstellen, das genauso gut ein eigenständiges, ausführbares JAR sein kann, ohne dass OSGi beteiligt ist.

Das OSGi bietet folgenden Vorteil:

■ Eine tragbare und sichere Ausführungsumgebung, die auf Java basiert

■ Ein Service-Management-System, mit dem Services bündelweise registriert und gemeinsam genutzt werden können und Service-Provider von Service-Verbrauchern entkoppelt werden können

■ Ein dynamisches Modulsystem, mit dem Java-Module, die OSGi Bundles nennt, dynamisch installiert und deinstalliert werden können

■ Eine leichte und skalierbare Lösung

Es wird auch verwendet, um die Portabilität von Middleware und Anwendungen auf der mobilen Seite zu erhöhen. Die mobile Seite ist beispielsweise für WinMo, Symbian und Android verfügbar. Sobald die Integration mit Gerätefunktionen erfolgt, kann diese fragmentiert werden.

Zumindest lässt OSGi Sie über Modularität, Wiederverwendung von Code, Versionierung und allgemein über die Installation eines Projekts nachdenken.

Andere haben die Vorteile bereits ausführlich beschrieben. Hiermit erkläre ich die praktischen Anwendungsfälle, die ich entweder gesehen oder mit OSGi verwendet habe.

1. In einer unserer Anwendungen haben wir einen ereignisbasierten Ablauf und der Ablauf ist in Plugins definiert, die auf der OSGi-Plattform basieren. Wenn also ein Client morgen einen anderen / zusätzlichen Ablauf wünscht, muss er nur noch ein weiteres Plugin bereitstellen, es über unsere Konsole konfigurieren und fertig .
2. Es wird zum Bereitstellen verschiedener Store-Connectors verwendet. Nehmen wir beispielsweise an, wir haben bereits einen Oracle DB-Connector und morgen muss mongodb verbunden werden. Schreiben Sie dann einen neuen Connector und stellen Sie ihn bereit und konfigurieren Sie die Details über die Konsole. Dann sind Sie wieder fertig. Die Bereitstellung von Connnectors erfolgt über das OSGi-Plugin-Framework.

Es gibt bereits eine ziemlich überzeugende Aussage auf seiner offiziellen Seite, ich darf zitieren als

Der Hauptgrund für den Erfolg der OSGi-Technologie liegt darin, dass sie ein sehr ausgereiftes Komponentensystem bietet , das tatsächlich in einer überraschenden Anzahl von Umgebungen funktioniert. Das OSGi-Komponentensystem wird tatsächlich verwendet, um hochkomplexe Anwendungen wie IDEs (Eclipse), Anwendungsserver (GlassFish, IBM Websphere, Oracle / BEA Weblogic, Jonas, JBoss), Anwendungsframeworks (Spring, Guice), industrielle Automatisierung, Gateways für Privathaushalte, zu erstellen. Telefone und vieles mehr.

Was die Vorteile für Entwickler angeht?

ENTWICKLER: OSGi reduziert die Komplexität, indem es eine modulare Architektur für die heutigen großen verteilten Systeme sowie für kleine eingebettete Anwendungen bereitstellt. Der Bau von Systemen aus internen und handelsüblichen Modulen reduziert die Komplexität und damit die Entwicklungs- und Wartungskosten erheblich. Das OSGi-Programmiermodell verwirklicht das Versprechen komponentenbasierter Systeme.

Bitte überprüfen Sie die Details unter Vorteile der Verwendung von OSGi .