OSGiとEquinoxを効果的に使う - Jeff McAffer氏とのインタビュー

少し前になりますが、EquinoxのプロジェクトリーダのJeff McAffer氏にJames Sugrue氏がインタビューした記事が、DZoneに上がってました。で、内容があまりに面白かったので、こそっと翻訳しました。DIを考慮したプログラミングモデルがbundle開発にとてもマッチする、という話があったり、全てのプロジェクトにモジュール化が合う訳ではないが、モジュール化をするのであれば、早い段階から考慮しないと、とてつもない痛みを伴うなど、自分も思っていた事が述べられています。

原題:Using OSGi & Equinox Effectively: An Interview With Jeff McAffer

OSGiとEquinoxを効果的に使うには?Jeff McAfferとのインタビュー
投稿者:James Sugrue 翻訳者:kompiro

Jeff McAffer氏の新著OSGi & Equinoxの出版後、私は彼にインタビューをする機会を得た。このインタビューでは、OSGiの基本と、その実装であるEquinox、そしてモジュール化の価値と、Equinoxを使う上でのいくつかのベストプラクティスについて伺うことができた。

James: まず最初に自己紹介と、Eclipseとの関係について話してくださいますか?

Jeff: Jeff McAfferと申します。EclipseSourceの共同設立者で、CTOを勤めています。Eclipseは10年前、IBMで最初のプロトタイプが開発されてからずっと携わって来ました。その時から、私は主にランタイム環境について、例えばRich Client Platformや、今ではEclipseRTと呼ばれる、Eclipseのランタイム環境に強く影響する技術をずっとリードし、Equinoxを進化させてきました。そのさなか、私はディレクタの議長になり、いくつかのPMCやアーキテクチャ委員会に所属しています。

James:この本はどういった人たちを対象にかかれたんですか?Eclipseアプリケーションを構築する人々のみならず、他の人々を対象にしたんですか?

Jeff:もちろん。タイトルはOSGi と Equinoxです。なのでOSGiと、いくつかの部分はEquinoxの詳細について書いています。ご存知のように、OSGiEclipseの中核ですが、その技術が適用できる範囲は非常に広いスコープを持っています。私たちはOSGiが組み込み環境に適用されているのを知っていますし(組み込みは元々のOSGiのターゲット)ですし、デスクトップアプリデモ使えますし(Eclipse RCPや他のアプリケーションインフラでも)多くのメジャーなアプリケーションサーバのようなサーバサイドでもとても広い領域を対象にしています。エンタープライズJavaに関わる多くの人は、OSGiについて目にし、話しています。この本は、こういった人々を対象にしています。OSGiの基本を明確にし、OSGiの一般的な使い方における、高度な使い方を探求しています。もちろんその例にはEquinoxを使い、Eclipseをツールとして利用しています。Equinoxをベースにしていますが、本の成果物であるサンプルは、どんなOSGiシステムでも動作できるものを提供しています。

James: OSGiについてやEquinoxがなんなのか、簡単に説明していただけますか?

Jeff:簡単に述べると、OSGiは、Javaにおけるモジュール実行環境の仕様です。 そして、EquinoxはOSGiの核となる部分の仕様の参照実装です。もちろん、どちらも重ならない領域も相当あります。OSGiは組み込みからエンタープライズ領域へ移るとたくさんのサービスが追加されます。Equinoxは仕様では与えられていない多くのトピックをカバーします。(例えばプロビジョニングや、ネイティブコードの起動、OSGiではないライブラリの統合、動的なアスペクトの織り込み等々)

James: Equinox & OSGiがどんなモジューラシステムの核にでもなると思われますか?またいくつかのケースでは過剰であることはありませんか?

Jeff: OSGiは驚くほど小さいです。ただ27個のJavaのタイプがコア仕様で定義されているだけです。もしJavaのアプリケーションを構築し、モジュール化に興味があったとき、OSGi以外の実行可能な実装を見たことがありません。このコンシェルジュのような実装はとても小さいです(100k以下)。他の実装は大きく、過剰な機能がついているでしょう。いつものように、やりたいことに忠実な実行環境を使いましょう。

James: OSGiのキーになる価値はなんですか?

Jeff: OSGiJavaにおけるシンプルで強力なモジュールフレームワークです。OSGiを使用すると言う事は、明確な境界を持ち、実行時にはその境界を(強制的に)利用する事になる自己完結したモジュールを開発者が書く事が出来ると言う事です。これは開発しているシステムで書かなければならないコード量を減少させます。なぜなら他の開発者がすぐに使えるようにしたモジュールを再利用できるからです。これはギークにとってもいいことにきこえますが、多くの人にうけいれられるでしょう。
この本のチャプター1では、"モジュール化とは...円滑なコラボレーションを助ける"と述べました。モジュール化はモジュールの提供者とモジュールの利用者のどちらの技術にも振る舞いに自由をもたらします。これは、あなた個人、そして組織、両者の開発とソフトウェアのデプロイを根本的に変えるものです。NASAの人々はOSGiを使った驚異的なサンプルを作っています。彼らは宇宙という領域のミッションに対して、多様な人々のチームで立ち向かい、コラボしています。OSGiEclipse RCPが形作られたの初期から利用していますが、現在ではサーバでもよく動作し、チームすべてのメンバーでソリューションを作成することを強力に支援します。OSGiの力のいくらかはシステムエンジニアリングを越えて拡大し、ソーシャルエンジニアリングに及んでいます。

James: Equinoxが他の実装より優れているのはどこですか?

Jeff: 私は"優れている"とは思っておらず、"少しずつ異なっている"と思っています。OSGiの実装は片手で数えられるくらいあり、どれも違ったまとまりのユーザを対象にしています。EquinoxはEclipse IDEとRCPベースのアプリケーションのランタイムとして広範囲に使われてきたため、年々改良されてきました。毎日、文字通りに何百万人の人々がデスクトップでEclipseベースのシステムを実行しています。そういったアプリケーションの要求は、よりスケーラビリティの優れた、堅牢で隅々まで注意の行き届いた、現実のソフトウェアシステムでは滅多に発生しない領域でも対応するようにEquinoxチームの背中を押してきました。ここ数年のEquinoxはWebsphereからSpring dm Server、そしてSAP NetWeaverまでのサーバ実装のフレームワークとして選ばれるようになりました。これはEquinoxの状態をより一層改善し、OSGiフレームワーク業界における強みになっています。

James: 本を書くのはどれだけ大変でしたか?長い時間かかりましたか?

Jeff: 私が本を書くのは2度めの経験ですが、一通り書くには、締切を少し守れませんでした。(1年半くらいかかりました。)でも実際はそんなに大変ではなかったです。特にレッスン用の土台は既にある成果物から始めることができました。いくつかのチャプターはRCP本を引用し、育てることができましたし、Toastという、この本のために考え抜いたシンプルなアプリケーションは、既におおきく、たくさんのファンがいました。Paul氏とSimon氏はToastの開発に精力的に働いてくれたおかげでとても素晴らしい仕事をしてくれました。Toastによりかっこいい事柄を追加しきるまで、このチャレンジは止まることがありませんでした。
たぶんこの大きなチャレンジは、詳細をよく知っている読者、よく知らない読者それぞれの心を打つのではないでしょうか?私たちはこの本がOSGiを導入するための簡単に理解できるものにしたかったですし、中途半端に放っておくことはしたくなかったのです。なので、多くのチュートリアルはどれも簡単に見え、あなた自身が試してみるときにはたくさんの質問に答えられていないようにしています。OSGiは表面上は本当にとてもシンプルです。bundleをつくり、依存性を定義し、システムに投入する。本当のシステムを構築するまでだったらそれだけです。なので、実際に本当のシステムを構築するときは手探りでサードパーティOSGiではないコード、API、そして自分たちのシステムを扱っていくわけです。そういう部分を想像し、作り込んでいくことはとても大変な仕事でした。

James: OSGiを既に使っていたり、使いたいと思っている人にアドバイスするとしたら、どんなことがありますか?

Jeff: 「よい垣根はよい隣人を育む」です。あなたの家に直接8つの家に隣接していることを想像してみてください。救急隊員や警察官、重機操縦者、ビル検査官、弁護士、裁判官、脚本家、そしてあなたの名前もあります。よく考えてみると、これらの話の大部分では、ほとんど定義されていなかった曖昧な境界ふるまいがあります。そういうことをぐるぐる頭の中で考えます。そしてソフトウェアシステムに置き換えて考え見てください。OSGiはあなたのAPI定義と、進化、そしてあなたの垣根を保守させるためのツールを与えてくれるのです。

James: OSGiの特殊な部分は何でしょうか?

Jeff: OSGiにイラついている人々の多くは、OSGiによらない部分でイラつかされていますが、何がそうさせるかというと、モジュール化と、ダイナミズム、つまり動的な部分にあります。モジュールを定義するには、あなたは境界と、モジュールがどういう振る舞いを持つのか、考えなければなりません。多くのシステムでは、アーキテクチャを大体決めたら早く開発しようとします。この事が、モジュールについて考えることや、インタラクション、繰り返しリファクタリングすることを難しくします。OSGiはあなたがこれらのインタラクションを把握し、実施できるようにします。もちろんあなたが好むのであれば大きなスパゲッティコードの塊を書くこともできますが、それはOSGiと独立して考えることでしょう。同じように、あなたがシステムに何を持たせるたいのか、自発的に考え直したいときはそうすべき時もでてくるでしょう。繰り替えしますが、OSGiはそういったシステムを作ることもできますが、タダのランチはありません。あなたは適宜コードを書く必要があるのです。
もちろんOSGiの動きにはいくつか特異な部分もあり、他の拡張メカニズム、例えばコンテキストクラスローダなどはインピーダンスミスマッチがあります。が、そういう部分に泣かされる人は後をたちません。これらの問題の多くは一度判明すると、順調に対応されています。

James: あなたの例を聞いていると、一般的なプログラミングのベストプラクティスを得たように聞こえます。OSGiアプリケーションを構築していく最中みつけたあなたのベストプラクティスをいくつか紹介していただけませんか?

Jeff: 「OSGiでプログラミングしていると考えない」 -- 私のOSGiについての話や、トレーニングコースでは、最初に「OSGi環境でプログラミングを行うベストプラクティスは、OSGiを使うためにプログラミングするわけではない」と言うようにしています。何を伝えたいのかというと、POJOでコードをかいて、DIのスタイルを貫く事が大切、ということなのです。多くの人々は、いたるところをコードで結びつけ、OSGiAPI呼び出しを至る所に散らかします。こういったやりかたはコードを読みづらくし、テストを難しくし、他のコンテキストでの再利用を難しくします。Toast全体で80のbundleがありますが、OSGiのcore framework APIのみを参照しています!
「Declarative Serviceを使う」 -- ServiceTrackerという重石の代わりに、Declarative Servicesに移行してください。DSはOSGi APIの受け渡しを簡単にます。これは決まり文句である、もろく複雑な他で必要なコードを、サービスへ直接受け渡します。そのため、かなりbundle間でOSGiサービスの連携を単純化します。
「bundleの食物連鎖を理解する」 -- 別の言い方をすると、依存関係を小さく、管理しやすいようにしてください。今使っているbundleについて現実的になり、なんで使っているのか考えてください。重複のファンになったことはありませんが、多くのメガバイトのコードが単純な制限で巻き込まれている事もあります。
「Bundle Activatorを使うな」 -- えぇ。ときどき例外的にBundleの機能によってはセットアップをすべきものもあります。これは特にDSを使っているときに考えるべきです。Activatorの悪い面は、起動時に時間をとり、通常シングルトンのような振る舞いをとります。例えばHTTPService bundleはHTTPサーバを起動し、受け付けるポートを設定します。何をしたいんでしょう?そして別々のときに起動したかったんでしたっけ?それから・・・。

James: OSGiを使う上で一番よくある典型的な間違いは何でしょうか?

Jeff: 今言ったベストプラクティスを基にする私が知っている最大の問題は特にサービス周りにおいてOSGiAPIを使いすぎることです。冗談抜きに、bundleのmanifestに"org.osgi"がないか、探してみてください。そしてどれもまっとうな使い方をしているか考えてください。多くの場合、他の世界とつなぐために手を出しています。これは周辺や、あなたのbundleがどのようなシチュエーションで使われるのか、またその結果がどうなっていなければいかないいのか、想定することを強制します。DSを使うことや、他の注入メカニズムを用いてあなたのbundleに依存しているものを注入してください。

James: モジュール化についてのご意見を伺わせてください。前もって設計から考えますか?もしくは必要なときにリファクタリングしますか?

Jeff: 素晴らしい質問です!設計や実装は実際の全ての要求をより良く実現できるかです。私は全てのチームにとってモジュール化の価値が優先順位の一番上にあると思うことを恐れています。ですが、現実的にはモジュール化はあなたが考えておくべき事実であれば、本当に可能な限り早く設計することです。モジュール化に取り組んでいるたくさんの有名なプロジェクトではもがき苦しんでいます。Eclipse自身も本来備わっていたモジュール化と同等にするには、大変な思いをしました
。多くの悩みは強結合や、異なる関心毎がごちゃ混ぜになっているところからくるのです。(言い換えれば凝集性されていないのです。)
本来であれば、本の中で述べている凝集度を高め、結合を弱めることはプログラミングにおけるベストプラクティスと明確に言えます。はっきり言ってモジュール化されていようが、いまいが、これらがよくできているのであれば、あなたのソフトウェアはよりモジュールに分割でき、デザインプロセスの中で明確に考えるべきことです。またそうしておけばリファクタリングも簡単になるでしょう。(そして、リファクタリングが必要になることも減ります。)そのため、結合を弱めるために設計や、コーディングに時間をかけることは前もってやるべきですが、あまり時間をかけずにいると、中長期的な視野からみたとき、手痛い目にあうでしょう。
最後に、現実的には要求ははっきりせず変わります。あなたはそういった事を意識し、リファクタリングできるように準備しなければなりません。より、構造を改善するために。そして、繰り返してください。早い時期からモジュール化を進めることはよいデザインプロセスであり、より重要な事なのです。

James: 今後Equinoxはどういう方向で進化しますか?e4の本質の核になりつづけますか?

Jeff: Equinoxというフレームワークは、OSGiの仕様と共に進化しつづけ、より強力な、そして堅牢な実装になっていくでしょう。e4のようなプロジェクトを活動する中で、またエンドユーザや現実世界のユースケースで揉まれていく中で、ニーズを見つけ、進化していくでしょう。Equinoxプロジェクト自身は、より幅広いモジュール化のニーズに拡大しています。昨年のリリースで、私たちは動的にコードを織り込む機能を追加しました。今年はEquinoxにScalaModulesの成果が取り込まれる事に興奮しています。加えて、私たちはEquinoxにサーバサイドやプロビジョニングに適した改善に取り組んでいます。
本当のことですが、Equinoxにとどまらない大きなものになっています。それはコミュニティとエコシステムによって実現されています。一昨年、Eclipseは実行環境におけるEclipseの技術の利用を広めていくため、EclipseRTプロジェクトを始めました。EclipseRTは成長し、(OracleからTopLinkとしてリリースされていた)EclipesLinkやJettyのような多くの良く知られたランタイムテクノロジを含んでいます。最近発表のあったGeminiとVirgoプロジェクトですが、OracleとSpringSourceのランタイムテクノロジがEclipseRTに貢献され始めています。特にSpring dm ServerがVirgoプロジェクトの一部として、移行しています。だからEquinoxとEclipseRTは近い将来、多くの、そしてとても面白いプロジェクトになると思います。

James: p2はそういったものにあっていますか?それらをプロビジョニングするための選択肢となり得ますか?

Jeff: p2はEquinoxの一部で、Eclipseの新世代のプロビジョニング技術です。そのため、汎用的なプロビジョニングのインフラとしてデザインされ、大なり小なりOSGiベースのシステムを管理において役立てることができます。p2が存在する理由として、みんなが抱えるプロビジョニングの問題が異なっているためです。とてもフレキシブルで、拡張ができ、設定できます。その本では、p2の役立つ詳細をカバーし、動的に、そしてリモートに対してプロビジョニングをサポートする事のできる深いレベルでp2をどのように統合するのか、サンプルコードを使って示しています。
もちろん、そこには多様なニーズがあり、それにあった多様な実装が提供されてます。要するにp2以外の選択肢があります。それらも強みと弱みがあるので、チームはチームにあうベストの選択肢を選ぶべきです。OSGi仕様では初期のプロビジョニングと、デプロイ管理という二つのサービスが定義されており、Apache Aceは相対的に新しい場面を対象にしてますし、これまでのOSGiベンダでは商用の選択肢も提供されています。たぶん普及の傾向にはあるものとして、内製のソリューションもあります。プロビジョニングの領域において驚くくらい創意あふれる人々により提供されています。

James: Eclipseのために働き始めてから10年経ちますが、あなたが見てきた一番興奮した変化はなんですか?

Jeff: 今あなたが言及したように、私は1999年の早くからEclipseのために働いてきました。なんて長い時間働いてきたんでしょう。その中で3つの大きな変遷をみてきました。一つ目は、「誰にも知られていないプロプライエタリーでニッチなものから、オープンソースにした経験とツールビジネスにおいて優位に立てた」ということです。これに興奮と、満足感を覚えました。その中で私は技術、モジュール化、コミュニティとオープンソースについてたくさん学びました。次の大きな変遷は、「EclipseのRich Client Platformとしての進化」です。とてもクールです。私たちと共に開発を進めてきたコミュニティからの希望で、私たちが考えもしなかった利用シーンを見つけられました。そして私にとってはモジュール化の裏にある全てのコンセプトを確かめるものになりました。。3つ目の変遷は、今目の当たりにしている「ランタイムとしてのEclipse、もしくはEclipseRT」です。ランタイム領域に適応していく割合とペースにはくじけそうでした。毎日工作のようなものが使われたり、何か新しいものとしてプロジェクトに貢献されました。私たちは昨秋、EclipseRT daysと題したシリーズを、様々な領域の参加者と共に行いとても楽しみました。私はそれを越えるものをしりません。