(クリックすると原寸大の図を表示します)
| 基本仕様 第 12 章 | 前の章 次の章 |
VB C# ALL プログラミング言語によるフィルタ (ここで選んだ言語で選別された説明や図だけが表示されます)
ツーピーススタイルのアプリケーションでは、以下に述べる通信手段を用いてクライアント (ローカルピース) とサーバ (セントラルピース) 間でデータ通信がなされます。 この通信手段としては、後述する 4 種類があり、その中からふさわしいものを選ぶことができます。 ところで、この通信処理は、すべて MANDALA 実動フレームワークによってなされるようになっています。 したがって、アプリケーションプログラムを一切変更することなしに、どの通信手段であっても自由にお選びいただき、お試しいただけます。どの通信手段を用いるかを決めた後に必要な作業は、カスタマイズ用のモジュール (Ae_MsgL9) の変更、および構成ファイルに関する設定だけです。
なお、通信手段の選択にあたっては、少なくともデバッグ作業の初期段階では、手軽な .NET リモート処理 (.NET Remoting) を用いることをお勧めいたします。 そして、アプリケーションを実際に稼動させる際には、ネットワーク構成や運用形態を考慮して、またセキュリティに関する配慮の必要度に応じて、最もふさわしいものをお選びいただくのがよいでしょう。
この章では、通信手段を選択する際のポイント、およびそれぞれの通信手段を用いるための設定の方法が書いてあります。
選択可能な 4 つの通信手段はいずれも、プロトコルとして、TCP/IP を直接用いるか、または TCP/IP 上の HTTP (または HTTPS) を用いるものであり、次の 2 種類に大別できます。
以下に、それぞれの方式について詳説しますが、次のような経験をしましたので、ご参考のために述べておきます。
リモート処理方式では、非常に多くの (1000 に近いような数の) クライアントを接続して処理すると、スループットが非常に悪くなることがあります。 弊社で MANDALA.net の負荷テストを行った際に、実際に、このような現象が観測されました。 この原因は完全には解明されていませんが、リモート処理の問題だと思われます。少なくとも HTTP ダイレクト方式ではこのようなことは起きませんでした。 なお、この現象が起きるのは、非常に多くのクライアントを同時に接続した場合だけですので、 同時接続クライアント数が 500 以下の環境では問題ないといってよいでしょう。
.NET リモート処理とは、リモートコンピュータ上にあるオブジェクトという形式のデータをローカルコンピュータで扱えるようにするための技術基盤であり、これを用いることによって実質的にデータの通信が行うことができます。 .NET リモート処理についての詳しい情報については Visual Studio のドキュメントに書いてありますが、MANDALA.net を用いれば、.NET リモート処理に関する知識がなくても、ツーピーススタイルのアプリケーションを開発することができます。
ところで .NET リモート処理を用いるシステムは、使うチャネル (プロトコル) および何にホストさせるのか (サーバ側での待ち受け処理を何に実施させるのか) によって分類できます。 MANDALA.net では、次の 3 種類の形態をサポートしています。
これらの 3 種類の通信手段には、次のような特徴 (メリット、デメリット) があります。
以上の 3 種類の通信手段の特徴から、次のことがいえます。
デバッグ作業の初期段階では、HttpChannel の .NET リモート処理を用いることをお勧めいたします。 各種の設定などの手間がかかりませんし、サンプルプログラムのほとんどはこの通信手段を用いているからです。
なお、HttpChannel の .NET リモート処理を用いてアプリケーションの単体テストをしても、アプリケーションプログラムを一切変更することなしに通信手段を切り替えることができます。
ネットワークからの情報漏洩防止に関する配慮がなされた専用回線や VPN (virtual private network) を用いる運用形態の場合には、.NET リモート処理を使うことができますが、 そうでない場合には HTTPS による通信手段をお勧めいたします。
.NET リモート処理を使う場合には、HttpChannel よりも TcpChannel の方が性能的に優れています。
なお、マイクロソフト社のドキュメントには、インターネット環境においては、.NET リモート処理を使用しない方がよいとの注意が書いてあります。 なぜ、このようなことを述べるのか、その真意を測りかねますが、想像するに、.NET リモート処理のようなリモートコンピュータ上のオブジェクトを直接操作できるシステムでは、セキュリティホールを完全に取り除くことが難しいとマイクロソフト社は感じているので、このような注意を促しているのてはないでしょうか。 たとえば、DCOM RPC のセキュリティホールを突くワーム型ウィルスが大流行して問題になったことが思い出されます。 MANDALA.net における .NET リモート処理の使い方は、慎重に設計したものであり、バイト配列という形のたった一種類のオブジェクトしか使わない極めてシンプルなものですので、この注意は当たりませんが、マイクロソフト社の OS や .Net Framework に、もしも何らかの脆弱性があるようだと、残念ながらその問題を抱えてしまうことになります。
HTTP ダイレクト方式は、いわゆる HTTP トンネリングと呼ばれている技術を応用しています。
この方式では、クライアントとなるアプリケーションのローカルピースが、ASP.NET と直接対話してサーバと通信します。ASP.NET は、クライアントからの要求を受け取ると、あらかじめ配置されているセントラルピースを呼び出してアプリケーション処理を実行させます。
またこの方式ではインターネットへの公開などにも特に制限事項はありません。(この場合ももちろん厳格な運用管理による安全確保は必要です。)
ツーピーススタイルのアプリケーションでは、ローカルピース (クライアント) 側とセントラルピース (サーバ) 側の間で通信が行われています。この節では、通信に関する振る舞いを決定する設定方法について説明します。
CentralMain の先頭部分で定義されているモジュールレベル変数の内容を書き換えます。
' VB の場合の例
Private MyUri As Uri = New Uri("tcp://localhost:9090/REMOTING")
Private EnsureSecurity As Boolean = True
クラス Ae_MsgL0 を継承したサブクラスで、下記のように AE_StartUp メソッドをオーバライドします。メソッドの最後で継承元の同名メソッドを呼び出すようにしてください。
' VisualBasic の場合 Friend Overrides Sub AE_StartUp(ByVal fB As FormBase) ServerURL = "tcp://localhost:9090/REMOTING" EnsureSecurity = True UseDefaultCredentials = False MyBase.AE_StartUp(fB) ' 必ず基本メソッドを呼び出す End Sub
// C# の場合 internal override void AE_StartUp( FormBase fB ) { ServerURL = "tcp://localhost:9090/REMOTING"; EnsureSecurity = true; UseDefaultCredentials = false; base.AE_StartUp(fB); // 必ず基本メソッドを呼び出す }
UseDefaultCredentials を False (VB の場合) または false (C# の場合) に設定した場合、クラス Ae_MsgL0 の AE_Login というメソッドが呼ばれます。このメソッドは、簡単なログイン情報入力ウィンドウを表示し、ユーザ名とパスワードを入力させます。認証が成功し、ログイン情報が正しいと判断された場合、さらに AE_LoginSuccessed というメソッドが呼び出されます。Ae_MsgL0 の AE_LoginSuccessed メソッドは何もしていませんが、サブクラスでオーバライドしてログイン成功時の処理を記述することができます。AE_Login メソッドと AE_LoginSuccessed メソッドを組み合わせてオーバライドすることで、様々な認証体系を実装することができます。
AE_Login メソッドのパラメタにある NetworkCredential というクラスは、.Net Framework の System.Net 名前空間に属しています。このクラスはネットワークにおけるユーザ認証のための資格情報を格納するコンテナとなります。MANDALA.net のリモート処理では、このクラスの UserName プロパティと Password プロパティ を使用します。(場合によっては Domain プロパティも必要になるようです。)
AE_Login メソッドの返却値は、再度の呼び出しを許可するか否かを決定します。タイプミスなどで認証に失敗しても、リトライを可能にするためです。返却値が True (VB の場合) または true (C# の場合) を返した場合、認証に失敗してもこのメソッドが繰り返して呼ばれます。False (VB の場合) または false (C# の場合) を返した場合、認証に失敗するとアプリケーションが終了してしまいます。
この繰り返しには回数制限が設けられています。MaxRetryCount という変数の値がその回数で、デフォルトでは 3 に設定されています。この変数の内容を、上記で説明した AE_StartUp メソッドなどで書き換えることで、制限回数を変更することができます。
CentralMain の先頭部分で定義されているモジュールレベル変数の内容を書き換えます。
' VB の場合の例
Private MyURI As Uri = New Uri("http://localhost:8080/REMOTING")
Private EnsureSecurity As Boolean = True
クラス Ae_MsgL0 を継承したサブクラスで、下記のように AE_StartUp メソッドをオーバライドします。メソッドの最後で継承元の同名メソッドを呼び出すようにしてください。
' VB の場合 Friend Overrides Sub AE_StartUp(ByVal fB As FormBase) ServerURL = "http://localhost:9090/REMOTING" EnsureSecurity = True UseDefaultCredentials = False MyBase.AE_StartUp(fB) ' 必ず基本メソッドを呼び出すこと End Sub
// C# の場合 internal override void AE_StartUp( FormBase fB ) { ServerURL = "http://localhost:9090/REMOTING"; EnsureSecurity = true; UseDefaultCredentials = false; base.AE_StartUp(fB); // 必ず基本メソッドを呼び出すこと }
UseDefaultCredentials を False (VB の場合) または false (C# の場合) に設定した場合、クラス Ae_MsgL0 の AE_Login というメソッドが呼ばれます。このメソッドは、簡単なログイン情報入力ウィンドウを表示し、ユーザ名とパスワードを入力させます。認証が成功し、ログイン情報が正しいと判断された場合、さらに AE_LoginSuccessed というメソッドが呼び出されます。Ae_MsgL0 の AE_LoginSuccessed メソッドは何もしていませんが、サブクラスでオーバライドしてログイン成功時の処理を記述することができます。AE_Login メソッドと AE_LoginSuccessed メソッドを組み合わせてオーバライドすることで、様々な認証体系を実装することができます。
AE_Login メソッドのパラメタにある NetworkCredential というクラスは、.Net Framework の System.Net 名前空間に属しています。このクラスはネットワークにおけるユーザ認証のための資格情報を格納するコンテナとなります。MANDALA.net のリモート処理では、このクラスの UserName プロパティと Password プロパティ を使用します。(場合によっては Domain プロパティも必要になるようです。)
AE_Login メソッドの返却値は、再度の呼び出しを許可するか否かを決定します。タイプミスなどで認証に失敗しても、リトライを可能にするためです。返却値が True (VB の場合) または true (C# の場合) を返した場合、認証に失敗してもこのメソッドが繰り返して呼ばれます。False (VB の場合) または false (C# の場合) を返した場合、認証に失敗するとアプリケーションが終了してしまいます。
この繰り返しには回数制限が設けられています。MaxRetryCount という変数の値がその回数で、デフォルトでは 3 に設定されています。この変数の内容を、上記で説明した AE_StartUp メソッドなどで書き換えることで、制限回数を変更することができます。
IIS Web サーバで、web.config ファイルに下記の設定を記述します。
<configuration>
<system.runtime.remoting>
<application>
<service>
<wellknown mode="Singleton"
objectUri="Communicator.rem"
type="AppliTech.Remoting.Communicator, AppliTech.Remoting8"/>
</service>
</application>
</system.runtime.remoting>
<system.web>
<authentication mode="Windows"/>
<authorization>
<deny users="?"/>
</authorization>
</system.web>
</configuration>
クラス Ae_MsgL0 を継承したサブクラスで、下記のように AE_StartUp メソッドをオーバライドします。メソッドの最後で継承元の同名メソッドを呼び出すようにしてください。
' VB の場合 Friend Overrides Sub AE_StartUp(ByVal fB As FormBase) ServerURL = "http://localhost/Application/Communicator.rem" EnsureSecurity = True UseDefaultCredentials = False MyBase.AE_StartUp(fB) ' 必ず基本メソッドを呼び出すこと End Sub
// C# の場合 internal override void AE_StartUp( FormBase fB ) { ServerURL = "http://localhost/Application/Communicator.rem"; EnsureSecurity = true; UseDefaultCredentials = false; base.AE_StartUp(fB); // 必ず基本メソッドを呼び出すこと }
UseDefaultCredentials を False (VB の場合) または false (C# の場合) に設定した場合、クラス Ae_MsgL0 の AE_Login というメソッドが呼ばれます。このメソッドは、簡単なログイン情報入力ウィンドウを表示し、ユーザ名とパスワードを入力させます。認証が成功し、ログイン情報が正しいと判断された場合、さらに AE_LoginSuccessed というメソッドが呼び出されます。Ae_MsgL0 の AE_LoginSuccessed メソッドは何もしていませんが、サブクラスでオーバライドしてログイン成功時の処理を記述することができます。 AE_Login メソッドと AE_LoginSuccessed メソッドを組み合わせてオーバライドすることで、様々な認証体系を実装することができます。
AE_Login メソッドのパラメタにある NetworkCredential というクラスは、.Net Framework の System.Net 名前空間に属しています。このクラスはネットワークにおけるユーザ認証のための資格情報を格納するコンテナとなります。MANDALA.net のリモート処理では、このクラスの UserName プロパティと Password プロパティ を使用します。 (場合によっては Domain プロパティも必要になるようです。)
AE_Login メソッドの返却値は、再度の呼び出しを許可するか否かを決定します。タイプミスなどで認証に失敗しても、リトライを可能にするためです。返却値が True (VB の場合) または true (C# の場合) を返した場合、認証に失敗してもこのメソッドが繰り返して呼ばれます。False (VB の場合) または false (C# の場合) を返した場合、認証に失敗するとアプリケーションが終了してしまいます。
この繰り返しには回数制限が設けられています。MaxRetryCount という変数の値がその回数で、デフォルトでは 3 に設定されています。この変数の内容を、上記で説明した AE_StartUp メソッドなどで書き換えることで、制限回数を変更することができます。
web.config ファイルに次の設定を加えます。system.web セクションの定義はすでに存在しているはずですので、太字の部分のみ書き加えることになります。
<system.web>
<httpHandlers>
<add verb="POST"
path="AppRequest.appmsg"
type="AppliTech.Remoting.AppRequestHandler, AppliTech.Remoting8"/>
<add verb="POST"
path="AppManagement.appmsg"
type="AppliTech.Remoting.AppManagementHandler, AppliTech.Remoting8"/>
</httpHandlers>
</system.web>
これで ASP.NET は、AppRequest.appmsg という URL を受け取った場合 MANDALA.net 実動フレームワークを呼び出してくれるようになります。
ローカルピースのプロジェクトでは、コンパイル定数に HttpDirect を定義します。
VB の場合、アプリケーションプロパティのコンパイルタブで 詳細コンパイルオプション(A) ボタンをクリックし、カスタム定数欄に HttpDirect=True を追加します。C# の場合、アプリケーションプロパティのビルドタブで 条件付きコンパイルシンボル(Y) 欄に HttpDirect を追加します。
コンパイル定数 HttpDirect を定義すると、クラス Ae_MsgL0 の動作が変更され、Communicator の HTTP ダイレクト方式版である WebClientCommunicator が使用されるようになります。
さらに、Ae_MsgL0 のサブクラスで次のように AE_StartUp メソッドをオーバライドします。
' VB の場合の例 Public Overrides Sub AE_StartUp(ByVal fB As FormBase) ServerURL = "http://someserver/AppServer/AppRequest.appmsg" EnsureSecurity = True UseDefaultCredentials = False MyBase.AE_StartUp(fB) ' 必ず基本メソッドを呼び出すこと End Sub
設定している変数の意味は次の通りです。
UseDefaultCredentials を False (VB の場合) または false (C# の場合) に設定した場合、クラス Ae_MsgL0 の AE_Login というメソッドが呼ばれます。このメソッドは、簡単なログイン情報入力ウィンドウを表示し、ユーザ名とパスワードを入力させます。認証が成功し、ログイン情報が正しいと判断された場合、さらに AE_LoginSuccessed というメソッドが呼び出されます。Ae_MsgL0 の AE_LoginSuccessed メソッドは何もしていませんが、サブクラスでオーバライドしてログイン成功時の処理を記述することができます。AE_Login メソッドと AE_LoginSuccessed メソッドを組み合わせてオーバライドすることで、様々な認証体系を実装することができます。
AE_Login メソッドのパラメタにある NetworkCredential というクラスは、.Net Framework の System.Net 名前空間に属しています。このクラスはネットワークにおけるユーザ認証のための資格情報を格納するコンテナとなります。MANDALA.net のリモート処理では、このクラスの UserName プロパティと Password プロパティ を使用します。(場合によっては Domain プロパティも必要になるようです。)
AE_Login メソッドの返却値は、再度の呼び出しを許可するか否かを決定します。タイプミスなどで認証に失敗しても、リトライを可能にするためです。返却値が True (VB の場合) または true (C# の場合) を返した場合、認証に失敗してもこのメソッドが繰り返して呼ばれます。False (VB の場合) または false (C# の場合) を返した場合、認証に失敗するとアプリケーションが終了してしまいます。
この繰り返しには回数制限が設けられています。MaxRetryCount という変数の値がその回数で、デフォルトでは 3 に設定されています。この変数の内容を、上記で説明した AE_StartUp メソッドなどで書き換えることで、制限回数を変更することができます。
ツーピーススタイルアプリケーションのうち、IIS にホストされた .NET リモート処理方式、および HTTP ダイレクト方式を採用したアプリケーションの場合、IIS 上で稼働できる Web サイトを構築する必要があります。この章では、Visual Studio でアプリケーションをホストするための Web サイトを開発する手順を説明します。
なお、Web サイトの開発・発行シーケンスにはいくつかの種類がありますが、本章では次の手順で作業することを前提に説明を進めます。
ここで説明する Web サイトを作成するソリューションを用意してください。ソリューションにはツーピーススタイルソリューションのローカルプロジェクト、セントラルプロジェクトの両方が含まれるようにします。 必要であれば Coherent Area (ca) プロジェクトも含めてください。
この節の以後の説明では、すべてこのソリューション上で作業を行うものとします。
Visual Studio のメニュー ファイル(F) から 新しい Web サイト(W) をクリックします。
(クリックすると原寸大の図を表示します)
Web サイトの場所は、特に制限はありませんがなるべくアプリケーションと近いところが望ましいでしょう。後でセントラルピースのコンパイル出力場所をこの Web サイトの bin ディレクトリに指定するのですが、コンパイル出力場所は相対表記されるようになるため、近いディレクトリの方が間違えにくくなるからです。可能であれば、アプリケーションプロジェクトのサブディレクトリでも構いません。
ディレクトリ名はたとえば CentralWeb などとしておくと良いでしょう。この節の例では CentralWeb という名前を付けたものとして説明を進めます。この名前は、開発時に使用されるだけであって、後で発行するサーバ上のアプリケーション名とは無関係です。
上記のすべて指定したら OK ボタンをクリックします。
Web サイトの初期設定が行われ、Default.aspx ファイルの編集状態になります。このページは Web サイトにファイル名を指定せずアクセスしたとき表示されるページです。アプリケーション開発において実用上の意味はありませんが、Web サーバの開通テストなどに使用することができますので、下図のように確認用の簡単なページを作っておくことをおすすめします。
次に参照設定を行います。Web サイトから MANDALA.net 実動フレームワーク、および通信用のアセンブリを参照する必要があります。Visual Studio のメニュー Web サイト(S) から 参照の追加(R) をクリックしてください。通常のアプリケーション開発時と同様、参照の追加ダイアログボックスが表示されますので、MANDALA.net がインストールされているディレクトリにある AppliTech.WorkFrame8Cnt.dll および AppliTech.Remoting8.dll の 2 つを指定してください。
この項は、.NET リモート処理を IIS でホストする場合のみ必要な設定事項を記述します。これ以外の方式では次の項に進んでください。
CentralWeb サイト配下にある web.config ファイルをエディタで開きます。このファイルは configuration 要素をルート要素に持つ XML になっています。この configuration 要素下に、次のように system.runtime.remoting 要素を追加します。(太字部分)
<configuration>
<system.runtime.remoting>
<application>
<service>
<wellknown mode="Singleton"
objectUri="Communicator.rem"
type="AppliTech.Remoting.Communicator, AppliTech.Remoting8"/>
</service>
</application>
</system.runtime.remoting>
</configuration>
この設定により、クライアントから Communicator.rem というアドレスの要求を受けたとき、ASP.NET はリモートオブジェクト AppliTech.Remoting.Communicator をアクティブ化してクライアントと接続させます。
この項は、HTTP ダイレクト 方式をホストする場合のみ必要な設定事項を記述します。これ以外の方式では次の項に進んでください。
CentralWeb サイト配下にある web.config ファイルをエディタで開きます。このファイルは configuration 要素をルート要素に持つ XML になっています。この configuration 要素下に、system.web という要素が定義されています。この system.web 要素に、次のように httpHandlers 要素を追加します。(太字部分)
<configuration>
<system.web>
<httpHandlers>
<add verb="POST"
path="AppRequest.appmsg"
type="AppliTech.Remoting.AppRequestHandler, AppliTech.WorkFrameCnt" />
<add verb="POST"
path="AppManagement.appmsg"
type="AppliTech.Remoting.AppManagementHandler, AppliTech.WorkFrameCnt"/>
</httpHandlers>
<system.web>
<configuration>
この設定により、クライアントから AppRequest.appmsg というアドレスの要求を受けたとき、ASP.NET は HTTP ハンドラ AppliTech.Remoting.AppRequestHandler に処理を委譲します。同様に AppManagement.appmsg というアドレスの要求を受けたとき、ASP.NET は HTTP ハンドラ AppliTech.Remoting.AppManagementHandler に処理を委譲します。
web.config ファイルの設定で、同時に稼働させられるアプリケーション・セッション数の上限値を決めることができます。 configuration 要素の下にある appSettings 要素を次のように編集してください。
<configuration>
<appSettings>
<add key="MaxSessions" value="999" />
</appSettings>
</configuration>
この数値を超えるアプリケーション起動要求が行われると、クライアントコンピュータのデスクトップにエラーメッセージが表示され、アプリケーションの起動は拒否されます。 この値の最大値は 9999 です。
なお、すでに appSettings 要素に何らかの値が定義されている場合、appSettings の子要素である add 要素を追加するようにしてください。
Web サイトは、ソリューションに対して実行 (デバッグ) 指示を行うと Web サーバを立ち上げます。 この Web サーバはポート番号を動的に取得して使用するため、Web サイトを表す URL は実行ごとに変わってしまいます。MANDALA.net アプリケーションのように、ソースコードや設定ファイルに URL を記述するタイプのアプリケーションをテストする場合、このような動作は不適切です。
そこで、動的ポートの使用をやめさせるように Web サイトのプロパティを設定します。
ソリューションエクスプローラで Web サイトのルートをクリックし、選択状態にしたうえでプロパティウィンドウを表示します。ポート番号に関する設定項目が表示されますので、「動的ポートの使用」を False に書き換え、「ポート番号」に使用したいポート番号を入力します。この例では 8080 を設定します。
これで、Web サーバが使用するポート番号、ひいては URL を固定することができます。
Web サイトがセントラルピースのアセンブリを利用できるようにするため、セントラルプロジェクトのコンパイル生成物を出力するディレクトリを Web サイトの Bin ディレクトリに変更します。 このためにセントラルピースのプロジェクトウィンドウを表示します。Visual Studio の メニュープロジェクト(P) から 〜のプロパティ(P) をクリックしてください。
VB の場合、「コンパイル」タブページの ビルド出力パス(U) を書き換えます。
C# の場合、「ビルド」タブページの 出力パス(O) を書き換えます。
これらを設定してからセントラルプロジェクトのコンパイルを行うと、dll などの生成物は Web サイトから認識可能な Bin ディレクトリに出力されるようになります。
完成した Web アプリケーションをテスト稼働、あるいは本稼働用のサーバに配置 (デプロイ) するために、Visual Web Developer には 2 種類の方法が用意されています。
Web サイトの発行ユーティリティは、Visual Studio のメインメニューから ビルド(B) - Web サイトの発行(H) とクリックすることで起動します。
Web サイトのコピーツールは、Visual Studio のメインメニューから Web サイト (S) - Web サイトのコピー(P) とクリックすることで起動します。
発行ユーティリティは、コピーツールに比べて機能面でのアドバンテージがありますが、改変時にコンパイルが必要など柔軟性に欠ける面があるようです。 詳しい情報は下記の Microsoft の Web サイトなどをご覧ください。
Visual Web Developer での Web サイトの配置
なお、ドキュメントには「Web サイトの発行ユーティリティは、Visual Web Developer Express Edition では、使用できない」という注意事項が書かれています。
どちらのツールを使用する場合、対象となる Web サーバコンピュータに対して次のうちいずれかの経理でアクセスして、 Web サイトの構成要素となるファイルを転送することになります。
下図は、Web サイトの発行ユーティリティで、ターゲットの場所を選択するために使用されるダイアログボックスです。左側の赤い枠で囲まれた部分（実際のウィンドウでは、赤い枠は表示されません）が、上記のアクセス経路における選択肢です。
ファイルシステムに転送する場合、目的のディレクトリが Windows エクスプローラの「ネットワークコンピュータ」から見えており、書き込み可能である必要があります。
ローカル IIS に転送するのは、対象となる Web サーバコンピュータ上で開発を行っている場合のみです。このとき、ローカル IIS 上で FrontPage Server Extension が有効になっている必要があります。
FTP サイトに転送する場合、対象となる Web サーバコンピュータ上で FTP サーバが稼働しており、開発用のコンピュータからこの FTP サーバを経由して目的のディレクトリに書き込み可能である必要があります。
リモートサイトに転送する場合、サーバ上で FrontPage Server Extension が有効になっている必要があります。サーバが Windows Server 2003 x64 Editions である場合、標準では FrontPage Server Extension がインストールされていませんので、このアクセス方法は使用できません。
この節では、MANDALA.net に付属しているサンプルアプリケーションを例に、ツーピーススタイルのアプリケーションでの設定をどのように行うかを説明します。
ここでご紹介するサンプルとして取り上げるのは、Jutyu2 というアプリケーションです。このアプリケーション用の Visual Studio ソリューションファイルは、次の場所にインストールされています。
(VB の場合)
MANDALA.net をインストールしたフォルダ\vb\Jutyu2Sds.sln
たとえば C:\Mandala9\vb\Jutyu2Sds.sln
(C# の場合)
MANDALA.net をインストールしたフォルダ\cs\Jutyu2Sds.sln
たとえば C:\Mandala9\cs\Jutyu2Sds.sln
サンプルの内容を確認するために、Visual Studio .NET で、このソリューションを開いてください。そしてまずファイル Ae_MsgL9.vb (VB の場合) またはファイル Ae_MsgL9.cs (C# の場合) を開いてください。Ae_MsgL9 は、Jutyu2Lcl プロジェクトの、 Customize フォルダの中にあります。
ファイル Ae_MsgL9 を開いたら、シンボルの検索で ServerURL というフィールドを探してください。このフィールドの宣言箇所では、次のように初期化を行っています。
(VB の場合)
Friend Shared ServerURL As String = "http://localhost:8080/REMOTING"
(C# の場合)
Friend Shared ServerURL As String = "http://localhost:8080/REMOTING"
この文字列が示す URL が、ツーピーススタイルのアプリケーションのデフォルト待ち受けアドレスになっています。これはテスト用のアドレスであって実際の使用には適していませんし、また通信方式も .NET リモート処理方式の HttpChannel にしか対応していません。アドレスや通信方式を変更する場合、ServerURL フィールドの値を書き換えればいいのですが、ファイル Ae_MsgL9 を直接編集するのは何かと問題を引き起こす可能性があります。サブクラスを作成する方法もありますが、ここではアプリケーション構成ファイルを利用する方法をとっています。
Jutyu2Lcl プロジェクトの Customize フォルダにある app.config ファイルを開いてください。このファイルのセクション Configuration/appSettings にある add 要素の中に、次のような定義があります。
<add key="CentralServerURL" value="http://localhost:8080/REMOTING"/>
この add 要素の value 属性の値が、実行時に Ae_MsgL9 内で ServerURL に転送されます。実はこのアプリケーションでは、Ae_MsgL9 初期化時に代入している値はあとでこの app.config の値で上書きされています。どちらも同じ値なので動作には影響ないのですが、データの流れとしてはそのようになっています。app.config ファイルがない場合は Ae_MsgL9 のソースに書かれている初期化値がそのまま使用されます。
app.config ファイルはサーバを起動するための CentralMain プロジェクトでも参照されており、これを書き換えることによってサーバも同じアドレスで待ち受けるようになります。1 箇所を変更することでクライアントとサーバの双方が不整合を起こすことなく変更されます。
では、app.config ファイルを編集して、次のように変更してください。
<add key="CentralServerURL" value="tcp://localhost:9090/REMOTING"/>
これで、.NET リモート処理は TcpChannel を使用して通信を行うようになります。その際のポート番号には 9090 を使用します。このファイルを保存してソリューションを再コンパイルし、実行してみてください。CentralMain のウィンドウが次のように表示されます。
待ち受けアドレスが、デフォルトのまま実行したときとは異なり、さきほど app.config ファイルで設定した値になっています。クライアント側もこのアドレスへ接続を試みるため、アプリケーションは全体として正しく実行されることになります。
一度アプリケーション実行を終了させ、app.config ファイルの次の箇所を見てください。
<add key="EnsureSecurity" value="False"/>
この要素はセキュリティ保護を使用して接続するかどうかを指定しています。この要素の Value 属性値を True にすると、ユーザ認証が行われるようになります。また、.NET リモート処理方式の TcpChannel を使用する場合、NTLM などシステム既定の方法により暗号化が行われ、通信内容が保護されます。 (HttpChannel を使用する場合、.NET Framework でセキュリティ保護がサポートされません。CentralServerURL に HttpChannel アドレスを指定し、かつ EnsureSecurity を True にすると実行時に例外が発生します。)
この要素を書き換えて、次のように True を指定してください。
<add key="EnsureSecurity" value="True"/>
再コンパイル後、実行します。セキュリティ機能を有効にしたため、ユーザ認証が行われるようになっていますので、次のようなウィンドウが表示されてログイン情報を求められます。
ここでは、現在ログインしている開発者用のユーザ名とパスワードを入力すれば正しく認証されますので、両方のフィールドに入力を行って OK ボタンをクリックしてください。ローカルピースのフォームが表示され、アプリケーションが実行されます。
アプリケーションを終了させ、app.config ファイルの次の箇所を見てください。
<add key="UseDefaultCredentials" value="False"/>
この値を True に設定すると、先ほど見たログインウィンドウが表示されなくなります。代わりに現在 OS にログインしているユーザ情報を使用して認証が行われるようになります。いわゆる Windows 統合認証という機能を実装したことになります。
<add key="UseDefaultCredentials" value="True"/>
app.config ファイルをこのように変更して保存し、ソリューションの再コンパイル後に実行すると今度はログイン情報入力ウィンドウは表示されず、すんなりとアプリケーションが実行されます。
app.config には、この他に以下の 2 つのツーピース通信に関する要素が記述されています。
<add key="MaxRetryCount" value="3"/> <add key="MaxSessions" value="9" />
1 行目の MaxRetryCount はログインをリトライできる回数の最大値です。ログイン情報入力ウィンドウで正しく認証されなかった場合、再度入力ウィンドウが表示されますが、この回数を制限するためのパラメタです。
2 行目の MaxSessions はサーバで参照される値で、接続できるセッションの最大値です。アプリケーションからこの値を超える接続要求があった場合、それを拒否してアプリケーションを開始しないようにします。
.NET リモート処理の接続要求を HTTP サーバが受け付ける場合の設定などについて説明します。
まずは Web サイトを用意します。Jutyu2Sds ソリューションを開いた状態で、Visual Studio .NET のメニューから ファイル(F) - 追加(D) - 既存の Web サイト(B) とクリックし、ファイルシステムタブで次のフォルダを指定してください。
MANDALA.net をインストールしたフォルダ\vb\Jutyu2\CentralWeb
(たとえば C:\Mandala9\vb\Jutyu2\CentralWeb)
このフォルダには、Jutyu2 アプリケーションをホストするための Web サーバ構成があり、ソリューションにこれを組み込んでおくことで、アプリケーション実行時自動的に開発テスト用の Web サーバが起動されます。
app.config ファイルは CentralServerURL を次のように書き換えます。
<add key="CentralServerURL" value="http://localhost:8081/CentralWeb/Communicator.rem"/>
このアドレスは、さきほどソリューションに追加した Web サイトが待ち受ける URL です。なぜこの URL になるか順に説明します。
まず、ソリューションエクスプローラのウィンドウで Web サイトのノード (プロジェクト名の代わりにフォルダ名が書かれている部分) をクリックして選択状態にしてください。そのまま Visual Studio .net のメニューから 表示(V) - プロパティウィンドウ(W) とクリックしてプロパティウィンドウを表示すると Web サイトのプロパティが表示され、プロパティ項目「ポート番号」の値として 8081 という数字が設定されているのがわかります。このポート番号は、同じくプロパティ項目の「動的ポートの使用」を False にすることで設定可能になります。「動的ポートの使用」が True になっていると、ポート番号は実行時に決められるため事前に URL を指定することができなくなってしまいます。
CentralWeb というディレクトリ名は、ソリューションに追加した Web サイトフォルダの名前です。開発用 Web サーバではこのような規則になっています。
Communicator.rem というファイル名は Web アプリケーションの設定ファイルで決定されます。ソリューションエクスプローラのウィンドウから、Web サイトのフォルダ直下にある web.config というファイルを開いてみてください。そしてテキスト検索で "Communicator.rem" という文字列を探し、前後を含めて表示してみると次のような部分が見つかります。
<system.runtime.remoting>
<application>
<service>
<wellknown mode="Singleton"
objectUri="Communicator.rem"
type="AppliTech.Remoting.Communicator, AppliTech.Remoting8"/>
</service>
</application>
</system.runtime.remoting>
ここで設定された値に従って Communicator.rem というアドレスが決定されます。要求用の URL を変更する場合は、この値とクライアントの app.config で指定している CentralServerURL の両方を書き換える必要があります。
web.config ではもう 1 箇所、次の設定が有効です。
<appSettings> <add key="MaxSessions" value="9" /> </appSettings>
セントラル・セッション最大数の設定ですが、Web サーバ下でホストされますので、CentralMain の場合と異なり app.config ではなく web.config で設定しなくてはなりません。
設定を確認したら、再コンパイル後に実行してみてください。開発用 Web サーバが立ち上がり、タスクトレイにアイコンが表示されます。アプリケーション起動して動作しているにもかかわらず、CentralMain のウィンドウにはアセンブリをロードした情報などが表示されていなければ、Web サーバでのホスティングに成功しています。確認できたらアプリケーションを終了させてください。
HTTP ダイレクト方式での設定を説明します。
ローカルピースのプロジェクトでは、コンパイル定数に HttpDirect を定義します。
VB の場合、アプリケーションプロパティのコンパイルタブで 詳細コンパイルオプション(A) ボタンをクリックし、カスタム定数欄に HttpDirect=True を追加します。C# の場合、アプリケーションプロパティのビルドタブで 条件付きコンパイルシンボル(Y) 欄に HttpDirect を追加します。
また、セントラル側の接続先を変更するために app.config の CentralServerURL 設定を次のように書き換えます。
<add key="CentralServerURL" value="http://localhost:8081/CentralWeb/AppRequest.appmsg"/>
セントラル側では、web.config ファイルに次のような箇所があります。(変更の必要はありません)
<httpHandlers>
<add verb="POST"
path="AppRequest.appmsg"
type="AppliTech.WorkFrame.AppRequestHandler, AppliTech.WorkFrame8Cnt" />
<add verb="POST"
path="AppManagement.appmsg"
type="AppliTech.WorkFrame.AppManagementHandler, AppliTech.WorkFrame8Cnt"/>
</httpHandlers>
この設定により、アプリケーションから Web サーバに AppRequest.appmsg というアドレスへの要求があると、セントラルピースと通信ができるようになっています。
セントラル側の設定としては、セントラル・セッション最大値を決める MaxSessions 設定も IIS にホストされた .NET リモート処理方式の場合同様この web.config ファイルで記述します。
すべての設定を確認したら、アプリケーションを実行してみてください。やはり CentralMain のウィンドウにはメッセージが表示されないまま正常に実行されているアプリケーションが見られます。
この節では、ツーピーススタイルのアプリケーションにおける処理要求と応答の流れについての技術的な概要を説明します。アプリケーションを開発する上では必ずしも必要な情報ではありませんが、ご一読いただくことで実働フレームワークをより深くご理解いただけるものと思います。
MANDALA.net を使用して開発したアプリケーションでは、操作者の操作・指示にしたがってフックメソッドが呼び出されます。ツーピーススタイルの場合は、クライアントコンピュータ上のフックメソッド (ローカルピース) が動作したり、サーバコンピュータ上のフックメソッド (セントラルピース) が動作したりします。
図のように、まずフックメソッドの要求を FormBase が受け取ります。FormBase は内部でセントラルピースへの要求が必要かどうかを判断し、これが必要であれば Ae_MsgL0 というクラスに通信要求を発行します。Ae_MsgL0 はこの要求を受け取り、Communicator というクラスを使用してサーバへの通信を行います。
サーバではクライアント (ローカルピース) からの要求を受け付ける待ち受けるポートを開いて常に待機しており、ローカル Communicator からの通信要求を受け入れられるようになっています。セントラル Communicator はこのポートを通じて受け取った要求のヘッダを解析し、適切なセントラル FormBase に転送します。そして最終的にセントラルピースのフックメソッドが呼び出されるのです。
図の矢印はクライアントからサーバへの要求経路 (往路) を示していますが、サーバでセントラルピース・フックメソッドが実行された結果をクライアントに返す応答経路 (復路) も逆順で同じコースをたどります。つまり、セントラルピース・フックメソッドの戻り値など結果データは セントラルピース FormBase に渡され、サーバエントリに返されます。この結果は、通信への応答として Communicator 経由で クラス Ae_MsgL0 が受信し、もとのローカルピース FormBase に返却します。ローカルピースのフックメソッドからは、あたかもクライアントの FormBase がすべての処理を行って結果が返されたかのように見えます。
Ae_MsgL0 というクラスは、MANDALA.net コード合成ツールよってプロジェクトに自動的に追加されます。このクラスはソースファイルの形でプロジェクトに含まれることになります。ファイル名は VB の場合 Ae_MsgL9.vb, C# の場合 Ae_MsgL9.cs です。
アプリケーションのローカルピースは、このクラス Ae_MsgL0 を通してセントラルピースとの通信を行います。セントラルピースの配置されているサーバのアドレスや通信プロトコルは、このクラスの中で設定されるようになっています。
Ae_MsgL0 クラスのソースファイルはカスタマイズのために内容を読んだり改変したりすることが許諾されていますので、通信に関するパラメタはこのクラスを編集することで変更できます。
クラス Ae_MsgL0 をカスタマイズする場合、コード合成によって自動追加された クラス Ae_MsgL0 のソースファイルを直接変更しないようにしてください。追加されたソースファイルを変更してしまうともとの状態に戻すことができなくなったり、MANDALA.net を使用した他のプロジェクトにも予期せぬ影響を与えてしまうことになります。また、MANDALA.net の再インストールやバージョンアップ時に上書きされてしまう危険性もあります。
カスタマイズは、次のいずれかの手段を用いて行ってください。
Ae_MsgL0 が内部で使用している、サーバとの通信を担当するクラスです。このクラスは AppliTech.Remoting というアセンブリに含まれていますので、開発時にはこのアセンブリへの参照が必要です (この参照設定は、コード合成を行うことで自答的になされます)。
Communicator クラスは、ローカルピースとセントラルピースを結びつける働きをします。Communicator クラスの実体は、.NET リモート処理におけるリモートオブジェクトであったり、クライアント側／サーバ側に分かれた協調オブジェクトであったりしますが、ローカルピースからそのような実装についてはまったく意識する必要はありません。また、セントラルピースからは実体を参照することすらありません (参照できません)。
このように通信に関する部分を Communicator が隠蔽しているため、アプリケーションの開発者はワンピース (スタンドアロン) 構成のアプリケーションの感覚でツーピーススタイルアプリケーションを開発することができます。
Communicator はまた、アプリケーションのセントラルピースを管理する機能も有しています。 不要になったセントラルピースのインスタンスを強制的に終了させる場合など、Communicator を使用して行います。
Communicator には、運用形態に応じて複数のバージョンが存在します。次にそれぞれのバージョンの Communicator について簡単に解説します。
.NET リモート処理方式では、Communicator はリモートオブジェクトとして定義されています。このオブジェクトはクライアント (ローカルピース) の クラス Ae_MsgL0 に操作されますが、この操作が実際に実行されるのはサーバコンピュータ上になります。.NET リモート処理の仕掛けにより、ローカルとセントラルであたかもひとつのオブジェクトに見えるように振る舞います。このイメージで図示すると次のようになります。
このように、.NET リモート処理方式では 1 種類の Communicator のみを使用します。
HTTP ダイレクト方式では、ローカル側とセントラル側で別バージョンの Communicator が動作します。それぞれ WebClientCommunicator, WebServerCommunicator というクラスのオブジェクトになっています。これを図示すると次のようになります。
このように、HTTP ダイレクト方式では 2 種類の Communicator が協調動作しています。
HTTP ダイレクト方式では、ASP.NET のカスタム HTTP ハンドラ機能を利用して、ローカルピースからの要求をセントラルピースに伝達します。
カスタム HTTP ハンドラは、IIS Web サーバに対して特定の拡張子を持つ URL が要求されたとき、あらかじめ設定されている .NET クラスに要求を転送します。転送されたクラスは、要求を自由に処理して応答を返すことができます。 この機能を使用することにより、通常は Web ページを表示するために使われる IIS Web サーバを MANDALA.net のホストシステムとして利用することができます。
MANDALA.net の HTTP ダイレクト方式では、.appmsg という拡張子の URL をローカルからセントラルへの通信要求として定義しています。 なお、この拡張子を別の文字列にすることもできますが、その場合には設定変更してください。
次に HTTP ダイレクト方式の処理イメージを図示します。
このようにしてアプリケーションのローカルピースから発せられた要求がセントラルピースに伝達されます。このとき、ローカルからセントラルに送信するデータは HTTP の POST コマンドによる電文本体として渡されます。また、セントラルからローカルに返すデータは HTTP の応答本文として渡されます。
SSL を使用した HTTP 通信で運用するシステムを開発する場合、テスト段階でも SSL での接続環境を必要とすることがあることでしょう。この章では、テスト用に HTTP on SSL サーバ環境を構築する方法を説明します。
なお、この節での説明はサーバ OS に Windows 2003 Enterprise Edition を、クライアント OS に Windows XP Professional Edition を使用した環境を前提としています。他の OS の組み合わせで作業する場合は適宜読みかえてごらんください。
管理ツールの インターネットインフォメーションサービスを実行します。テストに使用する Web サイト (デフォルトでは「既定の Web サイト」) のプロパティウィンドウを開いて、ディレクトリ セキュリティ タブにあるサーバー証明書(S) ボタンをクリックします。
IIS 証明書ウィザードが開始されますので、最初の選択肢で「証明書の新規作成」を選んで次へボタンをクリックします。
次の選択肢では「証明書の要求を作成して後で送信する」を選んで次へボタンをクリックします。
次は証明書の名前を求められますので、適切な名称を入力してください。ビット長は、テスト目的なのでデフォルトのままで充分でしょう。CSP を選択したい場合「この証明書の暗号サービスプロバイダを選択する」をチェックしておけばこの次の画面で入力できますが、ここではチェックせず次へボタンをクリックします。
組織名と組織単位を入力します。IIS 証明書ウィザードの説明に従って適切に設定し、次へボタンをクリックしてください。
サイトの一般名を入力します。Web ブラウザやアプリケーションから指定する URL におけるサーバ名の部分 (https://server/somewhere/somefile の server の部分)を指定します。ここで設定した名前以外の別名 (DNS 別名や IP アドレスなど) でのアクセスでは証明書が機能しませんので注意してください。入力が終わったら次へボタンをクリックしてください。
サーバ設置場所を入力します。IIS 証明書ウィザードの説明に従って適切に設定し、次へボタンをクリックしてください。
証明書要求ファイル (このウィザードで入力した情報を保存するファイル) の場所と名前を入力します。生成されたファイルはテキスト形式ですが、それを見ても簡単には分からない文字列になっています。証明機関のソフトウェアは、このファイルを処理して証明書が発行されることになります。でしから、適当なファイル名を入力し、次へボタンをクリックしてください。そして、最終確認の後にウィザードは終了します。
このファイル名は後で使用しますので控えておくか覚えておくかするようにしてください。
次に、管理ツールの証明機関を起動します。証明機関ツールはデフォルトではインストールされていないことがあります。その場合は、コントロールパネルの「プログラムの追加と削除」から「Windows コンポーネントの追加と削除」を使用してインストールしてください。
証明機関ツールウィンドウが表示されたら、証明機関 (ローカル) ツリーの下にあるサーバから、使用するサーバを選択し、右クリックメニューを表示、[すべてのタスク] - [新しい要求の送信] とクリックします。
この後、要求ファイルを選択するファイルダイアログが表示されますので、先ほど IIS 証明書ウィザードで作成した証明書要求ファイルを指定します。
証明書要求ファイルが受け入れられると、サーバツリーの「保留中の要求」カテゴリに要求メンバが加えられます。「保留中の要求」ツリーをクリックすると、右側のペインに作成された要求が表示されますので、これを右クリックしてポップアップメニューから [すべてのタスク] - [発行] をクリックします。
発行が成功すると、「保留中の要求」のメンバは削除されて無くなり、新しく「発行した証明書」カテゴリに新しい証明書メンバが加えられます。「発行した証明書」ツリーをクリックすると、右側のペインに作成された証明書が表示されますので、これを右クリックして [すべてのタスク] - [バイナリデータのエクスポート] をクリックしてください。
エクスポート指定のウィンドウが表示されますので、「バイナリデータを含む列」には「バイナリ証明書」を指定し、エクスポートオプションには「バイナリデータをファイルに保存する」を指定して OK ボタンをクリックします。
この後、エクスポートデータを保存するファイルを選択するファイルダイアログが表示されますので、適当な場所とファイル名を指定します。このとき、ファイル名の拡張子はかならず .cer としてください。
これで証明機関による証明書発行は終了です。証明機関ツールは終了させてください。
再度 IIS 証明書ウィザードを起動します。1-1 のときと同様に管理ツールのインターネットインフォメーションサービスから使用する Web サイトを右クリックして [プロパティ] メニュー項目をクリックします。
先ほどとは異なり、作成した要求の処理を選択する内容になっていますので、「保留中の要求を処理し、証明書をインストールする」を選択して 次へ ボタンをクリックします。
証明機関で作成した証明書データのファイル名を求められますので、「2-3 証明書のエクスポート」で作成したバイナリ証明書ファイルのパスを入力して 次へ ボタンをクリックします。
SSL が待ち受けを行う TCP ポートを入力します。特別な事情がない限り、デフォルト値 443 のままにしておきます。ここでポート番号を変更した場合、テストプログラムの URL 指定時にポート番号を負荷する必要があります。
次へボタンをクリックすると、最終確認の後ウィザードは終了します。
インターネットインフォメーションサービスの Web サイトツリーから、テスト対象とするサブフォルダを選択して右クリックし、[プロパティ] をクリックします。プロパティダイアログの「ディレクトリセキュリティ」タブにある「セキュリティ保護された通信」グループの編集ボタンをクリックするとさらにダイアログボックスが表示されますので、「セキュリティで保護されたチャネル (SSL) を要求する」のチェックをオンにして OK ボタンをクリックします。
これで、対象のサブフォルダにアクセスする場合は通常の HTTP ではなく SSL で接続するようになります。サーバを指定する URL は http: の代わりに https: で始めるようにしなければ鳴りません。
クライアントが SSL を経由してサーバのコンテンツを使用する場合、信頼できるサーバであることを確認します。その信頼の根拠となるのがこの章のここまでで作成した証明書です。この証明書を誰が発行したかが問題になります。通常は信頼できる第三者機関が発行した証明書を用いているため、Web ブラウザのようなソフトウェアはこれを信用して機密情報を扱うことができます。
ところがテスト用に発行した証明書は発行者が信頼できる機関として登録されていないため、このままでは正常な SSL 通信が行えません。そこで、クライアントにテスト用の証明書サーバを信頼できるものとして登録します。これで Web ブラウザからも MANDALA.net のローカルピースからも問題なく SSL 通信ができるようになります。
クライアントコンピュータで Web ブラウザを起動し、証明書を発行したコンピュータの Web サーバに接続します。アドレスは次のように指定します。
http://コンピュータ名/CertSrv/
「コンピュータ名」の部分は証明書を発行したコンピュータの DNS 名または NetBios 名、あるいは IP アドレスで置き換えます。接続ができるとブラウザに数のようなページが表示されます。
(クリックすると原寸大の図が登場します)
この Web ページの「CA 証明書、証明書チェーン、または CRL のダウンロード」というリンクをクリックしてください。下図のページに切り替わります。
(クリックすると原寸大の図が登場します)
この Web ページの「CA 証明書のダウンロード」をクリックしてください。もし CA 証明書欄 (リストボックス表示の部分) に複数の証明書が表示されているならば、この工程の中で作成した証明書を選択クリックしておきます。
クリックすると証明書をダウンロードしようとしますが、実際にダウンロードが始まる前にセキュリティの警告と確認のためのメッセージボックスが表示されることがあります。自分で作成した証明書なので安全なのはわかっていますから、これらの確認にはダウンロードできるよう適宜回答してください。ただし、この証明書が外部に漏れたりすることのないよう充分注意してください。テストが完了したら証明書はクライアントからアンインストールしてしまうのが最も安全です。
ダウンロードしたファイルを、Windows エクスプローラなどでダブルクリックしてください。
証明書情報のダイアログボックスが表示されますので、下部にある証明書のインストールボタンをクリックします。
証明書のインポートウィザードが開始されますので、「証明書をすべて次のストアに配置する」をクリックし、証明書ストアとして「信頼されたルート証明機関」を選択してください。次へボタンをクリックすると確認が行われ、ウィザードは終了します。
ここまでの設定が完了すると、クライアントが完全にサーバを信頼できたことになり、とどこおりなく SSL を使用できるようになります。これで、SSL 上での HTTP 通信によるツーピース・アプリケーションのテストが可能になります。
Copyright © 2006-2008 by AppliTech, Inc. All Rights Reserved. (A2602532)