Como sabemos, aplicações Silverlight rodam no cliente, dentro do seu navegador, ou mais recentemente, também temos a possibilidade de desacoplar a aplicação do mesmo, dando a impressão ao usuário de que é uma aplicação que roda localmente. O fato da aplicação rodar “desconectada” do servidor, havia uma grande necessidade de expor funcionalidades e dados para ela, e o WCF eleito como a “ponte” entre os dois lados, para estabelecer a comunicação, permitindo com que as aplicações cheguem até a sua origem e executem alguma tarefa ou extraiam dados necessários para que elas possam trabalhar.

Desde as primeiras versões do Silverlight que temos APIs dentro dele para comunicação HTTP e a API do WCF (System.ServiceModel.dll), para abstrair toda a complexidade de consumir um serviço SOAP. Essas APIs recorrem aos recursos expostos pelo navegador, estando assim condicionadas as suas limitações. Apesar de algumas dessas limitações, como era o caso da propagação de erros do serviço para o cliente, gerenciamento de cookies e chamada concorrente para serviços, essas APIs funcionavam razoavelmente bem. Mas a questão é que os serviços tem evoluído cada vez mais, obrigando a Microsoft a melhorar o modelo de comunicação dentro do Silverlight.

O que tínhamos até a versão 2.0 é o que chamamos de Browser Http Stack. Com ela, conseguíamos efetuar comunicações com serviços, mas com algumas limitações, pois estávamos condicionados aos recursos que o navegador oferecia, afinal, ela é apenas um wrapper para ele. Além de não conseguir interpretar um erro SOAP corretamente, uma outra limitação é a possibilidade de executar serviços além dos tradicionais verbos POST e GET do protocolo HTTP. Como serviços REST estão cada vez mais populares, existe uma grande necessidade de suportar mais do que estes dois verbos.

Para resolver estes tipos de problemas, e tentar acomodar novas funcionalidades, a Microsoft incluiu na versão 3.0 do Silverlight, uma nova forma de comunicação, chamada de Client Http Stack. A palavra “Client” é porque agora a comunicação utiliza os recursos fornecidos pelo sistema operacional, burlando as limitações impostas pelo navegador. Além de resolver os problemas que vimos acima, ela permite interpretar todos os headers, melhor forma de manipular cookies, códigos de status das respostas, algumas melhorias na parte de autenticação, etc.

Uma das preocupações da Microsoft foi em manter a modelo de utilização das classes que você já utiliza para efetuar a comunicação com algum desses serviços, podendo alterar entre uma das stacks, sem precisar mudar algo no código que faz o consumo do serviço.

Por padrão o Silverlight continua utilizando o modelo tradicional (Browser Http Stack), e se você quiser utilizar o Client Http Stack, terá que explicitamente dizer isso à ele. Para isso, devemos utilizar o método estático RegisterPrefix da classe WebRequest (namespace System.Net). O primeiro parâmetro consiste na URI (http://www.site.com.br) ou apenas o prefixo (http ou https) para onde quer se comunicar. Já o segundo parâmetro indica qual dos modelos utilizar (Browser ou Client). Esse método retorna um valor boleano, indicando se o registro foi ou não realizado com sucesso. O código abaixo ilustra como podemos proceder para efetuarmos essa configuração:

WebRequest.RegisterPrefix(“http://”, WebRequestCreator.ClientHttp);

Caso queira retornar a configuração padrão, então poderá utilizar a propriedade estática BrowserHttp, também exposta pela classe WebRequestCreator, assim como é exibida abaixo:

WebRequest.RegisterPrefix(“http://”, WebRequestCreator.BrowserHttp);