Ajaxとリッチクライアントの関係：インターネットサービスの新基準（2/2 ページ）

[大澤文孝，ITmedia]

　この方法では、クライアント側のアプリケーションは、一般的なWindowsアプリケーションやJavaアプリケーション（もしくはアプレット）として構成されていた。これにより、WindowsやJavaの標準的なユーザーインタフェースを提供できるようになったわけだ。

　しかし、この方法はイントラネット向けと言える。なぜならば、インターネット上では、ユーザーがどのようなOSを使っているか限定できず、セキュリティが厳しく問われる世情からも、専用のソフトウェアをインストールさせることは極力避けるべきだからだ。

　この問題を解決するものとして、ブラウザへのインストール率の高いMacromedia Flashがクローズアップされることがある。FlashはWebブラウザ内で動作するプラグインとして動作するため、事前にWindows上でローカルインストールする必要がないというメリットがある。おおむね、ユーザー評価が高いのも強みだろう。2006年2月には、AdobeがFlashを使ったリッチクライアント開発を支援する「Adobe Flex 2.0」のパブリックβが公開されており（関連記事）、方向性の1つとして注目されている。

JavaScriptでクライアントアプリを実現するAjax

　Ajaxでは、クライアントアプリケーションをJavaScriptで記述する（図2）。そのため、事前にアプリケーションをインストールする必要がなく、JavaScriptが動作するWebブラウザであれば、そのまま動作する。

　Ajaxは現在、広く受け入れられているが、図1に示した初期のリッチクライアントに比べ、優れているのは“汎用性”だけである点に注意したい。AjaxではJavaScriptを使うため、ユーザーインタフェースにはHTMLを用いる。必然的にHTML言語による表現の壁は超えられないのだ。

　しかし、JavaScriptではマウスの動きによってイベントを起こすことができるため、表示されている内容をドラッグ＆ドロップで並べ替える、また、スクロールさせるといった操作が実現できる。

　一方、Ajaxではソースを秘匿できないという点も特徴だ。なぜならば、JavaScriptで構成したプログラムであるため、クライアント側にソースをダウンロードした後に実行されるからだ。

　AjaxはJavaScript対応のブラウザで動作するという点も忘れてはならない。イントラネットのような閉じられた環境で、かつ、HTMLでは不可能な機能をWeb上で実現したいのであれば――プリンタを始めとする各種制御や、データのファイルへの保存というWebブラウザでは許可されないセキュリティ上の操作など――図1に示したWindowsアプリケーションなどで構成したほうがよいだろう。

　なお.NET Frameworkでは、Webを使ってクライアントアプリケーションを配布する「ClickOnce」という機能が提供されている。この機能をうまく使えば、イントラネットで（もしくはインターネットでも）、クライアントアプリケーションの配布の手間を軽減できるだろう。

　図1と図2を比較すると分かるように、AjaxはJavaScriptを使ってクライアントアプリケーションを実装したものでしかない。つまりAjaxの本質とは、「Webサービスを呼び出すJavaScriptプログラム」なのである。

図2■Ajaxアプリケーションの仕組み

JavaScriptが開発者を悩ませてきた

　AjaxでJavaScriptが使われるようになったが、JavaScript自体の仕様は昔と何ら変わっていない。

　前述したように、JavaScriptはWebブラウザによって動作の差異があり、ひとたび気を抜けばスクリプトエラーが表示されるので、ユーザーによってはJavaScriptをオフにしている可能性もある。

　そのため、ユーザーが使っているWebブラウザの互換性を考慮してWebアプリケーションを開発しなければならず、Webアプリケーション開発者の負担は、従来以上に増している。したがって今後は、「クライアント側ユーザーインタフェースの担当開発者」と「サーバ側実装の担当開発者」というように、分業が進んでいくことも十分に考えられる。

　JavaScriptを安定して動かすためには、「JavaScriptの文法の理解」だけでなく、「ブラウザ間の挙動の違いを避けるテクニック」が不可欠だ。そのためには、開発をたくさん経験するしかない。しかし、経験を重ねるのは相当な時間を要するだろう。幸い近年は、Ajaxを始めとするJavaScript用のライブラリが続々と登場している。

　そこで今後は、これらのライブラリを使って互換性を吸収し、比較的経験がなくてもJavaScriptでプログラムを書けるような環境が整っていくことになるだろう。

リッチクライアントでWebサーバ負荷が増大傾向に

　また、リッチクライアントが普及すればWebサーバへのアクセス数も増えるという点にも注意したい。これは、ページビューが増えるということではなく、1つのコンテンツを取得する際に従来よりも多くのデータがやり取りされるという意味だ。

　例えば、Ajaxを使ってマウスドラッグで画面をスクロールさせていくアプリケーションを作る場合を考えよう。ユーザーがマウスをドラッグするたびに、Webサーバへのアクセスが発生する恐れがある。

　つまりこれは、従来までは「人間がWebブラウザで操作していた速度」だったものが、「機械的に呼び出される速度」に変わっていくことを意味する。Webサーバは、これに追従する迅速なレスポンスを要求されるのだ。

　そのため、今まで以上に「できるだけ速くサーバ上で処理を行ってブラウザ側に返す」というチューニングが重要視されるのは間違いない。

　例えばプログラム側で考えれば、キャッシュを柔軟に用いて何度も同じデータを生成し直さないようにしたり、ユーザーの区別をせずに同じデータを返すプログラムであれば、セッションを使わずにメモリ消費を抑えるといった工夫をする必要があるだろう。

　またSOAPを使うのではなくREST（REpresentational State Transfer）を使うのも有効だ。SOAPの場合にはXMLの解析処理が必要だが、RESTであればXMLの解析処理が不要になるからだ。もちろん場合によっては、Webサーバのリソース増強も検討しなければならない。

　リッチクライアントから呼び出されるWebサービスは、少量のデータしか返さないことがほとんどだ（そもそも大量のデータを返していると、ユーザーの待ち時間が長くなって、結果として操作性が悪くなる）。そのため、リッチクライアントになるからといって、必要なネットワークの帯域が極端に膨れ上がるようなことは少ないだろう。