Distributed OSGiプロジェクトで主要なマイルストンを達成しつつあるため、これまで行ってきたことを見直したり、残りのステップを特定し、なぜこれを最初に行っているかについて話したりする、良い時期であるように思います。
11月に、我々は、来たるOSGi Specificationの4.2リリースに関する設計文書（OSGi用語でRequests for Comment、略称RFC）の初期リリースドラフトの更新(PDF)を公開しました。今月、このリリースの重要な新設計の1つ、RFC119、Distributed OSGiに関するリファレンス実装ソースコード(リンク)をApache CXF(リンク)でリリースしました。
Distributed OSGiプロジェクトは、OSGi Specificationの次回リリースの一部として開始されました。OSGi Specificationの現リリース(リンク)が埋め込みスペースで成功を収めており、エンタープライズスペースで採用され始めていたからです。たとえば、OSGiフレームワークはEclipseプラグインの背後にあり、すべてのアプリケーションサーバーベンダーとほとんどのESBベンダーがOSGiを支持しています。
OSGi Allianceは、2006年9月に、見込まれるエンタープライズエディションの要件をさらに調査するため、公開ワークショップを開催しました（Peter Kriens氏はそれについて素晴らしいバックグラウンドブログエントリ(リンク)を書きました）。その後OSGi Specificationの現リリースは、JSR 291(リンク)で移植されて、Java SEの一部になりました。ワークショップに出席した我々が直面した疑問は、OSGi SpecificationがJava EEの代替物になるべきかどうかと、そうだとすれば、どんな要件を満たす必要があるかということでした。重要な要件の1つは、OSGiサービスが、他のJVMで動作しているサービスを呼び出すことができるということと、可用性、信頼性、拡張性のためエンタープライズアプリケーショントポロジをサポートできるということでした。（現在のOSGi Specificationは、単一のJVMのみのサービス呼び出しの振る舞いについて定義しています。詳細については、Peter氏の素晴らしいワークショップ概要エントリを参照してください。）
2007年1月、第1回Enterprise Expert Groupミーティング(リンク)で正式に取り組みが開始しました。Distributed OSGiはそのセッションで承認された上位要件の中に残っていました。当初は「車輪の再発明（すでに存在しているものを再び一から作ること）」だとか「別のCORBAの作成」といった批判をよく受けましたが、これは誤解に基づくものです。初期ドラフト設計文書（RFC 119）とApache CXFのRIコードは、我々がこうしたことをしていないという事実を明らかにする助けとなるはずです。既存の分散コンピューティングソフトウェアシステムを構成するためにOSGiフレームワークを単に拡張しているのです。RFC 119では、リモートサービス呼び出しが可能なプロトコルとデータフォーマットシステムのタイプの総称表現として「分散ソフトウェア（distribution software）」略称DSWという用語を使用しています。リモートとは、別のJVMまたはアドレス空間内を意味しています。
特定のタイプの分散ソフトウェアを1つ選び、それを標準化することを提案する人もいました。利点は、実行可能コードのシリアル化など、プロトコル特有の機能を利用できるということでしたが、選択肢の減少と制約された状況を招く恐れがありました。代わりに、どんな分散コンピューティングソフトウェアシステムでも使用できる一般的構成機構を定義しました。また、私たちは、実行可能コードのシリアル化のような機能の使用を妨げないようにしました。つまり、必要ならばそうした機能を使用できますが、それは1つのタイプの分散ソフトウェアに特有のものであるため、標準化はされません。
Apache CXFのリファレンス実装のほか、Eclipse ECFプロジェクトやParemusのInfinflow製品が設計の実装を目的としています。また、Eclipse Rienaプロジェクトもそれを検討していると一部の人たちが言っているのを我々は耳にしています。ですからうまくいけば、Distributed OSGiで正しい軌道に乗ることができます。しかし、依然として我々はフィードバックに非常に関心を持っており、現在、実際に仕様になるものを変更する時間があります。また、Distributed OSGiの設計には、複数の分散ソフトウェアシステムコンポーネントを構成するためのディスカバリサービスとSCAメタデータ拡張が含まれています。これらのどちらもまだ公開されていませんが、間もなく利用可能になります。
我々がプロセスのどの段階にいるかを説明するためには、OSGi Allianceの活動に関する背景を簡単に説明することが参考になるかと思います。そのプロセスはJava Community Processと非常に似ています。実際、OSGi仕様はJSR 8として世に出てきて、基本的にまだそのオリジナルのJSRの取り組みの進化型に相当します。OSGiプロセス(リンク)は、要件を詳述するRequest for Proposal document（RFP）から始まります。RFPが承認されると、1つまたは複数のRequests for Comment（RFC）が、条件を満たす設計で作成されます。RFCが承認された後、その設計を含むように仕様が更新されます。RFPとRFCは、専門家グループ内の個人または小規模チームによって導かれる傾向がありますが、どちらも専門家グループのプロダクトです。
しかし、プロセスの仕様部分になると、OSGi AllianceがPeter Kriens氏にお金を払って記述を行ってもらっているため、OSGi Allianceが独占します。Peter氏はOSGiの取り組みに最初から関与し、仕様の品質と一貫性を確保しているため、これは素晴らしいことです。しかも、他のコンソーシアムが1人または複数のメンバー（一般に1人または複数の他のメンバーに匹敵するベンダーを示します）に「ペンを渡す」ときに直面する政治的問題も排除します。
リファレンス実装の現バージョンは、RFC 119に記載された設計を立証するためと、RFCがEG投票を通過できるようにするための手段でした。仕様段階で、それが仕様に取り込まれるときに設計についてさらなる議論があると予想しています。それは、RIへのさらなる変化につながる可能性があります。
OSGi専門家グループは現在Peter氏とともに、R4.2用の仕様更新に取り組み始めています。R4.2は3月か4月の事前形態での公開と6月の最終形態での公開が予定されています。この来たるリリースに関するさらに多くの情報は、3月23～26日のサンタクララでのEclipseConと同時に開催されるOSGi Dev Conで入手できます。
このリリースの他の主要部分には、コアフレームワークの様々な拡張、OSGiサービスを開発するためのSpringから派生したBlueprint Serviceコンポーネントモデル、OSGiバンドル（JTA、JDBC、JPA、JNDI、JMX、JAAS、Web Apps)にマッピングされたJava EEの様々な要素が含まれます。Java EEマッピングは、コア、Spring/Blueprint、またはDistributed OSGiの強化ほど作業は進んでいませんが、プレビューがR4.2の最終リリースと共に公開される見込みです。
この2年で、Distributed OSGi要件および設計の初期リリースドラフトへの文書化と、Apache CXFでのリファレンス実装コードでの例証を達成しました。これは、2009年中頃に発表予定のOSGi Specification R4.2エンタープライズリリースの重要な新機能の1つです。OSGiコアフレームワークや、Springから派生したBlueprint Serviceコンポーネントモデルの拡張、および主要なJava EE技術のマッピングと共に、このリリースはOSGi仕様とコミュニティの大きな進歩を示します。