Como sabemos, aplicações Silverlight podem recorrer a recursos que rodam no servidor que a hospeda utilizando WCF. Com isso, a aplicação que serve como host para o serviço é uma aplicação ASP.NET tradicional (WebForms ou MVC, Web Site ou Web Application), onde efetivamente criaremos o serviço WCF para que servirá a aplicação Silverlight.

Uma vez com o serviço pronto, tudo o que precisamos fazer para consumir o serviço no Silverlight, é a referência para o mesmo, utilizando a opção Add Service Reference, fornecida pela IDE do Visual Studio .NET. Como é feito em qualquer aplicação cliente, o Visual Studio extrairá as informações do documento WSDL e criará o proxy do lado do cliente, incluindo um arquivo chamado ServiceReferences.ClientConfig, que conterá as configurações de acesso ao serviço referenciado. O código abaixo ilustra esse arquivo:

<configuration>
  <system.serviceModel>
    <bindings>
      <basicHttpBinding>
        <binding name="BasicHttpBinding_IContrato"
                 maxBufferSize="2147483647"
                 maxReceivedMessageSize="2147483647">
          <security mode="None" />
        </binding>
      </basicHttpBinding>
    </bindings>
    <client>
      <endpoint address="http://localhost:1551/ServicoDeTeste.svc"
                binding="basicHttpBinding"
                bindingConfiguration="BasicHttpBinding_IContrato"
                contract="Servico.IContrato"
                name="BasicHttpBinding_IContrato" />
    </client>
  </system.serviceModel>
</configuration>

Como podemos notar, endereço do serviço WCF está definido de forma absoluta. Isso implica em alguns problemas que podemos ter durante a distribuição/instalação do projeto no servidor. Esse arquivo é comprimido para dentro de um outro arquivo, com extensão *.xap, e que por sua vez, é depositado no diretório ClientBin do projeto ASP.NET que hospeda a aplicação Silverlight. Ao colocar isso no servidor onde ele deverá rodar, provavelmente o endereço do serviço mudará, e ficará complicado e trabalhoso para alterar.

Para melhorar isso, a versão 4.0 do Silverlight permite especificar, de forma relativa, o endereço para o serviço, ou seja, não precisamos mais definir o endereço completo até o arquivo *.svc. Apesar da IDE ainda não ser inteligente o bastante para utilizar esse recurso ao referenciar o serviço, nada nos impede de alterar isso diretamente no arquivo de configuração do lado do cliente, apontando relativamente para o serviço WCF. Para o teste, eu criei um serviço na raiz da aplicação ASP.NET, e como a aplicação Silverlight é colocada na pasta ClientBin desta mesma aplicação, tudo o que precisamos fazer é subir um nível (../). Abaixo podemos visualizar essa ligeira mudança, mas que traz uma grande flexibilidade.

<configuration>
  <system.serviceModel>
    <bindings>
      <basicHttpBinding>
        <binding name="BasicHttpBinding_IContrato"
                 maxBufferSize="2147483647"
                 maxReceivedMessageSize="2147483647">
          <security mode="None" />
        </binding>
      </basicHttpBinding>
    </bindings>
    <client>
      <endpoint address="../ServicoDeTeste.svc"
                binding="basicHttpBinding"
                bindingConfiguration="BasicHttpBinding_IContrato"
                contract="Servico.IContrato"
                name="BasicHttpBinding_IContrato" />
    </client>
  </system.serviceModel>
</configuration>

Temos dentro do sistema operacional uma ferramenta administrativa conhecida como Component Services. É através desta ferramenta que controlamos os componentes que utilizam a tecnologia COM+, permitindo visualizar aqueles componentes que estão hospedados em um determinado servidor, configurar suas características, entre várias outras funcionalidades.

Em muitas situações, o Component Services é encarado como sendo o servidor de aplicações, pois é nele que estarão todos os componentes que são utilizados pela companhia. Utilizamos o Component Services para centralizar tais componentes, fazendo uso de suas funcionalidades, tais como: suporte à transações, pool de objetos, sincronização, etc. As aplicações clientes, sejam elas Windows ou Web, recorrem a estes componentes hospedados neste servidor para executar as tarefas.

Com o surgimento do WCF, o COM+ está perdendo espaço, e a partir de agora, quando falamos em sistemas distribuídos, utilizamos o WCF como tecnologia para suportar isso. Uma das principais características do WCF, é a independência de hosting, ou seja, podemos utilizar qualquer tipo de aplicação para hospedar um serviço WCF.

No ambiente do WCF, um dos hosts que mais se popularizou foi o IIS, que até então, possibilitava apenas a publicação do serviço em cima do protocolo HTTP/HTTPS. A partir da versão 7.0 do IIS, ele já traz suporte à todos os protocolos, incluindo o TCP (WAS). Ao incorporar essa funcionalidade, isso o tornou muito mais do que um simples servidor para sites da web, dando a ele características de um servidor de aplicação, onde podemos hospedar componentes, que através do WCF, vamos publicar para os consumidores, estejam eles dentro do fora dos limites da empresa.

O IIS ganhou todas essas capacidades, mas as ferramentas que ajudam a monitorar esses serviços não evoluíram na mesma proporção. Por mais que eu consiga hospedar meus componentes no IIS, fazendo uso dos diversos protocolos, não há como, por exemplo, saber quais são os serviços WCF que eu tenho hospedado naquele servidor; quais são os endpoints publicados para um determinado serviço, entre várias outras informações úteis tanto para os desenvolvedores quanto para aqueles que administram o servidor.

Pensando nisso, a Microsoft criou uma ferramenta chamada de Windows Server AppFabric. Quando instalada, essa ferramenta adiciona ao sistema operacional, mais precisamente dentro do IIS, um conjunto de funcionalidades que permitem diagnosticar e gerenciar os serviços que rodam dentro de um determinado servidor. Além disso, o AppFabric ainda fornece recursos adicionais, como uma estrutura para caching distribuído, que pode ser utilizado para qualquer tipo de aplicação.

Entre os vários recursos oferecidos pelo AppFabric, temos a possibilidade de gerenciar e monitorar serviços WCF. Entre as funcionalidades exclusivas ao WCF, temos a capacidade de visualizar quais são os serviços que rodam naquele servidor, quais são os endpoints que cada serviço publica (incluindo aqueles de metadados). As imagens abaixo ilustram essas funcionalidades:

Ainda há uma opção chamada de Dashboard, que exibe uma visão sintética de quantas chamadas para serviços WCF ocorreram, quantas falharam, as exceções que foram disparadas, etc. Como trata-se de uma visão agrupada, essa tela possui vários links, que ao clicar, levará para uma segunda tela, com os filtros relacionados àquela opção clicada, fornecendo a visão analítica, com informações mais completas a respeito daquele serviço. A imagem abaixo ilustra este dashboard:

Ao instalar o AppFabric, um assistente é inicializado para configurá-lo. Basicamente, ele solicitará um local para armazenar as informações geradas por ele, para que mais tarde, possamos visualizá-las. Essas configurações exigem que você defina, através de uma espécie de provider, um banco de de dados SQL Server. É importante que você crie um banco exclusivo para isso, já que este assistente adicionará vários objetos dentro dele (tabelas, views, jobs, etc.), que são de uso exclusivo, e misturar com a base de dados da aplicação não é uma boa prática.

Além dessas informações macros, ainda temos um detalhamento delas. Quando utilizamos o tracing, uma série de informações são geradas, catalogando todos os estágios por onde a requisição está passando. No AppFabric temos uma seção chamada de Tracked Events, que nos permite visualizar justamente esse tipo de informação. Se analisarmos a imagem abaixo, podemos perceber os diversos eventos (estágios) do processamento, que ocorreram do lado do servidor, e também é possível visualizar a operação que foi efetivamente disparada.

Algumas poucas configurações do serviço estão disponíveis a partir do AppFabric, como é o caso de algumas cotas e throttling, mas como sabemos, as configurações do WCF são extensas e complexas, e neste caso, o uso da ferramenta WCF Service Configuration Editor performa melhor.

Para finalizar, um outro recurso bastante interessante, que também é fornecido com o AppFabric, é a possibilidade de exportar todas as configurações de um servidor, incluindo os serviços que nele rodam. Esse recurso utiliza em seus bastidores, uma ferramenta conhecida como Web Deployment Tool, e que permite configurar um outro servidor com as mesmas características deste servidor de origem, sem a necessidade de lembrar cada uma das configurações que você já realizou anteriormente.

Conclusão: O AppFabric não visa apenas serviços WCF. Como o Windows Workflow (WF) tem uma forte integração com o WCF, é possível gerenciarmos esses serviços a partir do AppFabric, com recursos para interagir com workflows de longa duração. Além disso, ainda há recursos extras que vão além do escopo definido para este artigo, mas que não são menos importantes. Depois de ter criado toda a infraestrutura necessária para suportar serviços WCF dentro do IIS, a Microsoft tem destinado grande parte de seus esforços no desenvolvimento desse tipo de ferramenta, que ajudam a monitorar e diagnosticar problemas, algo que muitas vezes são realizadas por outras pessoas, e que não são necessariamente desenvolvedores.

Muitas vezes, quando estamos desenvolvendo algum componente, geralmente colocamos todos os tipos (classes, estruturas, interfaces, etc.) dentro do mesmo assembly, sem nos preocuparmos com possíveis reutilizações de tipos que, futuramente, possam acontecer. Uma vez que temos esse componente pronto, o referenciamos em diversas aplicações, que farão uso dos tipos que o mesmo fornece.

Mais tarde, você começa a notar a necessidade de precisar fazer uso destes tipos em outros assemblies que você venha a criar. Sim, referenciar esse primeiro assembly, que contém todos os tipos, resolveria o problema, mas você pode estar referenciando assemblies com tipos que, na verdade, não deveriam estar a disposição de certas aplicações.

Refatorar isso, levando esses tipos para outros assemblies é uma tarefa relativamente fácil, pois basta você tirar de um e colocar noutro. O problema é manter a compatibilidade com as aplicações que já usam esses tipos que serão movidos. Imagine que você tenha um componente chamado Componente1.dll com uma classe chamada DalHelper. Uma aplicação Windows (App.exe) referencia esse assembly e faz uso da classe DalHelper. E como falmos acima, mais tarde você achou necessário mover a essa classe para um outro assembly (Componente2.dll), que ficará mais coerente e facilitará a reutilização.

Se você remover a classe DalHelper, as aplicações que dependem daquela classe dentro do assembly Componente1.dll, irão quebrar. É importante dizer que a idéia aqui é você fazer essa alteração (mover o(s) tipo(s) entre assemblies), sem precisar redistribuir/recompilar as aplicações que já utilizam o Componente1.dll. E para resolver isso, utilizamos o atributo TypeForwardedToAttribute (namespace System.Runtime.CompilerServices), disponível a partir do .NET Framework 2.0. Quando aplicado este atributo em um assembly, ele redirecionará a requisição de um determinado tipo para algum outro lugar, outro assembly. Para ilustrarmos, imagine a seguinte situação:

[Componente1.dll]
namespace Common
{
    public class DalHelper
    {
        public string Execute() { }
    }
}

[App.exe]
Common.DalHelper dal = new Common.DalHelper();
MessageBox.Show(dal.Execute());

O que vamos fazer agora é criar um outro assembly (Componente2.dll), e mover a classe DalHelper para dentro ele, removendo essa classe do Componente1.dll. O código abaixo exibe a estrutura do assembly recém criado.

[Componente2.dll]
namespace Common
{
    public class DalHelper
    {
        public string Execute() { }
    }
}

Isso não basta, e quebrará as referências que existem para essa classe. No Componente1.dll ainda precisamos, explicitamente, direcionar a requisição desta classe, utilizando o atributo TypeForwardedToAttribute. Lembre-se que devemos referenciar o Componente2.dll no Componente1.dll. O código abaixo mostra como utilizar esse atributo, e note que a classe DalHelper que está referenciada está, agora, no Componente2.dll.

[assembly: TypeForwardedTo(typeof(Common.DalHelper))]

Para aquelas aplicações que referenciam o DalHelper do Compenente1.dll, ao enviar o Componente1.dll e Componente2.dll, você pode simplesmente substituir o Componente1.dll que não quebrará o binding, já que quando a requisição para a classe DalHelper chegar à ele, ele sabe onde estará esse tipo, e encaminhará para ele, e como podemos perceber, as aplicações continuam confiando apenas no Componente1.dll.

Podemos perceber que isso ajuda imensamente para refatorar o código e, principalmente, manter a compatibilidade com as aplicações que já fazem uso desses tipos. Novas aplicações que precisarem da classe DalHelper, tudo o que elas precisam fazer é referenciar apenas o assembly Componente2.dll. Mais fácil do que isso é tentar prever essa reusabilidade, criando os tipos separadamente antes mesmo de fazer a distribuição inicial.

Junto com a primeira versão do Visual Studio .NET e do .NET Framework, temos a possibilidade de criarmos serviços Web, baseados em XML e utilizando a tecnologia ASP.NET Web Services (ASMX). Isso ainda continua disponível nas templates de projeto da versão mais atual do Visual Studio .NET, mas, para a criação de novos projetos, ou melhor, de novos serviços, o ideal é recorrer ao WCF – Windows Communication Foundation.

De qualquer forma, os ASP.NET Web Services já existem há algum tempo e há muitas aplicações que ainda o utilizam, e este artigo ajudará a entender melhor as diferenças entre ASMX e o WCF, desde a sua estrutura de projeto até detalhes relacionados à execução do mesmo. Cada uma das seções a seguir irá analisar e discutir essas mudanças, falando também sobre alguns detalhes importantes que, se não se atentar, poderá ter um comportamento “estranho” durante a execução.

Templates e Estrutura de Projeto

Quando você opta por criar um projeto ASMX, então você deve recorrer à template ASP.NET Web Service Application. Ao criar esse tipo de projeto, você poderá adicionar dentro dele arquivos com extensão *.asmx. Esse tipo de arquivo representará um serviço. Dentro desta classe, teremos os métodos que queremos publicar. Vale lembrar que o modificador de acesso do método (public, private, etc.) não tem validade. O que determinará a visibilidade do método é se ele estiver ou não decorado com o atributo WebMethodAttribute.

Além disso, a classe que representa o serviço pode, opcionalmente, herdar da classe WebService. Essa classe fornece acesso direto aos objetos ASP.NET, como Application e Session. Assim como nas aplicações ASP.NET tradicionais (UI), o arquivo ASMX apenas possui uma diretiva chamada @WebService, que define alguns atributos utilizados pelo compilador do ASP.NET. As classes necessárias para trabalhar com o ASMX estão contidas no Assembly System.Web.Services.dll e debaixo do namespace System.Web.Service.

Já com o WCF, trabalhamos de forma bem parecida. Para trabalhar com ele, é necessário que você, ao criar um novo projeto, escolha a template WCF Service Application. Neste projeto, adicionaremos arquivos com extensão *.svc, que representará o serviço. Esse tipo de arquivo também possui uma diretiva própria, chamada de @ServiceHost, que também leva informações ao compilador do ASP.NET. As classes necessárias para trabalhar com o WCF estão contidas no Assembly System.ServiceModel.dll e debaixo do namespace System.ServiceModel.

Apesar de existirem templates distintas para cada uma das tecnologias, isso não quer dizer que você está obrigado a criar um projeto específico para os teus serviços. Caso você já possua uma aplicação ASP.NET criada, é perfeitamente possível adicionar arquivos com extensão *.asmx ou *.svc neste projeto. Uma aplicação ASP.NET (UI) consegue coexistir com qualquer uma dessas tecnologias.

Contratos

O ASMX irá se basear nos métodos decorados com o atributo WebMethodAttribute para gerar o documento WSDL. Você deverá controlar a visibilidade dos teus métodos adicionando um removendo este atributo. Qualquer tipo complexo referenciado nos métodos, será automaticamente inserido na descrição do serviço sem nenhuma configuração extra.

Já o WCF trabalha de forma bem diferente. Ele utiliza interfaces para determinar os contratos que o serviço possui. Essas interfaces são aquelas tradicionais, que já utilizamos no nosso dia-à-dia, mas decorada com um atributo chamado ServiceContractAttribute. Dentro das interfaces teremos os métodos, e controlamos se eles serão ou não expostos através do atributo OperationContractAttribute.

Em relação a tipos complexos vinculados ao contrato do serviço, a exposição deles será determinado pela versão do WCF que está utilizando. Se estiver utilizando a versão 3.0, então você precisará decorar essas classes com o atributo DataContractAttribute, e para cada propriedade que desejar expor, decorá-la com o atributo DataMemberAttribute (opt-in). Com o Service Pack 1 para o .NET Framework 3.5, esses parâmetros são opcionais (opt-out), tornando-os POCOs. Mas há um detalhe: quando você decorar a classe com o atributo DataContractAttribute, então você deverá explicitamente determinar quais propriedades deseja disponibilizar, utilizando o atributo DataMemberAttribute.

Há um outro detalhe importante durante a execução das operações. Quando você utiliza ASMX, ele concatena o namespace com o nome da mensagem para determinar o Action. O WCF concatena o namespace, o nome do serviço e o nome da operação. Para manter compatibilidade com possível clientes ASMX, você deve manter a mesma fórmula, e para isso, pode recoorer a propriedade Action do atributo OperationContextAttribute.

Serialização/Deserialização

A serialização e deserializaão estão condicionadas ao serializador que cada tecnologia utiliza. O ASMX utiliza o XmlSerializer (System.Xml.Serialization) para transformar os objetos em XML e vice-versa. O XmlSerializer serializa todos os membros públicos (propriedades e campos), sem a necessidade de definir algum atributo. Você ainda pode controlar como essa serialização será realizada, utilizando vários atributos que existem debaixo deste mesmo namespace. Para maiores detalhes sobre o funcionamento do XmlSerializer e dos atributos, consulte este artigo.

O WCF, por outro lado, utiliza o serializador DataContractSerializer por padrão. Este serializador trabalha de forma semelhante ao XmlSerializer, com poucos diferenças. Entre essas diferenças temos o entendimento por parte do DataContractSerializer do atributo SerializableAttribute, para manter a compatibilidade com objetos que foram criados para serem utilizados pelo .NET Remoting. Além disso, uma outra diferença é a capacidade que este serializador tem de persitir também membros definidos como private e protected. Este serializador ainda gera um XML mais simplificado, melhorando a interoperabilidade entre as plataformas. Se desejar utilizar o XmlSerializer, então basta decorar o seu contrato com o atributo XmlSerializerFormatAttribute. Somente utilize o XmlSerializer para cenários onde você precisa ter controle total sob como o XML é gerado.

Ainda temos um terceiro serializador que é o NetDataContractSerializer. A diferença em relação ao DataContractSerializer é que ele armazena no XML gerado, informações a respeito do tipo (CLR), como versão, assembly e full name. Este serializador é rico nas informações referente ao tipo, ele compartilha tipos, ao contrário do DataContractSerializer, que compartilha contratos. Este ainda possui baixa interoperabilidade, e pode ser utilizado em cenários onde se tem .NET Remoting.

Protocolo/Hosting

O ASMX pode somente ser hospedado no IIS, utilizando o protocolo HTTP/HTTPS. Já o WCF tem uma arquitetura muito mais flexível e é independente do protocolo, ou seja, ele pode rodar em HTTP, HTTPS, TCP, MSMQ, etc. Isso quer dizer que ao construir um serviço através do WCF, você não deve mencionar e/ou confiar em nenhum momento que o mesmo será exposto através de um determinado protocolo, já que você não conseguirá garantir isso.

O WCF também pode utilizar o IIS como host. Mas além dele, podemos fazer uso de outras aplicações para expor um serviço, como um Windows Service, ou ainda, uma simples aplicação Windows/Console. Para mais detalhes sobre cada um dos tipos de host, consulte este artigo.

Extensibilidade

O ASMX permite você interceptar as requisições através de SOAP Extensions. Com elas, podemos acoplar um código customizado no processamento da mensagem, efetuando logs, tratando a autenticação/autorização, etc. A estrutura para a criação de um extensão é simples: basta herdar da classe SoapExtension e implementar o método ProcessMessage. Como parâmetro, este método traz uma propriedade chamada Stage, que podemos identificar o estágio do processamento da mensagem. Ela nos fornece quatro opções auto-explicativas: BeforeSerialize, AfterSerialize, BeforeDeserialize e AfterDeserialize. Para utilizá-la, basta criar um atributo que herda de SoapExtensionAttribute, e sobrescrever o método ExtensionType.

O WCF traz inúmeros pontos de extensibilidade tanto do lado do serviço quanto do cliente. Através destes pontos, podemos interceptar e inspecionar os parâmetros que estão sendo enviados, a escolha da operação a ser disparada, a criação da instância da classe que representa o serviço, a serialização e deserialização da mensagem (é o que a classe SoapExtension faz), entre outros. O WCF fornece vários tipos (interfaces e classes) para você customizar o que for necessário. Para entender detalhadamente sobre todos as possibilidades que temos, consulte este artigo.

Segurança

O ASMX pode confiar somente na segurança baseada no transporte, ou seja, ele somente será seguro se você expor o serviço através de HTTPS. Você somente conseguirá abrir mão do HTTPS se utilizar a segurança baseada na mensagem, que está disponível no ASMX através do WSE – Web Services Enhancements. Muitas vezes se utiliza um SoapHeader com usuário e senha. Isso somente terá alguma segurança se utilizar HTTPS ou segurança em nível de mensagem. Do contrário, qualquer um que intercepte a requisição, conseguirá extrair o conteúdo da mensagem e seus respectivos headers.

Como já era de se esperar, o WCF fornece ambos níveis de segurança nativamente. São configurações que você realiza (de forma imperativa ou declarativa), e que o serviço utilizará para efetuar a autenticação e autorização do cliente. Uma das grandes dificuldades que o pessoal encontra ao utilizar o WCF, é que se configurar o WCF para autenticar o cliente através de usuário e senha, ainda assim será necessário utilizar um certificado para garantir a segurança.

Configuração

O ASMX possibilita que algumas configurações sejam feitas de forma declarativa, ou seja, aquela que é realizada através do arquivo Web.config. Entre essas configurações, temos a possibilidade de definir as SoapExtesions, página de ajuda/WSDL customizada, os protocolos que podem ser utilizados para acessar o serviço (HttpSoap, HttpPost e HttpGet) e mais algumas outras.

No WCF, a seção de configurações são extremamente ricas. Grande parte de tudo que utilizamos no WCF pode ser configurado a partir do arquivo de configuração. Segurança, transações, know types, behaviors, bindings, endpoints, contratos, etc. O arquivo de configuração é tão rico que as vezes chega a ser complexo. A Microsoft melhorou isso no WCF 4.0, como já foi discutido neste artigo. Aqui não há muito o que se comparar, já que grande parte do que temos no WCF não existe nativamente no ASMX. Devido a isso, muitos desenvolvedores experientes na construção de serviço utilizando o ASMX, sofrem bastante quando passam a usar o WCF.

Compatibilidade com o ASP.NET

Dentro de métodos criados no ASMX, você pode tranquilamente acessar os objetos nativos do ASP.NET, como caching, Session, Application, Cookies, etc. Você pode utilizar esses repositórios para manter as informações de acordo com o contexto. Todas essas informações são disponibilizadas através da propriedade estática Current da classe HttpContext.

A configuração padrão do WCF não permite você acessar essas informações. Na verdade, isso não é uma boa prática. Se fizer uso dessas classes dentro do seu serviço, ele ficará dependente do protocolo HTTP. Se quiser expor o mesmo serviço através de TCP ou MSMQ, essas informações não terão nenhuma utilidade. De qualquer forma, se quiser manter a compatibilidade e continuar utilizando os mesmos recursos, então você deverá explicitamente habilitá-los. Para fazer isso, você deve decorar a classe que representa o serviço com o atributo AspNetCompatibilityRequirementsAttribute, definindo a propriedade RequirementsMode como Required.

Dependendo do tempo de vida e do escopo que deseja manter alguma informação, você pode recorrer a técnicas nativas do WCF, como o compartilhamento de estado, utilizando a interface IExtension<T>, como é abordado no final deste artigo.

Interoperabilidade

Há várias especificações que foram definidas por grandes players do mercado, que regem a estrutura do envelope SOAP para suportar alguma funcionalidade. Essas especificações são conhecidas como WS-* e estão divididas em várias categorias, sendo Messaging, Security, Reliable Messaging, Transaction, Metadata, entre outros. Cada uma das empresas utiliza essas especificações e as implementam em sua plataforma. Como todos seguem (teoricamente) as mesmas especificações, haverá interoperabilidade entre serviços construídos em plataformas diferentes.

O ASMX não possui nativamente suporte a elas. A Microsoft criou um Add-on para o Visual Studio .NET, chamado WSE – Web Services Enhancements, que atualmente está na versão 3.0. Ao instalá-lo, além de várias ferramentas que ele adiciona na IDE para auxiliar na configuração destes protocolos, adiciona o runtime necessário para fazer tudo isso funcionar. É importante dizer que o WCF consegue também interoperar com o WSE, já que ambos implementam os mesmos padrões.

Como esses padrões já foram implementados nativamente no WCF, não exige nenhum complemento. Todas as especificações são configuradas através do binding, podendo inclusive efetuar essa configuração através do arquivo Web.config. Antes de habilitar ou desabilitar essas funcionalidades, é importante que se tenha o devido conhecimento, para evitar qualquer problema ao até mesmo criar alguma vulnerabilidade. 

Ainda falando sobre interoperabilidade, a Microsoft se preocupou em manter os investimentos feitos com o ASMX. O WCF consegue facilmente conversar com serviços construídos em ASMX em ambos os lados, ou seja, você pode construir um serviço ASMX e consumí-lo com a infraestrutura do WCF, bem como pode construir um serviço escrito em WCF e consumí-lo com a infraestrutura do ASMX. Na verdade, quando você for criar um novo serviço, opte sempre pelo WCF. Você somente teria essa interoperabilidade entre essas tecnologias, quando desejar substituir o ASMX pelo WCF em serviços que já estão rodando, e com vários clientes dependendo do mesmo.

Internals

As requisições para arquivos *.asmx são direcionadas pelo IIS para o ISAPI do ASP.NET (aspnet_isapi.dll). Em um determinado momento, o ISAPI direciona a requisição do pedido para o código gerenciado. As requisições para estes arquivos tem como alvo um dos handlers WebServiceHandlerFactory ou ScriptHandlerFactory. A primeira delas, se baseando no arquivo requisitado, construirá dinamicamente a classe que representa o serviço. Já a classe ScriptHandlerFactory construirá o handler baseando-se em uma requisição REST/AJAX.

O WCF também utiliza o pipeline do ASP.NET, e quando a requisição é entregue pelo IIS para o ASP.NET, ele verifica se trata-se de uma requisição para um arquivo *.svc. Caso positivo, o handler responsável pelo processamento do pedido é o HttpHandler (System.ServiceModel.Activation). Internamente o WCF faz o processamento síncrono da operação, não liberando a thread do ASP.NET, que ficará bloqueada até a finalização da operação. Para entender melhor esse problema e também como melhorá-lo, você pode recorrer a este artigo.

Deployment

Assim como qualquer aplicativo .NET, basta mover os serviços para o IIS remoto e tudo já funciona. Obviamente que você deverá se certificar que você tenha a mesma versão do .NET Framework (isso inclui o Service Packs) instalada no servidor. É importante dizer que ambas tecnologias necessitam de um diretório virtual devidamente criado no IIS, com as permissões também configuradas. Apenas atente-se ao WCF, que tem um pequeno bug quando você opta pela pré-compilação do projeto.

Cliente

Dentro do Visual Studio .NET você tem duas opções para referenciar um serviço: “Add Web Reference” e “Add Service Reference”. Podemos dizer que com a primeira opção, você deve utilizar quando for referenciar um serviço ASMX em uma aplicação; já com a segunda opção, você deve utilizar quando você for referenciar um serviço WCF em uma aplicação. Quando fizer isso, a IDE criará o proxy utilizando a API da tecnologia correspondente.

Isso não quer dizer que você precisa seguir sempre esta regra. Você pode referenciar um serviço ASMX na opção “Add Service Reference”. Ao fazer isso, toda a estrutura do lado do cliente, será criada utilizando a API do WCF, ou seja, o proxy será baseado na classe ClientBase<TChannel> ao invés da SoapHttpClientProtocol, e toda a configuração do endpoint do serviço será colocada no arquivo Web.config. O WCF criou um binding chamado BasicHttpBinding para a interoperabilidade com o ASMX, que você pode utilizar para interagir com o serviço criado através do ASMX, sem maiores problemas.

Conclusão: Como vimos neste artigo, há vários detalhes que precisamos nos atentar na construção ou migração de um serviço escrito em ASMX para WCF. Para efeito de compatibilidade, algumas funcionalidades continuam trabalhando da mesma forma, enquanto para outras há um jeito diferente de fazer, e que na maioria das vezes, acaba sendo mais flexível. O artigo também não aborda detalhadamente cada uma das funcionalidades do WCF. Se desejar construir um serviço utilizando WCF, ou se quiser entender mais detalhadamente cada uma das funcionalidades abordadas aqui, pode consultar este artigo, que no final dele, há uma relação com os principais artigos que falam sobre essas funcionalidades.

Quando fazemos alguma mudança no diretório bin, App_Code ou no arquivo Global.asax, toda a aplicação ASP.NET será recompilada. Para sites pequenos, isso não tem muitos problemas, já que não há muitos arquivos/recursos a serem compilados. Já quando temos um site com várias páginas, esse processo pode se tornar muito lento, principalmente na primeira requisição, que é o onde a compilação irá ocorrer.

O SP1 do .NET Framework 3.5 inclui um novo atributo chamado optimizeCompilations, dentro do elemento compilation. Quando esse atributo estiver definido como False (configuração padrão), qualquer mudança provocará a recompilação total do site; já quando voce, explicitamente, definí-lo como True, somente os arquivos afetados pela mudança serão recompilados. Abaixo temos o exemplo da utilização deste novo atributo:

<compilation optimizeCompilations="true">

Uma das grandes vantagens que o ASP.NET trouxe em relação ao ASP Clássico é que as páginas não são mais interpretadas, mas sim compiladas. Quando compiladas, não me refiro apenas ao código VB.NET/C# que escrevemos no CodeBehind, mas sim a aplicação como um todo, inclusive (e principalmente) os markups (conteúdo HTML da página ASPX).

Quando utilizamos projetos do tipo Web Application Project, há uma característica do ASP.NET que é um retardo no processamento da primeira requisição. Isso se dá pelo fato de que o ASP.NET precisa fazer o parser das páginas ASPX e transformá-las em código MSIL e, se irmos mais a fundo, notaremos que essa versão compilada estará armazenada dentro do diretório Temporary ASP.NET Files, que é criado dentro em %windir%\Microsoft.NET\Framework\Versao quando instalamos o .NET Framework na máquina.

Podemos apagar todo o conteúdo deste diretório para um exemplo. Ao fazer o deploy de uma aplicação baseada em uma template do tipo Web Application Project, nada terá dentro do diretório Temporary ASP.NET Files até a primeira requisição para essa aplicação. Assim que, qualquer página for chamada, já iremos notar uma pasta com o mesmo nome do diretório virtual criada por esse processo. Isso é mostrado a partir da imagem abaixo:

Para o exemplo, temos uma página simples com um TextBox, um Label e um Button. Ao clicar no botão, o conteúdo digitado no TextBox (propriedade Text) é atributo a propriedade Text do Label.

Se abrirmos a DLL no Reflector, podemos comprovar a compilação em código MSIL, pois todo o markup foi totalmente compilado. Na verdade teremos dois Assemblies: um contendo classes (herdando diretamente da classe Page) que representam as páginas ASPX e, dentro delas, o código que colocamos no CodeBehind juntamente com a declaração dos controles; já dentro do segundo Assembly, teremos o código responsável pelo criação e montagem da hierarquia de controles da página e, por sua vez, essa classe herdará da sua correspondente que estará definida no Assembly anterior. A imagem abaixo ilustra esse processo:

O método FrameworkInitialize é chamado pelo próprio runtime do ASP.NET e, dentro dele, há a chamada para o método BuildControlTree que tem o importante papel de criar a hierarquia de controles dentro da respectiva página.

Os projetos do tipo Web Site já possuem (maiores informações aqui), ao fazer a publicação do mesmo, uma possibilidade para efetuar a pré-compilação. Até mesmo em tempo de desenvolvimento, esses tipos de projetos são pré-compilados. Já para os projetos do tipo Web Application Project, voce pode também adiantar esse processo, evitando que o primeiro usuário pague o preço pela demora. Para isso, basta voce recorrer ao utilitário chamado aspnet_compiler.exe que, em uma de suas opções, voce poderá especificar um diretório virtual, para que o mesmo crie a versão compilado do mesmo. A sintaxe para isso (utilizando a partir do prompt do Visual Studio .NET) é:

C:\>aspnet_compiler -v /WebAppTest

Algumas ferramentas que são parte integrante do SDK do .NET Framework não estão disponíveis quando instalamos a versão do .NET Framework 2.0 (Redistributable Package (x86)), como é o caso do mscorcfg.msc. Essa ferramenta permite configurarmos o Runtime Security Policy (um caspol.exe visual) e também gerenciarmos os Assemblies que estão contidos dentro do GAC.

Apesar de somente a versão 1.x do .NET Framework disponibilizar essa ferramenta quando instalamos o Redistributable Package, há uma forma de habilitarmos na máquina. É importante dizer que quando fazemos essa configuração em uma máquina de desenvolvimento, é permitido que voce crie um arquivo do tipo *.msi, contendo a configuração necessário (de Enterprise, Machine e User) para que voce possa embutir durante a instalação do software nas máquinas clientes que exigem essa configuração de segurança.