Revista MSDN Magazine Edição 15 - Execução do ASMX sem o IIS

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

Execução do ASMX sem o IIS

por Aaron Skonnard

Quando o Microsoft® .NET Framework foi distribuído, introduziu uma estrutura de Web Services revolucionária conhecida como ASMX. A motivação por trás do projeto do ASMX era a máxima simplificação possível do processo de desenvolvimento de Web Services, para que até mesmo quem não fosse um especialista em XML pudesse criar um Web Service. O ASMX conseguiu isso ocultando a maior parte do XML básico e os detalhes básicos dos Web Services. Em vez de obrigar os desenvolvedores a lidar diretamente com envelopes SOAP e arquivos da Web Services Description Language (WSDL), o ASMX introduziu camadas de associação automática reduzindo a distância entre a codificação tradicional do .NET.

O ASMX também está intimamente integrado ao popular pipeline HTTP do ASP.NET. Assim, conta com os mesmos benefícios que os aplicativos Web tradicionais do ASP.NET , como um ambiente de hospedagem e modelo de processo sofisticados, opções robustas de configuração e implementação e pontos flexíveis de extensibilidade. Conseqüentemente, o ASMX é geralmente a primeira opção da maioria dos desenvolvedores de Web services. A maioria dos desenvolvedores supõe, incorretamente, que o ASMX exige o IIS; afinal, é o único exemplo de uso que já viram. Mas a verdade é que o ASMX não tem dependências técnicas do IIS, de forma alguma.

A necessidade de hospedar Web Services sem o IIS é bastante real. Em alguns ambientes pode não ser possível ter o IIS em execução no computador que tiver que hospedar o Web Service, por diversos motivos. Felizmente, você pode hospedar o ASMX em seu próprio processo, sem o IIS. Tornou-se possível fazer isso desde o lançamento da .NET Framework 1.0, mas era preciso fornecer seu próprio servidor Web para receber solicitações de HTTP. O Cassini é um exemplo de servidor Web desenvolvido pela equipe do ASP.NET, que atendia a essa necessidade e permitia a execução de páginas ASP sem o IIS. Contudo, criar no seu próprio servidor Web, ou usar um exemplo como o Cassini, não parece ser razoável para a maioria dos desenvolvedores.

Desde o lançamento do Windows Server¢ 2003 e do Windows® XP SP2, há uma nova pilha de protocolos HTTP disponível, chamada http.sys. Com a http.sys e algumas classes gerenciadas no .NET Framework 2.0 (especialmente a HttpListener), você pode construir facilmente um servidor Web diretamente no seu aplicativo, sem a necessidade do IIS na máquina. Esses avanços tornaram possível a execução do ASMX em qualquer lugar. Não se esqueça que o .NET Framework 2.0 está atualmente na versão Beta e, portanto, está sujeito a mudanças.

Arquitetura HTTP do ASP.NET

O ASP.NET foi projetado especificamente para evitar dependências no IIS. A arquitetura básica consiste de um pipeline de classes .NET que trabalham em conjunto, para processar as mensagens HTTP de entrada. É considerado um pipeline porque cada solicitação HTTP percorre uma seqüência de objetos, cada um executando algum processamento.

A classe HttpRuntime situa-se no início do pipeline e é responsável pelo início do processo. O pipeline inicia a execução quando o método estático ProcessRequest é chamado na classe HttpRuntime. O ProcessRequest toma um objeto HttpWorkerRequest, que contém todas as informações da solicitação atual. O HttpRuntime usa as informações do HttpWorkerRequest para preencher o objeto HttpContext. Depois instancia a classe HttpApplication apropriada, que invocará quaisquer implementações de  IHttpModule registradas no aplicativo, para pré/pós processamento. Neste ponto, a implementação apropriada de IHttpHandler é identificada, instanciada e invocada.

Esse processo ocorre para toda solicitação de HTTP que entrar no pipeline. Todos os recursos do ASP.NET (inclusive do ASMX) estão nas classes de pipeline. Por exemplo, o suporte para o processamento de endpoints do ASMX tem início quando a solicitação chega à classe System.Web.Services.Protocols.WebServiceHandlerFactory, que é responsável pela identificação, compilação (se necessário) e a instanciação da classe ASMX identificada, assim como a invocação do WebMethod destinado pela mensagem SOAP de entrada.

Figura 1  Pipeline de HTTP e servidores Web

O pipeline é totalmente autônomo e desconectado do IIS. Até mesmo executa em um processo independente do inetinfo.exe, quando usado em conjunto com o IIS. O nome do processo depende do SO do host (aspnet_wp.exe no Windows XP e w3wp.exe no Windows Server 2003). Além de ter seu próprio modelo de processo, o pipeline também possui uma história de configuração diferente, desassociada da metabase do IIS. A única coisa que o pipeline não traz é seu servidor Web capaz de receber solicitações de HTTP de entrada. Você ainda precisa de algo como o IIS 5.0 ou o http.sys, que seja capaz de ouvir as mensagens HTTP de entrada. Mesmo assim, esses componentes são responsáveis somente pelo recebimento das solicitações HTTP e o direcionamento dessas para o pipeline do ASP.NET, que trata de tudo a partir desse ponto (Figura 1).

Depois que a solicitação chegar ao processo worker, esse processo criará um objeto HttpWorkerRequest (representando a solicitação de entrada) e chamará o HttpRuntime.ProcessRequest para lançar o pipeline. Devido a esse projeto elegante, é possível chamar HttpRuntime diretamente de dentro do aplicativo.

Hospedando o pipeline do HTTP

As classes que você precisa hospedar no ASP.NET encontram-se nos namespaces System.Web e System.Web.Hosting. As classes principais de que você precisará para começar são ApplicationHost, HttpRuntime e uma classe derivada de HttpWorkerRequest. Comece chamando ApplicationHost.CreateApplicationHost. Esse método cria um novo domínio de aplicativo (AppDomain) capaz de processar pedidos ASP.NET. Como você está criando explicitamente o AppDomain, deverá especificar o diretório virtual e o diretório físico correspondente ao fazer a chamada.

Além de criar o novo AppDomain, CreateApplicationHost também instancia um objeto dentro do novo AppDomain, por meio do qual você pode se comunicar. Você especifica o tipo que gostaria que instanciasse ao fazer a chamado ao método. Como o objeto será usado além das fronteiras do AppDomain, ele deverá derivar de MarshalByRefObject. Você deverá usar sua própria classe que contiver os métodos de que precisará para interagir com o AppDomain. Por exemplo, no mínimo você precisará de um método ProcessRequest que torne possível o envio de uma nova solicitação ASP.NET para processamento.

Há uma classe que poderia ser usada para esse propósito:

public class MySimpleHost : MarshalByRefObject

...