Ajaxというキーワードが注目されるようになってから２年ほどが経過した。この間に多くのAjax関連フレームワークや部品が登場し，以前のWebアプリケーションフレームワークのような乱戦模様を呈している。筆者が把握している限りでも５０以上のJAX構築用のプロダクトがある。Ajax対応プロダクトを謳うものも含めるともはや数えきれない。

　Ajax関連プロダクトの波はApache Software Foundation(以降 ASF)にも例外なくおとずれている。ASF内でもAjaxに対応したプロダクトが複数存在している。また，Kabukiという新しいAjaxフレームワークの開発が，Apacheインキュベータプロジェクト内で開始された。

　今回は，Ajax とそれにまつわるASFの動きを紹介してゆく。

なぜAjaxなのか

　なぜ今，Ajax（注1）がここまで注目されるのだろうか。

(注1)Jesse James Garrett氏が2005年2月に「Ajax: A New Approach to Web Applications」という記事で「Ajax」と命名した。
　Ajax自体は，よく言われるように既存の技術(JavaScript，CSS，XML，SOAP など)を組み合わせたものにすぎない。JavaScriptに詳しい読者なら，Ajaxという名前が出るよりも前に同様のテクニックを利用していたことだろう。

　注目される様々な理由が語られているが，筆者は下記のような側面もあると考える。

  • クライアント，即ち WebブラウザおよびクライアントＰＣの性能と通信速度が向上し，比較的大きなクライアントプログラムを配布（HTTPレスポンス）可能となった
  • 特別なプラグインやプログラムは必要なく，ベンダ非依存なリッチクライアントを作成することも可能
  • Webアプリケーションと同様に，クライアントアプリケーションの配布管理が不要
　こうしてみるとAjaxは良いことずくめのように思える。しかし，実際には決してはそうではない。それには様々な理由がある。

　まず，JavaScriptやスタイルシートを多用するため，製造やデバッグに独特の知識やテクニックが必要となる。また，他のコンパイル型の言語(CやJavaなど）と比較すると開発環境が十分とは言えず，修正やメンテナンス，リファクタリングが困難となる場合が多い。また，ページ遷移とは異なるダイナミックなページ内容の変化が起こるため，設計やテストも困難となるなど，解決しなくてはならない問題がまだまだ沢山残っているのが現実だ。

　このような理由から，多くのアプリケーション・アーキテクトはJavaScriptの利用を敬遠し，極力利用しないというのが暗黙のルールのようになっていた。

　しかし，現在では多くのアーキテクトがコンシュマ向け，エンタープライズ向けを問わず Ajax を採用しはじめている。それは，前述のような利点があることはもちろんだが，Ajax構築用のプロダクトが充実してきたことが大きいだろう。冒頭で述べたように数限りないプロダクトが存在しているが，それらを上手く利用することで大きなリスクを背負うことなく Ajax の恩恵を受けることができるのだ。

　コンシューマ向けのサイトでは，全面的にAjaxを採用しているサイトも出てきた。ただしエンタープライズシステムでは，前述したような問題から，部分的にAjaxの手法と取り入れるといった場合が多いようだ。採用の理由も，コンシューマ向けサイトではデザイン重視に起因しているが，エンタープライズ向けではユーザービリティ向上やレスポンス向上が目的となっている。

ASF内にもAjaxを意識したプロダクトが続々

　ASF 内にもAjaxを意識したプロダクトが複数存在している。また，冒頭で述べたように Kabuki（歌舞伎）という新しいAjaxフレームワークの開発がインキュベータプロジェクト内で開始された。

　このプロジェクトが2005/12にはじめに提案されたとき，コミッタには Zimbra社とIBM社のメンバが提示されていた。しかし，その後，提案内容の一部が Eclipseなどの特定プロダクトに依存しすぎているという議論があり，2006年1月には再提案が行われた。再提出案では IBM社のメンバが抜け Eclipse への依存も薄まった内容となっていた。この再提出された提案が承認され Kabuki プロジェクトがスタートした。

　当初の提案ではKabukiではなく，AJAX Toolkitという名称のプロジェクトで提案され，JavaScriptエディタやデバッガなどを含むEclipse プラグインと，Ajax用のライブラリなどの具体的な成果物が提示されていた。しかし，再提出時には EclipseのSWTのような AJAX Development Toolkitとしてリッチクライアントライブラリのみとなり，開発ツールは削除された。

　だたし，当初提案されていたツールはThe AJAX Toolkit Framework (ATF)としてThe Eclipse Foundationに提案され開発が開始されている。

　Ajaxでは，通信部分やXMLの生成・解析などの制御処理とカレンダのような画面処理などが，多くのシーンで実装されている。Zimbra社が保有する部品がApache Licenceで流通することで，多くの開発者が恩恵を受けることができるようになるだろう。

　Kabukiにはまだ具体的なコードが存在しないため，本稿ではその利用方法などは紹介できないが，Zimbra社が保有している豊富なライブラリ群が提供されるようになると思われる。

Ajaxの仕組み

　以降は，Ajaxの仕組みを具体的なコードと共に紹介する。本コードでは実際にどのようなことが行われるのかを紹介するために，あえてAjaxライブラリやフレームワークを用いていない。実際のシーンでは，通信部分などの複雑且つ冗長な処理はKabukiのようなライブラリやフレームワークが隠蔽してしまう場合が多いだろう。

　冒頭で述べたようにAjax(Asynchronous Javascript and XML)とは，新しいテクノロジではなく従来から存在する技術を組み合わせた仕組みの総称だ。名称からも分かるとおり，JavaScript を用いた非同期通信がその中核となる。一般的には通信にはXMLが利用されるが，通信量の軽減のためにXML形式を用いずに，csv形式を用いる場合もある。

　通信はブラウザに表示されているボタンやイメージ，入力フィールドなどの各種エレメントのイベントに関連づけられたJavaScript内から行う。この時，レスポンス受信時の動作も関連づけておき，受信データの解析や表示の操作を行う。この仕組みによって，ページ遷移をすることなく，必要な時に必要な情報を通信によって入手するのだ。しかも，非同期通信（レスポンスを待たない）を行うことで，通信中もユーザーはインタフェースの操作が可能となる。例えば，通信中でもページのスクロールや入力を行うことができるということだ。

　Ajaxの動作イメージを図1に示す。

図1●Ajaxの動作イメージ

　Webブラウザ内には画面を描画するモジュール（描画エンジン）やJavaScriptを実行するモジュール（JavaScriptエンジン)など様々なモジュールが存在している。それらはそれぞれ非同期に動作可能となっており，Ajaxはこの仕組みを上手く利用しているといえるだろう。