Tópicos

IntroduçãoPara o início da página

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 ArchivePara o início da página

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çãoPara o início da página

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 ArchivePara o início da página

É 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.



Rational Unified Process   2003.06.15