Desenvolvimento - C#
WCF - Hosting
Como já sabemos, WCF - Windows Communication Foundation - é parte integrante do .NET Framework 3.0. Ele fornece um conjunto de classes para a construção e hospedagem de serviços baseando-se na arquitetura SOA (Service Oriented Architecture), podendo expor tais serviços para serem acessados através dos mais diversos tipos de protocolos, como por exemplo: HTTP, TCP, IPC e MSMQ.
por Israel Aéce
Com o host devidamente configurado, independente se foi através de código declarativo (*.Config) ou via código, basta inicializar a aplicação e, através do endereço que foi especificado para criar o serviço, você pode adicionar a referencia na aplicação cliente e, em seguida, já conseguirá consumir o serviço.
Como falamos acima, o self-hosting permite utilizarmos uma aplicação .NET para disponibilizá-lo. Existem três tipos de aplicações que podem atender essa necessidade: Console Application (onde baseamos o nosso teste), Windows Forms e Windows Service. A Console Application é muito útil quando estamos efetuando testes ou mesmo em tempo de desenvolvimento e jamais é indicada para o ambiente de produção, já que necessita de um usuário logado na máquina onde o executável reside e, ainda podemos acidentalmente fechar o host, o que evitaria que requisições subseqüentes sejam processadas. A outra opção é a utilização de criar o host em uma aplicação Windows Forms. Ela é um pouco melhor em relação a Console Application, mas ainda exige que um usuário acesse o sistema para que possa inicializar o host. Finalmente, temos o Windows Service. Este sim é um dos mais apropriados tipos de aplicações para servir como host de uma serviço WCF, pois não necessita que o usuário esteja logado para que funcione e ainda pode ser configurado para ser inicializado automaticamente quando o computador for ligado. Independente disso, o host já deve estar no ar quando a requisição chegar, o que já não acontece com o IIS, pois ele ativa o objeto assim que a requisição chega ao servidor. Analisaremos o host através do IIS na próxima seção. IIS - Internet Information Services Até o lançamento do WCF tínhamos (e ainda temos) à disposição dentro da plataforma .NET, a possibilidade de construirmos os famosos Web Services (ASMX). Os Web Services foram lançados desde a versão 1.0 do .NET Framework e revolucionou a forma de como expor dados e componentes para consumo. Eles, por sua vez, estão fortemente ligados à arquitetura do ASP.NET, onde a dependência do protocolo HTTP e algumas de suas funcionalidades específicas são uma das "piores" partes, já que quebra alguns dos conceitos que a arquitetura SOA impõe. Os serviços WCF também podem utilizar o IIS como hosting, de forma bem semelhante aos Web Services (ASMX), tirando alguns proveitos do mesmo; um dos principais é a ativação do processo, que é feita quando uma requisição chega até o servidor. Mas, como nem tudo é perfeito, o IIS limita o tipo de transporte, obrigando-nos a utilizar somente o protocolo HTTP. Para que seja possível fazer o host de um serviço dentro do IIS, é necessário que você tenha um arquivo físico com a extensão *.svc. Esse tipo de arquivo está associado com um serviço do WCF e, quando a requisição para um recurso deste tipo chega no servidor, ele é tratado através de um módulo chamado HttpModule em conjunto com um handler chamado HttpHandler, que estão contidos dentro do namespace System.ServiceModel.Activation (isso pode ser confirmado através do arquivo Web.Config que está dentro do seguinte endereço: %windir%\Microsoft.NET\Framework\v2.0.50727\CONFIG). A forma com que estes objetos trabalham irá depender do modo de compatibilidade com o ASP.NET que pode estar ou não estar habilitado. Analisaremos os dois modos existentes mais adiante, ainda neste artigo. Os arquivo com extensão *.svc tem uma diretiva ServiceHost, onde informamos a linguagem que estaremos escrevendo o código, o nome do serviço e o caminho até o arquivo de CodeBehind do serviço, que reside dentro da pasta especial App_Code. Isso é bem semelhante à estrutura de uma página ASP.NET. O código abaixo mostra a estrutura, de apenas uma linha, de um arquivo *.svc:
Dentro do arquivo de CodeBehind criamos uma classe e implementamos a Interface IServiceContract (já comentada mais acima). Depois de realizada a devida implementação devida realizada, definindo efetivamente o que os métodos irão fazer, é necessário criarmos o endpoint no arquivo Web.Config para que o IIS consiga identificar e expor o serviço. A configuração é bem semelhante ao arquivo App.Config que vimos acima, que configura o serviço em um self-hosting. Ligeiras mudanças são realizadas, conforme é mostrado abaixo:
É importante analisar que na criação do endpoint não é necessário o atributo address, pois o endereço (base address) será determinado a partir do endereço do arquivo *.svc. Outro detalhe importante é com relação ao atributo httpGetEnabled do elemento serviceMetadata que, quando estiver definido como True, é responsável por habilitar que o contrato do serviço seja publicado e, conseqüentemente, acessado pelos clientes. Finalmente, o atributo includeExceptionDetailInFaults, que é utilizado para propósitos de depuração pois, quando é definido como True, propaga qualquer exceção atirada pelo serviço para os clientes, facilitando a depuração quando estamos consumindo o serviço em um ambiente de testes. Claro que essa informação somente deve ser disponibilizada quando o serviço ainda está em processo de desenvolvimento, pois se essas informações chegarem aos clientes finais, você pode estar abrindo brechas para que ele possa explorar as informações de erro, inclusive o stack trace. Ao invocar o serviço no browser, já conseguimos ter acesso ao mesmo, inclusive ao seu contrato. A imagem abaixo ilustra o serviço sendo apresentado no browser:
Neste momento o serviço já está pronto para ser consumido pelos clientes e, como podemos notar na imagem acima, ela mesma exibe um exemplo de como gerar o proxy no cliente, através do utilitário svcutil.exe ou ainda, se estiver utilizando o Visual Studio .NET 2005 com o .NET Framework 3.0 devidamente instalado, pode ir diretamente no projeto onde deseja consumir o serviço, clicar com o botão direito do mouse em cima do mesmo e, em seguida, clicar na opção "Add Service Reference...", informando o endereço HTTP acima, que automaticamente o proxy será gerado e adicionado à aplicação. Podemos tranquilamente criar um diretório virtual dentro do IIS para hospedar os serviços WCF. Porém há cenários onde os serviços WCF estão dentro do IIS, mas contidos em uma aplicação ASP.NET ou até mesmo em uma aplicação do tipo Web Services (ASMX). Em todas as ocasiões, muitas vezes é necessário fazer o uso de algumas funcionalidades específicas do protocolo HTTP para atender uma determinada necessidade, como por exemplo, a utilização de variáveis de aplicação (Application), sessão (Session) ou até mesmo informações contidas no contexto HTTP (HttpContext). O WCF, em conjunto com o runtime do ASP.NET, fornece dois modos de execução de um pedido para um serviço, que tratam de forma bem diferente a requisição ao *.svc. Essas formas são: Mixed Transports Mode ou ASP.NET Compatibility Mode, as quais falaremos a seguir. |
Na primeira delas, Mixed Transports Mode (modo default), a requisição do serviço não é executada pelo ASP.NET pipeline. Isso permite definir endpoints com diferentes formas de transportes. Uma das características mais importantes deste modo é que ele não permite que serviços WCF façam uso de funcionalidades específicas do ASP.NET, mais precisamente do protocolo HTTP. Entre as funcionalidades desabilitadas em virtude de ter esse modo habilitado temos:
Já o ASP.NET Compatibility Mode trata de um modo que habilita todas as restrições impostas pelo modo anterior, mas impõe um grande ponto negativo, ou seja, o serviço fica completamente dependente do protocolo HTTP e, sendo assim, quando o serviço estiver sendo ativado, os endpoints serão verificados para assegurar que protocolos não-HTTP estão habilitados.
Os trechos de código abaixo, com algumas partes suprimidas por questões de espaço, ilustram a configuração na classe do serviço e no arquivo Web.Config para habilitar o ASP.NET Compatibility Mode:
Um pouco acima falamos sobre o módulo HttpModule e o handler HttpHandler, que fazem parte da execução do processamento de uma requisição para um serviço WCF. A forma de trabalho irá depender exclusivamente do modo que está habilitado. Se o modo Mixed Transports estiver habilitado, o módulo HttpHandler irá interceptar a requisição logo após o evento PostAuthenticateRequest e, neste momento, o objeto HttpContext.Current é definido como nulo. Agora, quando o modo ASP.NET Compatibility estiver habilitado, o módulo HttpModule será um simples filtro, sem fazer nada de mais importante. Depois da execução do módulo, o handler é finalmente executado, para efetivamente fazer o trabalho do serviço WCF. WAS - Windows Activation Services O Windows Vista fornece um novo recurso chamado WAS - Windows Activation Services. Trata-se de um processo que é instalado dentro do IIS 7, que desacopla a arquitetura de ativação do IIS, permitindo assim o transporte não somente via HTTP, mas também via named pipes, TCP e MSMQ (message queue). Um outro ponto importante é que, além de suportar múltiplos protocolos, fornece as funcionalidades dadas pelo IIS, como por exemplo o health monitoring, reciclagem de processo e, conseqüentemente, ferramentas de gerenciamento para tais configurações. Quando o listener de um determinado protocolo recebe a requisição, o WAS verifica a existência do work process para serví-lo e, antes de processar a requisição, o handler assegura que uma instância da classe ServiceHost tenha sido criada. Assim como vimos no IIS, felizmente o WAS utiliza também o modelo de ativação baseado na mensagem, o que aumenta a escalabilidade para as requisições em qualquer protocolo. O WAS, por padrão, não vêm instalado por padrão. É necessário fazer alguns ajustes para habilitá-lo e, conseqüentemente, disponibilizar serviços WCF para serem consumidos nos mais diversos protocolos. Deixarei a configuração e utilização do WAS dentro do IIS 7 (com Windows Vista) para um futuro artigo, dedicando-o para explorar completamente esse novo recurso. Conclusão: Como podemos notar no decorrer deste artigo, todo o host basicamente deverá ser um processo executável, que terá um AppDomain onde o serviço será carregado. Agora, com todas essas alternativas, você deve analisar e ser capaz de escolher qual das soluções é mais viável à sua necessidade, sempre pesando os prós e contras de cada um dos tipos de host. |