asp によるスケジュール管理アプリケーションの開...
TRANSCRIPT
筒井ゼミ 2002年度卒業論文
ASPによるスケジュール管理アプリケーションの開発
平成 14年 11月 27日
学籍番号：5199162
氏名：畠山 忠修
1
要旨 スケジュール管理を行う為のアプリケーションをサーバーサイドで動作する ASPスクリプトを用いて開発し、Web に公開する事で、インターネットを通じてどこからでもスケジュール管理できるアプリケーションを開発しようというものである。
目次 1. はじめに 2. ASPのスケジューリングWebアプリケーション －2.1 スケジュール管理のWebアプリケーションを作成する所以 －2.2 使用する言語 3. ASPとは何か －3.1 なぜ ASPか －3.2 ASPとは 4. 動作環境の構築 －4.1 Webに公開する為のサーバ －4.2 Webサーバの構築 －4.3 サーバセキュリティ対策 5. データの保存 －5.1 様々なデータ格納環境 －5.2 ASPからデータベースへの接続 6. アプリケーションの仕様の想定 －6.1 ASPの構成ファイルの想定 －6.2 Accessでデータベースファイルの作成 7. 機能の拡張 －7.1 機能拡張の概要 －7.2 拡張機能の追加工程 －7.3 リレーションシップの利用 8. 複数ページにまたがるユーザの追跡 －8.1 ユーザの特定 －8.2ページ間のデータ共有の必要性 －8.3 Sessionオブジェクト利用上の注意点 9. 今後の拡張性 10. むすび 11. 参考文献
2
1. はじめに
本論文は ASP を用いてスケジュール管理の Web アプリケーションを開発した所以、経過、そしてその結果について述べたものである。 昨今インターネットが急激に普及しており、もはや外出中でもモバイルを通じてインタ
ーネットに自由にアクセス出来るようになった。そこで、Web 上でスケジュール管理できるアプリケーションがあれば、場所を問わずスケジュール管理が可能になるという利点か
ら、スケジュール管理のWebアプリケーションを開発する事としたのである。 その開発に ASP スクリプトを起用したのであるが、その大きな理由として ASP はクライアントの環境に依存しないという特徴がある為である。今回の開発に当たってアプリケ
ーション自体の基本的な構造は「今日から使える ASP3.0サンプル集」[1]を参考とし、サー
バ構築から始まり、「今日から使える ASP3.0 サンプル集」[1]のサンプルをベースとして、
五つの追加機能を構築した。その機能は、第一に、予定入力項目の追加機能。第二に、カ
レンダー自体に現在の予定を表示する機能。第三に、１ヶ月の予定一覧表示機能。第四に、
定期予定の登録機能。そして第五に、今回開発において最も主力を注いだユーザ管理機能
を構築した。 以下、本論文では、2 章にて、スケジュール管理の Web アプリケーションを作成する所以と、開発言語についての説明を行い、３章にて ASP の説明と、なぜ ASP を利用するかについての説明を行う。4、5、6章では、開発に当たって必要とされる環境の想定と構築の経緯を述べる。7章では基本機能の実際の開発の経緯について述べる。8章では更なる追加機能の想定と、それを元に行った開発について述べる。
2. スケジュール管理のWebアプリケーション
2.1 スケジュール管理のWebアプリケーションを作成する所以 就職活動を通じ、次々に説明会や選考、面接の予約が埋まり、毎日の様に企業訪問を行
うという多忙な毎日を経験し、その多忙なスケジュールを管理するのに手帳は必要不可欠
であった。それに、来年から社会人になるに当たって、こうしたスケジュール管理は必要
不可欠となると思われる。 しかし、手帳だけでは不安である。もしある拍子に手帳を持参し忘れる。或いは紛失す
るということになると、現在入っている予定がわからなくなる。そしてその為にすでに予
定が入っているところに予定を追加し、予定が重複するなんていうことにもなりかねない。 そこで、手帳を持ち合わせていなくともWebサイトに繋げるパソコンさえあれば、自分の予定をたちどころに知ることが出来るWebアプリケーションを開発しようと考えた。これが本研究の直接の動機となった。
3
2.2 使用する言語 アプリケーションを構成するには、コンピュータにどういった処理を行わせるかを記述
するプログラム言語、或いはスクリプト言語を利用する必要がある。言語には様々な種類
があり、用途によって使い分けが必要である。今回の場合はWEBアプリケーションである為、インターネットを閲覧するためのソフトであるブラウザから利用可能な言語を選定す
る必要がある。その代表的なものは、ActiveXや Java、JavaScript、VBScript、Perl、CGI、ASPと様々である。 それらの言語は大きく2種類に分類される。1つはActiveXやJava、JavaScript、VBScript等の、クライアントサイド（Webを閲覧する端末側）で処理を行う言語と、もう 1つは Perl、CGI、ASP等のサーバサイド（Webにファイルを公開する側）で処理を行う言語の 2種類である。 今回はこのうちサーバーサイドのスクリプト言語を利用する事とする。その理由として、
クライアントサイドの言語は、その言語を処理する環境をクライアント側が実装する必要
があり、クライアント資源へ大きく依存している。また、情報を得ようとすると、クライ
アント側が要求するのは情報だけなのに、その情報を得るための手段（プログラム言語）
も一緒に得る必要があり、クライアント側は大量のデータを自分のコンピュータに持って
来なければならず、当然ながら、ネットワークにかかる負荷は増大するばかりである。ま
た、そうすることで、ユーザー認証などのクライアントには公開したくないプログラムソ
ースもクライアント側に公開することにもなる。 また、実際の処理を行うのはクライアント側である為、クライアント側のマシンスペッ
クにより処理速度が変わり、また、使用するブラウザごとに表示結果が異なるという、ク
ライアントの利用環境に影響される問題がある。図１クライアントサイドのスクリプトにお
ける、Webサーバとクライアントの関係図を以下図 1に示す。 こうしたことを解決するには、処理をサーバ側に移せばよいのである。こうすることで
情報を得るために必要な処理はサーバーサイドで全て処理し、その結果だけをクライアン
ト側は得ることが可能である。すなわち、サーバーサイドのスクリプト言語である Perl、CGI、ASP等を利用すればこの問題は解決できるのである。その中でも、今回のWebアプリケーションを開発するに当たっては ASPを利用する事とする。
4
HTML
ActiveX JAVA スクリプト
異なったWebページ
COM JAVA仮想マシン スクリプトエンジン
Webサーバ
プログラムの流出ネットワークへの負荷
クライアント環境に依存
Webクライアント
図 1クライアントサイドスクリプトにおける問題点[1]
3. ASPとは何か
3.1 ASPとは ASPは、サーバ上でWebアプリケーションが必要とする処理を行い、その結果（HTML）のみをクライアントに返す「技術」である。「技術」である為、ASP自体が特定の言語を指すわけではない。あらかじめ用意された組みこみオブジェクトやコンポーネントに対し、
ASPに対応したスクリプト（標準で VBScriptや JScriptが使用可能）が処理をおこなうサーバサイドスクリプティング環境、それが ASPである。
Webクライアントの要求に対する、Webサーバ側での ASPの処理と、その結果が戻ってくるまでの流れを以下図 2に示す。図２
5
②要求されたページを呼び出す Webサーバ ASPファイル
メソッド・プロパティASPスクリプトエンジン コンポーネント
結果・返り値
処理結果 ③コンポーネントが呼び出された場合は、コンポーネントを実行
①ページを要求する ④処理結果のみをクライアントに返す
無駄なデータが流れない
コンポーネントの再利用が可能
表示
クライアント環境に依存しない
Webクライアント
図 2 ASP の動作のしくみ[1] 3.2 なぜ ASPか サーバサイドのスクリプト言語にも幾つか種類があるが、その中でもなぜ ASPを利用するのかをここで述べる。 まず、データベースとの連携が容易であることが挙げらる。CGI でもデータベースは扱うことが可能であるが、いわゆる Accessのような馴染みのデータベースとの連携は出来ない為、初心者には敷居の高いものであった。 また、ASPは「.asp」のファイルの中の表示させたい HTMLと実際の処理をおこなうロジックの部分が一体化している。その為、スクリプトファイル（「.cgi」「.pl」など）を別管理しなければならない CGIと異なり、サイトの管理も容易に行える。 次に、サーバ資源を有効活用できるところが挙げられる。CGIの場合は、同じ CGIが必要とされた時には、要求された数だけスクリプトを起動さる必要がある。その為、大規模
なアプリケーションになればなるほど、サーバリソースの消費は無視できなくなる。しか
し、ASPの場合、各コンポーネントが DLL（Dynamic Link Library）というひとつの塊となっており、いくつの処理が要求されても、それが同じ処理の要求ならば、ASP はただひとつのコンポーネントを呼び出すだけなのである。図３CGI と ASP のそれぞれのサーバリソースの消費形態を以下、図 3で述べる 更に、CGI 等では複数のページにまたがったページでは、データを受け渡すために様々な裏処理を独自に構築しなければならなかった。しかし、ASP ではセッションという概念で各ユーザーを個別に管理をする事が可能である為、そのような手間はなくなった。図４ユ
6
ーザを１セッションに関連付けて管理する仕組みを以下図 4に示す。 ユーザを1セッションに関連付けて管理が可能になったという事は、これまで単純なWebコンテンツ（ドキュメント）がWebアプリケーションへと進化しうる可能性を示唆している。 ASPにはこういったメリットを備えている為、今回のWebアプリケーションの開発に利用しようと考えたのである。
CGIスクリプト要求の数だけプログラムが起動してしまう CGI
CGIスクリプト
CGIスクリプトＷｅｂクライアント
Webサーバ
Ｗｅｂクライアント ASPスクリプト ASPコンポーネント
同じ処理は同じコンポーネントが一人で片付けてくれる
Webサーバ
図 3 ASP コンポーネントによるサーバリソースの共有[1]
7
表示結果Ａ
ＷｅｂページＡ・Ｂ・Ｃを要求
表示結果Ａ
1セッション
CGI ASP
表示結果Ａ
表示結果Ａ
表示結果Ａ
表示結果Ａ
ＷｅｂページＡ・Ｂ・Ｃを要求
Webサーバ Webサーバ
ページCページA ページB ページC ページA ページB
お互いに関係しない別々の要求
同じクライアントからの要求は、1セッションとして関連づけて処理
WebクライアントWebクライアント図 4セッションによる管理[1]
4. 動作環境の構築
Webに公開する為のサーバ アプリケーションをインターネットで利用できるようにするには、Web サーバにファイルを保存し、Webにファイルを公開する設定を行う必要がある。これに関しては HTML等で作ったホームページも同じ事である。Web にファイルを常時公開するサービスを、ISP（インターネットサービスプロバイダ）が行っている為、ISPのサービスを利用する事でファイルをWebに公開することが出来る。 しかし、今回注意する点は、ASP を利用できる環境を備えているかどうかという点である。ASPはサーバーサイドで処理するスクリプト言語である為、サーバが ASPを処理する環境を実装していなければ ASPは処理されず、アプリケーションは実行されない。その環境というのは、WWWサーバが下記の中のどれかであることが必要である。 Internet Information Server Version 2.0（IIS 2.0） 以上
8
Peer Web Services Version 2.0（PWS2.0） 以上 パーソナル Web サーバ Version 1.0 以上
しかし、現状ではこれらの環境を実装している ISPはごくわずかで、大抵は、UNIX 上で動く、NCSA、CERN、apatch などの WWW サーバが使われている。また、ASP を作った際の実行権限の付与や、その他の管理の面から行って、ISP で提供している個人ホームページ開設サービス上で、ASP の機能を使用するのはかなり困難であろう。こういった事から、私は今回自分の PC で Webサーバを構築・設定し、ASPスクリプトを Web に公開しようと考えた。
4.2 Webサーバの構築 まず、Web にファイルを公開するに当たって、最も重要になるのが IP アドレスである。
一般的なプロバイダで接続の場合、プロバイダから振られる IPアドレスは固定になっておらず、繋ぎかえるたびに IPアドレスは変わってしまう。IPアドレスはデータの行き先、住所である為、接続のたびに変化していては他の人にホームページを公開することが困難に
なる。また、その番地も http://221.153.211.237のように数字になってしまうので、覚えてもらうのが大変である。そこで DDNS サービス(ダイナミックドメインネームサーバ)を使用する。DDNSを利用すると、ダイアルアップや ADSLなど、IPアドレスが固定されていないインターネット接続環境でもサーバの運営が可能になる。簡単に言うと転送サービス
のようなものである。具体的には、自分で指定したドメイン(http://www.○○○.com)にアクセスがあるとそれを先ほどの IP アドレスに転送するといった物である。図５DDNS サービスを行っている所は数多くある為、その中から条件に合ったものを選んで登録する。今回は
無料のサービスを受けることの出来る dyndns.org（http://www.dyndns.org/）を選択し、登録した。ここは英語のサイトだが、他にも無料の DDNSサービスを行っているサイトや、日本語のサイトも数多く存在する。それぞれサービス内容が微妙に異なる為、自分の要望
に合ったサイトを選べば良いであろう。[4]又、単に登録するだけでは、IP アドレスが変わったとたんに登録したドメイン名へ接続しても変わる前の IPアドレスへ繋がるので、Webサーバにたどり着くことが出来ない。そこで、各 DDNSサービスを行っている所から、現在 Web サーバに割り振られている IP アドレスを指定した間隔で自動的更新を行ってくれるソフトが提供されているので、それをインストールして設定をすれば、IP アドレスが変わっても、自動更新ソフトに設定した間隔以内に利用している DDNS サービスへ IP アドレスの更新をしてくれるので、引き続き登録したドメイン名を使用可能である。DDNS サービスの概要を以下図 5にて示す。
PCをWebサーバにする設定だが、本研究では OSはWindowsXPを使用し、Webサーバソフトは、上記にも記している、Internet Information Server Version 5.1（IIS 5.1）を使用する。IIS5.1はWindowsXPの CD-ROMに入っている為、それをインストールする。この際不要なコンポーネントは追加せず、IISを動かすために必要なオプションだけを選択
9
する。それは、「WWW サーバー」「インターネット インフォメーション サービス ス
ナップイン」「共通コンポーネント」の三つになる。インストールが完了しましたら後は IISを起動し、既定のWebサイトに仮想ディレクトリを作成し（既定のWebサイトを右クリック）、エイリアス（仮想ディレクトリの名前）、公開したいディレクトリへのパス、アクセ
ス許可の設定を仮想ディレクトリの作成ウィザード画面に従って行う。ASP ファイルの実行権を有効にする場合は「アプリケーションの設定」のアクセス権で「スクリプト」にチ
ェックを入れる。この設定は「実行」よりも、扱うアプリケーションが制限される。なお
「ディレクトリ セキュリティ」タブからは、OS (Windows XP) のユーザ認証機能と連動して、フォルダのアクセス権をユーザごとに設定することも可能である。これの設定が終
われば仮想ディレクトリが作成される。次に追加された仮想ディレクトリを右クリックし、
プロパティを開いて「ドキュメント」のタブの既定の「ドキュメントを有効にする」に公
開したい Web サイトのトップに当たるファイル名（拡張子を含む）を追加する。（今回はindex.asp）次に、使用する IP アドレスの設定だが、IIS の既定の Web サイトを右クリックし、プロパティを開いて IPアドレスのドロップダウンから選べるようになっている。本研究の場合、ここで必ず未使用の IPアドレスの全てを選択しておく必要がある。既定の設定値からそうなっているが、あえて念を押すのは、本研究では、非固定の IPアドレスである為、プロバイダから割り振られる IPアドレスは一定期間で変化する。だからここで今割り振られている IPアドレスを設定しても、IPアドレスが変わったとたんにWebサーバにアクセスできなくなる為である。どちらにしても IP アドレスが変わってから IP アドレス自動更新ソフトが次に更新を行うまでは登録したドメイン名は有効では無いが、ここの設
定で使用する IP アドレスを 1 つに絞ってしまうと、自動更新しても Web サービスは止まったままになるので注意が必要である。ここまで設定が終われば、IIS の既定の Web サイトを起動し、ブラウザから登録したドメイン名の URL へジャンプすれば、設定で Web に公開しているファイルをブラウザ上で開く事が可能である。これでWebサーバの構築は一通り完了である。
10
DDNSサービス
221.153.211.237
www.○○○.org （変わらない） DNSサービスを利用
しているサーバ 221.153.211.237で登録（変われば更新）
クライアント 121.183.121.215（毎回変わる）
DNSサービスを利用していないサーバ
図 5 DDNS サービス
4.3 サーバセキュリティ対策 Webサーバを構築し、Webにファイルを公開するということは、Webを利用する全ての人、すなわち全世界の人々に自分のファイルを見る権利を与えることになる。残念ながら
世界中の人が善良な人ではない為、こちらの公開しているファイルを改ざんされる恐れも
十分にある。これでは安心してWebにアプリケーションを公開する事が出来ない。その為、Web サーバを構築する上で、セキュリティ対策は必須である。本研究でもそれは例外ではない。 Web サーバのセキュリティを高める方法は、ルータで Web に公開する Web サーバのポートを設定する方法や、NTFSや IISのファイルアクセス権を設定する方法などがあるが、ルータを所持していない為、本研究では WindowsXP のファイヤーウォール機能で代用する事とする。 NTFS は、WindowsNT 等のネットワーク OS のファイルのフォーマット形式なので、Windows９８や Mｅでは利用不可能である。また、ネットワーク OS であっても、Fat 形式でフォーマットされているハードディスク上でも同じく利用不可能である。本研究で使
用したマシンは Fat形式であったため、convert c: /fs:ntfsのコマンドを利用して NTFS形式のフォーマットに変換し、ファイルアクセス権の設定を可能にした。NTFS によるアクセス権の設定は、設定を行いたいファイルが格納されているディレクトリを右クリックし、
プロパティのセキュリティのタブから行う。本研究ではWebに公開するディレクトリにあるファイルに対して設定を行うので、4.2で作成した仮想ディレクトリのルートディレクト
11
リに対して行う。まずは、使用するマシンの最高利用権限者の Adinistrators と、Systemの両者にフルコントロールを設定し、もしそれ以外のアカウントが存在する場合は、すべ
て削除する。そして、インターネットユーザのアカウント(IUSR_コンピュータ名)を追加する。これを追加しない限りはインターネットからこの仮想ディレクトリにアクセスするこ
とは不可能である。そして、アクセス権は読み取りのみを許可とし、設定を有効にする。
アクセス権で与えられている以外の操作を行った場合はエラー表示となるので、仮に公開
しているファイルを改ざんしようとしてもエラーが帰ってくることになる。ここで設定し
たアクセス権は設定を行ったディレクトリの階層下にあるサブディレクトリ又はファイル
に全て継承されるので、これで NTFS によるファイルアクセス権は完了である。ここで注意が必要なのは、今回 Access のデータベースを利用するが、この Access のファイルのアクセス権だけは書き込みのアクセス権を与えないとテーブルにアクセス出来ず、エラーと
なるので、書き込み権限を与える必要がある事である。この時、Access のファイルを実行時に生成されるレコードロック情報のアクセス権にも書き込み権限を与える必要があるの
で、このデータベースファイルの格納されているディレクトリ自体に書き込み権限を与え
るようにする事が必要である。 次に IISのディレクトリのアクセス権を設定する。アクセス権の種類として、匿名認証、基本認証、ダイジェスト認証の 3 つが存在する。匿名認証は不特定多数のユーザに仮想ディレクトリへのアクセス権限を与えるというものである。不特定多数のアクセスを望まな
い場合は，｢匿名アクセス｣のチェックを外せば良い。本研究では、Web にアクセスできる環境であれば場所を問わず利用できるアプリケーションを構築することが目的なので、必
ずチェックを入れる必要がある。後者 2 つの認証は、ユーザ名とパスワードを用いた認証方法であるが、今回は使用しないのでチェックを外します。なお、IISのアクセス権の方がNTFS のアクセス権よりも優先順位が高いということも頭に入れておく必要がある。しかし、どちらにせよ、一方でアクセスの明示的な拒否をしていればアクセス出来ない事とな
る為、アクセス権を与え忘れることの無いよう注意が必要である。なお、余計なアクセス
権を与えないことも念頭に入れておく必要がある。インターネットを閲覧するのに、ファ
イルへの書き込みは不要である。従って、間違えても書き込みの権限をインターネットユ
ーザアカウントに与えないように設定しなければ、公開しているファイルを改ざんされる
恐れがある為、厳重な注意が必要である。ただし、Access のデータベースファイル等の、読み書きが必要なファイルはその限りではない。しかし、幾ら書き込みが必要なファイル
であっても、やはり書き込みの権限を与えると改ざんされる危険性は発生する。そこで、
こうした書き込みの権限が必要であるファイルを、仮想ディレクトリの階層化に置かない
事でこの危険性を回避できる。インターネットユーザは仮想ディレクトリで設定したディ
レクトリがルートディレクトリとなり、設定された仮想ディレクトリより上位のディレク
トリは一切参照できない為である。これでアクセス権の設定は完了である。 次に、WindowsXP のファイアウォール機能を利用して、公開する Web サービスのポー
12
トを制御する設定を行う。Web にサービスを展開する種類として、ファイルを公開すること意外にも、ファイル転送や、メール受信等様々存在し、それぞれ独立したサービスとし
てそのサービスの入り口（ポート）が分かれている。これは勿論セキュリティを高める為
であり、既定値では全てのポートが閉じられている状態にある。今回は Web サーーバ（HTTP）のサービスを提供する為、このポートを空ける必要がある。無論、提供しないサービスはポートを空ける必要がない上、それでも空けていると、無駄に進入口を広げる事
となるので、注意が必要である。 以上の設定でWebにファイルを公開する準備は完了であるが、まだセキュリティ面では不十分である。現在の設定では入り口は狭くしたものの、そこにピンポイントで侵入して
くるセキュリティ・ホールを突く攻撃は防げないからである。そこで、ISAPI フィルタを導入する事とする。これは HTTP のリクエストの内容を解析し、悪意のある長いリクエストや特異な動作を要求するリクエスト、代替文字セットを使用してエンコードされたリク
エストを制御して、それらのアクセスを拒否してくれるものである。図 6ファイアウォール
と ISAPIフィルタによる防御イメージを以下図 6にて示す。本研究では参考文献「セキュリティ完全対策ｐ134」[3]に紹介されている、2つの ISAPIフィルタを起用した。１つはマイクロソフトが公開している URLScan。もう１つは guard3.dllである。 以上の設定を施せば、IISを利用したセキュアなWebサイトを公開できる。
正常なアクセス
セキュリティ・ホール攻撃
Webサーバ
不正なパケット
ISAPIフィルタ ファイアウォール
図 6ファイアウォールと ISAPI フィルタによる防御
5. データの保存
5.1 様々なデータ格納環境 今回スケジュール管理のWebアプリケーションを作成する訳だが、当然ユーザがスケジュールのデータを入力するものである為、データを保存する必要がある。また、ユーザが
13
要求した日にちのスケジュールのデータを引き出して出力するという、データの抽出が必
要である。これの仕組みを提供しているものとして、「データベース」が存在する。 ただ、「データベース」と一口に言っても、Accessや SQL Server、Oracleなどのデータベースソフトがあり、様々な種類の格納環境が存在する。今回はこの中でも最も馴染みの
深く、使い慣れている Accessを利用する事とした。しかし、問題がある。それは、様々な機能を持っていればインターフェースも異なるという、これらの環境に直接アクセスする
のはいかに ASPでも無理というものである。 5.2 ASPからデータベースへの接続 Web アプリケーションと各データベースをとり繋ぐ役割をする仲介者が存在する。今回その仲介者として OLE DBを利用する事とする。OLE DBはWebアプリケーションと各データベースの間に入って、共通のインターフェイス（窓口）を提供する。つまり、OLE DBを使用すれば、Accessにも Oracleにも、OLE DBに対応しているどんな「データベース」にも同じ命令でアクセスできると言う訳である。図７OLE DBと各種データベースとの関係を以下図 7にて示す。 かつて ODBC（Open DataBase Connectivity）と呼ばれる仕組みが提供されていたが、より高度な COMベースの OLE DBに移行していくだろうと言われている。 OLE DBで Accessに接続するには、あらかじめ Jetエンジン対応の OLE DBのモジュールがサーバマシンに導入されている必要がある。もしもインストールされているモジュ
ールがわからない場合は、Component Checker[5]をダウンロードして、サーバマシンのモ
ジュール導入状況をトレースする事が可能である。 もしモジュールが存在しない場合は、Microsoft Data Access Components 2.6 RTM[5]と、
Microsoft Jet 4.0 Service Pack 3[5]をダウンロードし、インストールすれば OLE DB でAccessに接続する環境を整える事が可能である。
14
Access
SQL Server ASP
Oracle 直接の接続は不可能
Access
SQL Server ASP
OLE DBOracle
OLE DBが各データベースへの共通の窓口
を提供
図 7 OLE DB によるデータベースへの接続
6. アプリケーションの仕様の想定
6.1 ASPの構成ファイルの想定 本研究でスケジュール管理のWebアプリケーションを作成する上で、基本的な構造、いわゆる骨組みとして、「今日から使える ASP3.0 サンプル集」[1]のサンプルプログラムを利
用する事とする。その基本的な構成を以下図 8にて示し、ここで概要を述べる。 まず、トップページとして今月のカレンダを表示するページがあり、予定の入っている
日付の枠が色分けされて表示する仕組みで、前月と、次月の“calendar.asp”へのハイパーリンクと、カレンダの各日付には、その日付に対応した詳細予定“day.asp”へのハイパーリンクが貼られている。この指定した日付への移動は、リンク元からリンク先へ選択した
日付の情報を授受する事で可能である。具体的には、”a href“の URLのパスにクエリ情報として移動先の日付の情報を付加することで実現可能である。図９このページを「今日のカ
15
レンダ“calender.asp”」図８とする。クエリ情報によるページ間のデータの授受を以下図 9にて示す。次に、“calendar.asp”に、ドロップダウン形式で予定区分を選択し、選択した予定区分の予定を抽出し、ダウンロードの処理を行うページへ移動する。このページを「予
定種別ダウンロード“cate.asp”」図８とする。次に、カレンダに表示されている日付をクリックすると、選んだ日付の予定の確認、追加、削除が行えるページへ移動する。ここで登
録した予定の確認や、入力、削除を行う。このページを「今日の詳細予定“day.asp”」図８
とする。次に、“day.asp”の入力フォームに予定を記述し、送信ボタンをクリックすると、入力フォームで入力されたパラメータを追加クエリに引き渡し、クエリ実行して登録を行
なうページに移る。このページを「スケジュール追加“update.asp”」図８とする。次に、
“day.asp”の「中止“OK”」をクリックすると、削除を選択した予定のレコードを、予定のテーブルの”id”のフィールドを抽出条件として抽出を行い、削除の処理を行うページに移る。このページを「スケジュール削除“delete.asp”」図８とする。以上が予定確認・予定入力・予定削除といった、スケジュール管理の基本機能を備えた「今日から使える ASP3.0サンプル集」[1]のサンプルの構成である。その基本構成を以下図 8にて示す。
6.2 Accessでデータベースファイルの作成 今度は入力されるデータの格納場所である、データベースファイルの作成です。これは、
データベースソフトで行ないます。Microsoft Accessを起動し、「テーブル」を作成します。このテーブルに入力される予定の全てが記録されるわけです。デザインビューで作成し、
フィールドを追加します。まずは、各予定を一意に決定する固有の番号を記録するフィー
ルドを用意します。これをフィールド名「id」とします。そして、言うまでもなくこのフィ
今日のカレンダ calendar.asp (1)
各日の詳細予定 day.asp (2)
予定種別ダウンロードday.asp (3)
スケジュール追加 update.asp (2)
スケジュール削除delete.asp (2)
図 8 Ｗｅｂスケジュール帳ファイル関係図[1]
16
4月 15日というクエリ情報今日のカレンダ
index.asp (1) 4月 15日の詳細予定
day.asp (2)
4月 15日をクリック
4月 15日の予定表示
来月の カレンダ表示 来月の日付の
クエリ情報
“来月へ“をクリック 来月のカレンダ
index.asp (1) 今月のカレンダindex.asp (1)
図 9クエリ情報によるページ間のデータの受け渡し
6.2 Accessでデータベースファイルの作成 次に、入力されるデータの格納場所の、データベースファイルの作成である。これも基
本となる部分は「今日から使える ASP3.0サンプル集」[1]のサンプルのデータベースの構造
を流用する事とする。まずは、Microsoft Accessを起動し、テーブルを作成するところから始まる。このテーブルに入力される予定の全てが記録されるのである。その内容は、各予
定を一意に決定する固有の番号を“id” 表１とし、主キーとする。次に、予定の年月日の記
録を“pdata”表１、予定の開始時刻の記録を“ptime”表１、実際の予定の内容の記録を“pname”表１、最後に予定区分の記録を“cate” 表１とする。このテーブル名を“schedule” 表１とす
る。テーブル“schedule”の構成を以下表 1にて示す。 次はユーザの要求ごとのデータの抽出を行なう「クエリ」の構造について述べる。各日
の「詳細予定“day.asp”」図８は、「今日のカレンダ“index.asp”」図８で選択した日付に登録済みの予定を全て明示する必要がある為、予定の年月日を抽出条件として、“schedule”の全てのフィールドを抽出する選択クエリを作成する。これをクエリ名“scheday” 図１０とす
る。次に予定を予定区分ごとにダウンロードする際の、予定区分ごとに予定の抽出を行う
選択クエリを作成する。これをクエリ名“schecate” 図１１とする。次に、その予定区分別
ダウンロードの際に、1年以上前の予定を削除する際の、削除クエリを作成する。これをク
17
エリ名“scheOldDel” 図１２とする。次に予定を削除する際、削除を選択した予定の固有の
レコードを特定して削除する必要がある為、予定のレコードを一意に特定可能な“id”を抽出条件とする削除クエリを作成する。これをクエリ名“schedel” 図１３とする。そして、「各
日の詳細予定“day.asp”」図８で入力された、入力フォームのパラメータを “schedule”に追加する追加クエリを作成する。“id”はオートナンバーで自動的に決まる為、それ以外の“schedule”の全てのフィールドを追加する。これをクエリ名“scheinsert“図１４とする。以上がサンプルのテーブルの仕様である。各クエリの構成を以下図 10～14にて示す。このデータベースをファイル名“masetr.mdb”とし、保存する。以降、研究の必要に応じてこのデータベースを拡張していく。
表１テーブル“schedule”の構成
フィールド名 データ型 フィールドサイズ 備考 id オートナンバー型 - 予定固有の番号（主キー） pdate 日付/時刻型 - 予定年月日 ptime 日付/時刻型 - 予定開始時間 pname テキスト型 50 予定の名前 cate テキスト型 10 予定区分（「会議」や「私用」
など）
図 10クエリ名：scheday（予定詳細抽出） 図 11クエリ名：schecate（カテゴリ別の予定抽出）
図 12クエリ名：schedel（予定削除） 図 13クエリ名：scheinsert（予定新規登録）
図 14クエリ名：scheOldDel（1年以上経過した予定の削除）
18
7. 機能の拡張
7.1機能拡張の概要 本研究では、6章において述べたサンプルをベースとして機能拡張を行い、より実用的なアプリケーションを構築する。具体的な、拡張機能を 5つ挙げる。 第一に、予定入力項目の追加する。サンプルでは予定内容、予定開始時間、予定年月日、
予定区分の、４つの要素しか登録できなかったが、さらに、予定終了時間、予定タイトル、
予定の場所、記入したユーザの ID、記入したグループの ID、記入日時の 6要素を新たに追加するものである。また、サンプルでは予定内容が最大 50だったのを、255文字に拡張した。第二に、カレンダー自体に現在の予定を表示する機能を加えた。サンプルでは、カレ
ンダー表示時に予定の入っている日付は色をつけて表示する仕組みであったが、それでは
実際にどのような予定が入っているのかを確認できない。そこで、実際の登録している予
定自体を簡易的に表示するというものである。第三に、登録済みの予定を更新する機能を
追加した。サンプルでは予定の追加、削除の機能は存在したが、登録済みの予定を更新す
る機能は存在せず、これでは予定の登録ミスの訂正や、変更等を一切行うことができない
為、この機能を追加する事とした。第四に、１ヶ月の予定一覧表示機能を追加した。サン
プルでは１ヶ月の予定を表示する画面はカレンダーのみで、それも予定の入っている日付
の色が変わるだけで、１ヶ月通しての実際の予定を明示する画面が存在しなかった。そこ
で、１ヶ月全ての予定を抽出し、縦に並べて全表示するという機能を追加する事としたの
である。第五に、定期予定の登録機能を加えた。これはサンプルにはまったくない機能で
あったが、毎週決まってある用事や、毎月、毎年の恒例行事などを登録する機能である。
そして第六に、今回開発において最も勢力を込めたユーザ管理機能を構築した。これもサ
ンプルには全くなかった機能で、ユーザがユーザ ID・パスワードを設定してユーザアカウントを生成し、そのアカウントを利用して自分だけの予定表の利用を可能にしたものであ
る。さらにこれに加えて、グループも登録できるようにした。これは何人かをまとめてグ
ループで登録し、そのグループ内で予定を共有するという機能である。これらの機能を追
加する事で、単なるスケジュール管理のWebアプリケーションではなく、複数のユーザが共同で利用できるグループウェアの役割を果たすアプリケーションを構築可能である。 7.2拡張機能の追加工程
第一の予定要素の追加は、主にテーブル“schedule”の拡張になる。データベースファイルのスケジュールのテーブル（テーブル名 schedule）のフィールドへ、既存の予定内容、予定開始時間、予定年月日、予定区分の、４つの要素に加えて、予定終了時間、予定タイ
19
トル、予定の場所、記入したユーザの ID、記入したグループの ID、記入日時の 6要素を新たに追加し、それぞれのデータ型を指定する。この時、予定の内容のフィールドサイズを
50から 255に変更すれば、予定内容を 255文字に拡張が可能である。次に、予定を抽出するクエリに追加した要素も抽出する様に設定しなおせば、後は ASPファイル内で入力フォームを作り直し、クエリに引き渡すパラメータの追加を行う。この時、クエリに渡す予定
内容のパラメータの要素サイズの記述を 255 に拡張しなければ、データベースで拡張したフィールド側の 255 の値と一致せず、エラーとなるので注意が必要である。これで第一の機能は完成である。第一の機能拡張で、テーブル“schedule”へ追加したフィールドの構成を以下表 2にて示し、その表示画面を図 15にて示す。
表 2テーブル“schedule”へ追加したフィールドの構成 フィールド名 データ型 フィールドサイズ 備考 pname テキスト型 50⇒255 予定の名前 etime 日付/時刻型 - 予定終了時間 ptitle テキスト型 30 予定のタイトル place テキスト型 30 予定の場所 wuid テキスト型 10 記入したユーザの ID wgid テキスト型 10 記入したグループの ID wlog 日付/時刻型 - 記入した日付
予定の内容を最大 255文字に拡張
図 15 予定詳細画面
20
次に、第二のカレンダ表示の日付の枠内に登録された予定の内容を表示する機能を構成
する。これは、カレンダ表示のソース内で、書く日付にリンク付けられたスクリプトの後
に、その日付の予定を抽出し、表示させるスクリプトを挿入すれば構成できる。しかし、
このままではここでは予定の記入者、開始時間、タイトルを表示させる事とする。しかし、
全部表示させると、カレンダー内にとても収まりきらない為、フォントを 2 サイズ下げ、記入者は頭文字１文字、開始時間はそのままで、タイトルは先頭から 8 文字までを表示させる。これで、カレンダ表示時にある程度登録した予定が把握できる様になる。第二の機
能拡張の完成図を以下図 16にて示す。
個人でのログオン画面
クエリ情報。この場合は日付けのデータ“dat=2002/12/06”と、グループか個人のどちらのログインかの判別データ“log=1”が送られて来ている。 ・毎週の定期予定は“青”
・毎月の定期予定は“オレンジ”・舞年の定期予定は“赤“で表示
・名前は、山田 太郎の頭文字表示・タイトルは、映画鑑賞（in アポロビル）の先頭８桁表示
図 16 カレンダへの予定の表示
次に、第三の予定更新機能である。まずは、テーブルのレコードに対して更新をかける
更新クエリをデータベースで作成する必要がある。更新を行うフィールドとして、スケジ
ュールのテーブル上のフィールドの全てのフィールドを加え、どの予定のレコードに更新
を行うかを一意に指定する為、スケジュールの IDのフィールドを抽出条件に指定する。これで更新を行うレコードを抽出し、同時に更新を加えるクエリが完成したので、後は今日
の詳細予定の図５ASPページの予定表示の部分に更新と削除のラジオボタンを設置し、削除
21
の方はサンプルにあった削除のページへ、更新のほうは、クエリに入力フォームのパラメ
ータを引き渡し、クエリを実行するページを作成し、そこへ移動する様に記述すれば、今
日の詳細予定のページ図５で、予定の追加、更新、削除の３つの操作が可能になる。第三の
機能拡張の完成図を以下図 17にて示す。
この予定は毎週の定期予定に登録されている
図 17 予定更新機能
次に、第四の１ヶ月の予定一覧表示の機能を構成する。これは、”For~Loop”で月初めから月末までループさせ、そのループ内で、各日付ごとの予定を抽出し、予定が抽出された
場合は HTMLで出力するという処理を記述すれば完成である。ここで表示させる予定のフィールドとして、日付、曜日、記入者、タイトル、場所を挙げる。日付の記述は、（今日の
詳細予定）へリンクするボタンを生成してそれに日付を表示し、そのボタンに日付のクエ
リ情報を含ませることで、そのボタンをクリックすればクリックした日付の詳細予定のペ
ージに移動する仕組みを構成する事が可能である。第四の機能拡張の完成図を以下図 18にて示す。
図 18 １ヶ月の予定一覧表示機能
今日の日付は黄色で色づけ
7.3リレーションシップの利用 第四までの機能拡張では、サンプルにあった機能をそのまま拡張することで実現できたが、
第五の機能拡張からは、サンプルには一切存在しなかった機能である為、データベースの
テーブルを 1 から準備する必要がある。更に、作成したテーブルと、スケジュールのテー
22
ブル（テーブル名 schedule）とを関連付けさせる為に、リレーションシップを構成する必要が出てくる。文献「今日から使える ASP3.0サンプル集」[1]には、リーションシップに関
することは掲載されていない為、文献「「クエリ」がわかると Access2000 に強くなる」[2]
を利用し、リレーションシップを構成する事とする。 第五の毎週、毎月、毎年の定期予定を登録可能な機能を組むには、データベースファイ
ルのスケジュールのテーブル（テーブル名 schedule）のフィールドに、週、月、年のフィールドを設け、ユーザによって毎週に登録された予定は週の、毎月に登録された予定は月
のフィールドに、予定を登録した日付の曜日、日付を記録すれば良い。毎年も同じ事であ
る。これならば新しいテーブルを作成する必要もなく、無論、リレーションシップを構成
する必要性も無い。しかし、これでは、ただでもスケジュールのテーブルには第一の機能
拡張でフィールドが既存の 4要素に加えて追加の 6要素で、計 10要素も存在するのに、更に 3 要素を加えることとなると、データベースファイルが膨れ上がる事となる。そこで、毎週、毎月、毎年の予定を登録するテーブルを別で用意し、リレーションシップを構成す
ることで、クエリ上で結合させて利用する事で、擬似的にテーブルを 13要素に拡張した事と同じ状態を作り出すことが可能である。後はチェックボックス形式で入力フォームを追
加し、次にクエリに入力フォームのパラメータを引き渡し、クエリを実行する記述を加え
れば完成である。定期予定に登録した予定の図を、上の図 16、17にて示す。 次に、本研究最大の難関であった、第六の追加機能である、ユーザ管理について述べる。
まず、どのような構成にするかという事から考えていく必要がある。本研究では、単なる
Web アプリケーションではなく、不特定多数のユーザが共同で利用できるグループウェアを作成したいと考えた為、個人とグループの 2 種類のアカウントを登録するテーブルが必要になる。個人用のアカウントは、ユーザ ID（主キー）、ユーザ名、パスワード、ユーザのログイン日時の 4 つのフィールドのテーブルを作成する。問題はグループのアカウントだが、個人用のアカウントのテーブルにフィールドとして追加するだけでは、Aというグループに属しているユーザがいたとすると、そのユーザは A というグループから脱退しない限り、他のグループに属することが不可能になる。すなわち、１人 1 グループにしか属することが出来ないという事になる。複数のグループに属する事を可能にするには、個人アカ
ウントのテーブルと、グループアカウントのテーブルを分ける必要があるのである。そし
て、その二つの利用窓口を作成する必要がある。更に、その 2 つのテーブルを関連付ける為のテーブルを１つ用意し、これら 3 つのテーブルをリレーションシップで関連付ける事で、自分がどのグループに属しているかという事を意識する必要なく、複数のグループに
属することが可能になる。これでアカウントを登録する為のテーブルは完成である。第五
の機能拡張と、第六の機能拡張で構成したリレーションシップを以下図 19にて示す。
23
各グループのメンバーがここに登録されている
毎週、毎月、毎年の定期予定のリレーションシップ
個人とグループの リレーションシップ 図 19第五、第六の機能拡張で構成したリレーションシップ
8. 複数ページにまたがるユーザの追跡
8.1ユーザの特定
ユーザ管理するには、ユーザが誰であるかを特定する為に、ユーザ IDとパスワードの入力を要求する必要がある。そのパスワードを元に利用者が誰であるかを特定し、その利用
者だけの予定を表示させる事で、あたかも自分専用のWebスケジュールアプリケーションを利用しているかのようにする事が可能である。また、この事により、自分の登録した予
定は一切他人に見られることは無いので、プライベートな内容でも気にすることなく登録
することが可能である。また、ユーザ”A”と”B”と”C”でグループ登録した場合は、グループのパスワードを確認した場合は”A”と”B”と”C”がグループで登録した予定のみを表示させるようにすれば、3人共同でスケジュールを組み、予定を構成することが可能になる。しかし、理論上では可能であるが、実際Web上でそれを実現させようとすると、様々な制限に阻まれる事となる。
8.2ページ間のデータ共有の必要性
7.1 でも述べた様に、どのユーザが利用しているかを特定するには、ユーザ ID とパスワードを確認する必要がある。確認後、複数のWebページで構成されるスケジュール管理のアプリケーションにログインするのだが、Web ページの仕組みとして、基本的には１つの
24
Web ページ内でしかデータを保持しないという特性があるため、仮にユーザを確認して、今日のカレンダ[5]のページでそのユーザのみの予定を表示できても、そこから別ページの今
日の詳細予定[5]へ移った瞬間、どのユーザが使用しているかというデータはクリアされ、ま
たユーザ確認の為にユーザ IDとパスワードをユーザに要求する必要が出てくる。ページを移動するたびにユーザ IDとパスワードを聞かれていては、ページを移動するのも嫌になってしまうであろう。そこで、１度入力されたユーザ IDとパスワードのデータを、複数のページ間で保持する必要がある。方法は幾つか存在し、第一に、最も簡単なものに他ページ
へのパスにクエリ情報を付加させる方法である。しかし、この方法は URLに送られているデータがそのまま表示される為、パスワード等の他人に知られたくない情報を載せるのに
は全く適していない。図１６第二に、<input>タグの隠しフィールドを利用して、ここに情報を付加させ、ページ移動時に送信してデータを他ページへ受け渡すという方法があるが、
この方法も、Webブラウザの“ソースの表示“で中に入っているデータが見えてしまう為、これもパスワード等の情報を入れる器として適していない。そこで、ASP の注目すべき大きな特徴である、Sessionオブジェクトを利用する事とする。セッションとは、ユーザがシステムにログインしてからログアウトするまでの一連なりの期間のことをいい、この間に
共通で利用されるデータを一元的に管理するのが Sessionオブジェクトの役割である。また、Sessionオブジェクトが管理する変数の事を”セッション変数“と言い、セッション変数はページ単位で破棄されず、セッション期間中永続的に保存されるという特徴を持っている。
すなわち、このセッション変数にユーザ IDとパスワードを格納すれば、セッション期間中はどれだけページを移動しても特定したユーザのデータを保持し続けることが可能である。 セッションによるページ間のデータ共有の仕組みを以下図 20にて示す。
今月のカレンダ index.asp (1)
今月の予定一覧 schelist.asp (5)
今日の詳細予定day.asp (2)
セッション内の全てのページから参照可能
4月 15日の予定のセッション情報
1セッション
図20 セッションによるページ間のデータの共有
25
8.3 Sessionオブジェクト利用上の注意点 しかし、Sessionオブジェクトを用いる上で、注意する点が 2つ存在する。１つは、サーバのリソース（資源）を大きく消費するという点で、ユーザが他のサイトに移ったり、ま
たはブラウザそのものを閉じてしまった等で、そのページには居なくなった後でも、サー
バはもう要らなくなったセッション情報を一定時間は保持し続ける。これは、ユーザ数が
非常に限定されているうちは、大した問題では無いのだが、ユーザ数が多くなってくるに
従って、サーバリソースを逼迫する深刻な原因となってくる。従ってむやみにセッション
変数を多用することは避けなければならない。又、セッション情報が一定期間残るという
事は、その期間中で同じ端末からなら、他の誰かがそのサイトを除けることなる。しかも、
IDやパスワードを「盗まれた」本人は盗まれているという自覚が無いのである。これでは、リソースの有効利用という面からもセッション管理という面からも、非常に不十分なアプ
リケーションであると言える。そこで、ログオフのページを作成し、そこへ Sessionオブジェクトに格納された情報の全てを開放するメソッドである”Session.Adandon”を記述すれば、ユーザがアプリケーションの利用終了時に Sessionを明示的に閉じることが可能である。 以上の説明で、度々「一定時間」と述べているが、具体的には既定で 20 分である。また、”Session.Timeout”プロパティでタイムアウト時間の設定を変更することも可能である。また、セッションの有効期限が終了すると、何の前触れも無くセッション情報は消去され
るので、セッション情報を元にユーザを特定しているので、次にセッション変数を見に行
った時にエラーが返ってくる事となり、使用しているアプリケーションがたちまち利用不
能になる。これではユーザはなぜエラーになったのか判らないので、セッションが終了し
た時の処理を記述する必要がある。セッションが終了したときに呼び出されるイベント処
理として、”Session_OnEnd”がある。これを使用すれば、セッション終了時行う処理を記述できる。但、これを記述する場所はファイル名”global.asa”というファイル内部に限られる。”global.asa”とは、仮想ディレクトリの直下に設置することで、Webアプリケーションをアプリケーション単位やセッション単位で一元管理することができる非常に有効なプロ
ジェクトファイルである。ここに、先ほど述べた”Session_OnEnd”と記述し、そのときの処理として、「ログオンの有効時間が切れました」と記述させて、ユーザをログイン画面に
誘導すれば良い。図２１逆に、セッション開始時に呼び出される”Session_OnStart”というイベント処理があるので、セッション開始時にユーザがアクセスしようとしている URLがログイン画面の URLで無い場合、すなわち、予定追加などのページの URLを指定して不正に他人の ID を使用しようとした場合等の時に、「こちらのログオン画面からお入りください」という具合にユーザを強制的にログイン画面に誘導することが可能である。図２２セッシ
ョン開始時と、セッション終了時のユーザの誘導画面を以下図 20、21にて示す。 以上 6.3のリレーションシップによる個人ユーザアカウントと、グループアカウントの関
連付け、そして第 7 章の Session オブジェクトによる、セッション変数と、セッションを
26
明示的に開放する ”Session.Adandon”、セッション開始時と終了時のイベント処理”Session_OnStart”と、”Session_OnEnd”を有効に利用すれば、完全なユーザ管理が可能である。後はユーザごとにユーザに対応した予定を抽出し、表示させるようにし、ログイ
ン画面の作成図２３、ユーザ及びグループの登録・更新図２４～２８を行えるようにすれば、不特
定多数のユーザが共通で利用可能なグループウェアが完成する。更に、今回はグループと
個人の表示切替も可能にした図２９。ログイン画面と、ユーザ及びグループ登録画面を以下図
22～26にて示す。 以上 6つの新機能の追加が、本研究において最も主力を注いだものである。
図 21セッションの有効期限切れ時のユーザ誘導 図 22セッションスタート時のユーザ誘導
図 23ログオン画面 図 24ユーザ登録画面
図 25グループ登録画面 図 26ユーザ更新画面
27
図 27グループ追加画面 図 28ユーザのパスワード更新画面
グループでのログオン画面
ドロップダウン形式で選択し、表示切り替えを行う
個人ログインでは表示されていなかった、グループで登録されている予定。“前”は、前田さん、“松”は松本さんである。
図 29グループとユーザの表示切り替え
9. 今後の拡張性
本研究において文献「今日から使える ASP3.0サンプル集」[1]のサンプルに 6つの機能を付け加えたが、アイデア次第ではまだまだこのアプリケーションには拡張の余地が存在す
る。例を挙げると、ユーザアカウントにメールアドレスを付加し、グループで使用時に予
定表に自分のグループに所属するメンバーのメールアドレスを表示させれば、メンバー間
の連絡のやり取りを円滑に出来る。次に、出張等の何日かにまたがる予定を登録できるよ
うにする。次に、携帯電話でも予定の閲覧、追加、変更、削除が行なえる様、携帯電話用
28
のWebサイトを用意する。この時もちろん使用するデータベースは、パソコンで使用するものと同じものを使用する。次に、祝日の表示をする等である。特に携帯電話で利用でき
る様にするというものは、外出中インターネットにつながっているパソコンが無くとも、
携帯電話さえあればアプリケーションを利用出来るという非常に実用性の高いものである
為、今後拡張する事を検討している。
10. むすび
以上、本論文ではインターネットを利用できる環境であれば場所を問わず利用可能な、
スケジュール管理のWebアプリケーションを構築する事を研究の動機とし、アプリケーションを構成する言語として ASPスクリプトを起用して Web サーバ構築、Web サーバセキュリティ対策を施し、文献「今日からつかえる ASP3.0サンプル集」[1]のサンプルをベース
として、第一に予定登録項目の追加、第二にカレンダー表示時の予定明示、第三に登録済
みの予定の更新、第四に登録されている１ヶ月の全ての予定の一覧表示、第五に毎週・毎
月・毎年の定期予定の追加、第六に個人・グループのユーザ管理機能の、計 6 つの新機能を付け加える際の技術検証、留意点、導入工程について述べ、最後に更なる拡張性につい
て述べてきた。本研究の結果、以下の事を学んだ。 WindowXPには IISやファイアウォール機能等のWebサーバの構築を支援する為のコンポーネントがあらかじめ搭載されている
非固定 IPアドレスでもWebサーバを構築出来る Webサーバの構築にはファイルアクセス権の設定が必須である為、ネットワーク OSである必要性がある
ファイアウォールの設定で、Web サービスを実行しないサーバのポートは閉じるべきである
ファイアウォールだけではセキュリティ・ホールを狙った攻撃を防ぐことが出来な
い為、ISAPIフィルタを使用してこれらを防ぐ必要がある Webは基本的に１つのページ内でしか状態を保持しない Sessionオブジェクトを有効利用する事で、複数ページが共通で利用するデータを一元管理することが可能である
本論分を論述するに当たって、実際の研究の方が進まない事には論文を書くことが出
来ないという点で論文作成で遅れをとってしまい、その遅れを取り戻すのに非常に苦労
をした。しかしその切迫感が逆に作業効率を向上し、限られた期間に中で両者とも高い
完成度のものを作成出来たと考えている。又、本研究を通して感じたことは、アプリケ
29
30
ーションを構成する上で、使用する言語やスクリプト等の技術的な知識が必要なのは勿
論の事、アプリケーション全体をどの様な構成にし、どの様な流れをするのかというの
を、ユーザが操作するパターンを想定して、こちらであらかじめその操作に対する準備
をする事が必要であるという点である。これはアプリケーション全般に言える事で、ど
の様なアプリケーションを作成する際も、アプリケーションの全体の流れと、ユーザの
操作を頭にしっかりとイメージしながら作成することが肝心であるという事を実感した。
11. 参考文献
〔１〕今日から使える ASP3.0サンプル集 著者：山田 祥寛 発行所：株式会社 秀和システム 〔２〕「クエリ」がわかると Access2000に強くなる
著者：高橋 良明 発行所：株式会社メディア・テック出版 〔３〕セキュリティ完全対策 編者：日経バイト 発行所：日経 BP社 〔４〕DiCE DynamicDNS Client (自宅でインターネットサーバー)
http://www.hi-ho.ne.jp/yoshihiro_e/dice/#DICE 〔５〕Microsoft Universal Data Access http://www.microsoft.com/japan/developer/data