ActiveX DocumentsとDCOMで変わるイントラネット
ActiveX DocumentsとDCOMで変わるイントラネット
Visual Basic 5.0では、Microsoftの提唱する一連のActiveX技術に対応したことが注目されている。これはすなわちインターネットやイントラネットへの対応でもある。ここでがぜん注目されるのがWindows NT 4.0から実装された分散OS環境を実現するDCOMである。DCOMとActiveX技術を組み合わせれば、従来は不可能だったWWWでのトランザクション管理が可能となり、柔軟なイントラネット構築への道が開けるのである。
ここでは、従来のイントラネットでの問題点を述べ、ActiveX Documents + DCOMでの次世代のイントラネット構築にチャレンジしてみよう。
酒井 法雄
Visual Basic 5.0の強化点で、もっともホットなのは、一連のActiveX技術を取り入れたことだろう。ActiveXはMicrosoftのインターネットに対応した一連の技術群の総称であり、単体のアーキテクチャーではない。しかし、そのほとんどは従来のOLE技術の発展形である。
OLE技術の心臓部をCOM(Component Object Model)と呼ぶが、これはプロセス間通信の仕組みである。COMで特徴的なのは、Automation(従来はOLE Automation)と呼ばれる関数呼び出し形式のプロセス間通信である。この仕組みを使えば、Visual Basicの言語仕様を拡張するような形で外部にあるコンポーネントを操作できる。ActiveX Server(OLE Server)やActiveXコントロール(OCX)も、この仕組みをベースとしている。そして目新しい名前のActiveX Documentsも、COMベースである。また、複数のマシン間でCOMの仕組みを実現できるDCOM(Distributed COM, 分散COM)もWindows NT 4.0からサポートされた。
前回の特集で、ActiveX Documentsの概要について述べたが、これはActiveX Serverの変種と見ることができる。言うなれば、IE(Internet Explorer)内で動作するActiveX Serverなのである。つまりは、Visual Basicで作成したアプリケーションが、WWWのプロトコルであるHTTPを通じてダウンロードされ、IE内部で実行される以外は、ふつうのアプリケーションと同じことができるのである。
ActiveX Documentsは、従来HTTPでは不可能と言われてきた数々の問題を解決する手段を内包している。つまり、新世代のイントラネット構築に有効なソリューションなのである。
ここでは、ActiveX Documentsと、DCOMを組み合わせたイントラネットシステムを比較的カンタンなサンプルプログラムを作って実現してみよう。そのためには、従来のイントラネットでどのような問題があったのかを知る必要がある。その上で、DCOMの仕組みや使い方を述べ、ActiveX Documentsと組み合わせてみることにする。
インターネット、イントラネット、さらにはエクストラネットという言葉が流行っている。もちろん言葉だけではない部分もあるのだが、どうも言葉だけが先走りしていて、その実体はなんだかわからないものだらけだ。ソフトウェアベンダーの思惑で妙な独自技術ばかりが取り上げられ、本当のインターネット、本当のイントラネットは何なのかが分からない状態になっている。まずは、これらの基本事項について確認しておこう。
図1:あまりに有名なOSIの７階層参照モデル
インターネットと聞くと、すぐにNetscapeだとかIEといったWebブラウザでネットサーフィン(ああ、なんて恥ずかしい言葉だ)をすることを連想する方も少なくないだろう。これは間違いである。インターネットとは、言わば電話線と同じような「線」である。トップダウンに言うならば、「異種の物理ネットワークを相互に接続するもの」であり、LANを世界規模に繋げたものがインターネットなのである。そこにあるのは線あるいは道路であり、通信をすることができる。このときの基本的なプロトコルはIP(Internet Protocol)と呼ばれ、その上位層にあるTCPやUDPと組み合わせてTCP/IPなどと呼ばれる。
つまり、TCP/IPというプロトコルをベースにした世界規模のネットワークこそインターネットなのである。
TCP/IPが初めて実装されたのは、UNIXから派生したBSD(Barkley Software Distribution)であり、間違ってもWindowsではない。
つまり、サーバー系について言うならば、今やタダで配布されているFreeBSDなどを使うのが一番正統なものであり、間違いがない。Windows NTでインターネットのサーバーを使う意味はほとんどない。管理がカンタンだとか教育がラクだというのはうそっぱちだ。現状のものでは、UNIXにある仕組みにGUIをかぶせたに過ぎず、UNIXでの知識があってこそ初めてちゃんと理解できる。そのため、上記のような理由でWindows NTベースでインターネット用サーバーを運用しているサイトに限って、ちゃんとした設定がされていない。インターネットでは、設定がきちんとできていないと他のサイトに迷惑をかけることになるので、このようなサイトが嫌われるのは言うまでもない。
TCP/IPは比較的低レベルなプロトコルであり、その上にさらにいろいろなプロトコルを実装する。これを一般にアプリケーション層プロトコルと呼ぶ。メールのSMTPやPOP、ネットニュースのNNTP、WWWのHTTPといったプロトコルはこれに当たる。つまり、WWWはこういったプロトコルの一つに過ぎないのである。
アプリケーション層プロトコルはいたってカンタンなものである。言うなれば、文字列でプロトコルを既定しているだけであり、「このファイルちょうだい」「はい、これね」といったような文字列での通信をするのである。
では、どれくらいカンタンかを、WWWを例にとって見てみよう。
通常、アプリケーション層プロトコルによって使われるポートは決まっている。HTTPは80番である。先に述べたように、アプリケーション層プロトコルは文字列の受け渡しで可能であるから、telnet.exeを使ってWWWサーバーに接続し、生の文字列のやり取りをすることができる。
コマンドプロンプトから、
telnet www.shoeisha.co.jp 80
と入力する、最後の80がポート番号である。これだけで、telnet.exeが起動され、指定されたサーバーに接続して待ち状態になる。ここから、
GET / HTTP/1.0
と入力し(エコーバックはされない)、さらにCtrl + Jを2回打つ。GETは、ファイルを送れ、/はファイルのパス、HTTP/1.0はおまじない、Ctrl+JはLFである。すると、図のようにWWWサーバーにあるルートのファイルが送られ、それと同時にセッションが切断される。
図2:ポート80にtelnetオープンしGETされる文字列
たったこれだけである。ここで送られてくるHTMLの文字列をどう整形するかはブラウザの仕事である。画面に必要なGIFファイルなどがあったときには、やはりブラウザが今手動でやったような接続とファイルの転送リクエストを繰り返し、全体の画面を作ることになる。
HTTPはこのように非常に単純なものであり、マルチメディアなどへの対応は、基本的にはブラウザがやるのである。JavaだのActiveXコントロールだの面倒な話も、こうして送られてきた分けの分からないデータをブラウザがMIME形式を判断し、プログラムと認識して実行するというだけの話なのだ。
静的なテキストだけではない。クライアント側からURLにCGI(Common Gateway Interface)と呼ばれるプログラムを指定すれば、サーバー側でプログラムが起動され、データベースなどにクエリーした結果をHTML形式にして返すこともできる。似たようなものに、HTML中に制御構文を埋め込むSSI(Server Side Include)と呼ばれるものもある。また、HTMLのFORM機能を使えば、クライアント側からデータをサーバー側に送ることもできる。つまりは、データベースへのアクセスが一通りは可能なのである。
このように大変拡張性のあるWWWであるが、その基礎となっているHTTPはこれだけのカンタンなものなのである。
HTTPはカンタンだが、WWWはそんなにカンタンではないこともできるのがメリットだ。つまり、インターネットという回転寿司の上には、HTTPという皿さえ置けば、どんな寿司でも回すことができるというようなものだ。海苔巻だけでなく、トロやウニもあるし、カリフォルニア巻だってある。世界中から様々なネタの寿司を喰うことができるのだから、これは楽しいし、流行るわけである。
図3:HTTPの概念
このようなインターネットの柔軟性に注目して、社内の業務にもインターネットの仕組みを使ってみようというのが、イントラネットである。トップダウンに言うならば、インターネット技術を社内で使おうということである。つまり、TCP/IPベースのSMTPやNNTP、HTTPなどを使うことこそイントラネットなのであり、WWWだけがイントラネットではない。メールやネットニュース、さらにWWWとの組み合わせで、従来はグループウェアと言われていたような業務や、データの共有や販売管理なども可能になるのである。
言うなれば、回転寿司のメカニズムを使って、皿の上にスケジュール表や売上伝票を載せてしまおうということなのである。
ちなみに、イントラネットと同じ一部のデータを外部にも公開する、つまりインターネットにも繋げてしまおうというのがエクストラネットというものだ。
では、従来のLotus Notesなどを使ったグループウェアや、C/Sベースでのデータベースアプリケーションではなく、なぜイントラネットなのだろうか。ここまでイントラネットにこだわるメリットは何なのだろうか。
これは、よきにつけ悪きにつけ、カンタンだということにほかならない。
C/Sなどの仕組みでは、クライアント側に専用のプログラムやミドルウェアが必要である。しかし、イントラネットならば汎用のWebブラウザさえあればよい。つまり、インストールやメンテナンスベースでのコストを削減できるのである。サーバーにあるファイルやCGIなどのプログラムを変更するという一極集中型なのである。もし、プログラムに変更が必要でも、サーバー側だけを修正すればよいのである。C/Sで言うところのストアドプロージャのようなものである。これは、図のような3階層システムであると言える。
図4:WWWを使った3階層モデル
HTTPベースのイントラネットには、もう一つカンタンである点がある。それは、複雑なことができないというものである。つまり、HTTPは、HTMLとCGIやSSIでどんな面倒なことをしようとも、しょせんは一つの画面を送るということしかできないのである。つまりは、たいした面倒なことはできないので、データベースへのアクセスといったところで、そんなに難しいことはしようがないのである。
たとえば、一つの画面のままで、クエリーを何度もしたり、ボタンを押した瞬間にどこか一部だけがデータベースともども書き換えられ処理は継続できる、特殊なコントロールが使えるといった、C/Sではごく当たり前のことができないのだ。必ずページ全体が書き換えられ。使えるコントロールはごく基本的なものだけなのである。
これはデメリットであるとも言えるが、比較的カンタンなシステムを作る上ではメリットとも言えるものである。難しくしようがないからカンタンなのである。
ところで、さきほどのtelnetでの画面を思い出してほしい。サーバー側からデータが送られると同時にセッションは切られてしまった。つまり、HTTPは一回データを送ったら、そこでセッションが切れてしまうのである。これでは、トランザクションができない。これも本格的な(?)イントラネット、つまりC/Sからのリプレースを考えるならば、致命的な問題である。
話を一度まとめてみよう。
WWWはインストールやメンテナンスのコストがかからないことがメリットだ。
しかし、イントラネットがC/Sに置き替わるためには問題がある。
1つはHTMLの問題だ。HTMLはしょせんページ記述言語であるため、送られてくるのはページにすぎない。クライアント側だけでインタラクティブな動作をさせることはできない。
2つめはHTTPの問題だ。HTTPはセッションの継続ができないため、ステートレスでありトランザクションができない。1つめの問題と組み合わせると、インタラクティブな連続した作業をスムーズに行うことはできない。
こうした問題を解決するために、ここ2年ほどの分けの分からない新技術のオンパレードという事態が発生している。
しかし、あらかじめ述べておくと、こういった問題に目をつぶれば、つまり適材適所という当たり前のことを考えれば、今までの仕組みで十分なのである。面倒なことをわざわざする必要はないのである。こういった結論を出してしまうと、話が続かなくなるので、あえて面倒な話に進むことにしよう。
では、2つの問題を解決するために提案された技術について述べる。
インタラクティブな操作性を実現するためには、クライアント側、つまりWebブラウザ内でプログラムが動けばよい。これには大きく分けて二つの方式がある。
一つはHTTPでプログラムをバイナリで送ってきてブラウザ内で動作させるという方法である。これには、JavaやActiveXコントロール、ActiveX Documentsなどがある。
2つめは、HTML中にプログラムをテキストで埋め込む方式である。これには、JavaScriptやVBScript(Visual Basic for Scripting Editon)がある。
いずれも、それぞれの技術に対応したWebブラウザが必要となる。そして、いずれもMicrosoftは後追いする形で技術を発表しており、ある意味ではマネッコである。
Javaがあれほど騒がれたのは、サーバーから機種依存しないバイナリのプログラムを送ってきて、ブラウザでそのプログラムを実行できたからである。つまりプラットフォームを問わないソフトウェア開発が可能になったということである。反Microsoftのベンダーとしては、こんなラッキーな仕組みはない。しかし、現実的なプログラムを作るには、どうしてもプラットフォームに依存したことや、ファイル操作などができないと困るわけで、セキュリティ重視のJavaでは問題があるのも事実である。
ActiveXコントロールはOCXのインターネット対応であり、ActiveX DocumentsはOLE Serverのインターネット対応である。したがって、プラットフォームは今のところWindowsに限定されるものの、何でもできる柔軟性と、何でもやられてしまう危険性を持っている。
せっかくのうまい寿司を熱湯消毒してしまうのがJavaで、そのまま喰って食中毒になるかもしれないのがActiveXであると言えるだろう。
Java ScriptやVBScriptはHTML中に埋め込む言語である。これはFORMなどのプリチェックには有効だが、実はたいしたことはできない。たいしたことをやろうとすると、ブラウザによる動作の違いや、同じブラウザでもプラットフォームによって動作が異なることがあり(これはJavaにも言える)、実用に耐えない。しかし、これらのスクリプト言語からは、JavaやActiveXコントロールなどの制御をすることができるのは面白い点だ。ところが、デバッグ環境が整っていないこともあり、とても使い物になるようなものではない。また、HTML、JavaまたはActiveXコントロール、JavaScriptまたはVBScriptという複数の言語を知らなくてはならないのも問題である。はっきり言って、そんな面倒なことはやっていられない。
こう考えてくると、これらの方法でイントラネット用で将来性があるのは、プログラムがそのまま動けばよく、HTMLなどはほとんど書く必要がないものでなければならない。となると、現状ではセキュリティはともかくVisual Basicで何でも書けてしまうActiveX Documentsが一番の有望株ということになるのである。
ただし、これはセキュリティを考慮していない結論であるから、インターネットで使おうなどとは思わない方がよい。イントラネットという東京湾で取れた近海物の寿司はそのまま喰いたいが、インターネットという回転寿司ではどこでいつ取れたのか分からないような怪しいネタもあるのだ。
トランザクションができないという問題は、HTTPにとって致命的だ。これを解決するためには、次の二つの方法がある。
1つめは、Cookieと呼ばれる変数をブラウザに送りつけ、次に接続したときに内容を比較してセッションを継続するというものだ。しかし、これはサーバー側でのCGIプロセスを生かしたままにしなくてはならないなど、作り込みに問題がある。Oracle Web Server (次期バージョン3.0)ではCookieを使ったセッション継続が可能になる。
2つめは、別のプロトコルでセッションを張り、継続しようというものである。つまり、別のセッションを張るためにはプログラムがクライアント側で動かなくてはならない。となると、JavaやActiveX Documentsなどで通信をさせる必要がある。この通信は何でもよい。TCP/IPを使って独自のアプリケーション層プロトコルを作っても良い。実はそれだけの話であるが、Visual Basicユーザーにとっては、なるべくカンタンに実現できた方がよいだろう。
そこで出てくるのが、DCOMである。DCOMは異なるマシン間でAutomationを実現するものである。ActiveX DocumentsもVisual Basicで作れるわけだから、すべてVisual Basicだけで済んでしまうというわけだ。Visual Basicユーザーならば、これを使わない手はないと考えるだろう。
では、次にDCOMについて述べることにしよう。
OLEのメカニズムがネットワークで接続された他のマシンに対しても有効になると、他のマシンにあるActiveX Serverを利用できるということになる。ここで言うActiveX Serverとは、WordやExcelのようなものではなく、Visual Basicで作成したAutomation Serverのことである。つまり、なんらかの計算などの処理を他のサーバーマシンにさせて、その結果をクライアント側で得るというものである。SQL ServerなどにSQL文を送って複雑な処理をさせて結果を受け取るというのと同じようなものだと考えればよい。
このようなメカニズムは、DCOM以前にも、Visual Basic 4.0にRemote Automationという名前で用意されていた。(図5) この仕組みは通常はローカルマシン内で起動されるActiveX Serverを、COMのメカニズムを言葉は悪いがちょっと騙してネットワークに接続されたマシンにあるActiveX Serverにしてしまうというものである。この騙す仕組みとして、RemAuto接続マネージャが用意されていた。（図6)また、サーバー側にはこうして接続要求があったときに答える窓口としてAutomationマネージャを起動しておく必要があった。
図5:Remote Automationの概念
図6:リモートオートメーション接続マネージャ
Visual Basic4.0のリモート接続マネージャではリモートマシンにあるActiveX Serverを接続させる
ことができた
図7:Automation Manager
サーバー側にはAutomation Managerを起動する必要があった
この騙すメカニズムが問題である。これには、少々ActiveX Server自体の仕組みの説明が必要だ。 ActiveX Server(ActiveXコントロールやActiveX Documentsも、ActiveX Serverの一形態である)には、Class IDと呼ばれる番号がある。これはそのActiveX Serverを作成したマシンに装備してあるネットワークカードのMacアドレスをベースにして作成されるもので、世界に唯一つしかないIDである。 （図8）
図8:レジストリに登録されているNetworkアドレス
ActiveX Serverには自由に名前をつけられるが、実際に内部のメカニズムでサーバーを判断する材料として使われるのは、このClass IDである。
CreateObject関数などでActiveX Serverのクラス名を指定しただけなのに、ちゃんとそのActiveX Serverが起動されるのは、システムにActiveX Serverの情報が登録されているからである。実際には、レジストリデータベースにこの内容は登録されている。regedit.exeまたはregedt32.exeを起動すれば、このレジストリデータベースの内容を調べることができる。クラス名で検索すると、HKEY_CLASSES_ROOTにそのClass IDを発見することができる。そこからさらにClass IDをキーに検索すると、そのActiveX Serverについての情報を得ることができる。ここに、そのActiveX Serverのパスなどの情報が含まれているのである。CreateObject関数が実行されると、この手順でパスを調べてActiveX Serverを起動するわけだ。Visual Basicの参照設定や、使用するActiveXコントロールの指定なども、同様のメカニズムで動作しているのである。
Remote Automationでは、RemAuto接続マネージャで、このClass IDのレジストリのサブキーとしてNetworkAddressなどを追加し、ここにサーバーマシンの名前などの情報を格納しておくのである。こうして、本来ならばローカルマシン上にあるはずのActiveX Serverを、他のマシンで動かすような騙しのメカニズムを搭載したワケだ。
しかし、結論から言うと、このRemote Automationは成功しなかった。あくまでもDCOMへの布石というようなデモンストレーションだったのである。では、何がいけなかったのであろうか?
問題はいくつかある。まず、インストールやメンテナンスがたやすくないことだ。つまり、リモートマシンにだけActiveX Serverがあればいいはずなのに、クライアントマシンにもそのレジストリ情報が必要になるのである。そして、RemAuto接続マネージャで設定をしなくてはならない。
また、ActiveX Serverの名前解決には、クラス名さえ合っていればよいはずだから、ActiveX Serverを修正したときにもクライアント側のプログラムに変更は必要はないのだが、Class IDは変わってしまう。したがって、レジストリの内容はその都度変更する必要がある。
また、ActiveX Serverが増えてきたときに効率的に管理する手法がなかった。
Microsoftはこのようなときに対処するためにツールを用意してあったが、それは未完成で使い勝手の良いものではなかった。
そもそも、こういった分散環境を構築する上でのノウハウは誰も持ち合わせていなかったのである。つまり、Remote Automationは、DCOMまでにそういった開発スタイルを練習しておきましょうといったものだったのである。
Windows NT 4.0では、この分散オブジェクト環境が、OSレベルでサポートされた。そして従来はネットワークOLEと呼ばれることになるハズのこの機能は、DCOMと呼ばれることになった。
では、Remote AutomationとDCOMの違いとは何なのだろうか? 内部的には、そして機能的にも大幅な違いがある。しかし、単純に言ってしまえば、OSレベルで分散オブジェクトをサポートしたということが違いであると言えるだろう。
ただし、Service Pack2以降がインストールされていないと、DCOMまわりは正常に動作しないので注意が必要だ。また、Windows 95用のDCOMモジュールのβ版もすでにリリースされているが、これは環境を目茶苦茶にしてしまうことがあるし、そもそもセキュリティの概念など皆無なWindows 95でDCOMを使うこと自体がナンセンスである。したがって、DCOMはWindows NTで使うべきものだと考えてほしい。
Windows NTのOSレベルでサポートされたため、従来のRemAuto接続マネージャ相当の、DCOMCNFG.EXEが含まれている。ただし、これはアイコンとして登録されているわけではないので、Windows NTのSystem32フォルダーから起動して使うことになる。
DCOMCNFG.EXEを起動すると、図のような画面になる。(図9)
ここではアプリケーションタブが選ばれており、例によってシステムに登録されているActiveX Serverの一覧が表示される。なお、Visual Basic 4.0で作成されたActiveX ServerのときにはClass IDとしてしか表示されない。
既定のプロパティでは、DCOMを使うかの選択および、認証レベルと偽装レベルの設定などを指定することができる。
既定のセキュリティからは、デフォルトのアクセス権、起動アクセス権、構成アクセス権についての設定ができる。
<既定値の編集>ボタンを押すと、図のようなダイアログが開く。ここで<追加>を選ぶと、ドメインのACLが表示される。この図は既定の構成アクセス権のときのものであるが、クライアントのユーザーにフルコントロールの権限を与えていないと、正常にアクセスできないので注意が必要だ。 <既定値の編集>ボタンを押すと、図のようなダイアログが開く。ここで<追加>を選ぶと、ドメインのACLが表示される。この図は既定の構成アクセス権のときのものであるが、クライアントのユーザーにフルコントロールの権限を与えていないと、正常にアクセスできないので注意が必要だ。
先ほどのアプリケーションタブから<プロパティ>ボタンを選ぶと、図のようなウィンドウが新たに開く。全般タブでは現在の設定が表示される。
場所タブを選ぶと、このActiveX Serverをどこで実行するかを選ぶことができる。
セキュリティタブでは、個別にアクセス権を設定できる。
識別タブでは、実行するときのユーザーアカウントを指定する。これは、このマシンで起動されたときのものである。つまり、他のマシンのActiveX Serverを起動するときには、そちら側のマシンで設定する必要があるということだ。このとき、対話ユーザーを選ぶと誰もログオンしていないマシンでは実行されないので注意が必要だ。また、対話ユーザーを選んだときには、ユーザーインターフェイスを持つサーバーのウィンドウは表示されるが、そうでないときには表示されずにプロセスだけが起動される。実行を確認するためには、タスクマネージャでプロセスを表示させる必要がある。
残念なことに、これらのプロパティやセキュリティといった設定についての詳細な情報はWindows NTには附属していない。ヘルプを見てもたいしたことは書いていないのである。MSDNなどにある英語のドキュメントやMicrosoftのWWWサイトなどから情報を集めるしかないのが現状である。私も動作確認のためになるべくセキュリティを甘くしている。そうでないと、ちょっとしたことで動かなくなるからである。
以上が、Windows NT 4.0附属のDCOM設定ツールだが、Visual Basic 5.0のRemAuto接続マネージャも、DCOMに対応した。図はその起動画面である。クライアントアクセスについては基本的に変更はない。
ACLを元にしたリモート許可についてもほぼ同様である。
サーバー接続については、DCOMとRemote Automationのいずれかを選択することができ、DCOM時にはネットワークプロトコルと認証レベルの指定はできない。DCOMは適切なネットワークプロトコルが使われる。認証レベルについては、DCOMCNFG.EXEの値が使われるものと思われる。
危険なのは、このRemAuto接続マネージャを使ってしまうと、動作がおかしくなることがあることだ。DCOMCNFG.EXEだけで設定したときには問題が起きないのだが、これと併用すると、うまく動かなくなることがある。このあたりの動作が設定によるものなのかバグなのかははっきりしないが、DCOMCNFG.EXEだけを使うことをお勧めしておく。
なお、DCOM使用時には、Automationマネージャは必要ない。
ここでは、DCOMの動作をテストするために、カンタンなプログラムを作ってみた。と言っても実はこれは以前にVisual Basic 4.0のRemote Automationのテストに作ったものであるから、読者諸氏には見覚えのあるものかもしれない。 このプログラムは、Windows API GetComputerName, GetUserNameを使って、コンピュータの名前とログオンしているユーザー名、さらにApp.Pathでアプリケーションのパスを得るというものである。それぞれの値を返すメソッド作成し、外部に公開したサーバーEnvSrvと、それを呼び出すEnvCliから構成される。実際には何回呼び出されたかも返すようにしてあり、サーバー側では呼び出された時刻を表示するフォームを用意してある。
EnvSrv.EXEは、ActiveX Server EXEとして作成する。これでレジストリに登録される。そのままクライアントマシンで実行を確認したら、このEXEをサーバーとなるマシンCONTAXにコピーし、そこで実行した。これでレジストリが作成される。なお、引数をつけて実行すると、レジストリに登録あるいは削除だけすることもできる。
DCOMCNFG.EXEを使って適切にサーバーマシン名やセキュリティを設定し、クライアントマシンから実行すると、図のようにサーバーマシンの名前およびそのマシンにログオンしているユーザー名、そのマシンにインストールされているパス名が取得できる。
手間としては、オートメーションマネージャを起動しておく必要がないこと、RemAuto接続マネージャでプロトコルなどを指定しておく必要がないことなどから、DCOMの方が設定はカンタンである。ただし、先に述べたようにセキュリティなどの設定が適切に行われていないとうまく動作しないので注意してほしい。また、Windows 95用のDCOMモジュールでも動作を確認した。
Remote AutomationやDCOMといった分散オブジェクト環境を作ることができることは分かった。では、実際にこれを使うとどのようなメリットがあるのだろうか。イントラネットとは別の視点で考えてみよう。
もちろん、すでに述べたように負荷分散できることはメリットである。しかし、もう一歩現実的なシステムとして、3階層システムが上げられる。これは、次の3つの層に分けて負荷分散させようというものである。
ユーザーインターフェイスだけを持たせ、内部処理の重要な部分は持たない。Visual BasicでOLEコンテナとして実現する。
ユーザーインターフェイスは持たず、ビジネスロジックなどの演算部分だけを担当する。必要に応じてデータアクセス層とやり取りをする。Visual BasicでActiveX Serverとして実現する。
データベースの管理をする。SQL ServerやOracle Serverなどである。
このようにすると、ビジネスルール層はあたかも大変柔軟でかつVisual Basicで書けるストアドプロシージャのような役割をさせることができる。もし、消費税率などに変更が生じても、ビジネスルール層を書き換えれば、クライアント側の変更は必要ない。つまりクライアント側プログラムの再インストールが必要ないといったメリットがあるのである。
また、クライアントプログラムにはデータベース用のミドルウェアやライブラリも必要なくなることも大きなメリットである。
しかし、先に述べたように、ビジネスルール層であるActiveX ServerのリビルトによるClass IDの変更の影響をクライアント側で受けてしまうことは問題だ。
前回の特集で、ActiveX Documentsの使い方は分かった。そしてDCOMの動作も確認できた。これで役者は揃ったわけだ。いよいよイントラネット用アプリケーションを作成することを考えよう。
では、実際にどのようにすればよいのだろうか。ここで、先ほどのイントラネットの問題を振り返ってみたい。イントラネットでは面倒なことができないことが、メリットでもありデメリットでもあった。それでは、面倒なことをしたいのであれば、C/Sをベースに考えて、クライアントプログラムの効率的な配布方法を考えればよいだけの話ではないだろうか。そう考えると、話は分かりやすい。つまり、従来のC/Sの仕組みをベースに考えて、クライアントプログラムの配布をWWW経由にしてしまうのである。これなら、WWW配布でのメンテナンスの良さを活かすことができるハズだ。つまり、従来のC/SシステムのクライアントプログラムをActiveX Documentsとして作成してしまえば良いというワケである。
しかし、それでも問題は残る。従来のC/Sのクライアント側には、ミドルウェアが必要になる。単にWebブラウザがあればよいというわけにはいかない。やはりインストールに手間がかかってしまうのである。
では、ミドルウェアをなくするためにはどうしたらよいだろうか? それはOSが標準で用意している通信手段を使って、それをミドルウェアとしてしまえばよいのである。たとえば、TCP/IPを使って独自のアプリケーション層プロトコルを作り、そこで通信させてしまう方法が考えられる。これはそれなりにセキュリティなどを考えて作り込みが必要になる。もっと手軽にやろうとするならば...そう、DCOMがあるではないか。
つまり、DCOMをベースとした3階層システムを作り、クライアントプログラムをActiveX Documentsとするのである。WWWと階層システムの融合こそ、従来のイントラネットの限界を超えるものであり、そのキーとなるものはActiveX DocumentsとDCOMなのである。
すべての問題が解決したように思えるが、実はまだ問題が残っている。それは、3階層システムのクライアント側には、ActiveX Serverのレジストリ設定をしなくてはならないということである。これを解決するには、2つのアプローチが考えられる。
サーバーのClass IDなどのレジストリ情報をレジストリに直接書き込む方法である。Visual Basicに内蔵されているレジストリ操作メソッドは、Visual Basicの管理するレジストリの下にのみアクセスできる。つまり、Private INIファイルのような使い方しかできない。そこで、Windows APIを使って管理することになる。
ActiveX Serverのクラス名やClass IDおよびその下にあるさまざまな情報を、サーバーが変更されたときに自動的に変更するとしたら、そのようなプログラムを適切なタイミングで実行しなくてはならない。これは少々面倒である。さらに、ActiveX Documentsがダウンロードされて実行されるタイミングで行うのも面倒そうだ。
実は、Visual Basic 5.0のSetup Wizardには、リモートサーバーを使うときの設定がある。これは、.VBRファイルを指定し、さらにリモートマシン名を指定するといったものである。これを使ったActiveX Documentsのセットアップを作れば問題は解決しそうだ。しかし、調査したところ、標準EXE以外ではこの設定は正しく動作しなかった(NT4.0 SP2使用時。SP3での動作は確認していない)。となると、やはり別途にプログラムを作り、非同期で動作させるか、ActiveX DocumentsのInitializeなどのイベントで設定するかのいずれかになるだろう。
>
このように考えてくると、2つめの方法が確実で効率的であろう。
すべての問題は解決した。Visual Basic 5.0とWindows NT 4.0が可能にした、Microsoftの提唱するイントラネットシステムを構築する準備は整ったのだ。
比較的カンタンに検索とクエリーをするプログラムを作って、動作を確認してみることにしよう。ここでは、SQL Serverをデータアクセス層とし、サンプルデータベースのPubsのauthorsテーブルから部分一致検索で複数の候補をリストボックスに表示し、そこから選ばれたものの詳細データが表示されるものとした。
アクセスはRDOを使い、外部には次のメソッドを公開する。(表1)
| GetCnames | すべてのカラム名をTABで区切った一つの文字列として返す |
| GetLnameメソッド | authorsテーブルから苗字(au_lname)に部分一致するものを、CRで区切った複数データを1つの文字列として返す。 |
| GetAuthorsメソッド | 引数au_idに相当するIDのデータをTAB区切りにして一つの文字列として返す |
ClsSQLを元にしたActiveX Serverに接続して必要な処理を行う。データアクセスをするものであるが、そのロジックはサーバー側にあり、このプログラムの実行にはODBC設定やRDOは必要ない。 サーバーオブジェクトの作成は、CoCreateInstanceEx関数を呼び出すようにカプセル化されたCreateObjectEx関数で行う。この関数は、microsoft.comのDCOM Mailing Listにあったもので、オリジナルの著作権はmailto:Charlie Kindel <ckindel@MICROSOFT.COM>にある。
動作:
起動時には、すべてのカラム名を取得し、コントロール配列となっているラベルを動的に必要なだけ増やし、Captionをカラム名にする。
ボタンが押されたら、テキストボックスに指定された文字列を部分一致で検索して、リストボックスに一覧する。
リストボックスから一つの項目が選ばれたら、その詳細データを得、テキストボックスに表示する。
このプログラムは、まずはクラスモジュールを含んだスタンドアローンとして実行し、動作を確認した後、ActiveX Serverとコンテナに分割する。実行例を図に示す。
動作を確認したら、ActiveX Document Micration Wizardを使って、ActiveX Documentsに変換する。インタープリタとIEで動作を確認したら、セットアップウィザードでインターネットセットアップを作成すればよい。
実行結果を図に示す。
このようにして、IEからも新たなページをサーバーから送らせることなく、インタラクティブな検索システムを構築することができた。ActiveX DocumentsとDCOMの組み合わせは強力である。WWWだけでページが送られてくるものに比較すると、最初の起動こそ遅いものの、その後の操作性は実にスムーズであり、C/Sそのままの使い勝手を実現することができた。
もう一つの問題であるトランザクションも、同様の手法で可能であることは言うまでもない。ただし、トランザクションが必要なときにも、クライアント側とビジネスルール側間でトランザクションをするのは感心しない。というのも、当然ながらトランザクション中は他のクライアントからはロックされていてアクセスすることができなくなってしまうからだ。悠長にWWWブラウザで操作をしながらトランザクションをすることは考えにくい。
ビジネスルール層にトランザクションする一連のコードを記述し、必要なパラメータを装備したメソッドとして実装するべきだろう。そうかんがえると、WWWでトランザクションができないと言っていたこと自体がナンセンスであったように思えてくる。たしかに、そういうことが必要な場面もあるかもしれないが、そうでないことの方が多いのではないだろうか。むしろ、3階層システムと組み合わせられたために、その必要はなくなるパターンがほとんどだと思われる。
WWW + 3階層システムを実現したActiveX Documents + DCOMは、イントラネットにおける最新で現実味のあるソリューションである。しかも、最近のあまりにも複雑化した複数アーキテクチャーの中では、比較的単純に実現できるものであり、かつVisual Basicプログラマーにとっても敷居は低いものだ。いや、むしろVisual Basicプログラマー向けのソリューションとも言えるだろう。
しかし、原稿執筆時ではDCOMについての資料が不足しており、またActiveX Documentsの動作もときどきおかしくなる。現実的な開発をはじめるには、もうちょっと待った方がよさそうではある。しかし、ビジネスルール層を管理するTransaction Serverも発売されたこともあり、数あるイントラネットソリューションの中にあって、これは確実にモノになりそうで、かつ汎用性のあるものである。
近い将来、「イントラネットよりやっぱり分散オブジェクト環境だ」ということになったとしても、移行はカンタンだ。ActiveX Documentsを使わないで、ふつうのEXEのままで止めればよいだけなのである。Microsoftは目先のインターネット/イントラネットへの対応に追われていたように見えて、実は確実に従来からの分散オブジェクトへの技術の蓄積をしてきたのだ。目まぐるしい変化があるこの業界だが、Visual Basicプログラマーは、このあたりをしっかり押さえておけば、当分安泰ということになりそうだ。
