昨年から「リッチクライアント」という言葉に注目が集まっているのは
周知のことかと思います。そこでリッチクライアントについて考えてみ
ました。まず言葉の定義ですが、以下では「リッチクライアント」=「
従来の専用クライアントと同等の機能を持ちながらブラウザ並みの容易
な運用管理が可能なクライアントアプリケーション」としておきたいと
思います。人によって若干の定義の違いはあるかと思いますが、概ね外
れてはいないでしょう。
昨今目にする記事ではHTMLベースのユーザーインターフェースの使い勝手
の悪さに注目し、それらを改善する手段としてリッチクライアントを提供
するというスタンスが多いように感じます。確かにタブキーによる項目移
動、入力補助とチェック、HTMLよりも少ない画面遷移、ドラッグ＆ドロッ
プといった操作はユーザーの利便性を向上させるには有効な手段です。
ですが、これらの動作は対象ブラウザや使用スクリプトの種類・バージョン
を限定すればある程度は実現できてしまいます。
リッチクライアントがブラウザと根本的に異なるのはユーザーインターフ
ェースよりはむしろ以下のようなポイントなのではないかと考えています。
1. ローカルリソースインタラクション
2. 高度なローカルコンピュテーション
1.は例えばリッチクライアント上のキャビネットブラウザのような画面に
おいて、サーバー上の共有フォルダ、インターネット越しのリモートフォル
ダ、自分のマシン内のローカルフォルダの全てを同じ形式で透過的に見せ
るといったものや、WEBメールの受信データの一部をオフライン状態でも
閲覧可能なようにローカルに格納しておく(「ローカルストレージ」)とい
った例が挙げられます。従来もプラグインの活用などでこうしたことはブ
ラウザベースでも可能でしたが、こうした機能をもっと標準的なAPIやオ
ブジェクトで手軽に実現できることが求められているように思います。
2.は従来のJavaScriptで記述されたユーザーインターフェース関連の処理
よりももっと高度なデータ操作に関する処理を指しています。例えばBIで
行われるような複数箇所に分散して格納された大量のデータから必要な情
報を選別するような処理をサーバー側で実行しようとすると多大な負荷が
かかります。またそうした処理を行うのが一部の経営層であるならば、そ
の処理をサーバー側に実装する必然性も薄くなります。むしろ、クライア
ント側でデータ収集と選別を行ってしまう(「ローカルアグリゲーション」
)方がリソースの有効活用やレスポンスタイムの向上という観点からも有利
な場合が少なくないでしょう。パーソナライゼーションを実現しようとす
る場合にも個々のユーザーごとに表示するコンテンツを選別する処理を
サーバー側で全て賄おうとすると大変です。ネットワーク回線が十分に太い
イントラ利用であり、かつクライアントマシンのスペックが十分であるならば
掲示板データやフォーラムデータを個々のユーザーの興味や関心に応じて
選別する処理はクライアント側で行ってしまう(「ローカルフィルタリング」)
というのも一つの有効な手段ではないかと思います。
リッチクライアントというと現時点ではFlashのようなプラグイン型の実現
手段の方がブラウザの延長線上で扱い易く、また見栄えも良いということで
目にとまりやすいのではないかと思います。ですが、JavaScriptに代わる
言語(ActionScriptなど)を習得する手間とそれによって実現できるソリュー
ションを天秤にかけた場合、上記の1や2のようなことは依然として困難なため
対象ブラウザバージョンを限定してJavaScriptで作り込むことと比較すると
絶対差別的なメリットを今ひとつ感じられないようにも思います。
個人的に今後期待しているのはWindows FormsアプリケーションやJavaの
Swing/SWTアプリケーションといった従来の専用クライアントアプリケーション
がブラウザ並みに容易に導入・管理できるようなソリューションです。これら
のアプリケーションであれば1や2は問題なく実現することができます。さらに
.NETであれば「ノータッチデプロイメント」の発展系としての「Click Once」
が次期Visual Studio .NET(Orchas)にで導入され、IIS経由でブラウザ画面
から容易にWindows Formsアプリケーションを導入することができます。
Microsoftは既に「スマートクライアント」としてWindows Formsアプリケーション
を活用したリッチクライアント実現を表明していますが、なぜか今ひとつ浸透
していないようです。一方のJavaにおいては既に「Java Web Start」という
Click Onceと同様の仕組みを標準として提供しています。
プラグインタイプのリッチクライアント実現手段でのシステム構築が一巡して
1や2のようなニーズが出てくれば「Click Once」や「Java Web Start」とい
った手段を用いて従来の専用アプリケーションをクライアントに活用するとい
うソリューションが注目を浴びるようになるのではないかと予想しています。
ただ、その場合には全てがこうした専用アプリケーションに移行するわけでは
なく、上記に挙げたようなBIやローカルへのデータ格納、ローカルでの高度な
処理といったものには専用クライアントが利用され、閲覧や参照が主体で簡易
な登録・編集処理で賄える場面では引き続きブラウザベースのクライアントが
利用されるといったように適材適所の活用がされるものと思われます。
