Grizzlyフレームワーク(リンク・英語)は、GlassFish(リンク・英語)やSailfin(リンク・英語)、RESTlet(リンク・英語)、OpenESB(リンク・英語)等、たくさんの様々な製品で使われている。このフレームワークではJava New I/O API(リンク・英語)（NIO）を利用しており、開発者は拡張性のあるサーバアプリケーションを書くことができる。Atmosphere(リンク・英語)Grizzlyから発展したPOJOベースのフレームワークで、Comet(リンク・英語)を広めることを目的としている。Jean-Francois氏は、この新しい開発についてInfoQに聞かせてくれた。
InfoQ: Jean-Francoisさん、Grizzlyのようなフレームワークを利用するメリットと、デプロイする一般的な方法を教えていただけますか？
Jean-Francois Arcand (JFA): 拡張性のあるクライアントあるいはサーバサイドのアプリケーションを作成することは、簡単な作業ではありません。Grizzlyフレームワークを使用するメリットは、そうした高性能なアプリケーションを、低レベルのNIOの概念を扱う必要なく作成できることです。Grizzlyによって、そのようなアプリケーションをとても単純な方法で書くことができます。Grizzlyは、クライアント／サーバサイドのアプリケーション開発にかかる時間の短縮を促進します。Grizzlyのコミュニティもとても活発に活動していて、質問への回答や問題の解決は非常に速く、開発をとてもスムーズにしています。活発なコミュニティは、どんなオープンソースプロジェクトにとっても必ずプラスになるものです。何年もの間、私達はコミュニティを育て、そしてコミュニティから多くのことを学んできました。
InfoQ: 先頃リリースされたバージョン1.8では、共存できるものや単独でインストールされるものなど、様々なモジュールがGrizzlyフレームワークに入っています。これらのモジュールの簡単な説明と、現行リリースのアーキテクチャ概要の説明をしていただけませんか？
JFA: Grizzly のモジュールは２つのカテゴリに分けることができます。NIOフレームワークとその拡張機能です。NIOフレームワークは、高性能なサーバサイドアプリケーションの構築に利用することができます。一例として、私はEricssonと（Sailfinプロジェクトを通して）Grizzlyフレームワークのモジュール上でSIPプロトコルのサポートを実装する仕事をしました。SIPプロトコルはTLSとUDP、TCPをトランスポートプロトコルとしてサポートしているので、唯一実行可能だった解決策は、このフレームワークを利用することでした。別の例としては、SunのShared Shell(リンク・英語)があります。これもGrizzlyフレームワーク上で構築されています。２つめのカテゴリは、httpやjruby、cometの拡張のように組み込み可能なコンポーネントと私が呼んでいるものです。これらは直接使うこともできますし、組み込むこともできます。ひとつの好例はGlassFish v3で、httpモジュール上に構築しています。実験的な不完全なサーブレットコンテナ（未完成）もあり、これはテスト用に（例えばjunitと）使用することができます。Jerseyプロジェクトは自動化したテストでこれを利用していますが、今までのところ、とても小さいサーブレット様のコンテナとして非常に有用であることを示しています。
InfoQ: Grizzly はSun Microsystems社の内外を問わず他にもたくさんのオープンソースプロジェクトで利用されており、最も傑出しているのはGlassFishアプリケーションサーバです。このフレームワークの能力をもっともよく示す例を、他にも教えていただけませんか？
JFA: オープンソースでは、自分が作ったものを使っている人を探すのはいつでも難しいことです。私が知っているのは、Sunの以外のものでは、 4homemedia.com、Kaazing、RESTlet、Jetty、Alt-mobile、Mediafed/blog-city、T- mobile、Yahoo Brazil、AjaxフレームワークのBindows等があります。Sunのものでは、GlassFish、JXTA、Phobos、JavaCaps に含まれるopen-esbのhttpバインディングコンポーネント、Jersey、GlassFish v3のGrailsの実装、Netbeans、Sailfin、Sun Shared Shell、Sun Instant Messenger、そしてGlassFish JRuby gemsはGrizzlyのJRuby on Rail拡張上に構築しています。Grizzly CometはICEFacesとDWRにクライアントサイドをサポートされています。おそらくもっとたくさんあると思いますが、わかりません。 :-)
InfoQ: Tomcat(リンク・英語)やJetty(リンク・英語)との競合については、Grizzlyをどのように考えていますか？
JFA: Grizzly とTomcat／Jettyとの一番大きな違いは、TomcatとJettyはサーブレット2.5の仕様を完全にサポートしていますが、Grizzlyでは（まだ :-)）サポートしていないということです。Grizzlyが競うのは、組み込みの空間です。私は、簡単にカスタマイズ可能な小さなhttpのランタイムを備えるというニーズは実際にあると思っています。JettyとGrizzlyでGrizzlyが優れた選択肢になれるのは、ここだと思います（より小さく、より拡張が容易等）。Jettyはこの空間をリードしていますが、アプリケーションはますます、JettyからGrizzlyへと乗り換えています。 Grizzlyが優位な点のひとつは非同期のリクエスト処理メカニズムで、httpのレベルでカスタマイズすることが可能です。このメカニズムは、小さな非同期プロキシの作成では、とてもポピュラーになるように思われます。Grizzlyのhttp拡張では、サーブレットをサポートする必要なくComet ベースのアプリケーションを書くことができますが、これは時には必要です。
InfoQ: サーブレット3.0の仕様（JSR 315）(リンク・英語)についてはどうですか？この仕様ではCometのサポートを備えることを目指しています。
JFA: そうですね、サーブレット3.0では公式のAPIにCometのサポートを追加しようとしています。主に、サスペンド／レジュームのリクエスト方法が議論されています。
InfoQ: Atmosphereフレームワークとはどのようなものなのか、そしてそこに至った原動力は何かを教えて下さい。
JFA: ２年前、私はブログでGrizzly Cometフレームワークについて書きました。そしてその時以来、それを中心としたコミュニティを作ることができました。Grizzly Cometフレームワークの欠点の一つは、GrizzlyランタイムとGlassFishでしか動かないことです。これは厳しい制限です。ここ１年、 TomcatやJetty、Resinといった他のコンテナにフレームワークを移植して欲しいと言われていました。ですから、Atmosphereでの私の目標は、Grizzly Cometフレームワークから最もよいもの（Grizzletと呼ばれている一つのコンポーネント）を取り込み、Cometをサポートしているか否かに関わらず、すべてのコンテナで動くようにすることです。これにより、みなさんはサーブレット3.0の仕様を待たずに、移植性のあるComet／Ajaxのプッシュ型アプリケーションを作ることができます。サーブレット3.0の仕様が提供すると思われる以上のものも、もたらします。
InfoQ: GrizzlyとAtmosphereでの、Bayeuxのpublish／subscribeプロトコル(リンク・英語)についてはどうですか？
JFA: Bayeux の実装はおそらくAtmosphere上に実装されるでしょう。しかし今のところは、私はAtmosphereそのものに集中し、それを中心としたコミュニティを育てられることを確かめる予定です。1.0がリリースされたら、Bayeuxプロトコルをその上で動作させられるかがわかるでしょう。
InfoQ: Atmosphereに対して、Grizzlyは今後どうなっていくのでしょうか？この新しいフレームワークに置き換えられるのでしょうか？
JFA: Atmosphere はCometに関する取り組みだけをGrizzlyから新しいプロジェクトへと移動する予定です。先ごろ、私たちはgrizzly-jrubyの拡張機能をGlassFishスクリプティングという新しいプロジェクトに移動しました。Atmosphereは新しいプロジェクトへと進む２つめの拡張機能となる予定です。
Grizzlyのメインコンポーネント、NIOフレームワークとそのhttp の拡張は、Grizzlyの傘下にとどまるでしょう。私たちは現在、Grizzly 2.0の作業を活発に行っています（新しいリードがいるので、私はAtmosphereに集中することができます）。そして、そちらの方面でもたくさんの活動が行われる予定です。
InfoQ: AtmosphereとGrizzlyの次期バージョンをリリースするスケジュールを教えて下さい。
JFA: Grizzly 2.0は2008年12月を目標にしています。Atmosphereについては、webコミュニティの反応と支援次第です。Comet APIについては今のところ標準がないので、たくさんのコンテナ独自のコードが必要となるでしょうし、おそらくコミュニティの助けがリリースと安定性をスピードアップするでしょう。今までのところ、バージョン0.1（私の最初のプロポーサルであり最初のリリース）は来年の夏になるはずだと思います。
InfoQ: 新しいフレームワークをサポートする、新しいツールのリリースはありますか？もしかするとNetBeansプラグインでしょうか？
JFA: 確かにIDEのサポートは意識しています。Mavenのサポートも備えておきたいと思っています。
InfoQ: GrizzlyプロジェクトとAtmosphereプロジェクトが近い将来、拡張性のあるアプリケーションやCometプログラミングのパラダイムに次第に対応するようになっていくことについてはどう考えていますか？
JFA: Atmosphere の利点の一つは、GrizzlyのComet実装の性能を他のコンテナと比較できることです。私はGrizzlyにはAtmosphereが役立つのではないかと思っています。なぜなら、他のフレームワークとの比較で見つかる性能の問題はどれも、Grizzlyの性能改善に役立つからです。
組み込みの市場は成長を続けていますので、GrizzlyのコミュニティはおそらくAtmosphereとは独立して発展し続けていくでしょう。 Grizzlyは簡単に組み込み可能な数少ないものの一つなのです。私が最近見たデモの一つは、GrizzlyのCometをiPhoneで動かしているもので、素晴らしいと思いました。私は、もっとたくさんの実例が今後２～３年で出てくるのは間違いないと思います！
InfoQ: Jean-Francoisさん、お時間をいただきましてありがとうございました。
CometやリバースAjaxの詳細については、http://www.infoq.com/jp/news/2008/02/comet-scalabilityをご覧いただきたい。
原文はこちらです：http://www.infoq.com/news/2008/06/grizzly-atmosphere