Servlet 3.0 JSR 315

O expert group da JSR 315 tem entrando em um grande impasse relacionado com as novas características sobre servlets e filters. Os membros estão em pleno debate sobre questões de segurança e flexibilidade relacionado com “deployed via annotations, discovered web.xml fragments or programmatically in Listeners discovered in TLD descriptors or web.xml.” Acompanhe aqui o andamento da discussão e fique antenado no que esta por sair nas próximas versões do novo JEE.

Combinação de JPA e EJB 3.0

Para quem acompanhou na época e ascensão dos Core J2EE Patters sobre o modelo do EJB 2.1,….. agora pode acompanhar seu declínio provando que a especificação do EJB 3.0 e JPA vieram para tomar espaço no mercado. Leia aqui um artigo interessante sobre isso.

JEE M1- Adetec 24/04/08

Neste post podemos trocar informações, comentários, sugestões e criticas durante o curso.

Vejam o post – Aplicativos Web com Java

EntityManager em Aplicativos Web Standalone

Segue algumas das estratégias que podem ser utilizados na implementação de uma camada de persistência utilizando o JPA em aplicativos web standalone:

1. Abrir e fechar um EntityManager por operação de negocio (quando precisar)

Perde o cache de nível 1 chamada de “repeatable read”, ficando somente com o de nível 2.

Tem que implementar o equals and hashCode dos pojos usando chave de negócio, uma vez que eles desligados perdem a identidade de persistência.

Perde a carga de objetos LAZY, uma vez que quando o pojo é retornado para a camada de visão, ele ja esta desligado(detached) e o contexto de persistência fechado.

2. Abrir e fechar um EntityManager por HttpRequest (Usando Filter Servlet + atributos de ThreadLocal)

Perde o cache de nível 1 chamada de “repeatable read”, ficando somente com o de nivel 2.

Tem que implementar o equals and hashCode dos pojos usando chave de negócio, uma vez que eles desligados(detached) perdem a identidade de persistência.

Mantém a carga LAZY uma vez que quando pojo esta sendo usando para renderizar a camada de visão, o contexto de persistência ainda esta aberta e somente será fechado pela volta da execução do filter.

3. Abrir e fechar um EntityManager por HttpSession (Extendida)

Essa estratégia usa um listener de session para criar apenas 1 objeto de contexto de persistência por usuário quando a sessão dele é criada.

O cache de nível 1 e 2 é utilizada.

Pedidos assíncronos simultâneos de um mesmo usuário ajax transacionais NÃO são executados concorrentemente uma vez que o objeto EntityManager é thread-safe.

Não existe a necessidade de implementar equal e hashCode, uma vez que o contexto de persistência mantém a referencia de identidade dos objetos persistentes (obj1==obj2).

Pedidos assíncronos simultâneos de um mesmo usuário podem interromper as transações definidas dentro do EntityManager, uma vez que uma consulta descarrega o contexto de persistência no SGDB. (Nesse caso tem que alterar o comportamento padrão do FlushMode podendo aumentar o grau de complexidade da camada de persistência)

Exceptions ocorridas dentro do um único contexto de persistência, invalidarão o estado do objeto, tendo a necessidade de criar outro, ou seja problemas se ocorrer durante a utilização do sistema. (Pode ser contornado pela aplicação criando um novo objeto quando o fato acontecer).

Head Hush ou Head First Ajax ?

Em fevereiro de 2006 a Head First lançou o livro sobre AJAX com o cod-nome Head Hush. E agora em julho de 2008, ela lançara o mesmo livro chamado Head First AJAX. A confusão aqui é que dentro da Head First existe uma outra série de versões simplificados e resumidas chamadas de Head Hush.

E foi isto que aconteceu, Head Hush Ajax é apenas um livro resumido ao básico mesmo sobre AJAX e seus assuntos correspondentes….mas que agora no verão americano(julho) esta agendado a versão completíssima do livro sobre AJAX…….que esta prometendo muito !!!

Veja aqui o artigo oficial bem humorado com sempre heheheheh (eu sempre me divirto de + com os personagens e seus comentários….), explicando toda esta confusão. Para quem ainda não se aprofundou no assunto vale a pena esperar por mais essa grande obra !! Eu concerteza estarei comprando para completar meus conhecimentos e a claro…..a coleção

Se for AJAX com java EU VOOOO !!!!

Java – Tecnologias Baseada em Especificações

Durante os treinamentos, palestras ou apresentações que venho ministrando, sempre procuro enfatizar uma das grandes vantagens de se usar a tecnologia java que são as especificações. Entretanto percebo que existe uma certa dificuldade em geral em entender isso, uma vez que especificações são sobre conceitos de engenharia software soando um tanto “estranho” a primeira vista. Para que o pessoal entenda isso, eu sempre acabo usando comparações com especificações do mundo real sobre outros assuntos…então vamos nessa:

Vc se lembra qual foi a ultima vez que vc comprou ou ganhou um CD de música de seu cantor ou banda preferida ? Vc teve que perguntar se este determinado CD da Banda X funcionava no seu som da marca Y ? É claro que não !!! Sabe porque ? POR CAUSA DA ESPECIFICAÇÃO !!! Existe uma especificação que determina as regras de “como” um CD de música de ser construído e de “como” os aparelhos devem fazer para toca-los. Não sei se já parou para pensar no caos que seria se isso não fosse uma realidade ? Tente imaginar um pouquinho …….. vc poderia gostar de vários cantores ou bandas diferentes onde cada qual gravaria seu CD em um formato/esquema/tecnologia diferente !! Em resultado, seu aparelho de som não teria a capacidade de toca-los ! O que vc acharia se isso fosse uma realidade ? Seria justo os cantores forçarem os clientes a comprarem um aparelho de som compatível somente para escutar seu CD em formato proprietário ? Realmente não seria justo para ninguém….nem para os cantores, nem para os clientes e principalmente para o produtores de aparelhos. A justa separação seria: o cantor tem que ganhar $ em cima da musica que ele criou, a empresa que produz o aparelho tem que ganhar $ em cima do aparelho que ela produziu e o cliente sendo principal articulador da historia, tem a liberdade em comprar qualquer aparelho que lhe atraia e a liberdade de comprar quantos CD de qualquer que seje o cantor/banda. Não podemos deixam de fora a competitividade que isso geraria tantos nos cantores para produzir melhores músicas e principalmente nas empresas produtoras de aparelhos, cada um oferecendo os mais diferenciados recursos que justificariam seus preços.

A péssima noticia é que este caos existe no mundo tecnológico ! As empresas quando adotam um determinada tecnologia para a construção de um produto de software, acabam ficando amarrados com ela para sempre e ainda amarrado com a plataforma de execução (SO). Os investimentos pesados acontecem para “aprender” a determinada tecnologia, o “tempo” gasto no desenvolvimento e o “próprio produto em si“. A casa cai quando as empresas tentam mudar de fornecedor de tecnologia por algum motivo….ou seja, o conhecimento adquirido na tecnologia proprietária não é o correspondente na outra, o produto desenvolvido em si não funciona sobre a outra e todo o tempo (que tb é dinheiro) investimento vai por agua abaixo….resumindo…..joga tudo fora e repete-se o ciclo em uma outra tecnologia proprietária mais atual ou adequada para o caso.

A Sun Microsystem visualizando este caos, se levantou contra tudo isso estabelecendo Java e suas tecnologias baseada em especificações, onde o órgão responsável por gerenciar é chamado de Java Comunity Process – (JCP) responsável pela elaboração, versionamento e aprovação das especificações. E atualmente não existe dúvidas que a idéia obteve sucesso, uma vez que todas as empresas mundiais então participando ativamente do processo.

Um exemplo simples disso, não estendendo muito o artigo seria o framework de conexão com banco de dados relacionais chamado JDBC. A especificação defini todas as regras de como uma aplicação java pode se conectar e trocar informações via SQL como o mesmo. Qualquer empresa produtor de banco de dados interessada, tem que ser ater as regras da especificação, se quiser que o seu produto seje usado com o java. Qualquer aplicação java que tenha que conectar com um banco de dados relacional, tem que se enquadrar as regras da especificação. As conseqüências são as mesmas em ambos os lados:

1. Desenvolvedor aprende somente uma vez a especificação que a implementação é igual para todos.
2. A empresa vendedora do software em java não fica amarrado com banco de dados específico.
3. A empresa produtora de banco de dados vai ganhar em cima de seu SGDB, independente de qual sistema ou tecnologia esta sendo usado.
4. O cliente que vai comprar a solução, tem a liberdade de usar o produto em java em qualquer plataforma e ainda com qualquer banco de dados.
5. Gera uma competitividade entre as empresas vendedores de sistema em java e as empresas vendedores de banco de dados relacionais…..ninguém amarrado em ninguém…..cada um ganhando $$$ em cima do seu.

Vale ressaltar que as especificações de tecnologia de software não se enquadram 100% nas mesmas condições que o caso citado de CD de músicas, podendo possuir algumas variações específicas ocasionadas pelo próprio tipo de produto especificado (por exemplo especificações de produtos como servidores de aplicações, componentes de integração, componentes distribuídos, componentes orm, protocolos de comunicação etc….) lembrando que a cada dia podem surgir novas especificações de novos produtos.

Outro detalhe importante é que alguns produtos contém especificações que podem oferecer aberturas válidas para algumas características proprietárias, aumentado ainda mais a concorrência entra as empresas ofertantes. E é claro……os desenvolvedores….nós ganhamos na medida das ofertas, mas podemos perder portabilidade na medida que resolvemos ultrapassar a especificação, utilizando recursos extras proprietários.