インプロセスとアウトオブプロセスの比較

秋月 巌 AKIZUKI, Iwao
首都圏コンピュータ技術者共同組合

　最近，気になっていることが2つある．1つは著作権の範囲についてである．たとえば，この記事で使用するCGI4VBというモジュールは，http://www.prplus.comから，Get（ダウンロード）してきたものである．このモジュールはソースコードが公開されており，私はVisual Basic Magazineの読者が理解しやすいように，いくつかのコードを削除し，2バイト文字に対応できるようにいくつかのコードを追加した．

　ダウンロードの出所を確認しようと同じサイトへのアクセスを試みたが，どこかへ引越してしまったのか，再び見つけることはできなかった．もっとも，プログラミングはスタンダードなものだから，変数名のすべてを変更し，いくつかのプロシージャの実行順序を変更するだけで，それを自分がつくったものだと主張することはできたかもしれない．

　もし，それは一切認められないとすると，たとえば，誰かがシンプルなアルゴリズムのソースをインターネットで公開しただけでも，それについて権利が発生するということになる．

　とにかく，今回，掲載するプログラムのコアになる部分を開発したのは，http://www.prplus.comのオーナー（あるいは元オーナー）であるということだけは，明記しておいた方がよさそうである．ソフトウェア業界は基本的にライセンスビジネスなのだから，権利に神経質になるのは当然である．だが，あまり神経質になりすぎると何もできなくなってしまい，結局は誰のためにもならなくなる．

　もう1つの気になっていることとは，言葉の定義の問題である．たとえば，SQLデータベースサーバーと，ファイル共有型データベースを区別するとき，私は今まで「SQLデータベース」と「非SQLデータベース」という呼び方をしてきた．日本のエンジニアがデータベースに持っているイメージとして，それが最も理解しやすいのではないかと考えたのだが，もちろん，これは「正しい」呼び方ではない．ファイル共有型データベースのほとんどがSQLをサポートしている現在，やはり，厳密な呼び方に改めるべきだろう．

　これに類する問題はいくらでも考えられる．混乱した言葉の定義が米国で発明され，それを曖昧に解釈したジャーナリストたちが日本のメディアに発表していく．また，ソフトウェアベンダーが新技術を発表する段階で定義を変更する場合もある．OLEなどは，その典型的な例にあたるだろう．後で仕様変更がきくように曖昧な表現を用いるのではないかと思いたくなるようなケースもある．

　また，用語を翻訳すべきか原語のまま使用するかの判断の難しい場合もある．曖昧な用語によって新技術を吸収していくのだから，混乱が生じて当然である．現在のソフトウェア業界を取り巻いている誤解を解きほぐすことこそが，コンピュータジャーナリズムの使命なのだろうが，現実はなかなか難しい．各々のエンジニアの努力に依存しているのが現状である．

　「WEBデータベースシステム」というのが正しい呼び方なのかも判断は難しい．それでも，WEBデータベースシステムが，現在，最もトレンドな技術であることは間違いない．各データベースベンダーとWEBサーバーベンダーが，WEBとデータベースを連携させるシステムを提供することに凌ぎを削っているのは，このシステムが強固なセキュリティを獲得したときに，エレクトリック・コマースの本命がスタートするからである．エンドユーザーの手元にあるWEBブラウザからデータベースにアクセスし，オンライントランザクションをおこなうのは，コンピュータが具現する最も有効な姿の1つであるに違いない．

　WEBデータベースシステムが，一般のC/Sシステムに対して持つ優位点には次のようなものがあげられる．

1，ブラウザが各種のOSに対応していることにより，Macintosh，OS/2，Windows，UNIX，それぞれの環境から一律の方法でデータベースへのアクセスが可能である．これはOSが混在している環境では強みになる

3，地方の出張所が地元のプロバイダに接続して本社のサーバーにアクセスすれば，高価な専用線やRASの高価な通話料なしに，WANシステムを実現できる

5，たとえば，従来のシステムではメニューの構成を1つ変更するのにもエンジニアが必要だったが，WEBシステムではHTMLを理解していれば，多少の再構成は可能となる

　逆に不利な点としては次のようなものが考えられる．

1，HTMLの性質上，データの受信が常にテキストデータとファイルという形でやりとりされる．JAVAアプレットのように，中間コードのモジュールを受信して実行することもできるが，それもパラメータのやりとりはHTMLの中に記述される

　結局はブラウザのタグ解析能力に依存することになる．それよりも現実的に問題となるのは，キャッシングのタイミングが各ブラウザで違うために，最新のデータが表示されないという現象が多々発生する点にある．解決策としては，キャッシングをOFFに設定することだが，その場合のパフォーマンスにはかなりきついものがある

　また，ブラウザ標準の「進む」「戻る」ボタンも問題となる存在である．ユーザーの好きなように前画面に移動できるのはユ―ザーにとって親切ではあるが，インターフェイスアーキテクチャの設計において，かなり制約が加えられる

2，ネットワークトラフィックのパフォーマンスは，イントラネットで使う限り大きな不満は発生しない．それよりも問題となるのは，ブラウザのタグ解析処理の遅さである．1000件ヒットしたデータを表形式で表示する場合，データの取得が終了していても，描画のためにかなりの時間待たされることになる．だからといって，表示するレコードだけを取得しておいて，スクロールするときにフェッチしながらデータを取得するという方法も現時点では採用しにくい

3，これはJAVAやActiveXなどのテクノロジーにより，いずれ解決されるだろう．それでも2で述べたような理由により，表形式でデータを入力するインターフェイスを高いレベルで作成することは難しい．これから，優れたビジュアル開発環境が提供されるだろうが，結局はHTMLの一部として動作するという不自然さから逃れることはできない．いずれ，HTMLがコンパイルされたモジュールを呼び出すためだけに利用されるようになったとき，ブラウザはただのアプリケーションフレームになる．まぁ，それはそれでいいだろう

4，データをHTTPで転送してブラウザでタグを解析しながら表示するというスタイル上，WEBは定型のレポート作成に向かない．クリスタルレポートのActiveXコントロールが発表されているので，その辺りが解決の糸口になるのだろうか?　印刷用のテンポラリーファイルをWORDなどでサーバー側でダイナミックに作成して，それをダウンロードして印刷するのが，妥当な方法になるのかもしれない

　前々号の特集で紹介したMicrosoftのIDC（Internet Databse Connector）も，Microsoft Internet Information Server用のデータベース接続機能の1つである．ただ，この機能はODBCを経由してアクセスするため，データベースエンジンの言語に依存する．Transact-SQLや，PL/SQLなどのSQLや，拡張されたSQL言語を使用することはできるが，途中で他言語で開発したプログラムが介在することを認めない．

　例外としては，SQL Server6.5に新しく搭載されたOLEオートメーションストアドプロシージャを使用する方法がある．これはSQL Serverのストアドプロシージャから，Visual Basicなどで作ったOLEオートメーションサーバーを利用する方法だが，今回はもっとシンプルな方法を紹介したいので割愛する．興味のある方はSQL Server6.5にサンプルが添付されているので，試してみるのもいいだろう．

　今回紹介するのは，1つはVisual Basicの実行形式ファイル（EXE）を使用して，データベースにアクセスする方法．もう1つはOLEISAPIを使用して，インプロセス動作としてデータベースにアクセスする方法である．どちらも，DAO（Data Access Object）を利用して，Jetデータベース（MDB）ファイルにアクセスする．JetデータベースエンジンがサポートするSQLステートメントや，Visual Basicのメソッド，関数が使えるので，IDCと比較して，かなり，柔軟な処理が可能である．ただ，IDCでサポートしているようなHTMLのテンプレートファイルを使用できないので，プログラムコードにHTMLのタグを埋め込むことになる．これは，あまり，洗練されているとは言い難いが，現時点ではやむをえまい．

　もちろん，Visual Basicで作成する関係上，OSはVisual Basicが動作する環境に限られる．

　今回，ファイル共有型データベースであるJetデータベースエンジンを使用するが，WEBデータベースシステムとして構築すると，完全なクライアントサーバー型のシステムとして動作する．ユーザーのリクエストによってプログラムモジュールはデータベースに処理を要求する．処理の結果をプログラムモジュールはIISに返答し，IISは処理ずみの結果だけをユーザーに返すことになる．つまり，ファイル共有はネットワークをまたがずにプログラムモジュールとIISの間でだけおこなわれており，サーバーとクライアントの間にファイルアクセスのためのトラフィックは発生しない（図1）．SQL ServerとJetデータベースエンジンの価格差を考えると，Jetデータベースエンジンが拡張言語つきのSQLデータベースサーバーとして動作する魅力は大きい．

図1 CGI-WEB-DBシステムと一般的ファイル共有DBシステム

　アウトオブプロセスの実行モジュールは，起動時に新しいプロセスを立ち上げるため，プログラムのレスポンスが悪くなる．また，同時にアクセスするユーザー数が多い場合にはメモリの不足を起こしやすい．ただ，今回試した限りでは，1回目のアクセスこそDAOがデータアクセスオブジェクトを生成するのに時間がかかるが，2回目からは十分なレスポンスが得られた．

　インプロセス動作のようにOLEオートメーションサーバーの設定なども必要なく，生成した実行モジュールをHTMLフォームのACTIONに指定しておくだけで動作するので，簡単にデータベースにアクセスする場合には有効である．

　今回，インプロセス動作のためのOLEISAPIモジュールには，MicrosoftがActiveXSDKからリムーブしたものではなく，アグレッシブ株式会社（http://www.aie.or.jp/extender）が開発したWeb Extenderを使用した．モジュールはサンプルつきのトライアル版を同社のサイトからダウンロードすることができる．この製品の優れた点は，処理中のクラスとメソッドを管理し，同じメソッドが再入しないようにメソッドの発行を待機させていることである．クリティカルセクションによるブロックをせずに再入を管理することにより，インプロセスサーバーの癖である，同じメソッドを呼び出した場合にメソッドが逆順に終了するという問題を回避している．逆順に終了するということがデータベースシステムでどういう影響を及ぼすか考えた場合，その対策が用意されていることは大きな意味を持つ．

　インプロセス処理はIISが起動しているプロセス内で処理されるため，アウトオブプロセスでプログラムを起動するよりも高速になる．また，その分のメモリ空間を節約することもできる．また，タスクスイッチの切り換えによるオーバーヘッドの発生や，プロセスが大量に生成されたときのサーバーの負荷の増大という問題もない．どちらが，より優れた方法と呼べるかは明白だが，作成したプログラムが何か問題を起こした場合，アウトオブプロセスの方がプロセスのシャットダウンで対応できるため，HTTPサービスに与えるダメージは少ない．

　WindowsNTのインターネットサーバーが主流でない現在では，Visual BasicによるCGIはインターネットよりも，イントラネットが主な利用の舞台となる．だが，今後も続くプロバイダの乱立やOCNによる一般企業のインターネットへの参加によって，保守の面でUNIXよりも有利なWindowsNTがWEBサーバーの主流になる可能性も考えられる．

　CGIを利用するためのモジュールとしては，前述のサイト（http://www.prplus.com/vb4cgi/）からダウンロードしたもの（CGI4VB）を利用する．記事の最後に記載したソースコードは，データベースアクセスするのに冗長な部分を削除し，2バイト文字列に対応したサブセット版である．CGIで環境変数を利用したい方はオリジナルを入手されたい（現在入手）．その場合Sendプロシージャだけを本誌掲載のものと入替えれば日本語に対応できる．

　標準入出力に対応していないVisual BasicでCGIプログラミングに対応するために，CGI4VBではファイルへの入出力をおこなっている．その他，フォームから転送されたデータを変数として簡単に利用できるようにGetCgiValue関数が用意され，HTMLのINPUTの名前を指定するだけで送信された値が取得できるように準備されている．

　CGIプログラムを作成するということは，実行した処理の結果をHTMLとして出力するということである．そのため，HTMLのタグに対する十分な知識が要求される．実際には文字列型変数にタグをセットしておき，プログラムの処理結果をその間に挿入していくという形になるだろう．

　ブラウザに返すHTMLを出力するのに，CGI4VBではユーザー定義のSENDプロシージャを使用する．SENDプロシージャはパラメータとして受けとった文字列を，HTMLの1行として文字列をセットしブラウザに送り返す．

　Cgi_Mainメソッド以外のモジュールは汎用なので，それらをプロジェクトファイルに加えておき，プログラマはCgi_Mainにプログラムを記述するだけでよい．他のモジュールの内容を理解しなくても，GetCgiValue関数とSENDプロシージャの使い方だけを理解していればいいだろう．

　図2,3はCGIを使って作った郵便番号検索プログラムである．入力項目に郵便番号を入力して「検索」ボタンをクリックすると，該当する住所がブラウザに表示される．また，入力項目の値をそのまま結果フォームに表示する実験として，2つの項目を追加している．

　このプログラムが社内のインターネットサーバーに上がっていれば，ネットワークに接続されているどのコンピュータからも郵便番号から住所を検索することができる．もっとも，実用という意味だったら，住所から郵便番号が検索できる機能の方が有用だろう．

図2：郵便番号入力画面

図3：郵便番号検索結果の表示

　リスト1のHTMLファイルの.FORMタグのACTIONに，VBCGI.EXEを指定している．これが，Visual Basicで作成CGIモジュールである．METHODにはPOSTを指定しているから，ユーザーが項目に入力した値は直接入力としてVBCGI.EXEに渡される．

<FORM ACTION="vbcgi.exe" METHOD="post">

　データベースにアクセスするための処理をするのがリスト2のプログラム本体である．このプロシージャでは次のような処理を実行している．

　このプログラムが作成したHTMLの結果が図3であり，HTMLのソースがリスト3になる．DAOの基本的な知識があれば，理解するのは難しくないはずである．今回は検索の結果を表示しただけだが，動的にHTMLを生成するときに入力項目を生成し，そのVALUEプロパティにデータベースの値を設定すれば，データベースの内容を修正するようなプログラムも作成可能である．

　ただ，WEBデータベースシステムはセッションの維持ができないため，編集操作をするときにはHIDDEN属性の項目を使って，そのクライアントのIDを常にサーバーが受けとれるような仕組みを作る必要がある．

　ここで説明するサンプルはWeb Extenderに同梱されてくるものである．基本的なプログラミングパラダイムは本誌前号でMr.Stealrideが説明していたOLEISAPIと変わらない．Web ExtenderはOLEISAPIの一種なのだから，当然である．ただ，環境変数の取得を変数として扱えるとか，デバック時に仮想的に実行環境を提供するなど，いくつかののツールが追加されている．OLEISAPIアプリケーションのデバッグは本来やっかいなので，上手に使いこなすことで開発効率があがるだろう．

　日本では一般的ではないが，米国ではOLEISAPIはサーバーアプリケーションの作成方法として開発者の間で注目され，WEBサイトなどでも活発な情報提供がおこなわれている．ISAPIアプリケーションはすべてインプロセスで動作するため，DLLファイルとして提供される．しかし，Visual Basicでは一般のDLLモジュールは作成できないので，Visual Basicでも生成できるOLEオートメーションサーバーのDLLを用いて，ISAPIアプリケーションを開発できるようにしたのがOLEISAPIである．

　図4のアプリケーションはWeb Extenderのサンプルのデータベースアクセスの部分である．入力項目にデータを入力し，「POST」ボタンをクリックすると入力したデータがMDBファイルに記録される．

　FORMタグのACTIONにOLEISAPIモジュールとOLEオートメーションサーバーを指定することで，データアクセスを実現している．ここではACTIONメソッド（リスト5）が呼ばれているが，ACTIONメソッドから，ユーザー定義のCreateResponse関数，SaveDbプロシージャ（リスト6，7）が呼び出される．

　また，入力項目下部のデータ表示リンクをクリックすると，ACTIONメソッドからCreateResponse関数，ActiveHtml関数（リスト6, 8）が呼び出され，MDBファイルにストアされたデータをHTMLファイルとして表示する．

　その他，クラスに含まれているCheckAuth関数，CreateCookie関数，CreateHeader関数はクラス作成のテンプレートモジュールと呼ぶべきもので，新しいモジュールを作成するときに汎用的に使用する．特に設定の変更が必要ない場合は手を加える必要はないので，記事の最後にコードをまとめて掲載する．

　まず，ボタンをクリックした場合のデータストアについて解説する．ACTIONメソッドから呼び出されたCreateResponse関数は，呼び出されたのがSUBMITによるものだと判断すると，SaveDbプロシージャを呼び出した後，データをデータベースに収納した旨のメッセージをクライアントに返す．

　SaveDbプロシージャ内では，次のような処理がおこなわれる．

　2番目の処理は，ブラウザがサーバーにデータを送信するときに，HTMLフォームに入力された全部のデータを特有の形式にフォーマットした1つのストリングに変換して送信するために，受信側で必要なデコード処理である．この処理は前出のCGI4VBでは，GetCgiValue関数とその前処理がおこなっている．

　次にデータを表示するプログラムは，ACTIONメソッドより，CreateResponse関数，ActiveHtml関数と呼び出され，ActiveHtml関数内でデータアクセスを処理する．

　DAOのメソッドでデータベースオブジェクトを作成した後，次のコードでHTML文にデータベースの内容を織り交ぜながら，文字列型の変数に代入している．

Resp = "<TABLE border = 1>" _
     & "<TR><TD>名前</TD><TD>" _
     & "電話</TD><TD>" _
     & "備考</TD></TR>"
  Do
    Resp = Resp & "<TR><TD>" & MyRec.Fields(0) & "</TD>"
    Resp = Resp & "<TD>" & MyRec.Fields(1) & "</TD>"
    Resp = Resp & "<TD>" & MyRec.Fields(2) & "</TD></TR>"
      MyRec.MoveNext
  Loop Until MyRec.EOF

最後にこの変数の内容をCreateResponse関数によって，クライアントに送信して表示すれば，データベースの内容をブラウザで表示できるというメカニズムである．

図4：Web Extenderサンプル画面

　もう気づかれたかと思うが，サンプルプログラムの違いがありこそすれ，アウトオブプロセスのCGIで書かれたプログラムも，インプロセスのISAPIで書かれたプログラムも，プログラミングの方法はまったく同じである．途中の入出力を経由する方法の違いがあるだけで，DAOでデータにアクセスし，プログラム内部でHTMLを合成するという方法には何の違いもない．

　開発をVisual Basicでおこなっても，Visualな開発はまったく不可能である．洗練されたツールもないし，デバッグには職人芸が要求される．それでも，CGIやISAPIアプリケーションをVisual Basicで作成できるのは，Visual Basicプログラマにとっては朗報である．

　また，Microsoftは「DENALI」という開発コードで呼ばれるサーバーサイドスクリプトの開発も進めている．これはVisual Basic Scriptを含むActiveX Scriptで，サーバー側のアプリケーションの作成をおこなおうというものである．プログラムファイルにはテンプレートとなるHTMLとVisual Basic Scriptプログラムが混在する．サーバーはプログラムが呼び出されるとVisual Basic Scriptを実行後，テンプレートを利用してHTMLを合成してブラウザに返す．いずれは，この方法がVisual Basicでサーバースクリプトを記述する最もメジャーな方法になるのかもしれない．

　しかし，我々は今日，稼動するプログラムを書かなければいけないのである．変化し続ける新技術を，いつまでも待ってはいられない．

リスト1：郵便番号入力フォーム

リスト2：郵便番号検索プログラムコード

リスト3：プログラムにより生成された結果画面

リスト4：Web Extenderサンプル画面のHTML

リスト5：Actionメソッド

リスト6：CreateResponse関数

リスト7：SaveDbプロシージャ（送信されたデータをDBに格納）

リスト8：ActiveHtml関数（テーブルの内容を参照し，HTMLに変換）

▼ CGI4VB日本語版サブセット　ソースコード

▼ Web Extender プログラム開発用　テンプレートコード

動作環境

ハードウェア：intel 486以上のCPUを搭載したコンピュータ／16MB以上のメモリ／3MB以上のハードディスク

ソフトウェア：Microsoft WindowsNT Server3.51 ServicePack4／Microsoft Internet Information Sever (IIS)／Microsoft Visual Basic 4.0 Professional Edition（またはインプロセスOLE DLLが作成可能な開発システム）

Visual Basic Magazine ライブラリ | Visual Basicコースホームページ
int21 ホームページ | PCDN ホームページ