R-Osgi は、リモートの OGSi コンテナーからサービスを呼び出す方法を提供します。ウェブサイト: http://r-osgi.sourceforge.net .
私は R-OSGi を初めて使用しますが、OSGi コンテナーを小さなものに分割し、R-Osgi によって相互にやり取りしたいと考えています。これは、大きすぎるためです。しかし、R-OSGi は Registered Service の方法しか提供していないようです。Service 以外の 2 つのバンドル間で対話する最も一般的な方法である "exported-package" も広く使用されています。
それで、R-OSGiに精通していて、リモートOSGiコンテナーから「エクスポートされたパッケージ」を使用する方法を知っている人はいますか?
返信ありがとうございます。
考えてみれば、パッケージのリモートインポート/エクスポートを処理しようとすると、非常に複雑で壊れやすく、エラーが発生しやすくなります。すべてのバンドルライフサイクルイベントをネットワーク経由で送信し、インポートシステムでそれらを尊重する必要があります（キャッシュが必要になります）。
さらに、フレームワークはこれらのクラス定義を使用するために事前に知る必要があります（クラスローダーで使用できないクラスを参照するクラスをインスタンス化することはできません）。リモートバンドルのクラスローダーは、別のクラスローダーのクラスに依存している可能性があります。このチェーンは、ネットワークをぐるぐる回って、クラスのロードに時間がかかる可能性があります。
別の言い方をすれば、ローカルバンドルは、依存するクラス定義がないと解決されません。SLAが非常に低いネットワーク/ハードウェア上に数千以上の潜在的なリモートエクスポーターが存在する可能性があることを考えると、分散コンピューティングの欠点を考慮すると、これは十分に拡張できないか、非常に堅牢ではありません。 。
リモートパッケージを実行しようとした場合、フレームワークは、使用可能なすべてのリモートノードからすべてのエクスポートされたパッケージをインポートしてから、各バンドルエクスポートをインポートするために1つだけを選択する必要があります（これは任意であり、選択ノードがダウンした場合、インポートリモート全体パッケージプロセスを再度トリガーする必要があります）。
必要なのは、API /インターフェースを実装から分離し、それを必要とするすべてのノードにAPIバンドルを配布してから、dOSGiを使用してサービスをインポートすることです。
これが不明確または不自然な場合はお詫びしますが、リモートでエクスポートされたパッケージを使用することが単に実用的でない理由を説明する必要があります。
ちなみに; r-osgiがアクティブに保守されているのか、最新のRemote Services Admin仕様で最新であるのかはわかりませんが、SVNトランクへの最後のコミットは2011年2月14日でした。ここにリストされているいくつかの代替dOSGi実装があります（ただし、CXFは避けてください）。
編集：デプロイメントに関しては、バンドル（および構成）の配布はOBRから実行できます（パブリックなものがいくつかあり、 Felix / Eclipseの実装がいくつかあります）。または、Mavenリポジトリーをpaxurlハンドラーで再利用できます。