quinta-feira, 22 de novembro de 2007

Feliz, Natal!

Após uma curta temporada em Natal estou de volta ao Rio. Com algumas horas a mais do que deveria de vôo, retorno bastante satisfeito, pois o principal motivo da minha viagem a Noiva do Sol foi a participação no III Natal Java Day onde tive o prazer de apresentar uma palestra sobre EJB e JPA. O outro motivo foi descansar um pouco, pois ninguém é de ferro...

Fiquei muito feliz ao ver cerca de 400 pessoas preenchendo as cadeiras do CEFET às 08:30 a manhã no meio de um feriado. Impressionante! Impressionante também foi a organização do pessoal do Jug JavaRN (aos mais desavisados: Java User Group): até transmissão pela internet o evento teve. Coisa de profissinal.

Como nem todos tiveram o prazer de acompanhar o evento, darei um breve resumo da minha palestra aqui.

Comecei falando do histórico da tecnologia java o ponto de vista de iniciativas da comunidade que acabaram influenciando diretamente a sua evolução. Foram citados XDoclet (annotations), Hibernate (JPA), Struts (JSF), Spring (Injeção de depedência, uso intensivo de POJO).

Na seqüência, falei um pouco sobre JPA - talvez o principal avanço da JEE5. Foi apresentado o conjunto dos elementos principais dessa especificação: EntityManagerFactory, EntityManager, Interface Query, ....... Apresentei um pequeno código de um simples CRUD (acrônimo para Create, Retrieve, Update e Delete ou o bom e velho lê-esquece-grava-apaga). Complementei com os prós e contras das estratégias de mapamento objeto-relacional: Um atabela por toda a família de classes, uma tabela por classe concreta e uma tabela por classe com joins.

Como as consultas são umas das facilidades da nova especificação, com a turbinada que a EJB-QL (finalmente) recebeu, citei as consultas simples, nomeadas - aquelas que são "fixas" e com um sentido em definido no sistema, como "pessoasRicas" - usando objetos para facilitar a escrita das Querys. Não foi esquecido o uso das consultas netivas usando o bom e velho SQL, além da citação dos avanços nas funçoes de agregação, subconsultas e afins.

No uso de injeção de dependência foi mostrado a grande facilidade que é o seu uso, assim como o contra-ponto de que as dependências a serem injetadas tem que estar no JNDI. Explico os palavrões:
.Injeção de Dependência - Quando dependências para que sua classe funcione são disponibilizadas para você sem que haja preocupação com a forma de como essas dependências chegam. Um exemplo simples de uma dependência é um EntityManager. Quem providencia isso? O Container.
.JNDI - Java Naming Directory Interface - Uma API padronizada para acesso a serviços de diretórios nomeados como LDAP ou AD. Um conainer tem que prover esse tipo de serviço onde, a partir de um nome, uma busca retorna o objeto.
Com isso até faz sentido o uso de objetos no JNDI para a injeção, já que ele é onipresente enquanto o container estiver no ar.

Os interceptors não foram esquecidos. Essas classes qie ficam na frente de EJBs com comportamento inspirado na AOP (Aspect Oriented Programming - Programação orintada a aspetos) possibilita que interesses interceptem as chamadas aos ejbs e processem permitindo uma centralização desse processamento em uma classe ao invés de estar espalhado por vários lugares colaborando para duplicação de código. No exemplo da apresentação foi considerado o interesse da saber quanto tempo o métodp gasta para processar. O que há de ruim nisso? A classe a ser interceptada precisa conhecer o seu interceptador, o que bate de frente com a proposta da AOP de que o interceptador é que conhece o interceptado. Bola Fora.

Como uma das bases da facilidades da especificação são as anotações, elas foram citadas o tempo todo e, sempre qie possível, ressaltando que os comportamentos padrões tendem a minimizar a escrutade código. Como toda a parametrização feita com anotações pode ser feita também com XML, essas duas opções foram comparadas.

Ainda faltam falar de alguns tópicos...

Procurei fazer uma palestra refletindo pontos fortes e fracos para apoiar a tomada de decisão dos desenvolvedores, não sendo mais uma palestra de EJB3. Espero ter conseguido atingir o objetivo colaborando para o bom uso da tecnologia. A apresentação? Está disponível aqui.

Como não bastasse, após a minha apresentação bati um excelente papo com o Daniel Oliveira do DFJug sobre "Comunidades". Mas isso é um outro post...

Alguns links interessantes:


Abraços.

3 comentários:

Anônimo disse...

A parte que fala sobre o relacionamento da injeção de dependência com JNDI me fez torcer o nariz por um momento, pois para conseguir recuperar um objeto do JNDI é necessário procurá-lo (lookup), além disso alguém já teria que tê-lo criado e colocado-o lá (onde entraria lazy instantiation?). Neste contexto não consigo enxergar IOC, a menos que exista alguém por trás gerenciando transparentemente as complexidades da criação e inicialização desses recursos, assim como a disponibilização para o cliente. Bom, para isso servem os deployment descriptors (ou anotações) e o container, né não?

Neste caso a injeção de dependência seria válida para os serviços disponibilizados pelo servidor de aplicação, creio que para recursos pertinentes apenas à aplicação (como DAOs sendo injetados numa camada de serviços ou num "domínio rico", por exemplo), a abordagem tenha que ser outra, em detrimento ao JNDI.

Abraços.

Unknown disse...

cadê os "links interessantes"?

Bala de Prata disse...

Olá Horácio,

Na verdade quem cuida da injeção é o container com o uso de anotações como "@Resource" antes de setters ou mesmo de atributos da classe. Também podem ser usados os deployment descriptors...

Dessa forma não existe mais os "services locators" da vida. Mais simples e barato!

Agora o container injeta o que está no JNDI. Classes comuns que você tenha criado devem estar lá.

Vou colocar um post sobre o assunto com alguns testes básicos, pois pegar do jndi está fácil, agora colocar continua da mesma forma.