使いやすいユーザーインターフェイス

　ウェブブラウザは万能で最良の道具なのだろうか? 否である。その証拠に、ほとんどの人はウェブメールを使用せずにメール専用プログラムを使用している。

　ウェブアプリケーション（クライアントにウェブブラウザを使用するアプリケーション）は、C／S（クライアント／サーバー）システムの課題であったTCO（システム総保有コスト）の削減を実現した。管理者にとっては素晴らしいことである。

　しかし、ウェブアプリケーションはあまりに使い勝手が悪い。GUI（グラフィカルユーザーインターフェイス）が貧弱で動作が遅いのだ。

　ウェブブラウザで帳票を入力するより、マイクロソフトのエクセルで入力した方が圧倒的に楽である。利用者にとってみれば、ウェブアプリケーション化とは使い勝手が悪化することなのである。

　利用者の不満を解消するにはどうすれば良いか?

　クライアントをインテリジェントにすれば良い。われわれは過去にそのようなインテリジェントな環境を使っていた。そう、C／Sシステムのリッチ・クライアントである。

　しかし、ただリッチ・クライアントを復活させたのでは、同じことの繰り返しになってしまう。少し工夫をしよう。「XMLウェブサービス」を呼び出す「リッチ・クライアント」を作成するのだ。

　この形のリッチ・クライアントを一般に「スマート・クライアント」と呼ぶ。

　スマート・クライアントを採用すれば、C／Sシステムとウェブアプリケーション双方の課題を解決できる。リッチ・クライアントなのだから使い勝手の良いユーザー・インタフェイスを提供可能である。

　そして、アプリケーションのロジックをXMLウェブサービスに集約するのだから、C／Sシステムに比べてTCOが削減される。クライアントの自動配布を行えば、ウェブアプリケーションと同じレベルまでTCOを削減できる。

　と、ここまで読んだ時、疑問に思うことが2つあるだろう。

　（1）分散オブジェクトを使用した三層アプリケーションとどこが違うのか？　（2）Java アプレットは現在ほとんど使われていないが、スマート・クライアントも同じ運命を辿るのではないか？

　（1）分散オブジェクトとは使用するプロトコルがXMLウェブサービスである点が異なる。XMLウェブサービスはどのプラットフォームでも使用できる汎用的なプロトコルなので、クライアントやサーバーを選ばない。分散オブジェクトは環境の制約が強すぎた点に問題があったのである。

　（2）今度は成功する。Java アプレットが衰退した理由は、当時のJavaはバック・エンドとの連携が貧弱で、実行速度が遅かったことにある。スマート・クライアントには、XMLウェブサービスがある。そして、.NET フレームワークのウィンドウズ・フォームズは実行効率も良いのだ。まっCPUも速くなりましたしね。