本企画では、巨大になったSpringの主要プロダクトを順に取り上げ、その役割や使い方を簡単に紹介している。

第1回目となる前回はSpringの歴史を追いながら、どのようなプロダクトがあるのかを概観した。そして今回からはいよいよ、各プロダクトの紹介に入っていく。

最初に取り上げるのは「Spring Dynamic Modules」。名前を聞いただけでは想像しづらいプロダクトだが、本稿をご覧になれば、その意義をご理解いただけるはずだ。

アプリケーションのダウンタイムを減らすために

SpringFrameworkなどのDIコンテナは、アプリケーションの開発スタイルに進化をもたらした。モジュールごとの実装・テストを容易にし、シンプルで俊敏なアプリケーションの開発が容易になった。しかし、アプリケーションのデプロイのスタイルは依然進化していない。

アプリケーションサーバにJavaアプリケーションをデプロイする場合、warファイルやearファイルの形式で複数のモジュールを1つにまとめてデプロイする。1つのモジュールに変更があった場合はアプリケーション全体を再度デプロイする必要があり、変更のない他のモジュールを停止させなければならない。

Spring Dynamic Modules(以降、SpringDM)は、モジュール単位のデプロイを可能にするプロダクトだ。これにより、依存しない他のモジュールを止めずに機能の追加・変更ができるようになるため、システムの円滑な成長をサポートするプラットフォームと言える。

SpringDMの核となる技術はOSGiである。次の章でOSGiを説明する。

OSGiとは?

OSGiは、動的^※1にモジュールを追加・変更できるJavaのプラットフォームの仕様である。2000年に初版が作成され、現在も改版を続けている。最新版はRelease 4のVersion 4.2^※2である。

※1 本稿では、プログラムを止めずに追加・更新できるモジュールを動的なモジュールと表現する。

※2 http://www.osgi.org/Release4/Downloadからダウンロードできる。

OSGiを実装した代表的な製品を以下に示す。

• Eclipse Equinox
• Apache Felix
• Knopflerfish

それぞれについての説明は割愛するが、興味のある読者は、上記のリンクをたどって各プロダクトのWebサイトをご覧になってほしい。

OSGiのモジュールの単位をBundle(バンドル)と呼ぶ。Bundleは、クラスファイル・リソースファイル(設定ファイル・画像ファイルなど)・マニフェストファイル^※3で構成されたjarファイルである。アプリケーションの開発者はBundleを作成してOSGiのプラットフォームにデプロイする。複数のBundleが連携し合ってアプリケーションを形成する。

※3 jarファイルに関する情報を記述するテキストファイル。jarファイルの仕様で書式が規定されている。

Bundle間の連携は、具体的には以下の2つである。

1. 他のBundleのクラス・インタフェースを使用する
2. 他のBundleのオブジェクトを使用する

1.は、クラスライブラリの使用と同じなので特に説明は必要ないだろう。2.は、サービスレジストリという概念が用いられる。サービスレジストリは、Bundle間で共有するオブジェクトの入れ物である。サービスレジストリに登録されたオブジェクトをサービスと呼ぶ。あるBundleが登録したサービスを他のBundleが利用する^※4(図1)。

※4 サービスレジストリへのサービスの登録や取得はOSGiが規定したAPIを使用して行う。

図1 : サービスレジストリ