AJAX
 
HOME
LAJAXS
JSON
カレンダーコントロール
Homepage
Blog
 

Last Update: 2005/12/07
LAJAXS ライブラリの更新。

1.About AJAX

 AJAX とは(Asynchronous JavaScript And XML) の略で、

  1. クライアント側は、 JavaScript を使用した動的UIを提供
  2. サーバーと非同期にデータ通信を行う
  3. 取得するデータの形式に xml を使用する

と言う特徴を持つWeb Applicatoinの実装方法です。

 どれもよく知られている技術だし、既にそういう方法論を使用している人たちもいました。私も数年前のプロジェクトで似た様なアプローチのシステムを構築した経験があります。では何が違ってこういう風にもてはやされるようになったのかと言えば、「AJAX と言う名前を付けて開発フレームワークとして明確化した」点が重要な訳です。デザインパターンの時もそうでしたが、「言葉は力である」と言う事を改めて認識させられました。

原典は、「Ajax: A New Approach to Web Applications」を参照してください。けんたろ氏による日本語訳もあります。

5.AJAX Library

 AJAX/AJAS 的アプローチに必要な要素技術やサンプルなど。
  • JavaScript 圧縮
     「何でこれが最初に来るのか?」と思われるかもしれませんが、RIAを重視するにせよServer負荷軽減を重視するにせよ、スクリプトとは言えJavaScriptもコードです。コードは人間が管理するので、読みやすなくてはならないし、ドキュメントも必要です。しかしソースがそのまま利用されるJavaScriptでこういうコードの管理をしていくと、必然的にサイズが大きくなります。また開発生産性の向上の為に、色々なコンポーネントを組み合わせて作っていく事になるので、必要なファイルサイズは増大する一方になるでしょう。しかしそれを避けるために、20年以上前のパソコンBASICの時代に戻った様なコードを書く訳にも行きません。
     そこで登場するのが、このスクリプト圧縮。機能はそのままで、実行時に必要の無いコメント、スペース、改行等を取り除き、ローカル識別子を短い名前に変えてくれます。これで開発時はメンテしやすくコードを書いて、実行時にはコンパクトにして環境(サーバー、回線、クライアントキャッシュ等)に優しくする事ができます。一般的なソフトウエア開発者なら、コードを書いて、コンパイルビルドして、実行と言う手順を採っているので、コードを書いて、圧縮ビルドして、実行と言うスタイルに違和感は全く無いでしょう。
     これはわざわざ自分で作るまでも無く、便利なものが色々公開されています。現在私が使っているのは「Dojo's compression」。VS.NET/VS2005で、カスタムビルドに設定しておき、ビルド時に *.js→*.jsc と実行される様にして使っています。
    自分用インストールメモ
    1.C:\Program Files\Support Tools に custom_rhino.jar をコピー。
    2.C:\Program Files\Support Tools に jscomp.cmd を作成。
      内容:java -jar "C:\Program Files\Support Tools\custom_rhino.jar" -c %1.js > %1.jsc 2>&1
    3.Sample.js をビルドする場合は、コマンドラインから jscomp Sample と入力すると、Sample.jsc が生成される。
     
  • LAJAXS
     AJAX の中心となる非同期通信を司るのは、Microsoft の ActiveX Object である XMLHTTP と、それに互換な XMLHttpRequest Object です。現在、JavaScript 側のフレームワークから、サーバーサイドのものまで色々あります。
     ここではサーバー負荷軽減を目論んでいる為、どちらかと言うと EoD (Ease of Development) 向きのサーバー側でAJAX スクリプトまで生成してくれるサーバーサイドフレームワーク系(Java/PHP/.Net各種ありますね)は、ちょっと遠慮したいと思っています。
     また、Prototype 系のクライアント側フレームワークは中々便利そうですが、RIA側により過ぎているし、ライセンス的に上記の様な開発時と運用時にコード変換してしまう場合に使いずらいと言う問題あります。
     結局、今のところは昔使っていたモジュールに少し手を加えた自作のモジュールを使っています。
     これはドキュメントをもう少し書いて、ここで公開します。
  • 交換用データ形式
     非同期通信様のオブジェクトには、サーバーからのレスポンスを、プレーンなテキストとして受け取るか、xml dom オブジェクトとして受け取るかができます。その他に「JSON」と呼ばれる JavaScript に特化した軽量なデータ形式が用いられます。サーバー側負荷軽減には「JSON」が相応しいと思いますので、これに関連する考察を...。
  • カレンダーコントロール
     ちょっと待った。サーバー負荷軽減を考えているはずなのに、なにゆえカレンダーコントロール?いや、クライアント側JavaScript 関連を調べていたら、たまたま「日付入力用カレンダー生成」と言うページを見つけて、「おお、なかなか良いじゃん」と感心し、さらにリンクを辿って「カレンダーコントロール色々」という所で祝日表示拡張版を見て、はたと気がついた事があった訳です。「サーバー負荷軽減以外にも、AJAS的アプローチが使えるじゃん!」。そういう訳で、本道を歩く前にまず横道にそれてみました、と言ったところです。
  • Visual Studio 2005 による AJAX 開発
     私のメインの開発環境は、Microsoft Visual Studio です。VS2005 からは、カスタムテンプレートやスターターキット等が作れるので、AJAX 開発に向いたそういうものがあったら便利ですね。と言う訳で、現在のプロジェクトを少し整理してこういうのにまとめておきたいと考えています。(現在準備中)

2.AJAX Essence

 さてこの AJAX、上記特徴の 1、2 は良いとしても 3 はどうでも良さそうだと言う事は、すぐに気がつくでしょう。そのため、既に色々なデータ形式が試みられています。つまりこの開発方法論の主要点は、「非同期データ通信+クライアント側スクリプト」にある事がわかります。その為、最後の「XML」部分を「X」=何かのデータ形式に置き換えてAJAX を「Asynchronous JavaScript And X」の略であると再定義している人達もいます。

 この実装方法によるメリットには、

  1. クライアント側に HTML だけでは表現できない、レスポンス良いUIを提供できる
  2. サーバー側の HTML レンダリング処理の大部分をクライアント側に移せるので、サーバー側処理が軽くなる

 と言う点が挙げられます。もちろんデメリットもあります。

  1. サーバサイドに比べて貧弱な開発環境による開発生産性の低下
  2. ブラウザの差異によるテスト負荷の増大
  3. 細切れのデータアクセスによるオーバーヘッドの増大によるサーバー負荷の増大

 従ってこの方法を使う場合、これらを良く勘案して適用する必要があるでしょう。

3.AJAX for RIA (Rich Internet Application)

 一般的にこのAJAXを目にするのは、「リッチクライアント」の文脈で使用される事が多いと思います。これは事の発端がGoogle Mapsにあって、標準的なブラウザ技術を用いているだけなの、まるでローカルにインストールされているアプリケーションを使っている様な操作性を提供している驚きから始まっているからでしょう。

 しかし、自分がこれに似たアプローチを採った時の状況はどうだったかを振り返ってみると、「貧弱なサーバーでできるだけたくさんの端末をサポートしたい」と言う要求に答える為でした。リッチクライアントの方は、ずいぶん前から「JavaScript だけでここまでできる!」的に、UIが非常に重要なゲームを含めて色々なものが作成されています。こちらの方向は突き詰めていくと、それこそ万単位の行数のスクリプトを書かなくてならない羽目になりそうな気がします。ブラウザ間の差異・言語仕様・開発ツール等にまだまだ問題があって、こういう方向はやっぱりできるだけ避けたいと言うのが、開発者側の本音だと思います。そこでこのホームページでは、もう一方のメリット「サーバー側の処理を軽くする」ための使い方を色々と考えてみる事にしようと思っています。

4.AJAX for Servers

 ではサーバー側の負荷を軽くする為にはどうすれば良いのか? AJAX 的アプローチを採る事によって、少なくともサーバー側で html を生成する処理は大きく省かれます。しかし、動的ページには必ずデータベースアクセスが伴います。一つのページを構成するのに必要なDBリクエストの数は減りません。

 極端なたとえ話をすると、従来どおりのサーバーサイドページ生成では、一回の http request でサーバー側では10回のDBクエリを行い、ページを作成して response を返すと言う状況だったとします。これが AJAX 的アプローチによって、ページリクエストに1回、DBアクセスの為に10回の http request が必要になってしまったとすると、おそらく後者の方がサーバー負荷が高まってしまうでしょう。もちろん、AJAX 的アプローチに変えてもDB用 http request を一回にしてしまえば殆ど変わりませんが、AJAX 的アプローチに変われば、必然的にコンポーネント毎にリクエストを発生させなければならないので、そういう事はまずできないと考えられます。従って、まずこのDBアクセスをどうにかしたいと考えます。

 最近やった仕事の中に、サイト全体を静的に生成すると言うアプローチのプロジェクトがありました。これには色々な目的があるのですが、その目的の一つに上記のDBアクセスの数を減らしてサーバー負荷を軽減すると言うものがあります。この考えを上記の問題に適用すれば「ページ生成に必要なデータを事前に生成しておく」と言うアプローチが有効なのでは無いか?と考えられます。そうすれば、例え上記の様に多数の細切れデータアクセスになっても、サーバー側はただの静的データファイルを送出するだけですので、負荷はぐっと小さくなるはずです。

 もしこの「事前生成」アプローチが有効であるとするなら、なにもAJAX的にしなくても従来どおりのサーバーサイドアプリケーションでも有効なのでは無いかと思われるでしょう。実際有効です。SSI と言うのはこういう方向の仕組みです。しかし、沢山のページを持つサイトに行ってみればわかると思いますが、一つのページと言うものは色々な部分から構成されています(ヘッダー、フッター、メニュー、ガイド表示、広告等...)。何百万、何千万と言うページがあっても、これらの部品はごく限られたパターンしか持っていません。動的・静的を問わずサーバー側でページを生成する言うことは、毎回こういうものを全てサーバーで合成してから送出しなければならないと言う事になります。もし1ページあたり10KBのデータ送出量が必要なら、1万リクエストで100MBのデータを転送する必要がありますが、それらをコンポーネントに分離してクライアント側で合成できれば、データ転送量を半分以下にする事もできるでしょう。つまりサーバーサイドではなく「クライアントサイドでデータを合成する」という事が負荷軽減に大きく寄与できると考えられます。クライアントサイドでのページ合成は、現在でも frame/iframe を使えば可能ですが、利用状況に色々と制限があります。そこで AJAX 的アプローチの出番となります。

 以上をまとめると、「サーバー側で事前生成されたデータファイルを、非同期通信によってクライアントに取り込んでページ生成」と言うアプローチが、AJAX for Servers にとって有効なのでは無いかと思います。
 さて、では先人にならって、これに名前を付けておきたいのですが、何が良いか?。うーん。とりあえず「Asynchronous JavaScript And Static Data」=AJAS(エイジャス)とでもしておきましょうか。ちょっとしっくりきませんが....

 ただし今のところこの方法には大きな欠点があります。それはこのページが検索エンジンに引っかかりにくくなると言う事です。しかし、これは AJAX for RIA なページでも同じことです。対策は...今後の課題でしょうね。
しかし、もしも将来こういうページ構成が普通になる時代がきたら、検索エンジンはどうやってページをインデックスするようになるのか、大変興味があります。

HOME | LAJAXS | JSON | カレンダーコントロール
Copyright (C) 2005 Takashi Oyama All Rights Reserved.