Life is beautiful

　　最近、「これからのウェブ・アプリケーションはAjaxだ」という声を良く聞く。ソフトウェアを生業としているエンジニアとしては、この手の「流行もの（hype）」に触れた時には、表面的なものに踊らされずに、その本質を自分なりにしっかりと捕らえて消化・吸収して自分のものにしなければいけない。今までも、「オブジェクト指向」、「マルチ・ティアー・アーキテクチャー」、などの言葉が一人歩きするたびに、「これからは○○だ」とか「○○の時代は終わった」などと、過激なことを言って読者の目を引こうとだけするマスコミや企業のマーケティング戦略に数多くの人が踊らされてきた。

　そんなノイズだらけのメッセージに混乱させられた結果、「Ｃではオブジェクト指向のプログラミングは出来ない」と信じているエンジニアがいまだに沢山いることは全く嘆かわしいことだ。「オブジェクト指向のプログラミング」は、設計姿勢・プログラミングスタイルに関わることであり、C++やJavaと言った言語に依存しなければ出来ないものではない。つまり、Ｃでろうとアセンブラーであろうと、「オブジェクト指向のプログラミング」は可能なのだ。にも関わらず、組み込み系のプロジェクトで、Ｃコンパイラーしかない環境でプログラムを書かせようとすると、「C++で書かないとコードがスパゲッティ状態になってしまいます」などと甘ったれたことを言うエンジニアが多いので困ったものだ。

　Ajaxに関しても、全く同じ誤解が生じそうなので、ここで一言書いておく。Googleなどが進めている第二世代のウェブ・アプリケーションのアーキテクチャーの本質は、XHTMLやXMLやJavascriptにあるのではない。その本質は、

（１）アプリケーションの明示的なインストールが必要ない。
（２）サーバーとの通信を非同期に実行することにより、通信遅延によりＵＩをブロックしない。
（３）サーバーとのやり取りは、ＲＰＣではなく、メッセージで行う。
（４）データ・バインディングはサーバー側ではなく、クライアント側で行う。
（５）ＵＩにインテリジェンスがあり、ある程度はサーバーに戻らずにユーザーとやり取りをする。

の５点にある。この５点さえしっかりと守れば、開発言語はJavaであろうとFlashであろうとも良いし、サーバーとのメッセージにＸＭＬを使わなくともかまわない。その意味で言うと、Ajaxという名前（J=Javascript、x=XML）がそもそもふさわしくしくないとも言える。単に、「非同期メッセージ型ウェブ・アプリケーション（Asynchronous Message-driven Web Application）」と呼ぶ方がずっと明確だし、特定の言語にしばられなくて済む。

　これらの５つの点については、自明だとは思うが、学生や初心者のために付け加えておく。

（１）アプリケーションの明示的なインストールが必要ない。
　こうでなければ、ウェブ・アプリケーションとは呼べない。

（２）サーバーとの通信を非同期に実行することにより、通信遅延によるＵＩのブロッキングを避ける。
　第一世代のウェブ・アプリケーションがリッチ・クライアント・アプリケーションと比べて圧倒的に使い勝手が悪くなるのは、、ハイパーリンクをクリックするたびにユーザーを待たせるためである。通信を非同期にして、ネットワーク遅延をユーザーからできるかぎり隠し、ストレスの少ないユーザー・インターフェイスを提供する点が第二世代のウェブ・アプリケーションだ。

（３）サーバーとのやり取りは、ＲＰＣではなく、メッセージで行う。
　サーバーとの非同期通信には、大きく分けて非同期ＲＰＣ（Remote Procedure Call）と非同期メッセージングの二通りがある。ＲＰＣのそもそもの利点は、「あたかも呼び先の関数がローカルで実装されているかのようにシームレスにプログラムが書ける」点であることに注意すれば、どちらを使えば良いかは自明である。ローカルの関数呼び出しとリモートな関数呼び出しのスピードの開きが１０００倍にもなる今の環境では、プログラマーにシームレスにプログラムを組まれては困るのである。その意味で言って、メッセージを使ったプログラミングスタイルでは、プログラマーはネットワーク遅延を強く意識しながら作るので、結果として使い勝手の良いアプリケーションができる。

（４）データ・バインディングはサーバー側ではなく、クライアント側で行う。
　第一世代のウェブ・アプリケーションは、データとビューのバインディングをサーバー側で行っていたため、新しいデータが必要になるたびに、UI（HTMLページ）全てを再度サーバーに取りに行き、再構築していた。第二世代のウェブ・アプリケーションは、まずビューをクライアントに取り込み、次にデータをメッセージの形でサーバーから取ってくる仕組みであるため、データだけを変更する場合の使い勝手は格段に向上する。

（５）ＵＩにインテリジェンスがあり、ある程度はサーバーに戻らずにユーザーとやり取りをする。
　ユーザーの入力に対して、クライアント側でレスポンスが可能なものに関しては、それを処理するようなインテリジェンスをUI自身（上で述べたビュー）に持たせておき、サーバーとのやり取りなしで処理してしまう。

　最後にもう一度繰り返すが、オブジェクト指向のプログラミングに必ずしもC++やJavaが必要ないのと全く同じ理由で、「非同期メッセージ型ウェブ・アプリケーション」のプログラミングには必ずしもHTML、Javascriopt、ＸＭＬは必要ないことを覚えておいて欲しい。もちろん、「ブラウザー上でプラグインなしで動かしたいからHTML+Javascriptを使う」とか、「ウェブ・サービスとの連携にHTTPを介してXMLをやり取りする」などの理由はもっともなので、それを否定するつもりは全くないので誤解しないで欲しい。実際、メッセージに"XML over HTTP"を使うことには私も大賛成だが、その議論と「非同期メッセージ型ウェブ・アプリケーション」の議論とは全く独立したものである。

　言い換えれば、Ajaxの提唱者たちは、「非同期メッセージ型ウェブ・アプリケーションを作ろう」という主張と、「HTML+Jascript+XMLを使ってウェブ・アプリケーションを作ろう」という主張を一緒くたにして発信しているだけなのである。受け取る側としては、それが二つの独立した主張が混ざったものであることをきちんと理解した上で、消化・吸収することが大切である。

[追記]　読者の一人に「ここに書かれている考えはどこから来ているのですか？」と聞かれたので、お答えします。実は、現在米国 Google で活躍している Adam Bosworth と Gary Burd と私は、マイクロソフトで Internet Explorer 4.0 を一緒に開発していた仲です。マイクロソフトが XML と DHTML の機能を初めて導入したブラウザーです。あの当時から、彼らとは「次世代ウェブ・アプリケーション」の話ばかりしていました。非同期通信の話とか、ＵＩをブロックしないだとか、XML over HTTP の話はその時に始まった話です。ある意味で、Adam も私も、１０年近く同じことを言い続けているわけですね。Gary が私の誘いを蹴って Google に行くと言ったときに、あやしいと思ったのですが、案の定あんなことが始まってしまいました。私も人のことを言える立場ではありませんが（笑）。

［お願い］ソシアル・ブックマーク・サービスをお使いの方がこの記事をブックマークするさいには、何か一言コメントを添えていただけると助かります。ブックマーク・コメントに関しては、恋はブックマークをご覧ください。

［このブログの記事で良く読まれているもの］
日本語とオブジェクト指向
ビル・ゲイツの面接試験－私の場合
愛すべき理科系人間たち
自分が少数派になるだろう項目ベスト１０