Esse artigo faz parte da revista Java Magazine edição 10. 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. 

 

Tira-dúvidas

Pacotes EJB-JAR e EAR

 

Nesta edição completamos o tira-dúvidas sobre empacotamento de aplicações Java, analisando os pacotes de Enterprise JavaBeans (EJB-JAR) e os "superpacotes" EAR

A definição de formatos padrão para pacotes no J2EE é um dos grandes benefícios da plataforma, pois permite às empresas empacotarem componentes e aplicações que podem ser instalados em qualquer servidor compatível, sem a necessidade de programas de instalação especializados. Por outro lado, a correta construção desses pacotes é uma barreira a ser vencida pelo desenvolvedor iniciante.

A primeira parte desse tira-dúvidas (Edição 9) apresentou os pacotes JAR (bibliotecas), JARs executáveis (aplicações stand-alone) e WARs (aplicações web). Esta parte apresenta os pacotes EJB-JAR e EAR.

Recapitulando: exemplos, o comando jar e Ant

Na primeira parte, criamos as classes FormataTexto e FormataNumero (dentro do package javamagazine.util), que realizam tarefas de formatação freqüentemente utilizadas em aplicações comerciais. As classes foram empacotadas em um JAR de biblioteca chamado jmutil.jar, de modo a serem facilmente reutilizadas em vários projetos – lembrando que tanto as classes de formatação quanto as aplicações que fazem uso delas são propositalmente simples, para que seja possível o foco no processo de empacotamento e não no código Java.

O JAR de biblioteca e as várias aplicações cliente foram construídos utilizando uma estrutura padrão, na qual cada aplicação tem seu próprio diretório ou “raiz”. Cada projeto/aplicação possui um subdiretório src, contendo os fontes, e um diretório bin, contendo o resultado da compilação das classes Java. Arquivos adicionais (páginas HTML, documentação, scripts SQL, descritores J2EE) são inseridos em subdiretórios separados, preservando a organização do projeto. Assim pode-se facilmente compilar e empacotar as aplicações por meio dos comandos javac e jar, ou então utilizar um buildfile Ant padronizado, localizado na raiz do projeto. A Figura 1 apresenta a estrutura dos projetos vistos até aqui; consulte a primeira parte para mais detalhes referentes a essa estrutura, e sobre as bibliotecas, a sintaxe do comando jar e o uso do Ant.

Enterprise JavaBean JARs

Um EJB-JAR é um pacote JAR que contém a definição de um ou mais EJBs. A única diferença em relação a um JAR comum é a presença do arquivo META-INF/ejb-jar.xml, que contém o descritor J2EE para os Enterprise Beans. Além disso, na maioria dos casos, haverá outros arquivos XML no diretório META-INF empacotado (descritores proprietários para cada servidor de aplicações suportado pelos EJBs), mas é possível escrever aplicações simples sem recorrer a esses arquivos.

Como exemplo, será utilizado um Session Bean Stateful, que em uma aplicação real seria uma "fachada" para um ou mais Entity Beans responsáveis pela persistência das informações da agenda em um banco de dados. Para manter a simplicidade do exemplo, será construído apenas o Session Bean – que deve ser Stateful para que os dados do objeto Contato sendo editado não sejam perdidos entre uma chamada e outra aos métodos remotos. Além disso, o Session Bean utiliza as classes utilitárias para garantir a formatação correta das informações fornecidas pelos usuários, antes do seu armazenamento como atributos.

A estrutura do novo projeto pode ser vista na Figura 2 (observe que o pacote jmutil.jar, criado na primeira parte, foi copiado para dentro do projeto).

Uma aplicação baseada em EJBs tem, no mínimo, dois componentes, rodando possivelmente em nós diferentes da rede: o EJB em si (ContatoEJB), hospedado por um servidor de aplicações, e uma aplicação cliente que utiliza os serviços fornecidos por ele (ContatoClient). Assim, temos necessidade de gerar dois pacotes: um EJB-JAR, para entregar ao servidor de aplicações; e um JAR simples (não-executável) para o cliente, que nesse exemplo é apenas uma adaptação da aplicação Swing vista na primeira parte.

Observe que a divisão de packages Java adotada visa facilitar a construção dos dois pacotes JAR: os .class necessários, tanto no cliente quanto no servidor, estão em javamagazine.agenda.remote, enquanto que os utilizados exclusivamente pelo servidor estão em  javamagazine.agenda.ejb. Já as classes usadas apenas pelo cliente ficam em  javamagazine.agenda.client.

A possibilidade de referenciar pacotes JAR externos é uma característica prevista na especificação EJB 2.0 e J2EE 1.3, mas algumas vezes esquecida pelos desenvolvedores. Para isso, especifica-se no arquivo de manifest o atributo Class-Path referenciando o pacote – no caso, jmutil.jar. Dessa forma o Session Bean Contato pode fazer uso das classes de formatação sem que seja necessário incluí-las diretamente em seu próprio EJB-JAR.

A seqüência de comandos a seguir ilustra uma das várias maneiras possíveis de compilar as classes do projeto e montar os dois pacotes.

 

C:\> cd \projetos\agenda_ejb\src

C:\projetos\agenda_ejbl\src> javac -d ..\bin javamagazine\util\*.java

C:\projetos\agenda_ejb\src> cd ..\bin

C:\projetos\agenda_ejb\bin> jar cvfm ..\manifest.txt ..\agenda_ejb.jar javamagazine\agenda\ejb

C:\projetos\agenda_ejb\bin> jar uvf ..\agenda_ejb.jar javamagazine\agenda\remote

C:\projetos\agenda_ejb\bin> jar cvf ..\agenda_client.jar javamagazine\agenda\client

C:\projetos\agenda_ejb\bin> jar uvf ..\agenda_client.jar javamagazine\agenda\remote

C:\projetos\agenda_ejb\bin> cd ..

C:\projetos\agenda_ejb> jar uvf agenda_ejb.jar META-INF

 

Bastante trabalhoso, não? Felizmente, é possível automatizar todos estes passos utilizando o Ant. O buildfile mostrado na Listagem 1 contém alvos separados para fazer a compilação, gerar os três pacotes resultantes e realizar o deployment (instalação) dos EJBs no JBoss; além do alvo all, que realiza todas essas operações. Assim, basta executar:

 

C:\projetos\agenda_ejb> ant all

 

Mas ainda falta um componente para que seja possível executar a aplicação: os pacotes de cliente fornecidos pelo servidor de aplicações, que permitem o acesso aos EJBs hospedados por ele. Por isso o pacote JAR da aplicação cliente não foi montado como um JAR executável, pois, se fosse, seu classpath estaria fixado para o JBoss e o pacote teria que ser reconstruído para referenciar as bibliotecas específicas de outros servidores. Em vez disso, foi incluído no buildfile um novo alvo – run –, que configura o classpath e executa a aplicação. Caso seja utilizado outro servidor J2EE no lugar do JBoss, o buildfile deve ser adaptado para referenciar os pacotes apropriados.

A aplicação cliente em si é basicamente a mesma vista na primeira parte, no exemplo de JAR executável. As únicas modificações são a conexão com o servidor J2EE e a chamada aos métodos remotos do Session Bean – a Listagem 6 apresenta apenas as modificações feitas no código.

Estratégias para distribuição de EJBs

Na hipótese do EJB utilizado ser fornecido por terceiros, ou ter sido desenvolvido por outro projeto da empresa, como fazer para gerar a aplicação? Fácil, desde que as partes remotas do EJB (interface remota, interface home, VOs e exceções customizadas) tenham sido empacotadas em um JAR à parte. Este mesmo pacote é referenciado pelo EJB-JAR e pela aplicação cliente.

O download disponível no site da revista inclui, no projeto agenda_ejb, o arquivo build2.xml (Listagem 8), demonstrando essa estratégia alternativa de empacotamento. Note que é gerado o pacote agenda_remote.jar contendo as classes remotas do EJB; a aplicação cliente Swing está em agenda_client.jar, da mesma forma que no buildfile original. O novo pacote deve ser referenciado pelo arquivo de manifest de agenda_ejb.jar, juntamente com o JAR de biblioteca. Para rodar o Ant utilizando o novo buildfile, utilize a opção -f. Por exemplo:

 

C:\projetos\agenda-web> ant -f build2.xml clean compile jar

 

Em seguida podemos realizar o deployment dos componentes EJB:

 

C:\projetos\agenda-web> ant -f build2.xml deploy

 

E, finalmente, a aplicação cliente pode ser executada, usando:

 

C:\projetos\agenda-web> ant -f build2.xml run

Enterprise Application ARchives (EAR)

...

Quer ler esse conteúdo completo? Tenha acesso completo