筒井ゼミ 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 Web サーバ ActiveX JAVA スクリプト プログラムの流出 ネットワーク への負荷 JAVA 仮想マシン COM スクリプトエンジン クライアント環境に依存 異なった 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 アプリケーションの開発に利 用しようと考えたのである。 Web サーバ Ｗｅｂクライアント CGI スクリプト CGI スクリプト 要求の数だけプ ログラムが起動 してしまう CGI CGI スクリプト Web サーバ Ｗｅｂクライアント 同じ処理は同じコン ポーネントが一人で 片付けてくれる ASP コンポーネント ASP スクリプト 図 3 ASP コンポーネントによるサーバリソースの共有[1] 7 Web サーバ Web サーバ CGI ページ B 表示結果Ａ 表示結果Ａ 表示結果Ａ お互いに関係しない 別々の要求 ページ C ＷｅｂページＡ・Ｂ・Ｃを要求 ページ A 表示結果Ａ ページ C 表示結果Ａ ＷｅｂページＡ・Ｂ・Ｃを要求 ページ B 表示結果Ａ ページ A ASP 1 セッション 同じクライアントからの 要求は、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 （変わらない） 221.153.211.237 で 登録（変われば更新） DNS サービスを利用 しているサーバ クライアント 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 DB Oracle 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 にて示す。 今日のカレンダ calendar.asp (1) 各日の詳細予定 day.asp (2) 6.2 Access でデータベースファイルの作成 今度は入力されるデータの格納場所である、 データベースファイルの作成です。 これは、 スケジュール削除 スケジュール追加 delete.asp (2) update.asp (2) データベースソフトで行ないます。Microsoft Access を起動し、 「テーブル」を作成します。 このテーブルに入力される予定の全てが記録されるわけです。デザインビューで作成し、 予定種別ダウンロード フィールドを追加します。まずは、各予定を一意に決定する固有の番号を記録するフィー day.asp (3) ルドを用意します。これをフィールド名「id」とします。そして、言うまでもなくこのフィ 図 8 Ｗｅｂスケジュール帳ファイル関係図[1] 16 今日のカレンダ index.asp (1) 4 月 15 日という クエリ情報 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 にて示す。 次はユーザの要求ごとのデータの抽出を行なう「クエリ」の構造について述べる。各日 「今日のカレンダ“index.asp”」図８で選択した日付に登録 の「詳細予定“day.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) 今日の詳細予定 day.asp (2) 今月の予定一覧 schelist.asp (5) セッション内の全てのページから参照可能 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 ーションを構成する上で、使用する言語やスクリプト等の技術的な知識が必要なのは勿 論の事、アプリケーション全体をどの様な構成にし、どの様な流れをするのかというの を、ユーザが操作するパターンを想定して、こちらであらかじめその操作に対する準備 をする事が必要であるという点である。これはアプリケーション全般に言える事で、ど の様なアプリケーションを作成する際も、アプリケーションの全体の流れと、ユーザの 操作を頭にしっかりとイメージしながら作成することが肝心であるという事を実感した。 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 30
© Copyright 2026 Paperzz
