Gibt es eine elegante Möglichkeit, Services über oder zwischen OSGi Container zu verwenden?Remoting und OSGi
Ist es überhaupt möglich?
Zum Beispiel sagen wir, ich habe eine Service-Schnittstelle auf meinem lokalen Rechner. Mit welchen Methoden/Technologien kann ich diese Service-Schnittstelle über den BundleContext eines Remote-OSGi-Containers aufrufen?
Es gibt einen RFC namens Remote Services (früher Distributed OSGi), der genau das tut, was Sie erreichen wollen. Der RFC ist fast abgeschlossen, und es gibt bereits 2 Implementierungen, die jeweils von Apache CXF und Eclipse ECF bereitgestellt werden.
Beide Implementierungen ermöglichen eine transparente Remotierung eines OSGi-Dienstes. Sie müssen lediglich den OSGi-Dienst wie gewohnt definieren und einige Konfigurationsparameter hinzufügen, um ihn zu einem Remote-Dienst zu machen.
Es ist möglich, aber es gibt keine Bibliotheken (afaik), die dies für Sie tun. Ich habe mich für meinen jetzigen Job selbst eingerollt. OSGi Runtime auf Client und Server, RMI ist der Transport. Ich musste HEAVY Proxy-Objekte verwenden.
Registrieren Sie einen Dienst in der OSGi-Laufzeit des Servers (Equinox). Ich habe einen Listener, der alle Dienste beobachtet, die nach einer Eigenschaft/einem Attribut suchen, die anzeigen, dass dieser Dienst exportiert werden sollte (remote gemacht), etwas wie "remotable = true". Es ist einfach, mit dem ServiceTracker zu filtern. Über RMI weise ich den Client an, ein Proxy-Objekt mit der Service-Schnittstelle zu erstellen. Alle Aufrufe dieses Proxy-Objekts werden generisch über RMI zurückgesendet (ein Aufruf wie execService serviceid, Methodenname, var args params) und dann auf dem REAL-Dienst aufgerufen.
Ich habe einige der Low-Level-Details weggelassen, aber Sie können es wahrscheinlich aussortieren. Wenn Sie sich von RMI entfernen können, möchten Sie vielleicht in Riena suchen (es kann sogar eine Möglichkeit geben, einen RMI-Transport für Riena zu schreiben, ich habe einfach keine Mühe zu versuchen)
Es ist nicht sehr klar, was Sie sind versuchen zu erreichen. Sie haben einen Dienst, Sie können mit RMI darauf zugreifen, und Sie müssen als OSGi-Dienst verfügbar sein?
Ich denke, Sie könnten eine Schnittstelle zu Ihrem lokalen Computer Service schreiben. Sie könnten dann ein Bundle schreiben, das mit diesem Dienst verbunden ist, und diese Schnittstelle in der OSGi-Dienstregistrierung verfügbar machen. Dann kann Ihr Hauptpaket diesen Dienst unter Verwendung des Schnittstellen- oder Dienstnamens lokalisieren.
Es sollte nicht zu viel Arbeit sein, um eine RMI-Verbindung zu Ihrem lokalen Dienst zu erhalten. Vielleicht einige Konfigurationsoptionen, um die anfängliche Verbindung herzustellen. Es kann wichtig sein, eine Fassade für Ihren Dienst zu schreiben, bevor Sie sie in OSGi veröffentlichen, um eine Art Entkopplung zu erreichen und vielleicht die Tatsache zu verbergen, dass es sich um einen RMI-Dienst handelt.
Aber dann vielleicht habe ich dich völlig missverstanden und das alles ist nutzlos.
Neben CXF oben, gibt es auch ECF Eklipse, die eine Sammlung von Kommunikationsrahmen ist und provies eine frühzeitige Umsetzung der OSGi 4.2 Remote-Dienste (auch bekannt als OSGi verteilt). Dazu wird ein lokaler Dienst registriert, an den der Client in der VM gebunden ist. Anschließend wird auf dem Remotecomputer ein Proxy erstellt, und mithilfe einer Technologie Ihrer Wahl (RMI, WebServices usw.) können die Aufrufe remote geschaltet werden.
Offensichtlich verwendet dies By-Value-Methode Aufrufsyntax (die Ihr Dienst wissen muss), aber alle anderen Comms-Fehler sind RuntimeException.
Es ist sicherlich möglich. Überprüfen Sie https://docs.paremus.com//display/NIM20/Home, die eine OSGi RSA-Implementierung enthält, die einen leistungsstarken RMI-Verteilungsanbieter enthält.
Überprüfen Sie das Kapitel "Remote Services" in der OSGi-Spezifikation Version 4.2. Es definiert eine Standardweise für die Verteilung von Diensten zwischen mehreren OSGi-Containern.
Die brandneue Version 4.3 der OSGi-Spezifikation bietet hierfür noch detailliertere Unterstützung - siehe Kapitel 6 Remote Services und 112 Remote Service Admin Service.