Neste artigo eu mostrei como construir serviços WCF para serem consumidos através do jQuery. Nele falamos sobre os cuidados que devemos ter para criar e expor serviços WCF, mas não chegamos a falar sobre alguns detalhes, não menos importante, como é o caso do tratamento de erros, que é algo tão comum em qualquer tipo de aplicação.

Ao executar alguma operação, uma exceção pode ser disparada por algum motivo. Como já falamos, ao utilizar a biblioteca do jQuery para invocar algum serviço, podemos através de um callback, especificarmos um código para ser disparado quando algum problema ocorrer do lado do serviço. Para configurar isso, podemos utilizar o parâmetro error da função $.ajax. O código abaixo ilustra como podemos configurar o parâmetro error, exibindo uma mensagem informando ao usuário que algum problema ocorreu:

function RecuperarUsuario() {
    $.ajax(
    {
        type: “POST”,
        url: “http://localhost/Services/ServicoDeUsuarios.svc/RecuperarUsuario”,
        contentType: “application/json”,
        data: ‘{ “nome”: “”, “email”: “ia@israelaece.com” }’, //Nome vazio causa o erro
        processData: false,
        success:
            function (resultado) {
                alert(resultado.RecuperarUsuarioResult.Nome);
                alert(resultado.RecuperarUsuarioResult.Email);
            },
        error:
            function (xhr, textStatus, errorThrown) {
                alert(‘Algum Problema Ocorreu!’);
            }
        });
    }

Esse tipo de código funciona normalmente, até que você precise capturar a mensagem exata do erro que ocorreu. Quando executamos uma operação que está disparando alguma exceção, o WCF acaba retornando a seguinte mensagem: “Request server encountered an error processing the request. See server logs for more details”. O problema é que o erro não será retornado em um formato que é facilmente entendido/preferido pelo jQuery, que é o JSON.

Ao configurar o contrato para expor via AJAX, podemos definir através do atributo WebInvokeAttribute, que a requisição (RequestFormat) e a resposta (ResponseFormat) sejam formatadas em JSON, mas isso não inclui eventuais exceções que sejam disparadas pelas respectivas operações, mesmo que esse problema esteja definido como um contrato de fault (FaultContractAttribute).

Para tentar resolver isso, podemos recorrer a alguns pontos de estensibilidade do WCF, para conseguirmos interceptar o erro que ocorreu. Ao interceptar, deveremos transformar a mensagem em algum objeto que deverá ser entendido pelo jQuery, entregando para o cliente todas as informações necessárias para que o mesmo consiga tratar o erro ocorrido.

Para descrever o problema, vamos criar uma classe que possui características que detalham o erro ocorrido. Essa classe será chamada de GenericErrorDescription, que possuirá apenas uma única propriedade (para manter a simplicidade), chamada de Message, do tipo string. Como a finalidade será transformar a exceção em formato JSON para facilitar o consumo pelo jQuery, criaremos uma classe chamada de JsonErrorHandler, e nela implementaremos a interface IErrorHandler, que é uma espécie de interceptador (mais detalhes neste artigo). O principal método fornecido por esta interface, é chamado de ProvideFault, que passa como parâmetro a instância da exceção que ocorreu e uma instância da classe Message, que corresponde a mensagem que será devolvida para o cliente.

Na implementação deste método, utilizaremos o método estático CreateMessage da classe Message, que criará a mensagem de retorno, utilizando o serializador JSON para que a mesma será formatada neste padrão, e além disso, esse serializador deverá serializar a instância da classe que representa o erro, que no nosso exemplo é a GenericErrorDescription. Na sequência configuramos a instância da classe HttpResponseMessageProperty, para customizarmos a mensagem, informando que o tipo a ser retornado será application/json, para que o jQuery consiga, facilmente, entender e interpretar esse conteúdo. Note também que mantemos o StatusCode do HTTP como 500, ou seja, um erro interno, e como sua descrição, definimos a mesma mensagem gerada pela exceção disparada pela operação.

A classe JsonErrorHandler ainda implementa a interface IEndpointBehavior, que nos permite acoplar a instância desta classe em um endpoint específico, do lado do serviço (dispatcher), na coleção de tratadores de erros. O código abaixo ilustra a classe JsonErrorHandler já devidamente implementada:

public class JsonErrorHandler : IEndpointBehavior, IErrorHandler
{
    public bool HandleError(Exception error)
    {
        return true;
    }

    public void ProvideFault(Exception error, MessageVersion version, ref Message fault)
    {
        GenericErrorDescription desc = 
            new GenericErrorDescription() { Message = error.Message };

        fault = Message.CreateMessage(version, “”, desc, 
            new DataContractJsonSerializer(typeof(GenericErrorDescription)));
        fault.Properties.Add(WebBodyFormatMessageProperty.Name, 
            new WebBodyFormatMessageProperty(WebContentFormat.Json));

        var msgp = new HttpResponseMessageProperty();
        msgp.Headers[HttpResponseHeader.ContentType] = “application/json”;
        msgp.StatusCode = HttpStatusCode.InternalServerError;
        msgp.StatusDescription = desc.Message;

        fault.Properties.Add(HttpResponseMessageProperty.Name, msgp);
    }

    public void AddBindingParameters(ServiceEndpoint endpoint, BindingParameterCollection bp) { }

    public void ApplyClientBehavior(ServiceEndpoint endpoint, ClientRuntime cr) { }

    public void ApplyDispatchBehavior(ServiceEndpoint endpoint, EndpointDispatcher ed)
    {
        ed.ChannelDispatcher.ErrorHandlers.Add(this);
    }

    public void Validate(ServiceEndpoint endpoint) { }
}

Só que essa classe por si só não funciona. Precisamos efetivamente acoplar ao pipeline do WCF, e para isso, podemos criar um extension element, que nos dará a oportunidade de efetuar essa configuração de modo declarativo, ou seja, através do arquivo Web.config. Basicamente, essa classe será responsável por criar instâncias da classe que criamos acima, ou seja, do tratador de erros:

public class JsonErrorElement : BehaviorExtensionElement
{
    public override Type BehaviorType
    {
        get
        {
            return typeof(JsonErrorHandler);
        }
    }

    protected override object CreateBehavior()
    {
        return new JsonErrorHandler();
    }
}

Depois das classes devidamente criadas, tudo o que precisamos fazer agora é configurarmos o arquivo Web.config do serviço, acoplando o extension element ao endpoint de acesso ao serviço. A configuração final do Web.config deve ficar da seguinte forma:

<system.serviceModel>
  <services>
    <service name=”ServicoDeUsuarios” behaviorConfiguration=”config“>
      <endpoint
        binding=”webHttpBinding”
        contract=”IUsuarios”
        behaviorConfiguration=”edpConfig” />
    </service>
  </services>
  <behaviors>
    <serviceBehaviors>
      <behavior name=”config“>
        <serviceDebug includeExceptionDetailInFaults=”false” />
      </behavior>
    </serviceBehaviors>
    <endpointBehaviors>
      <behavior name=”edpConfig“>
        <jsonErrorHandler />
      </behavior>
    </endpointBehaviors>
  </behaviors>
  <extensions>
    <behaviorExtensions>
      <add
        name=”jsonErrorHandler”
        type=”JsonErrorElement, WCFExtensions, Version=1.0.0.0, …” />
    </behaviorExtensions>
  </extensions>
</system.serviceModel>

Já do lado do cliente, as mudanças são bastante ligeiras. Tudo o que precisamos fazer é uma pequena mudança no código que é disparado quando o erro ocorre. Uma vez que o interceptador de erros está acoplado do WCF, a mensagem com o erro de retorno será formatada em JSON, e se analisarmos o retorno, veremos o seguinte resultado:

{“Message”: “Informe o nome do usuariou000du000aParameter name: nome”}

Como a mensagem de retorno está em formato JSON, utilizaremos o método parse da classe JSON, exposta pelo JSON2. Esse método é responsável por transformar o conteúdo JSON em um objeto, respeitando as mesmas propriedades serializadas pela classe GenericErrorDescription. Com isso, o nosso código de consumo ao serviço será alterado para:

function RecuperarUsuario() {
    $.ajax(
    {
        type: “POST”,
        url: “http://localhost/Services/ServicoDeUsuarios.svc/RecuperarUsuario&#8221;,
        contentType: “application/json”,
        data: ‘{ “nome”: “”, “email”: “ia@israelaece.com” }’, //Nome vazio causa o erro
        processData: false,
        success:
            function (resultado) {
                alert(resultado.RecuperarUsuarioResult.Nome);
                alert(resultado.RecuperarUsuarioResult.Email);
            },
        error:
            function (xhr, textStatus, errorThrown) {
                var erro = JSON.parse(xhr.responseText);
                alert(erro.Message);
            }
        });
    }

Se quiser levar mais detalhes do erro, você ainda tem algumas outras alternativas, mas não tão interessantes como essa. Você poderia optar por definir o atributo includeExceptionDetailInFaults do elemento serviceDebug para True, mas isso iria expor mais informações do que realmente deveria, como por exemplo a Stack Trace, algo que não deveria ultrapassar o serviço. Além dela, ainda poderia envolver toda a operação em um bloco try/catch, e caso algum problema ocorra, utilizamos a classe WebOperationContext para customizar o StatusCode e o ContentType através dela, mas isso torna a classe que representa o serviço dependente do protocolo HTTP, o que não é uma boa opção.

Conclusão: Graças a grande flexibilidade fornecida pelo WCF, podemos contornar alguma de suas “limitações” de uma forma bastante elegante, sem precisar misturar em minhas operações, códigos que estão relacionados puramente à infraestrutura.

Temos dentro do sistema operacional uma ferramenta administrativa conhecida como Component Services. É através desta ferramenta que controlamos os componentes que utilizam a tecnologia COM+, permitindo visualizar aqueles componentes que estão hospedados em um determinado servidor, configurar suas características, entre várias outras funcionalidades.

Em muitas situações, o Component Services é encarado como sendo o servidor de aplicações, pois é nele que estarão todos os componentes que são utilizados pela companhia. Utilizamos o Component Services para centralizar tais componentes, fazendo uso de suas funcionalidades, tais como: suporte à transações, pool de objetos, sincronização, etc. As aplicações clientes, sejam elas Windows ou Web, recorrem a estes componentes hospedados neste servidor para executar as tarefas.

Com o surgimento do WCF, o COM+ está perdendo espaço, e a partir de agora, quando falamos em sistemas distribuídos, utilizamos o WCF como tecnologia para suportar isso. Uma das principais características do WCF, é a independência de hosting, ou seja, podemos utilizar qualquer tipo de aplicação para hospedar um serviço WCF.

No ambiente do WCF, um dos hosts que mais se popularizou foi o IIS, que até então, possibilitava apenas a publicação do serviço em cima do protocolo HTTP/HTTPS. A partir da versão 7.0 do IIS, ele já traz suporte à todos os protocolos, incluindo o TCP (WAS). Ao incorporar essa funcionalidade, isso o tornou muito mais do que um simples servidor para sites da web, dando a ele características de um servidor de aplicação, onde podemos hospedar componentes, que através do WCF, vamos publicar para os consumidores, estejam eles dentro do fora dos limites da empresa.

O IIS ganhou todas essas capacidades, mas as ferramentas que ajudam a monitorar esses serviços não evoluíram na mesma proporção. Por mais que eu consiga hospedar meus componentes no IIS, fazendo uso dos diversos protocolos, não há como, por exemplo, saber quais são os serviços WCF que eu tenho hospedado naquele servidor; quais são os endpoints publicados para um determinado serviço, entre várias outras informações úteis tanto para os desenvolvedores quanto para aqueles que administram o servidor.

Pensando nisso, a Microsoft criou uma ferramenta chamada de Windows Server AppFabric. Quando instalada, essa ferramenta adiciona ao sistema operacional, mais precisamente dentro do IIS, um conjunto de funcionalidades que permitem diagnosticar e gerenciar os serviços que rodam dentro de um determinado servidor. Além disso, o AppFabric ainda fornece recursos adicionais, como uma estrutura para caching distribuído, que pode ser utilizado para qualquer tipo de aplicação.

Entre os vários recursos oferecidos pelo AppFabric, temos a possibilidade de gerenciar e monitorar serviços WCF. Entre as funcionalidades exclusivas ao WCF, temos a capacidade de visualizar quais são os serviços que rodam naquele servidor, quais são os endpoints que cada serviço publica (incluindo aqueles de metadados). As imagens abaixo ilustram essas funcionalidades:

Ainda há uma opção chamada de Dashboard, que exibe uma visão sintética de quantas chamadas para serviços WCF ocorreram, quantas falharam, as exceções que foram disparadas, etc. Como trata-se de uma visão agrupada, essa tela possui vários links, que ao clicar, levará para uma segunda tela, com os filtros relacionados àquela opção clicada, fornecendo a visão analítica, com informações mais completas a respeito daquele serviço. A imagem abaixo ilustra este dashboard:

Ao instalar o AppFabric, um assistente é inicializado para configurá-lo. Basicamente, ele solicitará um local para armazenar as informações geradas por ele, para que mais tarde, possamos visualizá-las. Essas configurações exigem que você defina, através de uma espécie de provider, um banco de de dados SQL Server. É importante que você crie um banco exclusivo para isso, já que este assistente adicionará vários objetos dentro dele (tabelas, views, jobs, etc.), que são de uso exclusivo, e misturar com a base de dados da aplicação não é uma boa prática.

Além dessas informações macros, ainda temos um detalhamento delas. Quando utilizamos o tracing, uma série de informações são geradas, catalogando todos os estágios por onde a requisição está passando. No AppFabric temos uma seção chamada de Tracked Events, que nos permite visualizar justamente esse tipo de informação. Se analisarmos a imagem abaixo, podemos perceber os diversos eventos (estágios) do processamento, que ocorreram do lado do servidor, e também é possível visualizar a operação que foi efetivamente disparada.

Algumas poucas configurações do serviço estão disponíveis a partir do AppFabric, como é o caso de algumas cotas e throttling, mas como sabemos, as configurações do WCF são extensas e complexas, e neste caso, o uso da ferramenta WCF Service Configuration Editor performa melhor.

Para finalizar, um outro recurso bastante interessante, que também é fornecido com o AppFabric, é a possibilidade de exportar todas as configurações de um servidor, incluindo os serviços que nele rodam. Esse recurso utiliza em seus bastidores, uma ferramenta conhecida como Web Deployment Tool, e que permite configurar um outro servidor com as mesmas características deste servidor de origem, sem a necessidade de lembrar cada uma das configurações que você já realizou anteriormente.

Conclusão: O AppFabric não visa apenas serviços WCF. Como o Windows Workflow (WF) tem uma forte integração com o WCF, é possível gerenciarmos esses serviços a partir do AppFabric, com recursos para interagir com workflows de longa duração. Além disso, ainda há recursos extras que vão além do escopo definido para este artigo, mas que não são menos importantes. Depois de ter criado toda a infraestrutura necessária para suportar serviços WCF dentro do IIS, a Microsoft tem destinado grande parte de seus esforços no desenvolvimento desse tipo de ferramenta, que ajudam a monitorar e diagnosticar problemas, algo que muitas vezes são realizadas por outras pessoas, e que não são necessariamente desenvolvedores.

Há algum tempo eu comentei aqui sobre uma dificuldade que existe quando hospedamos serviços WCF no IIS. Neste mesmo post, eu mostrei a solução que foi incorporada na versão 3.5 do WCF.

Para facilitar isso, a partir da versão 4.0 do WCF temos uma opção chamada multipleSiteBindingsEnabled, disponível através do elemento serviceHostingEnvironment, que quando definido como True, permite que o serviço fique disponível a partir dos múltiplos endereços de acesso configurados no IIS. Abaixo temos o arquivo de configuração com esta opção habilitada:

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