Ao desenvolver um serviço WCF, disponibilizamos um endpoint de acesso ao mesmo, permitindo que clientes o consumam diretamente. Independentemente da tarefa que ele venha a desempenhar, fica sob responsabilidade do mesmo, através de algum ponto de extensibilidade ou até mesmo em sua implementação, efetuar alguma customização ou reutilização em termos de infraestrutura, como segurança, caching, etc.

Esse tipo de customização visa centralizar alguns processos, facilitando a reutilização e gerenciamento dessas tarefas. Outro ponto importante no desenvolvimento de serviço, é a questão do balanceamento de carga. Ao publicar um serviço e muitos clientes passarem a consumí-lo, provavelmente o servidor onde ele ficar hospedado não comportará esse aumento. Neste caso, cria-se um segundo servidor para distribuir a execução do serviço, e através de algum software ou hardware, faz a configuração necessária para direcionar as requisições de acordo com a sua capacidade/disponibilidade.

Esses são alguns dos típicos cenários para o uso de roteamento de mensagens. A ideia do roteador é receber uma mensagem e encaminhá-la, podendo ou não fazer alguma verificação. Até a versão atual do WCF (3.5), é necessário uma grande quantidade de código para a criação deste roteador, enquanto na versão 4.0, que está por vir, já trará esse serviço nativamente, e é o que veremos no decorrer deste artigo.

Todos os tipos necessários para criarmos este roteador estão abaixo de um novo namespace, chamado System.ServiceModel.Routing (assembly System.ServiceModel.Routing.dll). Assim como a implementação manual que existia antes da versão 4.0, o roteador será disponibilizado como um serviço WCF qualquer, mas implementando alguns contratos (Interfaces) específicos, que determinarão como as mensagens serão encaminhadas para o respectivo serviço. A classe responsável por representar o serviço de roteamento é chamada de RoutingService, que por sua vez, implementa as seguintes Interfaces: ISimplexDatagramRouter, ISimplexSessionRouter, IRequestReplyRouter e IDuplexSessionRouter.

Cada uma dessas Interfaces descrevem as funcionalidades suportadas pelo serviço de roteamento. A primeira delas, ISimplexDatagramRouter, traz suporte ao processamento assíncrono de uma mensagem, suportando tipos “one-way”; já a Interface ISimplexSessionRouter, possibilita o processamento de mensagens que requerem sessões; a Interface IRequestReplyRouter possibilita ao serviço de roteamento, processar mensagens do tipo requisição-resposta, podendo ou não suportar sessões e, finalmente, a Interface IDuplexSessionRouter, que permite ao roteador processar mensagens “duplex” (aquelas que suportam callbacks).

Todas essas Interfaces estão implementadas na classe RoutingService, podendo ela tratar qualquer requisição, para os mais variados tipos de mensagens. A idéia de ter isso tudo isolado em Interfaces é que, eventualmente, você possa vir a criar um serviço de roteamento que suporte apenas um dos tipos.

A implementação e a forma como criamos e hospedamos um serviço não muda em nada. Continuamos criando os contratos, criação da classe que representa o serviço e o hosting do mesmo, com os respectivos endpoints. Em princípio, as aplicações que consomem o serviço também não mudam em nada. A única – grande – diferença é que entre essas duas partes haverá um intermediário, que como vimos acima, será o responsável por encaminhar as mensagens do cliente para o serviço e as mensagens do serviço para o cliente.

Uma vez que o serviço estiver construído, é necessário criarmos um serviço que servirá como roteador. Como vimos acima, a classe que representa isso é a RouterService, e podemos hospedá-la em qualquer hosting suportado pelo WCF. Já as Interfaces, que também foram comentadas acima, serão utilizadas para construir os endpoints do roteador, nos obrigando a escolher a Interface correta, em sincronia com o tipo de mensagem exposto pelo serviço efetivo.

Como o roteador será um serviço qualquer, também temos que configurar o(s) endpoint(s) e behavior(s). Como sabemos, uma das características do endpoint é o endereço, e neste caso, ele será utilizado pelos clientes para enviar a mensagem para qualquer um dos serviços que estão atrás do roteador, que por sua vez, se baseará em filtros para encaminhar a mensagem ao serviço correto.

Para o exemplo teremos dois serviços: um responsável pelo gerenciamento dos usuários e outro pelo gerenciamento de clientes, e ambos estarão acessíveis através do roteador. Um dos serviços (“ServicoDeUsuarios”) foi criado e disponibilizado utilizando o binding BasicHttpBinding, e as mensagens são do tipo requisição-resposta. Já o segundo serviço (“ServicoDeClientes”) possuirá apenas um método do tipo “one-way”, sendo disponibilizado através do binding WSHttpBinding. Dessa forma, o roteador será criado com dois endpoints distintos, onde o primeiro deles é configurado com o binding BasicHttpBinding e com o contrato IRequestReplyRouter, enquanto o segundo, utilizará o binding WSHttpBinding e o contrato definido como ISimplexDatagramRouter. Abaixo temos a configuração parcial do roteador:

<?xml version=”1.0″ encoding=”utf-8″ ?>
<configuration>
  <system.serviceModel>
    <services>
      <service name=”System.ServiceModel.Routing.RoutingService”
               behaviorConfiguration=”routerConfig”>
        <host>
          <baseAddresses>
            <add baseAddress=”http://localhost:9997/Router”/&gt;
          </baseAddresses>
        </host>
        <endpoint address=”rr”
                  binding=”basicHttpBinding”
                  contract=”System.ServiceModel.Routing.IRequestReplyRouter” />
        <endpoint address=”ow”
                  binding=”wsHttpBinding”
                  contract=”System.ServiceModel.Routing.ISimplexDatagramRouter” />
      </service>
    </services>
    <behaviors>
      <serviceBehaviors>
        <behavior name=”routerConfig”>
          <serviceMetadata httpGetEnabled=”true”/>
          <serviceDebug includeExceptionDetailInFaults=”true”/>
          <routing filterOnHeadersOnly=”false” 
                       routingTableName=”RouterMapping” />
        </behavior>
      </serviceBehaviors>
    </behaviors>
    <!– Outras Configurações –>
  </system.serviceModel>
</configuration>

Analisando essa primeira parte do arquivo de configuração do serviço de roteamento, podemos notar que o serviço que está sendo exposto é o RoutingService. Na sua definição vemos o baseAddress e dois endpoints. O endereço especificado no baseAddress, é o endereço que os clientes utilizarão para efetuar a comunicação com o roteador. Logo em seguida temos dois endpoints, onde o primeiro define o binding BasicHttpBinding e o contrato IRequestReplyRouter, ou seja, aceitará requisição através deste binding, suportando o tipo de mensagem requisição-resposta. Já o segundo, utiliza o binding WSHttpBinding com o contrato ISimplexDatagramRouter, ou seja, suporte à operações do tipo “one-way”.

Podemos reparar também que o serviço está referenciando um behavior chamado “routerConfig”. Dentro desta seção de configuração, além das opções comuns, como a disponibilidade de metadados, exceções, temos um novo behavior, chamado de RoutingBehavior (representando pelo elemento <routing />). Esse elemento possui apenas dois atributos: filterOnHeadersOnly e routingTableName. O primeiro atributo recebe um valor boleano indicando se poderemos ou não utilizar o corpo da mensagem para aplicar um determinado filtro (veremos mais sobre isso abaixo). O segundo atributo, define o nome de uma seção (que deve estar no mesmo arquivo de configuração), onde definiremos todos os filtros necessários para avaliar e, consequentemente, efetuar o encaminhamento da mensagem para o respectivo serviço.

Antes de falarmos efetivamente sobre os filtros, há uma seção muito importante e que é necessário efetuarmos a configuração da forma correta. Esta seção, delimitada pelo elemento <client />, muitas vezes é utilizada do lado de aplicações consumidoras, para especificar o endpoint que será utilizado por ela para efetuar a comunicação com o serviço. Neste contexto, esse elemento tem uma finalidade diferente, ou seja, de especificar o nome, endereço, binding e contrato dos serviços para os quais, eventualmente, o roteador encaminhará as mensagens. Abaixo podemos visualizar como fica a configuração dele:

<client>
  <endpoint name=”Servico1″
            address=”http://localhost:9998/usuarios&#8221;
            binding=”basicHttpBinding”
            contract=”*” />
  <endpoint name=”Servico2″
            address=”http://localhost:9999/clientes&#8221;
            binding=”wsHttpBinding”
            contract=”*” />
</client>

Na configurações destes endpoints, elencamos o endereço de cada serviço para qual o roteador enviará a mensagem, e a única e principal diferença em relação a uma configuração tradicional, é a presença o caracter “*” como contrato. Isso quer dizer que o serviço poderá receber a mensagem de qualquer contrato, obviamente, desde que passe pelos critérios que serão estabelecidos nos filtros.

A terceira e última parte do arquivo de configuração do roteador, consiste na definição dos filtros e como eles serão avaliados. No trecho de código abaixo, o elemento <routing /> agrupa dois sub-elementos que compõem o sistema de filtragem. O primeiro deles é a seção <filters />. Como o próprio nome diz, é uma coleção de filtros, onde cada filtro é represetado pelo elemento <filter />, que por sua vez, possui três atributos: name, filterType e filterData. O atributo name é autoexplicativo; já o atributo filterType especifica como será analisado o filtro. No exemplo abaixo, estou verificando a propriedade Action no header da mensagem. Finalmente, o atributo filterData é o valor a ser comparado com o qual foi extraído da mensagem.

O segundo sub-elemento é chamado de <routingTables />. Este elemento também possui uma coleção de entradas, onde ele relaciona um filtro à um endpoint cadastrado previamente (através do elemento <client />), por exemplo, se o “FiltroServico1” for avaliado como verdadeiro, a mensagem será encaminhada para o endpoint “Servico1”, e o mesmo acontecerá para o endpoint “Servico2” se o filtro “FiltroServico2” for atendido.

<routing>
  <filters>
    <filter name=”FiltroServico1″
            filterType=”Action”
            filterData=”http://tempuri.org/IUsuarios/Adicionar&#8221; />
    <filter name=”FiltroServico2″
            filterType=”Action”
            filterData=”http://tempuri.org/IClientes/Notificar&#8221; />
  </filters>
  <routingTables>
    <table name=”RouterMapping”>
      <entries>
        <add filterName=”FiltroServico1″ endpointName=”Servico1″ />
        <add filterName=”FiltroServico2″ endpointName=”Servico2″ />
      </entries>
    </table>
  </routingTables>
</routing>

Observação: Se existir dois endpoints do tipo “one-way” ou “duplex”, e que apontam para um mesmo filtro, que por sua vez, foi atendido, a mensagem será encaminhada para ambos endpoints.

Action é um dos filtros possíveis. Você pode utilizar o filtro do tipo XPath, para que através de uma query XPath, você consiga efetuar validações/consultas mais complexas, podendo inclusive analisar o corpo da mensagem. Com essa opção, você terá uma grande flexibilidade, já que conseguirá extrair mais informações e ter maior precisão na hora de avaliar/aplicar o filtro. Outro tipo de filtro é o MatchAll, que como o próprio nome já diz, acatará todas as mensagens. Basicamente, um filtro nada mais é do que uma classe que herda de MessageFilter, e sendo assim, você pode criar os teus próprios filtros, controlando como eles serão aplicados.

É importante dizer que os filtros são avaliados de acordo com a prioridade. Para determiná-la, podemos utilizar o atributo priority na coleção de filtros do elemento <routingTables />. Para o exemplo deste artigo, isso não faz muito sentido, já que temos dois filtros e cada um deles lidará com um tipo de mensagem específico, mas em um cenário onde você conseguir detectar a frequência de acesso, você pode determinar a prioridade para tirar melhor proveito em termos de performance, evitando que ele gaste tempo na avaliação dos outros filtros. Ao encontrar um filtro que atenda a requisição, a mensagem é encaminhada para o endpoint correspondente, caso contrário, uma exceção será disparada.

Outras Funcionalidades

Ainda há alguns outras funcionalidades que estão diretamente ligadas ao sistema de roteamento de mensagens. A primeira delas é a capacidade de aplicar filtros no corpo da mensagem. Como falado acima, tudo o que você precisa fazer é definir o atributo filterOnHeadersOnly para False e vasculhar o corpo da mensagem em busca dos parâmetros necessários para avaliar/aplicar o filtro, e para isso, você pode utilizar a seção <namespaceTable />. É através dela que conseguimos estabelecer a relação de namespaces com seus respectivos prefixos, para que assim, consiga encontrar e navegar pelos elementos que estão dentro da mensagem.

Como vimos acima, relacionamos um filtro à um determinado endpoint, e caso esse filtro seja atendido, a mensagem será encaminhada para o endpoint correspondente. Mas e se houver alguma falha de comunicação, como por exemplo, timeout? Para isso, a Microsoft também disponibilizou um elemento chamado <alternateEndpoints />. Através dele, podemos relacionar uma lista de endpoints, e caso a mensagem falhe, automaticamente o WCF tentará reencaminhar para o outro endpoint desta lista, até que algum deles processe com sucesso. Além deste elemento, tudo o que precisamos fazer é relacionar a lista de endpoints ao filtro, através do atributo alternateEndpoints, como vemos abaixo:

<routing>
  <!– Outras Configurações –>
  <routingTables>
    <table name=”RouterMapping”>
      <entries>
        <add filterName=”FiltroServico1″
             endpointName=”Servico1″
             alternateEndpoints=”alternateEndpoints” />
      </entries>
    </table>
  </routingTables>
  <alternateEndpoints>
    <list name=”alternateEndpoints”>
      <endpoints>
        <add endpointName=”Servico1Servidor2″/>
        <add endpointName=”Servico1Servidor3″/>
      </endpoints>
     </list>
  </alternateEndpoints>
</routing>

Para finalizar, outra funcionalidade que temos é a capacidade que o serviço de roteamento tem para trocar o binding que está sendo utilizado na comunicação entre o cliente e o roteador e entre o roteador e o cliente. Isso quer dizer que você pode definir que a comunicação com que o cliente terá com o roteador seja através do binding WSHttpBinding, enquanto a mensagem será encaminhada para o serviço através do binding NetTcpBinding.

Conclusão: Baseando-se nos problemas que vimos no início deste artigo, um roteador pode ajudar imensamente a resolvê-los e, felizmente, com este recurso disponível a partir da versão 4.0 do WCF, trará novas capacidades e funcionalidades para incorporarmos em nossas aplicações, tornando-as muitos mais poderosas, e resumindo alguns processos que antes eram complexos de serem realizados, em configurações extremamente simples.

RoteamentoDeMensagens.zip (38.73 kb)

Uma das possibilidades que temos ao construir um serviço WCF, é a capacidade de enviar mensagens conhecidas como one-way. Quando você tem operações que não retornam valores e, principalmente, o cliente não está interessado no sucesso ou falha da mesma, podemos recorrer à esta técnica. Ela permite que o proxy envie a mensagem ao seu destino, sem esperar pela sua execução. Há um bloqueio mínimo do lado do cliente, que é apenas necessário para que o proxy mande a mensagem e o serviço a enfileire. A partir daí, o cliente está livre para dar continuidade na execução do programa.

Dependendo do problema que ocorra, o retorno pode ser imediato, como acontece quando o respectivo endpoint não é encontrado, e dificilmente você notará esse bloqueio. Já em outros casos, quando a quantidade de informação enviada ao serviço é muito grande, isso também pode demorar a retornar, o que pode gerar uma má experiência (bloqueio) ao usuário. Outro problema que é muito comum, é quando você define o modelo de sincronização como Single e utiliza um binding que dá suporte à sessões, obrigando ao serviço (dispatcher) assegurar a entrega das mensagens de forma ordenada, impossibilitando que outra mensagem seja lida até que o processamento da mensagem atual seja completada.

Uma forma de contornar esse tipo de problema é trabalhar com mensagens assíncronas, como é mostrado aqui. Isso evitará a necessidade do cliente ficar aguardando até que a mensagem one-way seja efetivamente entregue ao serviço, mas como um ponto negativo, que é a saturação do ThreadPool, dependendo do volume de requisições que são realizadas. Outra alternativa é definir o gerenciamento de instância do serviço como PerCall e com modo de sincronização Multiple, onde cada requisição será atendida por uma instância diferente e podendo mais que uma thread enviar as mensagens.

Uma nova funcionalidade que estará presente no WCF 4.0, é a capacidade de criar serviços de forma declarativa. Quando trabalhamos com WCF, tudo o que devemos fazer é criar uma Interface que representará o contrato, implementamos ela em uma classe que representará o serviço e, finalmente, criamos o código necessário para servir como hosting para o serviço.

A criação do hosting conseguimos fazer totalmente de forma declarativa, enquanto as outras duas, somente podemos utilizar o modelo imperativo (via C# ou VB.NET) para criá-los. A proposta da Microsoft é permitir que a criação de um serviço WCF seja feita totalmente (definição e implementação) de forma declarativa, ou seja, utilizando o XAML. Ainda há o que chamamos de “projeção de contratos”, que permitirá separar a definição da representação (mensagens). Com isso, vamos ter apenas uma única definição, mas podendo ser representada de diferentes formas (SOAP, REST, etc.). Para mais detalhes sobre serviços declarativos, você pode consultar a documentação oficial desta funcionalidade.

Uma das grandes desilusões ao utilizar o WCF, é não conseguir utilizar tipos de dados genéricos nos serviços. Generics são tipos de dados exclusivos do .NET Framework, e utilizá-los viola os princípios da orientação a serviços, já que podem existir linguagens que não suportam essa funcionalidade. É importante dizer que isso não é uma limitação do WCF, mas sim do WSDL, que é o documento utilizado para expor os metadados para os consumidores.

O Visual Studio .NET/compilador não vão proibí-lo de utilizá-los nos contratos. O problema será na exposição das informações (via WSDL) para o cliente e, consequentemente, o proxy gerado possuirá tipos “estranhos”. Por exemplo, se uma operação do contrato retornar ou receber um tipo genérico como Teste<int>, ao gerar o proxy, ele irá criar um tipo (classe) chamado TesteOfInt, substituindo os parâmetros genéricos do mesmo, pelo tipo especificado na operação. Isso pode piorar um pouco se o parâmetro genérico informado for uma classe, como por exemplo Teste<OutraClasse>, resultando no seguinte tipo do lado do cliente: TesteOfOutraClasseKdjwuy4p, ou seja, acrescentando uma informação randômica para evitar eventuais conflitos com outros tipos no mesmo contrato.

Felizmente você pode sobrescrever esse comportamento, definindo a propriedade Name da atributo DataContractAttribute. Nela você pode especificar o formato do nome que deseja expor no WSDL. Se notarmos no primeiro exemplo abaixo, o parâmetro {0} será substituído pelo tipo genérico especificado. Caso a classe Teste suportasse mais do que um parâmetro genérico, então você pode também especificá-los para compor o nome, assim como mostrado no segundo exemplo.

[DataContract(Name = “TesteCom{0}”)]
public class Teste<T> { }

[DataContract(Name = “TesteComTipo{0}EComChave{1}”)]
public class Teste<T, D> { }

Um outro ponto importante é com relação as coleções. Elas também são características da plataforma, e não devem ser expostas além do serviço. Ao utilizar coleções que implementam direta ou indiretamente as Interfaces IEnumerable<T>, ICollection<T> ou IList<T>, o WCF automaticamente irá convertê-las em um array do tipo especificado no parâmetro genérico (<T>), facilitando a interoperabilidade com outras plataformas.

Ainda falando em coleções, ao criar uma coleção customizada, você poderá fazer uso do atributo CollectionDataContractAttribute, permitindo customizar o nome do tipo da coleção (através da propriedade Name) a ser colocado no WSDL e, consequentemente, criado no cliente (trabalhando da mesma forma que a propriedade Name do atributo DataContractAttribute). Ao utilizar este atributo, ainda temos a garantia de que o WCF verificará a existência do método Add durante a carga do serviço, e não existindo, uma exceção do tipo InvalidDataContractException será lançada. Este método se faz necessário para remontar a coleção durante a deserialização da mensagem.

Como dito acima, as coleções são características da plataforma, e não devem propagar além dos limites do serviço. Mas em algumas situações, isso pode ser interessante. Quando você está compartilhando tipos entre o cliente e o serviço (exige .NET/WCF presente dos dois lados), você pode optar por criar o proxy respeitando e preservando essas coleções. Para que isso seja possível, basta você utilizar a opções /reference e /collectionType do utilitário svcutil.exe. A primeira opção determina o Assembly (reference) onde está a coleção, enquanto a segunda opção determina qual é a coleção. É importante dizer que este recurso também está disponível quando a criação do proxy é feita pela IDE do Visual Studio .NET.

Há algum tempo eu escrevi um artigo que fala sobre a possibilidade que temos para efetuar callbacks do serviço para o cliente que, em outras palavras, significa o serviço se comunicando com o cliente, permitindo ao mesmo notificar sobre o término de alguma tarefa, simular eventos, etc. Esse tipo de comunicação é também referida/conhecida com “duplex”.

Quando queremos esta funcionalidade e o serviço está exposto via TCP, através do binding NetTcpBinding, o WCF utiliza o mesmo canal para efetuar a comunicação entre o serviço e o cliente. Já quando o serviço for exposto através do protocolo HTTP, utilizamos o binding WSDualHttpBinding, responsável por possibilitar callbacks através do HTTP. Como o HTTP é um protocolo unidirecional, esse binding é responsável por também criar um endpoint do lado do cliente (diferente do usado para envio das mensagens), que receberá os callbacks que o serviço enviará.

Enquanto você trabalha no desenvolvimento do serviço/cliente, que na maioria das vezes é na máquina local, tudo funciona perfeitamente. Alguns problemas começam a aparecer quando você faz a distribuição dos aplicativos que consomem o serviço via HTTP. O primeiro deles é quando você instala o serviço em uma máquina com Windows XP e que tenha o IIS instalado (que não tem o HTTP.sys). A ausência do HTTP.sys não permite ao Windows compartilhar uma mesma porta entre múltiplas aplicações. Por padrão, o WSDualHttpBinding irá criar e configurar o endpoint com a porta 80, ou seja, a mesma utilizada pelo IIS, resultando em uma exceção do tipo AddressAlreadyInUseException. Você pode facilmente resolver isso removendo ou parando o serviço do IIS ou especificando uma outra porta. Para utilizar uma porta diferente, basta utilizar o atributo clientBaseAddress (elemento binding) na configuração do binding do lado do cliente.

Já o segundo problema está relacionado a solução do primeiro. Se você altera a porta padrão, muito provavelmente ela estará barrada no firewall do Windows. Isso quer dizer que se o firewall estiver ativo (que é o recomendado), o serviço não conseguirá enviar o callback para o cliente. Para resolver isso, você pode adicionar uma exceção no firewall do Windows. Você pode fazer isso diretamente através do gerenciador do firewall no Painel de Controle, ou até mesmo via programação.

Há algum tempo eu falei aqui sobre o WCF REST Starter Kit. A finalidade deste kit foi disponibilizar algumas novas funcionalidades para o desenvolvimento de serviços em HTTP, permitindo que a comunidade avaliasse, e baseando-se no feedback, a Microsoft está incorporando algumas dessas funcionalidades nativamente no WCF 4.0. Com isso, teremos suporte ao caching do ASP.NET, interceptors, novas formas para reportar erros no browser, etc., sem a necessidade de referenciar assemblies extras.

Quando utilizamos a template de projeto WCF Service Library, todas as configurações do serviço estão no arquivo App.config. Ao rodar a aplicação, o utilitário conhecido como WCF Test Client é executado, fazendo tudo o que é necessário para efetuar o hosting do serviço recém criado. Como não temos acesso a criação e o gerenciamento do host (representado pela classe ServiceHost), não poderemos configurá-lo de forma imperativa.

Como grande parte das configurações do WCF pode ser realizada através do arquivo de configuração, podemos utilitizá-lo para adicionar behaviors existentes no WCF, mudar alguma característica do binding, etc. O problema aparece quando precisamos adicionar um behavior customizado. Neste caso, além da classe que o representa, ainda é necessário a criação de uma segunda classe, que definirá o respectivo behavior no arquivo de configuração.

Para isso, é necessário criar uma classe e herdar de BehaviorExtensionElement, implementando os membros BehaviorType e CreateBehavior, assim como mostro no final deste artigo. Depois desta classe criada, precisamos ainda registrar esta extensão no arquivo de configuração, antes de efetivamente fazer o uso dela. Para isso, utilizamos a seção behaviorExtensions, como mostrado abaixo:

<extensions>
  <behaviorExtensions>
    <add name=”errorService”
         type=”Host.ErrorServiceElement, Host, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null”/>
  </behaviorExtensions>
</extensions>

E, finalmente, utilizá-la:

<behaviors>
  <serviceBehaviors>
    <behavior name=”BehaviorConfig”>
      <errorService />
      <serviceMetadata httpGetEnabled=”True”/>
      <serviceDebug includeExceptionDetailInFaults=”False” />
    </behavior>
  </serviceBehaviors>
</behaviors>

Até a versão 2.0 do Silverlight, o binding BasicHttpBinding apenas codificava a mensagem em formato texto, enviando-a através de HTTP. Como já sabemos, esse binding com esta codificação pode ser facilmente interoperável com serviços baseados no protocolo SOAP 1.1, como é o caso dos ASP.NET Web Services (ASMX). Esse tipo de codificação também pode ser facilmente interceptado por qualquer ferramenta de monitoramento de requisições HTTP, como é o caso do Fiddler.

Uma inovação que está presente a partir da versão 3.0 do Silverlight, é o suporte a codificação binária do envelope SOAP que é transmitido entre o serviço e o cliente, e vice-versa. Apesar de, em alguns casos, diminuir o tamanho da mensagem trafegada, a grande finalidade deste tipo de codificação é ter uma velocidade maior entre a transferência das informações. Com esse benefício, esse tipo de codificação passa a ser o padrão quando criar um projeto baseando-se na template Silverlight-enabled WCF Service.

Para que isso funcione, temos um novo binding element chamado BinaryMessageEncodingBindingElement. Com a criação de um binding customizado, já podemos fazer a utilização do mesmo e, consequentemente, de seus benefícios. O código abaixo ilustra a sua utilização, configurando o binding através do arquivo de configuração:

<bindings>
   <customBinding>
      <binding name=”binaryHttpBinding”>
         <binaryMessageEncoding />
         <httpTransport />
      </binding>
   </customBinding>
</bindings>

Apenas fique atento para utilizar o mesmo codificador dos dois lados. Caso isso não aconteça, não será possível fazer a comunicação. Para finalizar, é importante dizer que ao utilizar esse codificador, não iremos mais conseguir monitorar as requisições e analisar o seu conteúdo. Enquanto estiver em ambiente de desenvolvimento, talvez seja melhor manter a codificação baseada em formato texto, para conseguir depurar facilmente eventuais problemas que venham a acontecer.