Revista MSDN Magazine Edição 21 - Web e Windows Services com ASP.NET em Intervalos Programados

Clique aqui para ler todos os artigos desta edição

Web e Windows Services com ASP.NET em Intervalos Programados

por Andrew Needleman

Suponha que você tenha escrito um excelente aplicativo n-camadas em ASP.NET e queira estendê-lo para executar tarefas programadas, tais como envio de e-mails para usuários selecionados no banco de dados a cada duas horas ou para analisar regularmente os dados no cache do ASP.NET a fim de monitorar a saúde do aplicativo. Você não quer jogar fora o modelo de objeto de seu aplicativo ASP.NET nem criar muitas dependências entre um agendador separado e o aplicativo ASP.NET, então como pode evitar isso e ainda manter os aplicativos trabalhando juntos?

Nos aplicativos baseados no .NET Framework, os timers são freqüentemente utilizados para realizar atividades em intervalos programados, por isso usar um deles parece ser uma solução apropriada. Você poderia iniciar um timer a partir do handler Application_Start no Global.asax para executar suas tarefas programadas. Infelizmente, essa solução não é ideal em domínios do aplicativo, processos ou reinicializações do sistema porque é necessário solicitar ao aplicativo que este inicie o timer. O ASP.NET é um paradigma de programação passivo que só responde a solicitações de HTTP, por isso um processo ou entrada de usuário deve chamar o código para que ele seja executado.

Uma solução melhor seria usar um Web service para fornecer uma interface com seu aplicativo ASP.NET e para criar um Windows® Service que o chame em intervalos programados. Desse modo, o aplicativo ASP.NET não precisa possuir a lógica de programação e só precisará se preocupar com a execução das tarefas que for capaz de executar. E, como o Web service pode ser executado no mesmo contexto de aplicativo que o restante de seu aplicativo ASP.NET, ele poderá ser executado no mesmo contexto de seu código existente.

Usarei um Windows service para iniciar a chamada do Web service porque os Windows services podem iniciar a si próprios quando o Windows é inicializado. Por isso, mesmo que o servidor seja reiniciado, o aplicativo será capaz de se autoiniciar. Essa capacidade de reinicialização torna o Windows service uma solução mais robusta para a tarefa do que um aplicativo comum baseado em Windows. Essa é também a razão por que os Windows services são usados para tantos processos de background (como IIS).

Neste artigo, demonstrarei como fazer isso durante a criação do menor número possível de dependências entre seu aplicativo de agendamento e o aplicativo ASP.NET. A solução envolve simplificar o aplicativo de programação que inicia o job do ASP.NET. No aplicativo de programação, não será chamada nenhuma lógica que seja específica ao aplicativo ASP.NET, exceto pelo endpoint do Web service que ela chamar. O Windows service usará um arquivo app.config para armazenar tanto o URL do Web service como o intervalo que o Windows service deverá aguardar entre as chamadas para o Web service. Armazenando essas duas configurações no arquivo app.config do Windows service, você poderá alterá-las sem precisar recompilar o Windows service. Caso precise alterar o comportamento do aplicativo quando ele for chamado, você poderá apenas alterar a lógica do aplicativo ASP.NET; no entanto, você não precisará alterar o código do aplicativo de programação. Isso significa que o aplicativo de programação (agendamento) será isolado das mudanças do aplicativo ASP.NET.

Observe que essa solução baseia-se na premissa de que existem algumas tarefas que só deverão ser executadas no contexto de um aplicativo ASP.NET em execução. Se isso não for um requisito para suas tarefas, você deverá considerar fazer uma referência ao assembly da lógica de negócio do aplicativo ASP.NET diretamente de seu Windows service e desviar do processo ASP.NET para acionar as tarefas.

A Estrutura do Aplicativo

Um aplicativo ASP.NET comum é criado com uma série de camadas independentes que executam funções específicas. Em meu exemplo, tenho classes de acesso de banco de dados, classes de lógica de negócios, classes de fluxos de negócios e páginas ASP.NET que funcionam como o ponto de entrada para essas camadas (observe a Figura 1).

Figura 1 O Plano

As páginas ASP.NET são usadas apenas para exibir e recuperar dados. Elas funcionam como uma interface de/para as classes de fluxo de negócios, que na verdade coordenam todo o trabalho. As classes de fluxo chamam as classes da lógica de negócios na ordem apropriada para concluir uma transação específica, tal como ordenar um widget. Por exemplo, a classe de fluxo poderia primeiro chamar a lógica de negócio para verificar o inventário, depois ordenar o widget e, por fim, reduzir o inventário ao nível apropriado.

As classes da lógica de negócios decidem como chamar as classes de acesso do banco de dados e, se necessário, processam esse resultado para obter o resultado final que você poderá usar para outras operações. Por exemplo, a lógica de negócios seria usada para calcular o preço total, incluindo o imposto para um estado em particular. Primeiro você precisa recuperar a porcentagem de imposto desse estado e dos preços base no banco de dados usando as classes de acesso aos dados e, em seguida, multiplicá-las para encontrar o imposto total de cada item.

As classes de acesso a banco de dados armazenam a lógica que permite a conexão com o banco de dados e o retorno de um resultset em um formato como DataSet, DataTable ou DataReader que possa ser consumido pelas camadas mais altas. Tais classes apenas recuperam os dados do banco de dados e os atualizam de acordo com as informações que recebem; elas não processam o resultado. Por exemplo, elas podem recuperar a porcentagem de imposto de um dado estado, mas não calculam o imposto total do pedido. ...