OSGi Declarative Services を使用した拡張フィーチャーの構成
単純なフィーチャーは、バンドル・アクティベーター・クラスを使用し、ManagedService や ServiceTracker などのインターフェースを直接実装することで制御できます。 バンドル間の関係が複雑になると、OSGi Declarative Services (DS) のような機能を使用して、1 つのフィーチャーを個々のサービスに分解する方が良い場合もあります。DS (Service Component Runtime (SCR) と呼ばれることもある) は OSGi サービスのライフサイクルおよび注入管理を提供します。
このタスクについて
フィーチャー・ロジックを Declarative Service のセットとして編成すると、いくつかの利点があります。
- サービスのアクティベーション (サービスを提供する Java™ クラスのロードを含む) を、そのサービスの使用時まで遅延させることができます。これにより、サーバーは素早く始動でき、リソースの使用を最小限に抑えることが可能です。
- サービスに対する依存関係を解決できるよう、サービスがまだアクティブ化されていない時点でも、サービスへの参照はサービス・レジストリーに配置されます。
- 他のサービスへの依存関係は実行時に注入できます。各種サービスのアクティベーションは、そのような依存関係に基づいて順序付けされます。
- サービスは、そのサービス・プロパティーが変更された時点で、必要に応じて非アクティブ化および再アクティブ化することが可能です。
OSGi Declarative Services の使用に関する詳細な情報は、『OSGi Community Wiki』をはじめ、多数のオンライン・リソースから入手可能です。
このタスクでは、DS に対してサービスを宣言する方法、他のサービスへの参照を取得する方法、および各サービスの構成プロパティーを管理する方法について、簡単に説明しています。