The Backyard - SmartClientAndAppDomain Diff
- Added parts are displayed like this.
- Deleted parts are displayed
like this.
この記事は、「WEB+DB PRESS Vol.14」(技術評論社)に掲載していただいた記事の元原稿(必要に応じて加筆/修正/削除をしています)を公開するものです。
----
!はじめに
2002年春のVisual Studio .NET登場から約1年が過ぎようとしています(注：2003年4月公開の原稿でした)が、いまだに.NETをどうビジネスへ適用するかについて混乱があるような気がします。特に、Windows フォームと呼ばれるクライアント向きライブラリの存在が、喧伝される.NETのインターネット指向、特にXML Web サービスやASP.NETとの関係が見えにくいこともその一因となっているようです。もちろん、これらのサーバーサイドの技術も重要ですが、そればかりに目を向けると、.NETが持つ重要な側面を見逃しかねません。
本稿では、企業内クライアントサーバシステム再構築のインフラという観点から、Windows フォームアプリケーションの利用方法について取り上げます。
実のところ、独立したクライアントアプリケーションとWebの融合というコンセプト（本稿ではこの形態のクライアントを「スマートクライアント」と呼びます）は何も.NETだけのものではありません。もしかしたら、既に読者の中にはJava Web Startテクノロジー（http://java.sun.com/products/javawebstart/ja/index_ja.html）を利用されている方がいるかも知れません。しかし、JNLP仕様が公開されているJavaと比較して、.NETではスマートクライアントについてのドキュメントや運用方法についての資料が乏しいのが現状です。理由の1つは最初に触れた.NETの適用に関する情報の混乱があると思います。本稿ではその点をかんがみて、最初にスマートクライアントの業務システムにおけるWebアプリケーションに対する優位性を解説します。次に、スマートクライアントのローンチャを例にして、実際に適用可能なスマートクライアント運用の基盤となる.NET Frameworkの技術解説を行います。取り上げるプログラミング上のトピックは
*スキーマコンパイラを利用したXMLのアクセス
*HTTPを利用した通信
*P/Invoke
*AppDomain
*Eメールの送信
です。
!Webアプリケーションの問題点
本誌の読者の皆さんには改めて説明するまでもないことですが、企業内システムがクライアントサーバーからWebアプリケーションへシフトしている主な理由は次の2点です。
*クライアント、サーバーそれぞれに必要となる開発スキルセットが異なり、さらにマルチベンダー環境だとサーバー毎に異なる開発／運用方法が求められること。これらは開発コストや運用コストが増大する理由となります。（図clientserver.png）
*クライアントアプリケーションの配備／保守の負荷が大きい。これにはインストールが必要となるためアプリケーションの入れ替えが容易ではないことから、いわゆるDLLヘル問題までを含みます。（図dllhell.png）
実際にはWebアプリケーションであっても、ブラウザーの種類やバージョンによって考慮しなければならない点や、サーバー側の開発に何を利用するかといった考慮点があります。それでも上に挙げた問題点はWebアプリケーションへの移行によって解消されるでしょう。
しかし、企業システムとして考えた場合、情報システムに求められることはあくまでも
*ビジネスの変化に合わせてタイムリーにソリューションの提供が受けられること
です。Webの導入はこの課題を解決するための手段であって、決してクライアントサーバーからWebアプリケーションへ移行することが問題の本質ではありません。
具体的には、Webアプリケーションへの移行は以下のような問題を抱えています。
*オペレーションの変更に伴う運用現場での教育コストの発生
*操作性の低下に伴う生産性の低下
*画面遷移に伴う処理遅延に対する運用現場からの不満
*オフライン発生（ネットワーク障害、サーバーメンテナンスなど）時の業務停止
*Webブラウザーのセキュリティモデルと業務要件の不整合
すでに、既存システムからWebアプリケーションへの移行を手がけられたことがあれば、業務部門からの「Enterキーは次の入力項目への移動」「10キーだけで処理ができなければダメ」「マウス不要」「スクロール不可」「Excelシートから入力項目を拾い出せ」というようなWebアプリケーションにとっては理不尽とも言える要求を突きつけられた経験をお持ちかも知れません。それに対して、「世の中の流れはWebだから」とかわしたり、ブラウザーのバージョン毎の動作の相違に苦しみながらJavaScriptを駆使したりするのは、やはり、本来目指しているものとは異なると言わざるを得ません。
現在の不況下にあって、コストセンターと見なされがちなシステム部門が効率的なオペレーションを図ることは望まれることですが、それによって、業務部門に対してしわ寄せが起きるようでは本末転倒のそしりを免れることはできません。また、業務部門の要求をブラウザーで実現するために苦労するのでは、少しも開発コストの削減にはなりません。
!Webアプリケーション再考
ここで、Webアプリケーションが業務システムのインフラとして注目され、実際に活用されるようになった理由について再考してみましょう。旧来のクライアントサーバーシステムの問題点について、2点あげましたが、この2つの問題の解をWebアプリケーションという言葉で一括りにしてしまうことが、問題の本質をわかりにくくしている原因だと考えられるからです。
まず、WebブラウザーのPCへの標準またはそれに近い形での搭載というものを挙げないわけにはいきません。HTTPサーバーを用意すれば、クライアントは既に存在しているのですから、これは一番の理由です。
それではサーバー側はどうでしょうか？ もし、Webアプリケーション「だけ」が解決方法であれば、企業システムであってもそれまでの実績やノウハウの蓄積から元々インターネット上のWebアプリケーションの主流であるCGIとPerlが主役であったはずです。しかし、実際に企業システムのWebアプリケーション開発基盤としてはWindows DNAやJ2EEが主流なのはご存知のとおりです。このことは、開発基盤と同時に紹介されたWeb3層モデル（図Web3Tier.png）こそが本質解だということを示唆しています。
すなわち、業務システムとしてのWebシステムを考えた場合、本質は
*HTTPによるクライアントからのアクセスプロトコルの一元化
*ビジネス層とプレゼンテーション層の分離
の2点です。
ここで重要なのは、一元化されたアクセスプロトコル（プレゼンテーション層としてのHTML、セッション層としてのHTTP、トランスポート層としてのTCP……）に対する万能クライアントとしてWebブラウザーが用意されていたという点です。そのため、クライアントサーバーの2つ目の問題点であるクライアント管理の問題が解消できるように錯覚し、すべてをWebブラウザーによって処理しようとしたことが悲劇の始まりです。
Webによって、業務アプリケーションの作成が統一されたモデルを持つようになったことは良いことですが、そろそろクライアントについて考え直すべき時期が来たのではないでしょうか。
もちろん、筆者はすべての処理に専用のクライアントアプリケーションを作成すべきと主張しているわけではありません。情報の参照が主眼となるような処理であれば、おそらくWebアプリケーションが良い選択でしょう。また、静的なコンテンツに対してわざわざ専用のクライアントアプリケーションを開発する意味はないでしょう。
それでは、どのようなアプリケーションをスマートクライアントとして実装すべきでしょうか。ちょっと考えただけでも次のような処理が挙げられます。
*データエントリー処理
*バックグラウンド印刷処理（定時レポート出力など）
*COMを利用したPC上でのアプリケーション連携処理
特にデータエントリーについては、専用アプリケーションであれば、ユーザーインターフェイスの自由度を抜きにしても、オフライン時にはディスクに格納し、バックグラウンドでネットワーク状態をチェックし、オンラインになった時点で送信を行うといったビジネスルール（これは業務処理そのものであるビジネス層のロジックとは異なります）を記述することも容易ですし、最悪の場合にはFDへ出力しバイク便でデータセンターへ送付するといった運用までカバーできます。
!スマートクライアントの要件
とは言え、Webアプリケーションの成果であるWeb3層構造やHTTPを捨てて、ビジネスロジックまでクライアントへ持ち込んでしまったり、ベンダー独自のRPCを利用しては（注）元の木阿弥です。スマートクライアントは基本的にはプレゼンテーション層のみを担うものでなければなりません。ただし、独自の表示処理を持っているのですから、HTMLを利用する必要はありません。そのかわりにクライアント、サーバー双方でプログラム的に扱いやすいXMLを利用すべきです。
なお、HTTPでXMLを利用するということは、必ずしもSOAPを使うという意味に限定されないことに注意してください。むしろ、スマートクライアント／データエントリという観点からは、複数のレコードを格納したバルクデータとしてXMLを扱うほうが望ましい場合もあるからです。
----
−−−−−−−Webサービス＝B2B？−−−−−−−
""なぜ、「Webサービス＝B2B」という不思議な公式が生まれたのでしょうか？ XMLの冗長性がイントラネット向きでないと言われますが、それならばHTMLやURLエンコードされたPOSTデータの冗長性が許容されるのはなぜでしょう。
""おそらく、この点についてはベンダーのエゴがあるように筆者は感じます。.NET陣営であればDCOMやRemoting、Java陣営であればJava/IDLやRMIといった独自のプロトコルを持っているため、イントラネットについてWebサービスと言い切ることに戦略的なまずさを感じているのが理由なのではないでしょうか。
""これらのプロトコルについてはサーバー間（Webサーバーとアプリケーションサーバー）専用と割り切り、クライアント／サーバー間は素直にHTTPを利用すべきと考えたほうが良いと筆者は考えます。
また、当然ですが、スマートクライアントはゼロメンテナンスの必要があります。具体的には、クライアント側で容認される問題領域外の操作は、実行のための起動だけでなければなりません。バージョンアップを含め、インストールを不要化することが必須です。もちろん、WebアプリケーションでもWebブラウザーのインストールやサービスパックの適用が必要なのと同様に、実行基盤（本稿では.NET Frameworkですし、Java Web StartならばJRE）のインストールは必要です。
この実行時のダウンロードを考えた場合、インストール元のアプリケーション配布サーバーとしても、Webサーバーを利用することが当然の帰結となります（smartclient.png）。運用面ではスマートクライアント自身をWebサーバーから配布することにより、直接クライアントがアクセスするサーバーと、使用するサービスを少なく保つことが可能となるからです。また、実装面からも、HTTPの
*サーバー上のファイルのメタデータ（更新日付、サイズなど）取得メソッドが存在する
*HTTPクライアント機能が実行環境に存在する
といった点を有効に利用できます。
なお.NET Frameworkがスマートクライアントの実行のためにデフォルトで提供しているのは、IEExce.EXEというインターネットエクスプローラのヘルパアプリケーションです。インターネットエクスプローラは、HTML上でリンクされたファイルが.NETのアセンブリであれば、IEExec.EXEを呼び出し、実行を依頼します。
ただし、IEExec.EXEは汎用であるため、
*AppDomainが有効活用されない
*キャッシュの制御がインターネット設定によって変動する
*イントラネットであってもセキュリティ制約が課せられる
といった業務システムのインフラとしては向かない点があります。
そのため、本稿では冒頭で述べたように筆者が作成したローンチャを利用した解説を行います。
!サンプルプログラムの説明
本稿でこれから取り上げるアプリケーション（NetLauncherという名称です）は、スマートクライアントのローンチャです（NetLauncherCap.png）。しかし、それと同時に、スマートクライアントの特徴を持ちます（ただし、ローンチャなので完全なスマートクライアントとするには自己更新機能が必要となり、それを含めるとコードと実行時の動作が相当煩雑になるため実装していません。自己更新機能の実装は読者への課題としましょう）。
NetLauncherの機能は以下のとおりです。
*起動時に構成ファイルから接続先サーバー名を得る
*サーバーへ接続し、構成ファイルが更新されているかを確認し、更新されていたら再取得する
*構成ファイルに登録されているアプリケーションの一覧を表示する
*この時、既にダウンロードされていれば実際のアプリケーションのアイコンを表示し、まだならば規定のアイコンを表示する
*アプリケーションがダブルクリックされたらサーバー上のアプリケーションの更新状態を確認し、まだダウンロードされていないか、またはサーバー上で更新されていたら再取得する
*サーバーがオフラインで、既にダウンロード済みならばそのアプリケーションを使用する
*AppDomainを生成し、アプリケーションを起動する
*実行中のアプリケーションのリストを表示し、強制終了を受け付ける
*実行中アプリケーションが例外で終了したら管理者に例外のスタック情報を添付したメールを送信する
実際にNetLauncherをインストールする場合には、接続先ホスト名と構成ファイルのサーバー上のパス名を記述した構成ファイルを含めます。それにより起動時に、最新の構成ファイルをサーバーから取得できるからです。なおサンプルには、最小限のセットアッププロジェクトを含めてありますので参照してください。
!!NetLauncherの構造
NetLauncherは（図UML.PNG）のようにMVCで実装してあります。
!!!LauncherForm
ビューに相当します。
登録されたアプリケーションがダウンロード済みであればメインのアイコンを、そうでなければ未ダウンロードを示すアイコンを表示します。
アイコンをダブルクリックすると、コントローラに対して実行を要求します。
また、現在実行中のAppDomainの表示とコンテキストメニューによる強制終了を受け付けます。
!!!WebLauncher
コントローラに相当します。構成ファイル（appicationList）から取得した内容でモデルの管理を行います。モデルの状態変更通知は、このクラスのイベントとして実装されます。また、AppDomainの生成（アプリケーションの起動）もこのクラスで実行します。
!!!Application（WebLauncherの内部クラスです）
モデルとして登録されているアプリケーションを表します。
!!!applicationList
スキーマコンパイラによって生成された構成ファイルのオブジェクト表現です。XMLのルート要素名から自動生成されるため、このクラスのみクラス名が小文字で開始されています。
!!!WebFile
ローカルにダウンロードしたファイルとサーバー上のファイルの日付の比較とダウンロードを行います。
!!!AssemblyFile
WebFileから派生したクラスです。アプリケーション（EXEファイル）だけでなく、アセンブリ内で参照している他のアセンブリについてもダウンロードを行います（注）。また、アイコンの取得をサポートします。
!!!IconLoader
P/Invokeを使用してアプリケーションのメインアイコンの取得を行うユーティリティです。
注）この実装では、DLLがさらに他のDLLを参照している場合の再帰的なダウンロードやサテライトアセンブリのダウンロード処理は含みません。
!XMLをデータ交換に利用する
XmlForDataExchange
!Webサーバー上のファイル情報の取得
HowtoGetFileFromWebServer
!Win32APIを呼び出してアイコンを取得
HowtoInteractWin32API[[HowtoInteractWin32API]]
!AppDomainの利点
WhatIsAppDomain
!AppDomainの作成と強制終了
CreateAndDestroyAppDomain
!メールの送信
SendMailWithDotNet
!まとめ
.NET Frameworkは最新の環境だけに、HTTP、SMTPといった標準プロトコルやXMLの利用について、ほとんどの機能があらかじめ実装されています。また、AppDomainのような仮想マシンで複数のアプリケーションを実行するのに必要となる環境も用意されています。
このようなサーバーサイドの開発にも有用な機能だけでなく、Windows フォームアプリケーションのようにクライアントサイドでの実行を意識したプログラムを短期間で開発するためのライブラリ（Windows フォーム）と開発環境（VS .NET）も備えています。また、P/Invokeのようにマネージドコードの中からネイティブAPIを呼び出すための機構もあります。Javaの場合、JNIを使用するとネイティブインターフェイス用にDLLという異質なファイルと異質な開発スキルが必要がなることに比較すると、Windows限定とは言えクライアントアプリケーション開発には有効な機能です。
システムを構築する場合に求められることのひとつに、現実に使用可能でかつ効果的なテクノロジーの知識があります。未だに情報が錯綜している感が否めない.NETですが、ここで紹介したようにWebサービス、Webアプリケーションだけではない使用方法があります。
もし、Webアプリケーションで実現するのが困難なソリューションを求められたら、スマートクライアントという選択肢もあるということを知っていただけたら幸いです。
----
!はじめに
2002年春のVisual Studio .NET登場から約1年が過ぎようとしています(注：2003年4月公開の原稿でした)が、いまだに.NETをどうビジネスへ適用するかについて混乱があるような気がします。特に、Windows フォームと呼ばれるクライアント向きライブラリの存在が、喧伝される.NETのインターネット指向、特にXML Web サービスやASP.NETとの関係が見えにくいこともその一因となっているようです。もちろん、これらのサーバーサイドの技術も重要ですが、そればかりに目を向けると、.NETが持つ重要な側面を見逃しかねません。
本稿では、企業内クライアントサーバシステム再構築のインフラという観点から、Windows フォームアプリケーションの利用方法について取り上げます。
実のところ、独立したクライアントアプリケーションとWebの融合というコンセプト（本稿ではこの形態のクライアントを「スマートクライアント」と呼びます）は何も.NETだけのものではありません。もしかしたら、既に読者の中にはJava Web Startテクノロジー（http://java.sun.com/products/javawebstart/ja/index_ja.html）を利用されている方がいるかも知れません。しかし、JNLP仕様が公開されているJavaと比較して、.NETではスマートクライアントについてのドキュメントや運用方法についての資料が乏しいのが現状です。理由の1つは最初に触れた.NETの適用に関する情報の混乱があると思います。本稿ではその点をかんがみて、最初にスマートクライアントの業務システムにおけるWebアプリケーションに対する優位性を解説します。次に、スマートクライアントのローンチャを例にして、実際に適用可能なスマートクライアント運用の基盤となる.NET Frameworkの技術解説を行います。取り上げるプログラミング上のトピックは
*スキーマコンパイラを利用したXMLのアクセス
*HTTPを利用した通信
*P/Invoke
*AppDomain
*Eメールの送信
です。
!Webアプリケーションの問題点
本誌の読者の皆さんには改めて説明するまでもないことですが、企業内システムがクライアントサーバーからWebアプリケーションへシフトしている主な理由は次の2点です。
*クライアント、サーバーそれぞれに必要となる開発スキルセットが異なり、さらにマルチベンダー環境だとサーバー毎に異なる開発／運用方法が求められること。これらは開発コストや運用コストが増大する理由となります。（図clientserver.png）
*クライアントアプリケーションの配備／保守の負荷が大きい。これにはインストールが必要となるためアプリケーションの入れ替えが容易ではないことから、いわゆるDLLヘル問題までを含みます。（図dllhell.png）
実際にはWebアプリケーションであっても、ブラウザーの種類やバージョンによって考慮しなければならない点や、サーバー側の開発に何を利用するかといった考慮点があります。それでも上に挙げた問題点はWebアプリケーションへの移行によって解消されるでしょう。
しかし、企業システムとして考えた場合、情報システムに求められることはあくまでも
*ビジネスの変化に合わせてタイムリーにソリューションの提供が受けられること
です。Webの導入はこの課題を解決するための手段であって、決してクライアントサーバーからWebアプリケーションへ移行することが問題の本質ではありません。
具体的には、Webアプリケーションへの移行は以下のような問題を抱えています。
*オペレーションの変更に伴う運用現場での教育コストの発生
*操作性の低下に伴う生産性の低下
*画面遷移に伴う処理遅延に対する運用現場からの不満
*オフライン発生（ネットワーク障害、サーバーメンテナンスなど）時の業務停止
*Webブラウザーのセキュリティモデルと業務要件の不整合
すでに、既存システムからWebアプリケーションへの移行を手がけられたことがあれば、業務部門からの「Enterキーは次の入力項目への移動」「10キーだけで処理ができなければダメ」「マウス不要」「スクロール不可」「Excelシートから入力項目を拾い出せ」というようなWebアプリケーションにとっては理不尽とも言える要求を突きつけられた経験をお持ちかも知れません。それに対して、「世の中の流れはWebだから」とかわしたり、ブラウザーのバージョン毎の動作の相違に苦しみながらJavaScriptを駆使したりするのは、やはり、本来目指しているものとは異なると言わざるを得ません。
現在の不況下にあって、コストセンターと見なされがちなシステム部門が効率的なオペレーションを図ることは望まれることですが、それによって、業務部門に対してしわ寄せが起きるようでは本末転倒のそしりを免れることはできません。また、業務部門の要求をブラウザーで実現するために苦労するのでは、少しも開発コストの削減にはなりません。
!Webアプリケーション再考
ここで、Webアプリケーションが業務システムのインフラとして注目され、実際に活用されるようになった理由について再考してみましょう。旧来のクライアントサーバーシステムの問題点について、2点あげましたが、この2つの問題の解をWebアプリケーションという言葉で一括りにしてしまうことが、問題の本質をわかりにくくしている原因だと考えられるからです。
まず、WebブラウザーのPCへの標準またはそれに近い形での搭載というものを挙げないわけにはいきません。HTTPサーバーを用意すれば、クライアントは既に存在しているのですから、これは一番の理由です。
それではサーバー側はどうでしょうか？ もし、Webアプリケーション「だけ」が解決方法であれば、企業システムであってもそれまでの実績やノウハウの蓄積から元々インターネット上のWebアプリケーションの主流であるCGIとPerlが主役であったはずです。しかし、実際に企業システムのWebアプリケーション開発基盤としてはWindows DNAやJ2EEが主流なのはご存知のとおりです。このことは、開発基盤と同時に紹介されたWeb3層モデル（図Web3Tier.png）こそが本質解だということを示唆しています。
すなわち、業務システムとしてのWebシステムを考えた場合、本質は
*HTTPによるクライアントからのアクセスプロトコルの一元化
*ビジネス層とプレゼンテーション層の分離
の2点です。
ここで重要なのは、一元化されたアクセスプロトコル（プレゼンテーション層としてのHTML、セッション層としてのHTTP、トランスポート層としてのTCP……）に対する万能クライアントとしてWebブラウザーが用意されていたという点です。そのため、クライアントサーバーの2つ目の問題点であるクライアント管理の問題が解消できるように錯覚し、すべてをWebブラウザーによって処理しようとしたことが悲劇の始まりです。
Webによって、業務アプリケーションの作成が統一されたモデルを持つようになったことは良いことですが、そろそろクライアントについて考え直すべき時期が来たのではないでしょうか。
もちろん、筆者はすべての処理に専用のクライアントアプリケーションを作成すべきと主張しているわけではありません。情報の参照が主眼となるような処理であれば、おそらくWebアプリケーションが良い選択でしょう。また、静的なコンテンツに対してわざわざ専用のクライアントアプリケーションを開発する意味はないでしょう。
それでは、どのようなアプリケーションをスマートクライアントとして実装すべきでしょうか。ちょっと考えただけでも次のような処理が挙げられます。
*データエントリー処理
*バックグラウンド印刷処理（定時レポート出力など）
*COMを利用したPC上でのアプリケーション連携処理
特にデータエントリーについては、専用アプリケーションであれば、ユーザーインターフェイスの自由度を抜きにしても、オフライン時にはディスクに格納し、バックグラウンドでネットワーク状態をチェックし、オンラインになった時点で送信を行うといったビジネスルール（これは業務処理そのものであるビジネス層のロジックとは異なります）を記述することも容易ですし、最悪の場合にはFDへ出力しバイク便でデータセンターへ送付するといった運用までカバーできます。
!スマートクライアントの要件
とは言え、Webアプリケーションの成果であるWeb3層構造やHTTPを捨てて、ビジネスロジックまでクライアントへ持ち込んでしまったり、ベンダー独自のRPCを利用しては（注）元の木阿弥です。スマートクライアントは基本的にはプレゼンテーション層のみを担うものでなければなりません。ただし、独自の表示処理を持っているのですから、HTMLを利用する必要はありません。そのかわりにクライアント、サーバー双方でプログラム的に扱いやすいXMLを利用すべきです。
なお、HTTPでXMLを利用するということは、必ずしもSOAPを使うという意味に限定されないことに注意してください。むしろ、スマートクライアント／データエントリという観点からは、複数のレコードを格納したバルクデータとしてXMLを扱うほうが望ましい場合もあるからです。
----
−−−−−−−Webサービス＝B2B？−−−−−−−
""なぜ、「Webサービス＝B2B」という不思議な公式が生まれたのでしょうか？ XMLの冗長性がイントラネット向きでないと言われますが、それならばHTMLやURLエンコードされたPOSTデータの冗長性が許容されるのはなぜでしょう。
""おそらく、この点についてはベンダーのエゴがあるように筆者は感じます。.NET陣営であればDCOMやRemoting、Java陣営であればJava/IDLやRMIといった独自のプロトコルを持っているため、イントラネットについてWebサービスと言い切ることに戦略的なまずさを感じているのが理由なのではないでしょうか。
""これらのプロトコルについてはサーバー間（Webサーバーとアプリケーションサーバー）専用と割り切り、クライアント／サーバー間は素直にHTTPを利用すべきと
また、当然ですが、スマートクライアントはゼロメンテナンスの必要があります。具体的には、クライアント側で容認される問題領域外の操作は、実行のための起動だけでなければなりません。バージョンアップを含め、インストールを不要化することが必須です。もちろん、WebアプリケーションでもWebブラウザーのインストールやサービスパックの適用が必要なのと同様に、実行基盤（本稿では.NET Frameworkですし、Java Web StartならばJRE）のインストールは必要です。
この実行時のダウンロードを考えた場合、インストール元のアプリケーション配布サーバーとしても、Webサーバーを利用することが当然の帰結となります（smartclient.png）。運用面ではスマートクライアント自身をWebサーバーから配布することにより、直接クライアントがアクセスするサーバーと、使用するサービスを少なく保つことが可能となるからです。また、実装面からも、HTTPの
*サーバー上のファイルのメタデータ（更新日付、サイズなど）取得メソッドが存在する
*HTTPクライアント機能が実行環境に存在する
といった点を有効に利用できます。
なお.NET Frameworkがスマートクライアントの実行のためにデフォルトで提供しているのは、IEExce.EXEというインターネットエクスプローラのヘルパアプリケーションです。インターネットエクスプローラは、HTML上でリンクされたファイルが.NETのアセンブリであれば、IEExec.EXEを呼び出し、実行を依頼します。
ただし、IEExec.EXEは汎用であるため、
*AppDomainが有効活用されない
*キャッシュの制御がインターネット設定によって変動する
*イントラネットであってもセキュリティ制約が課せられる
といった業務システムのインフラとしては向かない点があります。
そのため、本稿では冒頭で述べたように筆者が作成したローンチャを利用した解説を行います。
!サンプルプログラムの説明
本稿でこれから取り上げるアプリケーション（NetLauncherという名称です）は、スマートクライアントのローンチャです（NetLauncherCap.png）。しかし、それと同時に、スマートクライアントの特徴を持ちます（ただし、ローンチャなので完全なスマートクライアントとするには自己更新機能が必要となり、それを含めるとコードと実行時の動作が相当煩雑になるため実装していません。自己更新機能の実装は読者への課題としましょう）。
NetLauncherの機能は以下のとおりです。
*起動時に構成ファイルから接続先サーバー名を得る
*サーバーへ接続し、構成ファイルが更新されているかを確認し、更新されていたら再取得する
*構成ファイルに登録されているアプリケーションの一覧を表示する
*この時、既にダウンロードされていれば実際のアプリケーションのアイコンを表示し、まだならば規定のアイコンを表示する
*アプリケーションがダブルクリックされたらサーバー上のアプリケーションの更新状態を確認し、まだダウンロードされていないか、またはサーバー上で更新されていたら再取得する
*サーバーがオフラインで、既にダウンロード済みならばそのアプリケーションを使用する
*AppDomainを生成し、アプリケーションを起動する
*実行中のアプリケーションのリストを表示し、強制終了を受け付ける
*実行中アプリケーションが例外で終了したら管理者に例外のスタック情報を添付したメールを送信する
実際にNetLauncherをインストールする場合には、接続先ホスト名と構成ファイルのサーバー上のパス名を記述した構成ファイルを含めます。それにより起動時に、最新の構成ファイルをサーバーから取得できるからです。なおサンプルには、最小限のセットアッププロジェクトを含めてありますので参照してください。
!!NetLauncherの構造
NetLauncherは（図UML.PNG）のようにMVCで実装してあります。
!!!LauncherForm
ビューに相当します。
登録されたアプリケーションがダウンロード済みであればメインのアイコンを、そうでなければ未ダウンロードを示すアイコンを表示します。
アイコンをダブルクリックすると、コントローラに対して実行を要求します。
また、現在実行中のAppDomainの表示とコンテキストメニューによる強制終了を受け付けます。
!!!WebLauncher
コントローラに相当します。構成ファイル（appicationList）から取得した内容でモデルの管理を行います。モデルの状態変更通知は、このクラスのイベントとして実装されます。また、AppDomainの生成（アプリケーションの起動）もこのクラスで実行します。
!!!Application（WebLauncherの内部クラスです）
モデルとして登録されているアプリケーションを表します。
!!!applicationList
スキーマコンパイラによって生成された構成ファイルのオブジェクト表現です。XMLのルート要素名から自動生成されるため、このクラスのみクラス名が小文字で開始されています。
!!!WebFile
ローカルにダウンロードしたファイルとサーバー上のファイルの日付の比較とダウンロードを行います。
!!!AssemblyFile
WebFileから派生したクラスです。アプリケーション（EXEファイル）だけでなく、アセンブリ内で参照している他のアセンブリについてもダウンロードを行います（注）。また、アイコンの取得をサポートします。
!!!IconLoader
P/Invokeを使用してアプリケーションのメインアイコンの取得を行うユーティリティです。
注）この実装では、DLLがさらに他のDLLを参照している場合の再帰的なダウンロードやサテライトアセンブリのダウンロード処理は含みません。
!XMLをデータ交換に利用する
XmlForDataExchange
!Webサーバー上のファイル情報の取得
HowtoGetFileFromWebServer
!Win32APIを呼び出してアイコンを取得
!AppDomainの利点
WhatIsAppDomain
!AppDomainの作成と強制終了
CreateAndDestroyAppDomain
!メールの送信
SendMailWithDotNet
!まとめ
.NET Frameworkは最新の環境だけに、HTTP、SMTPといった標準プロトコルやXMLの利用について、ほとんどの機能があらかじめ実装されています。また、AppDomainのような仮想マシンで複数のアプリケーションを実行するのに必要となる環境も用意されています。
このようなサーバーサイドの開発にも有用な機能だけでなく、Windows フォームアプリケーションのようにクライアントサイドでの実行を意識したプログラムを短期間で開発するためのライブラリ（Windows フォーム）と開発環境（VS .NET）も備えています。また、P/Invokeのようにマネージドコードの中からネイティブAPIを呼び出すための機構もあります。Javaの場合、JNIを使用するとネイティブインターフェイス用にDLLという異質なファイルと異質な開発スキルが必要がなることに比較すると、Windows限定とは言えクライアントアプリケーション開発には有効な機能です。
システムを構築する場合に求められることのひとつに、現実に使用可能でかつ効果的なテクノロジーの知識があります。未だに情報が錯綜している感が否めない.NETですが、ここで紹介したようにWebサービス、Webアプリケーションだけではない使用方法があります。
もし、Webアプリケーションで実現するのが困難なソリューションを求められたら、スマートクライアントという選択肢もあるということを知っていただけたら幸いです。