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.
- 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
.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.
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.
- 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.
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 |
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 |
É 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.
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.
- 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.
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.
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);
}