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


18

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.


28
Exemplos práticos? Que tal todos os serviços em execução na sua caixa do Windows agora?
yannis

3
ou todos os daemon em execução no seu * nix box
jk.

1
Eu gosto de gravar música clássica de rádio transmitido. Com um programa, eu teria que acordar às 2 da manhã e pressionar o botão "gravar". Com um serviço, posso agendar a ação com antecedência e dormir em paz. Os programas são TVs - os serviços são videocassetes.
Kilian Foth

Respostas:


42

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.


1
+1. Ótima resposta. Sua resposta me lembra como eu resolvi fazer backup de banco de dados. Antes de fazer o backup, costumávamos executar um procedimento SQL no servidor por meio de um agendador que chama o exe. O exe costumava aparecer e, uma vez feito, é fechado por si só. Eu acho que um serviço do Windows era uma opção melhor aqui.
Karthik Sreenivasan

8
Não, não teria. Essa tarefa ainda não precisa escutar conexões. Tarefas agendadas são a maneira correta de resolver esse tipo de problema.
Wyatt Barnett

2
Também estava executando muitas tarefas agendadas no NTver <6.0. . .
Wyatt Barnett

1
@ Polinomial: tarefas agendadas podem ser executadas em qualquer conta, pelo menos para qualquer coisa NT5 +. Qualquer coisa que esteja sendo executada sem supervisão precisa fazer o log para que você possa descobrir por que ele falhou.
Wyatt Barnett

1
Ótima explicação :). Nosso sistema de imagem atual na empresa em que trabalho utiliza os serviços do Windows extensivamente para lidar com o processamento de arquivos. Desde o momento em que as imagens são digitalizadas no sistema até as filas para indexação para arquivamento e, finalmente, para saída por e-mail, impressão ou fax, são todos os serviços do Windows.
Kelleystar

9

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.


5

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


Como executar com privilégios mais altos um serviço do Windows? Tarefas agendadas, por exemplo, são possíveis, veja stackoverflow.com/a/11561410/206730 . IMHO, melhores amostras para minimizar a curva de aprendizagem são aplicações reais com código fonte completo e bons padrões
Kiquenet

4

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.


3

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.


+1 Para explicar onde os serviços do Windows são usados ​​em detalhes. Eu tenho exposição limitada a soquetes (modelo cliente-servidor se comunicando por meio de endereço IP por portas), mas não usei pipes em geral. Os tubos têm um papel semelhante a desempenhar, como os soquetes?
Karthik Sreenivasan

2

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.


+1 - Apenas para esclarecer, o serviço é hospedado no servidor como um serviço do Windows e, em seguida, o SDK do cliente envia informações ao servidor por uma porta para comunicar dados e receber feedback. Meu entendimento está correto?
Karthik Sreenivasan

1
@Karthik, você está se referindo ao padrão de design ou ao meu exemplo? Se for o primeiro, sim .. ou um daemon no Unix. A comunicação seria alguma forma de TCP / IP. Se você está se referindo ao meu exemplo, o servidor de vídeo é um daemon em uma máquina Linux incorporada. O SDK se comunica por uma porta, o servidor de vídeo possui um loop de escuta usado para processar as solicitações do cliente.
Jonathan Henson

@Karthik, a propósito, não precisa ser TCP / IP ou Pipes. Vi pessoas usarem sinais com slots para executar a comunicação entre processos. No entanto, o padrão de design é o mesmo. Como você se comunica é com o arquiteto do projeto.
Jonathan Henson

Eu estava me referindo ao exemplo.
Karthik Sreenivasan

2

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.


+1 para os exemplos. Você poderia informar sobre o tráfego de arquivos?
Karthik Sreenivasan

1
Por exemplo, se você tem um aplicativo Web que vê picos esporádicos nos uploads de arquivos, você deseja alertar alguém sobre eles. Além disso, isso se aplica a qualquer recurso que possa ver picos em momentos estranhos (por exemplo, tráfego na Web, uso do processador) que podem não ser detectados por verificações agendadas (devido a aliases).
Linkerro

2

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.

+1 para servidor de banco de dados. As coisas estão caindo no lugar. Todos nós usamos o SqlConnection ou OledbConnection para conectar-se ao banco de dados que é realmente processado pelo serviço que reside no servidor.
Karthik Sreenivasan

2

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

+1 para ilustrar com um exemplo. Vou tentar implementar o seu exemplo para entender melhor.
Karthik Sreenivasan

2

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. :)


+1 exemplo ao vivo. De todas as boas respostas fornecidas por todos aqui, agora estou entendendo melhor o uso apropriado dos serviços Windows e acho que outros programadores se beneficiarão definitivamente do compartilhamento de conhecimento aqui. Algumas das implementações que trabalhei no passado poderiam ter sido melhor implementadas usando os serviços do Windows.
Karthik Sreenivasan

0

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.


Se bem entendi, os serviços do Windows não podem ser chamados sem a permissão de administrador?
Karthik Sreenivasan

2
Não, o Windows Services não pode ser instalado ou iniciado sem permissões de administrador. Mas qualquer usuário pode se comunicar com eles, se o serviço está escutando (pense soquetes, pipes nomeados, etc ..)
Eclipse

1
Certamente, um usuário padrão pode iniciar e acessar um serviço do Windows. O serviço deve ser instalado por um usuário administrador.
Jim No Texas

0

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.


0

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 !!!

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.