Como parte da iniciativa Adote uma JSR (adopt-a-jsr) promovida pelo grupo de usuários SouJava, foi realizado via web, um workshop de introdução sobre o projeto ScrumToys. Este projeto é uma pequena aplicação Web implementada com os recursos do JavaServer Faces 2.0 do Java EE 5 que foi incorporada à ferramenta NetBeans para demonstração das diversas funcionalidades do JSF. Neste workshop foram apresentados, ao longo de uma hora e meia, detalhes da arquitetura interna, as principais funcionalidades demonstradas do JSF e como contribuir nas evoluções futuras deste projeto.
Está disponível no Youtube o vídeo do workshop de introdução ao projeto ScrumToys.
Os slides utilizados neste workshop já estão no slideshare.
Enjoy it!
By Spock
Twitter: @drspockbr
http://blog.spock.com.br/
http://linkedin.spock.com.br/
Mostrando postagens com marcador java. Mostrar todas as postagens
Mostrando postagens com marcador java. Mostrar todas as postagens
sexta-feira, 26 de outubro de 2012
segunda-feira, 4 de janeiro de 2010
EJB 3: Uma evolução sob os conceitos do Hibernate e Spring
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.
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.
domingo, 8 de novembro de 2009
Melhorando Performance de JPA com Spring Web Flow
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.
O TDC2009 em São Paulo foi fantástico!
By Spock
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.
O TDC2009 em São Paulo foi fantástico!
By Spock
segunda-feira, 24 de agosto de 2009
quarta-feira, 4 de fevereiro de 2009
Spring na Java Magazine by Spock
Finalmente consegui ter uma cópia da edição 65 da revista Java Magazine. Já fazem 10 dias que tive notícias de colegas que assinam a revista dizendo que já receberam. Mas, até hoje ainda não está nas bancas!
Estava ancioso para por as mãos nesta edição para ver como ficou o artigo que escrevi sobre o Spring Framework.
O artigo descreve uma aplicação simples e completa usando Spring Framework, JSF e JPA. Através de configurações em XML e anotações, os serviços de transação e persistência são ilustrados no desenvolvimento de DAOs e componentes de negócios gerenciados pelo Spring e acessados através de telas na web com JSF. As principais funcionalidades do Spring Framework e as partes que compõem o Spring Portfólio também são descritas neste artigo.
Uma aplicação completa para web é presentada, desde a modelagem simples de casos de uso até códigos em classes Java, interfaces e diagramas UML de classes e sequência, mostrando como usar o Spring Framwork para simplificar o desenvolvimento de aplicações.
Nem tudo é perfeito ... Por mais que revisemos o artigo e que exista um editor extremamente criterioso durante a revisão, sempre sobram alguns erros. Para a tranquilidade de todos, não são erros técnicos, mas sim, pequenos erros ortográficos e posicionamento de figuras e listagens em páginas diferente de onde são referênciados.
Aqui estão algumas erratas que encontei após uma nova leitura do texto através da revista:
De qualquer maneira, o artigo ficou muito bom e muito bem apresentado na Java Magazine. Está bem diagramado e com o conteúdo na medida certa. Contudo, para não estender o tamanho do texto, foi necessário colocar somente os códigos fontes e diagramas necessários para o entendimento do assunto apresentado. Em alguns códigos, trechos considerados irrelevantes foram omitidos sem prejuízo para a compreenção. Mas, a DevMedia disponibilizou para download o projeto Eclipse completo que fiz para a aplicação demonstrada no artigo. Quem se interessar pode fazer o download clicando aqui. O zip baixado tem um arquivo "leiame.txt" com os pré-requisitos e passos para instalação.
Show de bola foi a dobradinha com o artigo nesta mesma edição da Java Magazine que traz a tradução da entrevista com o Rod Johnson (criador do Spring e fundador da SpringSource) realizada no JavaOne2008. Eu ajudei a escrever algumas perguntas que foram realizadas pela Yara Senger (Globalcode) e Melissa Villela (Globalcode) durante o evento. Não perdi a oportunidade de questionar os seguintes pontos:
Por fim, comento no artigo os passos necessários para se tornar um profissional certificado em Spring Framework (S2CP - SpringSource Certified Professional). No início deste ano fiz a prova de certificação. Depois conto os detalhes em outro post.
Quem quiser comentar estes artigos da edição 65 da Java magazine é só mandar para blog@spock.com.br ou escrever comentários para este post.
Then, enjoy!
Estava ancioso para por as mãos nesta edição para ver como ficou o artigo que escrevi sobre o Spring Framework.
O artigo descreve uma aplicação simples e completa usando Spring Framework, JSF e JPA. Através de configurações em XML e anotações, os serviços de transação e persistência são ilustrados no desenvolvimento de DAOs e componentes de negócios gerenciados pelo Spring e acessados através de telas na web com JSF. As principais funcionalidades do Spring Framework e as partes que compõem o Spring Portfólio também são descritas neste artigo.
Uma aplicação completa para web é presentada, desde a modelagem simples de casos de uso até códigos em classes Java, interfaces e diagramas UML de classes e sequência, mostrando como usar o Spring Framwork para simplificar o desenvolvimento de aplicações.
Nem tudo é perfeito ... Por mais que revisemos o artigo e que exista um editor extremamente criterioso durante a revisão, sempre sobram alguns erros. Para a tranquilidade de todos, não são erros técnicos, mas sim, pequenos erros ortográficos e posicionamento de figuras e listagens em páginas diferente de onde são referênciados.
Aqui estão algumas erratas que encontei após uma nova leitura do texto através da revista:
- Pág. 54, 1a. coluna, 3o. parágrafo: A figura 1 citada aparece na página 53 exigindo do leitor a mudança de página;
- Pág. 60, 1a coluna, 3o parágrafo: Aparece a palavra "componentes" onde deveria ser "componente" resultando em: "Em alguns casos não é possível configurar um componente gerenciado pelo Spring através de anotações";
- Pág 60, 1a coluna, 3o e 4o parágrafos: O início do 4o parágrafo repete a mesma informação apresentada no final do 3o. parágrafo;
- Pág. 61, 1a coluna, 1o parágrafo: Uma das anotações do Spring está grafada com um s a mais: @Respository, e o certo seria: @Repository;
- Pág. 61, 1a coluna, 4o parágrafo: A listagem 5 é referenciada nesta página e o conteúdo desta listagem está na página 62, exigindo do leitor a mudança de página.
- Pág 63, 1a coluna: As listagens 7 e 8 são citadas nesta página, mas o conteúdo destas listagens estão na página 64, exigindo do leitor a mudança de página.
De qualquer maneira, o artigo ficou muito bom e muito bem apresentado na Java Magazine. Está bem diagramado e com o conteúdo na medida certa. Contudo, para não estender o tamanho do texto, foi necessário colocar somente os códigos fontes e diagramas necessários para o entendimento do assunto apresentado. Em alguns códigos, trechos considerados irrelevantes foram omitidos sem prejuízo para a compreenção. Mas, a DevMedia disponibilizou para download o projeto Eclipse completo que fiz para a aplicação demonstrada no artigo. Quem se interessar pode fazer o download clicando aqui. O zip baixado tem um arquivo "leiame.txt" com os pré-requisitos e passos para instalação.
Show de bola foi a dobradinha com o artigo nesta mesma edição da Java Magazine que traz a tradução da entrevista com o Rod Johnson (criador do Spring e fundador da SpringSource) realizada no JavaOne2008. Eu ajudei a escrever algumas perguntas que foram realizadas pela Yara Senger (Globalcode) e Melissa Villela (Globalcode) durante o evento. Não perdi a oportunidade de questionar os seguintes pontos:
- A plataforma Spring pretende ser uma alternativa viável à própria plataforma Java EE, e não apenas uma alternativa a EJB?
- Depois do EJB 3 no Java EE 5, porque deveríamos continuar usando Spring nas aplicações enterprise?
Por fim, comento no artigo os passos necessários para se tornar um profissional certificado em Spring Framework (S2CP - SpringSource Certified Professional). No início deste ano fiz a prova de certificação. Depois conto os detalhes em outro post.
Quem quiser comentar estes artigos da edição 65 da Java magazine é só mandar para blog@spock.com.br ou escrever comentários para este post.
Then, enjoy!
quarta-feira, 22 de outubro de 2008
LinkedIn usa Spring Framework
Achei muito legal ter lido no blog do Matt Raible (Raible Designs) que o site de relacionamentos profissionais LinkedIn usa Spring Framework.
Ele participou de uma palestra onde um integrante da equipe de desenvolvimento do site contou as experiências de uso do Spring. Interessante foram alguns números apresentados pelo Matt: 2 data centers (~600 máquinas), ~100 serviços (componentes), ~30-40 interfaces, ~1000 arquivos de configuração do Spring e atualmente 30 milhões de usuários com a taxa de crescimento de 1 milhão a cada 2-3 semanas! Uau! Tudo rodando num cluster de ~600 máquinas com o Tomcat! Isso mesmo, TOMCAT! Agora eles querem evoluir a solução para usar modularização através de OSGi e Spring Dynamic Modules for OSGi (que facilita tremendamente o uso de OSGi). Tudo isso para prover hotdeploy e múltiplas versões dos componentes, além da distribuição automatizada no ambiente em cluster.
Este mesmo caso de sucesso será apresentado no evento SpringOne que acontecerá no final deste ano nos USA com o título Case Study: Spring at LinkedIn.
Legal também foi a frase que vi no blog do pessoal do LinkedIn: LinkedIn is 99% Java but 100% Mac. Nos outros 1% estão usando C++, Ruby on Rails e Groovy/Grails.
Contudo, fiquei muito espantando quando soube que tem alguns poucos loucos querendo remover o Spring Framework de uma aplicação funcionando muito bem em produção simplesmente por ter birra do Spring e birra de frameworks. Se pelo menos estivessem substituíndo por EJB 3 ou JBoss Seam com um servidor de aplicações decente como o JBoss Application Server, aí eu aceitaria. Mas a insanidade leva a quererem usar servlets puro ou talvez Struts puro. Vai entender!
Quanto mais pesquiso sobre o Spring Framework vejo que tornou-se um padrão de fato. Não precisa ir muito longe em cliques ou páginas de resultado da busca no Google para ver muitos outros casos de sucesso de arquiteturas funcionando muito bem com o Spring Framework.
Não deixem de visitar o blog do pessoal do LinkedIn em (http://blog.linkedin.com/) ou o blog do Matt Raible em (http://raibledesigns.com/).
Ele participou de uma palestra onde um integrante da equipe de desenvolvimento do site contou as experiências de uso do Spring. Interessante foram alguns números apresentados pelo Matt: 2 data centers (~600 máquinas), ~100 serviços (componentes), ~30-40 interfaces, ~1000 arquivos de configuração do Spring e atualmente 30 milhões de usuários com a taxa de crescimento de 1 milhão a cada 2-3 semanas! Uau! Tudo rodando num cluster de ~600 máquinas com o Tomcat! Isso mesmo, TOMCAT! Agora eles querem evoluir a solução para usar modularização através de OSGi e Spring Dynamic Modules for OSGi (que facilita tremendamente o uso de OSGi). Tudo isso para prover hotdeploy e múltiplas versões dos componentes, além da distribuição automatizada no ambiente em cluster.
Este mesmo caso de sucesso será apresentado no evento SpringOne que acontecerá no final deste ano nos USA com o título Case Study: Spring at LinkedIn.
Legal também foi a frase que vi no blog do pessoal do LinkedIn: LinkedIn is 99% Java but 100% Mac. Nos outros 1% estão usando C++, Ruby on Rails e Groovy/Grails.
Contudo, fiquei muito espantando quando soube que tem alguns poucos loucos querendo remover o Spring Framework de uma aplicação funcionando muito bem em produção simplesmente por ter birra do Spring e birra de frameworks. Se pelo menos estivessem substituíndo por EJB 3 ou JBoss Seam com um servidor de aplicações decente como o JBoss Application Server, aí eu aceitaria. Mas a insanidade leva a quererem usar servlets puro ou talvez Struts puro. Vai entender!
Quanto mais pesquiso sobre o Spring Framework vejo que tornou-se um padrão de fato. Não precisa ir muito longe em cliques ou páginas de resultado da busca no Google para ver muitos outros casos de sucesso de arquiteturas funcionando muito bem com o Spring Framework.
Não deixem de visitar o blog do pessoal do LinkedIn em (http://blog.linkedin.com/) ou o blog do Matt Raible em (http://raibledesigns.com/).
segunda-feira, 13 de outubro de 2008
JBoss Seam: Injection vs Outjection
Injection - A capacidade do JBoss Seam de atribuir uma referência válida para um objeto (Seam Component) num atributo de outro componente. Esta capacidade é realizada através das anotações @In e @DataModelSelection, por exemplo. Quando o Seam encontra estas anotações num atributo de um Seam Component, localiza um objeto num dos contextos com o nome indicado e injeta no atributo.
Outjection - Que também podemos chamar de ejeção, é a capacidade do JBoss Seam de expor um objeto referenciado por um atributo de um Seam Component num dos contextos do Seam. Ejetar significa o Seam pegar a referência para um objeto armazenado num atributo privado de um Seam Component e armazenar num dos contextos com um nome associado. Ao expor o atributo, mesmo privado, este estará disponível para injeção em outros Seam Components via injection ou para acesso via Expression Language (EL) numa tela JSF. Esta capacidade é realizada pelo Seam através da anotação @Out. Contudo, no momento de ejetar um atributo como Seam Component num dos contextos, o Seam pode realizar alguma transformação do objeto como, por exemplo, na anotação @DataModel onde o Seam encapsula uma lista de objetos num JSF Data Model antes de armazená-lo no contexto. Assim, quando o usuário seleciona um item num Data Table numa tela JSF, o JSF sabe qual objeto foi selecionado e o Seam recupera este objeto para injetar num outro atributo do Seam Component que foi marcado com a anotação @DataModelSelection.
Sobre os contextos do Seam escrevi os posts Sobre os contextos do JBoss Seam e Seam Contexts Ilustrados. Neste último post cito a diferença entre Context Variable e Instance Variable. Considerando estes dois conceitos, podemos definir como injeção o movimento realizado pelo Seam de uma referência para um objeto do Context Variable para o Instance Variable. Já ejeção significa o movimento de um Instance Variable para um Context Variable. Nestes movimentos, o Seam pode realizar transformação dos objetos.
Outjection - Que também podemos chamar de ejeção, é a capacidade do JBoss Seam de expor um objeto referenciado por um atributo de um Seam Component num dos contextos do Seam. Ejetar significa o Seam pegar a referência para um objeto armazenado num atributo privado de um Seam Component e armazenar num dos contextos com um nome associado. Ao expor o atributo, mesmo privado, este estará disponível para injeção em outros Seam Components via injection ou para acesso via Expression Language (EL) numa tela JSF. Esta capacidade é realizada pelo Seam através da anotação @Out. Contudo, no momento de ejetar um atributo como Seam Component num dos contextos, o Seam pode realizar alguma transformação do objeto como, por exemplo, na anotação @DataModel onde o Seam encapsula uma lista de objetos num JSF Data Model antes de armazená-lo no contexto. Assim, quando o usuário seleciona um item num Data Table numa tela JSF, o JSF sabe qual objeto foi selecionado e o Seam recupera este objeto para injetar num outro atributo do Seam Component que foi marcado com a anotação @DataModelSelection.
Sobre os contextos do Seam escrevi os posts Sobre os contextos do JBoss Seam e Seam Contexts Ilustrados. Neste último post cito a diferença entre Context Variable e Instance Variable. Considerando estes dois conceitos, podemos definir como injeção o movimento realizado pelo Seam de uma referência para um objeto do Context Variable para o Instance Variable. Já ejeção significa o movimento de um Instance Variable para um Context Variable. Nestes movimentos, o Seam pode realizar transformação dos objetos.
- Anotações que realizam injeção: @In e @DataModelSelection.
- Anotações que realizam ejeção: @Out, @DataModel, @Factory e @Name.
quinta-feira, 25 de setembro de 2008
Spock na J... Magazine
Pensou besteira, heim?
Na verdade a revista Java Magazine, de circulação nacional e dedicada à tecnologia Java, publicou na última edição (no. 61, setembro/2008) um artigo escrito por mim e pela Yara Senger (diretora educational da Globalcode) com o título Facelets: Criando templates de telas no JSF. Este artigo apresenta a tecnologia Facelets para a construção de templates de telas com o JavaServer Faces (JSF) e a definição de componentes visuais customizados a partir de arquivos XHTML para aplicações Web.
No último JustJava realizamos uma prévia deste assunto através de uma palestra que comentei aqui no post Templates de Tela JSF e TagFiles com Facelets. Neste post encontram-se os slides da apresentação para visualização online e o link para download. Mas, o artigo só nas bancas!
Then, enjoy it! Any comment, let me know!
Na verdade a revista Java Magazine, de circulação nacional e dedicada à tecnologia Java, publicou na última edição (no. 61, setembro/2008) um artigo escrito por mim e pela Yara Senger (diretora educational da Globalcode) com o título Facelets: Criando templates de telas no JSF. Este artigo apresenta a tecnologia Facelets para a construção de templates de telas com o JavaServer Faces (JSF) e a definição de componentes visuais customizados a partir de arquivos XHTML para aplicações Web.
No último JustJava realizamos uma prévia deste assunto através de uma palestra que comentei aqui no post Templates de Tela JSF e TagFiles com Facelets. Neste post encontram-se os slides da apresentação para visualização online e o link para download. Mas, o artigo só nas bancas!
Then, enjoy it! Any comment, let me know!
domingo, 21 de setembro de 2008
Pencast do keynote de abertura JustJava2008
Usando a caneta mágica que roda Java, gravei o keynote de abertura do evento JustJava2008. Esta apresentação foi realizada pelo Bruno Souza (JavaMan), Yara Senger e Melissa Villela.
Durante a apresentação fiz algumas anotações no caderno e gravei o áudio usando o programa embutido na caneta chamado de "Paper Replay". O flash a seguir contem o pencast gerando pelo site de compartilhamento da Livescribe.
Clique no play para tocar ou na seta superior para full screen
Algumas fotos do evento estão disponíveis no álbum online da Globalcode.
Se desejar, deixe os seus comentários aqui neste post ou na home do pencast disponibilizado em My Livescribe Community.
Durante a apresentação fiz algumas anotações no caderno e gravei o áudio usando o programa embutido na caneta chamado de "Paper Replay". O flash a seguir contem o pencast gerando pelo site de compartilhamento da Livescribe.
Clique no play para tocar ou na seta superior para full screen
Algumas fotos do evento estão disponíveis no álbum online da Globalcode.
Se desejar, deixe os seus comentários aqui neste post ou na home do pencast disponibilizado em My Livescribe Community.
domingo, 14 de setembro de 2008
Templates de Tela JSF e TagFiles com Facelets
O JavaServer Faces (JSF) na versão atual para o Java EE 5 tem algumas deficiências que serão resolvidas na nova especificação JSF 2.0. Aqui estão algumas deficiências encontradas no atual JSF 1.2:
Este framework implementa um novo compilador de páginas baseado em XHTML para realizar a instanciação da árvore de objetos (componentes UI) no lado do servidor para representar a tela JSF a ser renderizada em HTML para o usuário. Este mecanismo se tornará o substituto do JSP onde, por exemplo, não seria mais possível usar scriptlets.
Para ilustrar os conceitos relacionados a este fremework, a sua atual importância, o relacionamento com o JCP no JSF 2.0 e apresentar alguns exemplos, fizemos uma apresentação no JustJava2008.
Seguem abaixo os slides utilizados durante a apresentação.
Nesta apresentação falamos sobre o que é template de telas JSF, como criar um template, como criar uma tela JSF reusando um template, como configurar o Facelets numa aplicação Web e como criar componentes via TagFile (XHTML) e a respectiva custom tag. Tudo ilustrado com algumas demonstrações e trechos de código.
Os slides e a aplicação de demonstração podem ser baixados através do seguinte link: JustJava2008-Facelets.
Then, enjoy it!
- A falta de um mecanismo de templates de telas, semelhante ao Tiles do Struts, que seja bem integrado ao JSF;
- Definição de novos componentes de UI e custom tags a partir da composição de outros componentes e uso de JSP (XHTML no caso do Facelets) semelhante ao conceito de TagFile;
Este framework implementa um novo compilador de páginas baseado em XHTML para realizar a instanciação da árvore de objetos (componentes UI) no lado do servidor para representar a tela JSF a ser renderizada em HTML para o usuário. Este mecanismo se tornará o substituto do JSP onde, por exemplo, não seria mais possível usar scriptlets.
Para ilustrar os conceitos relacionados a este fremework, a sua atual importância, o relacionamento com o JCP no JSF 2.0 e apresentar alguns exemplos, fizemos uma apresentação no JustJava2008.
Seguem abaixo os slides utilizados durante a apresentação.
Nesta apresentação falamos sobre o que é template de telas JSF, como criar um template, como criar uma tela JSF reusando um template, como configurar o Facelets numa aplicação Web e como criar componentes via TagFile (XHTML) e a respectiva custom tag. Tudo ilustrado com algumas demonstrações e trechos de código.
Os slides e a aplicação de demonstração podem ser baixados através do seguinte link: JustJava2008-Facelets.
Then, enjoy it!
sexta-feira, 12 de setembro de 2008
Integrando o futuro: Seam e Spring
Quem disse que não é possível usar o Spring Framework e o JBoss Seam juntos?
No JustJava2008 apresentei uma palestra com o resultado da integração destes dois frameworks. Nesta apresentação ilustrei os passos necessários para configurar uma aplicação Web para ter os dois frameworks funcionando em conjunto. Apresentei as características do Seam que o qualificam para o gerenciamento da camada de apresentação (View e Controller) numa arquitetura MVC na Web com Ajax e as características do Spring que o qualificam para o gerenciamento da camada model com integração com os serviços EE (transação, segurança, logging, remoting, pooling, etc). Claro que estes frameworks são mais abrangentes do que o discutido na palestra.
Na apresentação pude discutir os problemas encontrados nesta integração considerando as diferenças destes frameworks que resultam em alguns curto-circuitos. Contudo, a integração até que funciona bem! Mas, tem que ficar atento com estes curtos.
A seguir estão os slides para a comunidade. Then, enjoy it!
No JustJava2008 apresentei uma palestra com o resultado da integração destes dois frameworks. Nesta apresentação ilustrei os passos necessários para configurar uma aplicação Web para ter os dois frameworks funcionando em conjunto. Apresentei as características do Seam que o qualificam para o gerenciamento da camada de apresentação (View e Controller) numa arquitetura MVC na Web com Ajax e as características do Spring que o qualificam para o gerenciamento da camada model com integração com os serviços EE (transação, segurança, logging, remoting, pooling, etc). Claro que estes frameworks são mais abrangentes do que o discutido na palestra.
Na apresentação pude discutir os problemas encontrados nesta integração considerando as diferenças destes frameworks que resultam em alguns curto-circuitos. Contudo, a integração até que funciona bem! Mas, tem que ficar atento com estes curtos.
A seguir estão os slides para a comunidade. Then, enjoy it!
quinta-feira, 4 de setembro de 2008
A caneta de 1 milhão de dólares que roda Java
Brincadeirinha! Só usei este título para chamar a sua atenção para este post do blog. Contudo, nem tudo é brincadeira. Uma caneta que roda Java realmente existe, mas custa apenas USD 149,00 para a versão com 1GB de RAM e USD 199,00 para a versão com 2GB. Ou seja, não é tão cara assim!A caneta chamada Pulse SmartPen, que foi desenvolvida pela empresa chamada Livescribe, ganhou no JavaOne 2008 o prêmio Duke's Choice Award como um dos projetos de invovação que utiliza a tecnologia Java.
Esta caneta tem um processador ARM embutido de 32 bits, 150MHz e uma JVM com suporte a Java ME e CLDC 1.1 com Media Profile. Torna-se possível escrever programas em Java e fazer o upload via USB para a memória interna da caneta.
Mas, a grande inovação da caneta não está necessariamente na capacidade de rodar Java. Além de ser um mini-computador numa caneta, ela tem uma câmera de infravermelho de alta velocidade que permite capturar tudo aquilo que o usuário escrever num papel de um caderno especial.
O caderno usado pela caneta tem impresso nas páginas um padrão de micro pontos que não se repete ao longo de uma página e ao longo de todas as páginas do caderno. Este padrão de pontos forma um sistema de endereçamento chamado DPS (Dot Positioning System) que permite a câmera de infravermelho captar a posição da caneta no caderno e o movimento realizado pelo usuário. A câmera não enxerga a tinta da caneta esferográfica que tem na ponta, mas apenas visualiza os pontos para posicionamento e registro do movimento de escrita.
Tudo aquilo que o usuário escreve é registrado na memória da caneta. Através de um programa instalado no computador é possivel transferir todas as páginas escritas para o computador e visualizar este conteúdo exatamente como foi escrito. Após a transferência do conteúdo para o computador, torna-se possível fazer o upload deste conteúdo para um site de compartilhamento da própria Livescribe em formato flash que pode ser exportado para PDF.Mas não é só isso ... :) O recurso mais interessante é que a caneta tem um gravador de áudio embutido que permite gravar uma reunião, uma aula ou uma apresentação. Todo o áudio gravado é sincronizado com aquilo que é escrito e no momento no qual é escrito no caderno! Assim, torna-se possível depois da gravação, posicionar a caneta sobre uma palavra escrita no caderno para iniciar a reprodução do áudio gravado no momento que o texto foi escrito. O flash gerado também contem o áudio. O legal é quando o flash é reproduzido, toca o áudio e mostra o contéudo sendo escrito em sincronismo com o áudio como se fosse um filminho.
Você acha que é só isso? Que nada! Um recurso bem legal é o fone de ouvido que tem em cada fone um microfone embutido que simula os ouvidos do usuário e o seu ponto de vista. Quando este fone é colocado nos ouvidos do usuário e ligado à caneta, simula os ouvidos do usuário através do microfone e permite gravar o áudio do ponto de vista do usuário. A tecnologia de gravação do áudio é chamada de Binaural que grava a posição espacial de onde o som vem (um exemplo bem legal desta tecnologia é o áudio chamado Virtual Barber Shop, que só funciona ouvindo com um fone de ouvido estéreo). Assim, ao ouvir a reprodução do áudio, o usuário sabe de onde vem cada som ou quem fala numa reunião. Muito interessante numa sala de aula, numa discussão ou reunião onde o usuário pode identificar os participantes ao desenhar no caderno onde está cada individuo. Depois, ao ouvir o áudio, o usuário poderá saber quem é quem!Para não ficar somente no palavriado seguem alguns videos disponiveis no YouTube com demonstrações da caneta:
The Livescribe paper-based computing platform
A Java Minute with LiveScribe, Duke Choice Award Winner
The Livescribe paper-based computing platform
The Pulse Smartpen is a Java technology-based mobile computing platform that connects the paper world and the digital world. It is a computer within a pen that captures handwriting and simultaneously records audio and synchronizes it to the writing. Anything the user hears, writes or speaks is captured, accessible and shareable. The Pulse platform consists of an integrated system of smartpen, dot paper, applications, desktop software and development tools.
Com todos esses recursos, a JVM embutida baseada no Java ME permite escrever programas que tem acesso via uma API Java implementada pela Livescribe aos recursos de DPS, o display OLED, a gravação e reprodução de áudio. Então, agora é uma questão de criatividade ao desenvolver programas em Java através do Eclipse, compilar e instalar na caneta via USB.
Especificações técnicas da caneta.Eu não perdi a oportunidade e comprei uma pra mim já que não custa 1 milhão de dólares! Então, para ilustrar o que pode ser feito ao gravar um áudio e o que foi escrito, gerei o flash abaixo.
Clique no play ou na seta superior para full screen
E aí, quando vai encomendar a sua?! Não venha com a desculpa "como eu pude viver esse tempo todo sem essa caneta?". Isso pode parecer inveja :) Então, não perca tempo!Será que existe algo parecido em .NET?
Clique no video acima para ver todo o conteúdo
Vejam apresentação sobre a caneta no evento TDC em florianópolis: A caneta Java no TDC FLoripa.
Uma outra opinião: design@Sun
Then, enjoy it!
Usar ou não DAO nos tempos do JPA?
Recentemente fui questionado sobre os design patterns a serem usados no desenvolvimento de aplicações Web com JSF e JPA. As seguintes perguntas foram feitas:
Uma discussão acalorada foi resumida num post do site InfoQ pelo Craig Wickesser "Has JPA Killed the DAO?" com argumentos contra e a favor do DAO com JPA.
- Pensamos em usar um Mediator para evitar acesso direto ao JPA dentro do Seam Component. Este padrão é o melhor a ser adotado?
- Tem mais algum design pattern que devemos usar explicitamente? Já estamos utilizando DAO, para separar os métodos de acesso ao JPA.
Vejo que nos tempos de JPA, evitar o acesso direto ao JPA a partir da camada controller ou até mesmo da camada model (via serviços, ou melhor, façades) não é mais necessário. O uso de um mediator ou DAO para encapsular os códigos de persistência estão saindo de moda considerando que a interface desses objetos é praticamente a mesma do EntityManager. Ou seja, se adicionarmos essa camada, vemos que praticamente é uma cópia e passagem direta de chamadas de uma camada para outra sem um valor agregado significativo. Pode até ser que compense por impor uma interface de DAO com tipagem baseada nas entidades, considerando que JPA não usa generics ainda.
No tempo do JDBC, onde tínhamos infinitas linhas de código para persistência de cada entidade, o DAO ou o encapsulamento de códigos de persistência tinha uma valor enorme para o reuso e manutenibilidade. No tempo do Hibernate, o uso do DAO ainda podia ser justificado considerando que a API do Hibernate não era considerada um padrão. Então seria interessante manter o acesso ao BD encapsulado para possíveis trocas de "provider". Mas, já nesse tempo começamos a perceber que os DAOs não tinham muito código por conta do Hibernate generalizar o acesso ao DB através de reflection e dialect. Mas, agora nesses tempos de JPA a API é padrão, já encapsula a independência do provider, já oference um processo simplificado de configuração e uma API genérica para todas as entidades via reflection, além de ter o mesmo efeito do Hibernate na redução drástica de códigos nos DAO. Uma camada específica de DAO para persistência em banco de dados via JPA perde sentido. Contudo, o DAO ainda é interessante para outros meios de persistência, e até mesmo DB se JPA não for usado.
Portanto, eu recomendo usar o JPA (EntityManager) diretamente na camada controller (MBs clássicos ou seam components como MBs) ou na camada model (seam components como façades ou business services). Daí podemos nos beneficiar da simplificação proposta pelo Java EE ao promover o IoC/DI através da anotação @PersistenceContext ou da proposta do Seam ao promocer o IoC/DI através da anotação @In. Então, a dúvida agora reside em fazer ou não uma camada model para delegar a persistência da entidade a esta camada! Confesso que é uma dúvida interessante de responder e que pode ser adiada para o momento de modelagem de cada arquiterura que realizarmos.Muitos já me questionaram sobre usar ou não DAO nesses tempos de JPA. Agora pude compartilhar um pouco do que penso sobre esse assunto ... Qualquer contra-posição, adoraria discutir ...
Uma discussão acalorada foi resumida num post do site InfoQ pelo Craig Wickesser "Has JPA Killed the DAO?" com argumentos contra e a favor do DAO com JPA.
sexta-feira, 1 de agosto de 2008
Ecossistema Spring
Na palestra que realizei no último TDC junto com o Ricardo Jun, colocamos dois slides na apresentação que chamamos de Ecossistema Spring. Estes slides foram muito apreciados por várias pessoas que viram a apresentação. Como tivemos muitos feedbacks positivos sobre estes slides, gostaria de compartilhar com vocês as imagens utilizadas para representar o ecossistema.
A primeira imagem ilustra as integrações com diversos fremeworks e serviços Java EE que o Spring Framework proporciona. Estas integrações estão todas disponíveis num único JAR (spring.jar).
Os elementos folha neste diagrama representam as tecnologias ou frameworks que o Spring Framework permite integração sem reinventar a roda. Em alguns casos o Spring Framework traz uma implementação própria como, por exemplo, o Spring MVC e Spring JDBC (templates e datasources). A seguir alguns destas caixinhas são detalhadas:
Neste diagrama, os elementos vinculados ao Spring Framework são pacotes distribuídos separadamente e disponíveis em um ou mais arquivos JAR. Cada produto tem uma página própria de documentação e download que são acessíveis na página Spring Projects. A seguir alguns destas caixinhas são detalhadas:
Veja a seguir os slide usados na palestra.
Todas os slides das palestras do evento TDC2008 estão disponíveis para download no site da Globalcode.
Para fechar este post, algumas frases que definem o Spring Framework:
A primeira imagem ilustra as integrações com diversos fremeworks e serviços Java EE que o Spring Framework proporciona. Estas integrações estão todas disponíveis num único JAR (spring.jar).
Os elementos folha neste diagrama representam as tecnologias ou frameworks que o Spring Framework permite integração sem reinventar a roda. Em alguns casos o Spring Framework traz uma implementação própria como, por exemplo, o Spring MVC e Spring JDBC (templates e datasources). A seguir alguns destas caixinhas são detalhadas:
- Core: Implementa o contêiner IoC;
- Web: Recursos para implementação de aplicações Web: integração com frameworks MVC, implementação própria de MVC e integração com tecnologias de visualização;
- DAO: Classes utilitárias para desenvolvimento de DAO's com JDBC e gerenciamento de transações;
- AOP: Disponibiliza o conceito de aspectos via AOP Alliance e AspectJ para integrar os POJO's com os serviços enterprise;
- ORM: Implementa o suporte para integração com frameworks de mapeamento objeto/relacional;
- Java EE: Classes utilitárias para integração com serviços Java EE;
- Remoting: Expõe os métodos dos POJO's para invocação remota.
Neste diagrama, os elementos vinculados ao Spring Framework são pacotes distribuídos separadamente e disponíveis em um ou mais arquivos JAR. Cada produto tem uma página própria de documentação e download que são acessíveis na página Spring Projects. A seguir alguns destas caixinhas são detalhadas:- Spring Security: Segurança declarativa via XML ou anotações com suporte a AOP e integração com tecnologias de segurança: JAAS, LDAP, DAO, OpenID, CAS, X509, Windows NTLM;
- Spring Web Service: Suporte a Web Services a partir da definição do XML Schema e WSDL (Data Contract e Service Contract);
- Spring Web Flow: Suporte ao controle de fluxo de navegação Web, integração com JSF, conversação e Ajax;
- Dynamic Modules for OSGi: Simplifica o uso da API OSGi através do Spring com POJO's;
- Spring Modules: Projeto guarda-chuva que implementa a integração com diversos outros frameworks e ferramentas;
- Spring Rich Client: Recursos para desenvolvimento desktop com Swing e Spring;
- Spring JavaConfig: Suporte a configuração dos beans programaticamente sem usar XML ou anotações;
- Spring LDAP: Classes utilitárias para interação com um serviço de Lightweight Directory Access Protocol (LDAP);
- Spring Integration: Implementa o suporte para integração de sistemas via mensagens (EAI e Enterprise Integration Patterns);
- Spring Batch: Suporte a execução de processos em batch de longa duração;
- Spring IDE: Plugin para incrementar produtividade durante o desenvolvimento com o Eclipse;
- Spring BeanDoc: Ferramenta para gerar documentação semelhante ao Javadoc;
- Spring .NET: Porte de parte do Spring Framework para desenvolvimento de aplicações .NET!
Veja a seguir os slide usados na palestra.
Todas os slides das palestras do evento TDC2008 estão disponíveis para download no site da Globalcode.
Para fechar este post, algumas frases que definem o Spring Framework:
- Um framework de código aberto e uso livre, sob licença Apache, criado por Rod Johnson;
- Implementa um contêiner de injeção de dependências (DI) e inversão de controle (IoC);
- Um framework para programação orientada a aspectos (AOP);
- Um framework para integração de aplicações com serviços Java EE;
- Um framework para integração com outros frameworks que implementam serviços enterprise;
- Não é uma tecnologia padrão mantida pelo JCP;
- Não é um concorrente da plataforma Java EE;
- Não é a reinvenção da roda!
terça-feira, 29 de julho de 2008
Foram muitas novidades no TDC 2008
O TDC 2008 já se foi! Definitivamente o evento foi um sucesso. A Globalcode está se tornando senior em desenvolvimento de eventos Java. No ano passado, que foi a primeira edição do evento, contou apenas com uma trilha de palestras, apenas um palestrante internacional e a maioria dos palestrantes eram instrutores da Globalcode. Este ano foi um upgrade e tanto! Três palestrantes internacionais de peso, 2 trilhas de palestras em paralelo, vários palestrantes de outras empresas e, além de tecnologia Java, falou-se muito de processos e metodologia.
Para mim foi muito proveitoso ouvi falar de:
Aproveitei o evento e trouxe dois livros para casa: JavaServer Faces: The Complete Reference e EJB 3 In Action. Não perdi a oportunidade de fazer tietagem e consegui o autógrafo do primeiro livro com o Ed Burns e do segundo livro com o Reza Rahman. Mas perdi a oportunidade de conseguir o livro Secrets of the Rockstar Programmers que sumiu rapidamente das prateleiras da Tempo Real no evento já no início do evento. Contudo o Ed Burns deixou algumas palavras sobre este livro em palestra e numa entrevista para a Computer World Brasil: Conheça os grandes segredos dos programadores ‘rockstar’.
Contudo, fantástico mesmo foi reencontrar vários amigos, ex-colegas de trabalho e muitos ex-alunos. Pude trocar muitas figurinhas com vários deles, além de promover muito network!
Realmente o evento foi um sucesso. Pena que já acabou! Mas ainda ouviremos muito sobre o que foi discutido neste evento ... Parabéns a Globalcode!
Para mim foi muito proveitoso ouvi falar de:
- Scrum;
- Java EE 6: EJB 3.1, JSF 2.0, WebBeans, Servlets 3.0, asyncronous bean invocation e timed invocations;
- Java SE 7: JavaFX e applets;
- Annotations (a febre!);
- OSGi;
- JBoss Seam;
- SpringSource Application Platform;
- JBoss Rules e jBPM.
Aproveitei o evento e trouxe dois livros para casa: JavaServer Faces: The Complete Reference e EJB 3 In Action. Não perdi a oportunidade de fazer tietagem e consegui o autógrafo do primeiro livro com o Ed Burns e do segundo livro com o Reza Rahman. Mas perdi a oportunidade de conseguir o livro Secrets of the Rockstar Programmers que sumiu rapidamente das prateleiras da Tempo Real no evento já no início do evento. Contudo o Ed Burns deixou algumas palavras sobre este livro em palestra e numa entrevista para a Computer World Brasil: Conheça os grandes segredos dos programadores ‘rockstar’.
Contudo, fantástico mesmo foi reencontrar vários amigos, ex-colegas de trabalho e muitos ex-alunos. Pude trocar muitas figurinhas com vários deles, além de promover muito network!
Realmente o evento foi um sucesso. Pena que já acabou! Mas ainda ouviremos muito sobre o que foi discutido neste evento ... Parabéns a Globalcode!
quinta-feira, 24 de julho de 2008
Muito Java na veia com o TDC 2008
O TDC 2008 está chegando! Serão dois dias de pura adrenalina, ou seria cafeína na veia? Em todo caso, o evento contará com uma programação bem variada de tecnologia Java e duas trilhas de conteúdo em paralelo ("Java Expert Edition" e "Java Corporativo e Metodologias").
Eu estarei lá para falar sobre Spring Framework e o portfolio de produtos agregados junto com o meu colega Ricardo Jun. A palestra será no sábado (26/07) a partir das 15:15.
Vale a pena conferir. Pena que as vagas já estão esgotadas como divulgado no boletim da Globacode. Serão 550 participantes! Mas, a lista de espera existe e está crescendo. Não custa tentar!
Eu estarei lá para falar sobre Spring Framework e o portfolio de produtos agregados junto com o meu colega Ricardo Jun. A palestra será no sábado (26/07) a partir das 15:15.
Vale a pena conferir. Pena que as vagas já estão esgotadas como divulgado no boletim da Globacode. Serão 550 participantes! Mas, a lista de espera existe e está crescendo. Não custa tentar!
sexta-feira, 18 de julho de 2008
Sobre os contextos do JBoss Seam
O primeiro passo para entender o conceito de bijeção (bijection) do JBoss Seam é compreender muito bem os contextos Web e os próprios contextos do JBoss Seam.
Os contextos do Seam são muito semelhantes aos contextos de uma aplicação Web baseado em Java EE (componentes Servlet e JSP). Os contextos são áreas de objetos onde podemos associar um nome (uma string) para identificação de um objeto ao armazená-lo neste contexto. Um analogia bem simples e grosseira seria imaginar um contexto como um Map da API de Collections do Java. Um Map permite associar uma chave (referência ou identificador) a um valor (outro objeto) para localização simples e rápida dos objetos (valor). Contudo, os contextos vão além de um simples MAP e determinam um tempo de vida para os objetos que ali são armazenados. O tempo de vida determina um escopo de existência dos objetos ao torná-los disponíveis para os Servlets e JSP's da aplicação.
Numa aplicação Web simples baseada nas tecnologias Servlet e JSP (ao usar Struts, WebWork e JSF não seria diferente) temos disponíveis os seguintes contextos para armazenar objetos: page, request, session e application.
Escopos Java EE para Web:
Escopos do JBoss Seam:
Os contextos do Seam são muito semelhantes aos contextos de uma aplicação Web baseado em Java EE (componentes Servlet e JSP). Os contextos são áreas de objetos onde podemos associar um nome (uma string) para identificação de um objeto ao armazená-lo neste contexto. Um analogia bem simples e grosseira seria imaginar um contexto como um Map da API de Collections do Java. Um Map permite associar uma chave (referência ou identificador) a um valor (outro objeto) para localização simples e rápida dos objetos (valor). Contudo, os contextos vão além de um simples MAP e determinam um tempo de vida para os objetos que ali são armazenados. O tempo de vida determina um escopo de existência dos objetos ao torná-los disponíveis para os Servlets e JSP's da aplicação.
Numa aplicação Web simples baseada nas tecnologias Servlet e JSP (ao usar Struts, WebWork e JSF não seria diferente) temos disponíveis os seguintes contextos para armazenar objetos: page, request, session e application.
Escopos Java EE para Web:
- page - Objetos armazenados neste escopo tem o tempo de vida de apenas o tempo de execução (processamento) de uma página JSP no lado do servidor. Após a geração do conteúdo HTML pelo JSP no lado do servidor e o envio deste conteúdo para o browser, as referências para os objetos armazenados neste contexto são perdidos. Podemos imaginar este contexto como o escopo de um método onde declaramos váriaveis locais que são destruídas ao final da execução do método.
- request - Objetos armazenados neste escopo tem o tempo de vida de uma requisição Web realizada por um usuário através do browser. Este escopo passa a existir no momento que o servidor atende a requisição e será destruído ao final da requisição Web quando o conteúdo gerado for enviado para o browser. Este contexto permite armazenar objetos que podem ser passados de um servlet para outro ou de um servlet para uma página JSP se ocorrer um encaminhamento (forward) de um componente para outro enquanto a requisição ainda está em processamento no lado do servidor. Podemos imaginar este contexto como o escopo determinado pela passagem de parâmetros quando um objeto invoca o método de outro objeto.
- session - O contexto de sessão define uma área de objetos no lado do servidor para cada usuário que acessa a aplicação. Este contexto permite armazenar objetos com o mesmo nome para usuários diferentes e existe um isolamento para cada usuário não acessar objetos de outro usuário. Objetos armazenados neste contexto tem um tempo de vida maior que o tempo de vida determinado pelo contexto request e mantem os objetos no lado do servidor enquanto o usuário usar a aplicação Web. Após um período de inatividade do usuário, este contexto será destruído para eliminar somente os objetos deste usuário.
- application - Este contexto define uma área de objetos que tem o tempo de vida da própria aplicação. Quando a aplicação Web entra no ar no servidor de aplicações o contexto application é criado e será destruído somente quando a aplicação for desligada ou o servidor de aplicações sair do ar. Objetos armazenados neste contexto serão compartilhados entre todos os usuários que acessam a aplicação. Este objetos estarão disponíveis para qualquer Servlet e JSP da aplicação Web.
Escopos do JBoss Seam:
- stateless - Contexto para armazenar a referência para objetos stateless (ex. session stateless EJB). Tecnicamente não é um contexto já que cada busca ou chamada a método num objeto resulta numa nova referência para o bean. Este bean é gerenciado pelo pool de beans do EJB Container.
- event - Este contexto é equivalente ao contexto request da Web. Recebe outro nome porque é utilizado em outras situações além de requisições Web como, por exemplo, invocação RMI ou invocação via Seam Remoting aos componentes Seam. Este contexto está associado ao ciclo de vida JSF. Durante o processamento do ciclo de vida os objetos associados estarão disponíveis e serão eliminados somente ao final do ciclo de vida JSF. Inclusive este contexto tem o tempo de vida de uma requisição Ajax realizada pelas bibliotecas de componentes visuais JSF com suporte a Ajax.
- page - Este contexto permite armazenar objetos que são criados numa tela JSF e estão disponíveis para esta tela. Este contexto pode ser comparado com o contexto page da Web. Contudo, um objeto armazenado neste contexto estará diponível somente para a tela JSF correspondente que o instanciou a partir de algum listener de evento. Como a documentação sugere, este contexto é útil em alguns componentes visuais como, por exemplo, numa lista clicável de opções que precisa de um objeto com valores específicos para esta lista e tela JSF. Objetos neste contexto estarão disponíveis mesmo em sucessivas requisições Ajax a partir de componentes visuais a partir do browser.
- conversation - Aqui está o verdadeiro diferencial do JBoss Seam que agrega valor no desenvolvimento de aplicações Web com JSF. Este contexto permite armazenar objetos que terão um tempo de vida maior que uma requisição (event) e menor que uma sessão (session). Com este contexto se torna possível definir um escopo para objetos que são usados para implementar um fluxo de telas que realizam um "caso de uso" ou "história de usuário". Num Seam Component é possível anotar o início da conversação num método e anotar outro para demarcar o fim da conversação. O curioso deste contexto é que permite abrir várias janelas de browser para uma mesma tela JSF e cada janela representar uma conversação diferente (contexto diferente de objetos) para execução simultânea do mesmo caso de uso. Cada janela é um contexto separado que não influência um outro contexto aberto.
- session - Este contexto é equivalente ao contexto Web de mesmo nome. Este contexto define um escopo para manter objetos como, por exemplo, o usuário logado ou outros objetos a serem compatilhados entre várias conversações (escopo de conversação), Além de objetos globais do usuário que acessa a aplicação.
- business process - Define um contexto para objetos que são associados a um processo de negócio gerenciado pelo jBPM. Objetos armazenados neste contexto pertencem a um processo e podem ser compatilhados entre vários usuários que acessam o mesmo processo de negócio. Só faz sentido usar este escopo se a máquina de processos implementada pelo jBPM estiver em uso numa aplicação Web em conjunto com o Seam.
- application - Este contexto é equivalente ao contexto Web de mesmo nome. Objetos armazenados neste contexto estarão disponíveis para todas as converssações e usuários que acessam a aplicação. Este contexto é útil ao armazenar objetos com conteúdo que não mudam com freqüência para compatilhar para toda aplicação como, por exemplo, configurações ou meta informações. Muitos objetos internos do próprio Seam são armazenados neste contexto.
sexta-feira, 4 de julho de 2008
Seam Contexts Ilustrado
Preparei a ilustração ao lado para tentar representar os contextos do JBoss Seam. Em estudo recente comecei a compreender melhor estes contextos e a diferença entre Context Variable e Instance Variable. O primeiro tipo de variável representa uma referência para um objeto a partir de um contexto com um nome definido (como os pontos A, B e C na ilustração). O segundo tipo representa um atributo dentro de um Seam Component (como os pontos D e E na ilustração). A partir deste entendimento começou a ficar claro para mim o conceito de Bijeção, ou melhor, a diferença entre injection e outjection. Mas a explicação dessa diferença deixarei para outro post!
Assinar:
Postagens (Atom)