初めて作る.NET Windowsサービス：Visual Studio Magazine（7/7 ページ）

[Doug Thews，FTPOnline]

　実際のところおそらく実環境では、この種のモニタリングの設計は採用しないだろう。そのわけは、ファイルI/Oと単純にしすぎた整数のサービスコマンドに頼り切っているためだ。

　よりエレガント（だが複雑な）設計では、サービスのOnStartメソッドにおいて、分離されたスレッドを生成するようにするだろう。このスレッドでは、アプリケーションのモニタリングコマンドのためのメッセージキューを初期化する。そうしておいて、AppMonitorサービス自身が整数コマンドを実行するのではなく、MonitorWrapperクラスがメッセージキューと通信するように変更する。

　新しいWindowsサービスの配置準備が整ったら、それをコンパイルして改訂し、現在のバージョンと共にサイドバイサイドで実行できるよう、新しいMonitorWrapperクラスをGACに配置する（訳注：サイドバイサイドとは、.NET Frameworkにおいてコンパイルした時に、参照設定したアセンブリと同じバージョンのアセンブリを実行時にも使う機能）。古いAppMonitorサービスと並行してサイドバイサイドで実行できるようにするために、新しいWindowsサービスにはバージョンに依存する重複しない名前を与えることになる。

　デスクトップアプリケーションが新しいモニタリングの設計を利用できるようにするには、単に新しいMonitorWapperクラスを参照設定し直して再コンパイルするだけでよい。これで、.NETでWindowsサービスを開発する基礎知識が身に付いたはずだ。

　すでにお分かりのように、Visual Studio .NET 2003では、サービスを簡単に作成ならびに配置できる。そしてサービスイベントのフックはどんな.NET言語でも構築でき、もっとも複雑とも言えるWindowsサービスを構築するときの強い基盤となってくれる。

　今回例示した単純な設計は、より高負荷に耐えられるようにするために容易に拡張可能だ。そうとはいえ、本稿は「Getting Startedコラム」だ（訳注：原文はVisual Studio Magazineの「Getting Startedコラム」に掲載されたものである）。それゆえ、スレッドやMSMQを使ってどのようにAppMonitorサービスを拡張させればよいのかという点については、後の課題としたい。

　理想的なモニタリングの設計には、私が過去6カ月の間にVisual Studio Magazineに書いた.NETのテクノロジー（スレッドやMSMQ）とWindowsサービスとを組み合わせて、このAppMonitorサービスを改良すれば良いとだけ書いておこう。

著者について：

Doug Thews氏は、ダラスのD&D Consulting Servicesのソフトウェア開発ディレクター。C/C++、VB/ASP、VB.NET/C#による19年以上のソフトウェア開発経験がある。Visual Studio Magazineの「Getting Startedコラム」の執筆者で、「Professional ASP.NET Performance」（Wrox/Wiley Press刊）の共著者）

日本語訳：大澤文孝