初の OSGi DevCon London が先週，Hammersmith Novotel で JAX London と共に開催された。
プレビューで公開されていた Kirk Knoernschild 氏のキーノートは，立ち見が出るほどの盛況だった。内容 (スライド参照) としては OSGi に直接フォーカスしたものではなく，どちらかといえばソフトウェアの複雑性，あるいは今後のプロジェクトが抱えるであろう問題を取り扱ったものだった。いわく，過去のソースコード量の増加を分析すると，その時点までに記述されたソースコードと同じ行数が，次の７年間で作成されていることが確認できる。これを将来に当てはめれば，2010 年までに作られたものと同じ量の新たなコードが，2017 年には存在していることになる。
ソフトウェアの規模が大きくなるとシステムの複雑性も増加する。しかもコードは書く回数より読まれる回数の方が多いのが普通だから，複雑性に対処するには，システムを理解可能な形式に整理しておく必要がある。この問題に対する Kirk の答えはモジュール化だ。現在の Java スペースには，上位のサービスから下位のパッケージやクラスにまで及ぶ，モジュールの連続構造が存在している。この２つのグループのすき間を埋めるのが Modularity だ。複数のパッケージをモジュールに集約し，それが複数で協調作業することによって，最終目標のサービスを提供する。Kirk は (互いに自身のモジュールとして) 必要なサービスの多種多様な組み合わせが，エンドユーザアプリケーションのための，より高レベルなサービスを構成する例を見せてくれた。
Peter Kriens 氏は，OSGi の高度なトピックを取り扱った広範なプレゼンテーションとチュートリアルを行った。内容は主にサービス指向設計に関するものだ。要するに OSGi のモジュール化の側面を一度離れて，OSGi サービスへのステップを次に目指すならば，その論理的結論は，サービスとその相互関連の面からシステムを理解することである，ということだ。
氏はまた，OSGi サービスを JMX beans として使用する例を見せた。それが関連性を持つサービスに対してどのように発行 (publish) されているか，またリスナがそれをどのように消費 (consume) しているかを検討することが目的だ。面白いことに氏は，LogReaderService の設計について議論しているとき，Whiteboard パターン の採用には何か間違いがあるのではないかと思ったという。特定のインターフェースに一致したすべてのリスナサービスにブロードキャストするように，サービス依存性を利用した方がもっとシンプルなのでは，と考えたのだ。宣言型サービス (Declarative Service) の一般化 (ブループリント(Blueprint)モデル）によって，サービスをセットアップしたり結合したりすることは容易になっている。他のモジュールから何らかのフィードバックを受けるためには，登録型サービス (Registering Service) を利用するのがおそらくは正しい方法なのだろう。
その日は OSGi tooling が２回登場した。最初は Chris Aniszczyk 氏が，(baseline API checking など) PDE に組み込まれたツールのデモをいくつか見せてくれた。そして夜にはさまざまなツールを議題とした，OSGi 開発者によるパネルディスカッションが行われた。中でも maven-bundle-plugin で使用されている Bnd については，OSGi バンドルの構築手段として何度も取り上げられた。SpringSource の bundlor も同様だ。Eclipse Virgo プロジェクトが最近になって承認されたので，このプロジェクトの build train にも今後は多くの開発者の注目が集まるだろう。一方では Maven Tycho プロジェクト（バンドルをマニュフェスト優先あるいはPOM優先でビルドできるようにするもの) に進展があり，すでに２つの Eclipse プロジェクトで利用されるようになっている。最後に話題となったのは，Sigil をベースとする Ant-Ivy である。このプロジェクトは最近，自身のホスティングに移行している。そして今回の結論のひとつとして，以上のものを必要に応じてソースからチェックアウトするための Maven SCM URL が，バイナリ Eclipse OSGi のバンドルに追加されることになりそうだ。
Oracle の Shaun Smith 氏が OSGi と Java 永続化 API に関するプレゼンテーションを行った。今回の OSGi 4.2 エンタープライズ仕様には JPA サービスが含まれている。これは OSGi 環境において，オブジェクトのデータベースへの永続化を可能にするものだ。さらに (OSGi ではない) JPA 向けに書かれたプログラムにも (静的な) ファクトリが提供される予定だ。動作環境が適当であれば，これによって OSGi スタイルのサービスが利用可能になる。JPA のリファレンス実装としては EclipseLink があるが，OSGi の JPA サービスリファレンス実装も同じチームによる開発が予定されている。
間に合わなかったプレゼンタの終演間際に立ち寄ってみると，Paremus の Robert Dunne 氏が POSH と Nimble のデモを即興で行っているところだった。前者はバンドルの開始，リスト，設定をポータブルに実行できるシェルである。もう一方の Nimble の resolver は，アプリケーション(とその依存するもの)をオンデマンドで，自動的にロードするものだ。(David Savage 氏が以前，完全な Spring ベースの Web アプリケーションをシェルにダウンロードする，86 文字の インストールコマンドを tweet した ことがある)
クラウドコンピューティングへの OSGi の応用例が２つ紹介されていた。ひとつは Apache Felix Karaf を使用して Amazon EC2 上にインスタンスの生成とデプロイを行うもの，もうひとつは，Pax Exam を使ってクラウド上で OSGi アプリケーションのテストを行うものだ。EclipseCon/OSGi DevCon の期間中には，OSGi クラウドコンピューティング ワークショップも行われて，OSGi をグリッドモードで使用するときの問題点や教訓が議論された。
OSGi の新機能に関するプレゼンテーションが２つあった。Spring にインスパイアされたような Blueprint サービス がひとつ。もうひとつは次期 OSGi 4.2 Enterprise Expert Group に期待されている機能であるデータアクセスやWebアプリケーション，バンドルとJDNI の安全なアクセス方法のJMXコントロール，ClassLoader 的に安全な JDBC トランザクションなどだ。
OSGi DevCon London の成功により，Santa Clara の OSGi DevCon にも期待が持てそうだ。OSGi DevCon の期間中には Enterprise Expert Group から，上述の JPA やWebコンテナ(OSGi エンジンで Web アプリケーションのホストを可能にする)，その他 JMX やデータベースアクセスなどの機能に関する発表があると期待されている。EclipseCon/OSGi DevCon にサインアップすれば，さらに詳細を知ることができる。