Fragmental

Esqueci de avisar! Vou estar palestrando hoje no RioJug. basicamente a mesma palestra do evento em São Paulo.

http://www.riojug.org/conteudo.jsp?id=523

A revista Business 2.0 divulga no seu portal as 50 pessoas que são importantes neste momento para os negócios. Adivinha quem é o numero 34 numa lista que inclui Hugo Chavez.

Segunda-feira estou indo à Vitória, devo ficar até sexta. Alguém da terra me convida pra tomar uma heineken e jogar conversa fora?

Artigo sobre WebServices com XFire do Daniel Quirino Oliveira para a DevMedia!

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!

O Rodrigo Kumpera (famoso louds do GUJ) continua sua ótima sequência de posts, agora sobre paralelismo. Leia. Agora.

Há pouco mais de um ano, por influência das várias pessoas da UFSC que conheci nesta época e que viraram meus amigos, acabei começando a jogar jogos de tabuleiro importados (já que RPG toma tempo demais). Basicamente Settlers of Catan e Carcassone, com alguns outros de vez em quando. Bom saber que o Tio Fowler também se amarra e mais, que tem dicas de outros jogos :)

Acabo de ler Freakonomics, de Steven D. Levitt e Stephen J. Dubner. O livro é muito bom.

Eu não sabia bem o que esperar mas as ótimas revisões e o fato de eu achar uma versão pocket em inglês na livraria do saguão de Congonhas me fez comprar. Basicamente o livro examina dados sobre fenômenos inusitados, como a influência de nomes exóticos na vida das pessoas ou lutadores de sumô trapaceiros. A linha de pesquisa de Levitt é focada em trapaças que as pessoas fazem e como as descobrir com dados, ele fala de crime, educação pública e muito mais. Muito recomendado.

O Gabriel, Um dos caras mais escolados em C/C++ e otimização que conheço (alguém que escreve um parser SQL para uma base de dados num fim de semana em casa por falta de coisa melhor rpa fazer :D ) publicou um artigo no TheCodeProject. Vale a pena conferir o artigo sobre Hacked Ternary Tree em C, uma otimização em cima do conceito já otimizado de árvore ternária.

Para quem estava esperando e encheu a minha caixa postal e a do Guapo com e-mails (o que é bem legal, diga-se de passagem :D ) está disponível o código-fonte do meu último artigo.

Antes de mais nada quero deixar claro que a culpa no atraso foi minha unicamente, a Revista cumpriu seu papel, eu que tive problemas de tempo-espaço.

O código é basicamente o exemplo do texto (você não tem a revista ainda? Tá nas bancas, corre! - viu só, tô aprendendo marketing descarado…).

Como sei que muita gente estava esperando uma aplicação completa, o que fugia do escopo do texto, fiquem ligados que vocês vão ter uma surpresa em breve…