目次


エンタープライズOSGi入門

第1回:OSGi 概要と実行環境の導入

Comments

コンテンツシリーズ

このコンテンツは全#シリーズのパート#です: エンタープライズOSGi入門

このシリーズの続きに乞うご期待。

このコンテンツはシリーズの一部分です:エンタープライズOSGi入門

このシリーズの続きに乞うご期待。

このところ、Java のモジュール化技術として OSGi が話題に上ることが多くなってきました。OSGi はもともと組込機器向けの Java や、Eclipse プラグインの開発において広く普及してきましたが、最近ではエンタープライズ Java の領域でも OSGi を活用しようという動きがあります。2010年 3月に仕様が確定した OSGi R4.2 では、エンタープライズ Java における OSGi の標準仕様として” OSGi Service Platform Enterprise Specification” (以下、Enterprise OSGi) が規定されています。また、主要なアプリケーション・サーバーでは様々な形で OSGi の採用が進んでいます。

現在 OSGi が注目されている理由は、OSGi が Java のランタイム環境 (JavaVM) におけるモジュール化機構を補完して強化することが可能なためです。また、仕様策定や実装の面でも既に長い歴史があり、比較的枯れているという点も見逃せません。実際、Java SE 7 では新たなモジュール化機構を導入することが検討されていましたが、既に OSGi がデファクト・スタンダードとなっている現状を踏まえて、OSGi に歩み寄る方向で調整が行われています。

この連載では、エンタープライズ Java のエンジニアにとって馴染みの薄かった OSGi に親しんでいただくために、サンプル・コードを動かしながら、OSGi によって何が変わるのかを具体的に見ていきたいと思います。OSGi のランタイムとしては、2010年 5月にリリースされた ”WebSphere Application Server V7 Feature Pack for OSGi Applications and Java Persistence API 2.0” (以下、OSGi FP) を利用します。

連載は全3回を予定しています。

  • 第1回:OSGi 概要と実行環境の導入
  • 第2回:OSGi のエンタープライズ拡張仕様を紐解く
  • 第3回:OSGi を使いこなすためのモジュール設計

OSGi概要

OSGi の仕様は、”OSGi Alliance” (http://ww.osgi.org/) という非営利団体によって標準化が行われており、主要なメンバーとして、日立 /NEC/Mitsubishi/NTT などの日本企業の他、IBM/Oracle/RedHat/SpringSource(VMware) など、多くの企業が参画しています。

OSGi はもともと ”Open Service Gateway Initiative” の略称で、その名の通り通信機器などの組み込みソフトウェアを Java ベースで実装するためのプラットフォームとして仕様策定が進められてきました。その後、モジュール管理の仕組みとしての優位性が評価され、応用分野が車載機器やモバイル端末などに拡大していきました。2003年には Eclipse プラグインの実装基盤として OSGi が採用されたことにより、水面下ではありますが一般の Java プログラマーに恩恵をもたらす技術として普及が進むことになります。(Eclipse3.0 からプラグイン導入時の再起動がオプションになったことを覚えていますか?実は OSGi のおかげだったのです。)

OSGi の提供する機能のうち、重要なものは以下です。

  • ランタイムにおけるモジュール間の依存関係の解決
  • ランタイムにおけるモジュールのバージョン管理
  • モジュールのライフサイクル管理
  • モジュール・レジストリーやセキュリティーなどの基盤サービス

バンドル (Bundle): OSGi におけるモジュールの単位

OSGi では、モジュールをバンドル (Bundle) という単位で管理します。バンドルとは、簡単に言うと JAR ファイルに OSGi の規定するメタデータを付加したものです。OSGi コンテナはこのメタデータを参照して依存関係の解決やライフサイクル管理を行います。

OSGi におけるモジュール 「Bundle」
OSGi におけるモジュール 「Bundle」
OSGi におけるモジュール 「Bundle」

バンドルは、OSGi コンテナのない通常の環境では単なる JAR ファイルとして扱えますので、従来の Java 環境との親和性が高いのも特徴のひとつです。

バンドル間の依存性解決

OSGi が提供する重要な要素が、バンドルに閉じたクラス参照機構の提供と、Import-Package/Export-Package によるバンドル間の依存関係の明示です。

通常の Java 環境では、JAR ファイルでモジュールを分割していたとしても、実行時にはクラスパスで指定された全てのクラスがフラットな空間に読み込まれてしまい、モジュール単位 (JAR 単位) での参照制限を行うことが困難でした。結果として、モジュール間での意図しないクラスの競合などが発生するリスクがあります。典型的なのが、「xxx.jaryyy.jar がいずれも xerces.jar に依存しているが、必要な xerces.jar のバージョンが異なる」というケースです。特に、依存関係が複数階層に及ぶ場合、依存関係を手動で追跡することは困難を極め、実行環境で初めて問題が発覚するということが少なくありません。

問題は、通常の Java 環境では実行時のモジュール管理機能が不十分だということに起因しています。そこで、OSGi では以下のアプローチによってこの問題を解決しています。

  • クラスパスの参照はバンドル毎に分離する (クラスローダーをバンドル別に作成)
  • Export-Package でバンドル外部に公開するインターフェースを明示する (Java のパッケージ単位)
  • Import-Package でバンドルが依存するインターフェースを明示する (Java のパッケージ単位)
  • OSGi コンテナがバンドルのロード時に依存関係をチェックする

また、OSGi のバンドルにはバージョン番号が指定できるようになっており、依存関係を指定する際に「バージョン 2.0.0 以上」のように範囲指定を行うことも可能です。また、依存関係は「必須」「オプション」のいずれかが指定できるため、例えば「ロギング機能を提供するバンドルが利用可能であればログを出力する」といったように、環境に合わせてバンドルの挙動を柔軟にカスタマイズすることも可能です。

OSGi による依存性解決
OSGi による依存性解決
OSGi による依存性解決

ライフサイクル管理と動的なモジュール交換

OSGi ではバンドルのライフサイクルを定義しており、バンドルをインストールして実行するところから、停止してアンインストールするところまでの一連のステートと、ステートが変更になる際に実行されるライフサイクルメソッドが規定されています。ライフサイクルメソッドは BundleActivator のサブクラスに実装し、バンドルのメタデータで実装クラスを指定します。

Bundle のライフサイクル
Bundle のライフサイクル
Bundle のライフサイクル

このように、バンドル単位でのライフサイクルが規定されていることで、モジュール (バンドル) を動的にロード・アンロードすることが可能になり、その際の挙動も自由に指定することができるようになっています。

従来、エンタープライズ・アプリケーションの分野では、このような動的なモジュールの交換はあまり必要とされていませんでした。というのも、一般的な Web システムではスケールアウト構成を組むことで部分的なメンテナンス停止を許容するように設計されていることが多く、単一システムのレベルでの動的なモジュール交換は必須ではなかったからです。

しかし、動的なモジュール交換のニーズは本当に皆無なのでしょうか?裏を返せば、動的なモジュール交換が技術的に困難だったために、スケールアウト構成などで工夫して対処してきたと考えることもできます。あくまで筆者の私見ですが、OSGi の登場によって、今まで抑圧されてきた「モジュールの動的交換」のニーズが表面化する領域もあるのではないかと考えています。

実行環境の導入

本連載では、Enterprise OSGi に対応したアプリケーション・サーバーとして、WAS7.0 に OSGi ベースのアプリケーションを利用するための Feature Pack(OSGi FP) を適用したものを利用します。

実は、WAS は 6.1 から内部が OSGi 化されていたのですが、ユーザーアプリケーションは従来通り EAR/WAR でのデプロイを行うようになっていました。OSGi FP を適用することで、ユーザーアプリケーションも OSGi バンドルとしてデプロイすることが可能になります。

導入の手順は次のようになります。

  1. WAS7.0 のインストールと FixPack9 の適用
  2. IBM Installation Manager のダウンロードとインストール
  3. OSGi FP の導入
  4. サーバー・プロファイル作成
  5. サンプルアプリケーションの導入と実行

WAS7.0 のインストールと Fix Pack 9 の適用

【FAQ】 WebSphere Application Server を最新レベルにするには を参照し、WAS7.0 に最新の Fix Pack (FP9 以上) を適用してください。

導入済みの WAS7.0 の環境がない場合は、WAS7.0 評価版、ないしは無償の WAS7.0 開発者版をご利用ください。

IBM Installation Manager のダウンロードとインストール

OSGi FP は、IBM Installation Manager から導入することができます。(今後、IBM 製品の導入は Installation Manager に統合されていく予定です。)

次のページにダウンロード先へのリンクがあります。

最新の Installation Manager (2010/6/14 現在は 1.3.4.1) のダウンロード先 (HTTP) のリンクを選択します。

ダウンロードには IBM ID によるログインが必要ですので、アカウントを作成されていない場合はこの機会にご登録ください。(無償)

ダウンロード画面では、対象のプラットフォームの ”Download now” を選択します。

ダウンロードした zip ファイルを展開し、install.exe(install.sh) を実行します。
パッケージのインストール画面で、”IBM Installation Manager” にチェックを入れ、「次へ」を押してください。

次に、使用条件に同意し、インストール先のディレクトリー (任意) を指定します。
指定した内容に誤りがないことを確認し、「インストール」を押します。

インストールが完了したら、Installation Manager を再起動してください。

再起動後に、IBM ID とパスワードの確認がありますので入力してください。

OSGi FP の導入

OSGi FP は導入の前提条件として WAS7.0FP9 以上を必要としますが、Installation Manager の現在のバージョンでは WAS7.0 を認識することができませんので、最初に WAS7.0 の登録情報をインポートする必要があります。

Installation Manager の初期画面で「インポート」を選択します。

WAS7.0 のインストール・ディレクトリーを指定して、「次へ」を押します。

共有リソース・ディレクトリーが未登録の場合、登録を求められますので、十分な空き容量のある適当なディレクトリーを指定してください。

要約情報を確認し、問題がなければ「インポート」を押します。「インポートは完了しました」というメッセージが表示されれば、無事にインポートが行われています。

Installation Manager の初期画面に戻り「インストール」を選択します。

“IBM WebSphere Application Server V7 Feature Pack for OSGi and Java Persistence API 2.0” にチェックを入れ、「次へ」を押します。(前のステップで WAS7.0 の登録情報のインポートに失敗していると、次へ進めません。)

使用条件に同意し、FP の適用対象となるWASのインストール・ディレクトリーを指定します。

インストールするフィーチャーの選択では、”OSGi Applications” を選択してください。(”Java Persistence API 2.0” は必要であれば選択してください。)

要約情報を確認し、「インストール」を押します。
インストールが完了したら、「プロファイル管理ツール」にチェックを入れた状態で「終了」を押します。

サーバー・プロファイル作成

前のステップの最後でプロファイル管理ツールを起動していますので、プロファイル管理ツールの「ようこそ」画面が表示されているはずです。
「プロファイル管理ツールを起動」ボタンを押します。

OSGi に対応した新しいサーバー・プロファイルを作成するため、右上の「作成」を押します。(既存のサーバー・プロファイルを OSGi 対応にする場合は「拡張」を選択してください。)

環境の選択画面では、「OSGi Applications Feature付きApplication Server」を選択します。

後は通常通りサーバー・プロファイルを作成してください。

サンプルアプリケーションの導入と実行

OSGi FP を適用すると、<WAS_HOME>/feature_packs/aries ディレクトリー以下にツールやサンプルアプリケーションが導入されます。

samples/blabber の下に簡単なアプリケーションが提供されていますので、実際に導入して動かしてみましょう。詳細な導入手順は Readme.txt に記載されていますので、ここでは Windows 環境での導入手順の概略のみ説明します。

以下の項目は環境に合わせて適宜読み替えてください。
<WAS_HOME>: WAS導入ディレクトリー
<PROFILE_NAME>: OSGi FPを有効にしたプロファイル名
<NODE_NAME>: ノード名(管理コンソールで確認可能)

まず、WAS を起動します。(<WAS_HOME>\profiles\<PROFILE_NAME>\bin\startServer.bat server1)

次にコマンドプロンプトを起動し、<WAS_HOME>\feature_packs\aries\samples\blabber へ移動して、次のコマンドを実行すると、WAS に組み込まれた Derby 上にデータベースが作成されます。

> ..\..\..\..\derby\bin\embedded\ij.bat createBlabberDb.sql

データソース作成などの環境設定を行う Jython スクリプトが提供されていますので、実行します。

> ..\..\..\..\profiles\<PROFILE_NAME>\bin\wsadmin.bat -f blabberSampleInstall.py setupOnly server1 <NODE_NAME>


--------------
SETUP COMPLETE
--------------

と表示されれば、スクリプトの実行は完了です。

次に、アプリケーションが参照する OSGi バンドルを登録します。WAS の管理コンソールの「環境 – OSGi bundle repository - 内部 bundle repository」を選択します。

「新規作成」ボタンを押し、<WAS_HOME>\feature_packs\aries\installableApps\com.ibm.json.java_1.0.0.jar をアップロードします。「ローカル構成が変更されました」というメッセージが表示されたら、「保存」をクリックして構成を反映します。

最後にアプリケーションを登録しますが、一旦EBAファイル (Enterprise Bundle Application、通常の EAR ファイル相当) をアセットとしてインポートし、アセットを参照する BLA(Business Level Application) を登録するという手順を踏みます。EBA ファイルに関しては次回詳しく説明します。

WAS の管理コンソールの「アプリケーション – アプリケーション・タイプ – アセット」を選択します。

「インポート」ボタンを押し、<WAS_HOME>\feature_packs\aries\installableApps\com.ibm.ws.example.blabber.app.eba をアップロードします。その他の設定はデフォルトのままで、インポートを行います。「ローカル構成が変更されました」というメッセージが表示されたら、「保存」をクリックして構成を反映します。

次に、「アプリケーション – アプリケーション・タイプ – ビジネス・レベル・アプリケーション」を選択します。

「新規作成」ボタンを押し、アプリケーションの名前を指定します。(任意ですがここでは blabber としています。)

「適用」を押し、「ローカル構成が変更されました」というメッセージが表示されたら、「保存」をクリックして構成を反映します。

まだ BLA の中は空なので、起動可能な状態になっていません。
新しく追加した BLA をクリックし、詳細設定画面を開きます。「デプロイ済みアセット」の「追加」のプルダウンから、「アセットの追加」を選択します。

登録済みの ”com.ibm.ws.eba.example.blabber.app.eba” を追加します。

オプションの設定はデフォルトのまま追加を行います。「ローカル構成が変更されました」というメッセージが表示されたら、「保存」をクリックして構成を反映すると、BLAが起動可能な状態になります。

BLA を選択して、「開始」ボタンを押してください。

ブラウザーから http://localhost:9080/blabber を開くと、次の画面が表示されます。(ポート番号は環境に合わせて読み替えてください。)

“Click here to sign-up!” を押してユーザー登録を行ってからログインすると、次のような Twitter ライクな画面が表示されます。

第1回:まとめ

今回は、OSGi の概要と、エンタープライズ分野への広がりについて説明し、OSGi アプリケーションの実行環境として WAS V7 Feature Pack for OSGi Applications の導入手順をご紹介しました。
次回からは、この環境を利用して、Enterprise OSGi の仕様や使いどころについて解説していきたいと思います。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=WebSphere
ArticleID=496531
ArticleTitle=エンタープライズOSGi入門: 第1回:OSGi 概要と実行環境の導入
publish-date=06212010