Quali sono gli usi pratici dei servizi di Windows? [chiuso]

Sono nuovo a lavorare con i servizi di Windows. Anche se ho imparato a creare servizi Windows in VS2010, vorrei conoscere alcuni modi pratici in cui i servizi di Windows potrebbero essere utilizzati?

Ho provato a cercare su Google con il contesto attuale solo per trovare ulteriori tutorial su come creare i servizi di Windows.

EDIT sull'offerta Bounty:

Tutte le risposte sono fantastiche ma stavo cercando esempi più pratici sui servizi di Windows e le loro implicazioni? Questo aiuterà gli sviluppatori a sapere quando è appropriato usarli con il case study.

Un servizio viene eseguito in background, anche se nessuno è connesso alla macchina. Qualunque cosa tu possa immaginare di voler fare senza fare affidamento su una persona per avviare un'app e fare clic su un pulsante è un buon candidato per un servizio. Ad esempio, monitorando una cartella e ogni volta che un file viene scritto su di essa, elaborarlo in qualche modo. Qualsiasi "server" a cui puoi pensare - server web, server ftp, server di posta - è un servizio, così come molti processi in background che potresti non pensare spesso.

Alcune cose che una volta erano scritte come servizi (file di backup alle 2 del mattino, invio di e-mail di promemoria alle 3 del mattino, ecc.) Sono probabilmente fatte meglio oggi come attività pianificate, che hanno un'enorme flessibilità su Windows 7 e versioni successive, ma se lo sviluppatore non le ha mai imparate, o il il sistema deve supportare XP, troverete anche servizi che svolgono questo tipo di attività.

I servizi su Windows sono fondamentalmente programmi eseguiti senza una GUI. Server Web (come apache), server di database (come mysql e sql server), motori antivirus e server di applicazioni / "middleware" sono tutti esempi pratici di applicazioni che spesso vengono eseguite come servizi. Potrebbe esserci un client GUI che ti consente di interagire con il servizio, ma il servizio stesso non ne ha uno. Funziona solo "in background", facendo la sua cosa. Inoltre, poiché i servizi vengono eseguiti con i diritti utente loro assegnati, possono essere eseguiti come utente assegnatoindipendentemente dal fatto che un utente sia effettivamente connesso alla macchina. Quindi un server di database avrebbe gli stessi diritti di accesso indipendentemente dalla persona che ha effettuato l'accesso al computer, se presente. Quindi puoi capire perché sarebbe importante: non vuoi tenere un utente connesso per mantenere un server web in esecuzione, per esempio.

Sono l'equivalente di Windows (nella maggior parte dei modi pratici) dei demoni su * nix.

Servizio

Un programma, routine o processo che esegue una funzione di sistema specifica per supportare altri programmi, in particolare a un livello basso (vicino all'hardware). Quando i servizi vengono forniti su una rete, possono essere pubblicati in Active Directory, facilitando l'amministrazione e l'utilizzo incentrati sui servizi.

Vorrei sapere alcuni modi pratici in cui i servizi di Windows potrebbero essere utilizzati?

Secondo la definizione del servizio, Window Service e altri tipi di servizi offrono molte funzionalità. In questo contesto i motori di ricerca sono tuoi amici .

I servizi di Windows vengono normalmente utilizzati quando un'applicazione deve essere eseguita continuamente. È necessario creare un servizio Windows per eseguire il codice in background, senza l'interazione dell'utente .

Un servizio Windows verrà eseguito anche se nessuno è connesso. Il servizio Windows può iniziare a funzionare non appena la macchina è accesa , il che rende ideale per l'esecuzione come server, ad esempio un server http. Nessuno è richiesto per accedere.

Ad esempio se hanno bisogno di:

1. Attendi richieste in arrivo. (Come tramite telecomando o wcf)
2. Monitorare una coda, un file system ecc. Se un programma deve essere eseguito periodicamente, come una volta al giorno. Normalmente è più semplice creare un'attività pianificata.
3. Qualsiasi server che accetta connessioni (come un server di posta, web o FTP) dovrebbe essere normalmente un servizio Windows.

Vorrei utilizzare un servizio per i seguenti motivi:

• Non è necessario avere una sessione in esecuzione. Questo è utile per la sicurezza e riduce anche le spese generali sul server.

• Alcuni dei comandi di gestione sono integrati gratuitamente
  o Start
  o Stop
  o Pausa
  o Continua

• È possibile gestire eventi del server come l'arresto.

Collegamenti con ulteriori informazioni su questi servizi:

Su Asp.net - // TODONT: utilizzare un servizio Windows solo per eseguire un processo pianificato
Che cos'è l'uso del servizio Windows

Un programma interattivo, come una winform o WPF, è qualcosa che desideri che un utente apra, interagisca e chiuda. Un'attività pianificata è qualcosa che si desidera eseguire in background come orari specifici - forse basta avviare, fare qualcosa e interrompere. Un servizio Windows è qualcosa che vuoi eseguire sempre in background.

Alcuni vantaggi di un servizio Windows sono che funziona indipendentemente dall'utente che ha effettuato l'accesso (o anche se nessun utente ha effettuato l'accesso) e può essere impostato per iniziare l'esecuzione non appena il computer si avvia, il che può essere davvero utile se il il sistema viene riavviato.

Di solito ho usato i servizi quando devo monitorare qualcosa come una cartella o posta in arrivo.

Da quando hai aggiunto la nota sugli esempi pratici alla tua domanda, ti fornirò alcuni esempi di servizi che ho scritto per le applicazioni aziendali (non dici se sei un programmatore di applicazioni aziendali, ma suppongo che la maggior parte dei programmatori C # VS2010 lo siano) . Penso che tu stia cercando un'idea di ciò che gli sviluppatori che non lavorano per Microsoft potrebbero scrivere.

Un servizio di monitoraggio del battito cardiaco che ha verificato se altri programmi erano ancora in esecuzione (potrebbe aver funzionato anche come attività pianificata, ma è stato implementato come servizio).

Un servizio di scrittura di report che ha funzionato attraverso le code delle richieste di report, ha eseguito i report e li ha inviati a stampanti diverse a seconda della stampante occupata. Ciò ha contribuito a scaricare una buona quantità di lavoro da un'applicazione legacy e ha consentito la condivisione del report in esecuzione da più box economici che eseguono il servizio.

È stato implementato come servizio in modo da poter essere eseguito continuamente, avviarsi automaticamente al riavvio ed essere in grado di utilizzare l'interfaccia standard dei servizi di Windows per avviare, arrestare, mettere in pausa, ecc. Inoltre, se fosse un'attività pianificata, sarebbe necessario iniziare a ottenere dati da altri programmi o da una fonte persistente (una coda, un file, un database) anziché essere disponibile per essere chiamato da altri programmi (socket, pipe).

Anche la parte server di un'applicazione client / server è stata implementata come servizio in modo che si riavviasse al riavvio, ecc. Esisteva un altro progetto con un file .exe che eseguiva lo stesso programma non come servizio, per semplificare debug su macchine di sviluppo.

Spero che aiuti. Le altre risposte sono risposte generali migliori, in particolare l'idea che le attività pianificate sono probabilmente più facili da scrivere e amministrare per la maggior parte degli scopi ora.

Esistono molti usi pratici per un servizio. Un uso pratico principale è l'interazione tra UI e programmi di servizio (o demone in unix), che è, in questo caso, la differenza tra un client e un server. Un server riceve richieste, elabora la richiesta e generalmente invia una risposta. In altre parole, SERVE una richiesta. Pensa a SQLSERVER, IIS o telnet. Un client, di solito utilizza un server inviando richieste al server e quindi visualizzando o elaborando la risposta. cioè un'applicazione per l'immissione di dati, un'applicazione web ... Il server è quasi sempre installato come servizio in Windows (o un demone in unix) e il client è di solito solo un'app normale con una GUI. Esistono molti usi più complessi di un servizio, ma questo è quello che probabilmente utilizzerai di più.

Ad esempio: attualmente sto lavorando su un server video SIP / H323. Riceve richieste da un'applicazione utilizzando un SDK che ho scritto, le elabora e le risposte. L'applicazione del server video è installata come demone su una macchina linux incorporata (sarebbe un servizio su una macchina Windows incorporata, ma chi usa comunque Windows per incorporare) e qualsiasi applicazione che utilizza l'SDK sarebbe considerata un client.

Naturalmente, potresti scrivere tali applicazioni e non renderle un servizio. Potresti comunque farli avviare all'avvio di Windows e farli funzionare in background. Tuttavia, comporta diverse voci di registro e alcune operazioni di finagling nel codice: è molto più semplice fare uso di c api che in qualcosa come .NET. Microsoft, d'altra parte, ha reso tutto molto più semplice creando servizi e permettendoci di registrarli con il sistema operativo. È molto più semplice e facile da implementare che farlo manualmente.

Esempi di programmi candidati:

• Sistemi che devono monitorare risorse / altre applicazioni e inviare report (attività dell'utente, tipi particolari di traffico di file, notifiche di comportamento scorretto dell'applicazione)

• Sistemi che offrono servizi ad altre applicazioni locali (traduzioni, conversione di file, messaggistica tra sistemi)

• Programma antivirus.

Penso che questi siano i grandi esempi che non possono essere facilmente eseguiti utilizzando attività pianificate.

I miei esempi preferiti di utilizzo dei servizi:

1. Server : programmi che soddisfano le richieste dei client remoti. Di solito funzioneranno come servizi per assicurarsi che siano disponibili, indipendentemente dal fatto che un utente abbia effettuato l'accesso al server o meno. L'esecuzione come servizio significa anche che il server avvia l'elaborazione delle richieste non appena la macchina viene avviata, nessuno deve accedere alla macchina per avviare il programma dopo il riavvio della macchina per qualsiasi motivo. Un server di database è un ottimo esempio.
2. Elaborazione in background : programmi responsabili dell'elaborazione dei dati da un'origine dati e della memorizzazione dei risultati in una destinazione dati. Il target dei dati è spesso una fonte per un altro processo e così via. L'esecuzione come servizi consente a tali programmi di rimanere semplicemente lì e attendere l'arrivo dei dati. Inoltre, consente agli sviluppatori di migliorare la solidità dell'elaborazione suddividendo il processo in più passaggi semi-indipendenti.

Ecco un esempio di utilizzo del concetto di servizio con codice reale (vedi sotto).

Ciò che fa è configurare un bus di servizio che si consuma da una coda e ascolta i messaggi dai server Web e dalle GUI del client.

Quando riceve i messaggi fa quale logica garantisce il dominio, salva gli eventi sul disco e li pubblica sul broker dei messaggi.

Le applicazioni più grandi che sono accoppiate liberamente implementano una sorta di architetture "operaie" come quella qui sotto.

Il progetto Documently è un progetto di esempio che abbiamo creato per consentire a persone come te di imparare architetture distribuite. Puoi fare domande direttamente a me nel progetto, oppure fork e implementare alcune funzionalità da cui imparare e quindi inviare una richiesta pull (e ottenere commenti sul codice).

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();
        }
    }
}

Qualche tempo fa il mio team ha implementato 3 servizi Windows su una banca qui in Brasile, come di seguito:

• Interfaccia tra sistemi: avevamo un'applicazione di front office responsabile della prenotazione delle negoziazioni sul mercato azionario e un'applicazione di back office, responsabile della contabilità e del calcolo delle commissioni di negoziazione. Inizialmente, la comunicazione tra sistemi è stata effettuata direttamente su SQL Server, ma troppi problemi di blocco e conservazione hanno reso le prestazioni del sistema scarse. È stato implementato un servizio per connettersi a entrambi i database anteriore e posteriore e fare la lettura / scrittura corretta utilizzando un qualche tipo di strategia di conservazione (invece di scrivere ogni singolo trade su SQL Server, conserviamo i dati in una certa misura, diciamo 1000 trade, e ha fatto un inserimento in blocco, che era 40 volte più veloce della soluzione originale e non ha bloccato molte delle tabelle coinvolte per molto tempo).

• Coda messaggi: insieme alla soluzione precedente, abbiamo scritto un gestore di coda messaggi personalizzato, in modo che diverse procedure di elaborazione batch possano essere eseguite in modo asincrono. Ciò è stato integrato con MSMQ e IBM-MQSeries.

• Centralizzazione dei servizi alle imprese: diverse applicazioni utente avevano bisogno di dati comuni come i prezzi delle azioni, ad esempio, quindi abbiamo scritto un servizio personalizzato responsabile della ricezione di "richieste di prezzo" e della restituzione delle informazioni sui prezzi.

Uno degli aspetti che ci ha portato a scrivere servizi, anziché "robot", è che i servizi possono essere eseguiti come un utente specifico (come qualcuno ha già sottolineato in questo thread) e possono essere avviati automaticamente all'avvio della macchina.

Inoltre, per eseguire i servizi non è necessario un desktop o un servizio di gestione delle finestre. Possono funzionare sullo sfondo (bene, devono funzionare sullo sfondo).

E, se siete come alcuni miei colleghi a cui non piace scrivere interfacce utente, i servizi sono grandi sfide tecnologiche, perché di solito non devono fallire. Quindi è molto divertente scrivere un servizio. :)

Se si sta progettando un'applicazione desktop Windows che deve essere eseguita come utente standard ma a volte è necessario eseguire un'attività che richiede privilegi di amministratore, è possibile utilizzare un servizio.

Il programma di installazione installa il servizio con le autorizzazioni necessarie, l'applicazione desktop chiama il servizio quando deve eseguire un'attività con privilegio di amministratore.

Ci sono implicazioni di sicurezza per questo approccio che vanno oltre lo scopo di questa risposta.

Per i programmatori il motivo principale per l'utilizzo del servizio è:

• Questo programma deve avviarsi automaticamente su un computer Windows dopo un riavvio.

Tutto ciò che scrivi che deve essere conforme a quanto sopra deve essere eseguito come un servizio Windows.

Il servizio più utile che ho scritto, dal punto di vista dell'utente finale:
* L'utente ha stampato fatture UGLY su una stampante a matrice di punti con driver di stampa RAW.
* L'utente voleva una fattura GRAZIOSA con logo, grafica uniforme.
* Nessun accesso al codice legacy.

Il servizio dovrebbe:
* Monitorare (più) cartelle della stampante per i lavori di stampa.
* Crea un PDF della fattura.
* Il PDF "ricopre" una bella immagine vuota della fattura
* Sovrappone il testo non
elaborato * Cerca i metadati, in base alla cartella in uso (IE: stampante in uso)

Quindi i metadati dovrebbero:
* Generare PDF
* e / o stampare PDF
* e / o archivia il PDF in una cartella di destinazione finale
* e / o elimina il PDF
* e / o e-mail la fattura PDF al cliente

In questo caso, gestisce motori ghost-script, PLC e PDF. Funziona in modo molto pulito da anni. Includi i file di registro !!!