OSGi Allianceは、Java 1.2がリリースされた時代に、モジュール化されたコンポーネントベースのランタイムを提供する目的で1999年3月に設立された。仕様はJSR 8として参照された。JavaがOpenJDKという形で公開されるより前で、当時はJavaの拡張提案(JEP)と同等のバージョンであった。
Adobe、IBM、Boschなど多くのメンバに支えられた独立財団であったOSGi Alliance財団は、OSGi仕様の知的財産のリポジトリとして機能し、それを開発する専門家グループを組織してきた。ベンダ中立なひとつの組織に集まることにより、オープンな標準の定義が実現し、多数のオープンソースや商業プロバイダによる実装が可能になり、企業による数多くの商用技術の一部を今日も担っている。
OSGiの最大のユーザのひとつは、IBMによって始められ、その後オープンソースプロジェクトに転向したEclipseだ。最初のバージョンがリリースされたのは2001年で、OSGi Alliance設立の2年後のことだったが、IDEランタイムがOSGiを利用するようになったのは2004年のEclipse 3からだ。Eclipse Foundationも2004年、EclipseコードベースのIP管理組織として設立された(メンバの多くはOSGi Allianceと同じ)。その後、ルーツであるIDEを越えて、Webベースツールの提供やIoT(Internet of Things)との統合を提供し、最近ではJavaEE仕様(現在はJakartaEE)の開発を引き継いでいる。
これら変化の結果として、OSGi AllianceとEclipse Foundationの対象が大きくオーバーラップするようになったため、今年始めに行われた議論の末、OSGi Allianceの知財をEclipse Foundationに統合し、Eclipse OSGi Working Groupを新たに設立する決定が下された。設立されるワーキンググループの最初の仕事は、現時点では、作業が進行しているOSGi R8 Compendium仕様の完成と承認になる見込みである。OSGi R8 Core仕様は、OSGi Allianceによって承認された後、Eclipse Foundationが公開する予定である。それに伴って、OSGi R8仕様とEquinoxベースの実装が来年早々に公開されることになっている。
InfoQは今回、OSGi AllianceのプレジデントであるDan Bandera氏とコンタクトを取り、今回の動きについて詳しく聞いた。最初の質問は、Eclipse Foundationに移行した理由と、合流対象として他の財団が候補にあったかどうか、ということだ。
Bandera: OSGi Allianceが設立されたのは、現在とはまったく様相の違う時代でした。Apache Foundation [同じく1999年に設立]が唯一存在したのみで、Eclipse Foundationが始まったのはその5年後です。しかし、特定のユースケースセットを対象として財団を運用するコストは、効率的なリソース使用ではないと判断したため、他の財団を探すことにしたのです。
Apache、Linux Foundation、OASISを検討したのですが、Eclipseを選んだ理由が2つありました。OSGi Allianceのメンバの多くがEclipse Foundationのメンバでもあったことが最初にありますが、もうひとつは、Eclipse Foundationの活動の場が、オープンソースソフトウェアのリリースのみから仕様に関する作業へと発展していたことです。この活動は、Java EE(現在のJakarta EE)仕様の寄贈の一部とし行われているもので、Eclipseで将来に向けた実装作業が進んでいます。
標準化プロセスはOSGiにとって重要なものです。オープンソースの実装がいくつかありますが、その他に商用の実装も使用されており、実装間の互換性の検証に使用可能な仕様の存在が極めて重要だからです。
InfoQ: 仕様は今後、どのように進展するのでしょうか？
Bandera: OSGiワーキンググループがスタートすれば、ワーキンググループの仕事になるでしょう。最初の業務はワーキンググループ憲章を承認することです。これによって、ワーキンググループの将来的な活動が規定され、ワーキンググループが適切だと考える方向に仕様が展開することになります。
OSGi Core Release 8に向けた作業は現時点で概ね完了していて、関連するIPはEclipse Foundationに移管される予定です。これにより、EclipseのOSGi Working Groupがリリースを実施できるようになります。これまでのOSGiリリースはwww.osgi.orgで公開されていましたが、今後のOSGi仕様がどこで、どのように公開されるかの決定はワーキンググループに任されています。
OSGi Compendium Release 8の作業は現在進行中で、OSGiワーキンググループが立ち上がるまでには終わらないでしょう。基本的にはどちらの仕様セットも、Declarative Service 1.4など、バージョン管理された仕様への参照を集めたものです。ワーキンググループが今後も抄録(compendium)リリースを継続するのか、あるいはサービスを個別に順次リリースする方法を選択するかは、ワーキンググループが決定することのひとつになっています。
ワーキンググループが今後の仕様をEclipse Specification License下でリリースするように強く求めることはほぼ確実ですが、従来のリリースについては、これまでどおりのライセンスで引き続き利用できます。
InfoQ: 仕様において重要なことのひとつとして、実装が仕様に準拠していると宣言できるようにするために、JavaのTCKのような互換性スイートを用意する、ということがあります。それについてはどうですか？
Bandera: コンプライアンステストは仕様プロセスの重要な部分です。OSGi Allianceは移管作業の一環として、コンプライアンステスト用スイートをEclipse Foundationに提供する予定です。このスイートはオープンソースなので、自由にアクセスすることができます。ロゴを使用したり仕様準拠をうたうためには、ワーキンググループのメンバになって、コンプライアンステストスイートの実行と結果の公表を行わなくてはなりません。
これはつまり、Apache FelixやKnoplerfishなどのオープンソースプロジェクトも、商業ソフトウェアと同じコンプライアンステストにアクセスする必要があるということです。Eclipseのリファレンス実装であるEquinoxも同じようにテストされることになります。ワーキンググループのこれらのメンバによって、オープンソースバージョンもこれまでと同じ方法で検証されていることが保証されるのです。
InfoQ: 今回の移行によって、既存の、あるいは新たなOSGiメンバには、どのようなメリットがあるのでしょうか？
Bandera: まず、OSGi Allianceメンバの大半がEclipseのメンバでもあるということから、両方のメンバである企業にとっては、メンバシップ費用の削減が可能になります。
新しいメンバには、OSGi Allianceは各メンバシップティアがほぼ同じメンバシップ費用を課されていたのに対して、Eclipse Foundationは組織の売上高を基準とした段階的なメンバシップである点が異なっています。このため、小規模な新メンバに対してはコストが低く、より効率的になっています。これにより、多くの新メンバシップがワーキンググループに参加することを期待しています。
InfoQ: OSGiの未来に関わるには、どうすればよいのでしょうか？
Bandera: すでにEclipse Foundationのメンバであれば、新たに設立されるOSGiワーキンググループに参加できます。現在メンバでない方は、Eclipseメンバシップのページに詳しい情報があります。
参加に関心のある方は、https://accounts.eclipse.org/mailing-list/osgi-wgリストにメールを送ってください。ワークグループは数週間内に設立され、活動を開始する予定です。