Ajaxの長所・短所・実装に関するメモ (暫定版)のメモ
より、
しかし、Ajax分散モデルは、いわゆるWebサービスの分散モデルとは決定的に異なります。
いわゆるWebサービスの分散モデルは、不特定多数のサービスを検索によって集め、それらを組み合わせて応用システムを構築します。
たしかにSOA的なWeb Servicesとは違う。けれど、AJAXといえどもWebの１コンポーネントであるべきで、設計的にはUIとしての機能よりもまずリソースとしての振り分けが先に行われるべきでしょう。その上で個別のリソースに機能をAJAXで付加したり、もしくはまとめたUIをその上にかぶせることになるのでは。
そういう点では、上の文章では無視されてしまったXMLメッセージのURIとその意味の割付こそが設計の肝ではないでしょうか。クライアントステートを保持しないサーバを実現し、かつリッチなUIを実現するために、AJAXを使うというのが手順であるべきだと思います。こういうことができることこそがAJAXの長所だと思うんですが。つまり、AJAXはRESTスタイル上でのアプリ実装のより使いやすい解だと思うんです。
UIの機能（スタイル？）をトップにして分解しているので変になるのではないかとも思う。まずオンラインゲームとの対比は危ういメタファでしょう。実際のオンゲーはコネクション依存した通信を使うことも多いですし、これはXmlHttpとはかけ離れています。ゲームフレームワーク設計で多いフレーム処理もAJAXのイベントコールバックとは少し離れてしまう。あと、自動セーブという文脈も危うい。リソースへの編集かどうかという設計視点が無ければ、検索エンジンのフォームでもサーバへ自動セーブをさせようとするかもしれませんし、そうなればサーバ処理は一気に複雑になりますから。こういう視点になれば、AJAXは短所だらけになるし、企業AppletやWeb Servicesでの悲劇を繰り返すと思う。これが一般での見解であるとも思えないけど、そういう見方をする人が従来的な企業システム分野にはあるていど居るだろうことは予想がつきます。
ところでより完全な分散システムにするには、XmlHttpRequestでつなげる先は増やしたいところだけど、昨今のプライバシー事情からは、起源サーバは同一であるべきなのでしょう（埋め込み画像でさえそうなのだから）。フロントエンドプロクシになるサーバを挟めばよいわけですけど、こういうソリューションはなんか納得はいかない。このへんもインタラクティブな解がないものだろうか。
