BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ アーティクル Eric Newcomer氏によるOSGiの未来

Eric Newcomer氏によるOSGiの未来

ブックマーク

Eric Newcomer氏は、アイオナテクノロジーズ社のCTOです。彼は、DEC社で長い間一流の技術者として過ごし、分散トランザクションのバイブルの1つである本を執筆し、Webサービスに関する多くの本がベストセラーとなっています。また、WS-CAFやWS-TXといった、多くの重要なWebサービスの仕様策定にも参画しています。Eric氏は、現在、OSGiのエンタープライズエキスパートワーキンググループの共同議長であり、今回、OSGi、Java、ESBについて私たちInfoQと話をしてくれました。  

Mark Little (ML): はじめまして、Ericさん。まずは、自身のバックグラウンド及び、OSGiとの関係を説明して貰えますか?

Eric Newcomer (EN): 数年前は、OSGiでモバイルデバイスのアプリケーションの配信に関する将来のソリューションについて研究していましたが、実際のところ、それに関しては何も残せませんでした。

昨年の夏に、私はIONAから2006年の9月11日にOSGiのエンタープライズワークショップに参加する旨の招待を受けました。実は、休暇の後の月曜日であったので、他の誰かに参加してもらおうと思っていましたが、それはできなかったので、結局のところ参加しました。いろんなことが重なり、最終的には、エンタープライズエキスパートグループに参加するためにIONAがOSGiに参加するよう勧め、私はその共同議長を志願しました。

OSGiのエンタープライズ版は、この業界における重要な将来性を持っています。与えられた要求はワークショップで紹介され、それに対し、IONAは多大な貢献をしていると感じています。

ML: OSGiは長い間ありますが、ここ最近になって多くの注目を浴びるようになったように思います。なぜ、そのようになっていると思いますか?

EN: OSGiにスポットライトが当たったのは、まさにEclipseのお陰と言えます。それ故、おそらく、今なお大方の人たちがOSGiのことを知っているだろうと思っています。つまり、EclipseプラットフォームはOSGiの実装であり、皆さんがダウンロード/インストールしているEclipseプラグインは全て、裏でOSGiを使用しているのです

しかし、私は、それだけでは無いと言いたいのです。OSGiはサービス指向に関する現在のトレンドにフィットしたシンプルなサービスプログラミングモデルや、動的デプロイメントのサポートがあり、エンタープライズのIT環境内での吸引力が増しています。

ML: OSGiに対するIONAの関心はどこにありますか?

EN: 私たちは、OSGiを他のベンダーが注目しているのと同じように、巨大なソフトウェアプロジェクトを分けたり、結果を配備するための技術を可能にするものとして注目しています。

しかし、私たちは、基本的なエンタープライズITの要求を集めるためのOSGiのプログラミングモデルの将来性にも関心があります。私たちは、それをデプロイのプラットフォームやプログラミングモデルであったり、SOAベースのアプリケーションを強化するための大きな可能性を持ったランタイム、あるいは、Eclipseプラットフォームがツール周りのエコシステムを作ったように、ランタイム周りの主要なベンダーのエコシステムを作るという可能性を秘めたものとして考えています。

業界がJavaEEのための軽量な代替物の準備ができていることは明らかなようで、私たちは既にこの分野において、例えばSpringとOSGiの融合といった大きな関心事を見ることができます。

SOAのためのインフラストラクチャの要求は、JEEアプリケーションやEAIブローカーといったインフラストラクチャ製品により作られたものを扱うさいの要求とは異なっています。SOAは、よりライトウェイトな何かであったり、全く新規なものよりももっと多くの向上や改善を示す何かを必要としています。OSGiは、この分野において多くの可能性を秘めていると思います。

ML: ESBは、ここ数年にわたり発展していますが、突然、ESBの一般的な実装の多くが、あれこれとOSGiに注目し始めています。OSGiとESBの相性は良いとお考えでしょうか?

EN: 確実に相性は良いと思います。まず初めに、OSGiの開発と配布の側面があります。ESBは、OSGiのサービスやバンドルを使用した開発・配布、それらの機能強化が可能となります。これは、新しい特徴や機能、ESB開発の操作性を改善するということにおいて、市場へ出すまでの時間を早める助けとなっていると思います。次に、OSGiのプログラミングモデルがあります。それらは、ESBがJavaコンテナから機能的にアクセスするための標準的なインターフェースを作れる可能性を秘めています。最後に、私は、OSGiがESBの"プラットフォーム"となり、ベンダーはプラグインとなるOSGiバンドルを開発するという、ESB市場における'一番のブリーダー'になり得る可能性があると思っています。実際、私はより遠くに行って、OSGiが一般的なSOA基盤に適していると言います。そして、我々は、JBI 2やEclipseのSOAのランタイムプロジェクトの提案といったところに持ち込まれているのを目の当たりにしています。

ML: OSGi委員会での作業具合はどうでしょうか?

EN: 6月28日のミュンヘンでの会議で、第一回の要求フェーズから設計フェーズへと通過しました。そして、何度も言っていますが、今後、楽しいことが始まると思います。

複数の組織の中で仕事をしている人たちには周知のことですが、組織1つ毎に独自のアプローチとプロセスがあります。OSGiのプロセスは、RFP(Request for Proposal)にある要求を形式化することから始まります。さらに、一度、沢山のRFPのいずれかが要求委員会によって承認されると、エキスパートグループのメンバーらが、RFC(Request for Comment)を作り始めることができます。それらは、特定の設計文書によって、要求に対する解決策を提示します。その後で(というより同時に)、エキスパートグループのメンバーらが参照実装を開発することができます。さらに、誰か(できればRIのコードを書いている人で無いほうがよいのですが)が適合性テストの開発に着手します。参照実装や適合性テストができると、仕様が唯一完全なものとなります。故に、私たちが比較的プロセスの始まりにいたとしても、きちんと進めることができるのです。

昨年9月のエンタープライズワークショップ(告知(英語):
http://www.osgi.org/news_events/osgi_workshop_091106.asp, 結果(英語): http://www2.osgi.org/EnterpriseWorkshop/HomePage) にて、初期の要求が集められ、それらに対する優先度がつけられました (詳細はこちら(英語) http://www2.osgi.org/EnterpriseWorkshop/Requirements). エンタープライズエキスパートグループ(EEG)は、12月にOSGiの議会で作られ、初回の会議が1月の終わりに、アイルランドのダブリンで開催されました。そのときに、いくつかの"作業の流れ"が決まりました。リーダーたちは、様々な作業の流れを決め、13のRFPが作成されました。数週間前、EEGはそのRFPのうちの7つの承認に向け、提案を行いました。それによって、実際に設計段階に入っています。

RFPに基づいたものが提出され、私たちは、Spring、SCA、JEE、JBI、Web services、若しくはその他のものといった、既存のエンタープライズ技術に対し、OSGiをどのように対応付けるかということに、多くの時間を費やしました。

ML: OSGiに関わるところで、来年くらいまでに何か大きな変化はありますか?

EN: 私は、大きな変化は無いものと思っています。私たちが見ているものは、エンタープライズの要求に触れるための既存機能に対する将来的な拡張の部分だと考えています。OSGiを知っている人であれば誰でも、組み込みの分野に端を発し、ホームオートメーションや自動車のオートメーション携帯電話のアプリケーション管理を初めに行ったということを知っていると思います。よって、そういった質問は自然に起こるもので、OSGiのエンタープライズ版に対する要求を評価するときには、組み込み版若しくは他のものと同じであるかどうかということが必要とされます。これは、常にJ2ME、J2SE、J2EE(個人的には、Java 2と言われてから随分になるので、単にJME、JSE、JEEで良いと思うのですが)との比較が引き合いに出されます。しかし、今のところ、私たちはOSGiと共にやるということは無いというのが確かな答えです。もともとのOSGiのメカニズムは、OSGiがエンタープライズのIT環境で使用するための新たな要求に出会うために拡張、強化して使用されているように思います。しかしながら、OSGiの核の部分は、今も変わっていないと思います。

私たちが今後見るであろうそういった拡張は、提案されたRFPをベースにしています。例えば、JNDI、JDBC、RMIといったJEEコンポーネントのより良いマッピング、オブジェクトのシリアライズ化、Webアプリケーションのサポートの強化、同一JVM上にあるユーザーのコードやベンダーが提供したコードのデプロイに対するセキュリティサポートの強化、OSGiから外部システムにアクセスするための方法(逆もまたしかり)、リモートのOSGi環境に配備されたサービスの検索方法などがあります。

ML: Java EE7のコンテナとしてOSGiを採用すべきだという人もいますが、どのようにお考えですか?

EN: 全くそのとおりです。世の中全てがそういう考えであってほしいものです。Javaの将来に関する大きな問題として、いずれにせよ、SunはOSGiを採用するか、対抗するかになるでしょう。そして、もし彼らがOSGiに対抗し続けるのならば、Javaに影響を与えることになるでしょう。OSGiでの最近に限った私の体験からしても、Javaにおいて大きな改善を行っていると思います。例えば、モジュール性、バージョン管理、クラスローディングの改善といったことなどがあげられます。

JSR 291に対する提案は、いずれにせよ通過したので、OSGiが正式にJavaSEの一部となったと言えます。しかし、Sunの見解に対する結果もあります。Sunは、Javaのモジュール性に対しJSR 277も提案しており、OSGiと大きく重なる部分があります。SunにはOSGiを承認し、Java7がそれをベースにする絶好の機会であるのに、公式な声明はなく、OSGiを採用するというよりもそれをオーバーラップする方向に傾いているように思います。

私は、願わくばSunがOSGiに関する考え方になって欲しいと思います。一方では、今のところ、OSGiにとっては事がうまく進んでいるので、もしSunがOSGiに反対し続けてくれるなれば、もしかしたらその方が良いのかもしれません。

この記事に星をつける

おすすめ度
スタイル

BT