この特集のトップページへ
＞
Chapter 4：データストア層の構築
4.4.4 プロキシのインストール
作成したプロキシのセットアップファイルは，Windows Installerの形式になっている。Windows Installerとは，Windows 2000に標準搭載される予定の新しいセットアップメカニズムであり，このメカニズムに対応したセットアップファイルは拡張子“.msi”となる。Windows Installerは，Windows 95やWindows 98，Windows NT 4.0でも追加モジュールとして用意されており，たとえばMicrosoft Office 2000はWindows Installer形式でインストールされる。
作成したプロキシのセットアップファイルを利用する方法は，クライアントに導入されているOSがWindows 2000であるかそれ以外のOSであるかによって異なる。
○Windows 2000の場合
Windows 2000の場合には非常に簡単で，生成されたプロキシのセットアップファイルをダブルクリックして実行するだけである。
プロキシが正しくインストールされたかどうかは，［コンポーネントサービス］管理ツールから［コンピュータ］−［マイコンピュータ］−［COM＋アプリケーション］の配下を参照することで確認できる（Fig.4-45）。
Fig.4-45 インストールされたプロキシ
もしプロキシをアンインストールしたいのであれば，プロキシのセットアップファイルを右クリックし，表示されるメニューから［アンインストール］を選択する（Fig.4-46）。
Fig.4-46 プロキシのアンインストール
プロキシをアンインストールするとき，［コンポーネントサービス］管理ツールの画面（Fig.4-45）で該当するCOM＋アプリケーションを削除してもよい。
プロキシをインストールすれば，すぐにそのCOM＋アプリケーションに含まれるCOMコンポーネントは利用可能になる。たとえば，List 4-3などを実行し，リモートのCOMコンポーネントを実行できることを確かめてみるとよい。
実行できない場合には，適切な実行権限がないことも考えられるが，もう1つの理由としては，サーバー側とクライアント側で利用しているプロトコルが違うこともあり得る。Fig.4-39を参照し，サーバー側とクライアント側で同じプロトコルをサポートしているかどうかを確認してほしい。
エラーがあった場合には，「4.3.5 権限を持たないCOMオブジェクトの呼び出し」で説明したとおりイベントビューアに記録されるので，それを手がかりに問題を解決するとよいだろう。
○Windows 2000以外のOSの場合
Windows 2000以外のOSを利用する場合には，あらかじめOSにWindows Installerを組み込んでおく必要がある。
Windows 95やWindows 98の場合には，事前にそれぞれDCOM95やDCOM98を導入しておかなければならない。DCOM95やDCOM98は，Microsoft社のCOMのページ（http://www.microsoft.com/japan/com/）からダウンロードすることができる。
Windows Installerの実行モジュールは，http://msdn.microsoft.com/developer/sdk/wininst.aspからInstMsi.exeとしてダウンロードすることができる。利用するOSに適したコンポーネントをダウンロードして実行すれば，Windows 95，Windows 98，Windows NT 4.0にWindows Installerの機能を追加することができる。
Windows Installerは，バージョン1.1以降でなければならない．Microsoft Office 2000をインストールしたときには，自動的にWindows Installerもインストールされるが，そのバージョンは1.0である．
Windows Installerをインストールしたならば，コンポーネントサービス管理ツールのエクスポートウィザードで作ったプロキシのセットアップファイルを実行する。すると，プロキシがインストールされる。プロキシをアンインストールするには，Windows 2000の場合と同様に，プロキシのセットアップファイルを右クリックし，表示されたメニューから［アンインストール］を選択すればよい（Fig.4-46参照）。
プロキシがインストールされれば，リモートのCOMコンポーネントを利用することができる。List 4-3を実行し，実際にCOMコンポーネントを利用できるかどうかを確かめてみるとよいだろう。
Windows 2000でCOM＋の管理下にあるCOMコンポーネントの設定を変更するには，［コンポーネントサービス］管理ツールを使うわけだが，Windows 95，Windows 98，Windows NT 4.0には，［コンポーネントサービス］管理ツールは存在しない。そこで，これらのOSでリモートのCOMコンポーネントの呼び出し方法の設定を変更したいときには，代わりにdcomcnfgツールを利用する。dcomcnfgツールでは，リモートのアプリケーションを「アプリケーションID（AppID）」という値で区別する。そこで，事前にWindows 2000の［コンポーネントサービス］管理ツールで，エクスポートしたCOM＋アプリケーションのアプリケーションIDを調べておく。アプリケーションIDは，COM＋アプリケーションのプロパティページの［全般］パネルで参照できる（Fig.4-47）。
Fig.4-47 アプリケーションID
アプリケーションIDがわかったら，プロキシをインストールしたコンピュータ上でdcomcnfgツールを実行してみよう。dcomcnfgツールには特にショートカットは用意されていないので，［スタート］メニューから［ファイル名を指定して実行］を選んで，dcomcnfgと入力して実行することになる（Fig.4-48）。
Fig.4-48 dcomcnfgツールの実行
dcomcnfgツールを実行すると，Fig.4-49に示す画面が表示される。画面には，［アプリケーション］，［既定のプロパティ］，［既定のセキュリティ］，［既定のプロトコル］という4つのページがあるが，このうち［アプリケーション］のなかに，Fig.4-47で調べたアプリケーションIDを見つけることができるはずである。そのアプリケーションIDをクリックして［プロパティ］ボタンを押すと，Fig.4-50の画面が表示され，どのようにしてサーバーに接続するかを変更することができる。
Fig.4-49 dcomcnfgツール
Fig.4-50 アプリケーションのプロパティを構成する3つのページ
一般的には，dcomcnfgツールを使ってクライアント側の設定を変更する必然性はあまりないが，実行するサーバー名が変わったときや，COM＋のサポートするプロトコルと違うものが設定されているような場合には，アプリケーションのプロパティを変更する必要があるかもしれない。
ところで，「COM＋はWindows 2000の新機能であるはずなのに，なぜWindows 95やWindows 98，Windows NT 4.0から利用できるのか」と不思議に思われる読者もいるかもしれない。その答えは簡単である。コンポーネントの通信に利用するネットワーク通信プロトコルであるDCOM自体は，COM＋でも特に変更されていない。つまり，Windows 2000におけるDCOMは，Windows 95，Windows 98，Windows NT 4.0と同じものなのである。間違えてはいけないのは，Windows Installerのインストールによって，Windows 95やWindows 98，Windows NT 4.0にCOM＋の機能が加わったわけではない，ということである。よって，プロキシをインストールしたからといって，Windows 95やWindows 98，Windows NT 4.0でCOM＋の機能が使えるようになったわけではない。
プロキシは，あくまでもWindows 2000上のCOMオブジェクトを呼び出すだけの機能しか持たない。そして，COM＋の機能を利用したCOMコンポーネントは，サーバーであるWindows 2000上でのみ動作する。けっしてクライアント側で動作するわけではない。よって，ビジネスアプリケーションプラットフォームとしてWindows 2000を選択し，COM＋で追加された新機能をふんだんに使ってアプリケーションを構築したとしても，それがサーバー側でのみ動作するのであれば，クライアントはWindows 95やWindows 98，Windows NT 4.0であってもかまわない。
費用や手間などを考えると，Windows 2000が登場したからといって，クライアントが一斉にWindows 2000に移行されることはないだろう。ビジネスアプリケーションを構築するときに，COM＋の機能を使ったCOMコンポーネントをサーバー側だけでしか動作させない設計にしておけば，クライアントはWindows 95やWindows 98，Windows NT 4.0でかまわない。すなわち，準備の整ったクライアントから順にWindows 2000にアップグレードすればよく，一斉に切り替える必要はないのである。
 |
Chapter 4 15/16 |  |
