レベル: 初級 Editorial staff, developerWorks, IBM
2005年 5月 10日 オープソース・ソフトウェアの商品化に成功している会社は増えつつありますが、Gluecode Softwareもその1つです。Gluecodeは、将来性のあるオープンソースのミドルウェア・コンポーネントの幾つか、特にApache GeronimoとApache DerbyをJ2EE™アプリケーション・サーバー・スタックの中に取り込んでいます。最近発表された、IBMがGluecodeを買収するというニュースの後、私達はGeronimoの主要貢献者の1人でありGluecodeのCTOでもあるJeremy Boynesに対して、GeronimoやJava™の方向性、オープンソースの現状などについてのインタビューを行いました。
 Gluecode SoftwareにCTO（Chief Technology Officer: 最高技術責任者）として入社したJeremy Boynesは、オープンソース・ソフトウェアとエンタープライズ・アプリケーション開発との組み合わせに関して彼が持つ実務経験をGluecodeにもたらしました。彼はBravantaとNetmosphereのチーフ・アーキテクトを務めていましたが、そこではオープンソース・ソフトウェアを利用することによって、会社の経費削減に大きく貢献しました。また20年に及ぶ彼のエンタープライズ・コンピューティングでの経験の中には、CiscoやBT、Centrum Systems、Sequent Computer Systemsなどでの地位が含まれています。彼は電子工学で学位を取得しており、幾つかの大規模なオープンソース・プロジェクトに、貢献者、コミッターとして参加してきました。こうしたプロジェクトの中には、OpenEJBやObjectWeb、Derby Javaデータベース、そしてもちろん、Apache Foundationの Geronimo J2EEサーバー・プロジェクトも含まれています。
IBMは、Gluecode Softwareを買収すると発表しました。これは、オープンソース・コミュニティーを育成し、そこに参加すると共に、オープン・スタンダードを推進するというIBMの目標に沿ったものです。EclipseやDerby、そしてApache HTTPサーバー（httpd）の場合と同じく、IBMはGluecode Softwareの持つGeronimoベースのプラットフォームを取り込むことによって、IBMが既に持っているミドルウェア製品ラインアップをオープンソースで補完しようとしています。
 | |
Geronimoを、単なる1つのJ2EEサーバーと考えるべきではありません。よく調整された、あらゆる種類のインフラ・サービスを構築するための、システム・フレームワークの開始と考えるべきなのです。
Jeremy Boynesの弁
|
|
我々developerWorksのスタッフは、Geronimoアーキテクトの1人であるJeremyに対して、Geronimoの設計目標やアーキテクチャー、そしてGeronimoがどのようにユニークなのか、また、これだけの規模のオープンソース・プロジェクトが、どのようにまとまろうとしているのかについて解説してもらうことにしました。
developerWorks: Geronimoのアーキテクチャーを説明して頂けませんか。主なコンポーネントには、どんなものがあるのでしょう。
Jeremy Boynes: Geronimoが始まった時、このプロジェクトの主な目標は、J2EE 1.4仕様の一部をサポートしている数多くの既存オープンソース・プロジェクトを統合することによって、J2EE 1.4の実装を実現することでした。そうした中から生まれてきたアーキテクチャーは、主に2つの領域に焦点を当てていました。この統合を、他のプロジェクトへの影響ゼロで実現するためのフレームワークを提供すること、そして、一連のシステム・サービス・モジュールを提供し、完全なサーバーがモジュールの組み合わせで構築できるようにすることです。
このアーキテクチャーの中心には、GeronimoカーネルとGBeanフレームワークがあります。これらがインフラ、つまり他のサービスをコンフィギュレーションし、アクティブにし、管理し、そしてサービス間の依存関係を解決するためのインフラを提供するのです。このコアは、小さく保たれており、そのため非常に小さなデバイスにもGeronimoをスケール・ダウンできるようになっています。
実は、このコアには2種類があります。1つは軽量コアであり、コマンドライン・ツールや、管理されていないサーバーなどのために設計されています。もう1つは伝統的なサーバー用に作られており、全てのコンポーネントが管理され、監視されるようにJMXを使用しています。
このコアの中に、トランザクションやセキュリティー、ロギング、ネーミング、リモートなどのシステム・サービスを提供する、様々なモジュール（つまりアプリケーションが期待するようなインフラ）をインストールしています。
この柔軟性を活用してサービスを組み合わせれば、特定なアプリケーション環境を形成することができます。例えば、このプロジェクトの第一目標はJ2EE 1.4環境を作ることであり、これは適当なサービスを組み合わせることによって実現することができます。しかしこの組み合わせモデルは、他のコンフィギュレーションでも使用できるのです。ですから私達は、Spring Frameworkを直接サポートする組み合わせを作り出すために、Springコミュニティーと積極的に協力しています。
この柔軟性は非常に強力なものですが、コンフィギュレーション制御や管理という面で、特有な困難もあります。こうした困難に対応するために、私達はカーネルの中に強力なコンフィギュレーション管理システムを構築しています。これによって、モジュールを組み合わせ、署名して封印し、任意のGeronimoカーネルにインストールできるようになります。ある特定なサーバーが、どのコンフィギュレーションを実行しているかの制御は、サーバー自身でもエンタープライズ環境の中でも行うことができ、あるいは外部の管理サービスによって行うこともできます。
実際私達は、このコンフィギュレーション管理機能を、エンドユーザー・アプリケーションにまで拡張しています。そのため企業組織は、完全デプロイされたアプリケーションを統合環境あるいはテスト環境の中で構築しておいてから、そのバイナリーそのものを、実稼働へ、あるいは顧客への配布というリリース・プロセスに移すことができるのです。
その派生効果として、全てのデプロイメント処理をオフラインで行うことができ、実稼働サーバーでのオーバーヘッドを減らすことができます。そうすれば、（場合によってはバイト・コードをスキャニングしてコード・パスを最適化することによって）オンライン・システムに影響を与えることなく、デプロイメントの間に大幅な最適化を行うこともできます。
developerWorks: このプロジェクトの必須項目の1つが、J2EE標準に完全準拠すると聞いているのですが、なぜ、それが重要なのですか。
JB: 基本的な事実として、ユーザーにとって重要だからです。様々な組織によって独立に実装されながら、そのどれもが一貫性を持った振る舞いをするアプリケーション用フレームワークを定義する、という面で、J2EEは大きな進歩を遂げました（これはCompatibility Test Suitesで実証されています）。これによって企業ユーザーは、自分たちが選択しさえすれば、単一ベンダーのソリューションにロックされないアプリケーションが書ける、という保証が得られるのです。あるいはアプリケーション・ベンダーの場合であれば、一度アプリケーションを書いておけば、どんな顧客の環境でもそのアプリケーションを実行できる、という保証が得られるのです。
もちろん現実の世界では、仕様は不完全であり、今日時点においても、どの実装が使われているかを知っていることが重要、という領域があるのは確かです。ただし、ここで鍵となるのは、ユーザーが、ある特定なソリューションに自分たちをロックさせることに関して選択ができるという点です。もちろん、オープンソースを利用すれば、そうしたロックはずっと緩いものになります。
しかし、認証は、途中の一段階にすぎません。Geronimoが成功するためには、ベースとなる仕様を超えるような、明確な利点をユーザーに提示する必要があります。このプロジェクトでは、エンタープライズ環境での実稼働デプロイメントに最大の影響を持つ技術領域に焦点を当てることを最優先にしています。そうした領域としては、管理やコンフィギュレーション、信頼性、スケーラビリティー、パフォーマンスなどに関わる基本機能があります。
developerWorks: J2EE仕様の、どの部分が特に難しいのでしょう。また、どの部分は処理がしやすいのでしょう。
JB: このプロジェクトでは一時、「88では、こうなっている」という冗談が流行しました。JSR-88デプロイメント仕様の実装に経験のある人は、皆そろって意味不明なことを言い始め、すぐに不機嫌になるようなのです。
冗談はともかくとして、J2EE仕様の一部は、統合に利用できるような良質のオープンソース・ソリューションが既にあったため、ごく単純に処理できました。例えば、Webコンテナーの場合であれば、JettyサーバーあるいはApache Tomcatのいずれかを統合するのですが、どちらも非常によく確立されています。同じように、私達のJAXP（Java API for XML Processing）実装はApache Xercesを使っており、JMX（Java Management Extensions）実装はMX4J（JMXのオープンソース実装）を使っており、埋め込みのデータベースはApache Derby（以前はCloudscapeと言われていました）を基にしたものを提供している、といった具合です。
最も困難な部分というのは、実はどのJ2EE実装でも苦労する部分、つまり、WebサービスやIIOPを使う他のサービスとのインターオペラビリティーの部分です。
developerWorks: 世の中には、充分な能力を持つ商用のJ2EEサーバーが既に数多くあります。Geronimoがオープンソースであるということは、なぜ重要なのでしょう。
JB: 世の中には、オープンソースのJ2EEサーバーも他にあります。例えばObjectWebのJOnASなどです。しかしGeronimoのようなプロジェクトは、オープンソースであることによってのみ、本当に成功するのです。さらに、個々の開発者だけでなく企業の支持を得るためには、BSDスタイルのライセンスで利用できる必要があります。つまり、オープンソースと独自技術の混成ソリューションを許すApache Licenseのような条件で利用できる必要があります。
例えばApache Software FoundationがリリースするGeronimo J2EEサーバーは、Apache TomcatやJetty、OpenEJB、ActiveMQなど、他のオープンソース・プロジェクトの組み合わせから構成されることになります。
また、他の組み合わせが、他のプロジェクトあるいは他の組織から提供されることがあるかも知れません。例えば、システム・ベンダーであれば、Geronimoのトランザクション・マネージャーを、OSレベルのジャーナリング（journaling）に直結する独自ソフトウェアを使用するもので置き換えることができます。またエンタープライズ・ユーザーであれば、セキュリティー・ポリシー・プロバイダーを、自分たちの持っている認定や監査のインフラで置き換えることもできます。
developerWorks: コンポーネント化されている、というGeronimoの構成は、オープンソース開発モデルに適していると思いますか。
JB: オープンソースであれ単一組織の内部用のものであれ、こうした規模のソフトウェア・プロジェクトにとっては、Geronimoが採用したようなモジュラー型の手法は必須だと思います。
しかし私達にとって一番重要な利点は、開発がオープンなコミュニティーによって推進される、という点です。そこには個人でも企業でも参加することができ、そのプロジェクトによる成果を享受することができます。オープンで実力主義、そして協力的なコミュニティーを持つApache Software Foundationに基礎を置くことによって、プロジェクトが長期に渡って存続することが保証され、また、ある一個人、あるいは、ある一企業の商業的な動機によってプロジェクトが独占されるのを防ぐことができます。
developerWorks: Geronimoは完全機能のJ2EEサーバーであるため、大規模で分散型、トランザクション型のエンタープライズ・アプリケーションに利用するのが最適だと思います。では、小規模なものに注目した場合、Geronimoを使うことが無意味な場合はあるのでしょうか。
JB: Geronimoのアーキテクチャーはコンポーネント化されているため、ごく小さなデバイスから大規模なエンタープライズ・アプリケーションまで、自由にスケールアップすることができます。私達はカーネルのフットプリントをできるだけ小さくするように、つまりセットトップ・ボックスのような制約の多いデバイスでも使えるように、特に注意を払いました。こうすることによってユーザーは、自分たちが実行するアプリケーションでの必要に応じて、どのサービスをフレームワークの中に組み込むかを選択することができます。
例えば、どこかの支店で使うための単純なサーバー機器であれば、Webコンテナーやセキュリティー・プロキシー、場合によってはメッセージング・クライアントを実装しておき、ローカルでアプリケーションを実行するような使い方ができます。リモート管理やリモート・コンフィギュレーションの機能が備わっているため、こうした機器の何百台、何千台を、中央の場所から管理できるのです。
Geronimoは本当にサーバー・アプリケーションを目的にしているため、恐らく今の時点では、ハンドヘルド・デバイスや携帯電話などのデバイスに使用することは適切ではないでしょう。しかし、将来こうしたデバイスの能力が向上すれば、適切な領域となるかも知れません。
developerWorks: Geronimoの中に組み込まれているスケーラビリティーについて、少しお話ししてください。
JB: 生のパフォーマンスではなく、スケーラビリティーのことを取り上げてくれるのは嬉しい限りです（もちろん生のパフォーマンスの領域でも、私達は非常に積極的な努力をしていますが）。今日のようにサーバー・ハードウェアが日用品となり、ソフトウェアのライセンス・コストがゼロになりつつある時代では、大規模なサーバーだけを対象にするのではなく、どんなマシンにもスケールアップ/ダウンできるようにアプリケーションを作った方が効果的なものです。
必要に応じてアプリケーションをプリ・コンフィギュレーションでき、必要に応じてサーバー構成を調整できることによって、ユーザーはサーバー・リソースをアプリケーションの動作のために費やすことができ、アプリケーションとサーバーとの間のオーバーヘッドのために浪費する必要がなくなるのです。
スケーラビリティーを制限する要因は、昔からCPUやメモリー、I/Oへのアクセスです。私達はCPUリソースを管理するために、リソースをバランスさせるための一連のスレッド・プールを提供しています。これらを調整することによって、インバウンドWebやEJB、コネクター・リクエスト、あるいはトランザクション・ロールバックなどサーバー自体が生成するリクエストに対して、リソースをバランスさせることができます。将来は、様々なサービスからのスレッド・プールを組み合わせ、こうした様々な作業負荷をバランスできるような、単一作業管理インフラを作りたいと思っています。またコンポーネントが、共有プールや共有キャッシュで同期をとることなくトランザクション毎の情報にアクセスできるような、中央トランザクション・コンテキストという中核概念も導入しています。
メモリーのスケーラビリティーに関しては、作業を実行する際にコンテナーが割り当てるメモリー量の制御に非常に注意を払っています。残念ながら私達は、アプリケーション自体が要求するリソースに関しては制御していません。これは相変わらず、現実世界でのアプリケーションで経験を積みながらの調整が必要な領域です。
I/Oスケーラビリティーを改善するためにNIO（Java new I/O）の機能を使うことが現実的である場合には、NIOを使っています。私達が特に注意した領域の1つが、トランザクション・ログです。そして、ここでのObjectWebとの協力の中から、非常に高パフォーマンスのジャーナリング・サブシステムであるHOWLプロジェクトが生まれました。
結局のところ、まだ相変わらず初期段階なのです。本当の情報は、Geronimoが現実の世界のストレス・テストされる中で得られるのです。そうした中での問題は、必ず開発者の注目を浴びるでしょう。
developerWorks: このプロジェクトで最大の困難は何でしょう。また最高の成功は何でしょう。
最大の困難は、プロジェクト自体の複雑さ、実装すべきプラットフォームの規模そのものです。こうした作業を、協力的とは言え個々に独立なオープンソース・プロジェクトという環境の中で行うことは、より一層の困難が伴います。しかし私は、これは最大の成功でもあると思っています。つまり、これほど多くの人達が、これを実現するために集まっているという事実です。
developerWorks: Geronimoのプロジェクトが始まった時点で、どのくらいのものが既にできあがっていたのでしょう。また、これから書くべき量はどのくらいなのでしょう。
JB:プロジェクトが始まった時点では、Geronimoのカーネルで既にできあがっているものは何もありませんでした。しかし、統合されるべきプロジェクトの多くは、つまりOpenEJBやMX4J、Jettyなどは、しばらく前から既に入手可能でした。それらの多くは、J2EE 1.4仕様にまで高めるために何らかの作業が必要でしたが、2003年の8月に私達が始めた頃にはJ2EE 1.4仕様はまだ最終になっていなかったのです。
私達は機能的には完成に近づいていますが、たとえ完全に認証された後でも、パフォーマンス調整や使いやすさ、国際化、ドキュメンテーション、新機能等々、継続的な努力が必要です。
まじめな話として、先に進むことによって、改善が必要だと分かる領域が現れ、採用したい新しい考え方が出てくるものです。すべきことは山ほどあり、コミュニティーは誰にでも開かれています。皆さんもぜひ参加してください。
developerWorks: 通常の仕事の他に、何か大事にしているプロジェクトはありますか。
JB: Apache Derbyがあります。Apache Derbyがオープンソースに登場したことに、私は非常に興奮しています。実は私は以前、Cloudscapeを使っていました。このようなプロジェクトがApacheに登場し、利用できるようになったことは興奮すべき事態であり、私のデータベース経験を生かせるというものです。
developerWorks: オープンソースは、ついに企業の中で地位を確保したと思いますか。
企業では、特に最近の1年から1年半では、これまで以上にオープンソースを受け入れるようになっています。企業インフラの基本要素の1つ、オペレーティング・システムとしてLinuxが広く採用され始めていることは、オープンソース技術の持つ、実稼働に耐えうる能力に対して、企業が安心感を持ち始めていることを示しています。そうした動きは、より上位のレベルにも上がっており、企業の各組織は、データベースやアプリケーション・インフラにもオープンソースを評価対象とするようになっています。これらは、手軽な商品として扱えるほど明確に定義された仕様を持った成熟市場であり、今後3年から5年の間に、こうした市場においてオープンソースのソリューションが大きなシェアを占めるようになると思います。
developerWorks: オープンソースの一部に修正が必要なものがあるとしたら、それは何でしょう。
JB: 修正すべきものは数多くあります。素晴らしいことに、それぞれのオープンソース・コミュニティーでは、それぞれ異なったものに修正が必要です。オープンソースの活動は1つだけ、というわけではありません。様々なコミュニティーが、様々な形での開発を行っており、それぞれがLinuxオペレーティング・システムからApacheでのhttpdやGeronimoなどのプロジェクト、EclipseやObjectWebなどの協議会、あるいはSourceForgeプロジェクトでのデスクトップ・アプリケーションまでを対象としています。そこには非常に多くの種類があり、それぞれが皆、異なる問題を抱えています。ですから、どれに対しても必ず有効という全能な解決方法は無いと思います。
オープンソースでの困難として、相変わらずコミュニケーションの問題があります。多くの商業企業が役割を演じる一方で、個々の人による貢献も尊重できるように考慮しながら協調や協力を行う、という問題です。ですから最大の問題は、文化的なものと言えるでしょう。どのプロジェクトでも、それぞれの形で、この問題に対応しようとしています。
developerWorks: Javaにとって、次の大きな出来事は何でしょう。
JB: Geronimoです（笑い）。Java言語は、本格的にエンタープライズ・アプリケーションに利用されるようになった、という興味深い段階にあります。私達は今、ユーザーがアプリケーション・インフラというレベルでの、管理されたランタイム環境や仮想化を使うことに違和感を持たない、という段階に入りつつあります。ですから私達はそこに、興奮すべき成長時代を見ることになるでしょう。
Spring Frameworkがユーザーに求めるものを提供した例に見られるような、独立した動きも起きてきました。こうした多様性は歓迎すべきだと思います。その一方、この技術が将来にわたって進化して行くことを企業が信頼するためには、標準化の果たす役割も大きくなります。私達は興味深い時代にいるのです。非常に多くの革新が行われ、非常に多くの考え方が生まれつつあり、AOP（aspect-oriented programming）やその他の軽量フレームワークなど、非常に多くのものが試されています。興奮すべき対象は、今そこにあるのです。
developerWorks: その他に、developerWorksの読者に伝えたいことはあるでしょうか。
JB: 私が技術的な観点から伝えたかった最も重要な点は、Geronimoを単なるJ2EEサーバーと考えないこと、そして、よく調整されたインフラ・サービスを構成するためのシステム・フレームワークの開始と考えるべきである、という点です。このフレームワークの使い方を制限する要素は、私達の想像力のみなのです。皆さんも私達に加わり、将来を構築するために協力してください。
さらに私は、GeronimoやGeronimoに関するプロジェクトに直接的、間接的に関係した無数の人達に対して、深く感謝したいと思います。
参考文献 学ぶために
製品や技術を入手するために
議論するために
著者について | | | この記事はdeveloperWorksの編集スタッフがお届けしました。 |
記事の評価
| 
