Melhorias na configuração de serviços WCF

O schema de configuração do WCF é um pouco complexo, e mesmo utilizando o Microsoft Service Configuration Editor que, de forma gráfica, auxilia na configuração do serviço, há muito o que ser feito, já que existem várias propriedades, endpoints, bindings, behaviors, metadados, etc., para serem configurados. Apesar de complexo, depois que você entende o básico, até fica um pouco mais simples, mas sempre irá espantar os iniciantes da tecnologia, principalmente quando comparado com o ASP.NET Web Services (ASMX), que bastava criar o projeto, o serviço, compilar e referenciá-lo nos clientes.

Uma das grandes novidades no WCF 4.0, é justamente a configuração de serviços de forma muito mais simplificada. Na verdade, ele não obrigará mais fazer qualquer configuração. Basta criar o ServiceHost, informar o tipo da classe que representa o serviço e o endereço onde quer disponibilizar o serviço. Sendo assim, o código abaixo funcionará sem qualquer configuração no arquivo App.config ou Web.config:

using (ServiceHost host = new ServiceHost(typeof(ServicoDeUsuarios),
new Uri[]{ new Uri(“http://localhost:7373/srv”), new Uri(“net.tcp://localhost:7373/srv”) }))
{
host.Open();
Console.ReadLine();
}

Se executarmos o código acima, o serviço levantará sem problemas. Caso a classe que representa o serviço implementar 2 contratos diferentes, 2 endpoints para cada baseAddress. É importante dizer que o WCF torna as configurações não obrigatórias pelo cliente, mas isso não quer dizer que ele não precise mais delas. É justamente nesse momento que entra em cena o Protocol Mapping. O WCF 4.0 inclui uma nova seção no arquivo machine.config chamada <protocolMapping />, assim como vemos abaixo:

<protocolMapping>
<add scheme="http" binding="basicHttpBinding"/>
<add scheme="net.tcp" binding="netTcpBinding"/>
<add scheme="net.pipe" binding="netNamedPipeBinding"/>
<add scheme="net.msmq" binding="netMsmqBinding"/>
</protocolMapping>

Como podemos notar, temos uma coleção de schemes suportados pelo WCF, onde ele irá mapear cada scheme para um binding específico. Isso quer dizer que, quando você omitir as configurações na sua aplicação, ele irá extraí-las a partir deste mapeamento, baseando-se nos endereços (scheme) que você está utilizando para expor o serviço. Assim como grande parte das configurações do .NET, podemos também customizar esse mapeamento, tanto em nível de máquina (para que todos os serviços que rodem naquela máquina sigam aquela configuração), quanto em nível de serviço/aplicação. Para exemplificar a mudança, você poderia dizer que todos os serviços que rodarem através do protocolo HTTP, utilizassem o binding WSHttpBinding ao invés do BasicHttpBinding, utilizando segurança em nível de mensagem:

<protocolMapping>
<clear scheme="http" />
<add scheme="http" binding="wsHttpBinding" bindingConfiguration="messageSecurity" />
</protocolMapping>

<bindings>
<wsHttpBinding>
<binding name="messageSecurity">
<security mode="Message" />
</binding>
</wsHttpBinding>
</bindings>

No atributo binding do elemento add que vimos acima, definimos o nome do binding que será utilizado por aquele scheme e, opcionalmente, podemos definir também o atributo bindingConfiguration, apontando para uma seção dentro do arquivo de configuração, customizando as características básicas daquele binding. De forma semelhante trabalham os behaviors, ou seja, os behaviors sem o atributo name definido, serão automaticamente adicionados à coleção de behaviors de qualquer binding.

Ainda falando sobre as configurações, todos sabemos que os endpoints possuem três características, conhecidas também como ABC: Address, Binding e Contract (mais detalhes neste artigo). Além disso, ainda temos os behaviors que são configurações adicionais ao serviço, e que refletem diretamente na execução do mesmo. Como essas características são altamente configuráveis, talvez tenhamos a necessidade de disponibilizar esse “conjunto” para várias outras aplicações, precisando de uma “reutilização” da configuração destes endpoints.

Pensando nisso, a Microsoft também criou os Standard Endpoints. Assim como o Protocol Mapping, os Standard Endpoints são implementados através de uma seção no arquivo de configuração chamada <standardEndpoints />. Esta seção nada mais é do que uma coleção, onde cada elemento dentro dela é representado pelo sub-elmento chamado <standardEndpoint />, que receberá todas as configurações de um endpoint específico. E, finalmente, para relacionar essas configurações à um endpoint, utilizamos um novo atributo do elemento <endpoint />, chamado de kind, onde devemos informar o nome de um standard endpoint, assim como é mostrado abaixo:

<system.serviceModel>
<services>
<service name="ServicoDeUsuarios">
<endpoint kind="webHttpEndpoint" />
</service>
</services>
</system.serviceModel>

Quando utilizamos um projeto WCF Service ou até mesmo um projeto ASP.NET, é comum adicionarmos arquivos *.svc, onde cada um deles representa um serviço específico. Como já sabemos, estes arquivos possuem apenas uma única linha, que é a diretiva @ServiceHost, que define a classe do CodeBehind, o host, e servirá como alvo da requisição, ou seja, se ele não existir fisicamente, temos um erro 404, de recurso não encontrado.

Para facilitar a distribuição e gerenciamento, não há mais a necessidade deles. Ao invés disso, listamos os serviços diretamente no arquivo de configuração, neste caso, o Web.config, utilizando o já conhecido elemento serviceHostingEnvironment. Agora, dentro dele, temos um sub-elemento chamado serviceActivations. Ele é uma coleção, onde podemos elencar todos os serviços:

<system.serviceModel>
<serviceHostingEnvironment>
<serviceActivations>
<add relativeAddress="~/ServicoDeUsuarios.svc" service="ServicoDeUsuarios"/>
</serviceActivations>
</serviceHostingEnvironment>
</system.serviceModel>

É importante dizer que essas – novas – funcionalidades fazem parte do Beta 1. Talvez isso ainda mude até a versão final do produto. As novidades também não param por aí. O WCF 4.0, além do que foi visto aqui, ainda traz muitas melhorias em diversas outras áreas, que abordarei em futuros artigos.

Desenvolvimento - ASP. NET

Leia também