Windowsサービスの実用的な用途は何ですか？[閉まっている]

Windowsサービスを使用するのは初めてです。VS2010でWindowsサービスを作成することを学びましたが、Windowsサービスを使用できる実用的な方法を知りたいですか？

現在のコンテキストを念頭に置いてグーグルを試し、Windowsサービスの作成方法に関するチュートリアルをさらに見つけました。

バウンティオファーの編集：

すべての答えは素晴らしいですが、私はWindowsサービスとその意味に関するより実用的な例を探していましたか？これは、開発者がケーススタディでそれらを使用するのが適切である時期を知るのに役立ちます。

誰もマシンにサインオンしていなくても、サービスはバックグラウンドで実行されます。人に頼らずにアプリを起動してボタンをクリックすることを望んでいると想像できるものはすべて、サービスの良い候補です。たとえば、フォルダーを監視し、ファイルが書き込まれるたびに何らかの方法で処理します。Webサーバー、FTPサーバー、メールサーバーなど、考えられる「サーバー」はサービスであり、多くの場合、あまり考えられないバックグラウンドプロセスでもあります。

かつてサービスとして書かれていたもの（午前2時にファイルをバックアップする、午前3時にリマインダーメールを送信するなど）は、おそらくWindows 7以降で非常に柔軟性のあるスケジュールされたタスクとしてより適切に行われます。システムはXPをサポートする必要があります。また、これらの種類のタスクを実行するサービスもあります。

Windowsのサービスは、基本的にGUIなしで実行されるプログラムです。Webサーバー（Apacheなど）、データベースサーバー（mysql＆sqlサーバーなど）、ウイルス対策エンジン、およびアプリケーション/「ミドルウェア」サーバーはすべて、サービスとして実行されることが多いアプリケーションの実用的な例です。サービスと対話するためのGUIクライアントが存在する場合がありますが、サービス自体にはありません。「バックグラウンドで」実行され、その処理を行います。さらに、サービスは割り当てられたユーザー権限で実行されるため、割り当てられたユーザーとして実行できます。ユーザーが実際にマシンにログインしているかどうか。そのため、データベースサーバーは、その時点でマシンにログインしているユーザー（存在する場合）に関係なく、同じアクセス権を持ちます。そのため、なぜそれが重要なのかがわかります。たとえば、Webサーバーを実行し続けるためにユーザーをログインさせ続ける必要はありません。

それらは、* nix上のデーモンに相当する（ほとんどの実用的な方法で）Windowsに相当します。

サービス

特定のシステム機能を実行して、特に低（ハードウェアに近い）レベルで他のプログラムをサポートするプログラム、ルーチン、またはプロセス。ネットワークを介してサービスを提供する場合、サービスをActive Directoryで公開して、サービス中心の管理と使用を促進できます。

Windowsサービスを使用できる実用的な方法を教えてください。

サービスの定義に従って、Window Serviceおよびその他のタイプのサービスは多くの機能を実行します。この文脈では、検索エンジンはあなたの友人です。

通常、Windowsサービスは、アプリケーションを継続的に実行する必要がある場合に使用されます。ユーザーとの対話なしで、バックグラウンドでコードを実行するWindowsサービスを作成する必要があります。

誰もログオンしていない場合でも、Windowsサービスが実行されます。Windowsサービスは、マシンの電源が投入されるとすぐに実行を開始できるため、サーバー（httpサーバーなど）として実行するのに最適です。ログインする必要はありません。

たとえば、必要な場合：

1. 着信要求を待ちます。（リモート処理またはwcfを介して）
2. キュー、ファイルシステムなどを監視します。プログラムを1日に1回など定期的に実行する必要がある場合。通常、スケジュールされたタスクを作成する方が簡単です。
3. 接続を受け入れるサーバー（メール、Web、FTPサーバーなど）は通常、Windowsサービスである必要があります。

次の理由でサービスを使用します。

• セッションを実行する必要はありません。これはセキュリティに役立ち、サーバーのオーバーヘッドも削減します。

• いくつかの管理コマンドが無料で組み込まれています
  o開始
  o停止
  o一時停止
  o続行

• シャットダウンなどのサーバーイベントを処理できます。

これらのサービスに関する追加情報のリンク：

Asp.net- // TODONT：スケジュールされたプロセスを実行するためだけにWindowsサービスを使用する
WIndowsサービスの使用とは

winformやWPFなどの対話型プログラムは、ユーザーに開いて操作して閉じてもらいたいものです。スケジュールされたタスクは、特定の時間としてバックグラウンドで実行したいものです-単に起動して、何かをして、停止するだけかもしれません。A Windowsサービスは、あなたがバックグラウンドですべての時間を実行したいものです。

Windowsサービスのいくつかの利点は、ログインしているユーザーに関係なく（またはログインしているユーザーがいない場合でも）実行され、コンピューターが起動するとすぐに実行を開始するように設定できることです。システムがリブートされます。

私は通常、フォルダやメールの受信トレイなどを監視する必要があるときにサービスを使用しました。

質問に実用的な例に関するメモを追加したので、エンタープライズアプリケーション用に作成したサービスの例をいくつか示します（エンタープライズアプリケーションプログラマーであるかどうかはわかりませんが、ほとんどのC＃VS2010プログラマーはそうです） 。マイクロソフトで働いていない開発者が何を書くかについてのアイデアを探していると思います。

他のプログラムがまだ実行されているかどうかをチェックするハートビートモニターサービス（これはスケジュールされたタスクとしても機能していたかもしれませんが、サービスとして実装されていました）。

レポートリクエストのキューを処理してレポートを実行し、ビジー状態のプリンターに応じて異なるプリンターに送信するレポート作成サービス。これにより、従来のアプリケーションからかなりの量の作業をオフロードし、実行中のレポートをサービスを実行している複数の安価なボックスで共有することができました。

継続的に実行され、再起動時に自動的に起動し、標準のWindowsサービスインターフェイスを使用して起動、停止、一時停止などを行えるように、サービスとして実装されました。また、スケジュールされたタスクの場合は、他のプログラムの呼び出し（ソケット、パイプ）ではなく、他のプログラムまたは永続ソース（キュー、ファイル、データベース）からのデータ取得を開始します。

そのクライアント/サーバーアプリケーションのサーバー部分も、再起動などで再起動するようにサービスとして実装されました。同じプログラムを実行する.exeを含む別のプロジェクトがありました いました。サービスとしてではなく開発マシンでデバッグします。

それがお役に立てば幸いです。ただし、他の回答は一般的な回答よりも優れています。特に、現在のほとんどの目的では、スケジュールされたタスクの作成と管理がおそらくおそらく簡単だという考えです。

サービスには多くの実用的な用途があります。主な実用的な使用法の1つは、UIとサービス（またはUNIXのデーモン）プログラムとの相互作用です。これは、この場合、クライアントとサーバーの違いです。サーバーはリクエストを受信し、リクエストを処理し、通常は返信を返します。つまり、リクエストを処理します。SQLSERVER、IIS、またはtelnetについて考えてください。クライアントは、通常、サーバーに要求を送信し、応答を表示または処理することでサーバーを利用します。すなわち、データ入力アプリケーション、Webアプリケーション...サーバーはほとんどの場合Windowsのサービス（またはUNIXのデーモン）としてインストールされ、クライアントは通常GUIを備えた通常のアプリです。サービスにはさらに多くの複雑な用途がありますが、これはおそらく最もよく使用するものです。

例：現在、SIP / H323ビデオサーバーで作業しています。作成したSDKを使用してアプリケーションからリクエストを受信し、それらを処理して、返信します。ビデオサーバーアプリケーションは、埋め込みLinuxマシンにデーモンとしてインストールされ（埋め込みWindowsマシンのサービスですが、埋め込みにWindowsを使用します）、SDKを利用するアプリケーションはすべてクライアントと見なされます。

もちろん、このようなアプリケーションを作成して、サービスにすることはできません。Windowsの起動時にそれらを起動し、バックグラウンドで実行させることもできます。ただし、いくつかのレジストリエントリとコードの仕上げが含まれます。.NETなどの場合よりも、c APIを使用する方がはるかに簡単です。一方、Microsoftは、サービスを作成し、それをOSに登録できるようにすることで、これを非常に簡単にしました。手動で行うよりもはるかに簡単で実装が簡単です。

候補プログラムの例：

• リソース/他のアプリケーションを監視し、レポート（ユーザーアクティビティ、特定の種類のファイルトラフィック、アプリケーションの誤動作の通知）を送信する必要があるシステム

• 他のローカルアプリケーションにサービスを提供するシステム（翻訳、ファイル変換、システム間メッセージング）

• ウイルス対策ソフト。

これらは、スケジュールされたタスクを使用して簡単に実行できない大きな例だと思います。

サービスを使用する私のお気に入りの例：

1. サーバー -リモートクライアントからの要求を処理するプログラム。通常、これらのサービスはサービスとして実行され、ユーザーがサーバーにログインしているかどうかに関係なく、それらが利用可能であることを確認します。また、サービスとして実行すると、マシンが起動するとすぐにサーバーがリクエストの処理を開始し、何らかの理由でマシンを再起動した後、プログラムを起動するために誰もマシンにログインする必要がなくなります。データベースサーバーはその良い例です。
2. バックグラウンド処理 -データソースからのデータを処理し、結果をデータターゲットに保存するプログラム。多くの場合、データターゲットは別のプロセスのソースなどです。サービスとして実行すると、これらのプログラムはそこに座ってデータが到着するのを待つことができます。また、プロセスを複数の半独立ステップに分割することにより、開発者は処理の堅牢性を向上させることができます。

以下に、実際のコードを使用したサービスコンセプトの使用例を示します（以下を参照）。

それは、キューから消費し、WebサーバーとクライアントGUIからのメッセージをリッスンするサービスバスを構成することです。

メッセージを受信すると、ドメインが保証するロジックを実行し、イベントをディスクに保存し、それらのイベントをメッセージブローカーに公開します。

疎結合の大規模なアプリケーションのほとんどは、以下のような「ワーカー」アーキテクチャを実装しています。

Documentlyプロジェクトは、あなたのような人々が分散アーキテクチャを学ぶために作成したサンプルプロジェクトです。プロジェクトで私に直接質問するか、分岐して学習する機能を実装し、プルリクエストを送信します（そしてコードのコメントを取得します）。

https://github.com/haf/Documently/blob/master/src/Documently.Domain.Service/Program.cs：

using System.Threading;
using Castle.MicroKernel.Registration;
using Castle.Windsor;
using Documently.Infrastructure;
using Documently.Infrastructure.Installers;
using MassTransit;
using Topshelf;
using log4net;
using log4net.Config;

namespace Documently.Domain.Service
{
    class Program
    {
        private static readonly ILog _Logger = LogManager.GetLogger(typeof (Program));

        private IWindsorContainer _Container;
        private IServiceBus _Bus;

        public static void Main(string[] args)
        {
            Thread.CurrentThread.Name = "Domain Service Main Thread";
            HostFactory.Run(x =>
            {
                x.Service<Program>(s =>
                {
                    s.ConstructUsing(name => new Program());
                    s.WhenStarted(p => p.Start());
                    s.WhenStopped(p => p.Stop());
                });
                x.RunAsLocalSystem();

                x.SetDescription("Handles the domain logic for the Documently Application.");
                x.SetDisplayName("Documently Domain Service");
                x.SetServiceName("Documently.Domain.Service");
            });
        }

        private void Start()
        {
            XmlConfigurator.Configure();
            _Logger.Info("setting up domain service, installing components");

            _Container = new WindsorContainer()
                .Install(
                    new RavenDbServerInstaller(),
                    new CommandHandlerInstaller(),
                    new EventStoreInstaller(),
                    new BusInstaller(Keys.DomainServiceEndpoint)
                    );

            _Container.Register(Component.For<IWindsorContainer>().Instance(_Container));
            _Bus = _Container.Resolve<IServiceBus>();

            _Logger.Info("application configured, started running");
        }

        private void Stop()
        {
            _Logger.Info("shutting down Domain Service");
            _Container.Release(_Bus);
            _Container.Dispose();
        }
    }
}

しばらく前に、私のチームは以下のようにブラジルの銀行に3つのWindowsサービスを実装しました。

• システム間のインターフェース：株式市場での取引の予約を担当するフロントオフィスアプリケーションと、取引手数料の計算と計算を担当するバックオフィスアプリケーションがありました。当初、システム間通信はSQL Server上で直接行われましたが、ロックと保持の問題が多すぎるため、システムのパフォーマンスが低下していました。フロントデータベースとバックデータベースの両方に接続し、何らかの保持戦略を使用して適切な読み取り/書き込みを行うサービスが実装されました（SQL Serverですべての取引を書き込む代わりに、1000取引など、ある程度の範囲でデータを保持し、元のソリューションよりも40倍高速な一括挿入を行い、関係するテーブルの多くを長時間ロックしませんでした）。

• メッセージキュー：以前のソリューションに加えて、カスタムメッセージキューハンドラを作成したため、いくつかのバッチ処理手順を非同期に実行できました。これは、MSMQとIBM-MQSeriesの両方に統合されました。

• ビジネスサービスの集中化：たとえば、いくつかのユーザーアプリケーションは株価として共通のデータを必要としたため、「価格リクエスト」を受信して​​価格情報を送り返すカスタムサービスを作成しました。

「ロボット」の代わりにサービスを記述するようになった側面の1つは、サービスが特定のユーザーとして（このスレッドで既に指摘されているように）実行でき、マシンの起動時に自動的に開始できることです。

また、サービスを実行するためにデスクトップまたはウィンドウ管理サービスは必要ありません。バックグラウンドで実行できます（バックグラウンドで実行する必要があります）。

また、ユーザーインターフェースの作成を好まない同業者と同じような場合、通常、サービスは失敗してはならないため、サービスは大きな技術的課題です。ですから、サービスを書くのはとても楽しいです。:)

標準ユーザーとして実行する必要があるが、管理者権限を必要とするタスクを実行する必要があるWindowsデスクトップアプリケーションを設計している場合は、サービスを使用できます。

インストーラーは必要な権限でサービスをインストールします。管理者権限でタスクを実行する必要がある場合、デスクトップアプリケーションはサービスを呼び出します。

このアプローチには、この回答の範囲を超えたセキュリティへの影響があります。

プログラマーにとって、サービスを使用する主な理由は次のとおりです。

• このプログラムは、再起動後にWindowsマシンで自動的に起動する必要があります。

上記に準拠する必要があるものはすべて、Windowsサービスとして実行する必要があります。

エンドユーザーの観点から、私が書いた最も有用なサービス：
*ユーザーは、RAWプリントドライバーを備えたドットマトリックスプリンターでUGLYインボイスを印刷しました。
*ユーザーは、ロゴ、滑らかなグラフィックスを備えたPRETTYインボイスを望んでいました。
*レガシーコードへのアクセスなし。

サービスは次のようになります。
*印刷ジョブの（複数の）プリンターフォルダーを監視します。
*請求書のPDFを作成します。
* PDFは素敵な空の請求書画像を「アンダーレイ」し
ます
* 生テキストをオーバーレイします*使用中のフォルダーに基づいてメタデータを検索します（IE：使用中のプリンター）

メタデータは次のようになります：
* PDFを生成
*および/またはPDFを印刷
*および/またはPDFを最終的な保存先フォルダにファイルする
*および/またはPDFを削除する
*および/またはPDF請求書を顧客にメールで送信

この場合、ゴーストスクリプト、PLC、およびPDFエンジンを処理します。それは何年も非常にきれいに実行されています。ログファイルを含める!!!