Olá pessoal,
Em primeiro lugar vamos começar pela seguinte questão: Existe mesmo algum mistério nos Windows Services?
A resposta é simples e objetiva: NÃO.
Desmistificado isso, pode-se definir que o objetivo deste novo artigo será tratar de uma das funcionalidades da plataforma .NET que sem dúvida não é a mais utilizada e conhecida por todos os desenvolvedores: Os Windows Services.
O artigo estará separado em duas partes.
1ª Parte – Descrição de todas as suas principais características.
2ª Parte – Construir do zero um Windows Service, ou seja, mão na massa.
Mas o que são os Windows Services?
Pode-se dizer que os Windows Services são programas ou componentes que rodam em background no sistema operacional. Esses serviços, como também podem ser chamados, existem há bastante tempo, desde o Windows NT se estendendo por toda a sua família Windows 2000, 2003 e com certeza os novos que virão pela frente. Quem ficou de fora dessa lista foram os da família 9x e Me que eram sistemas operacionais destinados a usuários finais. Mas isso não está mais relacionado ao presente e ao futuro, já que a família XP os suporta de maneira bem eficaz.
Muitos destes serviços são conhecidos por todos, como por exemplo, o SQL Server, o Microsoft Exchange e por aí em diante. Todos esses serviços têm diversas características muito importantes. Imagine se por um acaso tivesse um pico de energia ou qualquer outro problema e o servidor onde está toda a base de dados corporativa caísse, o que aconteceria? Com certeza você irá falar que este servidor está configurado para “subir” sozinho, ou seja, reiniciar e voltar a servir a todos que precisam dele. Mas quem iniciou o SQL Server? Aí se encontram essas características. Os serviços podem inicializar sozinhos automaticamente se assim estiverem configurados sem que alguém precise dar um duplo clique em seu executável, por isso o SQL Server voltará a funcionar normalmente. Mas quem logou no servidor? Pois é, aí vem mais uma característica, os serviços não necessitam de usuários logados, eles utilizam credenciais ou contas do Windows pré-definidas para rodar dentro de um contexto de segurança. Todas essas e outras características irão ser abordadas adiante.
Agora você deve estar se perguntado: deve ser bem complicado construir um serviço, não é? A resposta mais uma vez é NÃO. Graças ao .NET esta tarefa ficou simples e prática permitindo com muita tranqüilidade que qualquer desenvolvedor que saiba construir uma Windows Applications construa o seu Windows Service. Antigamente no Visual Studio 6.0 também era possível criar serviços, mas esta sim era uma tarefa bem mais árdua e com muitos detalhes desfavoráveis.
Bom, agora que vocês já têm uma boa idéia do que são e para que servem os serviços, irá ser descrito a seguir as suas principais características de forma mais detalhada.
Para serem executados, os serviços dependem de uma interface chamada Windows Service Control Manager (WSCM). O WSCM é o responsável por toda a execução e controle, desde os eventos como pausar e iniciar até o recurso de debug.
Os serviços possuem uma série de eventos que ocorrem em um dado momento. Os eventos existentes são:
- OnStart – Ocorre quando o serviço é iniciado.
- OnPause – Ocorre quando o serviço é pausado.
- OnStop – Ocorre quando o serviço é parado.
- OnContinue – Ocorre quando o serviço é “despausado”.
- OnShutDown – Ocorre no shutdown do sistema operacional .
- OnCustomComand – Ocorre quando o serviço receber um comando customizado.
- OnPowerEvent – Ocorre no momento em que o sistema operacional percebe por exemplo uma falha de energia.
Esses eventos possuem algumas propriedades importantes que podem ser configuradas em um serviço. São as propriedades CanStop, para o método OnStop, CanPauseandContinue para os métodos OnPause e OnContinue, CanShutDown para o método OnShutDown e CanHandledPowerEvent para o método OnPowerEvent.
Exemplo: Você pode definir que um serviço possa ser parado em algum momento e então habilitar a propriedade CanStop; do contrário você poderia definir que o seu serviço nunca poderá ser parado, desabilitando então essa propriedade e como conseqüência o evento OnStop não existiria. O mesmo raciocínio pode ser usado para as outras propriedades existentes.
Quanto ao quesito segurança, os serviços não precisam que nenhum usuário logue no sistema operacional, pelo contrário, os serviços são executados antes do logon, pois ele se inicia no contexto de uma das contas abaixo:
- User – Solicita um nome de usuário e senha válidos para quando o serviço for instalado e executado no contexto de uma conta especificada na rede.
- LocalService – Executa no contexto de uma conta que age como um usuário não privilegiado no computador local e com credenciais anônimas em qualquer computador remoto.
- LocalSystem – Executa o contexto de uma conta que possua privilégios locais e possua credenciais em qualquer computador remoto.
- NetworkService – Executa no contexto de uma conta que age sem privilégios no computador local e possua credenciais em qualquer computador remoto.
O importante de ressaltar sobre o tema segurança é que de uma maneira geral deve-se tentar utilizar a conta LocalService que tem baixos privilégios e consequentemente uma segurança maior.
Com o .NET pode-se desenvolver dois tipos de serviços, são eles:
- Win32OwnProcess – possuem um único processo para sua execução.
- Win32ShareProcess – compartilham recursos na sua execução.
Os serviços têm uma característica peculiar se comparado às demais applications (Windows, Web etc.) existentes, ele necessita de duas classes (ServiceProcessInstaller e ServiceInstaller) específicas para a sua instalação. Essas classes irão fazer a instalação propriamente dita e toda a parte de registro no sistema operacional e consequentemente no WSCM.
Não se pode esquecer que os serviços são aplicações que rodam em background, consequentemente não se usa mensagens de erro ou de alerta na tela do computador, ou seja, nada de message box pessoal! Todas essas mensagens podem e devem ser direcionadas para outros lugares, como por exemplo, o Event Log do sistema operacional que irá ser demonstrado na prática na parte 2 do artigo.
O último alerta descrito será em relação ao ponto inicial dos serviços. Todas as ações iniciais devem ser programadas no método OnStart e nunca no construtor. Isso porque o construtor é acionado quando o executável roda (sempre antes do OnStart) e não quando o serviço é iniciado. Sendo assim, se o serviço é parado e posteriormente reiniciado o construtor não é mais acionado, o que inviabilizaria colocar código no mesmo.
Pessoal essa é parte mais chata, ou seja, a teoria. Mas vocês já podem comemorar, pois ela acabou.
Na 2ª parte será demonstrado o que todos querem realmente, como criar o seu Windows Service. Estudem esses conceitos importantes que certamente serão utilizados adiante.
Abraços e aguardem a continuação em breve.
