あなたは「Web2.0」という用語を聞いたことがあるだろうか ?
今、Webの世界を席巻している話題の中心と言えば「Web2.0」であり、その中核を成す技術が Ajax である。
Web2.0 とは今後の Webサイトのあるべき姿としてオライリーが提唱したものであるが
Web2.0 の規格(?) を技術的な立場として端的に表されるのが「Ajax」(エージャックス) である。
Ajax とは a Syncrohous JavaScript ＋ XML、邦訳すれば XML による非同期通信ということである。
Ajax の詳細な紹介は「アイマガジン vol3」(2007年7月27日号) で筆者が解説しているので
是非、そちらもご覧頂きたいが、ここでは簡単に Ajax について紹介しよう。

まずその前に、ネットサーフィン(これも死語?) で、いろいろなサイト上でクリックを押したりしてSUBMIT (投入) 操作を毎日、行っていることであろう。
このとき一瞬であるかも知れないがページが消滅してから、次の新しいページが表示されることにお気づきであると思う。
これはWebサイトは基本的に「ページ遷移」であり、ページ単位での入出力を行っているからで
ある。これは HTTPプロトコルの仕様であり、「ページ遷移」を行わないで一部だけを更新する
ように作成することはできない。

しかし私達が扱っている 5250画面を想像して欲しい。
ロールアップ・キーを押すと次頁が表示されるが、これは SFL 部分の更新だけで十分なはずで
ある。ところが Webサイトの従来の仕様ではページ全体が新規に更新するしか方法がなかった。

もし、そのページが結構な量の JavaScript を含んでいたり、レイアウト情報やスタイルシートの部分が多かったりしても、毎回、同じデータがブラウザに送られてくるのである。

これは非常に無駄なことであり、通信量が増えることによってパフォーマンスは著しく低下してしまう。
これに対して、一世を風靡したリッチクライアント型のソフトウェア製品の場合はデータ部分だけを CSV や XML で送信されてくるので、良好なパフォーマンスを得ることができた。
フォームはクライアントに常にキャッシュ(保管) されているからである。
ところがリッチクライアント型の適用業務であれば、インターネット経由での使用が困難であったり再配布の手間が多く、また HTML のように柔軟ではなかった。

このリッチクライアント型の欠点を補って、リッチクライアント型の長所だけを取り入れたのが
Ajax による適用業務である。

つまり Ajax を使うとブラウザとサーバーのあいだの通信は XML だけのデータのやり取りとなってHTMLフレームは ローカルPC にブラウザによって自動的にキャッシュされる。
しかも HTML に変更があれば HTTPサーバーによってこれまた自動的に再配布されるので
システム管理部門による再配布の手間は全く必要ではなくなる。

これまでのことをまとめると Ajax とは

非同期によるXMLデータ通信を JavaScript によって行う技術

であると言える。
Ajax を組み込むことは、まだ JavaScript にも精通してない開発者にとっても、それほど難しい
ことではない。ほんのわずかな JaVaScript を HTML に組み込むだけでサーバー側の CGI の
処理は大幅に変革して楽な開発となる。
何せ、CGI では HTML を送出する必要が全く無くなるのである。
XML がまだ苦手とするならば、レコードを送出するだけでもよいのである。
( しかし 必要な XML は 5分もあれば知ることができる。)

それでは非同期によって XML を送出するだけで何が変貌するのだろうか ?
一体、これほど騒がれている Ajax のどこがスゴイのであろうか ?

Ajax を利用すると次のようなことを実現することができる。

• 動的な画面の表現
• データとフレームの分離
• パフォーマンスの向上

動的な画面の表現

Ajax を使えば、Webサイトのページの一部分だけをユーザーの操作に応じて動的に変化
させることができる。
例えば、部品表の構成でユーザーがクリックした製品だけの構成図を、その場で動的に
展開して表示することができる。
もし Ajax がなければ、ユーザーがどの製品の構成を要求するかは前もって知ることが
できないので、あらかじめすべての部品構成をブラウザへダウンロードしておかなければならない。
ほんのわずかな構成を調べたいだけなのに大量の部品構成をダウンロードするような仕組み
であればユーザーのイライラを避けることができないかも知れない。
このような事例はいくらでもある。あなたの会社の適用業務の中で想像して頂きたい。

データとフレームの分離

Ajax を使えば CGI はデータとしての XML を送出するだけでよいので HTML に触れる
必要もなくHTML を個別に保守することができる。
例えば、これまで CGI の中にコンボボックスの HTML を含んでいるような適用業務で
あれば、保守は RPG/COBOL と HTML、JavaScript の両方に精通している開発者
にしかできないことになる。
また フォームを変更したいだけなのに JSP に精通した人にしか保守することができない。
HTML を理解することができる総人口に比べて JSP が理解できる人口は圧倒的に少ないのである。
さらには System i5/OS ＋ JSP が理解できて保守できる人口となると、砂浜から落としたコンタクト・レンズを探すような話になってしまう。
合理化やコスト削減が叫ばれているこの時代に非合理的は話ではないだろうか ?
Ajax によるデータとフレーム(HTML) を分離さえしてしまえば HTML の保守であれば
自分の HomePage を熱心にイジッている隣の家のオバさん(失礼) にでも保守を頼める
かも知れないのだ。
CGI の開発者はただデータを送出することにだけ専念すればよいことになる。
CGI は単なるバッチ転送のプログラムとなってしまうのである。
後で紹介するが CGI は非常に簡単なものになる。

パフォーマンスの向上

Ajax を使えば、劇的なパフォーマンスの向上を図ることができる。
あなたはこれまで過去に表示したWebサイトをもう一度、表示しようするときに、そのサイトに何の変更もなければ非常に速い速度でブラウザに表示されることを体感的にご存知のはずである。
逆に初めて表示するサイトか、または、そのサイトに前回表示のときより変更があれば表示に時間を要することになる。
このように変更のないサイトが素早く表示されるのは、以前に表示されたページのコンテンツがあなたのPC にキャッシュされているからである。
筆者は HTTPサーバーの開発者でもあるところから、このような HTTPプロトコルの動作は
つねに意識している。Ajax に市販解説書には、この重要な点が語られることは稀である。
これは Ajax解説本の著者が JavaScript には精通しているものの HTTPプロトコルまでの正確な知識か意識があまり無いのではないかと推測される。
これまでの CGI の起動の方法は

http://192.168.1.1/cgi-bin/MYCGI.PGM

のように CGI 名 : MYCGI を指定して起動するようにしてきたはずである。ところが

http://192.168.1.1/MYPAGE.HTM

のようにして Ajax を含む HTML : MYPAGE.HTM を起動するようにすれば MYPAGE.HTM は確実にブラウザによってローカルPC にキャッシュ保存される。
最初の起動および MYPAGE.HTM に変更が加えられたときだけはダウンロードされるがMYPAGE.HTM に変更の無い限りは一度でもダウンロードされると二度とダウンロードされることは決してない。
したがってほんどの場合は、このページを要求してもローカルPC からロードされることになる
ので、表示に至るパフォーマンスは劇的に改善されることになる。
データ部分だけが XML としてダウンロードされてくるが、この通信量はフレーム部分に
比べると極く小さなものである。
このことが多くの場合データを扱うことを目的としている私達にとって、大変なメリットをもたらして
くれるのである。