Todos sabem que WCF é uma plataforma poderosa e extensível. O que muita gente não sabe é que WCF é para poucos.

WCF é uma plataforma que permite a construção de sistemas distribuidos e sistemas distribuidos raramente são necessários. De maneira simplificada, podemos dizer que um sistema é distribuido quando tem seus componentes instalados em mais de um computador.

O problema da construção de sistemas distribuídos é que devido a não centralização de seus compnentes existe um overhead de comunicação entre os computadores e serialização/deserialização de objetos e isso consome muita memória e banda de rede.

Como gastamos mais recursos do que necessário temos como resultado final um aumento no tempo de resposta e gasto extra de hardware que, as vezes pode ser um problema grave além é claro do aumento da complexidade técnica.

No entanto, não sei por qual motivo, no momento em que lançou o produto, a Microsoft esqueceu de avisar seus “consumidores” a respeito destes pequenos detalhes. Talvez porque queria promover o produto?

</Importante>

<Importante 2>

WCF é uma tecnologia relativamente simples, mas apenas depois que você entende o BeABá da coisa (ou ABC[1] no caso do WCF). Até lá, qualquer coisa que fuja do point&click que o Visual Studio nos oferece é relativamente complexo.

Portanto, sugiro que antes de aplicar WCF você procure entender um pouco mais dos fundamentos e do papel de cada objeto que ele utiliza.

</Importante 2>

Agora que entendemos que não devemos usar WCF em toda aplicação que construimos (talvez isso seja tópico pra outro post?) vou falar um pouco da experiência que estou tendo com esta tecnologia e das boas práticas e atalhos que conheci.

Pretendo fazer uma pequena série e pra começar vou abordar boas práticas de consumo de serviços WCF, ou em outras palavras, como acessar um serviço WCF a partir de um cliente da maneira mais eficiente possível.

Para que seja possível consumir um serviço WCF é necessário que alguém o tenha publicado e também que tenha disponibilizado o WSDL[2] do serviço.

O WSDL nada mais é do que um arquivo XML que descreve quais são os tipos de dados que o serviço irá trafegar e quais operações ele oferece.

Geralmente, assim que temos um WSDL para consumir vamos ao Visual Studio e utilizamos a funcionalidade de Add Service Reference que ele nos oferece para gerar o objeto proxy que irá cuidar pra nós da comunicação com WCF. A partir dai utilizamos este objeto em toda nossa aplicação. E este é o nosso maior erro.

Este proxy, gerado pelo Wizard, encapsula todas as classes necessárias para ler o WSDL, criar os tipos necessários e lidar com os canais de comunicação em cada operação que executamos. No entanto, ele o faz da pior maneira possível.

Cada vez que invocamos uma operação através deste proxy, ele cria uma instância da classe ChannelFactory<T>. Esta classe é responsável por ler as configurações definidas em nosso app.config e baseado nestas configurações abrir os canais de comunicação com o serviço que iremos consumir. Este processo é muito lento, pois todos os sockets, listeners e objetos necessários da própria infra estrutura do WCF são criados e configurados neste momento.

No entanto, este processo não precisa ser feito a cada chamada para o serviço WCF uma vez que estas informações não mudarão enquanto a aplicação estiver rodando. Então, para otimizar bastante o consumo de serviços devemos ignorar o proxy gerado pelo Wizard e cuidar da criação e destruição de canais nós mesmos mantendo este objeto (ChannelFactory<T>) como Singleton que irá durar pelo tempo de vida da aplicação. Dessa forma toda vez que chamamos uma operação remota não existe a necessidade de executar o setup e tear down desse objeto.

Para facilitar a gerência desses objetos construi uma pequena DLL que é composta apenas de uma classe. O código está disponível no github e a DLL compilada está aqui. A documentação inicial também está lá. Tudo pronto para ser usado.

Referências adicionais (e importantes)

• Performance improvement for WCF client proxy creation in .NET 3.5 and best practices @ Wenlong Dong’s Blog
• Internals – Proxy de Serviços WCF @ Israel Aece
• WCF Client Channel Pool – Improved Client Performance @ Glavs Blog
• Bate papo que me levou a este componente @ StackOverflow

[1] ABC = Address, Bindings e Contracts
[2] É possível consumir um serviço WCF sem acesso ao WSDL, mas este é um cenário pouco comum

Fui pesquisar, mas não encontrei nenhuma ferramenta gratuita web que pudessemos usar. Foi ai que surgiu o .NET Scrum. A idéia não é construir nada pra competir com o que existe por ai, mas utilizar da idéia pra ter um laboratório e construir um projeto onde possamos aplicar o que há de mais novo em tecnologia além de boas práticas de engenharia e condução de projetos.

Portanto, quem der uma olhada no projeto e quiser contribuir ou apenas acompanhar vai encontrar um ASP.NET MVC, jQuery, NHibernate usando interfaces fluentes, DDD, TDD, Spring.NET e outros frameworks e design patterns importantes para a construção de uma boa solução em .NET.

Se deixarmos de lado a parte tecnológica também é possível aprender um bocado trabalhando na organização de um projeto open source. Projetos de código aberto e mantidos pela comunidade são o maior caso de sucesso de times distribuidos trabalhando juntos a fim de atingir um objetivo. Se já é difícil obter sucesso em um projeto com o time no mesmo lugar, imagine trabalhar com pessoas que você nunca viu na vida e com comunicação relativamente limitada? Um grande desafio!

O Maurício Aniche que participa do DotNetArchitects já se juntou ao projeto pra me ajudar. Já existem alguns códigos publicados no codeplex e uma documentação miníma também. Quem quiser ajudar é mais do que bem vindo!

O local será o mesmo das outras vezes, na UNIP Jaguaré. Nesta semana o Giovanni irá falar um pouco a respeito de Domain Driven Design.

A participação é aberta e muito bem vinda. Quem ainda não mandou seus dados pode fazer pelo blog do Giovanni ou pelo grupo do Google onde também está disponível a pauta para próxima reunião.

Na última reunião falei sobre Scrum e o vídeo da apresentação está disponível aqui no blog e no site do grupo.

Para quem já sabe o que é mais não se juntou ainda ou não acompanha, faço um convite a conhecer através do nosso não-muito-joia-ainda site e se juntar também ao nosso grupo do Google onde algumas discussões bem legais já foram iniciadas.

Desde a primeira reunião do grupo combinamos que em todas as nossas reuniões alguém iria fazer uma apresentação para que posteriormente o grupo discutisse o assunto e a primeira apresentação sou eu quem vai fazer. A idéia não é dar uma aula ou falar como “o expert” do assunto, mas tentar passar experiências interessantes para todos.

Esta primeira apresentação vai ser a respeito de Scrum e como estamos utilizamos dentro da nossa equipe.

Na sequência da apresentação eu disponibilizo os slides aqui para quem não pôde ir. É possível que consigamos gravar a reunião. Se der certo, disponibilizo também por aqui.

Junte-se a nós!

Como o Giovanni já blogou sobre o que rolou na reunião não vale repetir tudo aqui, mas sim linkar para o post dele.

A reunião foi excelente, muito divertida e de um ótimo nível. Felizmente conseguimos reunir um grupo que não chegava em acordos sempre e isso é fundamental para crescermos.

Os interessados em entrar no grupo podem me mandar email, comentar aqui ou então postar no próprio blog do Giovanni. “Você decide”.

Enfim, a primeira reunião é sabado agora na UNIP da Marginal Pinheiros. Quem tiver interesse será muito bem vindo.

Os detalhes podem ser encontrados aqui no blog do Giovanni.

Esse é um documento, que apesar de antigo, é bastante interessante e ainda atual na maioria dos aspectos. Eu descobri esse documento cerca de uns 1 ano e meio atrás quando procurava melhores práticas para aplicar no primeiro sistema pelo qual eu seria responsável.

Sempre achei uma pena o fato de eles não manterem esse documento atualizado. Talvez isso acontecesse, pois é sempre complicado falar a respeito de arquiteturas de referência já que cada caso é um caso.

No entanto, pra nossa felicidade, eles lançaram uma nova versão esse mês e está disponível através deste link no Codeplex.

O documento apresenta quais decisões tomar e porque toma-las em uma série de cenários. Desde aplicações desktop até aplicações web com SOA e RIA.

Ainda não tive tempo de ir a fundo no documento, mas parece estar bastante atualizado.

Há algum tempo atrás, eu procurava saber porque raios alguém construiria uma aplicação utilizando WCF/Remoting/Web Services se essa aplicação não teria seus componentes de negócio reutilizados. Nunca entendi isso e achava um absurdo a Microsoft não disponibilizar nenhum “guia” (eu nunca achei, pelo menos) que dissesse quando devo distribuir as camadas de uma aplicação fisicamente e quando não. Infelizmente algumas coisas nós acabamos aprendendo só depois de aplicar e apanhar um pouco.

Nesse documento, pelo menos este ponto a Microsoft esclareceu e isso já é suficiente pra me deixar bastante feliz.

Esse documento não vai evitar que nós, desenvolvedores, cometamos erros, mas acredito que é muito importante os fornecedores de plataformas e tecnologias grandes como .NET se pronunciarem e fornecerem guias, mesmo que simples e com uma visão bem macro, para que as pessoas não fiquem perdidas e cometam erros demais em seus sistemas.

Ponto pra Microsoft.