Muitas vezes construímos serviços para que sejam consumidos por aplicações que estão hospedadas no mesmo local. Um exemplo é quando criamos esses serviços para expor alguma funcionalidade, e que sejam consumidos através do jQuery ou do Silverlight. Ambas tecnologias possuem bibliotecas que facilitam a comunicação com este tipo de serviço.

Mas isso tudo funciona muito bem enquanto os serviços que são acessados estão dentro do mesmo domínio. Se desejar consumir serviços que estão além do domínio de onde a aplicação está hospedada, teremos que recorrer a técnicas diferentes, dependendo da tecnologia que estamos utilizando. A finalidade do artigo é mostrar como devemos proceder para permitir o consumo em cada uma delas.

jQuery

Como sabemos, o jQuery é uma biblioteca que facilita várias tarefas em JavaScript, abstraindo grande parte da complexidade que teríamos se fossemos utilizar uma funcionalidade diretamente. Uma dessas abstrações é o consumo de serviços, como já detalhei neste outro artigo.

O consumo de serviços funciona bem desde que ele esteja debaixo do mesmo domínio da aplicação Web, que é aquela que consome o serviço. Se ele estiver além, então precisamos de alguma técnica para possibilitar que essa tarefa seja realizada. Uma opção seria a criação de um serviço nesta aplicação cliente, que serviria como um wrapper, e este por sua vez, consumiria diretamente o serviço, sem as imposições de chamada entre domínios que o navegador impõe. Com isso, o código JavaScript irá consumir este serviço local, que por sua vez, encaminharia a requisição para o serviço remoto.

Apesar desta técnica funcionar, ela acaba sendo uma solução ruim, já que teremos que envolver outros elementos para realizar uma tarefa relativamente simples. Felizmente o jQuery fornece nativamente o suporte a uma técnica conhecida como JSONP (JSON with Padding).

O seu funcionamento não é muito complicado. Como disse acima, requisições entre domínios não são permitidas, mas há uma única exceção: a tag , ou seja, podemos definir no elemento src (source) a URL para um recurso que está além do nosso domínio, que o navegador não irá proibir o acesso. O que o JSONP faz é justamente o uso dela, criando dinamicamente esta tag, e definindo no atributo src a URL do serviço que estamos tentando acessar.

Na verdade isso não funciona sozinho, ou seja, precisa de uma certa colaboração por parte do serviço, para que o cliente possa processar o resultado da forma correta. Além dos parâmetros que são exigidos pelo método do serviço, o jQuery inclui um parâmetro chamado callback, que é o nome de uma função criada temporariamente no cliente. Aqui entra em cena a infraestrutura do serviço, que deve ser capaz de retornar o resultado (dados) envolvido nesta função, e quando o mesmo chegar ao cliente, ele invocará para capturar o resultado e encaminhá-lo para o nosso código, e assim iremos manipular da forma que acharmos mais conveniente.

Para fazer tudo isso funcionar, precisamos nos atentar à alguns detalhes do lado do cliente e do lado do serviço. Do lado do cliente, tudo o que precisamos fazer é indicar para a API de AJAX do jQuery que ela deve utilizar JSONP. Para isso, devemos recorrer ao atributo dataType, que indica o tipo de dado/formato que você está esperando que o servidor te retorne. No nosso caso, vamos apontar jsonp, assim como é mostrado no código abaixo:

    function Recuperar() {
        $.ajax(
            {
                type: “GET”,
                url: “http://localhost:1446/ServicoDeUsuarios.svc/Recuperar”,
                data: “nome=Israel”,
                dataType: “jsonp”,
                contentType: “application/json”,
                success:
                    function (usuario) {
                        alert(usuario.Nome);
                    }
            }
        );
    }

Como já sabemos, o serviço também precisa colaborar com isso. Para que ele consiga gerar o resultado da forma que esperamos, precisamos efetuar uma configuração no binding. Para expor um serviço para clientes AJAX, o WCF fornece um binding chamado WebHttpBinding e, consequentemente, é ele mesmo que expõe uma propriedade chamada CrossDomainScriptAccessEnabled, que recebe um valor boleano indicando se o serviço poderá ou não ser invocado através de outros domínios. Quando definido como True (o padrão é False), ele retornará o resultado da forma que o JSONP espera, e com isso, a chamada será efetuada com sucesso. O código abaixo ilustra a configuração de um serviço que poderá ser invocado através de outros domínios:

<?xml version=”1.0″?>
<configuration>
  <system.web>
    <compilation debug=”true”
                 targetFramework=”4.0″ />
  </system.web>
  <system.serviceModel>
    <services>
      <service name=”Servico.ServicoDeUsuarios”>
        <endpoint address=””
                  binding=”webHttpBinding”
                  bindingConfiguration=”bindingConfig”
                  contract=”Servico.IContratoDeUsuarios” />
      </service>
    </services>
    <bindings>
      <webHttpBinding>
        <binding name=”bindingConfig”
                 crossDomainScriptAccessEnabled=”true” />
      </webHttpBinding>
    </bindings>
  </system.serviceModel>
</configuration>

Se monitoramos as requisições através de uma ferramenta como o Fiddler, podemos reparar o que acontece nos bastidores. Abaixo temos a requisição e a sua respectiva resposta, com alguns headers omitidos para tornar a leitura mais simples. Note que o fato de definirmos o atributo dataType como jsonp fez com que um parâmetro chamado callback fosse atribuído à coleção de querystrings da requisição. Em seguida, no corpo da resposta temos os dados gerados do lado do servidor envolvidos na função que foi gerada do lado do cliente.

[ Requisição ]
GET http://127.0.0.1:1446/ServicoDeUsuarios.svc/Recuperar?callback=jsonp1284996021792&nome=Israel HTTP/1.1
Accept: */*
Host: 127.0.0.1:1446
Connection: Keep-Alive

[ Resposta ]
HTTP/1.1 200 OK
Date: Mon, 20 Sep 2010 15:20:24 GMT
Content-Length: 51
Content-Type: application/x-javascript
Connection: Close

jsonp1284996021792({“Codigo”:123,”Nome”:”Israel”});

Silverlight

Serviços que são consumidos por clientes Silverlight também sofrem o mesmo problema quando precisam consumir serviços que estão além de seu domínio de origem. Como sabemos, uma aplicação Silverlight não funciona sozinha, ou seja, ela é sempre hospedada em uma aplicação Web normal, e consumir serviços que estão debaixo dessa aplicação, não haverá qualquer problema e nenhuma tarefa extra precisa ser realizada, já que esse tipo de comunicação é permitida.

Mas ao tentar consumir um serviço que está fora do domínio de origem da aplicação, então receberemos uma exceção do tipo CommunicationException, indicando que a chamada entre domínios não é permitida.

Para resolver este problema, temos que colocar um arquivo Xml no mesmo local onde o serviço encontra-se hospedado (no servidor remoto), indicando que este serviço poderá ser consumido pelo cliente A, B ou C, ou se desejar, por qualquer aplicação. O Silverlight pode trabalhar com dois tipos de arquivos: ClientAccessPolicy.xml ou CrossDomain.xml. O primeiro arquivo foi desenvolvido pela própria Microsoft, enquanto o segundo já é utilizado por aplicações Flash, e para reutilizar, a Microsoft também incorporou no Silverlight a capacidade de utilizar este mesmo arquivo, sem a necessidade de criar um segundo só para atender as requisições a partir de clientes Silverlight.

Quando a aplicação Silverlight for efetuar a requisição para um serviço, ela primeiramente tenta fazer o download do arquivo ClientAccessPolicy.xml no mesmo domínio do serviço; caso não encontre, então ela tentará efetuar o download do arquivo CrossDomain.xml, e se mesmo assim não encontrá-lo, então a exceção mencionada acima será disparada. Ao encontrar um destes dois arquivos, o Silverlight analisará se no seu conteúdo, existe uma entrada dizendo que o serviço pode ser consumido pela aplicação cliente em questão, e se puder, efetuará a chamada para o serviço.

Abaixo existe a estrutura do arquivo ClientAccessPolicy.xml, já configurado para permitir que somente uma determinada aplicação possa consumí-lo. E você pode elencar ali quantas aplicações quiser, e se desejar, pode colocar apenas uma única entrada, definindo o atributo uri como *, que determina que toda e qualquer aplicação poderá consumir os serviços que rodam naquele local.

<?xml version=”1.0″ encoding=”utf-8″?>
<access-policy>
  <cross-domain-access>
    <policy>
      <allow-from http-request-headers=”*”>
        <!–
            Habilitar para todos os clientes
            <domain uri=”*”/>
        –>
        <domain uri=”http://localhost:2611/&#8221; />
      </allow-from>
      <grant-to>
        <resource path=”/”
                  include-subpaths=”true”/>
      </grant-to>
    </policy>
  </cross-domain-access>
</access-policy>

Com tudo isso configurado, podemos ver na imagem abaixo a requisição procurando pelo arquivo acima, e depois de encontrado e analisado, procede para a chamada efetiva para o respectivo serviço:

Conclusão: Vimos no decorrer deste artigo as possibilidades que temos para permitir que um serviço WCF possa ser consumido através de domínios diferentes, algo que é cada vez mais comum em um mundo cada dia mais conectado.

ChamadasEntreDominios.zip (213.04 kb)

A criação de serviços WCF envolve a construção de um contrato (interface), e depois a classe que o representará. Em seguida, para podermos expor ele para que os clientes possam consumir, precisamos utilizar algum host. Isso exige a configuração dos endpoints, behaviors, bindings, etc., e isso pode ser feito de forma imperativa ou declarativa.

Se tivermos toda a implementação pronta (a interface do contrato e a classe do serviço), podemos recorrer à algumas ferramentas que o WCF fornece, evitando assim escrever código para hospedar e/ou consumir o serviço. Utilizando essas ferramentas nos permite avaliar o comportamento, talvez analisar a performance, e tudo isso, sem a necessidade de gastar tempo configurando o servidor (o IIS por exemplo) ou criar um código para consumir o serviço. Para nos auxiliar, temos três ferramentas, que estão descritas abaixo:

• Service Configuration Editor: Este editor fornece uma interface gráfica para efetuarmos a configuração do serviço WCF, e que resultará na criação ou edição de um arquivo de configuração (App.config ou Web.config). Ele exigirá que você informe em qual assembly está o serviço, identificará o(s) contrato(s) que ele implementa, e depois disso, você configura os endpoints, bindings, behaviors, etc., tudo de acordo com a sua necessidade.
• WCF Service Host: Este utilitário recebe como parâmetro o assembly que contém o serviço e seu contrato. Além disso, um segundo parâmetro (que também é obrigatório), é o arquivo com extensão *.config onde está contida todas as configurações daquele serviço.
• WCF Test Client: Este utilitário tem a finalidade de simular um cliente, para que você consiga efetuar o consumo do serviço sem a necessidade de criar uma aplicação para isso. Ele recebe como parâmetro o endereço do documento WSDL, e com isso, irá extrair todas as informações e criará um formulário para que possamos informar os eventuais parâmetros para as operações, e depois exibirá o resultado.

Essas ferramentas já são conhecidas. Quando você cria um projeto utilizando a template WCF Service Library, ao rodá-la, verá que ambos utilitários serão inicializados para testar o serviço. Através das imagens abaixo, podemos visualizar o serviço sendo configurado pelo Service Configuration Editor. Em seguida, ele sendo hospedado no WCF Service Host e, finalmente, o WCF Test Client que irá consumi-lo.

O editor nós podemos acessá-lo diretamente através do Visual Studio, clicando em cima do arquivo de configuração correspondente, e em seguida, na opção Edit WCF Configuration. Se quiser acessar diretamente, você pode recorrer ao menu Tools e depois WCF Service Configuration Editor. Já os outros utilitários estão disponíveis através do prompt de comando do próprio Visual Studio. Abaixo temos a utilização de cada um deles:

C:>WcfSvcHost /service:C:TempMeuServico.dll /config:C:TempMeuServico.dll.config
C:>WcfTestClient http://localhost:8383/?wsdl

É importante dizer que esses utilitários não funcionam em alguns cenários, como por exemplo, quando utilizamos callbacks. Neste caso, a única saída será recorrer a criação de um projeto para o consumo deste serviço.

O WCF fornece várias tipos de mensagens, e entre eles, temos as operações one-way. Esse tipo de operação deve ser utilizado quando o cliente não precisa de qualquer retorno (resultado ou erro), uma espécie de fire-and-forget.

Esse tipo de mensagem pode ter um comportamento estranho quando exposto através de um binding que suporte sessões nativamente, como é o caso do NetTcpBinding. O protocolo TCP estabelece um canal duplex entre o cliente e o serviço, mantendo uma espécie de conexão ativa, onde a qualquer momento um pode tranquilamente se comunicar com o outro.

É importante dizer que mensagens one-way não são assíncronas, mas o tempo de entrega é tolerável. O maior problema, do qual falava anteriormente, refere-se ao fechamento do proxy depois da mensagem one-way disparada ao destinatário, ou seja, quando invocamos a operação one-way, tão logo já conseguimos continuar trabalhando na aplicação cliente, mas se tentarmos fechar o proxy, ficaremos bloqueados até que a operação one-way seja completamente finalizada. Mas se a ideia é disparar e esquecer, porque eu preciso esperar, mantendo o proxy aberto até finalizar a operação?

Para ter o comportamento fire-and-forget a sério, uma das alternativas que temos é habilitar as mensagens (ou sessões) confiáveis. Isso tornará a comunicação entre as partes muito mais descritiva, onde além das mensagens normais, ainda haverão uma porção de outras mensagens que são geradas pelo protocolo WS-ReliableMessaging, indicando se a mensagem foi entregue, quando ela foi entregue e a ordem de chegada, permitindo ao cliente continuar sem a necessidade de esperar. Para habilitar as mensagens confiáveis, consulte este artigo.

Apesar disso funcionar, a comunicação entre as partes ficará bem mais volumosa, já que várias mensagens de infraestrutura serão trocadas para garantir a entrega da mensagem principal. Para evitar todo este overhead causado pelo protocolo WS-ReliableMessaging, podemos recorrer a construção de um binding customizado, empilhando os vários elementos para compor a comunicação via TCP, mas com um detalhe, que é a adição de um novo elemento, chamado de OneWayBindingElement. A adição deste elemento fará com que o canal de comunicação se comporte semanticamente como um fire-and-forget. O código abaixo ilustra o seu uso, via código imperativo e declarativo, respectivamente:

private static Binding CreateOneWayTcpBinding()
{
    BindingElementCollection currentElements = new NetTcpBinding().CreateBindingElements();
    BindingElementCollection bindingElements = new BindingElementCollection();

    bindingElements.Add(new OneWayBindingElement());

    foreach (BindingElement be in currentElements)
        bindingElements.Add(be);

    return new CustomBinding(bindingElements);
}

<system.serviceModel>
  <bindings>
    <customBinding>
      <binding name=”OneWayTcpBinding”>
        <oneWay />
        <binaryMessageEncoding />
        <tcpTransport />
      </binding>
    </customBinding>
  </bindings>
</system.serviceModel>

Só que utilizar este procedimento possui dois detalhes importantes: o primeiro é que ao configurá-lo, o canal somente permitirá a comunicação através do modelo one-way, e com isso, o contrato que você está expondo obrigatoriamente precisa definir todas as operações neste mesmo modelo. Se tiver qualquer operação neste contrato do tipo request/reply, ao tentar subir o serviço, você irá se deparar com uma exceção do tipo InvalidOperationException, indicando justamente isso. Se você conseguir garantir com que todas as operações sejam one-way, então utilizar esta técnica pode trazer uma grande melhora em performance, quando comparado à opção anterior.

O segundo detalhe é com relação ao modelo de gerenciamento de instância. Mesmo que você diga ao serviço que ele deve ser PerSession, ele não conseguirá manter a sessão, ou seja, terá o comportamento do modelo PerCall, pois cada chamada para uma operação one-way encerrará a “sessão”.

Quando recorremos à uma das templates para a construção de serviços WCF (WCF Service Application ou WCF Service), ambas utilizam arquivos *.svc que representam o endpoint do serviço. Dentro deste arquivo temos apenas uma diretiva chamada @ServiceHost, que instrui o ASP.NET a como compilar o referido serviço.

Abaixo podemos visualizar um exemplo deste arquivo, que em seu atributo Service, permite apontar o tipo do serviço. Já no atributo CodeBehind, corresponde ao arquivo físico que possui a classe que representa o serviço e, finalmente, temos a atributo Factory, que é omitido por padrão, mas que tem a finalidade de criar instâncias da classe que gerencia o serviço (ServiceHost ou alguma de suas derivadas).

<%@ ServiceHost
    Language=”C#”
    Debug=”true”
    Service=”ServicoDeClientes”
    Factory=”System.ServiceModel.Activation.WebServiceHostFactory”
    CodeBehind=”~/App_Code/ServicoDeClientes.cs” %>

No WCF 4.0, a Microsoft incluiu a possibilidade de criarmos serviços WCF sem a necessidade da presença de um arquivo *.svc. Isso eliminará completamente a necessidade deste arquivo. Mas para poder excluir o arquivo, tudo o que precisamos fazer é elencar os serviços no arquivo Web.config, utilizando o sub-elemento serviceActivations, exposto pelo elemento serviceHostingEnvironment:

<system.serviceModel>
  <serviceHostingEnvironment>
    <serviceActivations>
      <add
        relativeAddress=”~/ServicoDeClientes.svc”
        service=”Servicos.ServicoDeClientes”
        factory=”System.ServiceModel.Activation.WebServiceHostFactory”/>
    </serviceActivations>
  </serviceHostingEnvironment>
</system.serviceModel>

Apesar de ainda precisar especifcar o arquivo no relativeAddress, ele não existe fisicamente. Note também que através do atributo service definimos o nome da classe que corresponde ao serviço e, finalmente, como já era de se esperar, podemos utilizar uma factory específica, que já configura o host com tudo o que é necessário para prepará-lo para receber e processar as requisições para uma determina situação. Com isso temos uma aplicação mais simples, onde tudo o que precisamos desenvolver é o contrato (interface) e o serviço (classe), assim como já fazemos com qualquer outro tipo de serviço WCF.

O maior problema desta técnica é a necessidade de ainda precisar informar a extensão do arquivo quando for efetuar uma requisição, e isso não é legal em um modelo REST. Lembre-se de que a funcionalidade que vimos acima, apenas elimina a necessidade do arquivo físico. Remover a extensão *.svc do atributo relativeAddress, não resolverá, pois vamos nos deparar com uma exceção do tipo ConfigurationErrorsException, dizendo que o valor informado no atributo relativeAddress não possui uma extensão válida.

Além do Url Rewrite Module (que já discuti no final deste artigo), temos agora a possibilidade de integrar o sistema de roteamento de URL do ASP.NET aos serviços WCF. Também na versão 4.0 do WCF, a Microsoft incluiu no assembly System.ServiceModel.Activation uma classe chamada ServiceRoute, que permite especificarmos exatamente os mesmos parâmetros que vimos acima e, automaticamente, será processado pelo handler correspondente (ServiceRouteHandler). Com isso, no evento Application_Start do arquivo Global.asax, devemos registrar mais uma rota, essa específica para o nosso serviço:

protected void Application_Start(object sender, EventArgs e)
{
    RouteTable.Routes.Add(
        new ServiceRoute(
            “ServicoDeClientes”,
            new WebServiceHostFactory(), 
            typeof(Servicos.ServicoDeClientes)));
}

A string que aparece sendo informada no construtor da classe ServiceRoute, define o nome do recurso para qual estaremos efetuando o roteamento. Os outros dois parâmetros refletem as mesmas configurações que vimos acima. Mas ainda é precisa se atentar a um detalhe: se você estiver utilizando um projeto que não vem com o módulo de roteamento de URL configurado, você terá que fazer isso manualmente, assim como eu mostro abaixo:

<system.web>
  <httpModules>
    <add
      name=”UrlRoutingModule”
      type=”System.Web.Routing.UrlRoutingModule, System.Web” />
  </httpModules>
</system.web>

O único detalhe aqui é a necessidade de habilitar o modelo de compatibilidade com o ASP.NET, caso contrário, esta funcionalidade não poderá ser utilizada. Para habilitar isso no contrato, precisamos recorrer ao atributo AspNetCompatibilityRequirementsAttribute, definindo-o como Allowed (para permitir que ele seja exposto por outros tipos de hosts), e depois devemos habilitar a compatibilidade no arquivo de configuração, através do elemento serviceHostingEnvironment, definindo o atributo aspNetCompatibilityEnabled como True. Abaixo é exibido as duas configurações:

namespace Servicos
{
    [AspNetCompatibilityRequirements(
        RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]
    public class ServicoDeClientes : IServico
    {
        //…
    }
}

<system.serviceModel>
  <serviceHostingEnvironment aspNetCompatibilityEnabled=”true” />
</system.serviceModel>

Depois destas configurações, já podemos acessar o serviço diretamente sem informar a extensão *.svc. É importante dizer que isso só é necessário quando você hospeda o seu serviço no IIS, já que as requisições são sempre realizadas para um arquivo físico. Quando você cria um serviço REST e deseja expor através de algum outro host, nada disso será necessário.

Ao criar um serviço WCF para ser acessado através do modelo REST, devemos decorar as operações que o compõem o contrato com os atributos WebGetAttribute ou WebInvokeAttribute, dependendo de como as requisições devem chegar até elas.

As requisições para estas operações podem ser enviadas e recebidas através de dois formatos: Xml ou Json, e para configurar isso, podemos recorrer à duas propriedades fornecidas pelos dois atributos listados acima. Essas propriedades são: RequestFormat e ResponseFormat, onde ambas recebem uma das opções expostas pelo enumerador WebMessageFormat.

Isso quer dizer que devemos definir, de forma estática, o formato que a mensagem será aceita e como ela será devolvida para os clientes. O grande problema desta técnica é que as vezes você pode ter um mesmo serviço sendo consumindo por clientes diferentes, que lidam melhor com um formato específico. Por exemplo, você pode ter um mesmo serviço sendo consumido por uma aplicação Silverlight, que possui um suporte melhor ao Xml, e ao mesmo tempo, o mesmo serviço sendo consumido por um código jQuery, que lida melhor com o formato Json. Para tornar o serviço flexível, tínhamos que fazer isso de forma imperativa, ou seja, dentro da implementação da operação, tínhamos que validar qual o formato desejado pelo cliente, e com isso especificar no contexto da requisição qual o formato que deve ser utilizado pelo runtime do WCF para gerar o resultado. O código abaixo ilustra de forma resumida essa condição:

public class Servico : IContrato
{
    public string Ping(string value)
    {
        WebOperationContext.Current.OutgoingResponse.Format =
            VerificarFormato(…) == “json” ? WebMessageFormat.Json : WebMessageFormat.Xml;

        return “resultado da operação”;
    }
}

Geralmente o formato é fornecido por uma query string adicional ou analisando os headers da requisição HTTP, que informa o formato através do content-type. O código acima permite definirmos o formato da resposta baseando-se na preferência do usuário, mas como podemos perceber, há muito código para avaliar isso, e me obriga a misturar a minha implementação com código de infraestrutura.

Para facilitar, a Microsoft criou na versão 4.0 do WCF, uma nova propriedade na classe WebHttpBehavior, chamada AutomaticFormatSelectionEnabled. Trata-se de uma propriedade boleana, que quando definida como True, irá interpretar a requisição e gerar a resposta no mesmo formato estipulado pelo cliente, olhando para a propriedade content-type que está nos presente nos headers da requisição. Para habilitar, podemos recorrer ao seguinte código:

<?xml version=”1.0″?>
<configuration>
  <system.serviceModel>
    <services>
      <service name=”Service”>
        <endpoint
          address=””
          binding=”webHttpBinding”
          contract=”IService”
          endpointConfiguration=”edpConfig” />
      </service>
    </services>
    <behaviors>
      <endpointBehaviors>
        <behavior name=”edpConfig”>
          <webHttp automaticFormatSelectionEnabled=”true” />
        </behavior>
      </endpointBehaviors>
    </behaviors>
  </system.serviceModel>
</configuration>

Com esta opção habilitada, meu contrato fica totalmente independente do formato, ou seja, se o cliente está requisitando em formato Json, o WCF será capaz de acatar a requisição, processá-la e devolver o resultado no mesmo formato. O mesmo acontece com o Xml. Finalmente, você pode ter um único serviço sendo capaz de receber e retornar mensagens no mesmo formato do cliente, não os obrigando mais ele a trabalhar com o formato específico, que as vezes diferente daquele que é o mais comum.

Há algum tempo eu mostrei aqui como podemos proceder para detectar a desconexão do cliente de um serviço WCF. Aquela solução tem a finalidade de detectar a desconexão do cliente ao tentar enviar um callback para ele, onde podemos analisar o estado do canal de comunicação com o mesmo, e se estiver em estado falho ou se já foi fechado, podemos desprezar a notificação.

O problema daquela técnica é que o serviço somente saberá que o cliente não está mais ativo, quando tentarmos acessar o canal para se comunicar com ele. Se o cliente já encerrou a aplicação, de forma normal ou não (matando o processo), a referência dele ainda existirá dentro do nosso serviço.

Para sermos notificados de que o cliente foi encerrado, novamente, de forma normal ou não, podemos recorrer à implementação da interface IInputSessionShutdown. Para bindings que suportam sessões, essa interface pode ser aplicada ao runtime, e sermos notificados quando o cliente encerrar a conexão com o serviço. Essa interface fornece dois métodos: DoneReceiving e ChannelFaulted. O primeiro método é disparado quando o cliente não puder mais receber as notificações, pois ele encerrou o canal de comunicação com o serviço; já o método ChannelFaulted é disparado quando o canal de comunicação do cliente entra em estado falho, ou seja, algum problema ocorreu na aplicação consumidora do serviço, que não foi capaz de encerrar o proxy de forma explicíta. Abaixo temos uma implementação simples deste recurso:

public class SessionShutdownTrigger : IInputSessionShutdown
{
    public void ChannelFaulted(IDuplexContextChannel channel)
    {
        Console.WriteLine(“ChannelFaulted”);
    }

    public void DoneReceiving(IDuplexContextChannel channel)
    {
        Console.WriteLine(“DoneReceiving”);
    }
}

Como podemos notar, ambos métodos recebem como parâmetro um objeto que implementa a interface IDuplexContextChannel, que corresponde ao canal de comunicação do cliente. Com esta classe criada, precisamos acoaplá-la ao runtime do WCF, e para isso recorremos aos pontos de estensibilidade que o WCF fornece, mais precisamente, ao uso da interface IContractBehavior, que nos permite modificar, examinar ou estender aspectos pertinentes à um contrato. Ao implementar essa interface, entre os vários métodos que ela fornece, temos o método ApplyDispatchBehavior, que nos permite interceptar e aplicar algum recurso customizado ao dispatcher do serviço. Justamente por isso, como parâmetro recebemos uma instância da classe DispatchRuntime, que por sua vez, fornece uma propriedade chamada InputSessionShutdownHandlers, que nos permite adicionar instâncias de classes que implementam a interface IInputSessionShutdown. O código abaixo ilustra essa classe:

public class SessionShutdownTriggerBehaviorAttribute : Attribute, IContractBehavior
{
    public void ApplyDispatchBehavior(ContractDescription contractDescription,
        ServiceEndpoint endpoint, DispatchRuntime dispatchRuntime)
    {
        dispatchRuntime.InputSessionShutdownHandlers.Add(new SessionShutdownTrigger());
    }

    //Outros Métodos
}

Essa classe por si só não funciona. Note que ela herda da classe Attribute, que me permite decorar a classe que representa o serviço, e com isso, ao rodá-lo, o WCF será capaz de perceber a presença deste atributo, e executar o método ApplyDispatchBehavior, incluindo a instância da classe SessionShutdownTrigger que criamos acima e, finalmente, quando a cliente encerrar o canal de comunicação, seremos notificados que isso ocorreu, e podemos executar algum código pertinentes aquele cliente, sem a necessidade de somente detectarmos isso quando precisarmos efetivamente comunicar com ele. Abaixo temos o contrato do serviço com esse atributo decorado:

[SessionShutdownTriggerBehavior]
public class Servico : IContrato
{
    public string Ping(string value)
    {
        return value;
    }
}