Há algum tempo eu mostrei publiquei aqui um artigo que demonstra como utilizar serviços WCF em conjunto com o Message Queue, que como sabemos, leva a confiabilidade dos serviços para um outro nível. Para efeito de testes, aquele exemplo usa uma aplicação Console para hospedar o serviço que faz uso do Message Queue.

Uma das opções de hosting que temos é o WAS (Windows Activation Service), que incorpora ao IIS funcionalidades extras, permitindo ao mesmo hospedar serviços que vão além do protocolo HTTP. Quando habilitamos o WAS, ele também fornece um listener para gerenciar serviços que são hospedados no IIS mas fazem uso do Message Queue. Esse serviço chamado de Net.Msmq Listener Adapter, é o responsável pela ativação do worker process que gerencia a execução dos serviços WCF hospedados no IIS.

O serviço de ativação nada mais é que um serviço Windows, que quando é inicializado, percorre todas as filas públicas e privadas que existem no computador, qual monitorará as mensagens que chegarem para elas, e quando uma mensagem chegar, irá entregá-la para o serviço WCF, que por sua vez, irá processá-la. Mas para que ele consiga lidar tranquilamente com o Message Queue, alguns cuidados precisam ser tomados.

O primeiro é com relação ao nome da fila. Para que o WAS consiga entregar as mensagens de forma transparente, é importante que o nome da fila tenha o mesmo nome do diretório virtual, incluindo o arquivo *.svc. Por exemplo, se temos um diretório virtual chamado Servicos e o serviço WCF nomeado como ServicoDePedidos.svc, então o nome da fila deverá ser Servicos/ServicoDePedidos.svc. Outro detalhe importante é que as filas do Message Queue também são protegidas por ACLs, o que nos obriga a fazer com que a conta definida no worker process (muitas vezes o Network Service) também tenha acesso à fila em questão.

Com essas configurações, já temos os serviços fazendo uso do Message Queue e, consequentemente, explorando todo o potencial das funcionalidades que o IIS e o AppFabric nos disponibiliza.

Assim como as classes, as interfaces também podem fazer uso da herança para agregar funcionalidades e características de outras interfaces, e quando implementamos uma interface que herda de outra, todos os membros envolvidos na hierarquia deverão ser definidas na classe.

Como sabemos, são as interfaces que definem os contratos de serviços WCF, e podemos fazer uso de herança de interfaces para refinar o acesso à operações, conseguindo filtrar o que será exposto através de um determinado endpoint. Considere as interfaces a seguir:

[ServiceContract]
interface IContrato1
{
    [OperationContract]
    string Metodo1(string value);
}

[ServiceContract]
interface IContrato2 : IContrato1
{
    [OperationContract]
    string Metodo2(string value);
}

Note que a interface IContrato2 herda da interface IContrato1, o que obrigará a classe (serviço) que implementar a interface IContrato2, também definir a implementação para o Metodo1, definido na interface IContrato1. Como na criação do endpoint somos obrigados a informar um contrato, podemos permitir que internamente o consumidor veja ambos os métodos, pois estamos expondo o contrato IContrato2, enquanto externamente, o consumidor somente irá visualizar as operações expostas pelo contrato IContrato1, que neste caso é o método Metodo1.

host.AddServiceEndpoint(typeof(IContrato1), new BasicHttpBinding(), “contratoExterno”);
host.AddServiceEndpoint(typeof(IContrato2), new NetTcpBinding(), “contratoInterno”);

O fato de existir a herança, permitirá ao consumidor interno visualizar as operações do contrato IContrato2 e também as operações expostas pelo contrato IContrato1, dando a ele todas as funcionalidades que foram fornecidas pela herança dos contratos (interfaces).

Já mostrei neste artigo e vídeo como podemos fazer para habilitar o log de mensagens do WCF, onde podemos capturar o envelope da mensagem SOAP que está sendo trafegado entre as partes envolvidas.

Somente o fato de habilitar já é o suficiente para capturar todas as mensagens que chegam ao serviço e também aquelas que são devolvidas para os respectivos clientes, contendo o resultado do processamento da operação. Dependendo do tamanho do envelope e do volume de requisições, em pouco tempo, você pode consumir uma grande quantidade de espaço em disco.

Para melhorar isso, o message logging do WCF fornece filtros que podemos aplicar aos headers do envelope SOAP, e com isso, analisar e decidir se queremos ou não catalogar aquela mensagem. Para exemplificar, considere o contrato abaixo, que possui duas operações simples:

[ServiceContract(Namespace = “http://www.israelaece.com/servicos“)]
public interface IContrato
{
    [OperationContract]
    ItemDeExtrato[] VisualizarExtrato(string conta);

    [OperationContract]
    void Debitar(string conta, decimal valor);
}

A operação VisualizarExtrato retorna um array de itens que fazem parte de um extrato de uma determinada conta, informada através do parâmetro conta. Já a segunda operação, recebe a conta e o valor a ser debitado da mesma. Como sabemos, podemos ligar o logging do WCF para começarmos a capturar as mensagens que chegam para este serviço como um todo. O código abaixo ilustra essa configuração:

<?xml version=”1.0″ encoding=”utf-8″ ?>
<configuration>
  <system.diagnostics>
    <sources>
      <source name=”System.ServiceModel.MessageLogging”
              switchValue=”All”
              propagateActivity=”true”>
        <listeners>
          <add name=”Xml”
               type=”System.Diagnostics.XmlWriterTraceListener”
               initializeData=”C:TempMessageLogging.svclog” />
        </listeners>
      </source>
    </sources>
    <trace autoflush=”true” />
  </system.diagnostics>
  <system.serviceModel>
    <diagnostics>
      <messageLogging logEntireMessage=”true”
                      logMessagesAtServiceLevel=”true”
                      maxMessagesToLog=”100″
                      maxSizeOfMessageToLog=”200000″ />
    </diagnostics>
  </system.serviceModel>
</configuration>

Com isso, ao abrir o arquivo gerado pelo logging recém habilitado, veremos a mensagem que chegou para o serviço com a requisição de débito:

<s:Envelope xmlns:a=”http://www.w3.org/2005/08/addressing&#8221;
            xmlns:s=”http://www.w3.org/2003/05/soap-envelope”&gt;
  <s:Header>
    <Action a:mustUnderstand=”1″
            xmlns=”http://www.w3.org/2005/08/addressing&#8221;
            xmlns:a=”http://www.w3.org/2003/05/soap-envelope”&gt;http://www.israelaece.com/servicos/IContrato/Debitar</Action>
    <a:MessageID>urn:uuid:25eb06f3-b1d5-41a4-99c8-37f1a5905d7f</a:MessageID>
    <a:ReplyTo>
      <a:Address>http://www.w3.org/2005/08/addressing/anonymous</a:Address&gt;
    </a:ReplyTo>
    <a:To s:mustUnderstand=”1″>net.tcp://localhost:9392/srv</a:To>
  </s:Header>
  <s:Body>
    <Debitar xmlns=”http://www.israelaece.com/servicos”&gt;
      <conta>000001</conta>
      <valor>1200</valor>
    </Debitar>
  </s:Body>
</s:Envelope>

Mas o problema é que também as mensagens que chegam para a operação VisualizarExtrato também serão catalogadas, e como elas possuem uma grande quantidade de informações, neste caso, não temos a necessidade de monitorar essas mensagens. É aqui que entra em cena os filtros, tema deste artigo. Dentro do elemento messageLogging temos um sub-elemento chamado de filters, que nada mais é que uma coleção, onde você pode elencar diversos filtros, utilizando a linguagem/tecnologia XPath para analisar e escrever tais filtros. Exemplo:

<system.serviceModel>
  <diagnostics performanceCounters=”All”>
    <messageLogging logEntireMessage=”true”
                    logMessagesAtServiceLevel=”true”
                    logMessagesAtTransportLevel=”false”
                    maxMessagesToLog=”100″
                    maxSizeOfMessageToLog=”200000″>
      <filters>
        <add xmlns:a=”http://www.w3.org/2005/08/addressing&#8221;
             xmlns:s=”http://www.w3.org/2003/05/soap-envelope”>/s:Envelope/s:Header/a:Action%5Btext()=&#8221;http://www.israelaece.com/servicos/IContrato/Debitar“]</add>
      </filters>
    </messageLogging>
  </diagnostics>
</system.serviceModel>

Modificando o arquivo de configuração do serviço, estamos acrescentando um filtro que utilizaremos para catalogar as mensagens somente se a Action (que representa a operação) for igual a Debitar, descartando assim todas as mensagens que chegam para as outras operações e, consequentemente, eventuais dados gerados por elas.

Quando hospedamos serviços WCF no IIS, podemos permitir ao serviço utilizar os recursos fornecidos pelo ASP.NET. Entre esses recursos, temos as variáveis de aplicação, de sessão, cookies, caching, etc. Para permitir isso, tudo o que precisamos fazer é habilitar através de um atributo na classe que representa o serviço, chamado de AspNetCompatibilityRequirementsAttribute. Ele fornece uma propriedade chamada RequirementsMode, que aceita uma das opções impostas pelo enumerador AspNetCompatibilityRequirementsMode. O código abaixo ilustra a sua configuração:

[AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Required)]
public class Servico01 : IServico01
{
    public string Ping(string value)
    {
        if (HttpContext.Current.Session[“Teste”] == null)
            HttpContext.Current.Session[“Teste”] = value;

        return HttpContext.Current.Session[“Teste”] as string;
    }
}

Note que na implementação estamos fazendo uso de variáveis de sessão. Além disso, precisamos ligar explicitamente essa compatibilidade com o ASP.NET no arquivo Web.config, que é utilizado pela aplicação que hospeda o serviço, e para isso, definimos o atributo aspNetCompatibilityEnabled do elemento serviceHostingEnvironment para True, conforme é mostrado abaixo:

<?xml version=”1.0″?>
<configuration>
  <system.serviceModel>
    <serviceHostingEnvironment aspNetCompatibilityEnabled=”true” />
  </system.serviceModel>
</configuration>

E com essas configurações podemos de dentro de serviços WCF, utilizar as funcionalidades expostas pelo ASP.NET. É importante dizer que variáveis de sessão são controladas através de cookies, e mesmo em serviços WCF, eles continuam sendo utilizados para relacionar um determinado cliente e as suas respectivas variáveis de sessão que estão armazenadas no servidor.

Quando estamos publicando o nosso serviço através de um binding HTTP (BasicHttpBinding ou WSHttpBinding), eles possuem uma propriedade boleana chamada AllowCookies. O nome desta propriedade pode parecer confuso, pois a finalidade dela não é permitir que o binding utilize ou não cookies, mas sim determinar quem deverá manipulá-los.

Quando esta propriedade estiver definida como True (o padrão é False), o próprio runtime do WCF irá gerenciar os cookies. Isso quer dizer que ele criará uma instância da classe CookieContainer e a associará ao serviço, utilizando-a para todas as requisições subsequentes, ou seja, todo e qualquer cookie retornardo pelo serviço, será automaticamente reenviado nas futuras requisições para este mesmo serviço, sem a necessidade de controlar como isso é realizado.

O problema aparece quando temos mais do que um serviço dentro da aplicação (WebSite). Serviços diferentes, exigem proxies diferentes no cliente, e os cookies estão vinculado à um proxy específico, ou seja, se você utiliza dois proxies, sendo um para cada serviço (*.svc), os cookies não serão compartilhados, e com isso, os cookies e, consequentemente, variáveis de sessão, não serão compartilhados entre eles (serviços), gerando assim um resultado inesperado. A imagem abaixo ilustra a estrutura do lado do servidor, e como sabemos, existirá um proxy para cada serviço.

A implementação do Servico02 para o teste é extremamente simples, ou seja, ele apenas lê a informação de uma variável de sessão que foi criada pelo Servico01. Apesar deste serviço também estar configurado para exigir o modo de compatibilidade, isso não resolverá, já que o problema reside do lado do cliente, pois como ele não consegue manter o cookie entre os proxies, quando tentarmos executar este segundo serviço, o WCF e o ASP.NET entendem que não foi criada a sessão e, consequentemente, retornará nulo.

[AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Required)]
public class Servico02 : IServico02
{
    public string Ping(string value)
    {
        return HttpContext.Current.Session[“Teste”] as string;
    }
}

Para começar a resolver o problema, o primeiro passo é desligar o controle automático de cookies pelo WCF, definido a propriedade AllowCookies para False (que já é o padrão), assim como é mostrado abaixo. É importante dizer que essa propriedade deve estar devidamente configurada no cliente, que com isso, será responsável por gerenciar manualmente os cookies gerados pelo serviço.

<bindings>
    <basicHttpBinding>
        <binding allowCookies=”false” />
    </basicHttpBinding>
</bindings>

Depois dessa configuração, o resto será através do próprio código. Se notarmos no exemplo abaixo, podemos perceber que temos os dois proxies, sendo um para cada serviço. Temos também uma string que receberá o valor do cookie gerado, que corresponderá ao Id da sessão. Logo depois da criação do proxy para o primeiro serviço, instanciamos a classe OperationContextScope, que cria um bloco de acesso ao contexto da operação, tendo acesso a recursos como headers e properties do serviço. Já dentro deste bloco, utilizamos a classe HttpResponseMessageProperty para extrairmos os valores pertinentes a resposta da execução do método Ping. Note que ela está sendo acessada depois da chamada ao método Ping. Com a coleção de headers em mãos, utilizamos o header SetCookie para extrair o valor do cookie de sessão do ASP.NET (ASP.NET_SessionId) e guardamos na string sessionIdCookie.

Se ainda invocarmos o método Ping a partir do mesmo proxy, não teremos problema, ou seja, ele conseguirá manter a variável de sessão. Mas aqui a situação é outra, ou seja, temos um segundo proxy para o consumo de um outro serviço, mas que queremos utilizar a mesma variável de sessão, gerada anteriormente. Para o segundo proxy, nós fazemos o processo inverso, ou seja, criamos o escopo de acesso aos recursos da requisição, e construímos a instância da classe HttpRequestMessageProperty e configuramos o cookie com aquele valor que salvamos depois de invocar o método através do primeiro proxy.

static void InvocarServico()
{
    string sessionIdCookie = null;

    using (Servico01Client proxy1 = new Servico01Client())
    {
        using (new OperationContextScope(proxy1.InnerChannel))
        {
            Console.WriteLine(proxy1.Ping(“teste”));

            HttpResponseMessageProperty response =
                OperationContext.Current.IncomingMessageProperties[HttpResponseMessageProperty.Name] as HttpResponseMessageProperty;

            sessionIdCookie = response.Headers[HttpResponseHeader.SetCookie];
        }
    }

    using (Servico02Client proxy2 = new Servico02Client())
    {
        using (new OperationContextScope(proxy2.InnerChannel))
        {
            if (!string.IsNullOrWhiteSpace(sessionIdCookie))
            {
                HttpRequestMessageProperty request = new HttpRequestMessageProperty();
                request.Headers[HttpRequestHeader.Cookie] = sessionIdCookie;

                OperationContext.Current.OutgoingMessageProperties[HttpRequestMessageProperty.Name] = request;
            }

            Console.WriteLine(proxy2.Ping(“outro valor”));
    }
}

Com isso tudo criado, agora o método Ping do proxy2 será capaz de retornar o valor gerado e armazenado na variável de sessão através do proxy1. Caso você não utilize essa técnica, a requisição para os métodos do proxy2 serão enviadas sem o cookie, e com isso, o WCF e o ASP.NET não saberá que existe variáveis de sessão já criadas para aquele usuário, e com isso, não terá acesso as informações previamente criadas.

Quando ouvimos dizer sobre programas P2P, sempre nos vem a mente aqueles softwares que compartilham diversos conteúdos (ilegal ou não, não é o caso a ser discutido aqui), e que geralmente estão em formato de músicas, vídeos, livros, etc. A ideia é cada ponto publicar o que deseja disponibilizar, para que outros pontos que estão dentro da mesma rede, possam baixar o que lhes interessam.

Mas publicar conteúdo não é a única finalidade deste tipo de comunicação. Podemos usufruir deste tipo de rede para colaboração, que é algo cada vez mais frequente nas empresas, e além disso, a possibilidade de distribuir processamento entre os vários pontos, para que todos consigam cooperar na execução de uma tarefa maior.

Cada um dos pontos que fazem parte de uma rede P2P, são conhecidos como nó (node) ou peer, e a rede como mesh (mesh network). Mas uma rede P2P pode ser definida de duas formas, onde a primeira é considerada pura, ou seja, não existirá um servidor – centralizador – envolvido, e cada ponto atuará como cliente e servidor. Já a outra forma, conhecida como híbrida, teremos um servidor fazendo parte da rede, mas a finalidade dele é apenas de rastrear ou de gerenciar a comunicação entre os pontos, mas não é responsável por armazenar qualquer tipo informação.

Para implementarmos uma rede P2P, a Microsoft disponibilizou dentro do .NET Framework um namespace chamado System.Net.PeerToPeer, que contém todos os tipos necessários para a construção de uma rede deste tipo. Mas como o WCF é o pilar de comunicação dentro do .NET Framework, a Microsoft resolveu permitir a exposição de serviços através do modelo P2P, podendo reutilizar o conhecimento que temos em serviços tradicionais para expor tarefas/dados através deste modelo. Isso evitará conhecermos detalhes de mais baixo nível, que é algo que teríamos que fazer se fossemos utilizar as classes contidas no namespace System.Net.PeerToPeer.

Apesar de utilizar o WCF como meio de criação de aplicações que estarão conectadas via P2P, temos algumas mudanças consideráveis em relação ao contrato e ao consumo destes serviços, justamente pela natureza dele. Para explicar melhor, vamos explorar o contrato, que é o primeiro passo a ser realizado para a construção do serviço. Abaixo temos a interface que possui um método chamado EnviarMensagem que possui duas strings como parâmetro, que representam o remetente e a mensagem, respectivamente. O principal detalhe a ser notar aqui, é a propriedade CallbackContract do atributo ServiceContractAttribute. Geralmente utilizamos uma interface de callback separada, mas como as mensagens enviadas e recebidas terão o mesmo formato, o contrato de callback deverá ser o mesmo que o contrato que descreve o serviço. Isso é referido como contrato simétrico.

[ServiceContract(CallbackContract = typeof(IContrato))]
public interface IContrato
{
    [OperationContract(IsOneWay = true)]
    void EnviarMensagem(string de, string mensagem);
}

Quando desenvolvemos um serviço WCF “tradicional”, o próximo passo é a criação da aplicação que servirá como hospedeira da classe que representará o serviço, e que deverá utilizar a classe ServiceHost (ou uma de suas derivadas) para gerenciar a execução do serviço. Mas como falamos acima, uma das alternativas de redes P2P é não possuir um servidor, ou seja, a criação de uma aplicação para hospedar o serviço, neste caso, não existirá.

Com essa grande diferença, tudo o que precisaremos fazer é a configuração do lado do cliente. E como sabemos, todo serviço WCF deve possuir três características essenciais, conhecidas como Address, Binding e Contract. Aqui o binding será o NetPeerTcpBinding, que foi criado justamente para abstrair toda a comunicação feita sobre o protocolo P2P, e que internamente, recorrerá aos tipos fornecidos pelo namespace System.Net.PeerToPeer, conforme falamos acima.

Seguindo em frente, devemos definir o endereço do serviço, que na verdade será o nome da rede (mesh) que todos os clientes farão parte. Mantendo a mesma padronização imposta pelo WCF, aqui o endereço deverá ser prefixado com net.p2p, a na sequência o nome do serviço. Um pouco mais abaixo, temos a configuração do binding, definindo a porta em que as mensagens serão processadas. Definindo a porta 0 (zero), fará com que o WCF escolha uma porta que não esteja sendo utilizada no momento.

Por fim, e não menos importante, temos o resolver. Como o próprio nome diz, o resolver é o responsável por manter e resolver os IDs daqueles que estão conectados na rede. Quando o canal é aberto, o WCF utiliza o resolver para resolver o ID daqueles que estão conectados à rede, e assim criar uma rede com pontos interconectados. O atributo mode define qual modelo de resolver será utilizado, e você pode escolher uma em três opções, que estão definidas através do enumerador PeerResolverMode, que estão listados abaixo:

• Pnrp: Utiliza o padrão PNRP (Peer Name Resolution Protocol), que é um protocolo desenvolvido pela Microsoft que habilita a publicação e resolução dinâmica de nomes.
• Custom: Com esta opção, você pode criar um serviço para a resolução de nomes e IDs daqueles que estão envolvidos na rede. Um exemplo mais detalhado será mostrado abaixo.
• Auto: Quando configurado com a opção Auto e houver um resolver customizado definido, ele será utilizado; caso contrário, tentará fazer uso do protocolo Pnrp.

Abaixo temos toda a configuração do arquivo App.config da aplicação. Note que neste primeiro momento, estamos utilizando o resolver definido como Pnrp:

<?xml version=”1.0″ encoding=”utf-8″ ?>
<configuration>
  <system.serviceModel>
    <client>
      <endpoint address=”net.p2p://servicos/chat”
                binding=”netPeerTcpBinding”
                bindingConfiguration=”bindingConfig”
                contract=”AplicacaoDeChat.IContrato”
                name=”ChatEndpoint”/>
    </client>
    <bindings>
      <netPeerTcpBinding>
        <binding name=”bindingConfig”
                 port=”0″>
          <security mode=”None” />
          <resolver mode=”Pnrp” />
        </binding>
      </netPeerTcpBinding>
    </bindings>
  </system.serviceModel>
</configuration>

Utilizar o PNRP parece ser a melhor alternativa, mas as vezes você está em um ambiente em que ele não é suportado, ou por algum motivo, você quer controlar como esse procedimento é realizado. Para isso que a opção Custom foi criada. Isso nos permitirá construir um serviço WCF, e lá customizar toda a regra de resolução de nomes/IDs.

Para essa customização ser feita, o primeiro passo é criar um serviço que fará essa tarefa. Felizmente o WCF já traz uma classe pronta, que corresponde ao serviço de resolução. Essa classe é chamada de CustomPeerResolverService, e implementa uma interface que define o seu contrato: IPeerResolverContract. Apesar de haver vários membros, essa interface fornece alguns principais métodos, que são autoexplicativos: Register, Resolve e Unregister. Caso essa implementação não te atenda, tudo o que você precisa fazer é criar a sua própria implementação, utilizando esta mesma interface.

Como ele será um serviço WCF puro, precisamos criar uma aplicação que sirva como hospedeira para ele, recorrendo ao ServiceHost. Note que logo abaixo temos o arquivo de configuração correspondente, que está expondo o serviço através do protocolo TCP:

CustomPeerResolverService cprs = new CustomPeerResolverService();

using (ServiceHost host = new ServiceHost(cprs, new Uri[] { }))
{
    cprs.Open();
    host.Open();

    Console.WriteLine(“[ Serviço de Resolução Ativo ]”);
    Console.ReadLine();
}

<?xml version=”1.0″ encoding=”utf-8″ ?>
<configuration>
  <system.serviceModel>
    <services>
      <service name=”System.ServiceModel.PeerResolvers.CustomPeerResolverService”>
        <endpoint address=”net.tcp://localhost:8282/prs”
                  binding=”netTcpBinding”
                  bindingConfiguration=”bindingConfig”
                  contract=”System.ServiceModel.PeerResolvers.IPeerResolverContract” />
      </service>
    </services>
    <bindings>
      <netTcpBinding>
        <binding name=”bindingConfig”>
          <security mode=”None”/>
        </binding>
      </netTcpBinding>
    </bindings>
  </system.serviceModel>
</configuration>

Quando este serviço estiver ativo, podemos definir o resolver customizado nas aplicações, e como já sabemos, devemos definir o atributo mode como Custom, e logo no interior do elemento resolver, especificarmos as configurações de acesso ao serviço de resolução, tais como o endereço, o binding e sua respectiva configuração. O código abaixo ilustra a mesma configuração que vimos acima, mas agora utilizando um resolver customizado ao invés do PNRP:

<bindings>
  <netPeerTcpBinding>
    <binding name=”bindingConfig”
             port=”0″>
      <security mode=”None” />
      <resolver mode=”Custom”>
        <custom address=”net.tcp://localhost:8282/prs”
                binding=”netTcpBinding”
                bindingConfiguration=”peerBindingConfig” />
      </resolver>
    </binding>
  </netPeerTcpBinding>
  <netTcpBinding>
    <binding name=”peerBindingConfig”>
      <security mode=”None” />
    </binding>
  </netTcpBinding>
</bindings>

Depois do resolver definindo (não importa qual modelo seja), chega o momento que criarmos a aplicação que fará uso deste tipo diferenciado de serviço. Como sabemos, não há um serviço rodando que podemos efetuar a referência. Tudo o que precisaremos fazer aqui é o “consumo direto”, criando manualmente as classes para efetuar essa comunicação.

Para o consumo, é necessário a criação de um canal de comunicação, e o responsável por isso é a classe ChannelFactory<TChannel>. Mas neste caso, o canal deverá ser duplex (bidirecional), o que nos obriga a utilizar uma factory especializada para esta situação, que é a classe DuplexChannelFactory<TChannel>. O construtor desta classe deve receber a instância da classe InstanceContext, que possui acesso à classe do lado do cliente que implementa a interface (contrato) de callback. Além dela, ainda é necessário apontar o nome do endpoint que está no arquivo de configuração, para que a factory possa criar os canais utilizando todas as configurações previamente estabelecidas.

Como estamos construindo um chat, estamos implementando o contrato de callback no próprio formulário. O método EnviarMensagem é o callback, que será disparado quando uma mensagem chegar, enquanto o método Enviar_Click é o tratador do evento Click do botão, que será disparado quando a aplicação desejar enviar uma mensagem. Abaixo temos o formulário já implementado, com algumas linhas de código omitidas por questões de espaço:

public partial class Conversacao : Form, IContrato
{
    private IContratoChannel channel;
    private string nomeDoUsuario;

    public Conversacao(string nomeDoUsuario)
    {
        InitializeComponent();

        this.nomeDoUsuario = nomeDoUsuario;

        this.channel = new DuplexChannelFactory<IContratoChannel>(
            new InstanceContext(this), “ChatEndpoint”).CreateChannel();
        this.channel.Open();
    }

    public void EnviarMensagem(string de, string mensagem)
    {
        this.Mensagens.Text += 
            string.Format(“{0}:{2}{1}{2}{2}”, de, mensagem, Environment.NewLine);
    }

    private void Enviar_Click(object sender, EventArgs e)
    {
        this.channel.EnviarMensagem(this.nomeDoUsuario, this.Mensagem.Text);
    }
}

Distribuindo as Mensagens

Aparentemente tudo funciona da forma correta, mas é importante ter cuidado com o modo em que as mensagens são enviadas para a rede. O P2P utiliza broadcast, ou seja, se uma aplicação mandar uma mensagem para a rede, todos os pontos que estiverem conectados, receberão a mesma. Na imagem acima temos a sensação de que somente as duas pessoas estão conversando, mas se uma outra instância desta mesma aplicação entrar no ar, ela também começará a receber as mensagens.

O WCF possui algumas formas para controlar a distribuição das mensagens entre os pontos que compõem a rede, onde a primeira é através de uma contagem e a segunda utilizando um filtro. No primeiro caso, podemos modificar o nosso contrato, criando ao invés de strings que representam as informações do mensagem, uma classe para incorporar todos os parâmetros necessários, e além disso, devemos incluir um novo campo para contabilizar o número de encaminhamentos que a mensagem deverá fazer.

Como a API que estamos utilizando abstrai grande parte da comunicação entre os pontos, podemos apenas incluir no contrato da mensagem um campo decorado com o atributo PeerHopCountAttribute, que será decrementado a cada ponto que ela for entregue, e quando atingir o número 0, por mais que existam ainda pontos, eles não receberão a respectiva mensagem. Abaixo temos a classe Mensagem com os campos que compõem a estrutura do negócio e um campo chamado Hops, que será utilizando apenas quando estiver sendo exposto através do binding NetPeerTcpBinding.

[MessageContract]
public class Mensagem
{
    [PeerHopCount]
    public int Hops;

    [MessageBodyMember]
    public string De;

    [MessageBodyMember]
    public string Para;

    [MessageBodyMember]
    public string Texto;
}

É importante dizer que o contrato que criamos acima (IContrato), também foi mudado para receber esta nova classe ao invés do parâmetros separados.

Para finalizar, podemos também fazer o uso de filtros, que permite criar alguma espécie de regra para entregar ou não a mensagem. Note que coloquei na classe Mensagem um campo chamado Para que não havia na implementação inicial. A finalidade deste campo é analisar se o ponto que está recebendo a mensagem é mesmo o usuário à qual se destina. Caso seja, entregaremos a mensagem e iremos parar a propagação para os pontos seguintes; caso contrário, não entregaremos e iremos optar por propagar a mensagem adiante.

A criação de um filtro consiste em implementar a classe abstrata PeerMessagePropagationFilter, que nos obriga a sobrescrever o método ShouldMessagePropagate. Esse método possui um parâmetro que corresponde a mensagem que está chegando e um segundo parâmetro do tipo PeerMessageOrigination, que determina se a origem dela é local ou remota. Esse parâmetro é útil para determinar se a mensagem partiu da própria aplicação, e que no nosso caso, deveremos entregar para ela própria para conseguir exibir o conteúdo na tela.

Esse método deve retornar uma das opções definidas no enumerador PeerMessagePropagation, que determinará se a mensagem deverá ser entregue apenas localmente, remotamente, ambos ou não deve fazer nada. Para exemplificar, abaixo temos a classe UserNameChatFilter, que analisará o conteúdo da classe Message que vem como parâmetro e determinará se ele deve ou não ser entregue para a aplicação local, olhando para a origem da mensagem e para o atributo Para do corpo da mensagem.

internal class UserNameChatFilter : PeerMessagePropagationFilter
{
    private string username;

    public UserNameChatFilter(string username)
    {
        this.username = username;
    }

    public override PeerMessagePropagation ShouldMessagePropagate(
        Message message, PeerMessageOrigination origination)
    {
        if (origination == PeerMessageOrigination.Local)
        {
            return PeerMessagePropagation.LocalAndRemote;
        }
        else
        {
            Mensagem temp =
                (Mensagem)TypedMessageConverter.Create(typeof(Mensagem), null).FromMessage(message);

            string to = temp.Para;
            return to == username ? PeerMessagePropagation.Local : PeerMessagePropagation.Remote;
        }
    }
}

Depois da classe criada, temos que adicioná-la à execução, e para isso vamos recorrer ao método GetProperty<T> da classe genérica DuplexChannelFactory<TChannel>. Esse método genérico é utilizado para extrair da channel stack, objetos que são específicos ao modelo de comunicação. Neste caso, vamos tentar recuperar o objeto PeerNode, que corresponde ao ponto atual. Essa classe possui uma propriedade chamada MessagePropagationFilter, que pode receber uma instância de alguma classe que implemente um filtro customizado (PeerMessagePropagationFilter), assim como fizemos acima. O código abaixo ilustra como acoplar o filtro à execução:

this.channel.GetProperty<PeerNode>().MessagePropagationFilter = 
    new UserNameChatFilter(nomeDoUsuario);

Com isso, ao enviar uma requisição para um usuário específico, o filtro entrará em ação, avaliando se deve receber a mensagem ou propagar para o próximo ponto existente na rede. Apesar de conseguirmos atingir o objetivo, talvez esse modelo não seja a melhor saída em algumas situações, inclusive aqui. Como na maioria das vezes queremos conversar com alguém específico, o melhor seria manter um contato direto, ao invés de inundar a rede em busca desta pessoa.

Conclusão: Apesar de mudar um pouco a forma de como se cria serviços WCF, vimos neste artigo que temos mais uma possibilidade de criar aplicações conectadas, que agora também nos permite usufruir de uma rede P2P utilizando um modelo se comunicação ligeiramente diferente do qual estamos habituados a trabalhar.

P2PComWCF.zip (24.53 kb)