非同期処理のアーキテクチャとは
最近、リッチクライアントが流行している（ように見える）。
理由は、UIの操作性よりも、非同期処理の実現にあるのではないか？
Webの技術では同期処理が基本である。HTTPのリクエストを投げてレスポンスを待ちページを表示する。
だから、WebはUIの操作性だけでなく、技術的にも制約が大きい。
非同期処理は、つまりバッチ処理。
業務系では至極当然のアーキテクチャ。
バッチ処理は設計力が鍵を握る。
Web上での非同期処理の実現方法は何がBetterか？
答えはWebサービス。
つまり、クライアントはXMLデータをバックグラウンドでサーバーとやり取りする。
Googleがこのアーキテクチャをうまく使ってサービスをどんどん提供している。
Ajaxの凄さは、UI操作性だけではなく、非同期処理にある。
Ajaxの威力を見せつけた例は、Google Mapsだった。
GMailは、勝手にリフレッシュし、メール一覧を更新する。
GMailにもAjaxが使われている。
GoogleMapsEditor は、GoogleMapsAPI を利用して地図を作成する。
ユーザが住所と関連付けて書き込んだ情報はローカルのXMLに保存される。
すごいのは、そのXMLを使うと、地図情報を埋め込んだ出力したHTMLファイルだけでGoogle Mapsが利用可能になること。
一般に地図情報システムは、クライアント：VBアプリ＋サーバー：ベンダーごとの製品ゆえ、非常に高価で、バッチ処理が基本なのでレスポンスも良くなく、使い勝手が悪い。Google Mapsは、普通の地図検索製品よりもはるかにお手軽でしかも無料で地図を作れるサービスと技術を提示したことに意義がある。
他にも、Blogがある。RSSはWebサービスそのもの。
つまりプッシュ配信サービスと言ってよい。
Webソリューションの進化系はおそらく非同期処理のアーキテクチャを洗練させることにあるのではなかろうか？
| 固定リンク
「日記・コラム・つぶやき」カテゴリの記事
- TwitterやFacebookは人力キュレーションツールとして使う(2022.10.02)
- 「現代病「集中できない」を知力に変える 読む力 最新スキル大全」の感想(2022.08.28)
- 人類は海辺から生まれた～水生類人猿説が面白い(2022.08.09)
- 戦前の日本人の気質はまだ成熟していない青年期と同じだった(2022.06.14)
- 物理学を攻略するためのマップ(2022.04.18)
「プログラミング」カテゴリの記事
- Javaのモジュールシステムの考え方をまとめてみた(2022.10.21)
- Javaのモジュールシステムは複雑性をより増している(2022.09.10)
- Javaはなぜ関数型言語になろうとしているのか(2022.09.02)
- Javaのラムダ式の考え方(2022.08.10)
- Javaはオブジェクト指向言語ではなく関数型言語だった～「[増補改訂]関数プログラミング実践入門」はお勧めの本だ(2022.08.06)
コメント
とうも、ご無沙汰してます。
さてさて、
>Web上での非同期処理の実現方法は何がBetterか？
>答えはWebサービス。
ここ、ちょっと違和感があるんですが。
Webサービスって端的には“繋ぐ技術”ですよね？
繋いだうえで、振る舞いが同期か非同期かというのは別の問題ではないでしょうか？
ひょっとして「Webサービス」の定義がちがうのかな･･･。
ただ、一般的なSOAP／WSDL／UDDIの組み合わせ、あるいはSOAに近い広義な意味にとっても直接に同期・非同期のアーキテクチャってことにはならないと思うので、もう少し厳密な言葉の定義が欲しいかなぁ、と言う感じです。
Webアプリにおける非同期処理というのは技術的にはローカルキャッシュと(リポジトリへの)マージの問題であり、突き詰めれば“マージすることが可能な(あるいは意味のある)類の情報か？”という分析力の問題かと思います。
Webアプリはそもそものシステム要件としてリアルタイム性を要求されるケースがほとんどです（だからWebで作る）から、非同期処理が必要となるのはクライアントが孤立するケース。
そして非同期処理が可能なのは、クライアントが復帰して即時にマージが可能な情報、ということで、ほぼ当該ユーザー個人に帰結する情報に限定されるでしょう。
＃そうでなければ最終的に“運用で同期”という考慮もなされているはずです。。。
それに対してC/SSでは扱う情報の性質から同期処理か非同期処理かを選択します。
つまり結果として同じような非同期処理の仕組みを作ったとしても、動機・経緯は異質です。
>業務系では至極当然のアーキテクチャ。
>バッチ処理は設計力が鍵を握る。
なのですが、この“どうやって実現するか？”という視点の前提として“なんの為に実現するか？”という視点もセットにしないと、大事なことを見落としてしまう気がします。
なので、この記事の導入であったリッチクライアントにしても、
>由は、UIの操作性よりも、非同期処理の実現にあるのではないか？
とは思いません。
“非同期処理の実現”はあくまで作る側の問題だからです。
ユーザー側から見れば、C/SS時代の快適なGUIが忘れられないエンドユーザーの操作性への要求、Webアプリに移行してシステムの面倒を見る手間・ヒマが大幅に減った管理者の要求を同時に満たしてさえくれれば、手段は何でも良い訳ですから。
･･･う～ん・・・。
長々と書いちゃったんで、なんか支離滅裂ですね。
また勉強会で、、、と言いつつドロン♪
投稿: やぎ | 2005/09/06 09:54
お久しぶりです。
ご丁寧なご指摘ありがとうございます。
仕事の詳細内容をBlogに書けないので「何のためのシステムか」という目的が抜けているし、Blogゆえに思いついたことをスラスラ書いているので、奥歯に物が挟まった感じで読みづらいと思います(m_m)
やぎさんが言う通り、クライアントが孤立した場合のシステム設計もしました。実装は簡単ですが。
Webサービスの定義はやぎさんと同じです。
クライアントからサーバーへ複雑な情報をXMLで送信する処理を設計に組み込まないといけないという意味をこめてますが、全然伝わってないですね(m_m)
ここの設計や技術検証に今手間取っていて、ああでもない、こうでもない、と悩んでいる所です。
＃.NETはJavaほど技術が枯れていない。。
やぎさん、やまねさんとアーキテクチャ・パターンについて議論してみたい所です。。
投稿: あきぴー | 2005/09/08 00:25