Uma questão que sempre é levantada quando falamos de contratos de serviços WCF, refere-se ao compartilhamento dos tipos que são expostos pelo documento WSDL. Para retornar e/ou receber uma instancia de uma classe customizada, basta referenciarmos este tipo em um contrato que, automaticamente, ele já será embutido no documento WSDL. Com isso, ao referenciar o serviço no cliente, uma representação desta classe será criada para que seja possível enviar e/ou receber uma instancia deste objeto complexo.

Durante a referencia (independentemente de qual artefato é utilizado para realizá-la (através da IDE ou utilitário svcutil.exe)), ele olhará para o projeto onde o serviço está sendo referenciado, para determinar se o tipo que o serviço expõe/retorna já existe dentro do mesmo. Caso ele não exista, automaticamente uma classe será criada para representá-la que, obviamente, será baseada no documento WSDL. Essa técnica fornece um baixo acoplamento, assim como já era o caso dos ASP.NET Web Services (ASMX).

Como sabemos, a serialização apenas persiste o estado de um objeto. Isso quer dizer que possíveis métodos e/ou atributos especiais não são propagados através deste processo. Há casos em que se quer compartilhar não somente o estado de um objeto, mas também outras funcionalidades que o mesmo forneça, e que está além das capacidades do processo de serialização.

É neste cenário que o compartilhamento de tipos entra em cena. Isso deve mudar ligeiramente a estrutura das aplicações, ou seja, o tipo a ser compartilhado entre o serviço e o cliente deverá ser isolado em um Assembly (DLL), referenciado pelas duas aplicações. O contrato do serviço agora passará a receber e enviar instancias da classe que está neste Assembly compartilhado e com isso, ao invés de criar uma nova classe para representar o objeto, a IDE (ou o utilitário svcutil.exe) irá fazer o uso deste tipo que, além do estado das propriedades que foram fornecidas pelo serviço, temos todas as possíveis funcionalidades que este objeto fornece. Ao contrário do que vimos acima, esta técnica traz um forte acoplamento entre os envolvidos, bem como já acontecia com o .NET Remoting, obrigando as “duas pontas” serem WCF.

A vantagem do compartilhamento é que a cada nova mudança no contrato, ou melhor, nas propriedades do objeto, não há necessidade de atualizar a referencia do serviço para que ele sincronize o objeto local com o objeto exposto pelo documento WSDL. Se todos os projetos estão dentro da mesma solução, basta uma simples compilação e tudo já estará funcionando. Esse comportamento melhora consideravelmente a produtividade e conveniencia durante o desenvolvimento do serviço e do cliente, enquanto o ponto negativo gira em torno da interoperabilidade e do acoplamento que se tem entre os participantes.

Uma necessidade existente em muitas aplicações é assegurar a consistência dos dados durante a sua manipulação. Ao executar uma tarefa, precisaremos garantir que, se algum problema ocorrer, os dados voltem ao seu estado inicial. Dentro da computação isso é garantido pelo uso de transações. As transações já existem há algum tempo, e a finalidade deste artigo é mostrar as alternativas que temos para incorporá-las dentro de serviços e clientes que fazem o uso do WCF como meio de comunicação.

Um exemplo clássico que demonstra a necessidade das transações é quando precisamos criar uma rotina de transferência de dinheiro entre duas contas. A transferência consiste basicamente em duas operações: sacar o dinheiro de uma conta e efetuar o depósito em outra. Caso algum problema ocorra entre o saque e o depósito e isso não estiver envolvido por uma transação, a conta de origem ficará sem o dinheiro e a conta destino não receberá a quantia, fazendo com que os dados envolvidos (saldo da conta de origem) fique em um estado inconsistente.

A definição de uma transação consiste em um conjunto de operações (muitas vezes complexas) que, caso alguma delas falhe, o processo como um todo deverá falhar, ou seja, uma operação atômica (ou tudo, ou nada). A atomicidade é uma das quatro características que toda transação deverá ter, a saber: Atomicidade, Consistência, Isolamento e Durabilidade (ACID). A consistência garante que, se alguma das operações que estiver envolvida em uma transação falhar, ela garantirá que os dados voltem ao seu estado inicial, ou seja, as mesmas informações antes da transação iniciar; já o isolamento garantirá que nenhuma outra entidade acessará os dados que estão sendo alterados durante a transação corrente, evitando que essas outras entidades acessem um valor que, talvez, não seja o valor final. Finalmente, e não menos importante, a durabilidade garante que uma vez que ela foi “comitada”, a transação será efetivamente persistida, resistindo a possíveis falhas na aplicação/banco de dados.

Tradicionalmente, as transações foram associadas aos banco de dados, mas elas podem ser aplicadas em uma série de operações que envolvem mudanças em dados. Atualmente a necessidade das transações vai além de garantir a consistência de registros de um banco de dados ou qualquer outro repositório. Com os serviços cada vez mais em evidência e sendo desenvolvido por muitas empresas para disponibilizar alguma funcionalidade, a necessidade de envolver a chamada à esses serviços em uma única operação transacionada fez com que as transações fossem implementadas de forma a garantir a propagação da mesma de uma forma genérica para diferentes serviços, processos, organizações e plataformas.

Como falado acima, uma transação é um conjunto de operações que, na maioria das vezes, envolvem recursos transacionais, como é o caso de banco de dados e até mesmo o Message Queue. Esses recursos transacionais são (devem ser) capazes de efetuar o commit ou rollback nas possíveis mudanças que foram feitas nos dados. Envolver um destes recursos em uma transação é chamado de enlistment; há também alguns recursos que conseguem detectar que estão sendo acessados por uma transação e, automaticamente, ele fará parte da mesma. Essa técnica é conhecida como auto-enlistment.

Dentro de uma transação, há sempre a aplicação que a inicia, conhecida como “coordenador”; já os demais são referenciados como “participantes”. A comunicação entre o coordenador e os demais participantes deve ser realizada de forma a garantir atomicidade quanto a consistência, como já falamos acima. Nesse contexto, isso é garantido através de um protocolo popularmente conhecido como two-phase commit protocol (2PC). Como o próprio nome diz, ele consiste basicamente em duas fases para garantir o commit ou rollback das informações, abstraindo toda a grande complexidade que existe por trás deste processo. Abaixo a descrição de cada uma dessas fases:

• Fase 1: Preparação. Nesta fase, todos os envolvidos (participantes) na transação enviam uma notificação para o coordenador da mesma, informando que ele está preparado para efetuar o commit ou rollback (voto).

• Fase 2: Commit ou Rollback. Ao coletar todos os votos (de commit ou rollback), o coordenador irá decidir o que deve ser feita. Se algum participante votou como rollback, então o coordenador irá notificar a todos os participantes para efetuar o rollback da transação; caso todos votem como commit, então o coordenador envia uma notificação para cada participante para efetivar as mudanças.

Observação: O estado dos dados entre a fase 1 e fase 2 é conhecido como in-doubt state. Como mencionado acima, o isolamento, uma das quatro características da transação, garantirá que essa informação não será acessada por nenhuma outra transação, fazendo com que não hajam inconsistências.

Os recursos transacionais estão divididos em duas categorias: duráveis (durable) e voláteis (volatile). Um recurso transacional durável é capaz de salvar a informação durante a fase 1 do protocolo two-phase commit e, mesmo que um problema ocorra na máquina e ela precisar ser reinicializada, ela poderá dar continuidade na transação (exemplo: Microsoft SQL Server). Já os recursos voláteis podem ser alistados para receberem notificações do protocolo two-phase commit, mas eles não resistirão aos possíveis problemas que possam acontecer, ou seja, eles não conseguem sobreviver à uma falha mais severa, como uma reinicialização do sistema. A criação de recursos voláteis está fora do escopo deste artigo mas, como referência, há classes e interfaces disponíveis dentro do Assembly System.Transactions que possibilitam a criação dos mesmos.

Ainda falando sobre as tecnologias que circundam as transações, temos os protocolos (aqui, a palavra protocolo se refere a forma de comunicação) que permitem que todo esse processo aconteça. Atualmente temos três diferentes protocolos, e cada um deles com uma finalidade diferente. Abaixo temos cada um deles com sua respectiva descrição:

• Lightweight: Esse é o protocolo mais performático em relação aos outros dois, mas tem uma limitação de que não pode propagar o contexto da transação fora do domínio da aplicação (AppDomain).

• OleTx: Ao contrário do Lightweight, o protocolo OleTx pode ser propagado através do domínio da aplicação (AppDomain), processos e máquinas. Por se tratar de um protocolo nativo do Windows, ele não pode ultrapassar firewalls ou mesmo interoperar com outras plataformas. Geralmente isso é utilizado em um ambiente de intranet e completamente homogêneo, onde essas “limitações” não são problemas.

• WS-Atomic Transaction (WS-AT): Esse protocolo é similar ao OleTx, podendo propagar entre domínio da aplicação (AppDomain), processos e máquinas, gerenciando o two-phase commit. A vantagem deste protocolo em relação ao anterior é que ele é baseado em um padrão aberto, podendo ser implementado por qualquer plataforma. Além disso, ele pode ser utilizado sob HTTP e na internet, atravessando possíveis firewalls existentes dentro da infraestrutura.

Finalmente, temos os gerenciadores de transações (Transaction Managers). Vimos resumidamente como funciona o two-phase commit e, felizmente, tudo o que precisamos fazer é dizer se deu certo ou não e ele se encarregará do resto. Mas afinal, quem gerencia tudo isso? Toda essa responsabilidade fica à cargo dos Transaction Managers. São eles quem alistam os recursos transacionais (banco de dados, message queues) dentro do ambiente transacional e fazem o uso de um dos protocolos acima para a determinar o commit ou rollback. Atualmente temos três gerenciadores de transação, a saber:

• Lightweight Transaction Manager (LTM): Este gerenciador somente é capaz de lidar com uma transação local, ou seja, dentro de um mesmo AppDomain. Ele utiliza o protocolo Lightweight para gerenciar o two-phase commit. Ele poderá gerenciar um único recurso durável e vários voláteis.

• Kernel Transaction Manager (KTM): O KTM, por sua vez, permite gerenciar recursos transacionais a nível de kernel (KRM), como é o caso do sistema de arquivos (TXF) e também do registry (TXR), fazendo o uso do protocolo Lightweight. Assim como o anterior, o KTM pode gerenciar um único recurso KRM e vários recursos voláteis. Somente suportado no Windows Vista.

• Distributed Transaction Coordinator (DTC): O DTC é o mais abrangente de todos. Ele é capaz de gerenciar uma transação sem um limite de escopo, ou seja, a transação poderá ser propagada entre vários AppDomains, diferentes processos e máquinas. Nativamente o DTC suporta o protocolo OleTx e, mais recentemente, ele foi adaptado para também suportar o protocolo WS-AT, pertindo à ele interoperabilidade com serviços e clientes não Microsoft.

Observação: Por padrão, o suporte ao protocolo WS-Atomic Transaction (WS-AT) no DTC vem desabilitado. Para que você consiga manipular essa configuração, primeiramente é necessário que você consiga visualizá-la e, para isso, é necessário executar a seguinte linha de comando (via prompt do Visual Studio .NET): regasm.exe /codebase wsatui.dll. Uma vez rodado este comando, você poderá ir até Control Panel, Administrative Tools, Component Services, Propriedades do Distributed Transaction Coordinator e verá a aba WS-AT a sua disposição, como é mostrado abaixo:

Transações no .NET 2.0

A partir da versão 2.0 do .NET Framework, a Microsoft introduziu um novo modelo de programação para suportar transações em código gerenciado. Trata-se do namespace System.Transactions (Assembly System.Transactions.dll). Este novo namespace traz vários tipos (classes, interfaces, etc.) para que você consiga manipular transações, alistar recursos duráveis ou voláteis e trabalhando com transações locais ou distribuídas.

Este novo modelo de programação permite ao desenvolvedor determinar uma seção (bloco) do código que será envolvido pela transação. Tudo o que você efetuar dentro deste bloco estará protegido por uma transação, ficando sob responsabilidade do desenvolvedor dizer se ela completou com sucesso para, posteriormente, ser “comitada”. Esse namespace já suporta o protocolo Lightweight Transaction Manager (LTM), promovendo-o de forma transparente para OleTx quando, por alguma limitação, o LTM não puder ser utilizado.

Uma das principais classes utilizadas é a classe TransactionScope. Essa classe é a responsável por determinar um bloco transacional dentro da aplicação. Geralmente, essa classe é criada e envolvida por um bloco using e, dentro dele, fazemos as chamadas para os recursos (banco de dados, message queues, etc.) que farão parte da transação. Uma vez que todas as tarefas concluírem com sucesso, você deve chamar o método Complete da classe TransactionScope; caso contrário, você apenas não deverá chamar este método e, automaticamente, o rollback acontecerá. O trecho de código abaixo ilustra um exemplo de como utilizá-la:

TransactionOptions opts = new TransactionOptions();
opts.IsolationLevel = IsolationLevel.ReadCommitted;
opts.Timeout = TimeSpan.FromMinutes(1);

using (TransactionScope ts = 
    new TransactionScope(TransactionScopeOption.RequiresNew, opts))
{
    Message msg = RecuperarMensagem();
    if (msg != null)
        InserirMensagemNoBancoDeDados(msg);

    ts.Complete();
}

É importante notar que se por algum problema uma exceção ocorrer durante a execução do método RecuperarMensagem ou InserirMensagemNoBancoDeDados, o método Complete não será disparado e, conseqüentemente, será feito o rollback de forma automática (neste caso, a verificação é efetuada dentro do método Dispose, o qual sempre será invocado). Já se ambos os métodos não disparar nenhuma exceção, o método Complete será chamado, e todas as modificações serão efetivadas.

Os recursos fornecidos para manipular transações não param por aqui. Há várias funcionalidades a disposição, como o caso da criação e alistamento de recursos voláteis mas, infelizmente, estão fora do escopo deste artigo. Caso queira saber sobre mais detalhes sobre como funcionam as transações dentro do .NET, então você pode recorrer a documentação deste namespace direto do MSDN.

Utilizando transações no WCF

Como os serviços vem ganhando cada vez mais espaço e uma das principais necessidades que eles têm é justamente a necessidade de envolvê-lo em uma transação, fazendo com que ele seja um coordenador ou participante de um processo transacional. Felizmente, a Microsoft se preocupou com isso e disponibilizou através de classes e atributos uma série de funcionalidades dentro do WCF para manipular transações.

É importante dizer que o suporte e configuração das transações são características do binding, ou seja, será o binding que determinará o suporte ou não à transação, definindo sob qual dos protocolos (WS-AT ou OleTx) a transação será exposta. Opcionalmente, o binding também poderá definir um timeout e a propagação das mesmas do cliente para o serviço (será abordado mais tarde, ainda neste artigo). Assim como quase todas as funcionalidades no WCF, a configuração das transações pode ser feita de forma imperativa ou declarativa.

Como tudo se inicia pelo contrato, então é ele que vamos inicialmente criar. Ele terá dois simples métodos: Adicionar e Recuperar, onde o primeiro deles deverá ser envolvido por uma transação e o segundo não. Note que o código abaixo ilustra a estrutura do contrato, mas sem nenhuma configuração de transação; o WCF desacopla a configuração da transação da definição do contrato (salvo uma, que será abordada mais adiante), sendo o desenvolvedor obrigado a configurar isso na implementação, através de behaviors.

using System;
using System.ServiceModel;

[ServiceContract]
public interface IUsuarios
{
    [OperationContract]
    bool Adicionar(string nome);

    [OperationContract]
    string[] Recuperar();
}

Uma vez implementado este contrato em uma classe que representará o serviço, o primeiro passo é determinar se uma operação deverá ou não executar em um ambiente transacionado que, por padrão, está desabilitado e, neste caso, mesmo que uma transação seja propagada do cliente para o serviço, ela será ignorada. Para habilitar o uso da transação em uma operação, basta recorrermos a propriedade TransactionScopeRequired do atributo OperationBehaviorAttribute, definindo-a como True, como é mostrado através do exemplo de código abaixo:

[ServiceBehavior(
    TransactionTimeout = "00:02:00"
    , TransactionIsolationLevel = IsolationLevel.ReadCommitted)]
public class ServicoDeUsuarios : IUsuarios
{
    [OperationBehavior(TransactionScopeRequired = true)]
    public bool Adicionar(string nome)
    {
        //implementação

        return true;
    }

    [OperationBehavior(TransactionScopeRequired = false)]
    public string[] Recuperar()
    {
        //implementação

        return null;
    }
}

Opcionalmente, você poderá definir, através do atributo ServiceBehaviorAttribute, um timeout e o nível de isolamento. O timeout, especificado a partir da propriedade TransactionTimeout (Timespan), especificará o período entre a criação e a finalização (com commit ou rollback) da transação. Caso ela não seja completada até o tempo especificado nesta propriedade, a transação será automaticamente abortada. Já o nível de isolamento, definido através da propriedade TransactionIsolationLevel, receberá uma das opções especificadas no enumerador IsolationLevel, que está contido no namespace System.Transactions e, quando não especificado, a opção Serializable é utilizada. Como os dados que são modificados pela transação são considerados in-doubt, é através do nível de isolamento que determinará se essas mudanças poderão ou não ser acessadas antes da transação ser concluída. É importante dizer que ambas as propriedades afetam diretamente todas as operações que tiverem a propriedade TransactionScopeRequired definida como True. No código acima, apenas o método Adicionar será envolvido em um contexto transacional. Explicitamente definimos a propriedade TransactionScopeRequired para False no método Recuperar, mas lembre-se de que ocultando este atributo iremos obter o mesmo resultado, ou seja, a operação não será transacionada. Para sabermos se a transação foi ou não criada, podemos recorrer à classe Transaction, uma das principais classes do namespace System.Transactions. Essa classe fornece uma propriedade estática chamada Current, que retorna uma instância da classe Transaction, representando a transação corrente e, quando o retorno estiver vazio, então nenhuma transação foi criada.

Se o método suportar transação e ela estiver criada, automaticamente, qualquer recurso transacional que você acesse dentro desta operação, automaticamente será alistado (auto-enlistment) e, com isso, toda e qualquer manipulação será gerenciada pela transação. Isso quer dizer que não há necessidade de escrevermos código para criar a transação, pois o WCF já garante isso; independentemente da transação criada pelo WCF, você pode perfeitamente, dentro do método, criar um bloco transacional através da classe TransactionScope, que um dos seus construtores aceita uma das opções especificadas no enumerador TransactionScopeOption, que permite “interagir” com o ambiente transacionado existente. Os possíveis valores são:

• Required: Uma transação é requerida. Caso a transação exista, o processo fará parte dela; do contrário, uma nova transação será criada.

• RequiredNew: Uma nova transação é requerida. Independentemente se existe ou não uma transação, sempre será criada uma nova.

• Suppress: Não é necessário uma transação. Independentemente se existe ou não uma transação, a tarefa não será envolvida em um ambiente transacionado.

O exemplo abaixo exibe como podemos proceder para suprimir uma transação dentro de um método que solicitou uma transação ao WCF. Notem que apenas uma parte do método será suprimido, não influenciando no voto da transação (commit ou rollback).

[ServiceBehavior(
    TransactionTimeout = "00:02:00"
    , TransactionIsolationLevel = IsolationLevel.ReadCommitted)]
public class ServicoDeUsuarios : IUsuarios
{
    [OperationBehavior(TransactionScopeRequired = true)]
    public bool Adicionar(string nome)
    {
        //operações

        using (TransactionScope scope = 
            new TransactionScope(TransactionScopeOption.Suppress))
        {
            //bloco não transacionado
        }

        return true;
    }
}

Efetuando o Voto

Uma vez que sabemos como configurar uma operação para suportar transações, precisamos agora saber como proceder para aplicar o voto, ou seja, dizer ao runtime se a transação foi completada com sucesso ou se alguma falha ocorreu. Há duas formas de efetuar o voto: declarativa (via atributos) ou imperativa (via código).

No modo declarativo devemos utilizar a propriedade TransactionAutoComplete, exposta também pelo atributo OperationBehaviorAttribute. Essa propriedade, do tipo booleana (o padrão é True), quando definida como True, determinará que, se nenhuma exceção não tratada ocorrer durante a execução da operação/método, a transação deverá ser marcada como “completada” quando o método retornar; se por algum motivo alguma exceção acontecer, a transação será abortada. Quando esta propriedade estiver definida como False, o comportamento é um pouco diferente, ou seja, a transação ficará vinculada à instância do serviço (*) e somente será marcada como “completada” se o cliente efetuar uma nova chamada para um método que também tenha esta propriedade definida como True ou quando invocamos o método SetTransactionComplete.

(*) Isso obrigará o serviço ser definido como PerSession.

A utilização do método estático SetTransactionComplete, definido na classe OperationContext, se faz necessária quando a propriedade TransactionAutoComplete estiver definida como False. A idéia aqui é permitir ao desenvolvedor determinar quando é o momento apropriado para marcar a transação como “completada”. Isso dá uma flexibilidade maior, pois nem sempre será uma exceção que determinará se a transação deverá ou não ser abortada. O exemplo abaixo ilustra como podemos fazer o uso deste método:

[ServiceBehavior(
    TransactionTimeout = "00:02:00"
    , TransactionIsolationLevel = IsolationLevel.ReadCommitted)]
public class ServicoDeUsuarios : IUsuarios
{
    [OperationBehavior(TransactionScopeRequired = true, TransactionAutoComplete = false)]
    public bool Adicionar(string nome)
    {
        if (true)
        {
            AdicionarNoBancoDeDados(nome);
            if(NotificarGerentes(nome))
            {
                OperationContext.Current.SetTransactionComplete();
                return true;
            }
        }

        return false;
    }
}

Como podemos notar no código acima, a propriedade TransactionAutoComplete está definida como False e, neste caso, compete ao desenvolvedor determinar quando a transação deverá ser “completada”. Já dentro do método, quando a inserção no banco de dados acontecer e, se o método NotificarGerentes for efetuado com sucesso, o método SetTransactionComplete será invocado. Caso a notificação para os gerentes não aconteça, o método SetTransactionComplete não será invocado e, quando o método Adicionar retornar, a transação será abortada.

Observação: Se ao chamar o método SetTransactionComplete e não houver um ambiente transacional, uma exceção do tipo InvalidOperationException será disparada.

Propagando as Transações

Pelo fato de todas as configurações serem server-side (via behaviors), elas afetam apenas a implementação e execução do serviço, e os clientes não sofrerão nenhuma mudança. Mas e, se por acaso, quisermos que o cliente também seja envolvido na transação? Para isso, o WCF fornece uma característica interessante chamada de propagação da transação.

A propagação da transação permitirá ao cliente do serviço encaminhar uma transação existente, fazendo com que a execução da operação também faça parte dela, ao invés do WCF criá-la. A configuração para suportar a propagação está definida em dois lugares: no contrato e no binding. A configuração do contrato irá garantir que o serviço seja exposto sob um binding que suporte essa característica, apenas isso. A configuração no contrato é definida através do atributo TransactionFlowAttribute que, em seu construtor, deve receber uma das três opções definidas pelo enumerador TransactionFlowOption:

• Allowed: Esta opção permite à execução da operação fazer parte da transação do cliente, caso exista; do contrário, o WCF criará uma nova transação.

• NotAllowed: Ao contrário da opção anterior, NotAllowed sempre rejeitará qualquer transação criada pelo cliente, fazendo com que o WCF sempre crie uma nova transação. Este é o valor padrão.

• Mandatory: Como o próprio nome diz, esta opção obriga o cliente a criar uma transação e propagá-la para o serviço como parte da requisição. Caso isso não aconteça, uma exceção será disparada.

O código a seguir exibe o mesmo contrato criado acima (IUsuarios), mas com as devidas mudanças para configurar a propagação da transação do cliente para o serviço. Para fins de exemplos, vamos definir como Mandatory, obrigando o cliente sempre a criar a transação:

using System;
using System.ServiceModel;

[ServiceContract]
public interface IUsuarios
{
    [OperationContract]
    [TransactionFlow(TransactionFlowOption.Mandatory)]
    bool Adicionar(string nome);

    [OperationContract]
    string[] Recuperar();
}

Ao definir, no mínimo, uma das operações como Mandatory, durante a carga do serviço o WCF irá analisar se o binding está permitindo a propagação da transação. Caso não esteja, uma exceção do tipo InvalidOperationException será disparada, informando que isso não é permitido. Os bindings que suportam a propagação da transação fornecem uma propriedade chamada TransactionFlow, que recebe um valor booleano (que, por padrão, é False), indicando se isso será ou não permitido. Além disso, é importante dizer que, quando essa propriedade for definida como True, refletirá no documento WSDL do serviço.

Como estamos falando sobre bindings é importante mencionar que, além de determinar se podem ou não propagar as transações, podemos definir qual o protocolo que ele deverá utilizar. Obviamente que nem todos os protocolos poderão ser utilizados por todos bindings, justamente pelo fato do escopo de utilização de cada um. Bindings como NetTcpBinding e NetNamedPipeBinding suportam tanto o protocolo WS-AT ou OleTx; já os bindings de internet (WSHttpBinding, WSDualHttpBinding e WSFederationHttpBinding) apenas podem expor as transações através do protocolo WS-AT. Apenas para constar, o binding BasicHttpBinding não suporta transações.

Pelo fato dos bindings NetTcpBinding e NetNamedPipeBinding suportarem dois protocolos diferentes, eles expõem uma propriedade chamada TransactionProtocol, onde podemos definir qual dos protocolos utilizar. Para efetuar essa configuração, basta escolher uma das proriedades estáticas da classe TransactionProtocol, que retornará uma instância desta mesma classe, devidamente configurada para tal protocolo. O código abaixo ilustra a configuração de um host, exibindo a customização para o suporte a transações:

using (ServiceHost host = 
    new ServiceHost(typeof(ServicoDeUsuarios),
    new Uri[] { new Uri("net.tcp://localhost:9393") }))
{
    NetTcpBinding tcp = new NetTcpBinding();
    tcp.TransactionFlow = true;
    tcp.TransactionProtocol = TransactionProtocol.WSAtomicTransactionOctober2004;

    host.AddServiceEndpoint(
        typeof(IUsuarios), 
        tcp, 
        "srv");

    host.AddServiceEndpoint(
        typeof(IMetadataExchange), 
        MetadataExchangeBindings.CreateMexTcpBinding(), 
        "mex");

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

Com essa configuração, o cliente será obrigado a criar uma transação antes de efetivamente invocar a operação e, caso ele não informe, uma exceção do tipo ProtocolException será disparada. A configuração acima é feita de forma imperativa, mas é perfeitamente possível fazer a mesma configuração de forma declarativa. Quando o cliente também for .NET/WCF, podemos utilizar a classe TransactionScope para criar um bloco transacional e, com isso, ao efetuar a chamada de uma operação dentro do bloco transacional, automaticamente ela será propagada para o serviço. O exemplo abaixo ilustra superficialmente como podemos proceder para criar a transação do lado do cliente. Note que nenhuma configuração extra é necessária.

using System;
using System.Transactions;

using (UsuariosClient proxy = new UsuariosClient())
{
    using (TransactionScope scope = new TransactionScope())
    {
        Console.WriteLine(proxy.Adicionar("Israel"));
        scope.Complete();
    }
}

Observação: Quando o serviço for referenciado através do Visual Studio ou quando utilizamos o utilitário svcutil.exe para gerar o proxy, a propriedade TransactionFlow do binding já é configurada como True e o contrato já terá o atributo TransactionFlowAttribute definido, respeitando a mesma configuração do serviço, e tudo isso garantirá que o cliente propague (ou não) a transação para o serviço.

Transações e o Gerenciamento de Instâncias

Um dos grandes desafios das transações é justamente manter a consistência dos dados que ela manipula entre o ínicio e o fim da mesma. As informações manipuladas vão desde dados em banco de dados (o mais convencional) até variáveis de memória e, em ambos os casos, é necessário que eles fiquem em formato consistente.

A escolha do modo de gerenciamento de instâncias (discutido neste artigo) influencia drasticamente no comportamento das transações. O modo PerCall é o mais ideal para suportá-las, já que a transação será finalizada quando a instância do serviço for finalizada. No modo PerCall, para cada chamada de uma operação (transacionada ou não), uma nova instância será criada para serví-la, mantendo a consistência inicial das informações. Depois do retorno do método e antes da desativação da instância, o WCF irá finalizar a transação, efetuando o commint ou abort.

O gerenciamento das transações começa a ficar um pouco mais complicado quando o serviço é exposto através do modo PerSession (que é o padrão), fazendo com que uma instância sobreviva entre as chamadas. Uma vez que o cliente efetua a conexão com um serviço deste tipo, a instância viverá enquanto a instância do cliente (proxy) exista. Um cuidado extra deve ser tomado neste cenário, devido ao fato que isso poderá quebrar duas das características das transações: consistência e isolamento.

A consistência pode ser afetada pelo fato de que o método poderá alterar o estado interno dos membros da classe ou de qualquer outro recurso envolvido na transação e, caso a transação não seja explicitamente encerrada, os dados que estão em um formato in-doubt ficarão disponíveis, e qualquer outra transação poderá acessá-lo, quebrando assim, a segunda característica, o isolamento. Uma forma que temos para manter um serviço PerSession de forma a garantir que transações funcionem como deveriam, é definindo a propriedade ReleaseServiceInstanceOnTransactionComplete do atributo ServiceBehaviorAttribute para True (que já é o padrão), como é mostrado abaixo:

using System;
using System.ServiceModel;
using System.Transactions;

[ServiceBehavior(
    TransactionTimeout = "00:02:00"
    , TransactionIsolationLevel = IsolationLevel.ReadCommitted
    , ReleaseServiceInstanceOnTransactionComplete = true
    , InstanceContextMode = InstanceContextMode.PerSession
    , ConcurrencyMode = ConcurrencyMode.Single)]
public class ServicoDeUsuarios : IUsuarios
{
    [OperationBehavior(TransactionScopeRequired = true)]
    public bool Adicionar(string nome)
    {
        //implementação
    }
}

A utilização da propriedade ReleaseServiceInstanceOnTransactionComplete obriga o serviço a ter, no mínimo, uma operação com a propriedade TransactionScopeRequired definida como True, e lembrando que você deverá votar se a transação deu certou ou não, utilizando as técnicas que já falamos acima. Isso fará com que o WCF descarte o objeto silenciosamente, sem refletir nada para o cliente. Essa funcionalidade é semelhante ao JIT Just-In-Time, fornecido pelo COM+. Outra consistência que será feita será em cima da modo de concorrência (já discutido neste artigo), nos obrigando a definí-lo como Single, para evitar o acesso multi-threading a partir de um mesmo cliente.

Ainda falando sobre o modo PerSession, o WCF fornece outro recurso para lidar com transações, que é completamente independente da propriedade ReleaseServiceInstanceOnTransactionComplete. Esse modo permitirá ao cliente criar uma transação para que a mesma dure enquanto a sessão estiver ativa, ou seja, a sessão será transacionada. A idéia aqui é a transação não ser finalizada dentro do serviço, já que o WCF descartaria a instância. Para evitar isso, podemos definir a propriedade TransactionAutoComplete para False e, através do atributo ServiceBehaviorAttribute, definirmos a propriedade TransactionAutoCompleteOnSessionClose como True que, ao finalizar a sessão, completará a transação. Apenas deve-se atentar ao timeout, pois a transação está sujeita a ser abortada por isso caso o mesmo seja excedido. O exemplo abaixo ilustra essa configuração:

using System;
using System.ServiceModel;

[ServiceBehavior(TransactionAutoCompleteOnSessionClose = true)]
public class ServicoDeUsuarios : IUsuarios
{
    [OperationBehavior(TransactionScopeRequired = true, TransactionAutoComplete = false)]
    public bool Adicionar(string nome)
    {
        //implementação
    }
}

Finalmente, o modo Single de gerenciamento de instância também possui suas peculiaridades. Serviços expostos sob este modo tem um comportamento parecido com o modo PerCall. Como falado acima, o valor padrão da propriedade ReleaseServiceInstanceOnTransactionComplete é True e, com isso, após uma transação, a instância do serviço será descartada para manter a consistência dos dados. Esse comportamento deverá fazer com que o serviço gerencie o estado a cada chamada e, tecnicamente falando, um identificador do cliente deverá ser passado para que o serviço consiga recuperar uma possível informação.

Conclusão: O artigo demonstrou as várias configurações suportadas pelo WCF para criar e gerenciar transações. Foi falado desde a necessidade das transações, passando pela infraestrutura necessária e, finalmente, falando sobre como configurá-la em serviços expostos via WCF. Notamos que o WCF desacopla totalmente a criação (e algumas vezes o gerenciamento) das transações da implementação do serviço, fazendo com que o desenvolvedor se concentre na regra do negócio, pois a transação será facilmente habilitada.

Transacoes.zip (137.93 kb)

A primeira etapa para a construção de um serviço WCF é a definição do contrato do serviço que, durante a escrita do código, é determinado pela criação de uma interface tradicional. Os métodos que são criados ali são, em tempo de execução, expostos através do WSDL para que os clientes possam consumí-los.

Se criarmos uma referencia para o serviço a partir da IDE do Visual Studio ou do utilitário svcutil.exe, automaticamente um proxy será criado e podemos invocar os métodos a partir dele, com a impressão de que se estivéssemos chamando um método localmente mas que, durante a execução, uma mensagem é criada e enviada ao respectivo método remoto.

Mas e quando não temos o essa flexibilidade de criar o proxy (exemplo)? Como fazemos para invocar o um método disponibilizado pelo serviço? Felizmente podemos recorrer ao Fiddler ou até mesmo as classes HttpWebRequest e HttpWebResponse para efetuar a requisição, montando o cabeçalho e o corpo (SOAP) para invocar um determinado método do serviço. Esse procedimento permite a quem estiver consumindo, colocar o nome errado do método a ser invocado e, consequentemente, o seu serviço irá rejeitar a requisição.

Felizmente o WCF nos permite lidar com mensagens genéricas, ou seja, podemos criar um método que capturará toda e qualquer mensagem que não for encontrada no contrato do serviço. Para isso, basta definirmos a propriedade Action e ReplyAction do atributo OperationContractAttribute para “*”. Isso fará com que todas as mensagens não encontradas na definição do contrato, sejam encaminhadas para este método, em que podemos efetuar logging, notificações, etc. Abaixo um exemplo ilustra como proceder:

[OperationContract(Action=”*”, ReplyAction=”*”)]
Message ProcessRequest(Message msg);

É importante notar que o método recebe e também retorna uma instancia da classe Message. Esta classe representa a mensagem dentro do WCF. Além disso, também podemos usar esta mesma técnica quando utilizamos o modelo REST, só que agora, devemos definir a propriedade UriTemplate do o atributo WebGetAttribute para “*” e, assim como o OperationContractAttribute, consiga capturar todas mensagens não mapeadas/existentes.

[OperationContract]
[WebGet(UriTemplate=”*”)]
Message ProcessRequest(Message msg);

O Visual Studio .NET 2008 traz uma funcionalidade que permite aos desenvolvedores de serviços WCF, efetuar a depuração do mesmo através do cliente, ou seja, quando estamos executando o cliente em modo de depuração, ao chamar uma operação através da instancia do proxy (via F11 – Step Into), automaticamente seremos redirecionados para o método do serviço, executando-o passo-à-passo.

Ao pressionar F11, o debugger automaticamente irá se vincular ao processo que corresponde efetua o host do serviço e, ao finalizar a execução do método, o controle voltará ao cliente. O mais importante é que a janela Call Stack traz informações tanto do cliente como do serviço.

Caso voce não esteja fazendo uso destas funcionalidades, então provavelmente isso está desabilitado. Para habilitar este recurso, basta recorrer ao utilitário vsdiag_regwcf.exe. Este utilitário está disponível a partir do Prompt de comando do Visual Studio .NET 2008 (se estiver rodando no Windows Vista, então é necessário rodar como Administrador) e, via os seguintes parametros, voce poderá interagir com ele:

• -i: Habilita o recurso.
• -u: Desabilita o recurso.
• -s: Exibe se o recurso está habilitado ou desabilitado.

Ao consumir um serviço WCF podemos interagir com o mesmo através de diferentes mecanismos, tais como, request-reply ou one-way (os tipos de mensagens suportados pelo WCF já foram discutidos detalhadamente neste artigo). Sabemos que, independente do tipo que você utilize, a mensagem trafega entre o cliente e o serviço através da rede, utilizando o protocolo especificado pelo binding. Com isso, uma das principais preocupações que se tem é com relação a garantia de entrega da mensagem ao seu destinatário, pois problemas com a rede podem acontecer, fazendo com que a mensagem seja interceptada ou simplesmente perdida. A finalidade deste artigo é apresentar uma técnica disponibilizada pelo WCF, para evitar que problemas como estes comprometam a consistência e execução de um serviço.

Quando desejamos enviar uma mensagem para um determinado serviço, queremos que ela chegue até o mesmo e, caso isso não aconteça, talvez precisamos reenviá-la. Mas como saber se ela chegou ou não, para tomar a decisão se devemos ou não reenviá-la? Geralmente, alguns protocolos fornecem a garantia de entrega da mensagem, como é o caso do TCP e IPC. Mesmo quando o protocolo garante nativamente a entrega da mensagem, ele somente irá assegurar a entrega ponto-a-ponto, ou seja, se houver intermediários, corremos o risco da mensagem ser perdida.

Felizmente o WCF implementa um padrão proposto pela OASIS (Organization for the Advancement of Structured Information Standards), chamado WS-ReliableMessaging (WS-RM). Essa especificação define um protoloco interoperável para transmissão de mensagens entre um único remetente para um único destinatário, garantindo que a mensagem será entregue (sem duplicação), independentemente de quantos roteadores intermediam a ligação entre eles (end-to-end). Além da garantia de entrega, este protocolo ainda fornece uma outra importante funcionalidade: você pode, opcionalmente, garantir que a entrega das mensagens aconteça na mesma ordem em que elas partiram do cliente (falaremos mais sobre ela ainda neste artigo).

Funcionamento

O funcionamento das reliable messages é um pouco complexo, mas o protocolo WS-RM em conjunto com o WCF o abstrai, facilitando o processo para aqueles que desenvolvem e administram o serviço. De qualquer forma, veremos a seguir como o processo ocorre nos bastidores do WCF (tanto no cliente quanto no serviço) para suportar essa funcionalidade.

Quando invocamos um método a partir do proxy, uma mensagem é enviada até o serviço com as informações (parâmetros, credenciais, etc.) para que o mesmo seja processado. Se temos a reliable message habilitada, não enviaremos apenas uma mensagem para o serviço (a operação que queremos invocar), mas várias outras que consistem, basicamente, na verificação para saber se a mensagem chegou ou não até o seu destino. Depois que o cliente envia a mensagem da operação, ele fica questionando o serviço para saber se a mensagem chegou até lá. O cliente espera essa notificação por um tempo (configurável) e, se o tempo exceder e a notificação não chegar, o WCF entende que ela não foi entregue, podendo agora, reenviá-la. Caso a notificação venha dentro do tempo esperado, o cliente sabe que a mensagem foi transferida com sucesso.

É importante dizer que o protocolo WS-RM foi desenhado para controlar a garantia de entrega de uma ou uma seqüência de mensagens SOAP entre dois endpoints, independentemente de como eles estão conectados, ou melhor, de quantos intermediários existam entre eles e de quais protocolos estão envolvidos. Utilizaremos a imagem abaixo para ilustrar como o processo acontece, exibindo os responsáveis que fazem isso acontecer.

Para que isso funcione, será necessário estabelecer uma conexão com o serviço e, neste primeiro momento, um identificador será criado (CreateSequence) para correlacionar as mensagens. Quando este identificador for criado, o serviço o retorna para o cliente (CreateSequenceResponse) que irá embutí-lo em mensagens subseqüentes. Podemos perceber que ao invocar uma operação, o remetente cria um cache temporário para efetuar o rastreamento das mensagens e, a partir deste momento, o proxy é responsável por gerenciar o envio da operação e aguardar pela notificação do recebimento. Da mesma forma, o servidor também cria um cache para receber as mensagens e entregá-las para o serviço. O cache do lado do serviço terá maior utilidade quando trabalharmos com mensagens ordenadas (mais abaixo).

Ao receber a mensagem, o serviço retorna para o cliente uma mensagem contendo o elemento SequenceAcknowledgement nos headers da resposta, indicando que o serviço a recebeu. Esse elemento traz várias informações e, entre elas, temos: Identifier, AcknowledgementRange e BufferRemaining. A primeira propriedade refere-se ao identificador; já a segunda traz dois números inteiros que representam a primeira e a última mensagem processada (permitindo ao cliente remover mensagens que já estão do outro lado); finalmente, a propriedade BufferRemaining indica a quantidade disponível dentro do buffer de mensagens. A LastMessage, como o próprio nome indica, indica ao serviço que uma última mensagem será enviada e, finalmente, a mensagem TerminateSequence que encerra o processo.

Observação Importante: Quando definimos o modo de gerenciamento de instância do serviço como PerSession e habilitamos a funcionalidade de garantia de entrega, essa combinação é referida como Reliable Sessions. O protocolo WS-RM não necessita que o serviço/binding suporte sessões para funcionar, bem como o suporte à sessão não necessita do protocolo WS-RM habilitado. Ainda através da figura que vimos acima, visualizamos duas operações sendo realizadas (o que pode caracterizar uma sessão), mas é importante dizer que todos os demais passos irão ocorrer, independente da sessão estar ou não habilitada.

Configuração

A configuração das reliable messages é realizada sob o binding onde o serviço será exposto. É importante dizer que nem todas as configurações suportadas estão diretamente disponíveis através do binding, ou seja, será necessária a criação de um binding customizado para editar as configurações padrão. Os bindings expõem uma propriedade chamada ReliableSession, do tipo OptionalReliableSession que, em seu construtor, recebe uma instância da classe ReliableSessionBindingElement, contida no namespace System.ServiceModel.Channels, onde podemos efetivamente customizar o comportamento deste tipo de mensagem. A tabela abaixo exibe as propriedades expostas pela classe ReliableSessionBindingElement e que estão disponíveis para uso:

Assim como quase tudo no WCF, a configuração das reliable messages pode ser realizada tanto de forma imperativa quanto declarativa. Como já foi dito acima, a configuração é uma característica do binding, e é através dele que iremos conseguir alterar qualquer uma das propriedades que vimos na tabela acima.

Os bindings NetTcpBinding, WSHttpBinding, WSFederationHttpBinding e WSDualHttpBinding suportam as reliable messages e permitem que você habilite ou desabilite, defina um tempo de timeout por inatividade e especifique se as mensagens serão ou não ordenadas. O código abaixo ilustra as duas formas de como como podemos proceder para configurar as reliable messages no binding:

WSHttpBinding ws = new WSHttpBinding();
ws.ReliableSession.Enabled = true;
ws.ReliableSession.Ordered = true;
ws.ReliableSession.InactivityTimeout = TimeSpan.FromMinutes(5);

<wsHttpBinding>
    <binding name="BindingConfig">
        <reliableSession
                enabled="true"
                ordered="true"
                inactivityTimeout="00:05:00" />
    </binding>
</wsHttpBinding>

Uma outra alternativa no modo imperativo é que os bindings possuem uma versão do construtor onde já podemos definir a propriedade Enabled da ReliableSession. As outras propriedades que vimos na tabela acima não estão expostas diretamente através do binding. Apesar de muitas vezes as configurações padrões serem suficientes, em algum momento talvez seja necessário alterá-las e, para que isso seja possível, somente poderemos efetuar essa modificação através de um binding customizado, como por exemplo:

using System;
using System.ServiceModel;
using System.ServiceModel.Channels;

ReliableSessionBindingElement rsbe = new ReliableSessionBindingElement();
rsbe.AcknowledgementInterval = TimeSpan.FromSeconds(5);
rsbe.FlowControlEnabled = true;
rsbe.InactivityTimeout = TimeSpan.FromMinutes(5);
rsbe.MaxPendingChannels = 10;
rsbe.MaxRetryCount = 10;
rsbe.MaxTransferWindowSize = 10;
rsbe.Ordered = true;

CustomBinding cb =
    new CustomBinding(
        new HttpTransportBindingElement(),
        new TextMessageEncodingBindingElement(),
        rsbe);

<customBinding>
  <binding name="BindingConfig">
    <reliableSession
      acknowledgementInterval="00:00:05"
      flowControlEnabled="true"
      inactivityTimeout="00:05:00"
      maxPendingChannels="10"
      maxRetryCount="10"
      maxTransferWindowSize="10"
      ordered="true"/>
  </binding>
</customBinding>

Habilitar a reliable message sob um determinado binding afetará o documento que descreve o serviço (WSDL), publicando nele o suporte a esse tipo de mensagem, para que os clientes consigam configurar corretamente o proxy. Algumas dessas configurações são propagadas para o cliente, como é o caso das propriedades InactivityTimeout e AcknowledgementInterval, enquanto as outras tratam-se de configurações exclusivas ao binding.

Ao invocar o método exposto pelo proxy, aparentemente apenas uma mensagem será enviada para o respectivo serviço mas, como notamos na imagem acima, várias outras mensagens são enviadas e recebidas entre o cliente e o serviço para garantir a entrega da mensagem que o cliente quer efetivamente enviar. Essas mensagens “extras” são criadas pelo próprio runtime do WCF quando habilitamos essa funcionalidade. Caso você queira visualizar para se certificar de que isso está realmente ocorrendo, basta você habilitar o tracing no cliente e conseguirá armazenar as mensagens que estão sendo trocadas. A imagem abaixo, ilustra isso (apesar de importante, o corpo da mensagem não será mostrado aqui por questões de espaço):

Mensagens Ordenadas

O que vimos até o momento é garantia de entrega, fornecida pelo protocolo WS-RM, e é importante ratificar que, quando habilitamos essa funcionalidade em um serviço que é exposto como PerSession, ela é referida como reliable session. Neste momento entra em cena uma configuração adicional que permite a entrega das mensagens na mesma ordem em que elas saíram. Nem sempre podemos assumir que a primeira mensagem chegará ao seu destino antes da segunda, pois elas podem optar por caminhos diferentes.

Quando esta opção está habilitada, as mensagens são enviadas para o serviço e são armazenadas no cache (ou fila) do mesmo. Se a mensagem chega na ordem correta, ela é imediatamente encaminhada para o serviço. Caso contrário, ela aguardará na fila esperando as demais mensagens para compor a seqüencia e, finalmente, ser encaminhada para o serviço. Imagine que o cliente envie as mensagens 1, 2, 3 e 4 e o serviço recebe as mensagens 1, 2 e 4, ou seja, está faltando a mensagem 3. Neste caso, a mensagem 1 e 2 serão encaminhadas para o serviço, enquanto a mensagem 4 irá aguardar a chegada da mensagem 3 para, depois disso, ser submetida para a execução.

Para habilitar este recurso (que já é o padrão) e configurá-lo, podemos utilizar o atributo DeliveryRequirementsAttribute sob a interface que representa o contrato ou sob a classe que o implementa. Onde definir dependerá do caso pois, se aplicá-lo no contrato, em qualquer classe que o implementar, ele seguirá essas configurações; se aplicar na classe que representa o serviço, então você terá uma flexibilidade para determinarem qual dos contratos você deseja aplicar essa técnica. Esse atributo fornece a propriedade RequireOrderedDelivery que é um valor booleano que indica se está ou não habilitado, e a propriedade TargetContract, que espera um objeto do tipo Type, que determina em qual contrato essa técnica será aplicada. A segunda propriedade somente faz sentido quando o atributo é aplicado na classe do serviço. O trecho de código abaixo exibe como proceder para efetuar essa configuração:

using System;
using System.ServiceModel;

[ServiceContract]
[DeliveryRequirements(RequireOrderedDelivery = true)]
public interface IContrato
{
    [OperationContract(IsOneWay = true)]
    void EnviarInformacao(string valor);
}

Conclusão: Este artigo demonstrou importantes funcionalidades que garantem a entrega e o processamento ordenado das mensagens e, como vimos, tudo isso é possível graças ao protocolo WS-ReliableMessaging. Com a implementação do protocolo WS-RM no WCF, a Microsoft conseguiu abstrair todo o trabalho complexo, permitindo aos desenvolvedores, com apenas algumas configurações simples, fazer com que ela entre em funcionamento, sem a necessidade de conhecer profundamente os detalhes que são necessários para que isso aconteça.

É muito comum envolvermos objetos que utilizam recursos custosos dentro de um bloco using, fazendo com que o método Dispose do mesmo seja disparado independemente de exceções que sejam disparadas durante a execução. Vale lembrar que somente podemos envolver objetos que implementam a interface IDisposable.

Quando fazemos a referencia para algum serviço WCF em uma aplicação cliente, automaticamente a IDE do Visual Studio (ou através do utilitário svcutil.exe), se encarregará de criar uma classe que herda diretamente da classe abstrata, chamada ClientBase<TChannel>. Essa classe implementa tudo o que é necessário para possibilitar a comunicação entre cliente e o serviço (em outras palavras, trata-se do proxy) e, que por sua vez, faz uso de objetos caros (channels, etc.) e que precisam ser brevemente liberados. Como a classe ClientBase<TChannel> implementa a interface IDisposable, isso quer dizer que podemos envolver a instancia do proxy em um bloco using, para que o método Dispose seja automaticamente disparado.

Se envolvermos o proxy em um bloco using (lembre-se de que ele será transformado em try/finally), é necessário tomarmos um certo cuidado. Não porque o método Dispose não será chamado, mas sim onde que a execução deste método afetará a aplicação cliente. Vamos supor que algum erro ocorra durante a execução da operação e, como já era de se esperar, o bloco finally será disparado, chamando o método Dispose do proxy. Neste caso, o método Dispose não faz mais nada a não ser invocar o método Close. O problema aqui é que o método Close poderá exigir algumas atividades extras, necessitando fazer alguma outra comunicação com o serviço e, se neste momento algum erro ocorrer, a exceção que chegará ao cliente será:

System.ServiceModel.CommunicationObjectFaultedException: The communication object, System.ServiceModel.Channels.ServiceChannel, cannot be used for communication because it is in the Faulted state.

…, mascarando assim, o real problema. Finalmente, a opção para contornar esse possível problema, é a chamada do método Abort, que encerra imediatamente a comunicação entre o cliente o serviço, assim como é demonstrado neste link.

A Microsoft criou o WCF e implementou nele os protocolos de segurança, transações e sessões confiáveis baseando-se nas primeiras versões destes padrões, que são gerenciados pela OASIS.

Com o .NET Framework 3.5, a Microsoft atualizou o WCF, disponibilizando agora a implementação mais atualizada destes protocolos através de dois novos bindings: WS2007HttpBinding e WS2007FederationBinding.