Diretrizes: Montagem de Módulos J2EE
Tópicos
Introdução
Esta página de diretrizes focaliza a montagem dos Módulos
J2EE.
A montagem de um Módulo J2EE resulta nos Elementos de
Implementação a seguir:
- Archive J2EE (arquivos WAR, EJB-JAR e JAR) e seus
- Descritores de implementação (arquivos XML) que descrevem o conteúdo do archive
e descrevem como os componentes contidos pretendem funcionar no
contêiner de implementação
Para obter informações adicionais sobre os Módulos J2EE, consulte Diretrizes:
Módulos J2EE.
Definindo o Archive
Nesta etapa, o provedor do componente de aplicativo identifica os componentes
que devem ser compactados no módulo.
É possível produzir vários archives para fins diferentes. Por exemplo, separe
archives para teste, depuração ou entrega para diferentes configurações de implementação
de "produção". Os archives de teste conteriam classes de teste
e classes construídas com sinalizadores de depuração, enquanto os archives de produção não
conteriam classes de teste e não seriam construídos com sinalizadores de depuração. O contexto pretendido
do archive que está sendo montado afeta o espaço de trabalho de montagem configurado.
Definindo os Descritores de Implementação
A etapa-chave na montagem de um Módulo J2EE é definir o descritor de implementação.
Boa parte dessas informações devem ter sido capturadas no design de cada componente e,
assim, definir o descritor de implementação é basicamente assegurar consistência
com o design. Se você estiver utilizando engenharia de permuta, então é possível que também
haja suporte de ferramenta para gerar o descritor de implementação.
Cada archive contém um descritor de implementação padrão J2EE, além de zero ou mais
descritores específicos do fornecedor. Os descritores padrão, ejb-jar.xml para EJB-JARs
e web.xml para WARs, contêm seções que precisam ser concluídas para teste e
outras implementações de "não-produção", além de seções que serão preparadas pelo
assembler de aplicativos final para implementação da produção.
Cada descritor contém informações de interesse aos provedores do componente de aplicativo,
assim como aos assemblers de aplicativos. Por exemplo, ejb-jar.xml contém três seções
principais (para os fins de nossa discussão): <enterprise-beans>...</enterprise-beans>, <relationships>...</relationships>
e <assembly-descriptor>...</assembly-descriptor>. O
provedor do componente de aplicativo define as propriedades dos EJBs, como campos
CMP, na seção <enterprise-beans>...</enterprise-beans>. O
provedor do componente de aplicativo também define os relacionamentos opcionais entre os
EJBs na seção <relationships>...</relationships>.
É na seção <assembly-descriptor>...</assembly-descriptor>
que as transações, as funções de segurança, as permissões de métodos, etc. são definidas.
Normalmente, apenas o assembler de aplicativos se preocupará com essa seção. O
assembler pode decidir modificar o conteúdo de outras duas seções, mas isso
é menos comum. A situação é semelhante para archives WAR. Para obter informações adicionais
sobre a montagem de aplicativos, consulte Diretrizes:
Montagem de Aplicativos J2EE.
Se, durante o design, você definiu mapeamentos entre as tabelas de bancos de dados no Modelo
de Dados e no EJB de entidade CMP (Persistente Gerenciado por Contêiner), eles
deverão ser refletidos nas diretivas de mapeamento nos descritores específicos do fornecedor
(as diretivas de mapeamento não fazem parte do descritor EJB padrão). Para obter informações adicionais
sobre o mapeamento de EJBs de entidade CMP para tabelas de bancos de dados, consulte Diretrizes:
Projetando Beans de Entidade.
Se vários componentes tiverem que ser compactados no mesmo archive (consulte etapa:
Definindo o Archive), o provedor do componente de aplicativo deverá integrar
suas informações do descritor de implementação. Por exemplo, ao combinar EJBs em
um EJB-JAR, o provedor do componente de aplicativo deve harmonizar as informações nos
descritores de implementação, tal como funções de segurança e referências cruzadas.
Validando o Archive
É interessante validar o conteúdo do archive antes de tentar a implementação,
uma vez que erros desconhecidos, especialmente do lado do servidor de aplicativos, podem resultar em
mensagens de erro vagas ou inexistentes. Por exemplo, nomes JNDI duplicados não podem
ser utilizados por nenhum dos componentes compactados no archive.
|