OSGi Alliance が OSGi 4.2 仕様をリリースした。これまで早期ドラフトが入手可能だったが，これはその最終リリース版である。
すでに Equinox や Felix などの処理系は，それぞれ 3.5 および 2.0 リリースから 4.2 互換機能の提供に向けての作業を開始していた。しかし，その時点では OSGi 4.2 がリリースされていなかったので，OSGi 4.2 準拠をうたうことができなかったのだ。最終仕様がリリースされた今，それに適合するために必要な作業(まだ残っていればだが)を各処理系の開発チームが確定するのは時間の問題だ。
今回のリリースには何があるのだろうか？ InfoQ では以前，予想される内容についての隠れプレビュー取材を行ったが，今ここにあるのがその最終仕様になる。注目すべきは次の点だ。
-
起動フレームワーク。組込形式 OSGi エンジン(Equinox の servlet bridge など)の Javaアプリケーションからの起動はこれまでも可能だったが，これは特定のエンジンに依存したアプローチだった。Pax Runner のようなラッププログラムを使えば，任意のエンジンを比較的簡単に起動できるようにはなるのだが，この場合はエンジン特有の知識をその中にコード化する必要があった。今回，透過的な機構によってこれが可能になる。すなわち OSGi ランタイムの種類に関わらずに起動できるようになるのだ。これによってブートストラップクラスパス上の適当な JAR ファイルを単に置き換えるだけで，ひとつのアプリケーションが Equinox と Felix いずれの下でもテスト可能となる。
-
リモートサービス。OSGi VM を相互接続する技術は，これまでは分散OSGi および RFC 119 として知られていた。リモートサービスはその新たな名称だ。リモートサービスは(ほとんどの動的 OSGi アプリケーションにおいて，キーとなる)サービスの概念を導入して，それをリモート利用者にエクスポートする(ないしはリモートサービスをローカルで使用する)機構を提供する。他のアプローチ(RMIなど)と違い，リモートサービスは特定のインターフェースを実装したり，チェック例外をスローしたりする必要はない。またリモートサービスは，すべてのものを動作させようとしているわけではない。しかし OSGi サービスが動的であることを考慮すれば，ひとつの OSGi 環境内ならばいかなるサービスも相互利用可能ではあるはずだ。
-
ブループリントサービス。Spring の制御反転(inversion of control)や依存性注入(Dependency Injection)をよく知っているならば，ブループリントサービスはごく近いものと思えばよいだろう。これはクライアントが接続されるサービスの外部設定ファイルによる指定と，それらのサービスとの動的な結合を可能にするものだ。宣言型サービス(Declarative Service:DS)のように使用可能なサービスのタイプの制約(それが必須であるか否か，など)を指定することもできるが，宣言型サービスと違うのは，ブループリントサービスでは有効なサービスが存在しない場合にプロキシを提供することができることだ。クライアントのコードがサービスへの接続を試みると，サービスが配置されるまでクライアントはブロックされる。ブループリントサービスなどの利用によって，結果的にはアプリケーションにコンテナ特有のコードを含むことを回避できる。これはシステムがOSGi ランタイム内外の両方で実行されるような場合には有益だろう。
-
バンドルトラッカ。OSGi には以前から，行き来するサービスの監視を行うためのサービストラッカがあった。バンドルトラッカはその概念をバンドルの追跡に拡張したものだ。動的に移動するバンドルをサービスで監視することは，これまでも BundleListener を用いれば可能だった。しかし BundleTracker を使えば，ServiceTracker が ServiceListenerに対して行うのと同じ使い勝手でこれを実行することができる。この機能が利用されそうなのは，ブループリントサービスと宣言型サービスがメタデータを読み込む(あるいは処理する)ときに行う動的登録の実行時などである。例えば Webベースのエンジンが
web.xmlに新たにインストールされたバンドルを自動的にスキャンし，実行対象となる HttpService を通じてサーブレットを自動登録するような場合だ。 -
サービスフック。存在するサービスの検出に加えて，サービス間のイベントをインターセプトし，場合によってはフィルタすることができる。ロールベースの認証モデルの実装や，製品の能力ベースが異なる種類の機能セットを実現する目的で使用できるだろう。また別のアプローチとして，他のバンドルへのイベントをインターセプトして取り去ることによるプロキシ(あるいはロードバランシング)機能の提供がある。ここで取り去ったイベントは，後のステージで他のメカニズム(分散サービスなど)によって代理処理される。これらは前もって登録しておかなくても，必要時にリスナフックで有効にすることが可能だ。
-
条件付パーミッション。OSGi 4.2 が提供するパーミッション機能の向上の中に，許可と同様な拒否(DENY)機能がある。これは資格署名の組み合わせの一部であり，バンドルのサブセット上で行われるオペレーションに対して明示的な許可を与えるものだ。無署名のバンドル実装をロックダウンすることができるこの機能は，セキュアなOSGiプラットフォームの開発に役立つと考えられる。
仕様の変更は他にもたくさんある。OSGi バンドルに自身の MIME タイプ(application/vnd.osgi.bundle)が与えられたこと，Bundle-Icon と Bundle-License の参照，パーミッションの縮小セット（protected を使わずにパッケージフレンドリなもの）を許容する宣言型サービスの変更などがそうだ。また，DS(宣言型サービス)のスキーマは他のXML要素も許可するようになった。これはサービス固有の情報を渡すのに役立つだろう。さらに Application Admin によって管理されるアプリケーションは，終了時の戻り値を取得する機構を持つようになった。
Equinox 3.5 はすでにいくつかの OSGi 4.2 機能のサポートを提供していて，Apache Felix は今月始め(4.2 仕様が承認されるよりも前)にテストセットをパスしている。4.2 仕様での公式結果とテストキットは月末までには明らかになるだろう。
InfoQ は Paremus Service Fabric OSGi クラウドの製作元 Paremus 社の創業者であり，CEOである Richard Nicholson 氏に，新リリースの感想を聞いた。
"私たちには過去数年にわたっての分散OSGiベースシステムの開発経験があるので，リモートサービスとブループリントサービスの標準を取り入れた今回の OSGi 4.2 仕様のリリースには，特別な喜びを持っています。"
OSGi 4.2 のもっとも注目すべき部分，あなたは何だと思うだろうか？