Como falei, terminei há pouco o Freakonomics e a linha “vamos destruir o senso comum” tem feito bastante parte dos meus pensamentos. É impressionante como falsas impressões estão espalhadas em todo lugar, intencionalmente ou não, e como tecnologia também está infestada.
É preciso prestar atenção ao fato que as pessoas gostam do senso comum. E por que gostam? Porque é muito cômodo e simples. O que você acha mais fácil: ler um estudo de trinta páginas sobre como uma linguagem de bytecode pode ser mais rápida que uma linguagem nativa em condições de concorrência ou acreditar cegamente no mantra “C++ é mais rápido que Java”?
É por isso, por exemplo, que Dan Brown faz sucesso. Eu nunca li o Código da Vinci (nem é nenhuma aversão, apenas tem uma prioridade muito baixa na minha lista) mas li Fortaleza Digital. O que ele faz é colocar algo entendível nos primeiros capítulos e seguir usando e abusando do senso comum. A Igreja é má. A NSA é má. Corporações são malvadas. Sociedades secretas escondem segredos que afetam o mundo todo. Professores universitários são super-inteligentes. Tudo isso é repetido ad nauseam e todos se acham inteligentes com o livrinho. Um exemplo é como ele tenta explicar criptografia: uma cifra básica de transposição. Pronto, depois ele começa a falar (besteiras) sobre cifras mutantes, ataques de força bruta, chaves públicas… e como o leitor já entendeu o que é uma cifra de transposição começa a acreditar que tudo se resume àquilo (imagine a cara de um CEO ao ler esse livro e olhar pro orçamento de segurança da informação…).
Eu estou na fase da especificação de arquitetura (tantas fases…) de um sistema distribuído baseado em componentes distribuídos numa rede coorporativa, algo próximo de SOA (Componentes Distribuídos não são Serviços Distribuídos). Durante uma conversa sobre os critérios de distribuição, não demorou muito (nuca demora…) para que alguém sugerisse distribuição máxima, possibilidade de colocar os componentes na mesma máquina, um em cada, nenhum…
Quando me dei conta da conversa já se especulava a criação de um arquivo EAR (uma ‘aplicação’ em Java EE) para cada componente. Argh!
Bom, vamos lá. Primeira pergunta: qual a vantagem em fazer isso? Depois da eventual perplexidade (eu nunca me acostumo à cara que alguém faz quando é perguntado isso por um arquiteto) o comentário foi: performance e escalabilidade.
Ótimo. Segunda pergunta: Por que temos mais performance com este tipo de arquitetura? Silêncio. Após um minuto alguém diz: por que nós podemos colocar os serviços mais utilizados me máquinas melhores e também ter redundância.
Terceira pergunta: Por que simplesmente não criar um cluster de servidores de aplicação? Resposta imediata: por que eu posso não querer que um componente esteja em uma máquina.
Quarta pergunta: por que não desabilita o componente em questão? Silêncio.
Então a proposta: vamos criar um cluster e deixar o resto a cargo de nosso excelente (cof cof) servidor de aplicações.
Aí vem a pergunta deles: mas por que evitar isso a todo custo? Sistemas distribuídos não eram pra ser…uhm… distribuídos?
Simples. Primeira Lei de Fowler sobre Objetos Distribuídos (citada em meu documento de arquitetura :) ): Não distribua seus objetos..
A maior dificuldade citada por Martin Fowler é a comunicação entre componentes distribuídos, os chamados a funções (e objetos, no caso) remotas. Note que esse problema não é tão recente, sempre se pensou em como minimizar as chamadas e daí surgiram coisas como os Data Transfer Objects.
Opa! Mais uma vítima do senso comum a vista. Quase todo profissional Java já leu, viu ou ouviu falar deste livro. Este é um catálogo de Padrões arquiteturais e de projeto para aplicações em Java 2 EE (o Java EE até a versão 1.4). E este livro fala bastante de DTOs, chamados na primeira edição de Value Objects, os famosos VO de Java.
Ótimo, mas… uma leitura mais atenta mostra que esse livro fala quase exclusivamente de arquiteturas com EJBs 2.1, e quase ninguém precisa de EJBs 2.1. DTOs são usados para passar por cima de algumas limitações na arquitetura com EJBs… então se eu não tenho EJBs (ou melhor: se não tenho Entity Beans) pra que DTOs? Como é mais fácil assumir que DTOs são necessários em qualquer arquitetura Java do que ler este livro e pensar um pouco nós temos mais um mito do senso comum, e eu pessoalmente luto contra este fazem uns bons 3 anos e sei como é difícil tirar isso da cabeça dos outros.
Então, voltando, minimizando a comunicação entre componentes distribuídos nós simplificamos o sistema (ou você acha que criar, gerenciar e dar manutenção em centenas de DTOs é simples?) e acabamos deixando mais rápido, já que só existirão chamadas locais. Se você realmente precisa de muita distribuição com muita performance, um sistema de cache distribuído pode ser o ideal, mas acredite: você não precisa. Quase sempre.
Considerando que hoje em dia é SOA pra cá, WebServices pra lá, como se lida com estes problemas?
A estratégia utilizada em SOA não tem nada de novo nem revolucionário nem mágico, é apenas aumentar a granularidade das operações. Isso pode ser um pouco confuso, então vamos a um exemplinho.
Imagine-se armado com um possante modem externo US Robotics de 33.300bps (se você nunca usou qualquer modem abaixo de 56kbps pense em algo muito lento) utilizando o chat do UOL (algo bem mil-novecentos-e-noventa-e-alguma-coisa mesmo) numa sala de bate-papo lotada de pessoas. A cada mensagem que alguém manda com seu “Alguém quer tc?” seu browser precisa se conectar ao servidor, baixar a atualização e renderizar novamente a tela. PRA CADA MENSAGEM!
Bem, com SOA estamos neste cenário só que ao invés de sermos nós os impacientes tecladores dos chats são nossos sistemas. Por mais infra-estrutura que se tenha existem limites que simplesmente não podem ser ultrapassados.
E como se resolvia este problema na época da Internet á lenha? Se você trabalhou com Web nesta época sabe que a lei era: economizar refresh (recarregar a página inteira). Isso que fazia termos páginas com milhares de frames, iframes e outras bizarrices para minimizar a troca de dados. Note: o problema não era a quantidade de dados mas a frequência. Ainda que custoso era melhor carregar 200kb do que fazer dez requisições de 20kb.
Então geralmente os sites tinham grandes formulários, em vez dos formulários de várias páginas. Nestes grandes (e desengonçados) formulários o usuário colocava o máximo de informação que fosse viável e pressionava ’submit’, minimizando a quantidade de vezes que se trocam dados.
É como dar entrada num requerimento numa repartição pública (tenho que tomar cuidado ao falar de repartições públicas…). Imagine que cada vez que o funcionário precisasse do seu nome, CPF, data de nascimento ou fosse te avisar da conclusão do processo ele tivesse que ligar pra sua casa (e se tratando da burocracia dos serviços públicos brasileiros provavelmente ele ia ter que dar entrada num requerimento próprio para usar o telefone…). O ideal é você preencher um formulário com os dados necessários e deixar nas mãos de algum responsável para que ele consulte quando precisar dos seus dados e quando terminar você receba um comprovante ou documento produto desta operação.
Isto é ocasionalmente chamado de Request/Response ao invés do RPC clássico (se Request/Response é RPC ou não é uma discussão que eu deixo pra próxima). É nisso que SOA se baseia.
Você manda uma mensagem para uma aplicação, ela processa e devolve algo. Este é o cenário ideal para uma aplicação SOA: mínimo possível de interação.
Como já falei acima nada disso é novidade para quem estuda Sistemas Distribuídos. A diferença é que com Microsoft, IBM, Sun e todos os outros meninos jogando isso na cabeça de todo mundo vai virar senso comum.
E aí Zahl nos ajude!