先週、ロンドンでOSGi Community Eventが、JAX Londonと一緒に開催された。カンファレンスでの発表は、広範囲な環境にわたり、JavaEEの移行とクラウド コンピューティングから組込みデバイスやAndroidまで及んだ。
OSGiによるエンタープライズJava
近年、サーバー側でOSGiを使うケースが非常に増えている、大抵のJava EEプラットフォームの実装にOSGiが使われているばかりでなく、アプリケーション モデルがOSGiランタイム上で直接走るぐらいに、浸透してきている。こうした流れの始まりの一つが、一般のJava EEサービスをOSGiサービス(JTA, JPA, JNDI など)にマップした、Enterprise Specificationのリリースである。これがプラットフォーム提供者の間で普通になってきている。たとえば、Apache Aries やEclipse Gemini (Eclipse Virgo、以前の Spring DM Serverによって使われた）は、Java EEアプリケーションの開発者に対して、移行方法を提供している。いくつものチュートリアルや発表は、その聴衆に、正面からこのことを訴えていた。そのような例が、 Ian Robinson氏のApache Ariesや Glyn Normington氏のEcipse Virgo アップデートの講演である。
OSGiランタイムへの移行における体験談もあり、移行したいと考えている人たちへのアドバイスも含んでいた。最初、SAPの Katya Todorova氏が NetWeaverプラットフォームのOSGi化を話した。最初のアプローチ － すべてをラップして、より高いレベルからOSGiを隠そうとした － うまくいかなかった。原因のほとんどが、OSGiが体系化しているところを力づくでこじ開けるようなやり方をとったからである。次のアプローチはずっとうまくいった。OSGiをその意図のとおりに使い、それから、コンポーネントとやりとりするOSGiサービスを提供した。（ Peter Kriens氏の表現によると、長年抱いてきた信念は、最も注目されるモジュール性よりも、OSGiのμServices が、仕様の中で最も重要な部分である、ということである。）
Gerd Kachel 氏は、アプリケーションをJBossからOSGiに移行することについて話した。彼の観察によると、（複数のコンポーネントを持つ）よく構造化されているプロジェクトは、ほとんどの場合、「大きな泥んこの塊」のコンポーネントよりもずっとOSGiに移行するのが簡単である。モジュールを分割する作業は、既に済んでいるからである。しかし、OSGiに移行した途端、この移行は、コンパイル時と実行時の両方で強制される。Gerd氏のケースでは、彼のアプリケーションは、すでにMBeanサービスを使って分割されていたので、OSGiサービスへのマッピングは簡単だった。特性をサービスプロパティに、メソッドをサービス インターフェースのメソッドに、依存性を関連サービスにマップした。 Katya とGerd両氏のOSGiへの移行経験をまとめると：
- 開発者がOSGi に熟達するには、1ヶ月ほどかかる。
- 既存のモジュールをOSGi サービスに変換するには、約1日かかる
- OSGi モデルと戦えば、負ける。それを使おうとすれば、成功する。
- アプリケーションがよく構造化されていれば、そうでない場合より、bundleにマッピングするのは、簡単になる。
- もしMBeanを使っているなら、OSGi サービスにマッピングする簡単な戦略がある。
- アプリケーションの中で、クラスローダを既に使っていると、OSGi への移行とそのクラスローダとの戦いは、難しくなるだろう。
- もし動的なクラスローディング(class.forName) を使っているなら、ほとんど修正が必要である。しかしOSGi サービスにマップできる。
- もしすでに IOCモデル(Guice, Spring など) を使っていれば、移行は、大抵非常に簡単である。
もう一方で
OSGiの領域のもう一方が組込みとマイクロデバイスである。いくつかの発表が工業あるいは組込みアプリケーションにおけるOSGi に焦点をあてていた。例えば、 Bernhard Dorminger氏の工業アプリケーションにおけるOSGiでの経験、 Dimitar Valtchev氏のホーム自動化システム用のOSGi、そしてTakefumi Yamazaki氏のOSGiによるi-House実験である。これらは、ProSystの mBSランタイムのような、より小さな組込みシステムを使っている。
モバイルの世界については、Andy Piper氏のOSGi と Android、Andre Bottaro氏のOSGi MEなどいくつかの話があった。これらは、また低パワーのデバイス、もっと公式にはモバイル製品に焦点を合わせたものだった。 Apache Harmonyプロジェクトのモジュール性によって刺激された更なる議論は、 J2SE-1.5よりも小さなプロファイルの持つ、という非公式な提言になった。java.beansのような、より新しいランタイムから、パッケージで Foundation-1.0のような、より小さなプロファイルにすることができそうである。OSGiは、暗黙的には、java.* ネームスペースからpackageをインポートしないので、これは、Import-Packageで簡単に、済ませることはできない。しかし、もっと新しい OSGi 4.3のRequire-Capabilityヘッダーでできるかもしれない。
基調講演とアップデート
Jim Colson氏のプレゼンは、長くて、曲がりくねった道というタイトルで、1999 年にJSR 8として始まり、Eclipse 3.0 でOSGiが採用され、そして、エンタプライズの世界において、現在のような状況になってきたOSGiの進化の歴史を説明した。 初期の Eclipse やOSGiに携わった人たちには、懐かしい話だったかもしれないが、OSGiがこの5年ぐらいで採用されるまでにいかに時間がかかったかを物語っている。今やすべてのJava EEベンダーは、自分たちのランタイムをOSGiベースにしている（JBoss以外は。彼らは、自前のOSGiランタイムを書いている）。
Jim Colson氏は、Apache Harmonyプロジェクトの Tim Ellison氏を招いて進行状況を発表した。Java 5 API の99％が完成し、 Java 6 APIの96％が終わった（そして100％認証されていない）が、Javaのランタイムは、 EclipseベースのRCPアプリケーションやwebサーバーを含んで、ほとんどのアプリケーションを走らせることができる。重要なことは、すべてが入ったOracle JDKと違って、Harmony xDKは、最小10MbのクラスライブラリとVMにそぎ落とすことができる、ことだ。これらは、 Harmony Select, Harmony Core, Harmony More そして Harmony Outとして知られる、いくつかのグループにパッケージ化されている。 Harmony OutだけがUIのコード（そして、これでさえSWTを使うのに不要である）と依存関係が増えているセットを含んでいる。
James Governor氏は、OSGiの重要性についてエネルギッシュな基調講演を行った（講演の全体の雰囲気は、彼のブログに載っているJava the Unipolar Momentで、わかる）。また Peter Kriens氏は、以前の bundle.updateで提起したいくつかの点を含んで、OSGiの将来について話した。
個別の発表に関する詳細な情報ついては、今後、載せていく予定である