OSGiをサポートするとうれしいと思うところ
koichik氏からまたまたコメントをいただきました。ありがとうございます。改めて考えてみるとDIコンテナとOSGiコンテナは違ったレイヤの話だと気づきました。個人的にはOSGiを使うということはパラダイムシフトを起こせるくらいアプリケーション開発に影響を与えると考えています。ちょっと酔っ払ってますので、自分の意図が伝わりにくいかもしれませんが、まとめてみます。DIコンテナはOSGiコンテナの内部で利用するものなのかもしれません。OSGi Bundleはサーバーサイド、クライアントサイドという垣根を取っ払います。そこまで話が大きくなってしまうとSeasarに限った話ではありませんよね。ということで、そんな感じのタイトルに変更しました。
僕自身はOSGi BundleとJARライブラリはほぼ等価のものであると考えています。ただ、JARライブラリと比較して、OSGi Bundleは単純に考えてこれだけの情報が追加されています。
- 依存するライブラリ情報
- このOSGi Bundle自体のバージョン情報
- 他のBundleへ公開するパッケージ情報
- OSGiコンテナに追加するサービス情報
- OSGiコンテナに登録されているサービスを利用する
これらは、クライアントサイドに限った話じゃありません。サーバーサイドでも使えるのではないでしょうか。事実、OSGiを使ったアプリケーションはクライアントサイドに限ったものではなく、どちらでも利用できるような形式になっているものが多いです。
OSGiコンテナは配置されたBundleの組み合わせでアプリケーションの振る舞いを変えられます。配置されているBundleにサーブレットコンテナがあれば、そこにWebアプリケーションが乗っかるかもわからないし、他のアプリケーションやデータへのコネクタを提供するサービスがあれば、それを利用するようなデスクトップアプリの作成に、簡単に利用できることを実現しています。RDBだったり、XML^DBだったり、データソースをこれ!と決め付けないまま開発にすることができます。また、開発しているWebアプリケーションの管理画面は、クライアントサイドのUIを使って作成することもできるわけです。アプリケーションがサーブしているのか、それとも別にサーバーがあるのか、ネットワークにつながっているのか、いないのか、とか、そういう垣根を越えて新しい物が作れるプラットフォームがOSGiだと思ってます。
今のところOSGiに稼動させるアプリケーションのサービスの標準仕様みたいなものは決められてこなかったようですが、それが出来上がったとすると、本当にコードを書かずにサービスだけでシステムがくみ上げられる時代がくるかもしれません。
Percsの設計に関しては、まだそれほど大きくないアプリケーションであるため、SpringなどのDIコンテナは不要だと考えています。*1しかし、ある程度アプリケーションの規模が大きくなって、DIコンテナを導入するほうがわかりやすいような状況になってきた時に導入を考えるかもしれませんが、基本的にDIを実現したいのであればOSGi上で依存するインスタンスを注入するような設計にするでしょう。そっちのほうがBundleの初期化コストを抑制できるはずです。*2
プラットフォーム側でOSGiが広く使われるようになると、DIコンテナはもしかすると使われなくなるかもしれません。依存性の注入は、より基盤に近い部分で行うことができるわけですから。