Formando equipes de alto desempenho, parte 1: Início e fases de evolução
Nesta primeira parte de uma série sobre equipes de alto desempenho e gerenciamento Agile, veja uma introdução geral e uma apresentação dos estágios de formação das equipes.
Notícias
O conteúdo foi adicionado aos favoritos!
Houve um erro ao adicionar aos favoritos! Por favor, tente novamente.
Hibernate 4: multitenancy, extensões, OSGI e uma entrevista com o líder do projeto
Postado por Kostis Kapelonis , traduzido por Jeff Prestes em 24 Jan 2012
A JBoss lançou a versão 4 do Hibernate, o popular framework de mapeamento Objeto/Relacional (ORM). Entre as principais novidades:
- Suporte a multitenancy;
- Introdução de uma API de "Serviços"
- Aprimoramento de serviços de logging com suporte a internacionalização e códigos de mensagens (através do JBoss Logging, no lugar do slf4j);
- Preparação para suporte a OSGI;
- Diversas melhorias no código e remoção de código obsoleto.
Multitenancy é a habilidade de criar partições virtuais para cada cliente (tenant) dentro de uma grande aplicação corporativa, em vez de dispor todos os dados em um espaço compartilhado. Esse princípio traz melhorias em gerência, monitoramento e até mesmo na segurança dos dados, e é muito útil para grandes provedores de serviços. Empresas que fornecem infraestruturas de cloud também podem se beneficiar dessa abordagem.
Existem diferentes maneiras de implementar o multitenancy, entre elas:
- Criar um banco de dados ou esquema de dados exclusivo para cada cliente;
- Usar o mesmo banco de dados ou esquema para todos os clientes, mas com uma coluna adicional em todas tabelas (por exemplo tenant_id) utilizada para filtrar os dados.
Na versão 4, o Hibernate suporta a primeira abordagem. O suporte à segunda está planejado para a próxima versão.
Outra nova funcionalidade importante é uma API interna de Serviços, que proporciona formas de expansão dos serviços padrão do framework. Já havia nas versões anteriores plugins capazes de acessar e estender funcionalidades internas do Hibernate, mas a nova API oferece uma forma padrão de expansão.
O InfoQ falou com o líder do projeto Hibernate, Steve Ebersole, para conhecer mais sobre as novas funcionalidades.
InfoQ: Poderia nos explicar o conceito de Serviços? Estes seriam utilizados somente para o desenvolvimento de extensões do Hibernate, ou a tecnologia poderia também ser útil para desenvolvedores de aplicações?
Primeiro é importante entender que muitos desenvolvedores já criam extensões do Hibernate. Se você já desenvolve listeners de eventos ou tipos personalizados, já está desenvolvendo extensões.
Considere a API de Serviços como uma pequena CDI de domínio específico, que traz uma maneira unificada de lidar com comportamentos e necessidades comuns, como ciclo de vida, dependências, gerência de JMX etc. Por esse prisma, podemos sim imaginar desenvolvedores criando serviços. Um exemplo seria um listener de eventos integrado ao JMS. A integração com o JMS pode ser considerada um serviço, pois outros listeners e extensões personalizadas poderiam reaproveitar essa integração.
A ideia de serviços é bastante ampla. De forma geral, não imagino código de aplicações utilizando serviços diretamente, mas isso não implica que todos verão a funcionalidade da mesma forma. Voltando ao exemplo do JMS, poderíamos imaginar código de aplicações interagindo com aquela conexão ao JMS; as aplicações estariam basicamente lançando mão do Hibernate para gerenciar seu ciclo de vida geral.
InfoQ: O quanto é importante o OSGI para vocês? Estamos próximos do suporte completo ao OSGI no Hibernate?
Na minha experiência, quando perguntamos o que realmente significa ter "suporte a OSGI" ou ser "aderente ao OSGI", obtemos respostas muito diferentes de cada pessoa. Na minha opinião, há duas questões envolvidas.
Primeiro, o Hibernate é capaz de trabalhar com o aspecto de carregamento modular de classes dos ambientes OSGI? Isto era complicado antes da versão 4.0, pois o Hibernate presumia uma configuração convencional de clasloaders. Na versão 4.0, um dos serviços padrão é o ClassLoaderService que define como o Hibernate localiza classes e recursos e como é feita a resolução dos ServiceLoaders do Java. Essencialmente, é definida uma API para todas as interações do Hibernate com o classpath, de maneira modular. A intenção é que ambientes de carregamento de classes não tradicionais possam adotar suas próprias estratégias de interação. Isto já está bem testado no JBoss AS, que inclui um ClassLoaderService personalizado para interagir com o carregamento de classes modular. Neste aspecto, portanto, o Hibernate já chegou lá.
Segundo, o Hibernate define bem os seus próprios "metadados de OSGI", em termos de importações e exportações? Hoje o Hibernate não define metadados específicos ao OSGI em seus JARs. Ninguém da equipe do Hibernate é especialista em OSGI; seria um trabalho para os desenvolvedores fluentes nesse padrão. Quando alguém contribuir funcionalidades nessa área, vamos incluí-las! Mas um passo que foi dado na versão 4.0 foi dividir os pacotes para deixar mais claro o público-alvo de cada um. Isso deve simplificar a especificação das funcionalidades a serem exportadas em cada pacote.
InfoQ. Por que o framework de logging foi alterado?
Ao começar o desenvolvimento do Hibernate 4, vimos que era fundamental o suporte a internacionalização no mecanismo de logging. Naquele momento o JBoss Logging era a única biblioteca de logging com suporte completo a internacionalização, incluindo parametrização.
Além disso, o JBoss Logging inclui suporte nativo a chaves de mensagens, tratando-as de maneira diferente daquelas em um ResourceBoundle. Uma chave imutável é associada a uma condição que leva a mensagem a ser registrada no log. Essa é uma boa base para a construção de FAQs e de documentação sobre as chaves. É verdade que se pode fazer algo similar usando diretamente o SLF4J, o java.util.logging etc. Mas da perspectiva de suporte a ferramentas, é importantíssimo que as chaves sejam cidadãs de primeira classe. Para um projeto extenso, com muitas mensagens de log, devemos ser capazes de verificar que as chaves são únicas e consistentes. O JBoss Logging também traz essa funcionalidade.
InfoQ. As novas características da versão 4.0 são mais internas. Isso significa que o Hibernate chegou a um nível de maturidade em que não haverá mais mudanças visíveis aos usuários? O Hibernate estaria indo para o "modo de manutenção"?
Não, definitivamente o Hibernate não está entrando em modo de manutenção, no sentido de que não haverá mais o desenvolvimento de novas funcionalidades. Mas o Hibernate tem mais de dez anos, em que foram sendo acumulandos remendos. Acho que simplesmente chegamos num momento em que devemos parar de colar remendos sobre remendos ao criar novas funcionalidades. O Hibernate cresceu sobre os princípios de design YAGNI ("você não vai precisar"), e se deve considerar que contratos e APIs se tornam naturalmente mais claros com o tempo.
Sei de poucos projetos open source em Java que tiveram sucesso e permaneceram relevantes por tanto tempo; e todos estes passaram por uma ou mais grandes refatorações.
InfoQ. O que podemos esperar do Hibernate 5?
O foco principal da versão 5.0 será em reprojetar o modelo usado para organizar os metadados objeto-relacionais (O/R), tanto para XML como para anotações. Esse código surgiu das necessidades iniciais do Hibernate, e novos requisitos vindos do JPA ou do desenvolvimento de novas funcionalidades foram sendo agregados sem reestruturação. O principal motivo foi que muitos projetos usam essas classes e queríamos manter a compatibilidade, mas chegou o momento de repensar esse modelo.
Os artefatos do Hibernate 4 já estão no Maven Central.
Nenhum comentário
Acompanhar Discussão Responder