OSGi: 次期リリース

作者 Alex Blewitt , 翻訳者 脇坂 茂明 投稿日 2009年7月27日

セクション

エンタープライズ・アーキテクチャ,

デベロップメント

トピック

JSR 291 ,

JSR 294 ,

JCP Standards ,

JCP ,

Java ,

言語 ,

Eclipse ,

プログラミング ,

エンタープライズアーキテクチャ ,

Equinox ,

Apache Felix ,

OSGi

共有 |

原文(投稿日：2009/7/17)へのリンク

OSGi allianceのテクニカルディレクターであるPeter Kriens氏は今週、Paremusスポンサーで、ロンドンのSkillsMatterにて開催されたUK OSGi Users Groupでプレゼンテーションを行った。そのイベントは記録されていて、ビデオが公開されている。

次期OSGi 4.2 リリース (2009年8月末までにはリリースされるといわれている) いくつかの新しい機能をカバーし、そのうちのいくつかは既に、暫定的にEclipseで利用されているOSGiエンジンであるEquinoxに実装されている。

OSGiコア新機能:

• 標準起動フレームワーク 基盤にある実装に関係なくOSGiシステムをより簡単に起動させられる。 (例えば、クラスパス上でEquinoxをFelixに単純に交換するだけで機能させることができる)
• サービスフック OSGiバンドルは他バンドル向けのサービスのインターセプト、フィルタリングができる。 (例えばセキュリティプロビジョニング)
• バンドルトラッカー バンドル開始時、終了時をモニタリングすることができる。
• 改良されたセキュリティ ポジティブとネガティブ(許可/拒否)の両方で認可ポリシーをカスタマイズできる。
• 標準バンドル-ライセンス ヘッダ バンドルは管理目的でライセンス要求を定義できる。

プレゼントかもしれない付加サービスを含むOSGi要約が、コア機能に続いてリリースされるために公開予定だが、以下のものを含んでいる。

• 初期プロビジョニング プロビジョニング情報をバンドルマニフェストに指定できる。
• 宣言的サービス BNDによってサポートされている宣言的サービスからいくつかの制約が外される。
• リモートサービス 以前の分散OSGi (通称RFC 119)ではOSGiサービスはリモーティング技術によってVM間の接続することができた。バンドルへの外部設定はどのようにこれらサービスを紐づけるか定義できる。RMIと異なり、これらサービスはチェック済例外を持たない。(接続エラーが起きるとRuntimeExceptionがスローされる)。これはEclipseのECF とFelix CXFでも実装されている。
• ブループリントエクステンダー 設定ドリブンなサービスモデルを提供する。(宣言的サービスに似ている) ベースはSpring パターンに基づいている。さらにサービスは初期起動時にインスタンス化でき、プロキシに紐づけられて、何回でも変更できる。

また、OSGiベーストランザクションAPI (JTA上)を含むエンタープライズOSGiサービスについての報告がありました。 それはOSGiサービスをとおしてのJDBCとJNDIであったり、JMX経由でのOSGiサービスの管理も用意している。 エンタープライズパズルの最後のピースは、 Spring DM Serverのように、WARを動作中のOSGiシステムにインストールすることができるWebコンテナである。

他にも実験的なサービスはある (仕様には定義されてない) 、例えばネストされたフレームワークを作成する機能 (OSGiエンジンは閉じた別のアプリケーションをホスティングするために他OSGiエンジンを内部的にインスタンス化する) と、OSGiサービスとやりとりをしたり、ランタイムコマンドをサポートするためのシェルライクなTSLである。後者はその時、その時のシステム毎のシェルを利用するより、標準シェルとしてOSGiエンジンを制御できるようになる。これはPOSH とPax-Shellのようなシステムで既に利用されている。

OSGiの実験的サービスへのアプローチはJCPで定義して進めていくやりかたとは異なります。どう機能するか経験値を得る前に仕様を定義することにたくさんの時間を費やすかわりに、RFCは仮な詳細事項を複数の実装(Felix、Knopflerfish、 Equinox など)に用意し、どう機能するかフィードバックを得るようにしている。終了してない状態、早期でのリリースをすることなく(例えばJavaでいう日程崩壊）、得たフィードバックで安定化するまでに仕様を洗練していくのである。最終的な仕様を発表する前にフィードバックを得て実験する機会があるということは、いったん仕様が最終的にFixしても、将来の変化による影響を与える可能性がそれほど高くはないことを意味する。

話はJSR294の方向性に関するいくつかの意見で締めくくられている。現在、融合される要件と実装のミックスがある。JavaCでのメタモジュールシステムの扱い方の話をふまえて、可視性がJava(新しいmoduleキーワードの導入を含んでいる)で機能する方法について変更案があがっている。これは最近、メタモジュールと必要なキーワードの意味あいについて熱い議論を促した。Sun社員でありFelix コミッタであるRichard Hall氏は以下のように書いている

私としては、私たちがあいまいな何かだけを定義している、というPeter氏の意見に共感しています。究極的にはJavaのビジョンである "write once, run anywhere"にそむいてしまいます。 私はより具体的な何かを定義したいと思っています。

幸い、JSR294で取り組む時間はまだあり、そしてJSR294に関する最近のコメントは、有効なソリューションに導く要求を示唆している。