Visão Geral do Pacote do Módulo EJB 3.x

Este tópico descreve o pacote de aplicativos quando você usa beans Enterprise JavaBeans (EJB) 3.x.

Os aplicativos de pacote que usam beans EJB 3.x são semelhantes aos requisitos de conjunto para aplicativos Java™ Platform, Enterprise Edition (Java EE) 1.4: componentes são empacotados em módulos, e os módulos são empacotados em arquivos application enterprise archive (EAR). Os componentes e os módulos possuem metadados de descrição fornecidos em um descritor de implementação XML (Linguagem de Marcação Extensível). As especificações EJB 3.x suportam um método adicional para descrever metadados e para empacotar unidades de persistência.

O arquivo EAR é um formato de arquivo compactado semelhante a um formato de arquivo .zip ou .tar. Ele pode ser visualizado como uma coleta de diretórios e arquivos lógicos compactados em um arquivo simples. Cada arquivo EAR inclui um ou mais arquivos de módulo Java EE, que podem incluir os seguintes módulos:
  • Os arquivos Java Application Archive (JAR) para módulos EJB. Módulos do cliente de aplicativo Java EE e módulos da classe do utilitário.
  • Arquivos Web application archive (WAR) para módulos da Web ou conteúdo EJB. O arquivo WAR deve ser versão 2.5 ou posterior para conter o conteúdo EJB.
  • Outros módulos tecnológicos específicos, como arquivos RAR (Resource Application Archive) e outros tipos de módulos.

Módulos EJB sem Descritores de Implementação

É possível empacotar módulos EJB sem um descritor de implementação se você estiver usando beans EJB 3.x. Para isso, você deve criar um arquivo JAR ou arquivo WAR com metadados em uma anotação localizada no componente EJB. Beans EJB 3.x não precisam de uma entrada no arquivo ejb-jar.xml para os metadados que você definiu por meio de anotações.

Com EJB 3.0, o padrão era varrer anotações durante a instalação de um módulo EJB 3.0. Para WebSphere Application Server, Versão 9.0, o padrão é não varrer módulos pré-Java EE 5 durante a instalação do aplicativo ou na inicialização do servidor.

Para preservar a compatibilidade com versões anteriores com o Feature Pack for EJB 3.0 e com o Feature Pack for Web Services, você tem a opção de varrer ou não os módulos da Web legados para metadados adicionais. Uma mudança de nível de servidor é definida para cada comportamento de varredura de pacote de recursos. Se o padrão não for apropriado, a mudança deverá ser definida em cada servidor ou servidor administrativo que exige uma alteração no padrão. As opções são as propriedades customizadas do servidor com.ibm.websphere.webservices.UseWSFEP61ScanPolicy={true|false} e com.ibm.websphere.ejb.UseEJB61FEPScanPolicy={true|false}. Para definir essas propriedades no console administrativo, clique em Servidores > Tipos de Servidor > Servidores de aplicativos WebSphere > nome do servidor > Java e gerenciamento de processo > Definição de processo > Controle > Java virtual machine > Propriedades customizadas.

Módulos EJB com Descritores de Implementação

É possível continuar utilizando módulos EJB com descritores de implementação. Módulos com descritores de implementação podem suportar qualquer nível de versão de especificação EJB, incluindo EJB 3.x, mas geralmente estes descritores devem refletir os requisitos de implementação dos componentes no módulo.

Um módulo EJB pode ter um descritor de implementação EJB 3.x, 2.x ou 1.x.

Para descritores de implementação EJB 2.x ou 1.x, assume-se que o descritor de implementação contenha os metadados completos para o módulo e não ocorre uma varredura adicional dos metadados de anotação.

A varredura da anotação do contêiner EJB é feita em módulos EJB ou que não têm um descritor de implementação ou que têm um descritor de implementação ejb-jar.xml no nível de esquema EJB 3.0 com o atributo XML metadata-complete configurado como false ou omitido. Consulte a seção Comportamento de Varredura de Anotação para obter o conjunto completo das regras usadas pelo servidor para determinar se a varredura de anotação é feita.

Nota: Você não pode varrer metadados de anotação de componente contidos em bibliotecas compartilhadas definidas utilizando o recurso de biblioteca compartilhado de gerenciamento de sistemas do WebSphere Application Server. No entanto, o conteúdo definido como um Recurso BLA é varrido em busca de dados de anotação.

Comportamento da Varredura da Anotação

O servidor pode inspecionar os arquivos de classe no módulo para o conteúdo da anotação. O servidor procura o conteúdo da anotação que pode definir um componente, uma referência para um recurso ou um determinado comportamento. Por exemplo, anotações podem ser usadas para definir um componente EJB, ou para declarar uma referência a uma origem de dados que deve ser usada por um componente EJB ou para declarar os atributos transacional ou de segurança que estão associados a um método EJB. Este processo de inspeção é chamado de varredura de anotação. Se os arquivos de classe no módulo contiverem anotações que devem ser respeitadas pelo servidor, o servidor deverá ser configurado para que ocorra a varredura de anotação. Se os arquivos de classe no módulo não contiverem anotações, então, por motivos de desempenho, é possível configurar o servidor para que não ocorra a varredura de anotação.

O servidor usa os seguintes critérios para determinar se varrerá o conteúdo em busca de anotações:
  • Se o arquivo descritor de implementação ejb-jar.xml existe
  • A versão do descritor de implementação ejb-jar.xml, quando ele existe
  • O valor da configuração metadata-complete no descritor de implementação ejb-jar.xml, quando ele existe
  • A versão do descritor de implementação web.xml quando o conteúdo EJB está empacotado em um módulo WAR e o descritor de implementação ejb-jar.xml não existe
  • O valor da configuração metadata-complete no descritor de implementação web.xml quando o conteúdo EJB está empacotado em um módulo WAR e o descritor de implementação ejb-jar.xml não existe

As tabelas a seguir indicam como é tomada a decisão para fazer ou não uma varredura das anotações para o conteúdo EJB que é empacotado em um módulo JAR EJB ou em um módulo WAR.

Tabela 1. Varredura de Anotação para Conteúdo EJB Empacotado em um Módulo JAR EJB. Varredura de Anotação para Conteúdo EJB Empacotado em um Módulo JAR EJB
ejb-jar.xml valor metadata-complete em ejb-jar.xml As anotações são varridas?
Existe, com uma versão de 2.x ou anterior NA Não
Existe, com uma versão de 3.x ou posterior verdadeiro Não
Existe, com uma versão de 3.x ou posterior false (ou omitido) Sim
Não existe NA Sim
Tabela 2. Varredura de Anotação para Conteúdo EJB Empacotado em um Módulo WAR. Varredura de Anotação para Conteúdo EJB Empacotado em um Módulo WAR
arquivo ejb-jar.xml valor metadata-complete em ejb-jar.xml Arquivo web.xml valor metadata-complete em web.xml As anotações são varridas?
Existe, com uma versão de 3.x ou posterior verdadeiro NA NA Não
Existe, com uma versão de 3.x ou posterior false (ou omitido) NA NA Sim
Existe, com uma versão de 2.x ou anterior NA NA NA Não
Não existe NA Existe, com uma versão de 2.5 ou posterior verdadeiro Não
Não existe NA Existe, com uma versão de 2.5 ou posterior false (ou omitido) Sim
Não existe NA Existe, com uma versão de 2.4 ou anterior NA Não
Não existe NA Não existe NA Sim
Nota:

É importante entender a distinção entre o atributo metadata-complete do elemento ejb-jar do descritor de implementação ejb-jar.xml e a configuração de instalação do metadata-complete que pode ser especificada durante o processo de instalação do aplicativo ou módulo.

O atributo metadata-complete do elemento ejb-jar do arquivo ejb-jar.xml é um atributo XML. Ele é usado pelo servidor para determinar se as classes devem ser varridas em busca de dados de anotação, conforme descrito pelas regras nas tabelas Varredura de Anotação para Conteúdo EJB.

Em contraste, a configuração metadata-complete que pode ser especificada no momento da instalação é usada pelo servidor para ajudar a gerar o arquivo ejb-jar.xml. Se nenhum arquivo ejb-jar.xml existir no módulo, e a configuração de instalação de metadata-complete receber um valor de true, o servidor varrerá o conteúdo da anotação e o usará para gerar um arquivo ejb-jar.xml; depois ele irá configurar o atributo XML metadata-complete nesse arquivo para um valor de true.

Unidades de Persistência

As unidades de persistência, incluindo o arquivo persistence.xml e as classes associadas a ele, podem ser compactadas no módulo para o qual são necessárias. Também podem ser compactadas no arquivo JAR do utilitário separado compactado no arquivo EAR com seu módulo dependente.

Quando um arquivo JAR de utilitário separado é compactado, é necessário que o módulo que o deseja utilize as unidades de persistência para declarar uma dependência no arquivo JAR do utilitário utilizando o MANIFEST típico. Caminho de classe do MF: declarações. Consulte o cenário de exemplo para este método de empacotamento na seção neste tópico chamada "Fachadas da sessão usadas para cenário de persistência"
Nota: A compactação de unidades de persistência nas bibliotecas compartilhadas definidas utilizando o recurso de biblioteca compartilhada de gerenciamento de sistemas do WebSphere Application Server não é suportada nesse momento.

Empacotamento do Aplicativo

É possível combinar beans EJB 2.x e anteriores com beans EJB 3.x no mesmo aplicativo. No entanto, beans EJB 3.x não são reconhecidos nos módulos EJB 2.x ou EJB 1.x.

No caso de um arquivo EAR conter apenas os arquivos JAR e web application archive (WAR), e nenhum arquivo application.xml, o produto fornecerá um descritor de implementação J2EE 1.4 padrão baseado nos seguintes padrões descritos na especificação Java EE:
  • Assume-se que o nome do aplicativo seja o nome do arquivo EAR, mas com a extensão do arquivo EAR removida.
  • Assume-se que arquivos terminados em .war sejam módulos da Web. A raiz de contexto do módulo da Web é o nome do arquivo relativo à raiz do pacote de aplicativos, mas com a extensão do arquivo WAR removida.
  • Assume-se que arquivos terminados em .jar que não estão no diretório /lib e que contêm um arquivo ejb-jar.xml ou pelo menos uma classe que define uma anotação @Stateful, @Stateless, @Singleton ou @MessageDriven, sejam módulos EJB.
  • Assume-se que outros arquivos JAR que não estejam no diretório /lib não sejam módulos EJB.
Se o arquivo archive do aplicativo contiver um descritor application.xml, o processamento ocorrerá de acordo com as diretivas desse descritor.

Link automático

AutoLink fornece a capacidade de tentar resolver automaticamente referências EJB para os componentes contidos em um arquivo EAR, sem precisar especificar um nome de ligação JNDI. Isso simplifica a implementação do aplicativo com grandes quantidades de beans e referências, no caso de serem exclusivos e inequívocos.
Restrição: O link automático não deverá ser utilizado para referências a componentes implementados em um cluster.

Empacotamento de JPA

Recomenda-se que as unidades de persistência sejam compactadas em arquivos JAR separados para torná-los mais acessíveis e reutilizáveis. Elas podem ser testadas fora do contêiner, com ou sem ocorrência real de persistência do banco de dados. As unidades de persistência podem ser incluídas em aplicativos independentes ou em arquivos EAR como arquivos JAR de utilitário. Em razão da variedade de casos de uso e de problemas potenciais de desempenho ao varrer grandes quantidades de classes, recomenda-se que a unidade de persistência defina as classes das unidades de persistência.

Fachadas da Sessão Usadas para Cenário de Persistência

Um padrão comum é utilizar fachadas de sessão para a persistência. O uso de fachadas de bean de sessão para acionar a JPA não é suportado. A interface EntityManager não é protegida contra encadeamento, portanto, os servlets nunca devem injetar @PersistenceContext. Os servlets devem utilizar o padrão de fachada ou utilizar uma instância EntityManagerFactory para criar um EntityManager em cada pedido.

Recomenda-se que as unidades de persistência JPA sejam definidas em um arquivo JAR separado das fachadas do bean de sessão. Isso não é apenas uma boa prática que fornece maior flexibilidade no compartilhamento, como também evita problemas de mistura de classes anotadas JPA e não JPA.

Normalmente, um arquivo JAR é criado para receber as classes de entidade e a definição JPA persistence.xml e é incluído no arquivo EAR com um arquivo JAR do utilitário. O módulo EJB 3.x inclui uma dependência do arquivo JAR declarando-o no módulo EJB 3.x MANIFEST.MF. Por exemplo, se um EAR contiver um arquivo TradeApp.ear, TradeWeb.war, EJB3Trade.jar, e TradeInfo.jar, o arquivo EJB3Trade.jar terá um MANIFEST.MF semelhante ao seguinte:

Manifest-Version: 1.0
Caminho de Classe: TradeInfo.jar

A fachada de sessão no arquivo EJB3Trade.jar refere-se a classes de entidade JPA e a unidades de persistência no arquivo TradeInfo.jar. O aplicativo da Web definido no arquivo TradeWeb.war pode fazer o mesmo trabalho com os objetos de entidade JPA, como Objetos de Transferência de Dados fluindo entre as camadas de contêiner EJB e da Web.

Cenário de Referência de Bean de Sessão de Camada Cruzada e Versão Cruzada

Há várias maneiras de se definir e usar referências a beans de sessão EJB 3.x. Para sessão para sessão EJB 3.x, o destino da injeção de @EJB pode ser usado. Para camada cruzada, por exemplo, aplicativo da Web para sessão EJB 3.x, ou versão cruzada, por exemplo, sessão EJB 2.1 para sessão EJB 3.x, uma referência do descritor de implementação XML pode ser usada para definir ejb-refs e ejb-local-refs. Existem duas variações disso, dependendo se a interface de negócios EJB 3.x é usada como referência, ou uma interface no estilo componente pré-EJB 3.x que também defina uma EJBLocalHome é usada como referência. Aplicativos da Web e aplicativos clientes também podem usar a anotação @EJB se o componente de referência puder ser resolvido usando autolink.

Para cenários de migração em que beans de sessão estão sendo convertidos de beans EJB 2.1 para beans EJB 3.x, o padrão é normalmente editar a classe de bean da Sessão, substituir as implementações SessionBean por implementações da interface de negócios, remover as extensões EJBLocalObject da interface local e cláusulas de lançamento não comerciais, e incluir a @Stateful @Local @LocalHome(<localhome>.class) ou anotações similares. ejb-refs e ejb-local-refs existentes são ligados à nova implementação do bean de sessão.
Nota: O nome da ligação padrão é alterado.

O cenário anterior usa um padrão de cliente de estilo EJB 2.1 com uma implementação de bean de sessão de estilo EJB 3.x. Para um estilo de cliente mais atual, o lado do cliente pode ser limpo para consultar diretamente a interface de negócios do bean de sessão, em vez de passar por uma interface inicial. Nesse caso, não é necessário definir a anotação @LocalHome(<localhome>.class). É possível usar uma definição variante de ejb-ref e ejb-local-ref para isso. Utilize um valor null para o valor de elemento local-home e ligue o ejb-local-ref à ligação ejblocal: do bean de sessão em vez da ligação inicial. Por exemplo:

<ejb-local-ref id="EJBLocalRef_1154112538064">
	<description>com.ibm.persistence.ejb3.order.facadecom.ibm.persistence.ejb3.order.facade</description>
	<ejb-ref-name>ejb/OrderEJB</ejb-ref-name>
	<ejb-ref-type>Session</ejb-ref-type>
	<local-home></local-home>
	<local>com.ibm.persistence.ejb3.order.facade.OrderProcessor</local>
</ejb-local-ref>

O código do cliente também deve ser ajustado para o cast apropriado para o objeto sendo consultado. Neste caso, a interface de negócios no lugar da interface inicial:

try {
	InitialContext ctx = new InitialContext();
	orderProcessor = (OrderProcessor)ctx.lookup("java:comp/env/ejb/OrderEJB");
}
catch(Exception e){
	e.printStackTrace(System.out);
	throw new ServletException(e);
}

Ícone que indica o tipo de tópico Tópico de Conceito



Ícone de registro de data e hora Última atualização: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cejb_packfep
Nome do arquivo: cejb_packfep.html