Artigo Java Magazine 41 - Java EE 5 na Prática

Esse artigo faz parte da revista Java Magazine edição 41. Clique aqui para ler todos os artigos desta edição

Atenção: por essa edição ser muito antiga não há arquivo PDF para download.Os artigos dessa edição estão disponíveis somente através do formato HTML. 

Java EE 5 na Prática

Criando uma aplicação passo a passo com EJB 3.0, JPA e NetBeans 5.5

Construindo uma aplicação de três camadas com EJB 3, utilizando os recursos do mais novo NetBeans e conhecendo práticas e técnicas importantes para aplicações reais

A tradicional plataforma J2EE sempre teve fama de ser poderosa, porém difícil, mas podemos argumentar que este julgamento é discutível. Difícil comparado com o que? Os críticos mais severos deveriam ter experimentado construir aplicações com recursos como distribuição, concorrência, persistência, clustering, transações e segurança, lá por 1999, antes da introdução do J2EE 1.0 e EJB 1.0!

Mas 1999 está longe. Uma tecnologia é sempre comparada ao estado de arte do seu campo, e à sua concorrência. Hoje os Entity Beans são comparados ao Hibernate, os servlets/JSP ao Rails; a linguagem Java a Ruby ou Python, as plataformas Java SE e EE a .NET ou a LAMP, e assim por diante. Por isso o Java não pode parar.

E é interessante notar que o foco da competição nem sempre é o mesmo. Em alguns momentos, é o desempenho – como nos anos 90, antes das JVMs modernas, quando o Java tinha grande desvantagem contra linguagens como C/C++. Em outros momentos, é a funcionalidade – como há poucos anos na “febre” dos web services, quando todos os fornecedores de tecnologia se atropelavam para implementar suporte a SOAP e padrões relacionados.

Agora estamos num momento em que a prioridade geral é a facilidade de desenvolvimento. Isso sem dúvida é resultado do amadurecimento e do conhecimento acúmulo de funcionalidades das plataformas de desenvolvimento hoje m uso – seja no Java, no .NET, ou mesmo em opções tradicionais (como C/C++ com os SDKs da Microsoft, ou em Unix com todas as suas bibliotecas). As conseqüências de toda a sofisticação hoje existente são assustadoras; todos os SDKs são enormes. Kits de documentação podem ocupar centenas de megabytes no seu disco, e alguns IDEs recentes têm gigabytes. Como mais complexidade em princípio implica maior esforço de aprendizado e custo de desenvolvimento mais alto, é natural que a corrida hoje seja pela produtividade.

A resposta do Java para este desafio vejo como o Java EE 5, que vimos no artigo “Java EE 5” na Edição 39, destaca-se pelas inovações direcionadas a uma maior produtividade. Guiaremos o leitor pelo desenvolvimento de uma aplicação de três camadas, usando Session Beans do EJB 3.0, persistência em banco de dados com JPA e uma interface web. Não nos entendermos sobre APIs com JPA, recém coberta em “Persistência no Java EE 5 (Edição 39). Ao invés disso, vamos analisar o ciclo de desenvolvimento como um todo. E utilizaremos o IDE NetBeans 5.5, que no momento em que este artigo é escrito, tem o suporte integrado mais completo à plataforma Java EE 5.

Instalando o NetBeans e o servidor de aplicações

Para acompanhar este tutorial, você precisará, além do NetBeans (5.5 ou superior), de um servidor de aplicações suportado por este IDE. Recomendo o Sun Java System Application Server 9.0 (SJSAS – também conhecido como Java EE 5 SDK) – ou sua distribuição open source Glassfish (v1 Milestone 7) – por ser o mais bem suportado pelo NetBeans. O GlassFIsh/SJSAS é também o único destes que atualmente implementa de forma completa e certificada o Java EE 5.

Outros servidores já suportados pelo NetBeans são JBoss, WebLogic e Jonas (este exigindo o plug-in JOnbAS). Em caso de dúvida, o mais fácil é baixar um dos downloads integrados: estão disponíveis downloads do NetBeans + SJSAS, e NetBeans + JBoss e o WebLogic (bem como outros servidores) possuem suporte parcial ao Java EE 5, em pré-release. Mas quando você estiver lendo, é bem provável que a lista de servidores certificados Java EE 5 tenha aumentado e que mais destes sejam suportados pelo NetBeans.

Iniciando com a aplicação

Vamos começar a aplicação no NetBeans. Selecione File/New Project>Enterprise/Enterprise Application. Este assistente cria um grupo de projetos de aplicação Java EE. Na aba Name and location, preencha o Project Name, ex.: JavaMagazine, e seu diretório-raiz, e aceite do defaults para as demais opções, como na Figura 1.

O resultado será uma estrutura de três projetos: JavaMagaziner-ejb, que irá gerar o EJB-JAR; JavaMagazine-war que gera o WAR; e JavaMagazine, que gera o EAR. Que já construiu aplicações J2EE tradicionais verá que o padrão de deployment de aplicações, e conseqüentemente o de organização de projetos, não parece ter mudado com o Java EE 5.

Na verdade, o padrão de deployment teve simplificações, como já vimos nesta coluna, com a remoção ou simplificação de descritores. Por exemplo, em JavaMagazine-ejb/Configuration Files, você verá que o NetBeans irá criar somente um arquivo: o MANIFEST.MF, cuja inclusão é uma “boa prática” para qualquer tipo de JAR. O Java EE 5 não exige mais este arquivo para incluir no classpath do módulo os JARs empacotados no mesmo EAR; portanto raramente será necessário.

O tradicional ejb-jar.xml (descritor de EJB padrão) não será mais criado. Mas dependendo das operações que você fizer no projeto, o NetBeans poderá criar o sun-ejb-jar.xml (descritor específico do SJSAS/GlassFish), ou talvez outro descritor proprietário se você tiver utilizado outro servodor.

Pode parecer estranho não precisamos mais de um descritor padrão e continarmos usando o proprietário. Mais veja porque isso faz sentido. O ejb-jar.xml  é opcional porque as informações que antes se encontravam nele agora podem ser determinadas por anotações em código. Porém, o código-fonte deve ser mantido portável. Você não iria querer utilizar anotações proprietárias – que continuarão existindo para opções de runtime (ex.: números de porta, tamanhos de pools, timeouts etc.) que sempre serão específicas a cada servidor. Por isso, os descritores proprietários poderão continuar sendo necessários, ainda que raramente.

Figura 1. Criando um projeto Java EE no NetBeans.

Implementando as entidades persistentes

Vamos agora à camada de back-end da aplicação, gerada pelo nosso projeto JavaMagazine-ejb. Nossa aplicação tem apenas duas entidades, Edição e Artigo, persistidas pela Java Persistence API (JPA). E  teremos um Session Bean chamado JavaMagazine com métodos para consultar e modificar estas entidades.

Pela descrição, vemos que é uma aplicação bastante simples. Em casos como esse, a reclamação antiga da plataforma J2EE é que, embora a burocracia de suas APIs e descritores pudesse se justificar para aplicações ambiciosas, cheia de requisitos avançados como clustering, transações distribuídas ou segurança, essas exigências eram um “canhão para matar mosca” no caso de aplicações mais simples sem estes requisitos. É a “escabilidade de complexidade”: aplicações simples devem resultar em codificação simples, ainda que a plataforma também suporte aplicações muito mais complexas. Vejamos então se o Java EE 5 cumpre a promessa de ser escapável no quesito de complexidade." [...] continue lendo...