特集 スマート・クライアントの傾向と対策 日本ユニシス 猪股健太郎 2004/05/15
Page1 Page2 Page3 Page4

スマート・クライアントに何を求めるか

　「やっぱりWebでは駄目。これからはスマート・クライアントだよ」などというのは簡単です。しかし、あらゆるシステムをWebで作るのが正しくない（例えば、3Dモデリング・システムをHTMLだけで作るのは事実上無理でしょう）のと同じように、あらゆるシステムをスマート・クライアントで作ろうとする姿勢も正しくありません。

　スマート・クライアントという単語は、マイクロソフトのマーケティング用語であることが分かりました。そしてその実態は「マイクロソフト版リッチ・クライアント」です。最初に述べたように、リッチ・クライアントを実現する技術にはスマート・クライアント以外のものもあります。それを踏まえたうえで、実装技術としてスマート・クライアントを選択する理由は何ですか？

　当たり前のことなのですが、開発者はシステム使用者の立場で、要件に応じた技術を選択しなければなりません。システム使用者の望むものはいったい何ですか？ それはスマート・クライアント以外では実現できないのですか？ 何が必要なのかをきちんと判断しないで、何でもかんでもスマート・クライアントで実現しようとしたために、余計なコストがかかってしまった……なんてことが起こらないように、システムに対する要求を検討してみます。

■Webアプリケーションの操作性に不満がある

●その1：キーボードを活用してエントリ系業務を効率化したい

シナリオ： 　アプリケーションの利用者はいわゆる「端末オペレータ」である。ユーザー・インターフェイスはマウスよりキーボードを重視する。ファンクション・キー、［Tab］キー、［Enter］キー、カーソル・キーを効率よく使った入力が必要である。Webアプリケーションで実現する場合は、ブラウザの「戻る」や「リロード」といった機能は禁止したい。アニメーションであるとか、マウス・ジェスチャといったようなユーザー・インターフェイスは不要である。

　この例は、重要な要件としてエントリ系業務の効率化があり、そのためWebアプリケーションでは操作性に不満があるという場合です。しかし、要件を満たすためには、キーボード入力を強力にサポートするコントロール部品があれば十分です。そのように考えれば、ActiveXコントロールを活用してWebベースのシステムを構築するという選択肢もあります。

　例えば、リッチ・クライアントの代表例としてよく取り上げられるアクシスソフトのBiz/Browserは1つの解決策でしょう。この例においてスマート・クライアントを選ぶには、「基盤技術を.NET Frameworkで統一したいかどうか」および「コントロール部品は既成のものを利用するかどうか」を判断基準にするとよいでしょう。

キーボードを活用してエントリ系業務を効率化したい例

●その2：インターネット向けに表現力のあるインターフェイスを提供したい

シナリオ： 　アプリケーションの利用者はインターネット上の不特定多数である。利用者に商品イメージを正確に伝えるために、アニメーションやマウス・ジェスチャといったような表現力のあるユーザー・インターフェイスが必要である。

　この例は、重要な要件としていわゆる「リッチなユーザー・インターフェイス」があり、そのためHTMLでは表現力に不満がある場合です。このような場合では、Macromedia Flashを使う方が対象プラットフォームを広くすることができます。

　現在主流のクライアントOSであるWindows XPについていえば、初期状態ではスマート・クライアントを実行するのに必要な.NET Frameworkはインストールされていません。このため、不特定多数向けアプリケーションの実装技術としてスマート・クライアントを選ぶのは、現状ではお勧めしません。

インターネット向けに表現力のあるインターフェイスを提供したい例

　結局、Webアプリケーションの代替としてスマート・クライアントが有効なのは、上記の「その1」にも「その2」にも該当しない場合なのです。そのように考えると、アプリケーションの利用者が見えてきます。対象プラットフォームを限定できる環境にいて、高機能なユーザー・インターフェイスを有効活用できる利用者。マイクロソフトがいう「インフォメーション・ワーカー」（情報の収集・加工・共有を効率化し、労働生産性を高めるビジネス・パーソン）とは、そのような利用者です。すぐ思いつく例は、CADシステムやデータ分析です。とはいえ、インフォメーション・ワーカーの生産性向上につながるような、真にリッチなユーザー・インターフェイスを作るのは簡単ではありません。アプリケーションの直接の利用者、デザイナー、開発者の3者がよく協力し合うことが必要になるでしょう。

■Webアプリケーションの機能に不満がある

　Webアプリケーションに対する不満のうち、操作性以外の機能に不満がある場合を2つ挙げてみます。1つ目は、オフラインでの利用ができないこと、そして2つ目は、ローカルの資源を利用するのに制限があることです。

●その1：オフラインでも使いたい

オフラインとオンラインの連携

　これは、クライアントは主としてオフラインで利用されることが前提になっているけれども、ユーザーの操作に基づいてサーバと通信し、データを送受信するというタイプのクライアント・アプリケーションです。

　ビジネス・ロジックはサーバ側に置き、クライアント上にはプレゼンテーション・ロジックを置きます。プレゼンテーション・ロジックには、クライアントでデータを入力してサーバに送信するものと、サーバから取得したデータをクライアントに表示するものの2種類があると考えられます。サーバとの通信技術にはXML Webサービスを利用するのが、自由度が高く便利です。

擬似接続

　これは、クライアントは主としてオンラインで利用されることが前提になっているけれども、ネットワーク接続が不安定であるため、断続的にオフラインになる可能性がある場合に適しています。

　具体的には、PDAやタブレットPCといったモバイル・デバイスが無線LANや携帯電話などでネットワーク接続している状況を想定しています。そのようなモバイル・ネットワーク技術は、接続状況が周囲の状況によって左右されますから、常にオンラインであるとは限りません。サーバと通信しようとしたときにたまたまオフラインになっているということも考えられます。そのような状況でオンライン・アプリケーションを使うと、ネットワーク例外と再試行が多発することになってしまいます。これを防ぐために、オフラインでも擬似的に動作するように設計します。

オフラインでのアプリケーション利用例

●その2：ローカル・コンピュータの資源を使いたい

　スマート・クライアントは、ローカル・コンピュータの資源を利用したい場合にも適しています。ローカル・コンピュータの資源といってもいろいろあります。プリンタ、スキャナ、バーコード・リーダーといった周辺機器を利用したい場合もありますし、ハードディスクに格納されたファイルを読み書きしたい場合もあります。もっといえば、先の「オフラインでの利用」という要求自体、ローカル・コンピュータのコンピューティング能力やグラフィック能力という資源を利用していると見なすこともできます。

　いずれの場合であっても、ローカル・コンピュータの各種資源を利用するには、ローカル・コンピュータのコンピューティング能力を利用する、すなわちローカル・コンピュータ上で何らかのプログラムを動作させることが必須となります。であれば、サーバ・プログラムはJava（J2EE）だけれどもクライアント・プログラムはVC++でActiveXコンポーネントを作る、というように異なる技術を採用するよりも、サーバもクライアントも.NET Frameworkを使ってアプリケーションを作るほうが開発の生産性が高くなるでしょうし、Webブラウザ上で動作するクライアント・プログラムよりは、完全なWindowsアプリケーションの方がプログラムの自由度も高くなります。したがって、Webアプリケーションを拡張する技術よりもスマート・クライアントの方が有利だといえます。

　ただし、ネットワーク上にあるスマート・クライアントを実行する場合は、WebにおけるJavaScriptやActiveXコンポーネントと同様に、セキュリティによる制限が問題になります。そのような場合では.NET Frameworkの詳細なセキュリティ制御機能を利用します。

ローカル・コンピュータの各種資源を利用する

　

INDEX
	［特集］スマート・クライアントの傾向と対策
	1．スマート・クライアントの位置付け
	2．スマート・クライアントに何を求めるか
	3．どうやって作るか − 導入・運用コストの削減ために
	4．どうやって作るか − 実装コストの削減のために

　

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）