Algumas semanas atrás eu pedi um pergunta semelhante em SO. Em uma casca de noz, minha abordagem há algum tempo tem sido desenvolver um serviço do Windows. Eu usaria o NServiceBus (basicamente o MSMQ, sob as coberturas) para organizar solicitações do meu aplicativo da web para o meu serviço. Eu costumava usar o WCF, mas obter uma transação distribuída para funcionar corretamente sobre o WCF sempre parecia uma dor no rabo. O NServiceBus fez o truque, eu poderia comprometer dados e criar tarefas em uma transação e não me preocupar se meu serviço estava funcionando no momento. Como um exemplo simples, se alguma vez eu precisasse enviar um email (por exemplo, um email de registro) eu criaria a conta de usuário e dispararia um sinal para o meu Serviço do Windows (para enviar o email) em uma transação. O manipulador de mensagens no lado do serviço pegaria a mensagem e processaria de acordo.
Desde que o ASP .NET 4.0 e o AppFabric foram lançados, existem várias alternativas viáveis ao mecanismo acima. Voltando à pergunta que mencionei acima, agora temos o AppInitialize (via net.pipe) do AppFabric, bem como o recurso Auto-Start do ASP .NET 4.0, que torna o desenvolvimento dos Serviços do Windows como aplicativos da Web uma alternativa viável. Eu comecei a fazer isso agora por vários motivos (o maior deles sendo a implantação não é mais um problema):
- Você pode desenvolver uma interface de usuário da web sobre seu serviço (desde que ele esteja sendo executado como um aplicativo da web). Isso é extremamente útil para ver o que está acontecendo no tempo de execução.
- Seu modelo de implantação para seus aplicativos da Web funcionará para seu aplicativo de serviço.
- O IIS fornece alguns recursos interessantes para lidar com falhas de aplicativos (semelhantes em alguns aspectos a um serviço do Windows).
- Os desenvolvedores da Web estão muito familiarizados com o desenvolvimento de aplicativos da Web (naturalmente), a maioria não sabe muito sobre as práticas recomendadas ao desenvolver um serviço do Windows.
- Ele oferece várias alternativas para expor uma API para consumo de outros aplicativos.
Se você seguir esse caminho (me perdoe por copiar e colar da postagem original), eu definitivamente consideraria a execução da lógica de plano de fundo em um aplicativo da web separado. Há várias razões para isso:
- Segurança . Pode haver um modelo de segurança diferente para a interface do usuário que exibe informações sobre os processos em segundo plano em execução. Eu não gostaria de expor essa interface para mais ninguém além da equipe de operações. Além disso, o aplicativo da web pode ser executado como um usuário diferente que possui um conjunto elevado de permissões.
- Manutenção . Seria ótimo poder implantar alterações no aplicativo que hospeda os processos em segundo plano sem afetar o usuário no site do front-end.
- Desempenho . Ter o aplicativo separado das solicitações do usuário de processamento do site principal significa que os threads de segundo plano não diminuirão a capacidade do IIS de manipular a fila de solicitações de entrada. Além disso, o aplicativo que processa as tarefas em segundo plano pode ser implantado em um servidor separado, se necessário.
Isso retorna ao aspecto do empacotamento. WCF, NServiceBus / RabbitMQ / ActiveMQ etc., baunilha MSMQ, API RESTful (pense MVC) são todas as opções. Se você estiver usando o Windows Workflow 4.0, poderá expor um ponto de extremidade do host que seu aplicativo da Web pode consumir.
A abordagem de hospedagem na web para serviços ainda é relativamente nova para mim, apenas o tempo dirá se foi a escolha correta. Até agora está bom. By the way, se você não quiser usar o AppFabric (eu não poderia porque, por algum motivo bizarro, o Windows Server Web Edition não é suportado), o recurso Auto-Start mencionado no post do Gu funciona muito bem. Fique longe do arquivo applicationhost.config, tudo nessa postagem é possível configurar através do console do IIS (Editor de Configuração no nível do servidor principal).
Nota: originalmente eu tinha postado mais alguns links nesta mensagem, mas, infelizmente, este é o meu primeiro post para esta troca e apenas um link é suportado! Havia basicamente dois outros, para obtê-los do Google "Morte ao Windows Services ... Long Live AppFabric!" e "auto-start-asp-net-applications". Desculpe por isso.