Windowsサービスの実際の用途は何ですか？
私はWindowsサービスを使用するのが初めてです。私は作成することを学びました VS2010のWindowsサービス Windowsサービスを使用できる実用的な方法をいくつか知りたいのですが？
現在のコンテキストを念頭に置いてグーグルを試してみたところ、Windowsサービスの作成方法に関するチュートリアルがさらに見つかりました。
バウンティオファーの編集：
すべての答えは素晴らしいですが、Windowsサービスとその影響に関する実用的な例をもっと探していましたか？これにより、開発者は、ケーススタディでそれらを使用するのが適切な時期を知ることができます。
誰もマシンにサインオンしていなくても、サービスはバックグラウンドで実行されます。ユーザーがアプリを起動してボタンをクリックすることを頼りにせずに、やりたいと思っていることはすべて、サービスの良い候補です。たとえば、フォルダを監視し、ファイルがそこに書き込まれるたびに、何らかの方法で処理します。 Webサーバー、ftpサーバー、メールサーバーなど、考えられる「サーバー」はすべてサービスであり、あまり考えられない多くのバックグラウンドプロセスもサービスです。
かつてサービスとして作成されたいくつかのこと（午前2時にバックアップファイル、午前3時にリマインダーメールを送信など）は、Windows 7以降で非常に柔軟性のあるスケジュールされたタスクとして今日より適切に実行されますが、開発者がそれらを学習したことがない場合、またはシステムはXPをサポートしている必要があります。そうした種類のタスクを実行するサービスも見つかります。
Windows上のサービスは、基本的にGUIなしで実行されるプログラムです。 Webサーバー（Apacheなど）、データベースサーバー（mysqlおよびsqlサーバーなど）、ウイルス対策エンジン、アプリケーション/「ミドルウェア」サーバーはすべて、サービスとして実行されることが多いアプリケーションの実用的な例です。サービスとの対話を可能にするGUIクライアントがあるかもしれませんが、サービス自体にはありません。 「バックグラウンドで」実行され、その処理を実行します。さらに、サービスは割り当てられたユーザー権限で実行されるため、ユーザーが実際にマシンにログインしているかどうかに関係なく割り当てられたユーザーとしてを実行できます。そのため、データベースサーバーには、そのマシンにログインしているユーザーが存在するかどうかに関係なく、同じアクセス権が与えられます。そのため、それが重要である理由を確認できます。たとえば、Webサーバーを実行し続けるためにユーザーをログインしたままにする必要はありません。
これらは、Windowsで* nix上のデーモンと（ほとんどの実用的な方法で）同等のものです。
サービス
特に低（ハードウェアに近い）レベルで他のプログラムをサポートする特定のシステム機能を実行するプログラム、ルーチン、またはプロセス。ネットワーク経由でサービスを提供する場合、サービスをActive Directoryで公開できるため、サービス中心の管理と使用が容易になります。
Windowsサービスを使用できる実用的な方法を教えてください。
サービスの定義に従って、ウィンドウサービスやその他のタイプのサービスは多くの機能を実行します。この文脈では 検索エンジンはあなたの友達です 。
Windowsサービスは通常、アプリケーションを継続的に実行する必要がある場合に使用されます。 ユーザーの操作なしにバックグラウンドでコードを実行するWindowsサービスを作成する必要があります。
誰もログオンしていない場合でも、Windowsサービスは実行されます。 Windowsサービスは、マシンの電源が入るとすぐに実行を開始できます。これは、httpサーバーなどのサーバーとしての実行に最適です。ログインする必要はありません。
たとえば、彼らがする必要がある場合：
- 着信要求を待ちます。 （リモーティングやwcfなど）
- キュー、ファイルシステムなどを監視します。プログラムが1日1回など、定期的に実行する必要がある場合。通常は、スケジュールされたタスクを作成する方が簡単です。
- 接続を受け入れるサーバー（メール、Web、FTPサーバーなど）は通常、Windowsサービスである必要があります。
次の理由でサービスを使用します。
- セッションを実行する必要はありません。これはセキュリティに役立ち、サーバーのオーバーヘッドも削減します。
いくつかの管理コマンドが無料で組み込まれています
o開始
o停止
o一時停止
o続行シャットダウンなどのサーバーイベントを処理できます。
これらのサービスに関する追加情報とのリンク：
Asp.netで- // TODONT：スケジュールされたプロセスを実行するためだけにWindowsサービスを使用
Windowsサービスの使用とは
WinformやWPFのような対話型プログラムは、ユーザーが開いて、対話して閉じたいものです。スケジュールされたタスクは、特定の時間にバックグラウンドで実行したいものです-単に起動して、何かをして、停止するだけかもしれません。 Windowsサービスは、常にバックグラウンドで実行したいものです。
Windowsサービスのいくつかの利点は、ログインしているユーザーに関係なく（またはユーザーがログインしていなくても）実行され、コンピューターが起動するとすぐに実行を開始するように設定できることです。これは、システムが再起動されます。
フォルダやメールの受信トレイなどを監視する必要がある場合は、通常、サービスを使用しています。
実用的な例についてのメモを質問に追加したので、私がエンタープライズアプリケーション用に作成したサービスの例をいくつか示します（エンタープライズアプリケーションプログラマーであるかどうかはわかりませんが、ほとんどのC＃VS2010プログラマーはそうだと思います） 。マイクロソフトで働いていない開発者が何を書いているかというアイデアを探していると思います。
他のプログラムがまだ実行されているかどうかを確認するハートビートモニターサービス（これもスケジュールされたタスクとして機能した可能性がありますが、サービスとして実装されていました）。
レポート要求のキューを処理し、レポートを実行して、ビジー状態のプリンターに応じて異なるプリンターに送信するレポート作成サービス。これにより、レガシーアプリケーションからかなりの量の作業をオフロードできるようになり、実行中のレポートを、サービスを実行している安価な複数のボックスで共有できるようになりました。
継続的に実行され、再起動時に自動的に開始し、標準のWindowsサービスインターフェイスを使用して開始、停止、一時停止などができるように、サービスとして実装されました。また、スケジュールされたタスクの場合は、他のプログラムの呼び出し（ソケット、パイプ）に使用できるのではなく、他のプログラムまたは永続的なソース（キュー、ファイル、データベース）からデータの取得を開始します。
そのクライアント/サーバーアプリケーションのサーバー部分も、再起動時に再起動するようにサービスとして実装されました。同じプログラムを実行する.exeを持つ別のプロジェクトnotがサービス、開発マシンでのデバッグを容易にするため。
お役に立てば幸いです。他の答えは、より良い一般的な答えですが、特に、スケジュールされたタスクは、おそらくほとんどの目的でおそらく記述および管理がより簡単であるという考えです。
実際のコードを使用したサービスコンセプトの使用例を以下に示します（以下を参照）。
これは、キューを消費して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();
}
}
}
サービスを使用する私のお気に入りの例：
- Servers-リモートクライアントからの要求を処理するプログラム。これらは通常、サービスとして実行され、ユーザーがサーバーにログインしているかどうかに関係なく、それらが利用可能であることを確認します。サービスとして実行することは、マシンが起動するとすぐにサーバーがリクエストの処理を開始することも意味します。マシンが何らかの理由で再起動した後、プログラムにログインするためにマシンにログインする必要はありません。データベースサーバーはその良い例です。
- バックグラウンド処理-データソースからのデータを処理し、結果をデータターゲットに格納するプログラム。多くの場合、データターゲットは別のプロセスのソースになります。サービスとして実行することで、これらのプログラムはそこに座って、データが到着するのを待つことができます。また、開発者は、プロセスを複数の半独立したステップに分割することにより、処理の堅牢性を向上させることができます。
少し前に、私のチームは以下のブラジルの銀行に3つのWindowsサービスを実装しました。
システム間のインターフェース：株式市場での取引の予約を担当するフロントオフィスアプリケーションと、取引手数料の計算と計算を担当するバックオフィスアプリケーションがありました。当初、システム間通信はSQL Serverで直接行われていましたが、ロックと保持の問題が多すぎるため、システムのパフォーマンスが低下していました。フロントデータベースとバックデータベースの両方に接続し、ある種の保持戦略を使用して適切な読み取り/書き込みを行うためのサービスが実装されました（SQL Serverですべての取引を書き込む代わりに、1000取引など、データをある程度保持します）。元のソリューションよりも40倍高速な一括挿入を行い、関連するテーブルの多くを長期間ロックしませんでした）。
メッセージキュー：以前のソリューションに加えて、カスタムメッセージキューハンドラーを作成したため、いくつかのバッチ処理プロシージャを非同期で実行できます。これは、MSMQとIBM-MQSeriesの両方に統合されました。
ビジネスサービスの一元化：たとえば、いくつかのユーザーアプリケーションでは株価などの共通データが必要だったため、「価格リクエスト」の受信と価格情報の返信を担当するカスタムサービスを作成しました。
「ロボット」の代わりにサービスを作成するようになった側面の1つは、サービスが特定のユーザーとして（誰かがこのスレッドですでに指摘したように）実行でき、マシンの起動時に自動的に開始できることです。
また、サービスを実行するためにデスクトップやウィンドウ管理サービスを必要としません。それらはバックグラウンドで実行できます（まあ、それらはmustバックグラウンドで実行します）。
また、ユーザーインターフェースを作成したくない同業者がいる場合、サービスは技術的に大きな課題です。通常、サービスは失敗してはなりません。サービスを書くのはとても楽しいです。 :)
サービスには多くの実用的な用途があります。主な実用的な用途の1つは、UIとサービス（またはUNIXのデーモン）プログラム間の相互作用です。この場合、クライアントとサーバーの違いです。サーバーはリクエストを受信し、リクエストを処理して、通常は返信を返します。つまり、リクエストを処理します。 SQLSERVER、IIS、またはtelnetについて考えてみてください。クライアントは通常、サーバーに要求を送信し、応答を表示または処理することによってサーバーを利用します。つまり、データ入力アプリケーション、Webアプリケーション...サーバーはほとんどの場合、Windowsのサービス（またはUNIXのデーモン）としてインストールされ、クライアントは通常、GUIを備えた通常のアプリにすぎません。サービスにはもっと複雑な使用法がたくさんありますが、これがおそらく最もよく使用されるものです。
例：現在、SIP/H323ビデオサーバーで作業しています。私が書いたSDKを使用してアプリケーションからリクエストを受信し、処理して、返信します。ビデオサーバーアプリケーションは、組み込みのLinuxマシンにデーモンとしてインストールされ（組み込みのWindowsマシンではサービスになりますが、組み込みにWindowsを使用します）、SDKを利用するアプリケーションはすべてクライアントと見なされます。
もちろん、そのようなアプリケーションを作成して、それらをサービスにすることはできません。 Windowsの起動時にそれらを起動し、バックグラウンドで実行させることもできます。ただし、コードにはいくつかのレジストリエントリと調整が含まれます。NETのようなものよりも、c apiを使用する方がはるかに簡単です。一方、Microsoftはサービスを作成し、それをO.S.手動で行うよりも実装がはるかに簡単で簡単です。
候補プログラムの例：
リソース/その他のアプリケーションを監視し、レポート（ユーザーアクティビティ、特定の種類のファイルトラフィック、アプリケーションの誤動作の通知）を送信する必要があるシステム
他のローカルアプリケーションにサービスを提供するシステム（翻訳、ファイル変換、システム間メッセージング）
ウイルス対策ソフト。
これらは、スケジュールされたタスクを使用して簡単に実行できない大きな例だと思います。
プログラマにとって、サービスを使用する主な理由は次のとおりです。
- このプログラムは、再起動後にWindowsマシンで自動的に起動する必要があります。
上記に準拠する必要のある記述は、Windowsサービスとして実行する必要があります。
エンドユーザーの観点から、私が書いた最も有用なサービス：
*ユーザーがRAWプリンタードライバーを備えたドットマトリックスプリンターでUGLY請求書を印刷しました。
*ユーザーは、ロゴと滑らかな線のグラフィックを使用したPRETTY請求書を求めていました。
*従来のコードにアクセスできません。
サービスは次のようになります：
*印刷ジョブの（複数の）プリンターフォルダーを監視します。
*請求書のPDFを作成します。
* PDFは、空白の請求書イメージを「下敷き」にします
*生のテキストをオーバーレイ
*使用されているフォルダーに基づいてメタデータを検索します（IE：使用されているプリンター）
その後、メタデータは次のようになります。
* PDFを生成
*および/またはPDFを印刷
*および/またはPDF=最終的な宛先フォルダーにファイルする
*および/またはPDFを削除
*および/またはPDF請求書を顧客に電子メールで送信
この場合、それはゴーストスクリプト、PLCおよびPDFエンジンを処理します。何年もの間非常にきれいに実行されています。ログファイルを含める!!!
標準ユーザーとして実行する必要があるが、管理者権限を必要とするタスクを実行する必要があるWindowsデスクトップアプリケーションを設計している場合は、サービスを使用できます。
インストーラーは必要な権限でサービスをインストールし、デスクトップアプリケーションは管理者権限でタスクを実行する必要があるときにサービスを呼び出します。
このアプローチには、この回答の範囲を超えるセキュリティ上の影響があります。