Ich habe gerade die letzten zwei Tage damit verbracht, all die OSGi-Sachen zu lesen, die ich in die Finger bekommen kann, und ich denke schließlich, dass ich meinen Kopf drum herum habe.
Ich versuche jetzt, es aus vielen Gründen in eine bestehende Anwendung zu integrieren, wie zum Beispiel Plugins von Drittanbietern, automatische Updates, ganz zu schweigen davon, dass SOA mich einfach glücklich macht.
Ich habe jetzt eine Entscheidung, die ich zu kämpfen habe, nämlich das Wetter
Ich würde 1 bevorzugen, da ich dadurch die Anwendung leicht aktualisieren kann und die Architektur konsistent ist. Natürlich muss ich die Anwendung in viele kleinere Pakete umgestalten. Allerdings macht 2 die Dinge auf kurze Sicht viel einfacher, wird aber in der Zukunft unangenehm werden.
für Option 1) Sie wollen wirklich nicht Ihre gesamte Anwendung in einem Paket - Sie würden alle Vorteile von OSGi verlieren - aber das hängt wirklich von der Größe Ihrer Anwendung ab.
Es hängt wirklich davon ab, wo Sie die Anwendung ausführen möchten und welche Aufgabe sie ausführen soll. Wahrscheinlich möchten Sie auch eine Art Remoting für den Zugriff auf die bereitgestellten Dienste haben.
in Option 1) müssen Sie eine Art http / Servlet-Paket aktivieren (es gibt eine Brücke, die existiert) In Option 2) können Sie Ihre Anwendung innerhalb eines Anwendungsservers ausführen, damit Sie sich darüber keine Gedanken machen müssen.
Die erste Frage, die Sie sich stellen wollen, ist die Betriebsumgebung. Wer wird die Anwendung ausführen? Müssen sie auf OSGi trainiert werden / wollen? Sind sie mit dem J2EE-Stack vertrauter?
Ich denke, die beste Option für Sie ist es, Ihre Optionen offen zu halten, es gibt keine wirklichen Unterschiede zwischen 1) und 2), sondern was das OSGi-Framework ansteuert, entweder Ihr Code oder der Framework-Code. Ihre Anwendung selbst, dh die Bündel, die Ihre Anwendung bilden, sind genau dieselben.
Mein Rat wäre, sich nicht zu sehr mit der OSGi-Laufzeit zu beschäftigen - sondern mit der OSGi-Entwicklung anzufangen - nichts hält Sie davon ab, "OSGi-style" zu entwickeln und in einer JRE-Standardumgebung zu laufen.
Ich denke, Sie möchten mit Option 1 gehen und Ihre Anwendung besteht aus einer Reihe von Bundles in einem (meist gebrauchsfertigen) OSGi-Container.
Ich würde also sagen, dass Option 1 auch auf kurze Sicht wahrscheinlich einfacher ist.
Ich stimme auch Patricks Behauptung zu, dass der Großteil Ihres Codes nicht darauf achten muss, ob er in OSGi oder in einer einfachen JVM ausgeführt wird. Insbesondere bei der Verwendung deklarativer Dienste und der Notwendigkeit, OSGi-Schnittstellen und -Mechanismen aus Ihrem Code zu verwenden, wird die Anzahl der Deskriptordateien um ein Vielfaches reduziert. Fügen Sie dem META-INF des Krams nur einige Deskriptordateien hinzu.
Ich würde lieber mit Option 2 gehen, Inhärent ist Ihre Anwendung kein Bündel, sondern eine Anwendung. Wenn Sie den OSGi-Wert hinzufügen möchten, erstellen Sie den OSGi-Container in Ihrer Anwendung. Wenn Sie sich zu einem späteren Zeitpunkt von OSGi entfernen, können Sie das auf einfache Weise tun.
Haben Sie sich den Spring Application Server angesehen? Können Sie damit nicht umgehen?
Ich würde auf jeden Fall 1 empfehlen - die App sollte ein OSGi-Bundle werden, und das nicht nur wegen der einfachen Aktualisierung. Wenn die Hälfte Ihres Codes im OSGi-Framework und die andere Hälfte außerhalb des Codes liegt, müssen Sie eine Brücke für die Kommunikation zwischen den beiden Hälften konstruieren. Sie könnten auch Probleme mit Sichtbarkeit der Klassen haben.
Es gibt auch viele Vorteile von 1, und es ist nicht so schwer zu erreichen. Was ich empfehlen würde, ist folgendes:
Sie sind nicht gezwungen, viele Module zu haben - OSGi kann genauso gut zwei Pakete mit jeweils 10 MB und 100 kleinere Pakete handhaben. Die Trennung sollte ein Ergebnis der Funktionalität selbst sein - ein guter Ausgangspunkt ist das UML-Architekturdiagramm, das Sie wahrscheinlich schon vor der Implementierung des Krams erstellt haben. Die Stellen, an denen die verschiedenen funktionalen Teile miteinander kommunizieren, sind genau die Orte, an denen Sie über die Definition von Schnittstellen anstelle von Klassen nachdenken sollten - und diese Schnittstellen werden dann Ihre OSGi-Dienste und die Implementierungen werden die Bündel - und das nächste Mal Um einen Teil zu aktualisieren, werden Sie feststellen, dass es viel einfacher ist, den Effekt auf die anderen Teile der App vorherzusagen, weil Sie ihn klar getrennt haben und im Manifest der Bündel deklariert haben.
Trennen Sie alle externen / Open-Source-Bibliotheken, die Sie in separaten Bundles verwenden. Sie werden höchstwahrscheinlich die Teile sein, die häufiger und auf einer anderen Zeitleiste als Ihr eigener Code aktualisiert werden müssen. Wichtiger ist es hier auch, klare Paketabhängigkeiten, Paketversionen zu definieren und abhängig von der Implementierung Teile statt nur auf Schnittstellen zu vermeiden!
Überlegen Sie sich, welche Teile der App für Plug-ins verfügbar sein sollen. Dann machen OSGi-Dienste aus diesen Teilen - d. H. Veröffentliche die Schnittstellen in der OSGi-Registrierung. Sie müssen keine spezifische Sache implementieren - Sie können jedes Java-Objekt veröffentlichen. Die Plugins werden dann die Registrierung für die Suche verwenden.
Das Gleiche gilt für die Plugins - denken Sie darüber nach, was Sie von Plugins erhalten möchten und definieren Sie die entsprechenden Interfaces, die die Plugins implementieren und veröffentlichen können und Ihre App in der Registry suchen kann.
Und als letzten Tipp: Sehen Sie, welche Bundles bereits in dem von Ihnen gewählten OSGi-Framework verfügbar sind. Es gibt viele Standard-OSGi-Schnittstellen, die durch die OSGi-Spezifikation definiert sind - für Konfiguration, Protokollierung, dauerhaften Speicher, Remote-Verbindungen, Benutzerverwaltung, Ereignisverwaltung und vieles mehr. Da sie Standard sind, können Sie sie verwenden, ohne von einer bestimmten OSGi-Implementierung abhängig zu sein. Und deinstallieren Sie, was Sie nicht brauchen.