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
Pacotes EJB
Nesta edição completamos o tira
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
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
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
Enterprise JavaBean JARs
Um EJB
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
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
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
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
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
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
C:\projetos\agenda
Em seguida podemos realizar o deployment dos componentes EJB:
C:\projetos\agenda
E, finalmente, a aplicação cliente pode ser executada, usando:
C:\projetos\agenda
Enterprise Application ARchives (EAR)
...
