Які практичні можливості використання служб Windows? [зачинено]

Я новачок у роботі зі службами Windows. Хоча я навчився створювати служби Windows у VS2010, я хотів би знати деякі практичні способи використання служб Windows?

Я спробував Google з урахуванням поточного контексту лише для того, щоб знайти більше підручників щодо створення служб Windows.

EDIT на Bounty пропозицію:

Усі відповіді чудові, але я шукав більше практичних прикладів щодо служб Windows та їх наслідків? Це допоможе розробникам дізнатись, коли доцільно використовувати їх при вивченні випадку.

Послуга працює у фоновому режимі, навіть якщо на машині ніхто не підписаний. Все, що ви можете уявити, бажаючи зробити, не покладаючись на людину, щоб запустити додаток і натиснути кнопку, є хорошим кандидатом на послугу. Наприклад, моніторинг папки та кожен раз, коли в неї записаний файл, якимось чином обробляйте її. Будь-який "сервер", про який ви можете придумати - веб-сервер, ftp сервер, поштовий сервер - це послуга, і тому багато фонових процесів ви можете не часто думати.

Деякі речі, які колись були написані як сервіси (резервні файли о 2 ранку, відправлення електронних листів із нагадуванням о 3 ранку тощо), ймовірно, краще сьогодні виконуватись як заплановані завдання, які мають величезну гнучкість у Windows 7 і новіших версіях, але якщо розробник ніколи їх не вивчив, або система повинна підтримувати XP, ви також знайдете сервіси, які виконують такі завдання.

Послуги в Windows - це, в основному, програми, які працюють без графічного інтерфейсу. Веб-сервери (такі як apache), сервери баз даних (наприклад, сервер mysql & sql), антивірусні двигуни та сервери додатків / "програмного забезпечення" - це практичні приклади програм, які часто працюють як сервіси. Може бути клієнт GUI, який дозволяє вам взаємодіяти зі службою, але сама служба такої не має. Він просто працює "на задньому плані", роблячи свою справу. Крім того, оскільки служби працюють із призначеними їм правами користувача, вони можуть працювати як призначений користувачнезалежно від того, чи дійсно користувач увійшов до машини. Таким чином, сервер бази даних матиме однакові права доступу незалежно від того, хто користувач увійшов у апарат у той час, якщо такий є. Тож ви можете зрозуміти, чому це було б важливо - ви не хочете, щоб користувач увійшов у систему, щоб, наприклад, підтримувати роботу веб-сервера.

Вони є еквівалентом Windows (у більшості практичних способів) Daemons на * nix.

Сервіс

Програма, рутина або процес, який виконує певну системну функцію для підтримки інших програм, особливо на низькому (близькому до апаратного) рівні. Коли послуги надаються через мережу, вони можуть бути опубліковані в Active Directory, полегшуючи адміністрування та використання сервісу.

Мені хотілося б знати деякі практичні способи використання сервісів Windows?

Відповідно до визначення сервісу, Window Service та інші види послуг виконують багато функціональних можливостей. У цьому контексті пошукові системи є вашим другом .

Служби Windows зазвичай використовуються, коли програмі потрібно постійно запускати. Вам слід створити службу Windows для запуску коду у фоновому режимі без взаємодії з користувачем .

Служба Windows запуститься, навіть якщо ніхто не входить у систему. Сервіс Windows може почати працювати, як тільки машина включена , що ідеально підходить для роботи як сервер, наприклад http-сервер. Нікому не потрібно входити в систему.

Наприклад, якщо їм потрібно:

1. Зачекайте на вхідні запити. (Як-от через видалення або wcf)
2. Контролюйте чергу, файлову систему тощо. Якщо програмі просто потрібно запускатись періодично, як раз на день. Зазвичай спростити створення запланованого завдання ..
3. Будь-який сервер, який приймає з'єднання (наприклад, пошта, веб-сервер або FTP-сервер), як правило, повинен бути службою Windows.

Я б користувався сервісом з наступних причин:

• Вам не потрібно проводити сеанс. Це добре для безпеки, а також зменшує накладні витрати на сервері.

• Ви отримуєте кілька вбудованих команд управління безкоштовно.
  Старт
  o Зупинка
  o Пауза
  o Продовження

• Ви можете обробляти події сервера, такі як відключення.

Посилання з додатковою інформацією про ці послуги:

На сайті Asp.net - // TODONT: Використовуйте службу Windows просто для запуску запланованого процесу. Для
чого використовується служба WIndows

Інтерактивна програма, на зразок winform або WPF, - це те, що ви бажаєте, щоб користувач відкривав, взаємодіяв і закривав. Задане завдання - це те, що ви хочете виконувати у фоновому режимі як конкретні часи - можливо, просто запустіть, зробіть щось і зупиніться. Служба Windows - це те, що ви хочете постійно працювати у фоновому режимі.

Деякі переваги служби Windows полягають у тому, що вона запускається незалежно від того, який користувач увійшов (або навіть якщо жоден користувач не ввійшов у систему), і його можна встановити для запуску, як тільки комп'ютер завантажиться, що може бути дуже корисним, якщо система перезавантажується.

Зазвичай я користуюся послугами, коли мені доводиться контролювати щось на зразок папки чи вхідних повідомлень електронної пошти.

Оскільки ви додали до запитання примітку про практичні приклади, я наведу кілька прикладів служб, які я написав для корпоративних додатків (ви не кажете, чи є програмістом для корпоративних програм, але я гадаю, що більшість програмістів C # VS2010 є) . Я думаю, ви шукаєте уявлення про те, що можуть писати розробники, які не працюють для Microsoft.

Сервіс монітору серцебиття, який перевіряв, чи ще запущені інші програми (це, можливо, також працювало як заплановане завдання, але було реалізовано як послуга).

Служба написання звітів, яка працювала через черги запитів звітів, запускала звіти та надсилала їх до різних принтерів залежно від того, який принтер зайнятий. Це допомогло вивантажити неабияку кількість роботи зі застарілого додатка та дозволило ділитися звітом за допомогою декількох дешевих скриньок, що виконують послугу.

Він був реалізований як послуга, щоб він запускався постійно, запускався автоматично при перезавантаженні та мав змогу використовувати стандартний інтерфейс служб Windows для запуску, зупинки, паузи тощо. Також, якщо це було заплановане завдання, потрібно було б ініціювати отримання даних з інших програм або постійного джерела (черга, файл, база даних), а не доступна для дзвінків іншої програми (socket, pipe).

Серверна частина цього клієнтсько-серверного додатку також була реалізована як послуга, щоб вона перезапустилася при перезавантаженні тощо. Був ще один проект із .exe, який запускав ту саму програму не як сервіс, щоб полегшити налагодження на розроблювальних машинах.

Я сподіваюся, що це допомагає. Інші відповіді - це кращі загальні відповіді, особливо ідея про те, що заплановані завдання, мабуть, простіше написати та виконувати зараз для більшості цілей.

Існує багато практичних застосувань для послуги. Одне головне практичне використання - це взаємодія між користувальницьким інтерфейсом та сервісними програмами (або демоном в unix), що полягає в цьому в різниці між клієнтом і сервером. Сервер отримує запити, обробляє запит і зазвичай надсилає відповідь. Іншими словами, він ОБСЛУГОВУЄ запит. Подумайте про SQLSERVER, IIS або telnet. Клієнт, як правило, використовує сервер, надсилаючи запити на сервер, а потім показуючи або обробляючи відповідь. тобто додаток для введення даних, веб-додаток ... Сервер майже завжди встановлюється як сервіс у Windows (або демон в unix), і клієнт, як правило, просто звичайний додаток з gui. Є набагато складніші можливості використання сервісу, але саме це ви, мабуть, використовуватимете найбільше.

Наприклад: Зараз я працюю на відео-сервері SIP / H323. Він отримує запити від програми за допомогою SDK, який я написав, обробляє їх та відповідає. Додаток для відеосервера встановлюється як демон на вбудованій машині Linux (це була б послуга на вбудованій машині Windows, але хто все-таки використовує Windows для вбудовування), а будь-яка програма, що використовує SDK, вважатиметься клієнтом.

Звичайно, ви можете писати такі додатки, а не робити їх послугами. Ви все ще можете змусити їх запускатись при запуску Windows і запускати їх у фоновому режимі. Однак це передбачає кілька записів у реєстрі та певну доопрацювання у вашому коді - це набагато простіше зробити за допомогою c api, ніж у чомусь подібному .NET. Microsoft, з іншого боку, зробила це набагато простіше, створивши сервіси та дозволило нам зареєструвати їх в ОС Це набагато простіше і простіше, ніж це зробити вручну.

Приклади кандидатських програм:

• Системи, які повинні контролювати ресурси / інші програми та надсилати звіти (активність користувача, певний тип файлового трафіку, сповіщення про неправильну поведінку програми)

• Системи, які пропонують послуги для інших локальних програм (переклади, перетворення файлів, міжсистемні повідомлення)

• Антивірусне програмне забезпечення.

Я думаю, що це великі приклади, які неможливо легко зробити за допомогою запланованих завдань.

Мої улюблені приклади використання послуг:

1. Сервери - програми, що обслуговують запити віддалених клієнтів. Зазвичай вони працюватимуть як сервіси, щоб переконатися, що вони доступні незалежно від того, будь-який користувач увійшов на сервер чи ні. Запуск в якості сервісу також означає, що сервер починає обробляти запити, як тільки машина запускається, нікому не доводиться входити в систему для запуску програми після перезавантаження машини з будь-якої причини. Сервер бази даних - прекрасний приклад.
2. Фонова обробка - програми, відповідальні за обробку даних з джерела даних та зберігання результатів у цільову інформацію. Цільова інформація часто є джерелом для іншого процесу тощо. Запуск цих служб дозволяє цим програмам просто сидіти там і чекати, коли дані надійдуть. Це також дозволяє розробникам підвищити надійність обробки, розділивши процес на кілька напівнезалежних етапів.

Ось приклад використання концепції обслуговування з реальним кодом (див. Нижче).

Для цього потрібно налаштувати службову шину, яка витрачає чергу і слухає повідомлення з веб-серверів та графічних інтерфейсів клієнтів.

Коли він отримує повідомлення, він робить таку логіку, яку вимагає домен, він зберігає події на диску і публікує ці події брокеру повідомлень.

Більшість великих додатків, які з’єднані слабко, реалізують якусь "робочу" архітектуру, як річ нижче.

Проект «Документально» - це зразок проекту, який ми створили для людей, як ви, щоб вивчати розподілені архітектури. Ви можете задати питання мені безпосередньо в проекті, або роздрібнити його, і реалізувати якусь функцію, з якої можна дізнатися, а потім подати запит на виклик (і отримати коментарі до коду).

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 сервері, ми тримаємо дані на деякому розширенні, скажімо, 1000 торгів та зробив об'ємну вставку, яка була на 40 разів швидшою, ніж оригінальне рішення, і довго не блокувала багато задіяних таблиць).

• Черга повідомлень: Поряд з попереднім рішенням, ми написали спеціальний обробник черги повідомлень, тому кілька процедур пакетної обробки могли працювати асинхронно. Це було інтегровано як з MSMQ, так і з IBM-MQSeries.

• Централізація бізнес-послуг: Кілька програм користувачів потребували загальних даних, наприклад, ціни акцій, тому ми написали спеціальну службу, відповідальну за отримання "запитів цін" та повернення інформації про ціни.

Одним з аспектів, який призвів до написання сервісів замість «роботів», є те, що сервіси можуть працювати як певний користувач (як хтось уже вказував на цю нитку), і вони можуть бути ініційовані автоматично, коли машина завантажується.

Для запуску сервісів також не потрібна служба управління робочим столом або вікном. Вони можуть працювати на тлі (ну, вони повинні працювати на тлі).

І, якщо ви схожі на моїх однолітків, які не люблять писати інтерфейси користувачів, сервіси - це великі технологічні проблеми, тому що зазвичай вони не повинні провалюватися. Тож дуже цікаво писати послугу. :)

Якщо ви розробляєте додаток для настільних ПК Windows, який повинен запускатися як стандартний користувач, але іноді потрібно виконувати завдання, яке вимагає привілеїв адміністратора, ви можете користуватися послугою.

Ваш інсталятор встановлює службу з необхідними дозволами, ваш настільний додаток запускає в службу, коли їй потрібно виконати завдання з правами адміністратора.

У цьому підході є наслідки для безпеки, які виходять за рамки цієї відповіді.

Основна причина використання сервісів для програмістів:

• Цю програму потрібно запустити автоматично на машині Windows після перезавантаження.

Все, що ви пишете, що має відповідати вищевказаному, має працювати як служба Windows.

Найбільш корисна послуга, яку я написав, з точки зору кінцевого користувача:
* Друкований користувачем UGLY рахунок-фактур на точковому матричному принтері з драйвером друку RAW.
* Користувач захотів ПРЕТТИЙ рахунок-фактура з логотипом, гладкою графікою.
* Немає доступу до застарілого коду.

Послуга:
* Монітор (декілька) папок принтера для завдань друку.
* Створіть PDF рахунку-фактури.
* PDF буде «підкладати» хороший порожній рахунок - фактура зображення
* Накладка сирий текст
* Подивіться метадані , засновані на папки використовується (IE: принтер використовується)

Потім метадані будуть:
* Створити PDF
* та / або друк PDF
* та / або подайте PDF у папку остаточного призначення
* та / або видаліть PDF
* та / або надіслати електронною поштою рахунок-фактуру PDF

У цьому випадку він обробляє ghost-script, PLC та двигуни PDF. Він роками працює дуже чисто. Включити файли журналу !!!