エンタープライズ環境での分散OSGiの利用を検討しています。
次の設定があります。
すべてのコンテナーにわたってバンドルのライフサイクル（インストール、開始、更新、停止、アンインストール）を管理する適切な方法は何ですか？
いくつかの要件：
上記の質問に関する提案に感謝します。
よろしく、マートン
クラウドのような環境向けに作成された、より「管理された」ソリューションを見たいと思うかもしれません: Apache ACEまたはその兄弟であるAmdatu。
Apache ACE は、単一の OSGi コンテナーを、単一の管理ポイントから状態を制御できる管理対象コンテナーに変換します。Amdatu は、プロビジョニング用の ACE を含むより完全なフレームワークですが、水平方向の機能が追加されています。
多数のバンドルの管理に関しては、Karafの機能を見てください。これらの機能により、主にバンドルのスイートの処理が大幅に簡素化されます。
分散側については、KarafサブプロジェクトCellarを見てください。これは、HazelCastを使用してKarafをクラスタリングしています（機能メカニズムを介してKarafにインストールされます）。
エンタープライズ対応、つまり「堅牢」な分散 OSGi ランタイムに真剣に取り組んでいる場合は、Paremus Service Fabric を検討してください。私たちは2005年からこれを行っています:)
Service Fabric のプロビジョニング/管理アーキテクチャは非常にスケーラブル (>> 1,000 のコンテナー)、応答性と安定性に優れています。この製品を支える数年にわたる開発および商用ランタイムの経験。Service Fabric アーキテクチャは、複数の同時分散 OSGi ベース アプリケーションをサポートします。Service Fabric のアーキテクチャは OBR 中心です。私たちの主任エンジニアは、最近の OSGi Alliance OBR 仕様の活動を担当していました。
Service Fabric メッセージ バックプレーンは、DDS メッセージング プロトコルを活用します。これは、IMO が分散 OSGi の自然なパートナーです。Paremus RSA (リモート サービス実装) は、標準のクリーン ルーム実装です。これは、非常に堅牢で軽量であり、プロトコルおよび配信プロバイダーの動的プラグ機能を可能にします。デフォルトのディスカバリー プロバイダーは、やはり DDS です。
最後に、Service Fabric はすぐに使用できます。
Gyrexでは、p2 を使用して、クラスターの異なるノードにバンドルを分散します。ノードタグと LDAP フィルター式 (OSGi で一般的) を使用して、どのバンドルをどのノードにプロビジョニングするかを制御できます。たとえば、Web ノードにのみ Web バンドルをインストール (およびアクティブ化) することができます。
分散サービスのサポートは、そのままでは利用できません。ECF は手動で統合する必要があります。