Recentemente participei do desenvolvimento da aplicação exemplo chamada de ScrumToys para demonstrar o maior número possível de funcionalidades do JSF 2.0. Boa parte do refactoring da arquitetura de componentes na camada de controle e modelo foi realizado por mim.
Alguns detalhes sobre as classes implementadas para suporte aos Managed Beans da aplicação ScrumToys estão disponíveis no blog da Globalcode: Um pouco sobre a arquitetura do ScrumToys.
As simplificações propostas nas classes implementadas na camada de controle serviram de referência para o desenvolvimento dos exemplos contidos no livro JavaServer Faces 2.0, The Complete Reference, escrito pelo Ed Burns, líder da especificação do JSF 2.0 no JCP, e pelo Chris Schalk, Developer Advocate no Google. Este livro implementa uma aplicação chamada Virtual Trainer ao usar a modelagem para gerenciamento do contexto de persistência e demarcação da transação via JTA através de classes base abstratas para os Managed Beans do JSF 2.0 no ScrumToys.
Um trecho do livro está disponível no Google Books e indica uma referência indireta à arquitetura proposta pelo ScrumToys.
O projeto ScrumToys foi incorporado à versão final do NetBeans 6.8 como uma demonstração de aplicação Web. O vídeo a seguir ilustra o uso do NetBeans para criar este projeto a partir de um wizard da ferramenta e permitir o acesso aos códigos de demonstração do JSF 2.0:
Em reconhecimento ao trabalho realizado, o Ed Burn faz referência à alguns desenvolvedores deste projeto no tópico Acknowledgments do livro.
Qual escolher? Qual o melhor? Êita decisão difícil!
Num comparativo realizado pela Info, o iPhone 3GS levou a melhor em alguns quesitos, mas o Motorola Milestone, além do Android 2.0, ganha em alguns pontos no hardware. Apesar da Motorola já oferecer um outro celular com Android (o Motorola Dext), no momento o Milestone é a nossa única opção com a versão mais nova do Android.
O Motorola Milestone conta com uma câmera fotográfica de 5M pixels contra a câmera de 3M pixels do iPhone. Além disso, o Milestone oferece flash através de LED e um certo nível de zoom. Contudo, o design quadradão do Milestone desanima qualquer um. Inclusive é chamado de Android de tiozão pela Info.
Tirando a câmera fotográfica e o sistema operacional aberto da Google (o Android) no Motorola Milestone, sem dúvida o iPhone se mostra melhor em vários aspectos, como comentado na avaliação da Info. O design e a usabilidade do iPhone são imbatíveis.
Apesar da velocidade proporcionada pelo Android, pela presença da Google, por ser mais simples de desenvolver aplicativos e disponibilizá-los sem muita burocracia para venda na loja online do Android, acabei optando pelo iPhone pelo design, facilidade de uso e excelente integração com o iTunes via um MacBook Pro que possuo. Contudo, achei muito chato não suportar multi-tarefa, ao sair do Skype para rodar outro aplicativo, o iPhone desconecta a minha conta Skype. Tem uma boa gambi para os programas serem atualizados periodicamente via a tecnologia de "push". Mas nem todo aplicativo suporta o "push".
Como disse o TK, que tem em mãos as duas plataformas, no seu twitter: "O iPhone é realmente um belo trabalho que oferece uma ótima experiência para o usuário. Como este trabalho de criar uma boa UI é valioso." (link) e "Testei o Android: funciona, rápido; muito legal e melhor que muito celular mais caro. Mas a interface com o usuário do iPhone é incomparável" (link).
E aí está uma pequena galeria de fotos do iPhone assim que chegou em casa:
Não pude deixar de notar que a operadora aqui na região que comercializa os dois celulares, oferece o iPhone e Milestone por quase o mesmo preço para o meu perfil de consumo de ligações e 3G. Portanto, a escolha foi difícil!
Este ano terei mais uma vez o privilégio de participar como palestrante do JavaOne, o maior evento Java do mundo.
No ano passado, com o tema "Enterprise Web 2.0 Architecture: from pristine Java EE to fully-loaded frameworks" (slides) e junto com o Vinicius Senger (sócio e co-fundador da Globalcode), apresentamos este tema num período de 60 minutos para uma sessão do tipo BoF (Birds of a Feather). Foi uma experiência ímpar apresentar uma palestra neste evento e totalmente em inglês.
Agora, para este ano, o tema será "Performance Tips and Tricks: Java EE, Persistence API and JavaServer Faces". Desta vez, vou apresentar junto com o Danival Calegari (arquiteto de software na Matera Systems e instrutor da unidade Globalcode em Campinas).
Neste evento teremos o objetivo de apresentar algumas técnicas (boas práticas atualizadas de desenvolvimento com JSF+JPA e design patterns) para melhorar a performance de aplicações Web 2.0 implementadas através de JSF com Ajax e acesso a banco de dados relacional via JPA com grande volume de dados. Para ilustrar estas técnicas, apresentaremos um estudo de caso através de uma aplicação usada como "implementação de referência" para ajudar a resolver problemas de performance encontrados em alguns projetos de consultoria realizados ao longo deste último ano.
O vídeo a seguir apresenta uma versão simplificada da aplicação demo que será usada para apresentar as "dicas&truques" sobre performance em aplicações Web 2.0:
O JavaOne 2010 acontecerá dos dias 19 a 23 de setembro em San Francisco, USA.
Segue uma tradução para português do resumo enviado para a organização do evento:
Dicas e Truques sobre performance em Java EE, JPA e JSF
"Desde o lançamento do JavaServer Faces no Java EE, tornou-se possível desenvolver aplicações Web 2.0 usando um modelo efetivo de componentes visuais com a mesma semântica de aplicações desktop baseando em Swing. O modelo de eventos tornou-se efetivo após a popularização do Ajax ao promover RIA. Todavia, performance e escalabilidade são afetadas por velhos padrões de projetos quando são aplicados na arquitetura da aplicação. Novos padrões de projeto devem ser aplicados para atingir os requisitos de performance neste novo cenário.
Esta sessão apresentará algumas dicas e truques para melhoria efetiva da performance de interfaces Web usando Ajax e o gerenciamento do contexto de persistência JPA."
Até a data do evento, vamos melhorar a aplicação de referência, preparar os slides em inglês e refinar o texto do que será dito durante a apresentação.
Mais importante no momento é ser gratuito do que ser open-source. Entre uma instalação pirata e uma licença a ser paga variando de R$ 150,00 à R$ 800,00, é muito melhor usar uma opção gratuita que tem a mesma qualidade e oferece os mesmos recursos.
2. Disponível nas plataformas Linux, Windows e Mac
Independência de plataforma. Temos defendido tanto isso com Java ... porque não com o editor de textos? O Open Document Format é um padrão aberto que vai além do OpenOffice, podemos enviar um mesmo documento para ser aberto em sistemas operacionais diferentes. Em pouco tempo poderíamos abrir os mesmos documentos em software diferentes. Eu uso muito o Ubuntu (Linux), outros só usam Windows e alguns fanboys usam o Mac. Temos tudo isso dentro de muitas empresas. Então porque não trabalhar com um pacote office que funciona em qualquer uma destas plataformas?
3. Oferece as mesmas funcionalidades que o MS Office
Todas as funcionalidades que usamos no dia-a-dia do M$ Office estão disponíveis no OpenOffice. Podemos enumerar algumas: criação de estilos de formatação, registro de mudanças, fontes, figuras, ilustrações, gráficos, etc. Inclusive a criação de templates para permitir a criação rápida de novos documentos. Foi fácil importar os estilos visuais definidos nos documentos word para odf. O mesmo efeito visual foi reproduzido!
A funcionalidade templates não é exclusiva do M$ Office. No OpenOffice é tão simples quanto no M$ Office a criação de um template. Podemos usar a mesma estratégia que muitos usam ao criar templates do M$O: limpa um documento já pronto e salva como template (Save as). A importação de um doc de restaurou todos os estilos visuais usados nas apostilas (tais como: TT_TITULO1, TT_TITULO2, TT_TITULO3, TT_CABECALHO, TT_CABECALHO_DIREITO, TT_CONTRACAPA e outros). Portanto, no OpenOffice conseguimos reproduzir perfeitamente o padrão visual de documentos importados do word. Este trabalho deve ser feito apenas uma vez, agora só salvar um template. Voialá! Podemos fazer o mesmo para o padrão de slides! Muitos templates estão disponíveis na rede, vários estão disponíveis no BROffice.org.
4. Permite abrir, editar e salvar nos formatos do MS Office (doc, ppt e xls)
Se recebermos um documento criado no M$ Office conseguimos abrir facilmente através do OpenOffice. Claro que algumas formatações podem ser perdidas. Mas isso está tendendo a zero a cada nova versão do OO, e já nas últimas versões (3.1 e 3.2) é muito difícil encontrar algo que é perdido. Contudo, M$ Office não abre documentos do OpenOffice :(
5. Permite exportar para PDF a partir de qualquer documento
Este é um recurso extra que já é nativo! Não precisamos instalar uma impressora especial ou algum plugin para o editor.
6. Tem disponível uma iniciativa brasileira através do BROffice.org
BROffice é uma comunidade brasileira criada em torno do OO para uma distribuição bem regionalizada, com direito a dicionário de palavras em português para suportar o corretor ortográfico, corretor gramatical, dicionário de sinônimos e temáticos, repositório de templates abertos e livre com atas, termos, declarações, contratos, distratos, recibos, relatórios, requerimentos, trabalhos acadêmicos (monografia, projeto de pesquisa, outros), etc. Tam free e open-source!
7. Não usa VBA para programação de macros
Uhuuu ... Podemos usar Java ou Javascript para criar macros! Tempos atrás eu comecei a fazer um script para abrir e exportar diversos slides (ODF presentation do Impress) para criar um book de slides num arquivo PDF. Funcionou bem! Todas as estruturas do OpenOffice estão disponíveis como classes e objetos Java na programação de macros ... mamão-com-açucar ... piece-of-cake! Não poderia ser mais fácil!
Estes argumentos apresentam apenas um ponto de vista e um cenário que me permitiu justificar o uso do OpenOffice. Mas sei que em outros cenários o M$ Office é a melhor opção. Você teria algum outro argumento em favor do OpenOffice? Ou algum cenário em que seria mais apropriado o M$ Office? Ou quer invalidar algum argumento? Deixe os seus comentários.
Alguns twitters atrás o brother @rafanunes pediu algumas sugestões de podcast. Rapidamente eu enviei através do twitter algumas sugestões de podcast que acompanho. Sabiamente, por estar antenada e sempre ponderando em como tirar o melhor proveito do twitter, a @yarasenger me alertou sobre a volatilidade do twitter e recomendou-me documentar as sugestões num post no blog. Ela citou que as mensagens no twitter podem se perder rapidamente dentro dos vários posts que uma pessoa recebe quando acompanha várias outras pessoas ou quando acessa com pouca freqüência o twitter. Então, aqui estão as sugestões que indiquei para o brother:
twit.tv - Leo Laporte and friends: Este cara tem vários podcasts com notícias e comentários sobre segurança e tecnologia. Muito bom para desenvolver o ouvido para o inglês. As várias discussões usam o inglês na velocidade normal. Além de ajudar a se manter atualizado, nos ajuda a ter outros pontos de vista sobre a tecnologia com uma visão crítica.
Buzz Out Loud: Este podcast segue a linha do Leo Laporte. Tenho acompanhado este podcast a mais de 4 anos. Os primeiros episódios tinham um inglês numa velocidade moderada, agora são 3 pessoas discutindo tecnologia e as últimas novidades numa velocidade impressionante. Uma pessoa sempre interrompendo outra e comentando as notícias recentes. Eles publicam um episódio novo quase que diariamente. Considero um nível avançado. Muito bom! Já estão com mais de 1000 episódios gravados. Agora estão disponibilizando videocasts gravados com o vídeo gravado durante a realização dos episódios.
Java Posse: São caras da Microsoft, Java e google falando de tudo sobre estas plataformas. Cada um tentando puxar a sardinha pro seu lado. Muito legal ...
BBC podcasts: São podcasts dos mais variados assuntos, que vão desde tecnologia até música, atualidades e política internacional.
World Nerds: Discutem sobre a origem das palavras em inglês e o uso em diversos contextos. Além das diferenças entre o inglês britânico e americano (não apenas pronuncia, mas significados principalmente). Contudo, este podcast está um pouco parado.
ELSPOD - English as a Second Language Podcast: Muito bom para desenvolver o ouvido pro inglês. Numa velocidade menor, assuntos sobre atualidades e cultura norte america são apresentados neste podcast. Por curiosidade, o narrador deste podcast foi o ator na serie Star War que interpretou o Chewbaca (bicho peludo que acompanhava o Han Solo - Harrison Ford).
Maestro Billy: Episódios semanais com uma compilação de várias músicas. Muito bom para saber o que anda rolando nas rádios e pistas.
VOANews Learning English: Muito bom para desenvolver o ouvido para o inglês. São narrações de textos, com direito a transcrição no site, de atualidades, história america, curiosidades, política, etc. Sempre num inglês claro, sem gírias, 1/3 da velocidade normal dos diálogos. Mas também tem uma rádio online, em velocidade normal de conversação, parecida com a CBN.
Acompanho todos estes podcasts através de configuração no Google Reader. Dá para rodar o áudio sem acessar o site de cada podcast, além de saber quando algum episódio novo está disponível.
Caso tenha outras sugestões para complementar o portifólio apresentado, não deixe de escrever nos comentários. Seria muito bom estar atualizado com sugestões.
Definitivamente o modelo de componentização definido no Java EE 5 e 6 evoluiu e melhorou muito. Mas, sem dúvida muita dessa evolução se deve às pressões do Hibernate e Spring Framework. Estes dois últimos frameworks nasceram baseados no conceito de POJO, que nada mais é do que a concepção de um modelo de componentização baseado em classes Java sem as regras impostas pelo EJB (curioso, sem o EJB não existiria o Hibernate ou o Spring).
O Hibernate nasceu da idéia de promover um modelo de persistência mais simples que o proposto pelos EJBs do tipo Entity Beans definido na especificação EJB 2.x. Este foi o primeiro tipo de EJB a sofrer com a evasão de desenvolvedores com o surgimento deste framework e a conscientização sobre os problemas nos Entity Beans. A partir de um modelo baseado em JavaBeans e o uso do JDBC, o Hibernate usa a Reflection API para gerar os SQLs necessários para persistir o estado de beans em diversos banco de dados relacionais, além de definir o conceito de dialeto para resolver as diferenças de sintaxe do SQL usado entre as diferentes implementações de banco de dados. Ao resolver efetivamente a persistência dos objetos em banco de dados relacional, a morte dos entity beans estava decretada. Não foi atoa que no Java EE 5, numa tentativa de resgatar um padrão efetivo entre os desenvolvedores, surgiu o JPA usando os mesmos conceitos do Hibernate e promovendo uma API padrão com base em vários dos seus conceitos. A morte oficial dos entity beans no EJB!
Já o Spring Framework nasceu para combater os problemas resultantes das idéias usadas nas definições de outro tipo fundamental de componente do modelo proposto pelos EJBs: os Session Beans. Usando a mesma proposta do Hibernate, o Spring Framework adotou o JavaBean como modelo de componentização aliado aos serviços enterprise com o auxílio da programação orientada a aspectos (AOP). Assim, o Spring Framework decretou a morte dos EJBs do tipo Session Beans.
O Java EE 5, apesar de manter compatibilidade com as versões anteriores, aplica os mesmos conceitos usados pelo Hibernate e Spring Framework (JavaBeans e injeção de dependências, por exemplo), numa tentativa de evitar o êxodo de desenvolvedores da padronização. Dando o braço a torcer, o EJB 3 aplica um modelo baseado em POJOs (que ironia!) até eliminar a obrigatoriedade das interfaces home, remota e local (favorecendo uma modelagem OO efetiva, uso de herança, polimorfismo, design patterns e interfaces de negócios). Contudo, o Java EE 5 trouxe uma novidade que impôs uma evolução nos frameworks que foram os seus carrascos: O uso de anotações para eliminar configurações em XML. Poderíamos dizer que o EJB 3 não é uma mera cópia dos conceitos usados no Hibernate e Spring, mas também traz uma inovação ao fazer copy/paste/modify. Curioso foi ver que o Hibernate e o Spring foram obrigados a evoluir.
Contudo, podemos notar que o EJB 3.0 deixou de fora muitas das melhorias já presentes no Hibernate/Spring. No JPA 1.0 podemos notar a falta do mecanismo de "Criteria" e no EJB a falta de uma modularização mais flexível além dos tradicionais JAR, WAR e EAR. Tanto que agora no EJB 3.1 e JPA 2.0, várias melhorias tentam eliminar as deficiências reclamadas pela comunidade que já não existiam em versões antigas do Hibernate e Spring Framework.
Muitos se questionam hoje se deveriam usar o Hibernate e o Spring considerando as evoluções do EJB 3 e JPA estabelecidas pelo Java EE 5 e 6. Acredito que pela simplicidade e padronização proporcionados no Java EE deveríamos usar o EJB e JPA. Mas, considerando as limitações deveríamos levar em consideração o uso do Hibernate e do Spring Framework. Apesar de não serem frameworks padrões, e por isso mesmo, não estão limitados às imposições políticas de vários interesses, estes frameworks têm a liberdade de evoluir e experimentar idéias inviáveis até o momento no Java EE, além de propiciar a integração com outros frameworks que também não são padrões e são legados ainda em uso pela comunidade (por exemplo: Struts, iText, Quartz, etc). Muitos conhecem as vantagens de usar o Hibernate diretamente em detrimento das limitações do JPA. No Spring temos a modularização através de OSGi e o uso pleno do AOP como parte da modelagem dos componentes de negócios das aplicações enterprise.
Apesar das melhorias amplamente comentadas no Java EE 6 através do EJB 3.1 e JPA 2.0, ainda é evidente muitas das vantagens do uso direto do Hibernate e do Spring Framework.
No TDC2009 realizado pela Globalcode em São Paulo eu apresentei um Lightning Talk sobre um problema específico de performance em aplicações Web com JPA e uma possível solução usando o Spring Web Flow.
Num período de 15 minutos, os slides a seguir foram apresentados e seguidos de alguns vídeos de demonstração de uma aplicação Web em execução.
Nesta apresentação foi dito que temos encontrado problemas de performance em aplicações Web que utilizam as tecnologias JSF + JPA + Ajax quando precisamos gerenciar um contexto de persistência (EntityManager). Este problemas se manifestam quando aplicamos uma resposta errada para a pergunta: Como gerenciar o contexto de persistência numa aplicação Web?
Se as aplicações não usam Ajax e limitam-se ao modelo orientado a requisições, a solução mais comum é o uso do design pattern chamado "Open Session In View Filter". Através deste design pattern, um contexto de persistência novo é aberto no início de uma requisição Web através de um filtro e fechado ao final desta requisição pelo mesmo filtro. Durante o processamento da requisição, as entidades persistente carregadas não geram erros (LazyInitializationException, por exemplo) porque o contexto de persistência ainda esta aberto. Mas se estas entidades são armazenadas no escopo de sessão, muitos erros podem acontecer quando estes objetos são usados numa outra requisição. Para resolver estes erros, muitos desenvolvedores utilizam o artifício de navegar nas associações, ou reinserir (merge) as entidades no novo contexto de persistência ou recarregar/salvar várias vezes estas entidades. Estas implementações degradam consideravelmente a performance da aplicação, além de inviabilizar o uso efetivo de cache de objetos, normalmente encontrado nas implementações de JPA.
O problema de performance é agravado quando a aplicação usa intensamente o modelo orientado a eventos. Este modelo é a tendência natural dos sistemas Web 2.0, principalmente pela mudança de paradigma de desenvolvimento Web proporcionado pelo JSF e Ajax. Ao longo de uma sessão de uso da aplicação e acesso às telas, muitas requisições assíncronas são enviadas para a aplicação no lado do servidor. A cada requisição, um novo contexto de persistência é aberto e fechado se o design pattern sugerido anteriormente é aplicado. Portanto, a resposta para a primeira pergunta não é o uso deste design pattern e muito menos os "workarounds" para os efeitos colaterais resultantes do uso deste padrão no novo modelo orientado a eventos.
Uma solução proposta e aplicada na prática está baseada no uso do conceito de escopo de conversação. Um escopo numa aplicação web define uma visibilidade e um tempo de vida dos objetos armazenados no servidor. Atualmente, um contâiner Web implementa os escopos de página, requisição, sessão e aplicação. O JSF 1.2 usa estes mesmos escopos e o JSF 2.0 adiciona os escopos View e Custom (que permite a criação de novos escopos). Já o Spring Framework disponibiliza os escopos singleton, prototype, request e session. Contudo, nenhum destes escopos tem a visibilidade por usuário e, ao mesmo tempo, o tempo de vida entre uma requisição e uma sessão como requerido pelo escopo de conversação. Mas, os frameworks Spring Web Flow, Seam Framework e Apache MyFaces Orchestra implementam este escopo e permitem o gerenciamento automático de um contexto de persistência neste escopo.
Então, uma solução efetiva para os problemas de performance e erros numa aplicação que usa JPA e o modelo orientado a eventos é o uso do escopo de conversação implementado por um dos frameworks sugeridos. Na aplicação web a ser demonstrada foi escolhido o Spring Web Flow por ser um dos produtos do Spring Portifolio, utilizar as mesmas boas práticas do Spring Framework, ter um baixo risco de se tornar um produto descontinuado e ser fácil de integrar numa arquitetura já baseada no Spring Framework + JSF + JPA.
O uso do Spring Web Flow (SWF) permitiu o fim dos erros de LazyInitializationException, o uso efetivo de cache das entidades persistentes, redução da quantidade de objetos na sessão, suporte a paginação, filtro e ordenação já na camada de apresentação com uma forte integração com o mecanismo de persistência JPA. Contudo, o SWF na versão atual (v.2) ainda requer o uso de XML para determinar quando uma conversação é iniciada e quando será destruída. Além de ser necessário realizar um "merge" das entidades ao final da conversação para atualizar na base de dados as possíveis alterações em memória.
Os vídeos de demonstração a seguir ilustram o funcionamento da uma aplicação web realizada através de uma implementação de referência que usa Spring Framework 2.5, JSF 1.2, JPA 1.0, Richfaces 3.3, Facelets 1.1.15, Spring Web Flow 2.0, Hibernate (JPA Provider) e MySQL 5.0.
TDC2009 Video Demo 1
TDC2009 Video Demo 2
TDC2009 Video Demo 3
Este último vídeo demonstra o poder do Lazy Loading a medida que os painéis são abertos e fechados. Como o contexto de persistência permanece disponível durante o período do escopo de conversação aberto, tornou-se possível carregar da base de dados somente alguns objetos e depois os outros objetos a medida que os painéis são expandidos. Os logs apresentados através do NetBeans neste vídeo ilustram a carga sob demanda dos objetos. Também ilustra o uso do cache nos objetos já carregados quando painéis que já foram expandidos são abertos novamente. Neste caso, nenhum log de consulta ao banco de dados aparece no NetBeans.
Consultor e arquiteto de software que desenvolve sistemas para a Web com tecnologias OO, banco de dados e Java desde '96. Um techno-freak, apaixonado e evangelista das novas tecnologias e arquiteturas para o desenvolvimento de sistemas complexos de software.
Consultant and software architect, hosted at Brazil, that develop systems to Web with OO technologies, databases and Java since '96. A techno-freak, lover and evangelist of new technologies and architectures to the development of complex systems of software.
Recentemente participei do desenvolvimento da aplicação exemplo chamada de ScrumToys para demonstrar o maior número possível de funcionalidades do JSF 2.0. Boa parte do refactoring da arquitetura de componentes na camada de controle e modelo foi realizado por mim.
As simplificações propostas nas classes implementadas na camada de controle serviram de referência para o desenvolvimento dos exemplos contidos no livro JavaServer Faces 2.0, The Complete Reference, escrito pelo Ed Burns, líder da especificação do JSF 2.0 no JCP, e pelo Chris Schalk, Developer Advocate no Google. Este livro implementa uma aplicação chamada Virtual Trainer ao usar a modelagem para gerenciamento do contexto de persistência e demarcação da transação via JTA através de classes base abstratas para os Managed Beans do JSF 2.0 no ScrumToys.
