第3回 どんなに無茶をやっても「それもありかな」なAjax
株式会社ピーデー川俣 晶
2005/12/28
|
AjaxうきうきWatchではWebアプリのユーザビリティを改善しまくるAjax、Ajax、それはWeb2.0へと続く道とAjax界隈での動向をお伝えしている。 |
ハイライト1・Ajax開発用強力言語 & ツール Backbase |
- - PR -
Ajax関係のツールやライブラリがいろいろ生まれつつあります。特に、アメリアかでは商用の製品も次々とリリースされつつあります。実は、これらの製品のサイトを見て困るのは、具体的にそれが何をしてくれるものであるのか読み取りにくいことが多いことです。Ajaxの特質として、実際に動くデモを見せるのは容易です。例えば、この製品の場合、Backbase RSS Readerというデモのリンクをたどって、RSSリーダーのデモを見ると、それが良くできていて動いていることはすぐに分かります。しかし、この製品がこのRSSリーダーを作成するに当たって、どのように貢献したのかがピンと来ませんでした。
というわけで、ドキュメントをいくつかざっと見てびっくり。これは、クリック数回でJavaScriptのコードを自動生成して便利ですよ、と主張するタイプの「第1印象はすごいが、現場ではいまひとつ使えないツール」ではないのです。手軽にコードを自動生成するツールの問題は、生成できる機能が限定されてしまうことと、生成した後のコードのメンテナンスが面倒なことです。しかし、このBackbaseは、そういうアプローチでAjaxアプリケーションを開発するのではありません。
BackbaseでAjaxアプリケーションを記述するために使うのは、BXML(Backbase eXtensible Markup Language)というXMLによって作られた独自言語です。この言語をXHTML文書の中に埋め込んでコンテンツを記述することができます。BXMLは、XHTMLよりもはるかに高度かつ強力な機能を提供するので、より手軽にリッチなAjaxアプリケーションを開発できるわけです。
もちろん、独自に決めた言語をXHTML文書に埋め込んでWebブラウザに送っても、それが解釈されることはありません。そこで出てくるのがBPC(Backbase Presentation Client)というJavaScriptプログラムです。XHTML文書には、このBPCへの参照を含めておき、文書が読み込まれた時点でこれが実行されるようにします。そして、このBPCがBXMLで記述されたコンテンツを解釈して実行します。(おそらく、Webブラウザ内で動的に解釈と実行が行われると思います)
このようなアプローチには、当然のことながら長所と短所があります。長所は、もちろんより高水準の使いやすい言語でアプリケーションを開発できることです。これによって開発効率が上がるのは間違いないでしょう。一方で、短所としては独自言語を解釈するまでの手順が生じるため、ページを表示するときの待ち時間が増えることがあります。また、1企業の独自言語を習得するというのも、覚えた知識の再利用性が制限されるという意味で、短所と見なせるかもしれません。
ちなみに、BackbaseにはVisual Studioでビジュアル開発するプラグインであるとか、J2EEと連携するツールなどもあり、開発効率は高そうです。
さて、Backbaseのような独自言語を使ってしまえ、というアプローチは、実はJavaScriptで開発することを条件の1つに据えているAjaxの定義に反すると見ることができます。確かに最終的にはJavaScriptとして実行されますが、主たる記述言語はJavaScriptではありません。
この点に関していえば、Ajaxにタブーはなく、JavaScriptで記述するであるとか、XMLHttpRequestオブジェクトを使うといったAjaxの定義に含まれる条件はいくら破っても構わないと考えます。事実、Ajaxブームの原点ともいえるGoogle Mapsで地図がマウスドラッグでスクロールする機能を実現するために、XMLHttpRequestオブジェクトは特に寄与していないのです。原点からしてこのような状況ですから、既存のWebブラウザ上でユーザビリティを上げる手法を用いたものはすべてAjaxと呼んで差し支えない……、つまりAjaxにタブーはないと考えます。
ハイライト2・Webブラウザの違いを自動判定・BrowserHawk |
このBrowserHawkというソフトも、一見して何をしてくれるのか分かりにくいものでした。これは、サーバ側でWebブラウザの種類を判定して、処理を変えるためのソフトです。ブラウザの種類を定義する“visual browser definition editor”とサーバ側のActiveXコンポーネントまたはJavaBeanから構成されます。これがどれぐらい詳細なWebブラウザのチェックを行ってくれるかは、以下のデモページを見ると分かると思います。
これを見ると分かるとおり、単にWebブラウザの種類やバージョン、プラットフォームなどを調べるだけでなく、クッキーやSSLがユーザーの設定で有効か否か、SVGなどのプラグインがインストールされているか、Flashプラグインのバージョンはいくつかなどもすべてチェックされます。しかも、恐れ入ったことにブロードバンド接続かどうかも判定され、接続スピードも計測されています。これらの情報を元にして、プログラムに最適な動作を行うようにできれば、非常に使いやすく優れたソフトができるでしょう。
ちなみに、このツールはサーバ側のツールということもあって、Ajax専用という訳ではないと思います。しかし、Webブラウザの非互換性を前にして「標準に適合しないから駄目だ」と不平をいいつつコードは書かない態度よりも、すでにあるWebブラウザの種類ごとに動作させるコードを変えることで今すぐ動くコードを作っていこうという態度は、Ajaxの精神に沿ったものであるように感じられます。
ハイライト3・すぐに反応が返ってくるチャット ConnectiveChat |
Ajaxにタブーはなく、すでにあるものを使って創意と工夫で乗り越えていくことが肯定されます。このチャットプログラムは、まさに創意と工夫でハンデを乗り越えた好例だと思います。
通常、Webアプリケーションは、クライアント側で構築する場合でも。サーバ側で構築する場合でも、通信開始の主導権はクライアント側が持ちます。例えば、何かのデータを取得するボタンをクリックしたときに、通信が発生することになりますが、これはクライアント側の操作がトリガとなって通信が始まることを意味します。
しかし、このようなアーキテクチャは、サーバ側で発生した状態の変化を機敏に察知してクライアント側に反映させることが困難です。典型的な例が、チャットを行うプログラムです。チャットは複数のクライアントから不定期にメッセージが送信され、それがすべての利用者に転送されます。しかし、メッセージを受け取ったサーバは、即座にメッセージがあるという事実をすべてのクライアントに通知する手段がありません。通信を開始する主導権はクライアント側にあって、サーバ側にはないからです。その結果、一定時間ごとにクライアント側がサーバに問い合わせるポーリングというテクニックが定番として使われることになります。ところが、このポーリングという処理は、間隔が長いと届いたメッセージが反映されるまでのタイムラグが長くなり、逆に間隔を短くするとネットワークとサーバの負荷が高くなるという問題が生じます。
さて、このConnectiveChatは、この問題を創意と工夫で解決しました。複数のパソコンから接続して試すとすぐに分かりますが、1つのクライアントに入力したメッセージは、即座にすべてのパソコンに反映されます。これはクライアント側が先に通信を開始させておき、それに対する応答を別のクライアントからのメッセージを受信するまで遅延させるという方法で実現されています。まさにクライアント側で処理を行うAjaxならではのテクニックといえます。サーバ側のプログラムで、これと同等の処理を行うことはおそらく困難でしょう。
| 1/2 |
|
INDEX |
||
| どんなに無茶をやっても「それもありかな」なAjax | ||
| Page1<全方位攻略 Ajaxにタブーはない!>Ajax開発用強力言語 & ツール Backbase/Webブラウザの違いを自動判定・BrowserHawk/すぐに反応が返ってくるチャット ConnectiveChat | ||
| Page2<そのほかのみどころ> 自分のブログに地図を貼れるちず窓β/街路の写真があるA9.com Maps/Ruby on Railsによるリバーシゲーム/Google Maps APIを背景にしたゲームMozilla専用、3DなGoogle Maps | ||
Ajax うきうき Watch バックナンバー
- 第1回 Webアプリのユーザビリティを改善しまくるAjax
- 第2回 Ajax、それはWeb 2.0へと続く道
- 第3回 どんなに無茶をやっても「それもありかな」なAjax
- 第4回 自動車業界のAjaxを活用したキャンペーンを目撃せよ
- 第5回 “どのブラウザでも動くAjax”を共有財産として育てよう
- 第6回 プロプライエタリ2.0から考えるAjaxの公開/非公開部
- 第7回 メモリリークが小さくなったGoogle Maps APIの新版
- 第8回 “CGUI” 消費者が作り出すUIの時代突入
- 第9回 巨大化するAjaxライブラリをシンプルにする新たな流れ
- 第10回 地図のように年代を移動できるMITのAjax歴史年表
- 第11回 JSONがRFCになり、どんどんこなれるAjaxサービス
- 第12回 サーバが通信を開始できるComet活用Webチャット
- 第13回 オンラインゲームで検索精度を上げるGoogleの巧みさ
- 第14回 IE7とFirefox 2への利用者の大移動は起こるか?
- 第15回 グーグル検索エンジンを特定ジャンル専用に、Co-op
- 第16回 帯域やデバイス領域をフル活用させる“モバイルAjax”
- 第17回 新しい技術を模索するYahoo!、Google、MS
- 第18回 Ajaxの高度な使用例、Yahoo! pipes
- 第19回 Apollo参戦でウィジェット開発者の争奪戦が激化
- 第20回 Twitter登場で注目されるRTコミュニケーションツール
- 第21回 過熱するTwitterブームとMicrosoftのマッシュアップ
- 第22回 iPhoneのAjax戦略、そして今日もWeb APIは増加する
- 第23回 Ajax開発者がヒーローになるとき、それはいま!
- 第24回 携帯電話への拡張を進めるGoogleとWeb隠しコマンド
- 第25回 Ajaxで加速!? エンタープライズ2.0とWebOSの普及
- 第26回 「言葉」を超えた説得力を持つAjaxの存在感と広がり
- 第27回 ゲームから読み解く、俺スクリプト時代の知的な挑戦
- 第28回 マッシュアップ元年が終わり、2008年はどうなる?
- 第29回 Twitterやクラウドへも分岐するAjax/Web APIの道
- 第30回 Ajaxはじめて物語、そしてサーバでも動くJavaScript
- 第31回 新ブラウザ戦争はon fireだがJavaScriptはoffのナゾ
- 第32回 Google App EngineはAjaxへのハードルを下げるか?
- 最終回 Pure JavaScriptの動画再生やRPGも好きでした
AjaxとPHPでリッチクライアント
Ajaxを扱うためのサーバーサイドのPHPライブラリを紹介する。リリースされたライブラリ、AjaxACを活用して好みの検索窓に改造してみよう
AjaxでつくるインタラクティブWebアプリケーション
AjaxでWebフォトアルバムを、ゼロから開発する。ライブラリを用いて機能を作り上げていくステップを、具体的に解説する
| 古くて新しいAjaxの真実を見極める 「Webインターフェイスの新しい手法」「画期的なWebアプリケーションの仕組み」であるとして開発者たちの人気を集めるAjaxとは何なのか、その真実を見極めてみよう 最終更新 2005/8/2
|
||
TechTargetジャパン
- コンテンツ政策ヲ転換セヨ! (2012/2/10)
mixiにしろTwitterにしろニコ動にしろ、ソーシャルサービスは伸びている。シロウトの個人が作るコンテンツで成り立つサービスだ - NFCやLTE対応予定のiPhoneと、先行するAndroid (2012/2/9)
iPhoneとAndroid、そしてWindows Phoneという3つのOSの今後を占う。それぞれの通信規格とコンセプトは? - 家電のUIになるブラウザ (2012/2/3)
未来の家電はインターネットに接続でき、ブラウザが内蔵されてくる。家電にブラウザが載ったらどうなるか? 未来のホームネットワークを想像しよう - 「汎用のUI技術」として広がるHTML5 (2012/2/2)
すさまじい勢いで成長しているHTML5を中心としたオープンなWebプラットフォーム。HTML5やAPI、Webブラウザのアップデート情報をお伝えする
|
|
