Bundleの連携の制御の仕組みを理解しよう！

ネットワーク上にあるBundleも指定できる！

こんにちは。チェンジビジョンの近藤です。「第3回：体験！モジュールの動的な追加と削除」では、OSGiの特徴であるモジュールの動的な追加・削除について説明しました。

「install」コマンドを使うとモジュールの追加が行われますが、実際にモジュールがコピーされているわけではなく、メモリ上での追加しか行わ れていません。そのため新しいモジュールを追加することで、既存の環境において新しい機能を試すことができます。その機能が気に入らなければ、その場で 「uninstall」をすることでモジュールを削除できます。

このようにOSGiコンソールからコマンドを入力することで、Equinoxを止めずに動的にモジュールを追加、削除できます。これにより機能は機 能的に十分かどうかを確認しながら進めるような、インクリメントに開発を進めたいアジャイル開発に活用できるといえるでしょう。

前回触れられませんでしたが、「install」コマンドではネットワーク上にあるBundleを指定できます（以下は、誌面の関係上改行して掲載していますので、注意してください）。

これはオフショア開発などの分散開発を容易にする可能性があります。分散開発時はファイルのやり取りを行うため、ファイルの同期がうまくいかないこ とがありました。実際に動作させているBundleでやり取りをすれば今まで以上に機能的な確認を行いやすいのではないでしょうか。

さて今回はサンプルアプリケーションがどのようにサービスを追加していたのか、ソースコードを基に解説していきます。

サンプルアプリケーションの制御はどのように行われているのか

サンプルアプリケーションでは新しいBundleをインストールし、活性化させるだけで新しいサービスをティッカー表示に追加していました。このティッカーの制御はどうやって行われているのでしょうか。

Bundleの開始・停止を制御するBundleActivator

ティッカーに新しいサービスを追加するにはBundleをインストール（install）するだけではなく、Bundleを起動（start）させる必要がありました。Bundleを起動するとBundleの状態が「ACTIVE」、つまり活性化されます。勘の良い方はこのことからBundleを活性化する時に処理がフックされていることが予想できるのではないでしょうか。

実はその通りで、サービスの追加はBundleを起動する時に行われています。まず「jp.co.thinkit.equinox.hello.service」プロジェクトにある「META-INF/MANIFEST.MF」を開いてください（リスト1）。

リスト1：jp.co.thinkit.equinox.hello.serviceのMANIFEST.MF

第1回で簡単に触れましたが、OSGiではBundleのモジュールとしての定義をMANIFEST.MFに行います。Bundleの起動・停止時に処理を行う場合の制御クラスの指定もMANIFEST.MFにて行います。

Bundle-Activatorというキー名で指定されているクラスがBundleの起動時、停止時の制御を行っているのです。リスト1では「jp.co.thinkit.equinox.hello.service.ServiceActivator」クラスが指定されています。

続いてServiceActivatorクラスを見てみましょう（リスト2）。

リスト2：jp.co.thinkit.equinox.hello.service.ServiceActivatorクラス

（画像をクリックすると別ウィンドウに拡大図を表示します）

リスト1のBundle-Activatorでは、「org.osgi.framework.BundleActivator」インターフェースを実装したクラスを指定します。BundleActivatorインターフェースは、Bundleの起動、停止をフックできます。

OSGiコンソール上でstartコマンドを実行すると起動時の処理をフックするクラスServiceActivatorのstartメソッド（リスト2-1）が呼び出され、コンソールに「Hello OSGi Service」が出力されます。同じようにstopコマンドでは、stopメソッド（リスト2-3）が呼び出され、コンソールに「Goodbye OSGi Service」と出力されます。