Em 2006 a Microsoft lançou a versão 3.0 do .NET Framework, que nada mais era do que “grandes blocos” que foram adicionados ao 2.0. Entre esses grandes blocos, temos o WCF. Como todo mundo sabe, ele é o novo pilar para comunicação dentro da plataforma .NET. A estrutura deste framework, facilitou a entrada de novos produtos, também criados pela Microsoft, para atender cenários específicos.

Isso acaba facilitando bastante, já que grande parte da complexidade do WCF acaba sendo abstraída do desenvolvedor. Depois do .NET Framework 3.0, veio a versão 3.5, que incorporou novas funcionalidades, e mais tarde, no PDC 2009, a Microsoft publicou novos serviços, construídos em cima do WCF. Atualmente temos os seguintes tipos de serviços disponíveis:

• Serviços SOAP: É o WCF em si. Possibilita a construção de serviços baseando-se em padrões de mercado, que tentam manter a interoperabilidade entre várias plataformas ou com outras tecnologias, como COM+, MSMQ, .NET Remoting, etc. Esses padrões regem transações, segurança, entre outras funcionalidades. A idéia aqui é permitir a construção de serviços orientado à operações que você precisa expor ao mundo, através dos mais diversos protocolos.
• Serviços WebHttp: A partir da versão 3.5, a Microsoft trouxe a capacidade de construir serviços REST dentro do WCF. Usando métodos como POST, GET, PUT, etc., em conjunto URLs (onde você pode formatar do jeito que desejar), temos a flexibilidade de expor operações para serem consumidas diretamente, sem envolver essas requisições em envolopes SOAP, facilitando assim o consumo por aplicações AJAX, por exemplo.
• Serviços para Dados: Semelhante a anterior, mas a idéia é expor via REST as informações contidas em um banco de dados. Inicialmente levava o nome de ADO.NET Data Services, mas depois do PDC foi renomeado para WCF Data Services.
• Serviços de Workflow: Basicamente, a ideia é permitir que um workflow (construído pelo Windows Workflow Foundation (WF)) possa ser consumido e coordenado por serviços WCF. Situações onde você tem operações que possuem uma longa duração, a necessidade de manter o estado entre chamadas, esse tipo de serviço poderá ajudar.
• Serviços RIA: WCF RIA Services estará disponível juntamente com o Silverlight 4.0, e simplificará a forma como você escreverá uma aplicação N-tier, onde o cliente será o próprio Silverlight.

Vimos nos artigos anteriores como criar, hospedar e consumir serviços com o WCF. Todas as tarefas que esses serviços disponibilizavam tinham uma duração curta, ou seja, o processo completo se resumia apenas na chamada de uma única operação. Mas é muito comum, em aplicações distribuídas, termos processos que podem durar muito mais tempo para completar toda a tarefa. Neste caso, pode ser complicado manter ativa a instância do serviço ou do cliente por todo esse tempo.

A Microsoft introduziu na versão 3.5 do WCF uma funcionalidade chamada de Durable Services. Como o próprio nome diz, ele possibilita a criação de serviços que podem ser persistidos, sobrevivendo a eventuais reciclagens do host que o hospeda e também de reinicializações do cliente. Com este artigo vamos analisar como devemos proceder para incorporar esta funcionalidade em nossos serviços.

Independentemente do modelo de gerenciamento de instância que utilize, a classe que representa o serviço tem um tempo de vida determinado, e se por algum motivo a aplicação que hospeda o mesmo for reinicializada, todo o estado do objeto será perdido. Isso ocorre porque todo esse estado, que cada objeto que representa o serviço mantém, é armazenado em memória, ou seja, é volátil e não conseguirá sobreviver durante possíveis reinicializações, e pode comprometer a regra de negócio, caso você dependa desta informação.

Com os Durable Services, podemos persistir as informações em algum repositório ao invés de utilizar a memória. Isso irá garantir que as informações sejam mantidas, mesmo que o processo demore dias para ser concluído. Mesmo que a sessão com o cliente seja destruída, você conseguirá restaurar o estado mais tarde. A Microsoft já disponibilizou um provider para armazenar as informações no banco de dados SQL Server, mas nada impede de você customizar, optando pela criação de um provider que armazene as informações em arquivos XML.

Para guiar os exemplos, teremos o seguinte cenário: um serviço que irá fornecer as operações necessárias de um comércio eletrônico, como por exemplo a criação de um carrinho, a inserção de novos itens, recuperação dos itens selecionados e a finalização da compra. A idéia é que os itens selecionados pelo usuário, sejam mantidos além das sessões e também do desligamento da aplicação cliente e, eventualmente, do serviço.

Os tipos que usaremos estão contidos no Assembly System.WorkflowServices.dll. Antes de efetivamente começarmos a ver os tipos disponibilizados por esse Assembly, precisamos preparar a base de dados para que ela consiga acomodar as informações. Felizmente já temos todo o script pronto, apenas será necessário executá-lo. Para isso, basta ir até o seguinte endereço: %windir%Microsoft.NetFrameworkv3.5SQLEN. Lá temos quatro arquivos, sendo dois para a criação e dois para a exclusão. No nosso caso, devemos executar os seguintes arquivos: SqlPersistenceProviderSchema.sql e SqlPersistenceProviderLogic.sql, nesta mesma ordem. O primeiro é responsável por criar a tabela InstanceData, enquanto o segundo cria as Stored Procedures com toda a lógica de inserção, exclusão e carregamento das instâncias.

Podemos serializar o estado do serviço de forma binária (o padrão) ou através de Xml, e para suportar isso, temos duas colunas na tabela InstanceData, chamadas de “instance” e “instanceXml”. A primeira é utilizada quando o estado é serializado em formato binário, enquanto a segunda apenas será utilizada quando o conteúdo for persistido em Xml. Além dessas duas colunas, ainda temos a coluna “id”, que terá o seu valor propagado do serviço para o cliente e sendo devolvido do cliente para o serviço. Esse ID representa a instância (estado) do serviço que foi armazenada. Falaremos detalhadamente sobre ela mais tarde, ainda neste artigo.

Implementação

O contrato do serviço não sofrerá qualquer alteração. Você deve continuar decorando a interface com o atributo ServiceContractAttribute e as operações que serão expostas, com o atributo ServiceOperationAttribute. As mudanças começam a aparecer na classe que representará o serviço. O primeiro passo para a criação de um serviço durável, é decorar a classe que representa o serviço com o atributo DurableServiceAttribute. Durante o carregamento do serviço, este atributo irá garantir que o modo de gerenciamento de concorrência não esteja definido como Multiple e que o modo de gerenciamento de instância deve ser PerSession. É importante dizer que o estado deve ser de uso exclusivo de uma sessão. Se desejar que o estado seja compartilhado com todos os clientes (sessões), então você deve optar pelo modo Multiple de gerenciamento de instância. E mais um detalhe importante, temos que aplicar o atributo SerializableAttribute, assim como todas as classes que desejamos serializar.

Cada operação que irá compor o serviço durável, deverá ser decorada com o atributo DurableOperationAttribute. Esse atributo indica ao runtime que ao completar cada operação, o estado do serviço deverá ser persistido fisicamente. Essa classe possui duas propriedades, que por padrão são sempre False: CanCreateInstance e CompletesInstance. A primeira delas indica se uma nova instância do serviço deve ser criada ao executar a respectiva operação. Já a segunda propriedade, indica se a instância será removida da memória e excluída do repositório quando a operação for executada. A classe abaixo exibe como configurar esses atributos, com a implementação omitida para poupar espaço:

[Serializable]
[DurableService]
public class ServicoDeComercioEletronico : IComercioEletronio
{
    private List<ItemDaCompra> _produtos;
    private string _usuario;

    [DurableOperation(CanCreateInstance = true)]
    public void CriarCarrinho(string usuario) { }

    [DurableOperation]
    public void AdicionarItem(ItemDaCompra item) { }

    [DurableOperation]
    public ItemDaCompra[] RecuperarItensDaCompra() { }

    [DurableOperation(CompletesInstance = true)]
    public void FinalizarCompra() { }
}

Não há nenhuma mudança drástica na implementação do serviço, apenas temos que nos atentar ao estado dos membros internos, que serão mantidos entre as chamadas (lembre-se de que essa persistência sobreviverá mesmo após o host ou o cliente ser encerrado).

Mudanças mais significativas são realizadas para expor o serviço. Isso se deve ao fato da necessidade de propagar o ID que representa o estado o serviço. O ID em questão é o mesmo que é gerado durante a inserção do registro na tabela acima mencionada. Quando o runtime encontra uma operação que possui o atributo DurableOperationAttribute e com a propriedade CanCreateInstance definida como True, ele irá criar um registro na tabela InstanceData, capturar o ID gerado e devolver para o cliente. Todas as operações subsequentes devem embutir esse ID.

Antes da operação ser efetivamente executada, o runtime irá extrair a instância da base de dados, abastecer os membros privados previamente serializados, e depois disso irá executar a operação; ao retornar, o runtime devolve os dados para a base de dados, com as informações atualizadas. Finalmente, quando o runtime encontra uma operação com o atributo DurableOperationAttribute e com a propriedade CompletesInstance definida como True, o respectivo registro que representa o estado do serviço é excluído da base de dados.

Como podemos perceber, todo o processo acontece utilizando o ID gerado durante a primeira requisição, e a necessidade de mantê-lo durante as requisições futuras se faz necessário, caso queira manter o estado. Visando essa manutenção do ID, a Microsoft criou três novos bindings: NetTcpContextBinding, BasicHttpContextBinding e WSHttpContextBinding. Cada um deles herda diretamente dos bindings tradicionais (NetTcpBinding, BasicHttpBinding e WSHttpBinding), apenas trazendo o suporte necessário para gerenciar o ID de persistência.

Cada um destes bindings sobrescrevem o método CreateBindingElements, criando uma instância da classe ContextBindingElement. Este elemento é responsável por gerenciar como o ID será propagado entre o serviço e o cliente (ou vice-versa). Em seu construtor, recebe uma das seguintes opções expostas pelo enumerador ContextExchangeMechanism:

    – ContextSoapHeader: O ID será enviado através de um header na mensagem SOAP. É o valor padrão.
    – HttpCookie: O ID será definido em um cookie.

Cada um dos bindings utiliza um mecanismo diferente. O binding NetTcpContextBinding utiliza a primeira opção, mesmo porque não é possível utilizar cookies através de TCP. Já o BasicHttpContextBinding utiliza cookies para manter o ID, e irá disparar uma exceção caso não haja suporte aos mesmos. Finalmente, o binding WSHttpContextBinding utiliza cookies quando suportado, e SOAP Headers quando não há tal suporte. Com isso, não precisamos nos preocupar como o ID será propagado entre as partes, apenas teremos a responsabilidade de armazenar o ID para conseguir carregar uma instância previamente criada. O trecho de código abaixo ilustra como proceder para configurar a classe ServiceHost, utilizando o binding NetTcpContextBinding:

using (ServiceHost host =
    new ServiceHost(typeof(ServicoDeComercioEletronico),
        new Uri[] { new Uri(“net.tcp://localhost:3832”) }))
{
    host.Description.Behaviors.Add(ConfigurarPersistencia());
    host.AddServiceEndpoint(typeof(IComercioEletronio), new NetTcpContextBinding(), “srv”);

    host.Open();
    Console.ReadLine();
}

Utilizar um dos bindings que vimos acima não é o bastante. Ainda precisamos configurar a persistência das informações, e como já era de se esperar, isso será feito através de um behavior de serviço, chamado PersistenceProviderBehavior. Note que há um método customizado chamado de “ConfigurarPersistencia”, que é o responsável por criar e retornar a instância do provider que fará a persistência das informações.

O construtor da classe PersistenceProviderBehavior recebe como parâmetro uma instância da classe PersistenceProviderFactory. Essa classe abstrata serve como base para todos os providers, inclusive aquele que a Microsoft já disponibilizou para efetuar a persistência no SQL Server. Caso você queira criar o seu próprio provider, então será necessário criar duas classes: o provider em si (herdando da classe PersistenceProvider) e a factory responsável por criar e gerir as instâncias do respectivo provider (herdando de PersistenceProviderFactory).

Como comentado acima, utilizaremos o provider para SQL Server, chamado SqlPersistenceProviderFactory, que está contido no namespace System.ServiceModel.Persistence. Para utilitizá-lo, é importante que você prepare a sua base de dados, rodando os scripts mencionados acima. Como estou utilizando a configuração imperativa, então vou criar a instância da classe SqlPersistenceProviderFactory, que em seu construtor receberá a string de conexão com a base de dados. Note que no código abaixo, além da string de conexão, ainda é passado um valor boleano, indicando como será efetuado a persistência, onde True indica que será serializada em Xml e False em formato binário (padrão).

static PersistenceProviderBehavior ConfigurarPersistencia()
{
    return new PersistenceProviderBehavior(
        new SqlPersistenceProviderFactory(
            ConfigurationManager.ConnectionStrings[“SqlConnString”].ConnectionString, true));
}

Consumindo o Serviço

Para referenciar e invocar operações que compõem serviços duráveis, não há diferenças em relação ao que já conhecemos. Apenas devemos ter duas preocupações: utilizar o binding correspondente ao binding utilizado pelo serviço e também como e onde armazenar o ID que representa a instância remota, que por sua vez, deverá ser devolvido do cliente para o serviço, afim de carregar o respectivo estado do mesmo.

O método “CriarCarrinho”, responsável por criar a instância, deve somente ser invocado uma única vez. Se você não se atentar a isso e chamá-lo sempre, uma nova instância será criada, perdendo todo o sentido da funcionalidade fornecida pelos serviços duráveis. Como também já foi falado acima, sempre quando o método retorna, o repositório é acionado para armazenar o estado atual do objeto, que eventualmente a operação alterou. Se você não invocar o método “FinalizarCompra” (responsável pela exclusão do registro do repositório), a instância sobreviverá a eventuais reinicializações do host ou da aplicação cliente, podendo iniciar uma tarefa e finalizá-la mais tarde, sem a preocupação de perder todo o trabalho realizado até aquele momento.

Toda a mensagem que é enviada do cliente para o serviço, deverá conter o ID que irá relacionar a mensagem a uma determinada instância. O desafio aqui é manter esse ID entre as chamadas, mas lembrando que elas podem ser feitas dias depois, e com isso, utilizar a memória não resolve o nosso problema. O que precisamos é persistir esse ID fisicamente, para que em eventuais reinicializações, sejamos capazes de restaurar o mesmo, e reenviar novas requisições para serem relacionadas aquela instância específica. Utilizaremos as classes já conhecidas do namespace System.IO para efetuar essa tarefa, juntamente com o serializador binário que o .NET disponibiliza (BinaryFormatter).

O segredo é como extrair o ID que foi enviado/gerado pelo serviço do lado do cliente. O proxy gerado durante a referência do serviço, herda diretamente da classe ClientBase<TChannel>. Essa classe possui uma propriedade chamada InnerChannel do tipo IClientChannel. A finalidade desta propriedade é expor a funcionalidade básica de comunicação e informações contextuais. Entre os membros fornecidas pela interface IClientChannel, temos o método GetProperty<T>. Este método genérico, recebe um objeto tipado que o método utilizará para efetuar a busca dentro da channel stack. Caso o objeto seja encontrado, ele é retornado; caso contrário, ele encaminha a busca para a próxima layer.

Utilizaremos este método para extrair uma classe que implementa a interface IContextManager. Como o próprio nome diz, ela representa o gerenciador do contexto do canal atual (contexto relacionado aos serviços duráveis), permitindo você ler ou definir um contexto, com informações específicas. Para isso, ela fornece dois simples métodos: GetContext e SetContext. O primeiro retorna uma cópia do contexto atual, representado por um dicionário de dados (onde a chave e o valor são do tipo string) com os itens que foram enviados pelo serviço. Já o segundo método, SetContext, recebe um dicionário de dados (do mesmo tipo anterior), com as informações que devem ser enviadas do cliente para o serviço. Para facilitar, criei uma classe chamada “GerenciadorDeEstado”, que tem como finalidade gerir o ID que é informado pelo serviço, e reenviado para ele. Por questões de espaço, alguns membros foram omitidos:

internal static class GerenciadorDeEstado
{
    private const string ARQUIVO_COM_CHAVE = “InstanceId.bin”;

    public static void Salvar(IClientChannel channel)
    {
        IContextManager context = channel.GetProperty<IContextManager>();
        if (context != null)
            using (FileStream fs = File.Create(ARQUIVO_COM_CHAVE))
                new BinaryFormatter().Serialize(fs, context.GetContext());
    }

    public static void Carregar(IClientChannel channel)
    {
        if (JaExisteArquivo)
        {
            IContextManager context = channel.GetProperty<IContextManager>();
            if (context != null)
                using (FileStream fs = File.Open(ARQUIVO_COM_CHAVE, FileMode.Open))
                    context.SetContext((IDictionary<string, string>)new BinaryFormatter().Deserialize(fs));
        }
    }

    //Outros Membros
}

Note que no método “Salvar” invocamos o método GetContext, enquanto no método “Carregar” utilizamos o método SetContext. No nosso exemplo, esse dicionário irá conter apenas uma única entrada, chamada de “instanceId”, que é justamente o GUID gerado pela inserção do registro no SQL Server.

O que irá determinar se existe ou não uma instância em aberto para esse cliente, é a existência do arquivo com o respectivo ID. Se notarmos o código abaixo, ele irá verificar a existência do arquivo. Caso não exista, então ele invoca o método “CriarCarrinho” e salvará o contexto atual (ID); caso contrário, ele apenas carregará o contexto (ID) existente, para que as chamadas para as operações sejam encaminhadas para a instância previamente criada. Na sequência, você inclui itens dentro do carrinho e, finalmente, será perguntado se deseja ou não finalizar a compra. Se disser não, então você poderá reabrir a aplicação cliente, que os produtos adicionados ainda estarão disponíveis. Se optar por finalizar a compra, então você deve invocar a operação “FinalizarCompra”, que como já sabemos, é responsável por remover o registro da base de dados.

using (ComercioEletronioClient proxy = new ComercioEletronioClient())
{
    if (!GerenciadorDeEstado.JaExisteArquivo)
    {
        proxy.CriarCarrinho(“Israel Aece”);
        GerenciadorDeEstado.Salvar(proxy.InnerChannel);
    }
    else
    {
        GerenciadorDeEstado.Carregar(proxy.InnerChannel);
    }

    //Incluir Itens

    Console.WriteLine(“nDeseja finalizar a compra? (S)im ou (N)ão”);
    if (Console.ReadLine() == “S”)
    {
        //Finaliza a Compra e remove o registro da base de dados.
        proxy.FinalizarCompra();
        GerenciadorDeEstado.Excluir();

        Console.WriteLine(“A compra foi finalizada com sucesso.”);
    }
}

Durante a execução, ou depois do término da aplicação cliente sem finalizar a compra, ao analisarmos a tabela InstaceData no SQL Server, notaremos um registro adicionado, onde a coluna “id” representa o ID que foi propagado para o cliente e está armazenado no arquivo “InstanceId.bin”, e a coluna “instanceXml” com os membros privados devidamente serializados em formato Xml. Abaixo temos informação formatada que está nesta coluna:

<ServicoDeComercioEletronico xmlns=”http://schemas.datacontract.org/2004/07/Host&#8221;
                             xmlns:i=”http://www.w3.org/2001/XMLSchema-instance&#8221;
                             xmlns:z=”http://schemas.microsoft.com/2003/10/Serialization/&#8221;
                             z:Id=”1″
                             z:Type=”Host.ServicoDeComercioEletronico”
                             z:Assembly=”Host, Version=1.0.0.0″>
  <_produtos z:Id=”2″>
    <_items z:Id=”3″
            z:Size=”4″>
      <ItemDaCompra z:Id=”4″>
        <NomeDoProduto z:Id=”5″>Mouse Microsoft</NomeDoProduto>
        <Quantidade>10</Quantidade>
        <Valor>100.00</Valor>
      </ItemDaCompra>
      <ItemDaCompra z:Id=”6″>
        <NomeDoProduto z:Id=”7″>Celular Motorola</NomeDoProduto>
        <Quantidade>10</Quantidade>
        <Valor>40.0</Valor>
      </ItemDaCompra>
      <ItemDaCompra i:nil=”true” />
      <ItemDaCompra i:nil=”true” />
    </_items>
    <_size>2</_size>
    <_version>2</_version>
  </_produtos>
  <_usuario z:Id=”8″>Israel Aece</_usuario>
</ServicoDeComercioEletronico>

Conclusão: Através deste artigo podemos compreender a finalidade e como implementar serviços duráveis. Notamos que não há nenhuma mudança muito radical em relação ao que conhecemos para a construção de serviços em WCF, mas há alguns detalhes importantes, que se não nos atentarmos, este recurso não funcionará como o esperado. Esse tipo de serviço permite enriquecer ainda mais a experiência com o usuário, não obrigando o mesmo a finalizar a tarefa naquele momento, podendo persistir e restaurar mais tarde.

WCFDurableServices.zip (73.37 kb)

Ao referenciar um serviço WCF em uma aplicação cliente, um proxy é gerado para abstrair toda a complexidade necessária para efetuar a comunicação entre o cliente e o serviço. Ao efetuar essa referência, além da classe que representa o proxy, o arquivo de configuração da aplicação cliente também é alterado, efetuando todas as configurações necessárias para que o WCF possa efetuar a requisição ao serviço remoto.

Entre essas configurações que são realizadas, uma delas é a criação do endpoint do lado do cliente, com o endereço, binding e o contrato necessário para efetuar as requisições. Ao fazer isso, o endereço ficará fixado no arquivo de configuração e não teremos problemas até que o endereço mude de local. Se, por algum motivo, o serviço não estiver mais disponível naquele endereço (endpoint) que foi inicialmente publicado, todos as aplicações deixarão de funcionar, até que alguém altere o endereço manualmente, apontando para o novo endereço.

Para solucionar este problema, a Microsoft estará incorporando ao WCF 4.0 a implementação do protocolo WS-Discovery. Como o próprio nome diz, WS-Discovery trata-se de um padrão criado pela OASIS, que define um mecanismo para o descobrimento de serviços de uma determinada rede, removendo a necessidade dos consumidores conhecerem o endereço do serviço até que a aplicação execute, e além disso, os serviços podem mudar constantemente de endereço, que os eventuais consumidores não deixarão de funcionar. A finalidade deste artigo é abordar como podemos proceder para criar, publicar e consumir serviços utilizando o WS-Discovery. Vale lembrar que este artigo será baseado na versão Beta do Visual Studio .NET 2010 e do .NET Framework 4.0, ou seja, poderá haver alguma mudança até a versão final.

Antes de analisar as classes que são necessárias para fazer com que o descobrimento de serviços funcione, precisamos primeiramente conhecer um pouco mais sobre o procotolo WS-Discovery em si, ou seja, analisar como as notificações são enviadas aos clientes e como esses clientes podem interrogar o serviço. Segundo as especificações deste protocolo, as mensagens utilizadas por ele para descobrimento do serviço são formatadas em padrão SOAP, enviadas através do protocolo UDP. Assim como vários outros padrões WS-*, o WS-Discovery utiliza várias mensagens para notificar e/ou descobrir um serviço na rede. Para entender o fluxo, vamos analisar a imagem abaixo, extraída da especificação do WS-Discovery:

Antes de compreender a imagem acima, é importante estar familiarizado com dois termos: multicasting e unicasting. Ambos são considerados routing schemes, e definem para quem enviar a mensagem. No formato multicast, a mensagem (seja ela qual for) será enviada de forma simultânea para um grupo de destinatários dentro da rede. Já no formato unicast, as informações são enviadas para um único destinatário da rede. Ainda existem outros formatos, como o broadcast e anycast, mas não serão utilizados aqui.

(1) Ao entrar na rede, o serviço envia uma mensagem conhecida como “hello”, no formato multicast, e os clientes que fazem parte do mesmo grupo, podem detectar que o serviço está online, evitando que o cliente fique repetidamente consultando para ver se o serviço está ou não online, reduzindo a quantidade de informações trafegadas na rede. Em analogia à programação assíncrona, seria mais ou menos como receber um “callback” ao invés de utilizar o pooling. (2) Os clientes também podem enviar uma mensagem conhecida como “probe” no formato multicast para a rede, em busca de um serviço de um determinado tipo. (3) Serviços que atendam aquele critério, retornam uma mensagem conhecida como “probe match”, no formato unicast, para o respectivo cliente. O cliente pode querer procurar um serviço através de seu nome. (4) Neste caso, o cliente deve enviar uma mensagem conhecida como “resolve message” através do formato multicast, e caso um serviço seja encontrado, (5) ele responderá através de uma mensagem conhecida como “resolve match”. (6) Finalmente, ao deixar a rede, o serviço envia uma mensagem conhecida como “bye” no formato multicast, para notificar que ele está saindo.

Depois de uma pequena introdução ao protocolo WS-Discovery, vamos analisar os tipos que temos a disposição a partir do WCF 4.0, que permitem ao serviço e ao cliente efetuar o descobrimento. Esses tipos estão debaixo do namespace System.ServiceModel.Discovery, que por sua vez está definido dentro do Assembly System.ServiceModel.Discovery.dll.

Em princípio, o contrato e a classe que representa o serviço não sofrerão qualquer alteração. As mudanças começam na configuração do serviço, onde você deverá criar um endpoint para possibilitar o descobrimento do serviço. Esse endpoint permitirá ao serviço monitorar as requisições (as mesmas mostradas na imagem acima) que este protocolo envia ou recebe para garantir o seu funcionamento. Para configurá-lo, você pode optar pela programação declarativa ou imperativa. No modo imperativo, basta você passar uma instância da classe UdpDiscoveryEndpoint para o método AddServiceEndpoint da classe ServiceHost, enquanto pelo modo declarativo, você pode recorrer ao atributo kind do elemento endpoint, especificando o valor “udpDiscoveryEndpoint”, que determina um standard endpointpreconfigurado.

Além da criação de um endpoint para descobrimento, ainda precisamos adicionar um behavior em nível de serviço, que é representado pela classe ServiceDiscoveryBehavior (ou pelo elemento serviceDiscovery em modo declarativo), que indica ao serviço que ele possa ser descoberto. Esse behavior ainda fornece uma coleção chamada de AnnouncementEndpoints, que permite aos consumidores do serviço a receberem notificações de quando o serviço estiver online ou offline. Basicamente, dentro desta seção temos também os standard endpoints, que encapsulam toda a comunicação para fazer o protocolo WS-Discovery funcionar, sem interferir na comunicação com o serviço em si. O trecho de código abaixo exemplifica a configuração do protocolo WS-Discovery em um serviço, utilizando o modelo declarativo:

<?xml version=”1.0″ encoding=”utf-8″ ?>
<configuration>
  <system.serviceModel>
    <services>
      <service name=”Service.Servico” behaviorConfiguration=”bhv”>
        <host>
          <baseAddresses>
            <add baseAddress=”http://localhost:8383/Srv/”/&gt;
          </baseAddresses>
        </host>
        <endpoint address=”” binding=”basicHttpBinding” contract=”Service.IContrato” />
        <endpoint address=”mex” binding=”mexHttpBinding” contract=”IMetadataExchange” />
        <endpoint name=”udpDiscovery” kind=”udpDiscoveryEndpoint” />
      </service>
    </services>
    <behaviors>
      <serviceBehaviors>
        <behavior name=”bhv”>
          <serviceMetadata />
          <serviceDiscovery>
            <announcementEndpoints>
              <endpoint name=”udpAnnouncement” kind=”udpAnnouncementEndpoint” />
            </announcementEndpoints>
          </serviceDiscovery>
        </behavior>
      </serviceBehaviors>
    </behaviors>
  </system.serviceModel>
</configuration>

Consumindo o Serviço

Como falado acima, geralmente efetuamos a referência do serviço no cliente, onde a IDE ou o svcutil.exe faz todo o trabalho para a geração do proxy e do arquivo de configuração correspondente. Você pode continuar utilizando estas técnicas para construir os artefatos necessários para efetuar a comunicação, mas ao invés de definir o endereço de forma estática no arquivo de configuração, vamos fazer uso do protocolo WS-Discovery. O WS-Discovery é útil quando o serviço pode mudar frequentemente de endereço, e fixá-lo fará com que uma exceção seja disparada quando o mesmo não estiver mais respondendo naquele endereço, obrigando o administrador ou desenvolvedor alterar para o novo endereço de forma manual.

Como já falamos acima, utilizando o WS-Discovery não há mais a necessidade de conhecer o endereço, pois compete a este protocolo procurar pelos serviços que estão rodando naquela rede. Antes de invocar efetivamente a operação que o serviço disponibiliza, há alguns passos extras que devem ser realizados para que o cliente consiga determinar o endereço onde o serviço está rodando. Felizmente o WCF fornece uma classe chamada DiscoveryClient, que dado um endpoint de descobrimento e um critério de pesquisa, dispara as mensagens “probe” ou “resolve” para tentar encontrar o serviço em questão. O endpoint utilizado pelo cliente segue as mesmas características do endpoint utilizado pelo serviço, ou seja, fazendo uso do padrão UDP.

O critério a ser pesquisado deve ser criado a partir da classe FindCriteria, que em seu construtor recebe um parâmetro que especifica o contrato do serviço a ser pesquisado na rede. É importante dizer que neste momento é necessário que o cliente conheça, de alguma forma, o contrato que os possíveis serviços que estão rodando na rede implementem. Esse contrato pode ter sido fornecido out-of-band (por exemplo via e-mail), através do compartilhamento de assemblies que especificam os contratos e tipos que são utilizados por estes serviços, ou até mesmo via IDE ou através do utilitário svcutil.exe. A instância desta classe é passada como parâmetro para o método Find da classe DiscoveryClient, que por sua vez, retorna uma instância da classe FindResponse, contendo o resultado da pesquisa. O código abaixo ilustra essa primeira etapa do descobrimento:

using (DiscoveryClient dc = new DiscoveryClient(new UdpDiscoveryEndpoint()))
{
    FindResponse fr = dc.Find(new FindCriteria(typeof(IContrato)));
}

É importante dizer que o método Find é sobrecarregado, ou seja, há uma segunda versão dele que não recebe parâmetros, retornando todos os serviços ativos na rede, independentemente de quais contratos ele venha a implementar. Além disso, a classe DiscoveryClient ainda fornece um método chamado FindAsync, que como o próprio nome diz, possibilita a busca por serviços de forma assíncrona, pois caso este processo demore, você estará livre para continuar trabalhando em outras áreas do sistema, efetuando outras tarefas. Utilizando a forma assíncrona, você pode se vincular aos eventos FindProgressChanged e FindCompleted, para ser notificado a respeito do progresso da busca e quando ela for finalizada, respectivamente.

A classe FindResponse, que representa o resultado da pesquisa, possui apenas uma única propriedade chamada Endpoints. Essa propriedade retorna uma coleção, onde cada elemento é do tipo EndpointDiscoveryMetadata. Cada um destes elementos representam os serviços que estão ativos na rede e que implementam o contrato que você especificou no critério de busca, disponibilizando informações através de suas propriedades, de cada serviço descoberto, como por exemplo, o endereço (Address) e os contratos que o serviço implementa (ContractTypeNames).

A partir deste momento passamos a utilizar as classes já conhecidas, e que existem desde a primeira versão do WCF. Como falado acima, temos duas opções: a primeira delas consiste em criar o proxy através da IDE ou do utilitário svcutil.exe. O proxy criado possui um overload do contrutor que recebe uma instância da classe EndpointAddress, que representa o endereço de acesso ao serviço. Como antes o endereço estava fixado no arquivo de configuração, não era necessário informar explicitamente, já que com a configuração padrão, ele envia a requisição para aquele endereço preconfigurado. Já a segunda alternativa, geralmente utilizada quando estamos compartilhando o contrato através de assemblies, podemos recorrer a classe ChannelFactory<TChannel>, que dado uma instância da classe EndpointAddress e o binding em seu construtor, também estabelece a comunicação com o serviço em questão.

A propriedade Address, exposta pela classe EndpointDiscoveryMetadata, retorna uma instância da classe EndpointAddress contendo o endereço do serviço descoberto. Como já podemos assimilar, essa instância é passada para o proxy ou para a classe ChannelFactory<TChannel>. Para exemplificar, estarei utilizando a segunda opção, onde utilizarei a classe ChannelFactory<TChannel> para estabelecer a conexão e executar a operação no serviço descoberto pela classe DiscoveryClient:

using (DiscoveryClient dc = new DiscoveryClient(new UdpDiscoveryEndpoint()))
{
    FindResponse fr = dc.Find(new FindCriteria(typeof(IContrato)));

    if (fr.Endpoints.Count > 0)
    {
        EndpointAddress address = fr.Endpoints[0].Address;

        using (ChannelFactory<IContrato> factory =
            new ChannelFactory<IContrato>(new BasicHttpBinding(), address))
        {
            IContrato client = factory.CreateChannel();
            Console.WriteLine(client.Ping(DateTime.Now.ToString()));
        }
    }
    else
    {
        Console.WriteLine(“Nenhum serviço encontrado.”);
    }
}

Se estivermos utilizando o proxy que foi gerado automaticamente através do WSDL, então somente devemos substituir o ChannelFactory<TChannel> pela instância do proxy, informando o endereço do serviço que foi descoberto. É importante notar também que o arquivo App.Config não possui nenhuma configuração do serviço.

A principal vantagem do descobrimento é conseguir identificar um serviço que muda frequentemente de endereço. Como vimos acima, ao encontrar o serviço, criamos a instância da classe ChannelFactory<TChannel> com o respectivo endereço e informamos o binding BasicHttpBinding. Como estamos em um projeto de testes, onde tudo é facilmente controlado, conseguimos definir o mesmo tipo de binding, já que sabemos qual deles foi utilizado para expor o serviço. Mas em um mundo real, o serviço pode, por algum motivo, também alterar o binding que está sendo exposto pelo serviço, e por mais que você saiba o endereço até o mesmo, se o binding não corresponder ao mesmo utilizado pelo serviço, a comunicação não será possível.

O binding é uma informação que é exposta através do documento WSDL. Caso o serviço disponibilize este documento através de um endereço (isso não é obrigatório para o WS-Discovery funcionar), você pode utilizar o método estático Resolve da classe MetadataResolver (existente desde a primeira versão do WCF), para efetuar o download dos metadados de um determinado contrato, onde também teremos uma coleção com os endpoints disponíveis, e cada elemento desta coleção é representado pela classe ServiceEndpoint. Essa classe expõe uma propriedade chamada Binding, que como o próprio nome diz, retorna a instância de um binding que corresponde ao binding que está sendo utilizado pelo endpoint remoto.

É importante dizer que o método Resolve necessita do endereço até o endpoint que expõe o documento WSDL, e sendo assim, o critério de busca passa a ser pelo endereço do WSDL e não mais pelo endereço do serviço diretamente. O código cliente está totalmente dinâmico, ou seja, tanto o endereço como o binding são descobertos durante a execução. Aplicando essas mudanças, o código de exemplo que vimos acima passa a ficar da seguinte maneira:

using (DiscoveryClient dc = new DiscoveryClient(new UdpDiscoveryEndpoint()))
{
    FindResponse fr = dc.Find(FindCriteria.CreateMexEndpointCriteria(typeof(IContrato)));
    if (fr.Endpoints.Count > 0)
    {
        EndpointAddress mex = fr.Endpoints[0].Address;

        ServiceEndpointCollection sec =
            MetadataResolver.Resolve(typeof(IContrato), mex);

        if (sec.Count > 0)
        {
            ServiceEndpoint se = sec[0];

            using (ChannelFactory<IContrato> factory =
                new ChannelFactory<IContrato>(se.Binding, se.Address))
            {
                IContrato client = factory.CreateChannel();
                Console.WriteLine(client.Ping(DateTime.Now.ToString()));
            }
        }
    }
    else
    {
        Console.WriteLine(“Serviço não encontrado.”);
    }
}

Para finalizar, note que utilizamos uma instância da classe FindCriteria que foi retornada através do método estático CreateMexEndpointCriteria, pois o foco agora é procurar pelo documento WSDL, para conseguir extrair também o respectivo binding que está sendo exposto pelos endpoints.

Notificação através de Announcements

Announcements é uma funcionalidade que é disponibilizada juntamente com o WS-Discovery que possibilita o cliente ser notificado quando o serviço estiver online ou offline. Isso permitirá você interceptar essas notificações e tomar alguma decisão para determinar se deve ou não invocar o serviço. Podemos enxergar os announcements a partir das mensagens “hello” e “bye” da imagem acima, enviando-as a partir do formato multicast, ou seja, somente os clientes interessados irão receber essas mensagens.

Para que isso funcione, primeiramente você precisa configurar o serviço para que ele notifique os possíveis clientes quando entrar no ar ou quando ele for deixar a rede (quando fechar o host). Para efetuar essa primeira configuração, você precisa adicionar um endpoint de announcement (também UDP) no elemento announcementEndpoints, do behavior serviceDiscovery. O código do arquivo de configuração que vimos acima, já está com esse endpoint devidamente configurado.

Já do lado do cliente, há algumas classes que precisamos utilizar para que o mesmo seja notificado. É importante dizer que não será o proxy que irá monitorar essas mensagens, mas sim um serviço chamado AnnouncementService. Essa classe irá “ouvir” as mensagens de “hello” e “bye”, enviadas pelo serviço, e notificará a aplicação cliente através dos eventos OnlineAnnouncementReceived e OfflineAnnouncementReceived. Como disse anteriormente, essa classe será um serviço hospedado pelo próprio cliente (self-hosted), ou seja, devemos configurar os eventos e passar a instância dela para um ServiceHost. A única configuração necessária no host é a adição de um standard endpoint, que é representado pela instância da classe AnnouncementEndpoint. O código a seguir mostra o quanto é simples fazer a aplicação cliente receber essas mensagens:

AnnouncementService announSrv = new AnnouncementService();
announSrv.OfflineAnnouncementReceived += (sender, e) => Console.WriteLine(“Serviço Offline.”);
announSrv.OnlineAnnouncementReceived += (sender, e) => Console.WriteLine(“Serviço Online.”);

using (ServiceHost announHost = new ServiceHost(announSrv))
{
    announHost.AddServiceEndpoint(new UdpAnnouncementEndpoint());
    announHost.Open();

    Console.ReadLine();
}

Extensions

A classe EndpointDiscoveryMetadata ainda fornece uma propriedade chamada Extensions, que nos permite passar informações extras do serviço para o cliente, que estarão acessíveis durante o processo de descobrimento. Para que você consiga adicionar essas informações, você deverá recorrer à um behavior de endpoint, chamado EndpointDiscoveryBehavior. Essa classe fornece uma propriedade chamada Extensions, que expõe uma coleção de elementos do tipo XElement, representando as informações customizadas que desejamos enviar ao cliente.

Primeiramente é necessário criar a instância da classe EndpointDiscoveryBehavior e configurar as extensões através da propriedade Extensions. Depois disso, basta adicioná-la na coleção de behaviors de um endpoint específico, acessível a partir do host (ServiceHost). A escolha de qual endpoint adicionar, dependerá de qual critério utilizará para busca, e no caso do exemplo acima, estamos procurando pelo endpoint que expõe o WSDL. O código abaixo ilustra a criação da classe EndpointDiscoveryBehavior e como adicioná-la ao endpoint:

using (ServiceHost host = new ServiceHost(typeof(Servico), new Uri[] { }))
{
    EndpointDiscoveryBehavior edb = new EndpointDiscoveryBehavior();
    edb.Extensions.Add(new XElement(“InfoExtra”, “ViaDiscovery”));
    host.Description.Endpoints[1].Behaviors.Add(edb);

    host.Open();
    Console.ReadLine();
}

Já do lado do cliente, tudo o que precisamos fazer (caso o endpoint seja encontrado), é também recorrer a propriedade Extensions, assim como é mostrado abaixo:

using (DiscoveryClient dc = new DiscoveryClient(new UdpDiscoveryEndpoint()))
{
    FindResponse fr = dc.Find(FindCriteria.CreateMexEndpointCriteria(typeof(IContrato)));

    if (fr.Endpoints.Count > 0)
        Console.WriteLine(fr.Endpoints[0].Extensions[0].Value);
    else
        Console.WriteLine(“Serviço não encontrado.”);
}

Conclusão: Vimos neste artigo como funciona a utilização do protocolo WS-Discovery, que estará disponível com a versão 4.0 do WCF. Isso traz grandes benefícios aos serviços que mudam constantemente de endereço, e principalmente, para os clientes que consomem, já que não precisam alterar nenhuma configuração caso isso aconteça. Esta nova funcionalidade é adicionada ao WCF seguindo as mesmas características anteriores, ou seja, com pequenas configurações habilitamos este recurso, sem a necessidade de entender como o protocolo funciona nos bastidores, nos permitindo continuar com o foco no desenvolvimento da regra de negócio.

WSDiscovery.zip (14.63 kb)

Quando expomos um serviço através do binding NetTcpBinding, as requisições que chegam até ele, são processadas e, finalmente o retorno é enviado para o respectivo cliente. As mensagens que chegam são processadas no formato FIFO (first-in, first out), ou seja, elas aguardam o processamento em uma fila e, sob demanda, são encaminhadas para o processamento.

Se a velocidade do processamento da mensagem é mais lenta que a velocidade de envio das mensagens, essa fila pode aumentar. Por padrão o binding NetTcpBinding limita, através da propriedade ListenBacklog, o número de requisições pendentes que podem ser enfileiradas. O valor padrão é 10 e, dependendo da quantidade de requisições que chegam para o serviço, esse limite pode exceder e, a seguinte exceção será disparada:

System.ServiceModel.EndpointNotFoundException: Could not connect to net.tcp://localhost:8879/srv. The connection attempt lasted for a time span of 00:00:02.1404880. TCP error code 10061: No connection could be made because the target machine actively refused it 127.0.0.1:8879.  —> System.Net.Sockets.SocketException:No connection could be made because the target machine actively refused it 127.0.0.1:8879

A alternativa aqui é aumentar esse número, definindo um valor próximo a quantidade das conexões simultaneas que eventualmente podem chegar para o serviço. O exemplo abaixo ilustra a configuração desta propriedade no binding NetTcpBinding:

host.AddServiceEndpoint(typeof(IContrato), new NetTcpBinding() { ListenBacklog = 70 }, “srv”);