SitebricksはGoogleによって開発された新しいWebアプリケーションフレームワークである。このフレームワークはGoogle Guice上に構築されており、早期エラー検出、短いコード、スピーディな開発に焦点を合わせている。InfoQではクリエイタでありGoogle WaveのコアエンジニアでもあるDhanji Prasanna氏から話をうかがった。
InfoQ：新Webフレームワーク構築の背景にある動機は何だったのですか？ 既存のフレームワークで満足できなかったのはなぜですか？
Dhanji氏：私は長い間（Java 5が出たのと同じ頃から）これに取り組んできました。Struts1/2、JSFなどのポピュラーなフレームワークを使ってみて苦労する点を特定し、自分自身のために楽しくて苦痛のないWebプログラミングを試みてきました。それらの機能には本当にエキサイトさせられています。それらは「また？」という皮肉から始まりますが、幸いなことにいつもポジティブな反応で終わります。これは私をエキサイトさせ続けます。
私は革新の余地が多くあるということも信じています。私は"REST"というマーケティングバズワードが好きではないのですが、Sitebricksはその設計にコアHTTPイディオムを採用しています。"RESTful Webフレームワーク"と名付ければ人々をよりエキサイトさせることができたかもしれませんが、我々は現在の機能でも人々をエキサイトさせるのに足るという自信があります。
InfoQ：JSF、Wicketなどの従来のJavaフレームワークやテクノロジへの対策についてどう考えていますか？
Dhanji氏：これらとはずいぶん違いがあります。JSFやWicketはイベント、コンポーネント、ウェジットのようなデスクトップUIの抽象化を行うWeb UIデザインのアプローチです。一方、SitebricksはHTTPを直接抽象化するので、RESTful WebサービスのためのJava APIであるJAX-RS（私も設計を手助けしました）と比較するのが相応しいと思います。しかし今のところ、JAX-RSはテンプレートやクライアントAPIに対応していません。
既存のMVCフレームワークに対する私の第一の不満は、それらがHTTPレイヤーを隠そうとすることです。これはクリックを捕捉して状態収集POSTに変換するJavaScriptの自動注入のような奇怪な習慣に導いてしまいます。これらのフレームワークはかなり冗長でもあり、プロトタイピングを退屈なものにします。言い換えれば、Sitebricksは極めて簡潔で、HTTPに愛着を持っており、リソースやメッセージの取得や交換をするものです。
加えて、テンプレーティングレイヤは関数型言語のように構築され、単純で簡潔なやり方でページを構築できます。これはScheme、Haskellのような関数型言語やTerrence Parr氏のModel/View分離に関する素晴らしい論文(http://www.cs.usfca.edu/~parrt/papers/mvc.templates.pdf)から大いに着想を得ています。
InfoQ：Sitebricksの基本方針や技術的な選択について説明しようと思っていますか？
Dhanji氏：もちろんです。第一の方針はGuiceのような簡潔さとタイプセーフです。URLマッピングやテンプレートの式など、全てのものはエラーチェックや静的解析のレイヤによって支えられています。Sitebricksテンプレートの式はJSPと同じようにシンプルですが、型推論アルゴリズムによる静的型チェックが働きます。ダックタイピングさえ静的に保障されます。
別の方針は、パフォーマンスだけでなく開発者の生産性も含めたスピードです。SitebricksのライフサイクルはHTTPと同じで、各ページはフロントにHTMLテンプレートを使ったJava POJOです。他のフレームワークの"カスタム"コンポーネントは多くの追加設定やサポートクラスを必要とすることが多いですが、Sitebricksはテンプレートシステムであり、カスタムの再利用可能なページの部品は通常のページと変わりありません。
また、SitebricksはGuice上に構築されています。これは最初の頃からのコアな設計方針でした。これによって、Sitebricksは完全なDIシステムに統合されており、DIを活用するために他のフレームワークでしなければならないようなことを行う必要はありません。
InfoQ：Sitebricksを使ったWebアプリケーション開発のためのプロセス、ツール、ライブラリは何ですか？
Dhanji氏： HTMLページを育ててそれを削減するという考えがSitebricksの本質です。ページやコンポーネントを設計するのに豪華なツールを必要とするべきではありません。任意のサーブレットコンテナを使ったり、ページの部品（bricks）や大きなコンポジットページを繰り返すことができます。
Sitebricksはエンジニアのために、Guiceのようにタイプセーフや早期エラー検出のアプローチを採用しています。オブジェクトはDI依存性（GuideやビルトインGuideサーブレットを使った）のために検証されるだけでなく、ページ内の式は対応するページクラスに対して静的に型チェックされます。Red Hatのエンジニア、Mike Brock氏の助けにより、私はJSPの簡潔さは残しつつJavaコンパイラの豊富なエラーチェックを提供する型推測アルゴリズムを使うため、MVEL言語（http://mvel.codehaus.org）を拡張しました。
これは特殊なツール（言ってしまえばIDEさえ）なしでほとんどことができるべきだという我々のゴールに沿っています。MVELはまたJSP ELよりも一桁早く、時には他のほとんどのELよりも速度が上です。
加えて、SitebricksはHTMLテンプレートの静的分析も行います。これは、フォームパラメータがバインドされているターゲットやアクションURLにマッチすることを保証したり、それ以外の多くの検査を行います。ただ、それは氷山の一角です。我々は多くのことをしています。
InfoQ：GWTやJavaScriptツールキットのような他のポピュラーなWebテクノロジやHibernateなどの永続化メカニズムとSitebricksはどのように統合しますか？
Dhanji氏：現在のところ、Sitebricksページ内でJavaScriptフレームワークを使ったり、これを他のSitebricksページや"brick"に埋め込むことができます。Sitebricksは正しいことを行い、<head>タグの中のCSSやJavaScript、その他のリソースが必要に応じて書き換えられることを保証します。このことは他のシンプルな注釈を埋め込むことができることを意味します。これは有用な機能を持った他のWebページを構成可能な部品としてラップしたり再利用することを可能にします。またクライアントサービスのように、GWTアプリケーションにXMLやJSONを配信するためにSitebricksを使うこともできます。
我々はSitebricksが一時的にバックエンドになれるようにするGWTとコミットスタイルで統合することに取り組んでいます。
SitebricksはGuice上に構築されているので、ユーザーは我々がすでに持っている様々なフレームワークやライブラリとの統合を生かすことができます。JPA、Hibernate、db4objectsにとって、warp-persist（http://www.wideplay.com）はGuiceアプリケーション上で永続化やトランザクションを簡単にセットアップするための薄くてシンプルな統合レイヤです。それは豊富なタイプセーフとクエリ自動化機能も備えています。warp-persistはGoogleのいくつかのプロジェクトを含む、多くの組織や個人に利用されています。
ユーザーのアプリケーションからバグを発生させるようなweb.xmlをほとんど完全に排除できるように、GuiceのサーブレットモジュールもSitebricksに組み込まれています。
InfoQ：Google WaveフェデレーションプロトタイプサーバーにSitebricksへの参照があるようですが、このサーバーで使われているのですか？より多くのGoogleプロジェクトで使う予定はありますか？
Dhanji氏：実際のところ、SitebricksはGoogle Waveのリファレンス実装では使われていません。私がフェデレーションプロジェクトのビルド構成をした時、テンプレートとしてSitebricksのAntスクリプトを使いました。だから、例のいくつかにはコメント化されたコードが残っています。しかしながら、私は特定のチームとGoogle Waveの他のシステムでSitebricksを使うことを議論し、より安定した時にそれを使う予定です。
私はGoogle関連の人々と話し合い、彼らはSitebricksについてかなりエキサイトしていました。しかし、それはまだ生まれたばかりなので、我々はコードベースが成熟していくのを見届ける必要があるでしょう。
InfoQ：あらゆる仕事のためのベストなフレームワークはないわけですが、Sitebricksを使うことでどんな種類のWebアプリケーションがより多くの恩恵を得られ、どんな要求なら魅力的なソリューションにならないと思っていますか？
Dhanji氏：素晴らしい質問ですね。Sitebricksは多くのテキストコンテンツとJavaScriptによって挿入されたり変更されたりするいくつかのコンポーネントからなるHTMLを持った、今日のほとんどのサイトで動作します。
一見したところ、ページの重さの議論のようですが、Google Waveのような最新のAJAXアプリケーションはSitebricksの恩恵はあまりないでしょう。しかし、RPCレイヤーについて考え始めた時、SitebricksのRESTful WebサービスAPIはGWTアプリケーションにJSONやXMLを直接配信するためのとても魅力的なものになります。おまけに、プレレンダードHTMLのフラグメントはJSONやGWT-RPCの変換に比べて大きなパフォーマンス上の利益を提供できることがわかりました。Sitebricksはこの分野に自然にフィットします。
最後に、我々は高速シリアル化を使った堅牢なHTTP（RESTful）Webサービスの提供も手がけています。シンプルなHTTPクライアントAPIもバンドルしており、いくつかのSitebricks jarファイルはWebサービスリモーティング設定の両サイドで使うことができます。我々はこのためにMVELをMVBus拡張の上に構築し、XStreamのような従来のライブラリに比べて一桁パフォーマンスを向上させました。
InfoQ：Sitebricksリリースのおおよそのロードマップやライセンシングについて教えていただけますか？
Dhanji氏：Sitebricksは現在Apacheソフトウェアライセンス2.0です。今のところAlpha段階であり、http://code.google.com/p/google-sitebricksからアクセスできます。
また、Sitebricsに関する質問やコメントをTwitter（http://twitter.com/dhanji）で直接送っていただいても構いません。
Google Sitebricksプロジェクトページやメーリングリスト、今年のJavaOneのDhanji氏のプレゼンテーションスライドを見れば、さらなる情報を参照することができる。
Dhanji氏は最近InfoQが特集を組んだDependency Injectionに関する書籍の著者でもあり、その最後の章はGoogle Sitebricksを使って完全なWebアプリケーションを構築する方法のケーススタディになっている。
さらに、InfoQではフレームワーク、Google Guice、Google Waveについていくつかの記事を読むことができる。