OSGiアライアンスはOSGiプラットフォームの次期リリースの仕様のドラフトを発表した。これはドラフトなので多くの機能に変更が加えられるかもしれない。また、廃止されたり置き換えられる可能性もある。このドラフトには下記の仕様が含まれている。
- RFC 112 - OBR
- RFC 152 - サブシステム
- RFC 167 - サービスローダーのサポート
- RFC 169 - JMXの更新
- RFC 172 - 宣言的サービスアノテーション
- RFC 174 - バンドルコリジョンフック
- RFC 175 - バージョニングの更新(スナップショット)
- RFC 176 - 宣言的サービス1.2
OBR: バンドルを取得して実行中のOSGiシステムにインストールする方法は共通の課題だ。現在、これはmvn:プロトコルを使ってリモートリポジトリからバンドルを取得するか、EclipseのP2のような独自のプロトコルを使うことで実現している。
これらの方法が確立される前はOscar Bundle Repository、OBRが使われていた(OscarはApache Felixの以前の名前)。OBRはXMLファイルでどのバンドルがどのパッケージを含んでいるかなどのリポジトリの情報を提供する。こうすることでリゾルバはある機能を使うために必要なバンドルを特定することができる。
OBRは利用されていた(利用できるリポジトリもあった)が普及しなかった。仕様は決まっていなかったのが原因かもしれない。結果、使われているOBRのバージョンによって差異が生まれてしまった。
OBR RFCはリポジトリの形式をしっかりと定義することでこのような問題を解決しようとする。最終的にはこの形式を使うことで、すべてのOSGiランタイムは同じ方式でバンドルの要求を実行できるようになる。
サブシステム: Although OSGiはバンドル(そしてサービス)のレベルで働くが、バンドルをまとめてインストールできれば、何度も個別にインストールよりも便利だ。サブシステムの目的は機能とアプリケーションの概念を標準化して、バンドルをまとめて参照したり、ひとつの単位としてインストールできるようにすることだ。WARファイルがバンドルの集まりでひとつの単位としてインストールできるのに似ている。
しかし、異なるOSGiランタイム(Eclipse P2とApache Karafのような)はこれらの概念への参照の仕方がことなる。その結果、P2の機能はApache Karafにインストールできない。Apache Karafの機能はP2にインストールできない。標準化することで互いに利用できる、互換性のある機能を実現できる。
現在のサブシステムの仕様には懸念点がある。それは、ダウンロード単位と融合してしまう新しい新しい概念が定義されている点だ。この結果、既存のスタンドアロンのバンドルに個々の機能は個別にダウンロードしなければならない要素(現在のEclipseの機能のように)にとどまったままになってしまう。
サービスローダーのサポート: 驚くべきことにJavaのサービスローダーはモジュール化されていない。従って、サービス(XMLの解析のような)を要求するためにサービスローダーを使うアプリケーションの場合、問題が発生する可能性がある。レガシなアプリケーションがサービスローダーを利用できるようにするという提案はサービスローダーのルックアップにOSGiサービスを登録する仕組みと、サービスローダー経由でサービスを要求する仕組みを提供することだ。
サービスローダーはOSGiを直接探索するよりは非力だが、古い方法で使われているレガシコードはOSGiの仕組みを利用したり、OSGiで制御できるようになる。
ServiceLoaderはJava上ではfinalなので、これが動作する場面のひとつは、読み込み時にリライトをして呼び出しをServiceLoaderからClassLoaderが反応する方式にリダイレクトするときだ。
JMXの更新: これによって以前にはエンタープライズ仕様の124章で網羅されていたJMXプロセッシングが導入される。また同時に4.3フレームワークではバンドルライティングやプロパティ、ジェネリックのような新しい機能も使えるようになる。
宣言的なサービスアノテーション: @Componentや@ReferenceのようなJavaコードで利用される標準的なアノテーションを提供する。このようなアノテーションはBndで使われているが、標準的なOSGiがサポートすることで他のツールも同じようにアノテーションを使うことができるようになる。
バンドルコリジョン: 複数のバンドルが共存できる環境を取り除くために使われる。フレームワークがバンドル共存環境を排除するためのフックをフレームワークがサポートしてれば、異なるコンテキストで同じ名前のバンドルをインストールできる。また、バンドルの利用が適法かどうか判断するため、バンドルコリジョンのフックを利用することもできる。
バージョニングのアップデート: OSGiのバージョニングとMavenのバージョニングの大きな違いのひとつは非公式バージョン(例えば、1.2.3)の重要性だ。Mavenではこの値は可能な値の中での最大値となるが、OSGiでは最小値になる。Mavenで-SNAPSHOTを使うと(またはEclipseで.qualifierを使うと)動的にタイムスタンプに置き換えられるが、これは常に非公式バージョンよりも小さい値が想定されている。このふたつの違いの中で、奇数と偶数でバージョン(リリースと開発に対応)を分かる方法、常に正式なバージョンを付与する方法、'最大'を表すRELEASEのような識別子をハードコードしてしまう方法など、様々な方法が模索されてきた。
新しいバージョニングではリリース前のバージョンの範囲とリリースバージョンの範囲というふたつの異なる範囲が提供される。リリース前バージョンはmajor.minor.micro-プレフィックスで識別される。リリースバージョンはmajor.minor.micro.プレフィックスだ。リリース前のバージョンの範囲はリリースバージョンの範囲よりも小さい。これは、1.2.3-SNAPSHOTが1.2.3よりも小さいことを保証するためだ。しかし、1.2.3は範囲の'中間点'であり、1.2.3.SNAPSHOTは1.2.3より高い値であることに注意する必要がある。
リリースの範囲と同じように、リリース前バージョンの範囲も辞書順で並べ替えられる。さらに、現時点では-は有効なバージョンではないため、既存のリリースとの後方互換性は保たれる。新しいOSGiのリリースでは-の範囲を区別できるようになる予定だ。
宣言的サービス1.2: サービス利用の新しい"欲張り"な選択肢を提供する。新しいサービスが提供され、このサービスの優先度が高いと既存のサービスを優先度の高いサービスで置き換えることができる。
総括: 一般的に言って、OSGiの仕様はよく考えられており、上で紹介したRFCも例外ではない。OSGiの仕様はこのプラットフォームが促進してきたモジュラリティを示している。ClassLoaderが認識するコードが原因で発生するServiceLoaderの問題のような特定の問題に対処するために既存のシステムはアップグレードを行い、新しい機能の利点を享受することができる。
小さな変更だが、最も影響があるのはリリース前バージョンの範囲の機能だろう。この機能によってMavenとOSGiの世界はさらに近くなり、よく知られたトークンを使って両者の関係を整理しなくてもよくなる。
これは仕様のドラフトなので、正式リリースまでに変更される可能性もある。この記事は将来に含まれる可能性のあることを紹介しているという点に注意されたい。