Introdução ao Windows Communication Foundation

Introdução

Com o crescimento da .NET framework, a tarefa de criar aplicações distribuídas ficou menos penosa. Seja pela facilidade de usar Web Services, pela performance e flexibilidade do .NET Remoting ou pela robustez do Enterprise Service (COM+), não esquecendo o MSMQ.

A Microsoft quando criou a .Net Framework 3.0, uma das novidades adicionadas foi o Windows Communication Foundation (WCF), que uniu as várias tecnologias de programação distribuídas na plataforma Microsoft, como por exemplo, Web Services Enhancements (WSE), ASP.NET Web Services, .NET Remoting, COM+ (Enterprise Services) e Message Queue (MSMQ), num único modelo, baseando-se na arquitetura orientada a serviços (SOA).

Com a chegada de uma nova versão da .NET Framework chega também uma nova versão do WCF, versão 4.

Nesta versão existem muitas novidades, mas neste artigo só vão ser abordadas quatro dessas novidades, como forma de estimular a curiosidade dos leitores, fornecendo assim uma plataforma de início de aprendizagem.

Todos os exemplos apresentados neste artigo são escritos usando C#.

O que é o WCF

O WCF é uma framework que nos possibilita construir e usar aplicações orientadas a serviços. Como principais características temos:

  • modelo de programação unificado;
  • suporte a SOA;
  • interoperabilidade e fiabilidade baseada em padrões de mercado;
  • segurança integrada;
  • arquitetura flexível e extensível;
  • maior flexibilidade e segurança em relação aos serviços ASP.NET Web Services.

Como principal desvantagem temos:

  • Fazer o design certo para os requisitos por vezes torna-se um pouco difícil.

Serviços em WCF

A estrutura de um serviço WCF não é muito complexa. Deve-se utilizar conceitos puros de programação .NET para a criação do contrato e da classe que representará o serviço. Além disso, o WCF também suporta a utilização de tipos complexos, como classes criadas para atender uma determinada necessidade.

Para definir um serviço em WCF pode-se usar a definição da Microsoft “Toda comunicação com um serviço WCF ocorre através de endpoints do serviço. Os endpoints fornecem aos clientes o acesso às funcionalidades oferecidas por um serviço WCF.”

Lendo atentamente a definição, verifica-se que para usar serviços WCF é necessário estes serem expostos via endpoints.

Cada serviço precisa de um endereço (Address) para que possa ser utilizado. Cada serviço possui também um contrato (Contract) que define o que o serviço vai fazer e uma vinculação (Binding) que define como se comunicar.

Em WCF o relacionamento entre o endereço (Address), o contrato (Contract) e a vinculação (Binding) é chamado de endpoint.

Address + Binding + Contract = Endpoint (o famoso ABC do WFC)

Hosting

Uma das grandes vantagens do WCF é a possibilidade de utilizar qualquer tipo de aplicação como host, não existem dependências de software, como o IIS (Internet Information Services), como acontece com os ASP.NET Web Services. O WCF pode expor serviços para serem acedidos através dos mais diversos tipos de protocolos, como por exemplo: HTTP, TCP, IPC e MSMQ.

Atualmente existem três alternativas de hosting: self-hosting, IIS e WPAS. Como há vários detalhes na criação e gestão do hosting, fica muito extenso publicar cada detalhe, vantagens e desvantagens que cada uma das técnicas possui. Na bibliografia, o leitor pode encontrar referências ao hosting.

O que há de novo no WCF 4

Tal como foi dito inicialmente, vão ser abordadas quatro das muitas novidades que podemos encontrar na versão 4 do WCF.

A primeira dessas novidades é a configuração simplificada.

Ao analisarmos o ficheiro de configuração usado da versão 3.5, verifica-se que por vezes o ficheiro de configuração consegue ser mais complicado que todo código que se escreve para criar e utilizar os serviços em WCF.

Exemplo de um ficheiro de configuração do WCF 3.x

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <system.serviceModel>
    <behaviors>
      <serviceBehaviors>
        <behavior name="CalculatorServiceBehavior">
          <serviceMetadata httpGetEnabled="True"/>
        </behavior>
      </serviceBehaviors>
    </behaviors>
    <services>
      <service name="Microsoft.Samples.GettingStarted.CalculatorService"
               behaviorConfiguration="CalculatorServiceBehavior">
        <endpoint address="" binding="basicHttpBinding" contract="ICalculator"/>
        <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/>
      </service>
    </services>
  </system.serviceModel>
</configuration>

Na versão 4, do WCF o ficheiro de configuração é simplificado. Não existe a necessidade de uma configuração muito extensa. Pode-se tirar vantagem de algumas das novas funcionalidades introduzidas pela Microsoft:

  • Configuração automática de bindings e behaviors;
  • Default endpoints;
  • Não é necessário usar a tag <service>.

Exemplo de um ficheiro de configuração do WCF 4

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <system.serviceModel>
    <behaviors>
      <serviceBehaviors>
        <behavior name="">
          <serviceMetadata httpGetEnabled="True"/>
        </behavior>
      </serviceBehaviors>
    </behaviors>
  </system.serviceModel>
</configuration>

Self hosting de um serviço WCF 4 com configuração simplificada

ServiceHost serviceHost = new ServiceHost(typeof(HelloService),
    new Uri("http://localhost:7777/Services/Hello"), 
    new Uri("net.tcp://localhost:7778/Services/Hello"));
serviceHost.Open();
 
Console.WriteLine("WCF Service is running.");
Console.WriteLine("Press <ENTER> to terminate service.");
Console.ReadLine();
 
serviceHost.Close();

Como o leitor pode ver na imagem abaixo o WCF cria automaticamente toda a configuração sem existir necessidade de existir um ficheiro de configuração.

Windows Communication Foundation: configuração automática

No WCF 4 existe a possibilidade de se definirem serviços de routing.

O uso desta funcionalidade permite que as aplicações cliente só tenham a necessidade de conhecer a existência de um único endpoint (os serviços de routing). Com base em tabelas de routing, pode-se instruir o WCF para reencaminhar os pedidos para os serviços correctos.

<client>
      <endpoint name="HelloService" 
       address="http://..." 
       binding="basicHttpBinding" contract="*" />
</client>
<routing>
      <filters>
        <filter name="MatchAllFilter" filterType="MatchAll" />
      </filters>      
      <filterTables>
        <filterTable name="mainRoutingTable">
		<add filterName="MatchAllFilter" 
                 endpointName="HelloService" />
	</filterTable>
      </routingTables>
</routing>

O WCF 4 implementa a funcionalidade de discovery.

Esta funcionalidade pode ser usada de duas maneiras diferentes:

  • Ad-Hoc;
  • Probing (Hello/Goodby).

O discovery funciona pois os endpoint implementam o protocolo UDP. Com o WCF 4 é bastante fácil implementar esta funcionalidade, para tal basta que:

  • Os serviços que queiram usar esta funcionalidade implementarem um discovery endpoint e permitirem o uso desta funcionalidade na sua configuração;
  • Os serviços que desejam enviar “heartbeats” permitam o uso desta funcionalidade na sua configuração;
  • Os clientes que queiram fazer “prob” dos serviços implementem a funcionalidade de discovery.

Exemplo de ficheiro de configuração do uso Ad-Hoc do discovery:

<system.serviceModel>
      <services>
        <service name="HelloService"
                 behaviorConfiguration="serviceBehavior">
          <host>
            <baseAddresses>
              <add baseAddress="http://localhost:7777/Services/Hello"/>
            </baseAddresses>
          </host>
          <endpoint binding="basicHttpBinding"
                    contract="IHelloService" />
          <endpoint name="udpDiscovery" kind="udpDiscoveryEndpoint"/>
        </service>
      </services>
      <behaviors>
        <serviceBehaviors>
          <behavior name="serviceBehavior">
            <serviceDiscovery />
          </behavior>
        </serviceBehaviors>        
      </behaviors>
</system.serviceModel> 

Exemplo de ficheiro de configuração do uso Probing (Hello/Goodby) do discovery:

<behaviors>
    <serviceBehaviors>
       <behavior name="serviceBehavior">
          <serviceDiscovery>
            <announcementEndpoints>
              <endpoint name="udpAnnouncement"
                 kind="udpAnnouncementEndpoint"/>
            </announcementEndpoints>
          </serviceDiscovery>
       </behavior>
    </serviceBehaviors>      
</behaviors> 

Exemplo do código de cliente do uso Probing (Hello/Goodby) do discovery:

DiscoveryClient discoveryClient = new DiscoveryClient("udpDiscoveryEndpoint");
FindCriteria findCriteria = new FindCriteria(typeof(IHelloService));
FindResponse findResponse = discoveryClient.Find(findCriteria);
 
if (findResponse.Endpoints.Count > 0)
{
    EndpointAddress address = findResponse.Endpoints[0].Address;
 
    ChannelFactory<IHelloServiceChannel> factory = 
      new ChannelFactory<IHelloServiceChannel>(
        new BasicHttpBinding(), address);
    IHelloServiceChannel client = new factory.CreateChannel();
 
    client.SayIt("Hello from WCF4!");
 
    client.Close();
    factory.Close();
} 

Conclusão

De certa forma, pode-se dizer que o WCF é até agora, o caminho certo, pois facilita o desenvolvimento e é totalmente desacopolado das regras de negócio que serão expostas pelos serviços.

A Microsoft quis com o WCF convergir todas as tecnologias de comunicação existentes numa única tecnologia que permitisse aos programadores terem as mesmas funcionalidades de antes, sem se preocuparem com as especificidades de cada uma das diferentes tecnologias. Como o leitor pode constatar, o WCF 4 ainda continua a ser WCF pois o ABC do WCF ainda está lá.

A funcionalidade de Discovery é interessante, especialmente para cenários empresariais. O Routing pode ser usado em arquiteturas mais complexas e como forma de abstrair do utilizador final alguma complexidade de configuração.

Não existem grandes mudanças, mas foi efetuado um grande investimento a nível da framework de suporte ao WCF para permitir aos utilizadores uma maior versatilidade e um desenvolvimento mais rápido e eficaz.

Bibliografia

O leitor pode encontrar mais informações em:

Publicado na edição 24 (PDF) da Revista PROGRAMAR.