Desenvolvimento - ASP. NET
WCF, IIS e Threads
Sabemos que podemos utilizar o IIS como hosting para um serviço WCF.
por Israel AéceSabemos que podemos utilizar o IIS como hosting para um serviço WCF. O Visual Studio 2008 já traz uma template chamada WCF Service. A finalidade desta template é possibilitar a criação de vários serviços, onde cada um será representado por um arquivo com a extensão *.svc. Depois de desenvolvido, podemos publicar este serviço em um servidor com IIS e com o .NET Framework devidamente instalado.
O WCF fornece dois tipos não documentados dentro do namespace System.ServiceModel.Activation, a saber: HttpHandler e HttpModule. A finalidade destes tipos é acoplá-los ao pipeline do ASP.NET e, quando uma requisição chegar para um serviço WCF (*.svc), o ASP.NET irá desviar a execução para o HttpHandler.
Um grande problema que ocorre neste procedimento é com relação ao uso de threads. Como a requisição é inicialmente passada pelo ASP.NET e, quando ele detecta quese trata deum serviço WCF, uma thread deI/O é criada para executar o serviço mas, a worker thread que é utilizada por tratar as requisições do ASP.NET, continuará bloqueada até que a requisiçãoà operação esteja completa. Isso impedirá que a worker thread atendaà outras requisições enquanto espera que o processo seja finalizado.
A configuração padrão do WCF (mesmo depois do SP1 instalado) continua utilizando esta mesma técnica, ou seja, o processamento síncrono da operação. Mas,a partir do SP1 do .NET Framework 3.5, foram introduzidos mais dois tipos que tem o papel de executar, de forma assíncrona, as operações que chegam pelo ASP.NET ao WCF. Esses novos tipos são: ServiceHttpModule e ServiceHttpHandlerFactory.
Com estes dois novos tipos acoplados no pipeline do ASP.NET, permitirá que a execução seja feita de forma assíncrona, liberando a worker thread utilizada pelo ASP.NET para atender a outras requisições. Para habilitar o processamento assíncrono, podemos utilizaruma ferramentachamada WcfAsyncWebUtil.exe, desenvolvida pelo Wenlong Dong.
É importante dizer que há uma relação entre o processamento assíncrono do runtime do ASP.NET/WCF com o contrato assíncrono (AsyncPattern = true). Se combinarmos o handler/módulo assíncrono com o contrato assíncrono, nenhuma thread será consumida durante a espera pelo processamento assíncrono da operação. Mesmo quando o contrato não é assíncrono, ao utilizar o handler/módulo assíncrono, teríamos uma diminuição de threads rodando concorrentemente e assim, tendo um ganho considerável.
O WCF fornece dois tipos não documentados dentro do namespace System.ServiceModel.Activation, a saber: HttpHandler e HttpModule. A finalidade destes tipos é acoplá-los ao pipeline do ASP.NET e, quando uma requisição chegar para um serviço WCF (*.svc), o ASP.NET irá desviar a execução para o HttpHandler.
Um grande problema que ocorre neste procedimento é com relação ao uso de threads. Como a requisição é inicialmente passada pelo ASP.NET e, quando ele detecta quese trata deum serviço WCF, uma thread deI/O é criada para executar o serviço mas, a worker thread que é utilizada por tratar as requisições do ASP.NET, continuará bloqueada até que a requisiçãoà operação esteja completa. Isso impedirá que a worker thread atendaà outras requisições enquanto espera que o processo seja finalizado.
A configuração padrão do WCF (mesmo depois do SP1 instalado) continua utilizando esta mesma técnica, ou seja, o processamento síncrono da operação. Mas,a partir do SP1 do .NET Framework 3.5, foram introduzidos mais dois tipos que tem o papel de executar, de forma assíncrona, as operações que chegam pelo ASP.NET ao WCF. Esses novos tipos são: ServiceHttpModule e ServiceHttpHandlerFactory.
Com estes dois novos tipos acoplados no pipeline do ASP.NET, permitirá que a execução seja feita de forma assíncrona, liberando a worker thread utilizada pelo ASP.NET para atender a outras requisições. Para habilitar o processamento assíncrono, podemos utilizaruma ferramentachamada WcfAsyncWebUtil.exe, desenvolvida pelo Wenlong Dong.
É importante dizer que há uma relação entre o processamento assíncrono do runtime do ASP.NET/WCF com o contrato assíncrono (AsyncPattern = true). Se combinarmos o handler/módulo assíncrono com o contrato assíncrono, nenhuma thread será consumida durante a espera pelo processamento assíncrono da operação. Mesmo quando o contrato não é assíncrono, ao utilizar o handler/módulo assíncrono, teríamos uma diminuição de threads rodando concorrentemente e assim, tendo um ganho considerável.
Israel Aéce - Especialista em tecnologias de desenvolvimento Microsoft, atua como desenvolvedor de aplicações para o mercado financeiro utilizando a plataforma .NET. Como instrutor Microsoft, leciona sobre o desenvolvimento de aplicações .NET. É palestrante em diversos eventos Microsoft no Brasil e autor de diversos artigos que podem ser lidos a partir de seu site http://www.israelaece.com/. Possui as seguintes credenciais: MVP (Connected System Developer), MCP, MCAD, MCTS (Web, Windows, Distributed, ASP.NET 3.5, ADO.NET 3.5, Windows Forms 3.5 e WCF), MCPD (Web, Windows, Enterprise, ASP.NET 3.5 e Windows 3.5) e MCT.
