Liberty アーキテクチャー

Liberty は、高度に構成可能で動的なランタイム環境です。 OSGi サービスを使用して、コンポーネント・ライフサイクル、依存関係の注入、および構成を管理します。 サーバー・プロセスは、単一の JVM、 Liberty カーネル、および任意の数のオプション・フィーチャーで構成されます。 フィーチャー・コードと大部分のカーネル・コードは、OSGi フレームワーク内の OSGi バンドルとして実行されます。 フィーチャーでは、アプリケーションに必要なプログラミング・モデルとサービスが提供されます。

図1: Liberty アーキテクチャー
ランタイム環境は、カーネル、JVM、および Liberty の機能を含む OSGi フレームワークです。

前の図では、ランタイムは、カーネル、JVM、 Liberty フィーチャー、および 2 つのアプリケーションをホストするコンテナーを含む OSGI フレームワークです。

カーネル・ランチャーがシステムをブートストラップして、OSGi フレームワークを開始します。 構成が解析され、構成されているフィーチャーがフィーチャー・マネージャーによってロードされます。 カーネルは、OSGi サービスを広範囲に利用して非常に動的なランタイム環境を実現します。 OSGi Configuration Admin Service でシステム構成を管理し、OSGi Declarative Services コンポーネントでシステム・サービスのライフサイクルを管理します。 ファイル・モニター・サービスはアプリケーションと構成ファイルの変更を検出し、ロギング・サービスはメッセージとデバッグ情報をローカル・ファイル・システムに書き込みます。 以下の図に示しているように、カーネルには、フィーチャー・マネージャー、ファイル・モニター、ロギング・サービスのほか、 構成管理や宣言型サービスの処理を行うための OSGi リソースが含まれています。

図2: Liberty カーネル
カーネル・フローチャート

前の図では、 Liberty カーネルは、OSGI Configuration Admin、OSGI 宣言サービス、ファイル・モニター、およびロギング・サービスを含むフィーチャー・マネージャーで構成されています。 フィーチャー・マネージャーと OSGI Declarative Services はフィーチャー・バンドルに接続されます。 OSGI Configuration Admin とファイル・モニターは server.xml ファイルに接続さます。 ロギング・サービスはトレース・ログに接続されます。

フィーチャーは、システム構成ファイル (server.xml ファイルとその他の組み込まれたファイル) で指定されます。 サーバー構成ファイルから OSGi Configuration Admin Service に情報を取り込み、このサービスがフィーチャー構成をフィーチャー・マネージャー・サービスに注入します。 フィーチャー・マネージャーは各フィーチャー名を、そのフィーチャーを提供するバンドルのリストにマップします。 バンドルが OSGi フレームワークにインストールされ、開始されます。 フィーチャー・マネージャーは、 サーバー稼働中にフィーチャーを動的に追加および削除して、構成変更に対応します。 以下の図に示しているように、OSGi Configuration Admin Service は、server.xml ファイルから構成を読み取って、 フィーチャー構成をフィーチャー・マネージャーに注入します。 フィーチャー・マネージャーは、各フィーチャーを提供するバンドルからバンドル・リストを読み取り、OSGi フレームワークにこれらのバンドルをインストールして開始します。

図3: フィーチャー管理
機能管理フローチャート

上の図では、フィーチャー・マネージャーには OSGI Configuration Admin が含まれています。 OSGI Configuration Admin は、server.xml ファイルから構成を読み取って、フィーチャー・マネージャーに注入します。 フィーチャー・マネージャーは、useful-3.2.mf ファイルのバンドル・リストを読み取って、OSGI フレームワークにフィーチャー・バンドルをインストールして開始します。

ランタイム・サービスには、指定が必要な構成を最小限にするために、構成デフォルト設定が用意されています。 必要なフィーチャーと、システム・デフォルト設定に対する追加やオーバーライドを server.xml ファイルに指定します。 include 構文を使用して、親 server.xml ファイルにリンクされるいくつかの別個のファイルに構成することを選択できます。 サーバー始動時、またはユーザー構成ファイルの変更時に、カーネルの構成管理は構成を解析し、システム・デフォルト設定の上にそれを適用します。 構成が更新されるたびに、各サービスの構成プロパティー・セットがサービスに注入されます。 以下の図に示しているように、構成アドミニストレーターは、カーネル内のバンドルからデフォルト構成を読み取り、 このデフォルト構成の上にユーザー指定の構成を適用し、 マージされた構成をフィーチャー・バンドルに注入します。

図4: 構成管理
構成フローチャート

上の図では、OSGI Configuration Admin はカーネル・バンドルとフィーチャー・バンドルからデフォルト構成を読み取って、デフォルトにユーザー構成をマージし、バンドルに注入して戻します。 マージされた構成は server.xml ファイルに送信されてから、オプションで他の XML ファイルに送信されます。

OSGi Declarative Services コンポーネントを使用して、個別のサービスに機能を分解し、それらのサービスを必要なときだけアクティブにするようにします。 この動作により、ランタイム環境が「late (ランタイム・エレメントを必要時のみにロード) および lazy (最小数のエレメントをロード)」 になり、占有スペースを小さくし、起動を速くすることができます。 OSGi サービス・レジストリーに宣言型サービスが追加され、実装クラスをロードせずに、サービス間の依存関係を解決できます。 サービスのアクティベーションは、サービスが使用されるとき (サービス参照が解決されるとき) まで遅延させることができます。 各サービスの構成は、サービスをアクティブ化する際に注入され、その後、構成が変更されると再注入されます。