Para quem se interessar, o pessoal da Red Hat está disponibilizando aos poucos todas as apresentações do evento no site da JBoss World.
Tirei também algumas fotos das apresentações que fui e do evento em geral. Vejam no meu Flickr!
Muito legal o evento, espero ser convidado novamente para ir no ano que vem 🙂
Max Ross, do Google, fez uma apresentação sobre o Hibernate Shards.
Desenvolvido em 6 meses como um “pet project” (projeto pessoal) usando 20% do tempo de 3 engenheiros, o Hibernate Shards foi lançado internamente no Google em dezembro de 2006 e depois doado para a JBoss em maio de 2007.
“Shard” é um termo que o pessoal do Google usa para falar de divisão/particionamento. O Hibernate Shards é um framework de persistência baseado no Hibernate, usado para dividir os dados entre vários bancos de dados diferentes, criando um particionamento horizontal das informações.
Resumidamente, o particionamento horizontal é usado quando você têm aplicações com bancos de dados monstruosamente grandes e você precisa distribuí-los em vários bancos de dados. Então, você tem várias instâncias de banco de dados diferentes, todas com o mesmo schema, e com os dados divididos entre elas. Quem gerencia onde está cada banco de dados e em qual “shard” (partição/bucket/o que você quiser) estão os dados é o Hibernate Shards, de forma transparente para a aplicação. O Shards pode usar qualquer banco de dados suportado pelo Hibernate (ele tira vantagem dos dialects).
Os criadores do projeto queriam que fosse fácil e natural para os usuários de Hibernate usá-lo, por isso ele usa vários conceitos familiares como, por exemplo, a ShardedSessionFactory, que implementa a interface SessionFactory. Eles tem uma ShardedSession, e por aí vai.
Apesar do Shards ser totalmente compatível com Hibernate do ponto de vista da aplicação (porque usa as mesmas interfaces), ele não suporta JPA, a implementação de Query ainda não funciona 100% e vários outros probleminhas e “gaps” em relação ao Hibernate…
Confesso que fiquei um pouco decepcionado, porque pelo que eu tinha conversado com o pessoal por aí, parecia que ele seria uma forma de ter um schema distribuído em vários bancos de dados diferentes, e isso ia resolver um problema gigante que tenho. Mas descobrí que isso que eu preciso é particionamento vertical. Perguntei para o Max se daria para fazer alguma adaptação e ele falou que até seria possível escrever um ShardStrategy que quebrasse um galho, mas eu teria muitos problemas maiores pra resolver.
Ao menos serviu para conhecer esses conceitos de banco de dados, que de certa forma eu conhecia mas não da maneira formal.
Mladen Turk acabou de fazer sua apresentação sobre o JBoss Web Server, que é um web server/container baseado no Tomcat, projetado para aplicações de médio e grande porte. Ele suporta Java (JSPs, Servlets, etc), PHP, e CGI. Basicamente ele concorre com o Tomcat, com a vantagem de que é excelente para prover conteúdo estático, lidar com milhares de requisições simultâneas e tem um container web bem razoável, suficiente para a maioria das aplicações.
É óbvio que o criador dele só poderia falar que ele é ótimo, então a opinião dele é suspeita. Mas o fato é que na Globo.com temos usado JBoss Web em várias aplicações e de fato ele é muito bom. Ele realmente aguenta o tranco de milhares de acessos e definitivamente é muito mais estável que o Tomcat, e muito mais leve que o JBoss. IMHO, ele é o mais completo da atualidade e é a minha primeira escolha para os tipos de projetos que tenho trabalhado (web applications que não usam EJBs, JMS e as parafernalhas mais complexas do Java EE).
As principais vantagens do JBoss Web sobre o Tomcat são:
O objetivo do JBoss Web não é substituir o Apache, nem o Tomcat, nem o JBoss. Se você tiver aplicações tradicionais onde um Apache é suficiente (conteúdo estático + PHP, por exemplo), use-o. Se você for usar JSP/Servlets para um site pequeno-médio, talvez a melhor opção seja mesmo o Tomcat. Se você precisar processar EJBs, certamente vai precisar de um full JEE application server. Além disso, o JBoss Web não têm a variedade de módulos que o Apache tem, e também não tem um foco grande em segurança. Mesmo assim, é mais uma excelente carta na manga.
Há algum tempo eu queria escrever sobre virtualização. Essa palestra do Isaac Christoffersen e do Dan Santillo, da Booz Allen Hamilton, foi o impulso que faltava.
Como esse é um assunto que muita gente não conhece, vou colar aqui a definição da wikipedia sobre virtualização:
“[Virtualization is] a technique for hiding the physical characteristics of computing resources from the way in which other systems, applications, or end users interact with those resources. This includes making a single physical resource (such as a server, an operating system, an application, or storage device) appear to function as multiple logical resources; or it can include making multiple physical resources (such as storage devices or servers) appear as a single logical resource.”
Agora, falando em português curto e grosso e transportando para o nosso contexto (aplicações web): virtualização seria basicamente fazer com que as aplicações que rodam em clusters de várias máquinas passem a rodar em clusters de menos máquinas, onde em cada uma delas teria várias instâncias de sistemas operacionais. Ou seja, rodar vários sistemas operacionais em uma mesma máquina em paralelo. Com isso você mantêm o número de instâncias da aplicação, porém usando menos máquinas. Para isso pode-se usar VMWare ou Xen, por exemplo.
Muitas empresas hoje gastam milhões de dólares com hardware, como uma solução de contorno para software de qualidade ruim. E quando se gasta milhões comprando, naturalmente se gasta vários outros milhões mantendo essa infraestrutura, e não dá para crescer. Muitas vezes o hardware é super-dimensionado, e fica “90% idle” na maior parte do tempo.
As aplicações cliente-servidor de antigamente muitas vezes precisavam apenas de 1 servidor de banco de dados para funcionar (só para centralizar os dados, na verdade). Nos dias de hoje, com N-camadas e arquiteturas baseadas em SOA, as aplicações podem ser resultado da composição de dezenas de serviços, e cada um desses serviços pode estar instalado em dezenas de máquinas. Resumindo: hoje em dia temos aplicações que rodam em centenas, talvez milhares de máquinas.
E onde que a virtualização se encaixa nisso tudo? Vamos lá, vamos imaginar um cenário. Imagine uma aplicação que roda em um cluster de 20 máquinas, e que nos horários de pico a utilização de CPU chega a no máximo 5% ou 10%. Ou seja, você tem 90% de máquina sobrando o tempo inteiro! Com virtualização, uma estratégia poderia ser fazer com que esse mesmo cluster funcionasse em 5 máquinas, e cada máquina teria 4 instâncias de sistema operacional. Ou seja, cada sistema operacional ficaria com 25% da máquina original, que como vimos, é mais do que o dobro e o suficiente para ela funcionar. Resumindo: mesmo resultado e 1/4 dos recursos necessários.
Temos várias vantagens com essa abordagem:
Sou apenas um curioso e não um especialista nesse assunto, mas com certeza essa é uma área que vai crescer muito nos próximos anos.
No nosso laboratório na Globo.com, já fazemos experiências com virtualização há algum tempo e temos inclusive deploys virtualizados de algumas aplicações para teste. Agora precisamos colocar para funcionar!
James Ward, evangelista da Adobe, fez uma apresentação muito legal sobre como criar Rich Internet Applitacions com Flex, usando back-ends robustos em Java com JBoss.
Essa apresentação teve muito a ver com o artigo que ele publicou no InfoQ sobre como portar aplicações HTML tradicionais para Flex, escrito em conjunto com Shashank Tiwari (mais detalhes no blog do James).
No início ele mostrou um demo sensacional de uma aplicação de seguros que eles migraram de “web 1.0” para Flex. Realmente o poder das interfaces ricas é impressionante. Outro demo interessante foi do eBay Desktop, que tem uma boa combinação de HTML e Flash (usando o Adobe AIR), resultando em uma interface muito bonita e funcional.
Ultimamente na Globo.com temos trabalhado muito com Flash, por causa do player do Globo Vídeos. Antes disso eu nunca tinha trabalhado com Flash e talvez por isso nunca tenha tido a oportunidade de sentir tão de perto seu potencial. Flash/Flex/AS3/AIR/etc abrem um novo mundo de possibilidades, dando o poder de criar interfaces com usabilidade e interatividade excelentes, e ainda com um forte apelo visual.
Ele apresentou o conceito de “SOARIA” (aliás, quando ele falou isso eu comecei a rir sozinho, parecia que ele estava falando “sorria”). O que ele chama de SOARIA significa SOA + RIA, ou seja, aplicações ricas (RIA) que interagem com o back-end através de serviços (SOA). IMHO, acho essa abordagem muito legal, porque evita aquela dependência cíclica que sempre acaba se formando entre o Flash e a aplicação.
No final, vimos um benchmark interessante, comparando vários modelos de carregamento de dados em aplicações RIA usando Flex, Laszlo e Javascript/Ajax, integradas com serviços SOAP, pure-XML, HTML e JSON. O benchmark analisa como cada um desses modelos impacta em performance, consumo de banda e consumo de memória na máquina cliente. Fiquei surpreso com os resultados… Por exemplo, a aplicação mostra que o Dojo tem uma performance surpreendentemente ruim quando comparado a aplicações Flex, que têm uma performance normalmente superior a todas as outras (atenção, se você for rodar os testes não se esqueça de desabilitar o Firebug antes!).
A Adobe realmente acertou com o Action Script 3, Flex, AIR e todos esses novos produtos que têm sido lançados. Tenho que tirar o chapéu.
Acabei de participar de um BOF com Emmanuel Bernard, Gavin King, Pete Muir, Max Andersen e mais uma dezena de pessoas.
O assunto era desenvolvimento de aplicações usando Hibernate, Seam e outras coisas mais da Red Hat. Dentre as várias coisas que foram discutidas, falamos sobre o Hibernate Validator.
O Hibernate Validator me incomoda, e é um pouco complicado de explicar o motivo, mas eu vou tentar. Na verdade não é o Validator em sí, mas as suas annotations. Vejamos um exemplo de código traduzido da página Validator. A sintaxe é muito simples e mesmo que você não saiba exatamente como funciona provavelmente conseguirá entender:
public class Endereco { @NotNull private String rua; private String cep; private String estado; @Length(max = 20) @NotNull private String pais; @Range(min = -2, max = 50, message = "Andar invalido") public int andar; ... } |
Na minha concepção, quando usamos o Hibernate Validator dessa forma, passamos a ter regras de negócio/validação do objeto fora do seu controle, e essas regras não estão fortemente encapsuladas. A verificação de que um endereço deve ter no máximo 20 caracteres, por exemplo, deveria estar encapsulada dentro de um método que cria/atualiza o endereço, e não numa annotation.
Existe uma discussão muito grande sobre isso. De um lado, os “puristas” acreditam que colocar annotations num objeto de domínio significa acoplar esses objetos à infraestrutura e implementações específicas. Do outro lado, os “práticos” acham que isso não tem o menor problema, que na prática o efeito colateral disso é nulo.
Eu sinceramente fico meio dividido. O que eu sei é que isso de alguma forma me incomoda. Estou acostumado a pensar de um modo “Domain-Driven Design”, e para mim o mais natural e certo seria que essa regra estivesse dentro de algum método.
Se você pensar que sua aplicação pode usar todas essas coisas juntas com esses quilos de annotations (Seam, Hibernate, Validator, Guice, etc, etc), no final você vai ter objetos de domínio altamente acoplados à toda a infraestrutura da aplicação. Pior ainda quando essas annotations tem regras de negócio. Os objetos vão acabar se tornando meros “fantoches” controlados por annotations… Isso definitivamente não parece ser bom.
A apresentação do Emmanuel Bernard sobre Hibernate foi muito boa. Inicialmente o Gavin King também iria participar, mas ele acabou não chegando a tempo. Fiquei com medo achando que eles fossem falar sobre coisas muito básicas que todo mundo já conhece, mas ao invés disso o Emmanuel se preocupou justamente em falar sobre coisas que as pessoas não estão muito acostumadas a ver por aí, como estratégias de replicação e ResultTransformers, por exemplo.
O Emmanuel deu uma visão muito ampla do que eles planejam para o futuro. O roadmap do Hibernate para as próximas versões (3.x), que serão lançadas durante os próximos meses, incluem dentre outras coisas o seguinte:
Quando o Hibernate se torna um impecilho para o desenvolvimento porque não te dá a flexibilidade que você precisa, use um “proxy” para JDBC provido pelo Hibernate.
Usada para operações em batch, esta API permitirá a inserção de milhões de objetos sem erros de “out of memory”, facilitará o desenvolvimento de tarefas para rodar em intervalos de tempo determinados (tipo cron jobs) e coisas do tipo.
Já o Hibernate 4.0, que não tem data marcada para sair e parece que não vai ser tão cedo, tem uma lista de features muito mais extensa e “agressiva”. Basicamente essa nova versão do Hibernate será focada nos seguintes objetivos:
Versionamento automático e transparente de dados “out of the box”.
Uma das idéias é que não seja mais necessário registrar as entities em um arquivo de configuração, só a annotation @Entity será necessária.
Outros projetos mais novos como Hibernate Search, Hibernate Validator e Hibernate Shards ganharão mais foco.
Tudo isso automaticamente nos remete ao assunto Java Persistence API. A JPA foi lançada com um conjunto de featues muito pequeno que simplesmente não atende qualquer caso que não seja feijão-com-arroz. O que normalmente acaba acontecendo é que você sempre tem que recorrer a features específicas do Hibernate para resolver casos mais complexos. Isso simplesmente elimina o papel da JPA, que seria manter a aplicação desacoplada de um “vendor” específico. Então, o Emmanuel também falou um pouco do que podemos esperar para a JPA para resolver esses problemas:
Estou partindo daqui a pouquinho para a JBoss World 2008 em Orlando.
O evento é bem especializado nos produtos da Red Hat, o que me deixa com o pé um pouco atrás (tomara que não seja daqueles eventos ultra-“marketeiros”). Pela agenda do evento, dá pra esperar coisas interessantes.
Espero poder conhecer mais de algumas coisas que já ouví falar bem, como o Drools, Seam e Hibernate Search, além dos velhos conhecidos Hibernate, JBoss Cache, etc. Tem algumas apresentações sobre SOA e performance tuning que também podem ser interessantes.
Durante a semana vou contando aqui no blog o que está tendo de bom por lá.