私が理解していることから、OSGiでは、サーバーを再起動せずに実行時にjarを更新できます。ただし、jboss には、完全な耳が更新され、サーバーがまだ実行されているホットデプロイメントもあります。
では、jboss のエンタープライズ Java プロジェクトにおける OSGi の利点は何でしょうか?
その答えは、OSGi のすべてのユース ケースと同じであると思います。それは、モジュール性とより細かい更新の粒度です。
OSGi は、サーバーを再起動せずに実行時に jar を更新するだけではありません。あなたの質問の観点からは、アプリケーションを再起動せずに実行時にjarを更新しています。
JBoss AS での EAR のホット デプロイメントの特定の実装については知らないことは認めますが、いずれにせよ、アプリケーションの状態全体を保持するように EAR の更新を設計することはできません。サーバーはまだ実行されていますが、基本的に更新時にアプリケーションを再起動します。このような状態損失の程度は、実際にはアプリケーションの設計方法によって異なりますが、物事をモノリシックに行っているという事実は変わりません。
OSGi の場合はそうではありません。アプリケーションは多数のバンドルで構成されており、それぞれが機能の個別の部分を処理するように設計されていることが望まれます。フレームワークは、単一の jar の再起動がアプリケーション全体にもたらす影響を考慮し、他の jar が適切に反応できるように設計されているため、このアプローチにより、アプリケーション内のホット デプロイメントが可能になります。これにより、アプリケーションの状態を可能な限り保持する機能が提供されます。
したがって、エンタープライズの場合の OSGi 設計の利点は、アプリケーションの活性です。その重要性を強調する必要はありません。実際、アプリケーションを安全に再起動できるユース ケースがあります。しかし、私の意見では、OSGi は、今日の Java EE にとって本当にスケーラブルで保守可能な唯一の選択肢です。最も重要なアプリケーション サーバーが OSGi ランタイムに移行した (または移行する予定である) (その結果、OSGi アプリケーション サポートを提供する) という事実は、その証拠です。
l10i は次のように書いています: OSGi の場合、これは当てはまりません。アプリケーションは多数のバンドルで構成されており、それぞれが機能の個別の部分を処理するように設計されていることが望まれます。フレームワークは、単一の jar を再起動するとアプリケーション全体にもたらされる影響を考慮し、他の jar が適切に反応できるように設計されているため、このアプローチにより、アプリケーション内のホット デプロイメントが可能になります。これにより、アプリケーションの状態を可能な限り保持する機能が提供されます。
これについてもう少し詳しく説明すると、最高の OSGi アプリケーションは、OSGi サービス レジストリを介して統合されるサービス指向のアプリケーションです。このサービス レジストリは動的であり、サービスはいつでも出入りでき、OSGi サービス コンシューマはこの動的性に適切に反応します。たとえば、アプリケーションが多数のバンドルで構成されているとします。これには、支払いサービス (クレジット カード支払いの処理など) を使用するバンドルと、その支払いサービスを提供する別のバンドルが含まれます。支払いサービスを更新する必要がある状況に陥った場合 (重大な修正があるか、より安価なプロバイダーを見つけたなどの理由で)、このサービスの利用者をダウンさせることなく、この支払いサービスを更新できます。これを実現するには、支払いサービス バンドル自体を更新します。最初に古いバージョンと並んで。これが可能なのは、OSGi が同じバンドルの複数のバージョンの共存を許可しているためです。次に、新しいバンドルが起動して実行されたら、古い支払いサービス バンドルを削除できます。その時点で、消費者は OSGi サービス レジストリのおかげで、自動的に新しいバンドルを使用するようになります。
上記の例のようなアーキテクチャーは非常に強力であり、企業アプリケーションを確実に稼働させるのに最適です。これは、OSGi サービスと OSGi バンドルを動的にインストール、アンインストール、または更新する機能を組み合わせて使用することで実現できます。
ところで、特定のタイプのすべてのサービスを使用するようにバンドルを作成することもできるため、上記の例にはもう少し詳細があります。何が最適かは状況によって異なります。
OSGi サービス レジストリを使用するにはさまざまな方法があります。かなり低レベルのServiceTracker APIで使用できます。ほとんどの場合、これには OSGi Declarative Services (DS)、OSGi Blueprint、またはその他のフレームワークなどのフレームワークを使用することをお勧めします。ほとんどの場合、これらのフレームワークはインジェクションを通じて機能し、OSGi Service Registry の動的性を処理します。DS または Blueprint については、OSGi 4.2 Enterprise Specificationを参照してください。