- - PR -
.NET Windowsサービスのエラー通知方法のバリエーションについて
投稿者 | 投稿内容 | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2005-05-24 15:17
Win2K Pro + VS.NET 2003 C# + .NET Framework v1.1 SP1でWindowsサービスを開発しております。
このWindowsサービスはサービス起動時にだけDBからそのクライアント端末に必要な情報を取得してから常駐し、他APから要求があったら取得したデータを渡す、というサービスなのですが、エラー時の通知方法に頭を悩ませています。 通常、Windowsサービスがエラーを通知する方法はイベントログだそうですが(当方サービス開発初心者です)、本サービスがエラーを起こした場合(e.g.DBへ通信エラー、取得したデータの不整合、DBのエラー、etc...)はオペレータにもっと判りやすく通知して欲しいとリクエストがありました。 そこで2つ案を考えましたが、より良い方法は無いか皆さんにご意見伺いたく投稿致しました。もし良いアイデアがあれば是非ご教授お願い致します。 案@ダイアログを表示する・・・一番判り易いがサービス側で「デスクトップと対話」のオプションやアンマネージコードが必要になってしまう。ログオンしている/していないを考慮しないといけないのではないか? 案A常駐後、最初にリクエストしてきたAPにダイアログを表示してもらう・・・サービスを利用(.NET Remoting)するため全APはサービスのクライアントモジュールを参照させているためAPに作りこみは必要無いが、リアルタイムでエラー通知できない。 宜しくお願い致します。 | ||||||||||||
|
投稿日時: 2005-05-24 15:27
私だけかもしれませんが、
「DBサーバ」「Windowsサービス」「クライアント端末」「他AP」の関係がイマチチわかりません。 どのような構成になっているのでしょうか? | ||||||||||||
|
投稿日時: 2005-05-24 15:47
すいません、分かり難さに気づきませんでした。
■マシンの構成 マシンの構成はクライアント端末一台、DBサーバ端末一台です。DBサーバにはIISがありクライアント端末上のAP(含む本サービス)はWebサービス経由でDBへアクセスできます。クライアント端末は前述の開発環境と同じです。 [クライアント端末] <--Http(Soap)-->[DBサーバ端末+IIS] ■クライアント端末のソフト構成 クライアント端末内のソフト構成はWindowsサービス、そのサービスへのプロセス間通信機能を提供するクライアント用アセンブリ、サービスを利用する通常のオペレータが使うWindowsAPから構成されています。サービスの利用者であるWindowsAPは沢山あります。 [Windowsサービス] <-Remoting-> [通信用アセンブリ] <-参照-> [通常のAP] あくまでクライアント端末のローカル内での話ですのでDBサーバはあまり関係ありませんが、具体的な関係を書いた方が分かり易いかと思ったのですが反って分かり難くしてしまいました。 | ||||||||||||
|
投稿日時: 2005-05-24 16:03
●メールで通知する。
システム構成にメールサーバを追加する必要がありますが・・・。 携帯のメールに登録して、土日にやられた日には、(以下略 ●MSMQ(キュー)に投げて、処理を任せる。 キューサーバを立ててまでやるほど、 大げさなものではないでしょうが。(汗 | ||||||||||||
|
投稿日時: 2005-05-24 16:11
Windowsサービスでエラーログをファイルに出力して、
AP側でFileSystemWatcherで監視する。 微妙ですね。。。。 | ||||||||||||
|
投稿日時: 2005-05-24 22:48
なぜ、サービスを作る必要があったのでしょう?アプリケーションが直接データベースとやりとりしても良かったのでは?
「複数のアプリケーションがあって、それぞれに作り込むのは無駄」というのであれば、DLL形式のアセンブリを作って、それを参照させれば良かった話ですよね。 それと、サービスが最初に起動したときにデータを取り込む、ということですが、その時に例えばサーバが再起動中でデータを取り込めなかったとき、一般ユーザはマシンを再起動しなければならないのでしょうか?(ユーザがサービスの再起動の方法を知っている場合、その方法を提供している場合を除く) イントラネットで使用するなら、ドメイン間通信を使う方がSOAPでやりとりするより速そうですし、データベースクライアントアプリをインストールする必要もなくなるため、WindowsサービスがDBサーバでのみ動いている、というのなら、理解できるのですが。 _________________ | ||||||||||||
|
投稿日時: 2005-05-25 11:08
レスポンスが遅く申し訳ありません。VIMさん、burton999さん、ご意見有難う御座います。
皆様のご意見ではWindowsサービス自体にエラー通知させるのではなく代理人を立て、その代理人にエラー通知をさせるという点が共通しているように感じました。またサービスはデスクトップにログオンしていない状態でも常駐できる点からも、少なくともサービスから直接ダイアログを表示するような設計は止めておこうと思います。 | ||||||||||||
|
投稿日時: 2005-05-25 11:53
Jittaさんご意見有難うございます。ご質問に回答致します。
ご指摘の通り、設計の際にサービスと通常のEXEとで議論になりました。最終的にサービスとなった理由はクライアント端末では利用するログオンアカウントはほとんどのリソースに対して読取りの権限しかありません。よってDBから取得したデータを保持するのに通常のEXEだとレジストリ、ファイルに保存できません。メモリを使うなら常駐しなければなりません。権限と保存場所をメモリとして実装する場合も考えてサービスに決定しました。
ユーザが業務中にサーバがダウンする正常ケースは無いシステムですが、障害ケースではユーザの端末を再起動することになります(ユーザはサービスを再起動できる権限がないので)。
イントラネットなのですが端末、DBサーバ間にファイアウォールがあるため.NET Remoting(TCPの)では無くXML Webサービス(HTTP+SOAP)で通信することになっています。ちなみにDBクライアントアプリはクライアント端末には入らない設計になっています。 |