Quais são os usos práticos do Windows Services? [fechadas]

Eu sou novo em trabalhar com os Serviços do Windows. Embora tenha aprendido a criar os Serviços do Windows no VS2010 , gostaria de saber algumas maneiras práticas pelas quais os serviços do Windows podem ser usados?

Tentei pesquisar no Google com o contexto atual apenas para encontrar mais tutoriais sobre como criar os Serviços do Windows.

EDIT na oferta de recompensa:

Todas as respostas são ótimas, mas eu estava procurando por exemplos mais práticos sobre serviços do Windows e suas implicações? Isso ajudará os desenvolvedores a saber quando é apropriado usá-los no estudo de caso.

Um serviço é executado em segundo plano, mesmo que ninguém esteja conectado à máquina. Qualquer coisa que você possa imaginar querendo fazer sem depender de uma pessoa para iniciar um aplicativo e clicar em um botão é um bom candidato a um serviço. Por exemplo, monitorando uma pasta e sempre que um arquivo for gravado nela, processe-o de alguma maneira. Qualquer "servidor" em que você possa pensar - servidor web, servidor ftp, servidor de email - é um serviço, e muitos processos em segundo plano nos quais você nem sempre pensa.

Algumas coisas que antes foram escritas como serviços (arquivos de backup às 2 da manhã, enviar e-mails de lembrete às 3 da manhã etc.) provavelmente são melhores hoje em dia como tarefas agendadas, que têm uma enorme flexibilidade no Windows 7 e superior, mas se o desenvolvedor nunca as aprendeu ou o Se o sistema precisar suportar o XP, você também encontrará serviços executando esse tipo de tarefa.

Serviços no Windows são basicamente programas executados sem uma GUI. Servidores Web (como apache), servidores de banco de dados (como mysql e sql server), mecanismos antivírus e servidores de aplicativos / 'middleware' são exemplos práticos de aplicativos que geralmente são executados como serviços. Pode haver um cliente da GUI para permitir que você interaja com o serviço, mas o serviço em si não possui um. Ele apenas roda "em segundo plano", fazendo o que precisa. Além disso, como os serviços são executados com os direitos de usuário atribuídos a eles, eles podem ser executados como o usuário designado.se um usuário está ou não conectado à máquina. Portanto, um servidor de banco de dados teria os mesmos direitos de acesso, independentemente da pessoa conectada na máquina no momento, se houver. Assim, você pode ver por que isso seria importante - você não precisa manter um usuário conectado para manter um servidor web em execução, por exemplo.

Eles são o equivalente do Windows (da maneira mais prática) aos Daemons no * nix.

Serviço

Um programa, rotina ou processo que executa uma função específica do sistema para oferecer suporte a outros programas, particularmente em um nível baixo (próximo ao hardware). Quando os serviços são fornecidos por uma rede, eles podem ser publicados no Active Directory, facilitando a administração e o uso centralizados em serviços.

Gostaria de saber algumas maneiras práticas pelas quais os serviços do Windows podem ser usados?

De acordo com a definição de serviço, o Serviço de Janela e outros tipos de serviços oferecem muitas funcionalidades. Nesse contexto, os mecanismos de pesquisa são seus amigos .

Os serviços do Windows são normalmente usados ​​quando um aplicativo precisa ser executado continuamente. Você deve criar um serviço do Windows para executar o código em segundo plano, sem a interação do usuário .

Um serviço do Windows será executado mesmo se ninguém estiver conectado. O serviço Windows pode começar a funcionar assim que a máquina for ligada , o que é ideal para executar como servidor, servidor http por exemplo. Ninguém é necessário para fazer login.

Por exemplo, se eles precisarem:

1. Aguarde os pedidos recebidos. (Como através de remoting ou wcf)
2. Monitore uma fila, sistema de arquivos etc. Se um programa precisar executar periodicamente, como uma vez por dia. Normalmente é mais fácil criar uma tarefa agendada.
3. Qualquer servidor que aceite conexões (como um servidor de email, web ou FTP) geralmente deve ser um Serviço do Windows.

Eu usaria um serviço pelos seguintes motivos:

• Você não precisa ter uma sessão em execução. Isso é bom para a segurança e também reduz a sobrecarga no servidor.

• Você recebe alguns dos comandos de gerenciamento gratuitos
  o Iniciar
  o Parar
  o Pausar
  o Continuar

• Você pode manipular eventos do servidor, como desligamento.

Links com informações adicionais sobre esses serviços:

No Asp.net - // TODONT: use um serviço do Windows apenas para executar um processo agendado
O que é o uso do serviço Windows

Um programa interativo, como um winform ou WPF, é algo com o qual você deseja que um usuário abra, interaja e feche. Uma tarefa agendada é algo que você deseja executar em segundo plano em horários específicos - talvez apenas inicie, faça alguma coisa e pare. Um serviço do Windows é algo que você deseja executar o tempo todo em segundo plano.

Algumas vantagens de um serviço do Windows é que ele é executado independentemente do usuário conectado (ou mesmo se nenhum usuário estiver conectado) e pode ser configurado para começar a funcionar assim que o computador inicializar, o que pode ser realmente útil se o sistema é reiniciado.

Normalmente, eu uso serviços quando tenho que monitorar algo como uma pasta ou caixa de entrada de e-mail.

Como você adicionou a nota sobre exemplos práticos à sua pergunta, darei alguns exemplos de serviços que escrevi para aplicativos corporativos (você não diz se é um programador de aplicativos corporativos, mas acho que a maioria dos programadores de C # VS2010 é) . Eu acho que você está procurando uma idéia do que os desenvolvedores que não trabalham para a Microsoft podem escrever.

Um serviço de monitor de pulsação que verifica se outros programas ainda estão em execução (isso também pode ter funcionado como uma tarefa agendada, mas foi implementado como um serviço).

Um serviço de gravação de relatório que trabalhava nas filas de solicitações de relatório, executava os relatórios e os enviava para impressoras diferentes, dependendo da impressora ocupada. Isso ajudou a descarregar uma quantidade razoável de trabalho de um aplicativo herdado e permitiu que o relatório em execução fosse compartilhado por várias caixas baratas executando o serviço.

Ele foi implementado como um serviço para que funcionasse continuamente, iniciasse automaticamente em uma reinicialização e pudesse usar a interface de serviços padrão do Windows para iniciar, parar, pausar etc. Além disso, se fosse uma tarefa agendada, seria necessário inicie a obtenção de dados de outros programas ou de uma fonte persistente (uma fila, um arquivo, um banco de dados) em vez de estar disponível para a chamada de outros programas (soquete, canal).

A parte do servidor de um aplicativo cliente / servidor também foi implementada como um serviço para reiniciar em uma reinicialização etc. Havia outro projeto com um .exe que executava o mesmo programa e não como um serviço, para facilitar a depurar em máquinas de desenvolvimento.

Espero que ajude. As outras respostas são melhores respostas gerais, especialmente a ideia de que as tarefas agendadas provavelmente são mais fáceis de escrever e administrar para a maioria dos propósitos agora.

Existem muitos usos práticos para um serviço. Um uso prático principal é a interação entre a interface do usuário e os programas de serviço (ou daemon no unix), que é, nesse caso, a diferença entre um cliente e um servidor. Um servidor recebe solicitações, processa a solicitação e geralmente envia uma resposta. Em outras palavras, atende a uma solicitação. Pense em SQLSERVER, IIS ou telnet. Um cliente, geralmente utiliza um servidor enviando solicitações ao servidor e exibindo ou processando a resposta. ou seja, um aplicativo de entrada de dados, um aplicativo Web ... O servidor quase sempre é instalado como um serviço no Windows (ou um daemon no Unix) e o cliente geralmente é apenas um aplicativo normal com uma GUI. Existem muitos usos mais complexos de um serviço, mas esse é o que você provavelmente mais utilizará.

Por exemplo: Atualmente, estou trabalhando em um servidor de vídeo SIP / H323. Ele recebe solicitações de um aplicativo usando um SDK que eu escrevi, as processa e responde de volta. O aplicativo de servidor de vídeo é instalado como um daemon em uma máquina linux incorporada (seria um serviço em uma máquina Windows incorporada, mas que usa o Windows para incorporação de qualquer maneira) e qualquer aplicativo que utilize o SDK seria considerado um cliente.

Obviamente, você pode escrever esses aplicativos e não torná-los um serviço. Você ainda pode fazê-los iniciar ao iniciar o Windows e executá-los em segundo plano. No entanto, envolve várias entradas do Registro e algumas finalizações no seu código - é muito mais fácil usar a API do que em algo como o .NET. Por outro lado, a Microsoft tornou isso muito mais fácil criando serviços e permitindo registrá-los no sistema operacional. É muito mais simples e fácil de implementar do que fazê-lo manualmente.

Exemplos de programas candidatos:

• Sistemas que devem monitorar recursos / outros aplicativos e enviar relatórios (atividade do usuário, tipos específicos de tráfego de arquivos, notificações de mau comportamento do aplicativo)

• Sistemas que oferecem serviços para outros aplicativos locais (traduções, conversão de arquivos, sistema de mensagens entre sistemas)

• Software antivírus.

Eu acho que esses são os grandes exemplos que não podem ser feitos facilmente usando tarefas agendadas.

Meus exemplos favoritos de uso de serviços:

1. Servidores - programas que atendem solicitações de clientes remotos. Eles geralmente serão executados como serviços para garantir que estejam disponíveis, independentemente de qualquer usuário estar conectado ao servidor ou não. A execução como um serviço também significa que o servidor começa a processar solicitações assim que a máquina é iniciada, ninguém precisa fazer login na máquina para iniciar o programa depois que a máquina é reiniciada por qualquer motivo. Um servidor de banco de dados é um ótimo exemplo.
2. Processamento em segundo plano - programas responsáveis ​​pelo processamento de dados de uma fonte de dados e pelo armazenamento de resultados em um destino de dados. O destino dos dados geralmente é uma fonte para outro processo e assim por diante. A execução como serviços permite que esses programas fiquem parados e aguardem a chegada dos dados. Ele também permite que os desenvolvedores aprimorem a robustez do processamento, dividindo o processo em várias etapas semi-independentes.

Aqui está um exemplo de uso do conceito de serviço com código real (veja abaixo).

O que ele faz é configurar um barramento de serviço que consome fora de uma fila e ouve mensagens de servidores da Web e GUIs de clientes.

Quando recebe as mensagens, faz o que a lógica o domínio justifica, salva os eventos em disco e os publica no intermediário de mensagens.

A maioria dos aplicativos maiores que são pouco acoplados implementam algum tipo de arquitetura de "trabalho", como a abaixo.

O projeto Documently é um exemplo de projeto que criamos para pessoas como você aprenderem arquiteturas distribuídas. Você pode fazer perguntas diretamente para mim no projeto, ou bifurcá-lo e implementar algum recurso para aprender e depois enviar uma solicitação de recebimento (e obter comentários de código).

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

Há algum tempo, minha equipe implementou 3 serviços do Windows em um banco aqui no Brasil, como abaixo:

• Interface entre sistemas: tínhamos um aplicativo de front-office responsável pela reserva de negociações na bolsa de valores e um aplicativo de back-office, responsável por contabilizar e calcular as taxas de negócios. Inicialmente, a comunicação entre sistemas foi feita diretamente no SQL Server, mas muitos problemas de bloqueio e retenção fizeram com que o sistema sofresse um desempenho ruim. Foi implementado um serviço para conectar-se aos bancos de dados frontal e traseiro e fazer a leitura / gravação adequada usando algum tipo de estratégia de retenção (em vez de escrever todas as trocas comerciais no SQL Server, mantemos os dados em certa extensão, digamos 1000 negócios e fez uma inserção em massa 40 vezes mais rápida que a solução original e não travou muitas das tabelas envolvidas por um longo tempo).

• Fila de mensagens: juntamente com a solução anterior, escrevemos um manipulador de fila de mensagens personalizado, para que vários procedimentos de processamento em lote pudessem ser executados de forma assíncrona. Isso foi integrado ao MSMQ e ao IBM-MQSeries.

• Centralização de serviços de negócios: vários aplicativos de usuário precisavam de dados comuns como preço das ações, por exemplo, por isso, escrevemos um serviço personalizado responsável por receber "solicitações de preço" e enviar as informações de preço.

Um dos aspectos que nos levou a escrever serviços, em vez de "robôs", é que os serviços podem ser executados como um usuário específico (como alguém já apontou neste segmento) e podem ser iniciados automaticamente quando a máquina é inicializada.

Os serviços também não precisam de um serviço de gerenciamento de área de trabalho ou janela para executar. Eles podem ser executados em segundo plano (bem, eles devem ser executados em segundo plano).

E, se você é como alguns colegas meus que não gostam de escrever interfaces de usuário, os serviços são grandes desafios tecnológicos, porque geralmente não devem falhar. Portanto, é muito divertido escrever um serviço. :)

Se você estiver projetando um aplicativo de área de trabalho do Windows que precise ser executado como usuário padrão, mas que às vezes precise executar uma tarefa que exija privilégios de administrador, poderá usar um serviço.

Seu instalador instala o serviço com as permissões necessárias, seu aplicativo da área de trabalho chama o serviço quando ele precisa executar uma tarefa com privilégio de administrador.

Existem implicações de segurança nessa abordagem que estão além do escopo desta resposta.

Para os programadores, a principal razão para usar o serviço é:

• Este programa precisa iniciar automaticamente em uma máquina Windows após uma reinicialização.

Qualquer coisa que você escrever e que esteja em conformidade com o descrito acima deve ser executado como um Serviço do Windows.

O serviço mais útil que eu escrevi, da perspectiva do usuário final:
* O usuário imprimiu faturas UGLY em uma impressora matricial com driver de impressão RAW.
* O usuário queria uma fatura BONITA com logotipo, gráficos de linhas suaves.
* Sem acesso ao código legado.

O serviço seria:
* Monitorar (várias) pastas da impressora para trabalhos de impressão.
* Crie um PDF da fatura.
* O PDF "submergiu" uma bela imagem da fatura em branco
* Sobrepõe o texto bruto
* Pesquise metadados, com base na pasta que está sendo usada (IE: impressora sendo usada)

Em seguida, os metadados:
* Geram PDF
* e / ou imprimem PDF
* e / ou arquive o PDF em uma pasta de destino final
* e / ou exclua o PDF
* e / ou envie a fatura em PDF para o cliente

Nesse caso, ele lida com mecanismos de script fantasma, PLC e PDF. Está funcionando muito bem há anos. Incluir arquivos de log !!!