製品拡張

製品拡張機能を作成することにより、Liberty の機能を拡張できます。

独自の Liberty フィーチャーを開発し、それらを既存の Liberty サーバーにインストールするか、または、ユーザーに配布できるようにパッケージすることができます。

Liberty で提供されているさまざまなシステム・プログラミング・インターフェース (SPI) を使用して、ランタイム環境を拡張することができます。また、Liberty サーバーを Java™ アプリケーションからプログラマチックに操作するなど、さらに上級のフィーチャーを使用することもできます。

製品拡張

製品拡張は、Liberty のインストール・ディレクトリー ${wlp.install.dir} のように構造化された、ディスク上のディレクトリーです。これは、${wlp.install.dir}/etc/extensions ディレクトリー内の extension-name.properties というファイルによって、Liberty インストール済み環境に定義されます。その後、製品拡張ディレクトリーの内容は、Liberty を拡張するために使用されます。複数の製品拡張をともにインストールできますが、名前は固有でなければなりません。これは、プロパティー・ファイルの命名によって強制されます。デフォルトの製品拡張ロケーション ${wlp.user.dir}/extension にプロパティー・ファイルは不要です。このロケーション内の内容は自動的に検出されて、ランタイムに「usr」製品拡張として認識されます。

製品拡張には通常、1 つ以上の Liberty フィーチャーが含まれますが、Liberty 環境を拡張する任意のコンテンツ (例えば、スクリプトやリソース) を含めることができます。

ベスト・プラクティス: 製品拡張は、Liberty 環境の更新の影響を受けないディレクトリーにインストールします。詳細については、『サービスまたはアップグレードの適用によって変更される可能性があるもの』を参照してください。
図 1. 2 つのフィーチャー (「Supergui」と「App Services」が含まれた Liberty インストール済み環境が示された図
製品拡張ファイルには、次のプロパティーがあります。
com.ibm.websphere.productId=your_product_id
com.ibm.websphere.productInstall=absolute_or_relative_file_path
注: 相対ファイル・パスを使用する場合、そのパスは ${wlp.install.dir} 値のピアでなければなりません。
以下に例を示します。
com.ibm.websphere.productId=org.acme.supergui
com.ibm.websphere.productInstall=supergui/wlp-ext

フィーチャー

Liberty フィーチャーは、定義ファイル (フィーチャー・マニフェスト) と、Liberty ランタイム環境の特定の機能に対応するクラスおよびサービスを提供する OSGi バンドルのコレクションから成ります。

通常のアプリケーションの代わりに Liberty フィーチャーを使用するシナリオ

多くのシナリオで、アプリケーションとしてではなく、Liberty フィーチャーとして機能を実装するのが適している場合があります。以下のリストに、フィーチャーを使用した場合のメリットの一部を示します。
  • フィーチャーはフィーチャー・マネージャー構成によって制御されるため、ユーザー・アプリケーション管理から分離しています。
  • フィーチャー・コードでは Liberty SPI にアクセスできるため、ランタイム環境とのより深い統合が可能になります。
  • フィーチャーは、server.xml ファイルからユーザー指定の構成を受け取って、開発ツールで、ツールを変更することなく、その構成設定を公開できます。
  • フィーチャーは、クラスおよびサービスを相互に、またユーザー・アプリケーションに簡単に公開できます。
  • フィーチャーは、アプリケーション・コンテナーに依存することなく、極めて軽量にすることができます。
  • フィーチャーを使用して特定のプログラミング・モデルを拡張することができます。 例えば、ユーザー・フィーチャーで、カスタムの Blueprint 名前空間ハンドラー または Blueprint アノテーションのサポートを OSGi アプリケーション・プログラミング・モデルに追加することができます。
注: フィーチャーは通常、他のアプリケーション・サーバーに直接移植することはできません。移植性が重要な場合は、仕様に準拠したアプリケーションを使用してください。

サーバーでのフィーチャーの使用

Liberty サーバーでユーザー作成のフィーチャーを使用するには、そのフィーチャーを製品拡張ディレクトリーにインストールする必要があります。これは、事前定義の「ユーザー製品拡張」ロケーションにすることも、Liberty のインストール・ディレクトリーの外部にある拡張にすることもできます。次に、フィーチャー名をサーバー構成に追加できます。

ユーザー製品拡張は、サーバーが追加フィーチャーを検索する事前定義のディレクトリーです。 フィーチャー定義 .mf ファイルを ${wlp.user.dir}/extension/lib/features ディレクトリーにコピーする必要があります。また、バンドル .jar ファイルを ${wlp.user.dir}/extension/lib ディレクトリーにコピーする必要があります。

ユーザー作成のフィーチャーは、製品フィーチャーと同じ方法でサーバー構成に追加されます。別のプロバイダーからのフィーチャーとの名前の競合を回避するために、製品拡張の一部であるフィーチャーの前に拡張名を付加する必要があります。usr/extension/lib ディレクトリー内のフィーチャーの場合、デフォルトの接頭部は usr: です。

例えば、simple-1.0 というフィーチャーを ${wlp.user.dir}/extension/lib ディレクトリーにインストールした場合、以下のようにそのフィーチャーを server.xml に構成する必要があります。
<featureManager>
    <feature>usr:simple-1.0</feature>
</featureManager>
myFeature というフィーチャーを独自のロケーションにインストールし、${wlp.install.dir}/etc/extensions/myExt.properties ファイルで製品拡張を定義した場合、以下のようにそのフィーチャーを server.xml ファイルに構成する必要があります。
<featureManager>
    <feature>myExt:myFeature</feature>
</featureManager>

サーバーの始動時に、フィーチャーがフィーチャー・マネージャーによって検出され、バンドルが OSGi フレームワークにインストールされて開始されます。

Liberty フィーチャーの追加および削除』および『フィーチャーの管理』も参照してください。

アプリケーションからのフィーチャーのプログラマチックな使用

フィーチャーは、クラスおよびサービスをアプリケーションに公開できます。

アプリケーション用に Java クラスを公開するには、フィーチャー・マニフェストの IBM-API-Package ヘッダーにクラス・パッケージをリストする必要があります。IBM-API-Package ヘッダーにクラス・パッケージをリストすると、アプリケーション・クラス・ローダーからクラスが可視になります。API パッケージの可視性は、API 可視性タイプを使用して制御できます。 Liberty フィーチャー・プロジェクト用の API および SPI パッケージの指定』を参照してください。

サービスを OSGi アプリケーションで使用できるようにするには、フィーチャー・マニフェストの IBM-API-Service ヘッダーにサービスをリストする必要があります。フィーチャーによって OSGi サービスが提供され、アプリケーションからプログラマチックにそのサービスを参照できます。

サービスは通常、アプリケーション (または他のフィーチャー) から検出できるように、OSGi サービス・レジストリー (SR) に登録する必要があります。OSGi アプリケーションおよび他のフィーチャーは、SR から直接ルックアップを実行するか、Blueprint や OSGi Declarative Services などの機能を使用してサービス依存関係を注入できます。Java EE アプリケーションは、JNDI を使用してサービスを検出する可能性が高いと思われます。Liberty では、SR と JNDI のフェデレーションが用意されているため、Java EE アプリケーションは JNDI を使用して SR のサービスを検出できます。詳細については、『OSGi サービス・レジストリーの使用』を参照してください。

Web アプリケーションとしてのフィーチャーの公開

Liberty フィーチャーを Web アプリケーションとして公開するために、フィーチャー内の OSGi バンドルを Web アプリケーション・バンドル (WAB) として公開できます。バンドルに必要な OSGi ヘッダーに加えて、Web-ContextPath ヘッダーを使用して Web アプリケーションのコンテキスト・パスを指定できます。

以下に例を示します。

Web-ContextPath: myWABapp
Bundle-ClassPath: WEB-INF/classes

構成の注入および処理

フィーチャーを使用する主なメリットは、server.xml ファイル (および組み込みファイル) でユーザーが簡単に構成できる点にあります。構成ファイルは Liberty のカーネルによってモニターおよび解析され、変更があるたびに、結果のプロパティー・セットを関連コンポーネントに注入できます。

Liberty 構成は、カーネルの OSGi Configuration Admin (CA) サービスによって管理され、その仕様に従ってアクセスできます。構成プロパティー・セットはパーシスト ID (PID) によって識別されます。PID を使用して、プロパティーを受け取るために登録されたコンポーネントに server.xml ファイル内のエレメントを関連付けます。

例えば、PID com.acme.console を使用して CA サービスにフィーチャーを登録した場合、ユーザーは、server.xml ファイルで以下の構成を指定できます。
<com.acme.console color="blue" size="17"/>
これにより、フィーチャーは以下のプロパティーを受け取ります。
  • color="blue"
  • size="17"

オプションとして、OSGi Metatype 記述子を使用して、構成プロパティーを記述するメタデータを提供できます。記述子を使用すると、Liberty プロファイルが生成して Developer Tools が使用する構成スキーマに構成メタデータが組み込まれるため、サーバーの構成時に構成プロパティーが自動的にアプリケーション開発者に提示されます。

構成プロパティーの受け取りおよび記述について詳しくは、『サービスによる構成データの受け取りを可能にする』を参照してください。

Liberty での Declarative Services

大きなフィーチャーまたは複雑なフィーチャーでは、多くの場合、OSGi Declarative Services (DS) を使用することでメリットを享受して、フィーチャーを複数のサービスで構成したり、依存関係および構成プロパティーの注入を管理したりすることができます。 DS を使用すると、サービスの lazy アクティベーションが可能になり、サービスを使用するまで Java クラスのロードを遅延させ、また依存関係に基づいてサービスのアクティベーションを順序付けできます。Liberty 製品内のほとんどのフィーチャーは、DS によって管理されます。

OSGi Declarative Services を使用した拡張フィーチャーの構成』も参照してください。


トピックのタイプを示すアイコン 概念トピック



タイム・スタンプ・アイコン 最終更新: Monday, 5 December 2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-libcore-mp&topic=cwlp_prod_ext
ファイル名: cwlp_prod_ext.html