OSGi

Bin mir nicht sicher, ob es überhaupt Sinn macht das hier zu Fragen, aber ich versuche es mal.

Hat hier eventuell jemand Erfahrungen mit OSGi und kann mir ein paar Buchempfehlungen geben oder kennt Adressen im Netz zu dem Thema. Es geht mir dabei weniger um die technische Umsetzung. Da findet man durchaus genug Tutorials o.ä. mit Minimalbeispielen usw.
Es geht mir darum zu verstehen wie das ganze später mal "in der Realität" funktionieren soll. Also eine Art "best practice", Erfolgsgeschichten oder Praxisbeispiele.
Ich sehe zB die Gefahr, dass man seine Anwendung sehr schnell zu sehr aufsplittet. Gibt es hier Empfehlungen oder Faustregeln wie groß oder klein einzelne Module sein sollten?
Auch verstehe ich irgendwie nicht so genau auf was ich als Entwickler achten muss.
Also das ganze sollte für mich als Entwickler annähern transparent sein und "einfach funktionieren". Dh ich kann ein bundle austauschen und das funktioniert technisch. Nehmen wir an ich habe einen Cache in meiner Anwendung mit Einträgen "Entity_v1". Jetzt tausche ich das bundle und dadurch gibt es nur noch "Entity_v2". Muss ich den Cache jetzt für ungültig erklären oder passiert das irgendwie magisch von alleine?

Eventuell hat irgendwer ein Forum, einen Blog o.ä. zur Hand wo solche Themen erklärt werden oder man Fragen kann. Ich finde da leider nichts, nicht mal ein Wiki o.ä.

Schon mal danke für eure Antworten.

Tobiking2

Ich arbeite seit etwas über 1 Jahr mit OSGi. Einstieg habe ich relativ viel über Tutorials und der OSGi Spec gemacht. Die ist dank Grafiken und Beispielen gar nicht mal so trocken. Ansonsten gibt es auf der OSGi Seite (https://www.osgi.org/developer/resources/books/) auch ne Buch Liste. Da kann ich allerdings nichts zu sagen.

OSGi schrieb:

Ich sehe zB die Gefahr, dass man seine Anwendung sehr schnell zu sehr aufsplittet. Gibt es hier Empfehlungen oder Faustregeln wie groß oder klein einzelne Module sein sollten?

Es kommt etwas darauf an was man mit den Bundles machen möchte. Bei uns sind die Bundles teilweise recht klein, da wir diese nach Features aufteilen. Der Kunde bekommt dann nur die Bundles/Features die er möchte (und natürlich bezahlt hat ;)). Zudem gehören bei uns zu einem typischen Deployment mehrere Systeme, die unterschiedliche Rollen übernehmen sollen. Das lässt sich dann ebenfalls über die Auswahl der Bundles steuern. Daraus ergeben sich natürliche Grenzen der Bundles.

Ein gewisser Mehraufwand ist das definitiv wenn man die Bundles ziemlich klein macht. Gerade beim Deployment kann man ohne Automatisierung ziemlich viel Zeit verschwenden. Was die Entwicklung angeht ist es aber verkraftbar. Es gibt einige ziemlich gute Tools was das Einbinden von Declarative Services etc. angeht. Der Unterschied zum normalen Entwickeln ist da nicht mehr so groß, da die Konfiguration aus Code und Annotations generiert werden kann.

OSGi schrieb:

Auch verstehe ich irgendwie nicht so genau auf was ich als Entwickler achten muss.
Also das ganze sollte für mich als Entwickler annähern transparent sein und "einfach funktionieren". Dh ich kann ein bundle austauschen und das funktioniert technisch. Nehmen wir an ich habe einen Cache in meiner Anwendung mit Einträgen "Entity_v1". Jetzt tausche ich das bundle und dadurch gibt es nur noch "Entity_v2". Muss ich den Cache jetzt für ungültig erklären oder passiert das irgendwie magisch von alleine?

Den Updatemechanismus setzen wir bisher noch nicht gezielt ein. Bei Services weiß ich aber das beim Update einfach die entsprechenden unbind* und bind* Methoden aufgerufen werden wenn das Bundle mit dem Service geupdatet wird. Bei Import Abhängigkeiten laufen die Bundles mit den alten Klassen weiter, bis sie refreshed werden. Der Refresh ist soweit ich weiß dann einfach ein Neustart des Bundles. Man muss also dafür sorgen das sich die Bundles problemlos stoppen und starten lassen. Und man sollte nicht Ungewöhnliches mit den Classloadern oder mit statischen Klassenvariablen machen.

OSGi schrieb:

Eventuell hat irgendwer ein Forum, einen Blog o.ä. zur Hand wo solche Themen erklärt werden oder man Fragen kann. Ich finde da leider nichts, nicht mal ein Wiki o.ä.

So wenig finde ich das gar nicht. Meistens habe ich bei Problemen eine Lösung gefunden. Es hilft allerdings direkt mit der verwendeten Implementierung (Equinox, Felix etc.) zu suchen. Ansonsten ist wie gesagt die offizielle Spec auch nicht schlecht.

Danke erstmal für die Antwort.

Ja, es gibt genug Tutorials die auch gut für die ersten Schritte sind. Mein Problem ist aber nun die "reale Welt".

Auch macht es mir den Anschein, wenn man mal ein konkretes Problem hat findet man dafür durchaus Lösungen. "Leider" habe ich aber diese konkreten Probleme noch nicht sondern stehe vor der Frage wie eine OSGi Anwendung grundsätzlich aufgebaut sein sollte, auf was muss ich achten usw.
Theoretisch sollte das alles für mich als Entwickler transparent sein. Es gibt die Tools die mir helfen und ich muss nicht großartig drüber nachdenken.

Natürlich ist es nicht die Aufgabe der OSGi Leute mir meine Anwednung zu planen. Aber einfach nur auf die Spezifikation zu verweisen reicht mMn auch nicht, da keine "Musterimplementierung" existiert. Jeder Implementierung kann wiederum für sich entscheiden, ob man sich an die Spezifikation hält oder nicht.

Du schreibst das ihr den Updatemechanismus (noch) nicht verwendet. Was macht ihr den wenn ihr plötzlich feststellt das ihr ihn nicht verwenden könnten, weil die Anwendung falsch geplant ist?

In deinem Link sind 2-3 Bücher dabei die passen könnten. Allerdings sind die auch schon 5+ Jahre alt. Wäre halt schön gewesen wenn es eine Art OSGi Blog o.ä. gibt in dem ein Entwickler von den täglichen Problemen und deren Lösungen berichtet.

Als ich zufällig über das Thema gestolpert bin hat sich das richtig genial angehört. Inzwischen weiß ich nicht, ob es die Zeit wert ist, da ich mich nur als Hobby nebenbei damit beschäftige. Die Lernkurve scheint irgendwie doch recht steil und Erfolg ist ungewiss.

Tobiking2

OSGi schrieb:

Als ich zufällig über das Thema gestolpert bin hat sich das richtig genial angehört. Inzwischen weiß ich nicht, ob es die Zeit wert ist, da ich mich nur als Hobby nebenbei damit beschäftige. Die Lernkurve scheint irgendwie doch recht steil und Erfolg ist ungewiss.

OSGi sieht zwar relativ mächtig aus, aber es lassen sich unglaublich schnell Minimalbeispiele bauen. Ein Bundle ist grundsätzlich erstmal nichts anderes als eine normale Jar mit einem Manifest in dem die OSGi Informationen über Bundle Name und Version stehen. Das einzige was da OSGi von einer "normalen" Java Anwendung unterscheidet ist, dass man nicht einfach so auf public Klassen in anderen Jars zugreifen kann. Man muss in der Manifest explizit angeben welche Packages ein Bundle exportiert und welche von andere importiert werden sollen. Das ist schon einer der Kernpunkte von OSGi, die so für eine striktere Trennung zwischen den einzelnen Modulen hat.

OSGi schrieb:

"Leider" habe ich aber diese konkreten Probleme noch nicht sondern stehe vor der Frage wie eine OSGi Anwendung grundsätzlich aufgebaut sein sollte, auf was muss ich achten usw.

So allgemein fallen mir nur Punkte ein an die man sich eh halten sollte: Interfaces benutzen und auf loose coupling setzen (wenn auf Teilupdates abgezielt wird). Haben zwei Bundles eine starke Abhängigkeit, müssen wie gesagt beide neu gestartet werden sobald eins geupdatet wird. Bleibt aber z.B. das Interface bei einem Service gleich, kann einfach die Implementierung ausgetauscht werden. Oder wenn die Bundles nur über den Eventmechanismus verbunden sind ist dem Empfänger komplett egal das der Sender gerade neu startet. Ich habe da im Zusammenhang mit OSGi auch des öfteren Vergleiche mit dem Microservice Ansatz gehört, der in eine ähnliche Richtung geht.

OSGi schrieb:

Du schreibst das ihr den Updatemechanismus (noch) nicht verwendet. Was macht ihr den wenn ihr plötzlich feststellt das ihr ihn nicht verwenden könnten, weil die Anwendung falsch geplant ist?

Es ist bei uns kein Muss-Kriterium das wir zur Laufzeit updaten können. Wichtiger ist bei uns das sich das System nach einem kompletten OSGi Restart wieder in einen vernünftigen Zustand kommt und wieder die Arbeit beginnt. Wir haben zudem auch das Problem das wir ein paar native Bibliotheken mit reinladen, die sich in den Prozess hängen und sich ohne Restart eh nicht verlässlich updaten lassen. Von daher haben wir da keinen Druck.

OSGi schrieb:

Wäre halt schön gewesen wenn es eine Art OSGi Blog o.ä. gibt in dem ein Entwickler von den täglichen Problemen und deren Lösungen berichtet.

So eine wirklich gute Quelle habe ich da leider auch nicht. Man findet immer mal wieder einzelne Artikel, aber selten scheint sich jemand detailliert darüber zu äußern. OSGi ist allerdings gefühlt in der Open Source Welt auch nicht so verbreitet. Oder halt nur bei wirklich großen Projekten wie Eclipse und Netbeans. Bei dem ganzen JBoss Stack oder auch anderen Application Server hab ich das Gefühl das OSGi auch nur so eine Nebenrolle spielt. Und die Unternehmen die im Bereich Telekommunikation, Automotive etc. aktiv sind, äußern sich meist nicht so freizügig über das was sie tun.