Tópicos

Introdução To top of page

Um Módulo J2EE é a menor unidade independente de implementação em um aplicativo J2EE. Há tipos diferentes de Módulos J2EE, conforme descrito em Conceitos: Visão Geral do J2EE.

O número e o tamanho dos Módulos J2EE afetam a facilidade de implementação e de teste de um aplicativo J2EE, além da facilidade com que os componentes podem ser reutilizados para outros aplicativos e a facilidade com que o sistema poderá ser adaptado para outras configurações de implementação.

Para obter informações sobre a montagem de Módulos J2EE, consulte Diretrizes: Montagem de Módulos J2EE.

Para obter informações sobre a implementação de Módulos J2EE, consulte Diretrizes: Implementando Módulos e Aplicativos J2EE.

Identificando Módulos J2EE To top of page

Os Módulos J2EE são criados durante a integração, mas refletem as decisões tomadas na implementação (e, verdadeiramente, no design). Os Módulos J2EE são comumente utilizados para compactar os Subsistemas de Implementação, que são comumente mapeados para Artefato: Subsistemas de Design.

Os Módulos J2EE devem conter EJBs e classes auxiliares estreitamente relacionados que sejam utilizados apenas por esses EJBs. Geralmente, esses relacionamentos são identificados no design e essas classes seriam agrupadas em um Subsistema de Design. A identificação de Subsistemas de Design já deveria ter considerado os problemas de reutilização, substituição e suporte para várias configurações de implementação. Entretanto, quando os módulos são alocados para implementação em nós específicos, a deficiência no design pode tornar-se aparente e podem ser necessárias mudanças nos Subsistemas de Design (e/ou Subsistemas de Implementação).

Identifique os Módulos J2EE para que contenham componentes destinados a um único contêiner. Os componentes da Web são compactados em módulos da Web, os componentes EJB são compactados em módulos EJB e os componentes do Cliente Aplicativo são compactados em módulos do Cliente Aplicativo.

As classes Java comuns que são utilizadas por vários módulos devem ser compactadas em Módulos J2EE separados. Os arquivos JAR resultantes aparecem em referências do caminho de classe nos módulos que os requerem (ou no fechamento transitivo dessas referências de caminho de classe).

Resumindo, ao identificar os Módulos J2EE, inicie identificando um módulo para cada Subsistema de Implementação, a não ser que o subsistema contenha componentes para serem implementados em contêineres diferentes e, em seguida, defina módulos separados para cada um dos contêineres.

Modelando Módulos J2EE To top of page

Os Módulos J2EE são representados no Modelo de Implementação como artefatos UML com um estereótipo que identifica seu tipo: <<EJB-JAR>>, <<JAR>> ou <<WAR>>.

A composição de componentes (como EJBs ou servlets) em um Módulo J2EE pode ser mostrada graficamente, desenhando uma dependência <<implements>> a partir do componente contido para o módulo no qual está compactado, conforme mostrado no diagrama a seguir. As dependências <<JARInclude>> também podem ser desenhadas para mostrar a inclusão de um pacote Java inteiro no archive.

Diagrama descrito no texto de acompanhamento.

Outra opção é representar o archive como um pacote e mostrar os componentes contidos no pacote, conforme mostrado no diagrama a seguir.

Diagrama descrito no texto de acompanhamento.

 

Além de modelar os componentes que serão compactados no archive, também é possível modelar as propriedades dos componentes, que são documentadas por último, no descritor de implementação do archive.

A seguir, é fornecido um exemplo de como modelar algumas propriedades do componente EJB.

Diagrama descrito no texto de acompanhamento.

O diagrama anterior mostra a montagem de três EJBs, BankEJB, LoanEJB, CustomerEJB e LoanManagerEJB no mesmo módulo, EJBJARArchive1. Observe a modelagem das propriedades do método EJB, as funções de segurança e as transações. Nesse exemplo, o CustomerEJB é executado sob o tipo de transação especificado pelo CustomerTrans (por ex., "Obrigatório"). O código fonte utiliza o nome da função "user", que é mapeado para a função de usuário "Customer" no descritor de implementação. Além disso, todos os métodos em LoanEJB e CustomerEJB são executados com as credenciais do "Cliente", mesmo que o usuário que está chamando pertença a uma função diferente. De forma semelhante, os métodos LoanManagerEJB são executados como "Admin". Finalmente, nenhum método pode ser acessado pelos usuários no BankEJB.

A seguir, é fornecido um exemplo de como modelar algumas propriedades do componente da Web.

Diagrama descrito no texto de acompanhamento.

O diagrama anterior mostra a montagem de um servlet em um módulo da Web. Observe a modelagem das funções e limitações de segurança, na qual os usuários do tipo "Customer" executam métodos no servlet showresults como eles mesmos, sujeitos às limitações de segurança definidas pelas propriedades de WebSecurityContraint1.

A implementação de um módulo J2EE em um nó pode ser mostrada no Modelo de Implementação. Consulte Diretrizes: Descrevendo a Distribuição para Aplicativos J2EE para obter discussão adicional sobre a modelagem do mapeamento de módulos para os nós de implementação.

Descritores de Implementação To top of page

Cada Módulo J2EE contém um descritor de implementação padrão J2EE, além de zero ou mais descritores específicos do fornecedor. Os diferentes tipos de descritores de implementação são descritos em Conceitos: Visão Geral do J2EE. Em geral, os descritores de implementação J2EE padrão capturam principalmente as decisões de design e de implementação. As decisões que o RUP referiria como "decisões de implementação", tal como em quais nós um componente é executado e como um componente é configurado para o nó específico, são capturadas em descritores de implementação específicos do fornecedor.

Os descritores de implementação atendem duas finalidades individuais:

  • Um meio de comunicar decisões de design para o contêiner. Por exemplo, o descritor de implementação para um EJB de sessão tem um "tipo de sessão" que indica se o EJB de sessão é sem preservação de estado ou com preservação de estado. Isso deve estar consistente com o design e o código - alguém não pode simplesmente fazer a alteração no descritor de implementação.
  • Um meio de adaptar o comportamento sem recompilar o código. Por exemplo, alguém pode utilizar o descritor de implementação para definir quais funções são autorizadas para chamar métodos específicos. Isso PODE ser feito sem mudanças no código do EJB.

O conteúdo do descritor de implementação é definido quando o Módulo J2EE é criado e quando ele é montado em um Aplicativo J2EE. Para obter informações adicionais sobre a montagem de Módulos J2EE, consulte Diretrizes: Montagem de Módulos J2EE. Para obter informações adicionais sobre a montagem de Aplicativos J2EE, consulte Diretrizes: Montagem de Aplicativos J2EE.

 



Rational Unified Process   2003.06.15