システム管理者のための.NET入門 第2回 ビジネス・アプリケーションの現在と.NET 1．C/S型システムの特長と問題点 デジタルアドバンテージ　小川 誉久 2006/12/28

GUIアプリケーションを容易に開発できるC/S型システム

　前回ご紹介したとおり、各クライアントにアプリケーションをインストールし、これらからデータベース・サーバ（DBサーバ）に直接アクセスするというC/S型システムは、特に小規模なイントラネット・システムにおいて、現在でもなお業務アプリケーションの主流の1つである。このようなC/S型システムが普及した背景には、Visual BasicやDelphi（ボーランド）など、ボタンやメニューなどの操作部品をマウスでウィンドウに配置しながら、それらが操作された際の処理を簡単に開発できるRADツール（Rapid Application Development）が普及したこと、SQL Serverなど比較的安価なデータベース・システムが利用できるようになったことなどがある。

　業務アプリケーションのGUI設計で重要な点は、必要な機能をできるだけ使いやすくして、高い業務生産性を達成するとともに、操作ミスなどをできるだけ発生させないようにすることだ。具体的にこの過程では、何をウィンドウにするか、情報をどのような配置と順番で表示するのがよいか、メニューやボタン、リスト・ボックスなどの操作部品をどのように配置するか、それらの部品が操作されたときにどう動くのかなどを決定していく。しかしこうしたGUIの使い勝手は、実際に作って動かしてみて、初めて工夫の余地や問題点などに気付くことが少なくない。無計画にトライ＆エラーを繰り返すのは効率のよい開発方法とはいえないが、このような理由から、GUI設計はある程度試行錯誤が避けられない。RADツールでは、マウス操作などのGUIを利用して、実行時の画面を確認しながらインターフェイス・デザインを簡単に行えるという利点がある。

　例えば以下は、筆者が所属するデジタルアドバンテージが開発したC/S型システムの例である。これは＠ITで別途公開しているコンピュータ用語辞典（Insider's Computer Dictionary）の編集支援用として開発したものだ。用語辞典の解説文や関連用語などの情報をSQL Serverに保存しておき、VBで開発したクライアント・アプリケーションからアクセスしている。

VBによるC/S型システムの例

デジタルアドバンンテージ社が開発した社内用ツールの1つ。コンピュータ用語解説用データ編集の支援を行う。実際に実用で使いながら、機能やインターフェイスを何度となく改良し、現在はこの形式に落ち着いている。

　現在はこの形式で落ち着いているが、開発当初から現在までに、必要に応じて、機能追加やインターフェイス変更など、幾度となく改良を繰り返してきた。「いきあたりばったりの開発だ」といわれれば反論できない部分もあるが、新たに開発する業務アプリケーションでは、程度の差こそあれ、微妙な調整では試行錯誤が必要になるだろう。

　ユーザーから見たC/S型システムの構成はシンプルである。上記のコンピュータ用語辞典編集ツールもそうだが、クライアント・アプリケーションをコンピュータにインストールすれば、すぐに用語辞典を編集できるようになる。シンプルで分かりやすく、手軽なのもC/S型システムの長所である。

C/S型システムの問題点

　小規模なイントラネット・システムであれば手軽で便利なC/S型システムだが、いくつか重大な問題がある。1つは、各クライアントがDBサーバにアクセスする構成であるため、クライアント数が増えてくると、同時にアクセスするクライアント数分の接続をデータベース側で管理しなければならなくなることだ。DBシステムは複数の同時アクセスを管理する能力を備えているが、接続ごとにサーバ側リソースを消費するため、あまりに数が増えてくると、サーバのリソース不足が全体のボトルネックになりやすい。サーバ側のリソース増強には限界があるので、その限界点がサポートできるクライアント数の上限ということになる。処理にもよるので一概にはいえないが、同時アクセスが数十〜100台規模になると、多くのシステムがこの問題に直面することになるだろう。つまりC/S型システムは、拡張性（スケーラビリティ）にあまり余裕がないということだ。

　前回も簡単に触れたとおり、C/S型システムのもう1つの問題点は、クライアント管理のTCO（総所有コスト）が増大しやすいことである。典型的な問題は、クライアント・アプリケーションのバージョンアップである。クライアント・アプリケーションが更新されたときには、すべてのクライアントでバージョンアップ（更新インストール）を実施しないと、システムが正しく機能しなかったり、不整合を起こしたりしてしまう。

C/S型システムにおけるクライアント・アプリケーションの更新

クライアント・アプリケーションが更新された場合には、すべてのクライアントでの更新作業を徹底しないと、システムは正しく機能しなくなる。

　アプリケーションをクライアントにインストールしている場合には、各クライアントのユーザーに依頼するなどして、新しいアプリケーションを更新インストールする必要がある。ごく少数のクライアントが同一個所に集中しているならよいが、多数のクライアントがある場合や、クライアントのロケーションが広範にわたっている場合などは、バージョン統一作業に多大な労力が必要になる。

　これを回避する方法として、イントラネット内のファイル・サーバや、Webサーバにクライアント・アプリケーションを置き、クライアントからは毎回これを起動するという方法がある。共有フォルダに配置された実行ファイル（.EXEファイル）のショートカットをクライアントに作成し、ここからアプリケーションを起動したり、Webサーバ上の公開フォルダにアプリケーションを配置し、そのURLをブラウザで指定／イントラネット・ページに設定したURLのリンクをクリックして実行したりする方法だ。

共有フォルダからのクライアント・アプリケーションの実行

アプリケーションをクライアント・コンピュータにインストールするのではなく、毎回サーバ上の実行ファイルを実行するようにする。この方式なら、サーバ上の実行ファイルを更新することで、クライアント・アプリケーションのバージョンアップが可能になる。

　この方法なら、毎回サーバ上の実行ファイルがクライアントにロードされ実行されるので、アプリケーションの更新はサーバ側だけで実施できる。すでに起動されているアプリケーションの更新問題（そのままでは更新されない）や、遅いネットワーク回線を使用しているクライアントでの実行など、いくつかクリアすべき問題はあるが、工夫すればアプリケーションの配布コストを大幅に圧縮することができる。

　ただしこの方法は、更新の徹底や完全性を運用の裁量に多くを委ねているという問題がある（例えば、エンドユーザーがアプリケーションをローカルにコピーして実行してしまうといったことを禁止できない）。この点最新の.NETアプリケーション（Visual Studio 2005で開発された.NET Framework 2.0ベースのアプリケーション）なら、ClickOnceと呼ばれるアプリケーション実行／配布の仕組みを利用することで、クライアント・アプリケーションの展開や更新をほぼ自動化できるようになっている。ClickOnceについては、次回に詳しく解説する予定だ。

ダウンロードしたアプリケーションとセキュリティ問題

　サーバからダウンロードしたアプリケーションをクライアントで実行する際には、セキュリティ面についても考慮しなければならない。万が一にもウイルスなどを実行してしまうと、それを実行したコンピュータだけでなく、システム全体が破壊や改ざんなどの危険にさらされてしまうからだ。

　現在のWindows OSは、セキュリティ管理機能を持っているが、管理の単位はユーザーである。Windows環境で実行されるアプリケーションは、それを起動したユーザーの権限に従ってセキュリティ制御を受ける。Windowsのセキュリティ・メカニズムについては、関連記事が詳しいので参照されたい。

Windowsセキュリティ・メカニズム入門

　従ってサーバから起動されたアプリケーションも、それを起動したユーザーの権限でハードディスクを読み書きしたり、共有フォルダを読み書きしたりできる。安全なイントラネット内のサーバなら、アプリケーションが改ざんされている可能性などは低いだろうが、出所のはっきりしないインターネット・サーバからダウンロードしたアプリケーションは、ウイルスなど「悪意のあるプログラム」である可能性もある。この場合、プログラムを実行してしまうと、クライアント・コンピュータはもちろん、ネットワーク上の共有資源についても、実行ユーザーの権限で破壊や改ざんが実行されてしまう危険がある。

セキュリティ制限のない環境でのダウンロード・アプリケーションの実行

特別なセキュリティ制限がない場合、サーバからダウンロードされたアプリケーションは、それをダウンロード／実行したユーザーの権限で各種ローカル／ネットワーク資源にアクセス可能。万一実行したプログラムがウイルスなどだった場合には、アクセス可能なコンピュータ資源が破壊されたり、改ざんざれたりする危険がある。

　特に危険性が高いのは、インターネット上にあるサーバからプログラムをダウンロードして実行するケースだ。このため、Webサーバからのダウンロード／実行を前提とするJavaアプレットやActiveXコントロールのブラウザでの実行では、サンドボックス・モデルと呼ばれるセキュリティ対策が適用される。簡単にいえば、ネットワークからダウンロードしたJavaアプレットやActiveXコントロールなどは通常のプログラムと区別し、サンドボックス（砂場）と呼ばれる制限された環境でのみ実行するという方式だ。具体的には、サンドボックス内のアプリケーションは、デフォルト設定ではクライアント・コンピュータのハードディスクを読み書きしたりできない。

サンドボックス・モデル

JavaアプレットやActiveXコントロールなどをブラウザで実行すると、利用可能な機能が強く制限される「サンドボックス」が適用される。ローカル・ディスクへの読み書きなどはできない。

　このサンドボックス・モデルにより安全性は高まるが、プログラムで利用可能な機能は強く制限されるため、利便性は損なわれる。出所不明のインターネット・サーバからダウンロードしたプログラムはこれで仕方ないとして、安全なイントラネットからダウンロードしたプログラムに対してもサンドボックスを適用するのは不便だ。

　詳細は次回に述べるが、こうした問題に対し.NETでは、CAS（Code Access Security）と呼ばれる機能により、安全性と利便性のバランスを柔軟にとれるようにしている。CASを利用すれば、ダウンロード元の情報や、プログラムに付けられた署名の情報などを使って、セキュリティ制限を柔軟に切り替えられるようになっている。

CASの例

.NETのCASを使えば、プログラムのダウロード元や添付されたデジタル署名の内容などによって、適用されるセキュリティ制限を細かく調整できる。

　このCASをうまく使えば、出所不明のWebサーバからダウンロードしたプログラムには従来のサンドボックスを適用しながら、安全なイントラネットからダウンロードしたアプリケーションに対しては、より緩いセキュリティ制限を適用し、ローカル・ディスクへのアクセスを許容するなどが可能になる。

INDEX
	システム管理者のための.NET入門
	第2回 ビジネス・アプリケーションの現在と.NET
	1．C/S型システムの特長と問題点
	2．Web型システムの特長と問題点
	3．ビジネス・アプリケーションの論理3階層

　

「システム管理者のための.NET入門」

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