Conteúdo EJB em Módulos WAR

Use esse tópico para entender os requisitos de criação de pacote do conteúdo do Enterprise JavaBeans (EJB) nos módulos do web application archive (WAR).

Conteúdo EJB Suportado

Exceto para restrições declaradas explicitamente, a função do EJB, que é suportada para beans compactados dentro dos módulos EJB Java™ archive (JAR), também é suportada para beans compactados dentro dos módulos WAR. Um bean que é compactado dentro de um módulo WAR pode ter o mesmo comportamento que um bean que é compactado dentro de um módulo JAR EJB.

Todos os tipos de beans EJB 3.x são suportados em módulos WAR e em beans de sessão 2.x e 1.x. Consulte a especificação EJB 3.1 para obter detalhes completos.

Mecânica de Empacotamento

As regras para empacotar conteúdo EJB em um módulo WAR são diferentes das regras para empacotar conteúdo EJB em um módulo JAR.

Os arquivos de classe de bean devem ser colocados em um de dois locais no módulo WAR:
  • Livremente na estrutura de diretório WEB-INF/classes
  • Em um arquivo JAR colocado no diretório WEB-INF/lib

Por exemplo, é possível colocar a classe de bean com.foo.MyBean livremente no módulo WAR neste local: WEB-INF/classes/com/foo/MyBean.class.

Você também pode colocar essa classe de bean no arquivo myJar.jar, que é então colocado neste local: WEB-INF/lib/myJar.jar.

Um módulo WAR pode ter alguns códigos de bean colocados livremente na estrutura de diretório WEB-INF/classes e outros códigos de bean dentro de arquivos JAR no diretório WEB-INF/lib . Isso também é válido para um modulo WAR para que todo o código de bean esteja na estrutura de diretório WEB-INF/classes e nada no diretório WEB-INF/lib ou para que todo o código de bean esteja nos arquivos JAR no diretório WEB-INF/lib e nada no WEB-INF/classes.

É válido ter diversos arquivos JAR no diretório WEB-INF/lib, sendo que todos eles podem conter código de bean.

Se a mesma classe de bean for colocada livremente na estrutura de diretório WEB-INF/classes e também colocada em um arquivo JAR no diretório WEB-INF/lib, a instância da classe colocada livremente na estrutura de diretórioWEB-INF/classes será carregada e a instância colocada em um arquivo JAR no diretório WEB-INF/lib será ignorada.

Se a mesma classe de bean for colocada em dois arquivos JAR diferentes no diretório WEB-INF/lib, não se saberá qual instância da classe será carregada e qual instância será ignorada. No tempo de execução, o servidor escolhe arbitrariamente uma instância de classe e a carrega e ignora a outra.

Os arquivos descritores da implementação EJB devem ser colocados no diretório WEB-INF. Esse diretório contém o descritor de implementação ejb-jar.xml e quaisquer ligações e arquivos de extensão XML ou XMI ibm-ejb-jar-ext e ibm-ejb-jar-bnd. Os arquivos descritores EJB que estão localizados dentro dos arquivos JAR no diretório WEB-INF/lib são ignorados. Tal como um módulo JAR EJB, pode haver de 0 a 1 instância de cada arquivo descritor EJB. Não pode haver diversas instâncias de nenhum arquivo descritor EJB. Isso não inclui o arquivo persistence.xml, se ele existir. Pela especificação Java Persistence API, se um arquivo persistence.xml estiver presente, ele deverá permanecer em um diretório META-INF localizado no diretório WEB-INF/classes do módulo WAR ou em um arquivo JAR no diretório WEB-INF/lib do módulo WAR. Por exemplo:
  • WEB-INF/classes/META-INF/persistence.xml
  • WEB-INF/lib/MyEntity.jar
O MyEntity.jar contém META-INF/persistence.xml.
Se um arquivo ejb-jar.xml estiver localizado em um arquivo JAR no diretório WEB-INF/lib, uma mensagem de aviso é exibida. Por exemplo:
IWAE0068W O descritor de implementação EJB META-INF/ejb-jar.xml no arquivo foo.jar do archive de biblioteca será ignorado. O produto não processa o descritor de implementação META-INF/ejb-jar.xml em archives de biblioteca. Mova o descritor de implementação META-INF/ejb-jar.xml do archive de biblioteca para o diretório WEB-INF no módulo WAR.

Um módulo WAR deve ser versão 2.5 ou posterior para conter o conteúdo EJB. Conteúdo EJB posicionado em um modo WAR que seja versão 2.4 ou anterior é ignorado.

Evitar Problemas Evitar Problemas: Se um módulo WAR for versão 2.5 ou posterior, os arquivos de metadados da web contendo informações de ligações e extensões devem usar a versão XML destes aquivos, não a versão XMI.gotcha

Diferenças Técnicas para Enterprise Beans que são Empacotados em um Arquivo WAR

A seguinte lista contém diferenças técnicas principais que existem entre os beans que são compactados em um módulo WAR e beans que são compactados em um módulo JAR EJB:

  • Namespace de componente compartilhado

    Todos os componentes em um módulo WAR compartilham um único namespace de componente. Isso significa que cada componente EJB compartilha um namespace de componente único com todos os outros componentes EJB no arquivo WAR e quaisquer componentes não EJB, como servlets. Em contraste, um componente EJB empacotado em um módulo JAR EJB tem seu próprio namespace de componente particular, que não é compartilhado com nenhum outro componente.

    O namespace de componente compartilhado tem impactos importantes. Primeiro, um componente (EJB ou não EJB) pode declarar uma referência, e um componente diferente pode procurar o namespace do componente para essa referência. Segundo, as referências declaradas por um componente podem entrar em conflito com as referências declaradas por outro componente. Em contraste, um EJB empacotado em um módulo JAR EJB não pode consultar no namespace do componente uma referência declarada por um componente EJB ou não EJB, e é impossível para uma referência declarada pelo EJB entrar em conflito com o namespace do componente com uma referência declarada por qualquer outro componente, mesmo se a referência tiver o mesmo nome.

    Durante o uso do namespace compartilhado, é válido que a mesma referência seja declarada diversas vezes, contanto que essas declarações de referência não entrem em conflito umas com as outras. Se as declarações de referência não entrarem em conflito, o servidor se comportará como se a referência tivesse sido declarada exatamente uma vez.

    Se as declarações de referência entrarem em conflito, uma mensagem de erro será emitida e o aplicativo falhará ao iniciar. Uma mensagem de aviso é emitida para cada referência em conflito. A mensagem de aviso indica o nome da referência conflitante e diversos valores designados para essa referência. Após todas as mensagens de aviso serem emitidas, uma exceção será emitida.

  • Local dos arquivos descritores EJB

    O arquivo descritor de implementação ejb-jar.xml, e qualquer outro arquivo descritor, devem ser colocados no diretório WEB-INF do WAR. Qualquer instância de um arquivo descritor EJB em qualquer lugar no WAR, incluindo o diretório META-INF de um arquivo JAR no diretório WEB-INF/lib, será ignorado.

  • Determinando se anotações são varridas

    As regras para determinar se você deve fazer a varredura de anotações são diferentes para módulos WAR e JAR EJB. Consulte o tópico Visão Geral de Pacote do Módulo EJB 3.x para obter o conjunto de regras completo.

  • Carregamento e Visibilidade de Classes

    O padrão de uso mais comum para as classes EJB que são compactadas em um módulo WAR é as chamadas de método local a partir de componentes da Web compactados no mesmo módulo. Entretanto, essas classes EJB também podem ser acessadas pelas chamadas de método remoto ou pelos clientes em outros módulos. Nesses casos, é importante entender as regras de visibilidade das classes EJB que são compactadas em um módulo WAR. As regras de visibilidade são diferentes quando comparadas com as classes EJB que são compactadas em um módulo JAR.

    No caso de chamadas de método EJB remoto, não há nenhuma diferença de visibilidade introduzida ao criar pacotes das classes EJB em um módulo WAR. Os EJBs são limitados ao namespace global e podem ser consultados a partir dos, ou injetados nos, componentes em outros módulos. O cliente remoto deve fazer chamadas de método com uma classe de stub apropriada. A geração de classe de stub é descrita nesse tópico na seção "Geração de Stub".

    No caso de chamadas de método EJB local a partir de componentes em outros módulos, há diferenças de visibilidade porque os EJBs são compactados em um módulo WAR. Essas diferenças de visibilidade ocorrem porque há implicações do carregador de classes que devem ser consideradas.

    O conteúdo que é compactado em todos os módulos JAR EJB para o aplicativo inteiro é carregado por uma instância do carregador de classes do aplicativo única.

    Em contraste, todo conteúdo empacotado em um módulo WAR é carregado em uma instância de carregador de classes específica para o módulo WAR. A instância do carregador de classes do aplicativo única que é usada para carregar todo o conteúdo JAR EJB é o pai de cada uma das instâncias do carregador de classes que são usadas para carregar o conteúdo WAR.

    A visibilidade de uma classe é afetada pela instância do carregador de classes que o carregou. Uma instância do carregador de classes pode ver classes carregadas por ela mesma ou por um carregador de classes-pai. No entanto, um carregador de classes não pode ver uma classe carregada em um carregador de classes que não seja ele mesmo e nem um de deus pais.

    Como resultado, as classes carregadas por um carregador de classes específico de um módulo WAR podem ver classes em um módulo JAR EJB, mas não podem ver classes em outro módulo WAR. Classes em um módulo JAR EJB não podem ver classes em nenhum módulo WAR. Por exemplo, se houver conteúdo EJB compactado dentro do módulo JAR EJB ejb3.jar e também houver conteúdo EJB compactado dentro do arquivo ejb1.jar e do arquivo ejb2.jar, então:
    • Se o arquivo ejb1.jar e o arquivo ejb2.jar estiverem instalados como módulos JAR EJB, o conteúdo no arquivo ejb1.jar, arquivo ejb2.jar e arquivo ejb3.jar será todo carregado na mesma instância de carregador de classes, que também será usada para carregar quaisquer outros módulos JAR EJB no aplicativo. Nesse caso, as classes nos três arquivos JAR podem ver umas às outras, pois todas são carregadas pela mesma instância de carregador de classes.
    • Se o arquivo ejb1.jar e o arquivo ejb2.jar estiverem ambos compactados dentro do diretório WEB-INF/lib de um arquivo WAR, o conteúdo dento do arquivo ejb1.jar e do arquivo ejb2.jar será carregado por uma instância do carregador de classes única. Entretanto, esse carregador de classes não é o mesmo que o carregador usado para carregar o conteúdo do arquivo ejb3.jar e por qualquer outro JAR EJB no aplicativo. Nesse caso, as classes nos arquivos ejb1.jar e ejb2.jar podem ser vistas entre si e também ver as classes no arquivo ejb3.jar. As classes no arquivo ejb3.jar não poderá ver as classes nos arquivos ejb1.jar ou ejb2.jar.
    • Se o arquivo ejb1.jar estiver compactado dentro do diretório WEB-INF/lib do arquivo firstWar.war e o arquivo ejb2.jar estiver compactado dentro do diretório WEB-INF/lib do arquivo secondWar.war, o conteúdo no arquivo ejb1.jar será carregado na primeira instância do carregador de classes, o conteúdo no arquivo ejb2.jar será carregado em uma segunda instância do carregador de classes e o conteúdo ejb3.jar, e todos os outros EJB JARs no aplicativo, serão carregados em uma terceira instância do carregador de classes. Nesse caso, as classes nos arquivos ejb1.jar e ejb2.jar não poderão ver umas às outras, mas poderão ver as classes no arquivo ejb3.jar. As classes no arquivo ejb3.jar não poderá ver as classes no arquivo ejb1.jar ou arquivo ejb2.jar.
    Uma estratégia para evitar essas complicações do carregador de classes é compactar as classes da interface EJB em uma biblioteca compartilhada.
    Boas Práticas Boas Práticas: Não compacte a mesma classe, ambos os módulos JAR EJB e WAR, no mesmo aplicativo. O empacotamento da mesma classe em diversos locais no mesmo aplicativo pode resultar em confusão em relação a qual instância da classe será carregada e usada no tempo de execução. Essa distinção pode ser significativa se dois arquivos .class representarem versões diferentes da classe. Para evitar esse cenário, compacte o arquivo .class em apenas um local ou altere a estrutura do pacote da classe para que o nome completo da classe compactada dentro do módulo WAR seja diferente do nome completo da classe compactada no módulo JAR EJB.bprac
  • Extensão do perfil do aplicativo

    A extensão do perfil do aplicativo não é suportada para as classes EJB que forem compactadas nos módulos WAR.

Geração de Stub

O acesso remoto aos métodos EJB requer o uso de classes de stub do lado do cliente. Para a maioria dos ambientes do cliente, o tempo de execução do produto gera automaticamente as classes de stub necessárias. Uma exceção é o ambiente do thin client. Para os thin clients, as classes de stub devem ser geradas e compactadas manualmente com o cliente.

Use a ferramenta createEJBStubs para gerar stubs quando o conteúdo EJB for compactado em um módulo WAR, independente da versão do EJB.

Consulte o tópico Criar Comandos de Stubs para obter informações adicionais.

Evitar Problemas Evitar Problemas: Quando criar o pacote das classes EJB 2.1 em um módulo WAR, não inclua nenhuma classe de stub gerada pela ferramenta EJBDeploy. Essas classes de stub são diferentes das classes de stub geradas automaticamente pelo tempo de execução do produto e pode causar falhas. Na maioria das situações, as classes de stub geradas automaticamente são suficientes. A exceção será se um componente no módulo da Web tiver que fazer uma chamada de método remoto em uma classe EJB 2.1 compactada em outro módulo JAR. Nesse caso, a classe de stub gerada EJBDeploy para o EJB no outro módulo JAR deve ser compactada no módulo WAR.gotcha

Conteúdo de EJB 2.x e 1.x em um Módulo WAR

Exceto para beans de entidade, o conteúdo EJB 2.x e 1.x é suportado em um módulo WAR.

Um módulo 2.x ou 1.x compactado dentro de um arquivo WAR requer um descritor de implementação ejb-jar.xml na versão 2.x ou 1.x no diretório WEB-INF do módulo WAR. Se as ligações e os arquivos de extensão XMI estiverem presentes, você também deverá compactar essas ligações e arquivos no diretório WEB-INF de um módulo WAR.

Beans de sessão e beans acionados por mensagens que você implementa de acordo com o estilo de codificação 2.x ou 1.x podem ser empacotados em um módulo WAR.

Beans de entidade persistência gerenciada por bean (BMP) e persistência gerenciada por contêiner (CMP) não são suportados em um módulo WAR.

Os serviços de perfil do aplicativo e de intenção de acesso não são suportados em um módulo WAR. Os beans de sessão em um módulo WAR não podem acessar as tarefas de perfil do aplicativo.

O conteúdo EJB que é implementado de acordo com o estilo de codificação 3.x e com os estilos de codificação 2.x e 1.x podem ser compactados juntos em um módulo WAR único. Entretanto, nesse caso, você deve declarar quaisquer informações de ligações e de extensões com a versão XML dos arquivos, e não com a versão XMI.

Movendo o Conteúdo EJB Existente a Partir de Módulo JAR EJB para Módulos WAR

Uma abordagem é colocar o arquivo JAR EJB existente no diretório WEB-INF/lib do arquivo WAR. Em seguida, remova os arquivos descritores do diretório META-INF do arquivo JAR e coloque-os no diretório WEB-INF do arquivo WAR.

Uma segunda abordagem é colocar os arquivos de classe do arquivo JAR EJB no local correto sob o diretório WEB-INF/classes no módulo WAR. Em seguida, remova os arquivos descritores do diretório META-INF do arquivo JAR e coloque-os no diretório WEB-INF do arquivo WAR.

Se diversos módulos JAR EJB forem movidos para um único módulo WAR, você deverá mesclar o conteúdo de cada arquivo descritor localizado anteriormente nos diretórios META-INF dos módulos JAR EJB na única versão dos arquivos descritores que agora estão colocados no diretório WEB-INF do arquivo WAR. Os exemplos de arquivos descritores que podem ser mesclados incluem, mas não se limitam a, ejb-jar.xml, ibm-ejb-jar-bnd.xml, ibm-ejb-jar-ext.xml, e ibm-ejb-jar-ext-pme.xml.

Você deve inspecionar as referências declaradas pelos vários componentes no módulo WAR, tanto EJB quanto não EJB, para garantir que elas não entrem em conflito umas com as outras, desde que tudo que há no módulo WAR compartilhe um único namespace de componente.

Você deve modificar as ligações e arquivos XMI de extensão que são movidos de um módulo JAR EJB para um módulo WAR em vários locais para remover referências para META-INF/ejb-jar.xml e substituí-las por WEB-INF/ejb-jar.xml.

Função EJB que é Suportada em Módulos JAR EJB, Mas Não em Módulos WAR

A função EJB a seguir não é suportada em módulos WAR:
  • Beans de entidade BMP e CMP
  • Beans de inicialização de estilo pré-EJB 3.1
    Atenção: Beans de inicialização singleton definidos por EJB 3.1 são suportados.
Se um bean de entidade for colocado em um módulo WAR, mensagens de erro serão exibidas e o aplicativo falhará ao iniciar. Por exemplo, o bean de entidade foo é colocado no módulo foo.war no aplicativo FooApp. Isso resulta nas seguintes mensagens:
CWMDF0025E: Os beans de entidade nos módulos Web application archive (WAR) EJB não são permitidos, segundo a especificação EJB 3.1.
WSVR0039E: Não é possível iniciar o arquivo JAR EJB, foo.war: Os beans de entidade nos módulos Web application archive (WAR) EJB não são permitidos, segundo a especificação EJB 3.1. O bean foo no módulo foo.war deve ser movido para um módulo EJB independente. Examine o log para ver uma lista completa de beans de entidade válidos em um módulo WAR.

Í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_ejbinwar
Nome do arquivo: cejb_ejbinwar.html