A partir do IIS 6.0, temos a capacidade de criar Web Sites, onde cada um desses Web Sites poderá conter 1 ou N aplicações e, para cada Web Site, podemos definir um Application Pool.

Dentro do IIS, os worker process (w3wp.exe) são representados por um objeto denominado Application Pool, ou seja, um repositório de aplicações que compartilham o mesmo worker process. Sabendo que um Application Pool poderá suportar muitas aplicações, já que ele é definido para cada Web Site, devemos entender algumas características para tirar o melhor proveito deles:

• Somente uma versão do .NET Framework (CLR) poderá ser carregada para dentro dele. Aplicações que usam versões diferentes do .NET Framework, deverão ser separadas em diferentes pools.
• Podemos configurar cada worker process para uma conta diferente que, por padrão, é sempre o usuário Network Service. Se quiser alterar e usar uma outra conta (falaremos mais abaixo), voce deve colocar esse novo usuário dentro do grupo IIS_WPG que, garantirá a ele os privilégios necessários para assumir este papel.
• Sabemos que todas as requisições para uma aplicação ASP.NET utilizam threads oriundas de um thread pool. O pool de threads é único dentro do processo, sendo compartilhado por todas as aplicações que ali estão hospedadas. Isso poderá, em algum momento, causar problemas de escalabilidade. Páginas assíncronas ajudam a melhorar isso.
• Quando o worker process for finalizado (independentemente do motivo), todas as aplicações, serão finalizadas, fazendo com que todos os dados de memória, como variáveis de aplicação, sessão e caching sejam perdidos.
• Todas as aplicações que estão dentro de um mesmo worker process compartilham o mesmo contexto de segurança. Se cada aplicação tiver permissões diferentes dentro do sistema operacional, o ideal é isolar cada uma delas em um pool diferente, configurando a conta daquele pool com os respectivos privilégios.

Eu ministro treinamentos oficiais Microsoft e, em um dos capítulos, falamos sobre o envio de e-mails, mais precisamente, sobre as classes MailMessage e SmtpClient.

Pois bem, para não ter que criar/utilizar uma conta de e-mail dummy ou ter uma infraestrutura com um servidor de e-mail, podemos ao invés de efetivamente enviar o e-mail ao seu destinatário, salvá-lo localmente e assim visualizar como ficou o mesmo, sem a necessidade de abrí-lo em alguma ferramenta específica ou webmail. Para essa mudança, voce deve configurar o modo de entrega como sendo specifiedPickupDirectory ao invés de network. O exemplo abaixo exibe como efetuar essa mudança através do arquivo de configuração da aplicação:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <system.net>
    <mailSettings>
      <smtp deliveryMethod="SpecifiedPickupDirectory" from="automatico@site.com.br">
        <specifiedPickupDirectory pickupDirectoryLocation="C:\Temp\"/>
      </smtp>
    </mailSettings>
  </system.net>
</configuration>

Já no ambiente de produção, voce deverá trocar o valor do atributo deliveryMethod para Network e, ao invés de utilizar o sub-elemento specifiedPickupDirectory, configurar o sub-elemento network, como mostrado abaixo:

<network host="mail.site.com.br" port="25" />

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);

Um dia desses um colega me perguntou como customizar, ou melhor, como variar o OutputCaching de uma página para cada usuário da aplicação. Entre as opções que a diretiva @OutputCache fornece, temos a opção VaryByCustom, especificando como valor deste atributo uma string qualquer, com a finalidade de definirmos uma informação, que indicará como proceder para capturar a "chave" que será utilizada pelo runtime, para determinar se já existe ou não uma versão do cache. Abaixo está a configuração desta diretiva:

<%@ OutputCache Duration="60" VaryByCustom="UserName" VaryByParam="none" %>

Quando utilizamos esta técnica, devemos sobrescrever o método GetVaryByCustomString da classe HttpApplication (leia-se Global.asax) e, lá colocar o código que irá retornar a string que servirá de "chave", para que o ASP.NET use-a para determinar se já existe ou não uma versão para ela. No nosso caso, a finalidade é criar uma versão de caching para cada usuário, portanto, temos o seguinte código:

public override string GetVaryByCustomString(HttpContext context, string custom)
{
    if(custom == "UserName" && context.User.Identity.IsAuthenticated)
        return context.User.Identity.Name;

    return base.GetVaryByCustomString(context, custom);
}

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.

Os ASP.NET Web Services fornecem uma possibilidade de efetuar a autenticação do serviço através de SOAP Headers. Para isso, bastava criar uma classe que herde da classe SoapHeader e criar as propriedades UserName/Password e, via SoapHeaderAttribute, voce vinculava este header aos métodos que exigem a autenticação do usuário para poder funcionar.

Essa configuração funciona bem, mas é vulnerável. A questão é que o envelope SOAP irá trafegar entre o cliente e o serviço de forma desprotegida e, sendo assim, qualquer um que interceptar a requisição, conseguirá extrair essas informações confidenciais. A autenticação baseada em SOAP Headers apenas são seguras se o transporte garantir a segurança; em outras palavras, isso quer dizer HTTPS. Outra alternativa ainda utilizando os tradicionais ASP.NET Web Services, seria a utilização do WSE (Web Services Enhancements), que possibilita a segurança em nível de mensagens.

O WCF, que é seguro por padrão, tem um comportamento ligeiramente diferente em relação aos ASP.NET Web Services. Para utilizar a autenticação baseada em UserName/Password que o WCF fornece sob o protocolo HTTP, será necessário utilizar um certificado. Sem a utilização deste, não seria possível garantir a integridade e confidencialidade da mensagem, comprometendo as informações e, principalmente, permitindo que alguém intercepte a mensagem e capture os dados sigilosos. Assim como os ASP.NET Web Services, se o serviço WCF for exposto via HTTPS, isso não é necessário, mas utilizar segurança baseada em transporte tem seu ponto negativo: a segurança é apenas garantida ponto-a-ponto e, caso haja intermediários entre o cliente e o serviço, não temos a garantia de que a mensagem chegará segura até o destino.

Estou trabalhando em um projeto que utiliza o Health Monitoring para notificações de que alguma falha ocorreu na aplicação. Essa configuração faz com que qualquer exceção não tratada, seja capturada pelo Health Monitoring e a seção customErrors garante uma página amigável para o usuário final.

A maioria dos erros não tratados são ocasionados por certos valores que são passados através de algum campo no formulário e, muito raramente, através de  query strings (no caso deste projeto). A configuração padrão do Health Monitoring traz a stack trace do erro que ocorreu e outras informações relevantes ao problema, como o usuário, tipo da exceção, servidor, processo, etc. O problema é que, para simular o erro em um ambiente de teste ou até mesmo em produção, é necessário termos os mesmos valores especificados pelo usuário, para assim tornar essa simulação o mais próximo do que ocorreu. Para isso, podemos criar um evento customizado e fazer uso dele quando uma exceção for disparada.

Essa classe que representará o evento customizado herda diretamente da classe WebRequestErrorEvent e tem o nome de WebParametersRequestErrorEvent. Ao contrário dos eventos padrões que já estão embutidos no ASP.NET, os eventos customizados devem ser explicitamente disparados e, para poupar código, podemos criar um módulo. O módulo fornece a instancia da classe HttpApplication que nos permite interceptar o evento Error que, por sua vez, é disparado sempre quando um erro não tratado ocorre na aplicação. Com isso, basta simplesmente instanciar e invocar o método Raise do evento customizado.

Finalmente, apenas o que precisamos é configurar devidamente o Health Monitoring no arquivo Web.Config da aplicação, fazendo o mapeamento entre o eventMapping, rules e providers, como é mostrado detalhadamente através do código abaixo:

<system.web>
    <healthMonitoring enabled="true" heartbeatInterval="0">
        <providers>
            <add
                name="SimpleMailWebEventProvider"
                type="System.Web.Management.SimpleMailWebEventProvider"
                from="suporte@site.com.br"
                to="israel@site.com.br"
                buffer="false" />
        </providers>
        <rules>
            <add
                name="WebParametersRequestErrorEventModule Mail"
                eventName="WebParametersRequestErrorEvent"
                provider="SimpleMailWebEventProvider"
                profile="Default"
                minInstances="1"
                maxLimit="Infinite"
                minInterval="00:00:00"/>
        </rules>
        <eventMappings>
            <add
                name="WebParametersRequestErrorEvent"
                type="Logger.WebParametersRequestErrorEvent, Logger"/>
        </eventMappings>
    </healthMonitoring>
    <httpModules>
        <add
            name="WebParametersRequestErrorEventModule"
            type="Logger.WebParametersRequestErrorEventModule, Logger"/>
    </httpModules>
<system.net>

Ao receber o e-mail, tenho todos os detalhes do erro que já era fornecido pelo evento WebRequestErrorEvent, e mais os dados contextuais da requisição:

Custom event details:
    Request - QueryStrings
            ID: 123
            Nome: Israel Aece
            E-mail: israel@projetando.net
    Request - Forms
            __VIEWSTATE: /wEPDwUJOTQ4N...m+ks3yA==
            __EVENTVALIDATION: /wEWBALs0J+...ewcwK+BGBh
            txtValor: 123,45
            txtNome: Jack Bauer
            Button1: Button

Download: WebParametersRequestErrorEvent e WebParametersRequestErrorEventModule.

Quando fazemos uma referencia a um serviço WCF, e ele possuir um certificado definido para assegurar a troca de informações entre o cliente o e serviço, a IDE do Visual Studio ou o utilitário svcutil.exe, adicionanão um elemento chamado identity/certificate com o atributo encodedValue. O valor deste atributo é uma série de letras e números mas, o que isso representa?

Essa informação trata-se da chave pública do certificado, codificada no padrão Base64. Ela será utilizada pelo runtime do WCF para criptografar as informações que serão trocadas, mais precisamente, as credenciais. Quando essa informação não existir no cliente, a configuração do serviço deverá permitir a negociação ou informar a referencia para o certificado que, geralmente, esta armazenado em um dos repositórios do cliente.

É 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.