Existem recursos que viabilizam o desempenho em aplicações Web de forma aceitável para o usuário final. Entre elas, na minha opinião, o mais adequado é o Ajax. Existem outras alternativas como o Flex, porém, dependendo da aplicação desenvolvido pode haver demora no carregamento e processamento das requisições, mesmo sendo carregada uma única vez. Com base nisso, a utilização do Flex sobre uma intranet é uma excelente opção. Como o contexto é a internet, soluções Ajax levam vantagem pelo fato do conteúdo ser apresentado em HTML/XHTML e pelo fato de não utilizar nenhum plugin para os navegadores. Porém, quando se trata de JavaScript, muitos desenvolvedores tentam evitar por ser mais uma linguagem necessária para o aprendizado para desenvolver uma aplicação. Ironicamente, um desenvolvedor web necessita saber no mínimo três linguagens para desenvolver uma aplicação utilizável.

Em alguns casos, a utilização do javascript em alguns projetos torna-se complicada devido a dificuldade, principalmente quando projetos são feitos utilizado AJAX. Isso encorajou a criação de inúmeros frameworks e componentes que tentam tornar o desenvolvimento de aplicações que utilizam AJAX mais simples e fáceis de manter.

JQuery é um framework que tenta facilitar ao máximo a utilização de JavaScript nas páginas, sendo que, é a ferramenta mais utilizada quando se trata de recursos para a linguagem. O que chama mais atenção são os efeitos e a facilidade para desenvolver com essa ferramenta.

A comunidade Java é privilegiada com inúmeros frameworks e APIs que facilitam o desenvolvimento resolvendo problemas de vários segmentos, principalmente WEB. Acredito que, devido a dificuldade de desenvolver aplicações WEB apenas com JSP, Servlets, Filters, TagLibs, etc., os desenvolvedores tentaram diminuir essa dificuldade com frameworks, tai então a explicação da grande quantidade de frameworks WEB para Java.

Em Java, atualmente, o frameworks WEB mais utilizado, depois do Struts (legado) , é o JSF. Talvez devido ao fato de ser um produto da Sun e estar coberto por uma especificação. Não cheguei a ver detalhes da especificação 2.0, mas nas versões anteriores o desenvolvimento ainda é maçante e chato, onde existem situações que necessitam cada vez da habilidade do desenvolvedor. Porém, muito foi feito para tentar corrigir os problemas e ao mesmo tempo agregar valor ao framework com as extensões repletas de componentes para ser utilizados nos projetos, uma dessas extensões é o RichFaces. Atualmente encontra-se na versão 3.3 e vem uma série de componentes que podem funcionar sobre uma camada AJAX. A facilidade é tanta que a forma de desenvolver é a quase a mesma que desenvolver com JSF puro. Com isso, está a disposição do desenvolvedor recursos de Drag’nDrop, calendários bem elaborados, efeitos, e uma série de componentes bem desenvolvidos que funcionam sobre AJAX.  A configuração do RichFaces também é simples, basta adicionar alguns filtros, escolher o template, ou desenvolver um, configurar um ou dois XMLs e adicionar algumas taglibs no projeto e pronto, seu projeto já está configurado.

O objetivo desse artigo não é de escrever um tutorial e nem comparar as ferramentas, é de alertar sobre a má utilização dos recursos AJAX na aplicação com o RichFaces. O framework utiliza JQuery para fazer os efeitos e manipular do DOM HTML/XHTML, com isso, o conteúdo do framework vai junto com o projeto. A infra-instrutora de um projeto AJAX é repleta de JavaScript e quando projetos se tornam  complexos, conseqüentemente, a complexidades de manter os script se eleva. Com isso, existe uma estrutura de arquivos javascript pronta para suportar a arvore JSF gerada a cada requisição tornando a estrutura pesada ao ponto de ser desvantagem desenvolver a aplicação baseada em requests sobre toda a página.

Destrinchando o conteúdo carregado pelo browser, existe um tipo de arquivo que representa a chamada de sua URL que é respondida a cada requisição, é configurada no web.xml na definição da chamada para a execução do servlet. Nesses arquivos contem o emaranhado do Javascript que o servidor envia a cada requisição. No meu caso, esses arquivos ficaram em torno de 933Kb, é um tamanho considerável quando se trata de requisições. Isso pode deixar sua aplicação uma carroça quando sua aplicação for pro ar.

Nessa situação, a solução para esse problema é aplicar ao máximo os recursos AJAX na aplicação, fazendo com que apenas um trecho da página possa ser renderizada e não todo a cada requisição. Isso diminui bastante o tráfego na rede tornando a aplicação um pouco mais leve. Nas primeiras solicitações a aplicação fica muito lenta, mas quando o conteúdo está no cache o desempenho fica razoável.

Para comprovar, fiz um teste desenvolvendo uma página simples com um CSS pequeno e sem nenhum arquivo JavaScript amais. Fiz as configurações dos pacotes JSF e do RichFaces descritas em seus devidos manuais respectivamente. Fiz com que a primeira página utilizasse um apenas um <a4j:region > contendo alguns componentes, como; <a4j:form> e  um <a4j:commandLink>. Isso é suficiente para habilitar o suporte AJAX do framework, ou seja, carregando todos os JavaScript responsáveis por essa funcionalidade.

Na documentação do framework não existem tópicos que auxiliem a diminuir o tamanho do conteúdo, isso encoraja a utilização massiva dos recursos em todas as páginas e evitando request desnecessários. Não quero dizer que o framework seja ruim, pelo contrário, é uma ótima ferramenta, porém, deve ser utilizada com cuidado. A utilização de AJAX puro é uma excelente opção.

[]s.

Alem das funcionalidades do contexto de persistência também podemos contar com as funcionalidades extras que foram desenvolvidas pelo time de desenvolvimento, hoje pertencente a JBoss. Estou falando do pacote hibernate-tools.jar, contido no plugin feito para o eclipse, com o intuito de auxiliar no processo de configuração, mapeamento, importação de schemas e mecanismo de interpretação e execução de HQL. O link para download do plugin encontra-se aqui.

Tive a necessidade de fazer com que todo o schema fosse exportado para o banco de dados ao executar uma simples task do Ant. Funcionalidade que facilitaria muito a vida da equipe ao modificar o mapeamento das entidades do projeto, sendo apenas necessário executar a task para exportar as modificações para o SGBD. Para isso, desenvolvi uma task personalizada para solucionar esse problema. A task funcionava bem, mas chegou um ponto que não nos atendia. Portanto, vi que uma boa alternativa seria utilizar as tasks do hibernate-tools.

O pacote hibernate-tools.jar contem um conjunto de tasks que permitem a execução de procedimentos básicos de persistência através de simples tasks do Ant. As tasks são variadas, portanto é possível utiliza-las para; exportar schemas, gerar os inserts do mapeamento em um arquivo .sql, gerar os hbm.xml (se não tiver utilizando anotações) entre outras coisas. Mais um detalhe: o pacote hibernate-tools.jar é completamente independente do plugin.

A configuração para utilizar as tasks a princípio é simples, porém levei um tempo para acertar, já que meu projeto estava mal configurado e gastei muito tempo para descobrir o problema. Vou levar em conta que o seu projeto está devidamente configurado e fazendo todas as operações básicas (insert, update e delete) no banco de dados.

Para uma simples exportação do schema para o banco de dados, a primeira coisa que você deve fazer é adicionar o pacote hibernate-tools.jar no classpath do projeto. Após isso é necessário incluir uma referencia a classe que representa a task. Nesse caso, assim como está abaixo:

<taskdef name="hibernatetool" classname="org.hibernate.tool.ant.HibernateToolTask" classpathref="path.lib" />

Após isso, é necessário incluir um target que fará todo o trabalho sujo. Nessa target deve conter, dentro do <hibernatetool>, no mínimo as tasks <annotationconfiguration/> e <hbm2ddl/> para fazer o processo de configuração e a exportação de todas as configurações de mapeamento incluídas nas classes. Vamos ver o detalhe abaixo:


<target name="generate" depends="compile">
<hibernatetool destdir="${dir.build}/generated">
<classpath>
<path location="${dir.out.classes}"></path>
</classpath>
<annotationconfiguration propertyfile="${dir.out.classes}/hibernate.properties"  configurationfile="${dir.out.classes}/hibernate.cfg.xml" />
<hbm2ddl drop="true" create="true" export="true" outputfilename="../schema.sql" delimiter=";" format="true" />
<hbm2dao />
</hibernatetool>
</target>

Reparem que é necessário ter os .class incluídos no <classpath/> como descrito acima, pois é daí que vem todo o mapeamento dos objetos. A propriedade <annotationconfiguration/> representa as configurações do seu SGBD (hibernate.properties) e das classes persistentes (hibernate.cfg.xml). Claro que o arquivo cfg.xml pode conter as configurações do SGBD mas eu achei melhor separá-los.

A task <hbm2dll/> é o elemento principal do processo de exportação do schema. Nela é possível definir se, ao exportar o schema, irá dropar as tabelas existentes e criar uma nova estrutura e além do mais irá criar um arquivo .sql contendo tudo o que foi feito no banco.

Adicionei a task <hbm2dao/> apenas para mostrar o DAO gerado conforme as entidades geradas. Acredito que isso seja útil para os projetos que não utilizam o suporte aos DAOs do Hibernate do Spring.

Bom pessoal, esse foi um processo que me atendeu perfeitamente nos projetos que desenvolvo, portanto, segue a dica para os leitores. Chega de ficar mexendo nas propriedades hibernate.hbm2ddl.auto create-drop e escrever tarks personalizadas para essa tarefa.

[]s

Com a curiosidade a tona decidi baixar o JAR, junto com os fontes do projeto, para ver do que se tratava e como era feito essa proeza. Notei que era um framework que fazia um processo de serialização da JVM de forma mais elaborada com logs, transações e integridade dos objetos persistidos. Ou seja, um mecanismo de persistência simples e que atendia a aplicações de pequeno porte. A empolgação foi tanta que até fiz minha monografia da faculdade sobre ele.

Ter disponível um framework que implemente um novo conceito de persistência chamou atenção não só de brasileiros, tanto que muitos desenvolvedores se juntaram no desenvolvimento do frameworks, plugins para Eclipse e uma implementação do SQL para consultar objetos “prevalecidos”. Ma o que aconteceu? Porque não vingou? Bom, a resposta dessas perguntas eu não tenho. As suposições são muitas. Uma delas seria a aceitação e a barreira da mudança de paradigmas. Muitos até tiveram boa intenção de utilizar em suas aplicações. Um exemplo disso é o ThinFeeder e portal JavaFree. Lembro que o JavaFree teve uma série de problemas de concorrência ao disponibilizar o portal com a camada de persistência com prevayler.

Deixei de acompanhar a evolução do framework já faz um tempo, acredito que tenham resolvido os velhos problemas de concorrência, portanto não tenho em detalhes das melhorias e de novas funcionalidades do framework. Porém, acredito que seria uma boa oportunidade de investir na evolução desse framework polêmico. Quem tiver curiosidade o site do projeto está aqui.

O projeto encontra-se maduro, porém, a quebra de paradigmas ainda é uma barreira para a adoção do framework em suas aplicações. Tentar aceitar que um framework de persistência de objetos possa dar conta de suas aplicações tendo uma série de SGDBs disponíveis realmente é uma coisa difícil.

[]s

Olá pessoal,

Em primeiro lugar um feliz ano novo a todos vocês que visitam esse blog. Depois de alguns dias sem colocar nada aqui venho disponibilizar algumas informações sobre um framewok que ta tirando o meu sono, não por ser difícil e chato, mas por me fazereu ver o desenvolvimento web, com Java, uma forma diferente de desenvolver. Li a JavaMagazine 58 e depois de alguns meses resolvi baixar o dito cujo pra dar uma olhada.

Realmente, pra mim foi um pouco esquisito. Acostumado com o desenvolvimento tradicional (Request, Response, Sessions e Forward) vi nesse framework uma maneira mais intuitiva de desenvolver aplicações WEB. Seu modelo de manipulação de conteúdo dinâmico é baseado em markups em arquivos HTML, ou seja, todos os arquivos HTMLs devem estar na mesma estrutura de pacotes na qual se encontra suas WebPages, coisa de louco. Para mim isso foi coisa de outro mundo, mas depois que você começa a escrever os exemplos e ter maior afinidade com o mesmo, só então é possível se acostumar.

Em paralelo com isso, também estou estudando RoR. Talvez esteja aí o segredo para uma aceitação com pouco trauma as mudanças de paradigmas.

Ainda não utilizei o Wicket em algum projeto, porém vontade não falta. Portanto pessoal, fica ai a dica de um framework poderoso e inovador. Os desenvolvedores do Wicket realmente fizeram um excelente trabalho.

Pelo fato da plataforma ser complexa, foram criados inúmeros frameworks com o objetivo de minimizar os detalhes. Entre os mais populares e robustos está o Globus ToolKit , recomendado pela Globus Aliance . O Globus ToolKit é um conjunto de ferramentas que tenta cobrir todas as necessidades relacionadas a Grid Computing. Porém, é complexa e ao mesmo tempo pesada.

Uma alternativa para aplicações de pequeno e médio porte é o Grid Gain. Framework escrito em Java, mantido por Nikita Ivanov, que demonstra ser muito eficiente e simples de utilizar, já que não necessita de muitas das funcionalidades contidas no Globus Toolkit.

Agora, se você for construir uma aplicação que roda na infraestrutura do LHC, SETI@HOME ou similares, aconselho você usar o Globus ou implementar um do zero.

Muitos desenvolvedores que utilizam Hibernate como camada de persistência já se depararam com problemas de Lazy Load, principalmente em aplicações WEB. Isso acontece quando esquecemos de ler a documentação do produto referente a utilização nesse ambiente. O resultado disso são sucessíveis erros referente a sessões duplicadas na aplicação.

Deixamos isso de lado, pois esse problema será discutido em outro post. Vamos nos concentrar no que é esse tal de Lazy Load.

• Lazy Load
  

Lazy Load(Carga Preguiçosa) nada mais é um padrão de projetos utilizado na maioria dos frameworks de persistência, com implementações específicas para cada arquitetura. A justificativa da sua utilização é de minimizar a carga dos objetos que possuem relacionamento com o objeto solicitado, carregando a lista de coleções apenas quando acessado.

O hibernate habilita o recurso Lazy Load por padrão para evitar que os objeto relacionados sejam carregados por parão. Porém, em alguns casos a utilização desse recurso deve ser controlada. Principalmente no caso que as tabelas referenciadas pelos objetos persistes estão repletas de informações. Nesse caso, deve ser utilizado um recursos como HQL/SQL, consultas embutidas ou tá mesmo configurações que limitam a carga total das tabelas.

A mágica contida na implementação do padrão está no trabalho com conjunto com outros padrões de projetos aplicando técnicas de desenvolvimento. Padrões de projetos como o proxy que tem a finalidade de prover um wraper que instancia e inicia os objetos solicitados. Técnicas com a instrumentação de código que encapsulam funcionalidades extras nas classes persistentes. Para que isso aconteça, o mapeamento, em conjunto com as configurações, devem ser bem feitas para tornar toda a aplicação funcional.

• Desenvolvimento de aplicações WEB com Hibernate

Desenvolver aplicações WEB que utilizam hibernate é uma tarefa desafiadora para desenvolvedores de primeira viagem, principalmente quando o projeto tem diversos relacionamentos e requer constante acesso a bases de dados. Participei de alguns projetos que esses problemas vieram a tona e foram resolvidos. Nos próximos posts publicarei algumas técnicas que foram utilizadas para resolver os problemas de Lazy Load, transações, múltiplas sessões e open session in view.

]]> http://www.nelsonalone.com.br/2008/10/20/hibernate-dicas-para-desenvolvedores/feed/ 0