とりあえず、前回まででOSGi Bundleの連携からバージョンの切り替えと基礎的なことをやり終えたと思っています。
ここらでちょっとOSGiとVirgoを使ってみての雑感を。
まずは良さそうなところから。
- 同じモジュールであっても、複数のバージョンを管理、共存できる
- 稼働中にモジュールのバージョンアップ、差し替えが可能
- OSGiの本来の面倒さは、SpringとVirgoがそこそこフォローしてくれる
特に、稼働中のモジュールを更新できたり、複数のバージョンが共存できるというのは大きいですよね。複数のユーザに対して、異なるバージョンのAPIを提供したり、アップグレードが容易にできたりするというのは、プラットフォームを提供するような側から見ると、かなり大きなメリットだと思います。一応、Bundleの切り替えはアトミックらしいので、稼働中の切り替えは安心？
続いて、実際に使う時に不満に思いそうなところ、ハマりそうなところを。
- ただのJARファイルが、勝手にOSGi Bundleになるわけではない
- OSGi Bundleが依存するコンポーネントは、OSGi Bundleでなければならない（はず…）
- MANIFEST.MFにエクスポート／インポートするパッケージやBundleに関する情報を書く必要があるため、最初に決めたBundle構成を変更しようとするとコストが高くつきそう
- OSGi Bundleのライフサイクルを知らないと、思わぬ障害を引き起こしそう
- Springのコンポーネントスキャンを使っている割には、結局OSGiのサービスとして公開するインターフェースを設定ファイルに書かなければならない
いかにSpring／Virgoが面倒を見てくれるとはいえ、公開する／依存するパッケージをエクスポート／インポートするというのは、けっこうな負担になると思います。というか、アプリケーションを作る時にOGSiを意識せざるを得なくなります。
さらに、OSGi Bundleが利用できるのはOSGi Bundleである必要がある（と思われる）ので、今まで使っていたライブラリなどをOSGi Runtimeにポイっと放り込んですぐ利用…というわけにはいきません。いちいちMANIFEST.MFにエクスポートするパッケージを書いてあげたり、OSGi Bundleとしてサービスを公開する実装／設定をしてあげる必要があるはずです。さらに使いたいライブラリ自体が別のライブラリに依存していると…って考えると、かなりゾッとすることになります。つまり、色気を出して言語にScalaなんぞを選択していたら、とんでもないことになっていた、というわけですね。
最後に、やっぱり敷居が高いよ、これ。Spring／Virgoに助けてもらっているとはいえ、本来素のOSGi Runtimeだけでこの仕組みを使う場合は、OSGi Bundleの起動／停止APIを実装しなくてはいけないはずで（この辺りがGeminiが面倒を見てくれている…はず）、この辺りも用意しなくてはならない…という話になると、さらに敷居が跳ね上がります。
だから、OSGiって（海外ではどうかは知りませんが、少なくとも日本では）流行ってないんでしょうねぇ。唯一普及しているOSGi Bundleは、Eclipseプラグインだけだと思います。
よって、設計／運用ノウハウがないです。確かにバージョン管理はできますけど、Bundleの依存バージョンの定義とかどう決めるのが適切なのかとか、今のBundleの依存関係をどう管理していくのかとかを放っておくとすぐさまカオスになりそうな予感がしますね。
仕組みとしては面白いのですが、こいつを業務で本格的に活用する日が来るのかなぁ…？
最後に、Spring dm Serverに関する参考資料をちょっと載せておきます。Virgoの前の話ではありますが、OSGiの考え方やVirgoはSpring dm Serverが元なので、参考になると思います。
http://genba-oriented.jp/index.php?title=SpringSource_dm_Server%E3%81%AE%E7%B4%B9%E4%BB%8B
http://d.hatena.ne.jp/keiono/20080708
http://www.wuetherich.com/public/jaxindia-2009-04/JAX-India-Spring-DM-by-example.pdf
仕事の方が忙しくなりそうな雰囲気なので、OSGi／Virgoの勉強は今回はここまでかな？
