EJB 3.0 e EJB 3.1 EJB 3.0

Aprenda sobre o modelo de implementação Enterprise JavaBeans (EJB) 3.0, e 3.1 incluindo a implementação Just-In-Time (JIT).

Todos os produtos do servidor de aplicativos Java™ Enterprise Edition (Java EE ) têm alguma forma de fase de implementação de EJB na qual seu aplicativo é customizado para execução nessa implementação específica do servidor de aplicativos. Normalmente, isso é realizado por uma ferramenta de implementação específica do servidor de aplicativos, que gera código para servir como ponte para a interface EJB e código de implementação para a implementação do contêiner de EJB do servidor de aplicativos. Algumas ferramentas de implementação de produtos do servidor de aplicativos alteram os códigos de byte das classes de aplicativos em vez de utilizar a geração de códigos, mas o resultado final é semelhante.

O Servidor de Aplicativos faz a ponte da interface EJB com sua implementação gerando código que encapsula as classes de implementação EJB, conectando-as ao contêiner EJB do Servidor de Aplicativos. Isso possibilita ao contêiner EJB hospedar os enterprise beans e fornecer serviços a eles. Se um ou mais dos enterprise beans tiver definido interfaces remotas, será gerado código adicional para fornecer a função remota.

Para obter informações adicionais sobre como empacotar seu módulo EJB, consulte o tópico que contém a visão geral do pacote do módulo EJB 3.x.

Ferramenta EJBDeploy

Historicamente, a implementação de EJB no produto Application Server foi executada pela ferramenta EJBDeploy, que está incluída no WebSphere Application Server e é fornecida no mesmo pacote das ferramentas de desenvolvimento para os produtos WebSphere.

A ferramenta EJBDeploy examina as interfaces externas para os enterprise beans, gera o código wrapper como arquivos .java e compila utilizando o compilador javac para produzir arquivos .class, que são compactados no módulo EJB com o código do aplicativo. A ferramenta EJBDeploy também executa a ferramenta rmic nas interfaces EJB remotas no aplicativo, produzindo arquivos de classe stub e tie adicionais que interagem com o RMI-IIOP (Remote Method Invocation over Internet Inter-ORB Protocol) ORB (Object Request Broker), fornecendo suporte ao objeto remoto.

Para módulos anteriores ao EJB 3.0, você executava a ferramenta EJBDeploy quando instalava o aplicativo no Application Server ou antes de instalar o aplicativo a partir da ferramenta de linha de comandos ou da ferramenta de desenvolvimento.

Implementação Just-In-Time (JIT)

O suporte ao EJB 3.0 no Application Server introduziu um novo recurso chamado implementação JIT.

Com a implementação JIT, o contêiner de EJB gera dinamicamente o wrapper, as classes stub e tie na memória quando o aplicativo está em execução. Além disso, o contêiner da Web e os contêineres de aplicativo cliente geram dinamicamente a classe de stub necessária para chamadas EJB remotas.

Efetivamente, isso significa que não é necessário processar módulos EJB 3.0 ou 3.1, módulos da Web que chamam beans EJB 3.0 ou 3.1 ou módulos de cliente que chamam beans EJB 3.0 ou 3.1 por meio da ferramenta EJBDeploy antes de executá-los no Application Server.

ferramenta createEJBStubs

Na maioria dos casos, o recurso de implementação Just-In-Time pode gerar dinamicamente as classes stub RMI-IIOP que são necessárias para chamar as interfaces EJB remotas. Existem algumas instâncias nas quais essas classes stub não são geradas dinamicamente. Para clientes EJB 3.0 ou 3.1 que não estão em execução em um contêiner da Web ativado para EJB 3.x, contêiner EJB ou contêiner do cliente, você deve gerar as classes de stub com a ferramenta createEJBStubs e garantir que os stubs gerados estejam disponíveis no caminho da classe do ambiente do cliente. Normalmente, isso seria realizado copiando-se os stubs gerados para o local em que está a classe de interface de negócios do cliente.

A ferramenta createEJBStubs deve ser utilizada para gerar stubs do lado do cliente para os seguintes ambientes:
  • Clientes Java Standard Edition (SE) "Bare" nos quais uma Java Virtual Machine (JVM) Java SE é o ambiente do cliente.
  • Contêineres em ambientes do Application Server anteriores à Versão 7 que não têm o Feature Pack for EJB 3.0 aplicado.
  • Ambientes que não são ambientes do WebSphere Application Server.

Interoperabilidade

Pode haver resultados inesperados se um produto da pilha do WebSphere, ou outro produto, que é executado em uma versão do Application Server que não suporta EJB 3.0 ou 3.1 tentar chamar remotamente um método em um enterprise bean que é compatível com EJB 3.x em um servidor separado em execução em uma versão do Application Server que suporta EJB 3.0 ou 3.1. Se esses produtos tentarem chamar um método por meio da interface de negócios remota do EJB 3.x do enterprise bean, eles poderão encontrar exceções que foram introduzidas no EJB 3.0 que serão mandadas de volta para o ambiente que não é compatível com EJB 3.x.

Esse cenário também poderia ser um problema para um administrador de um ambiente que inclui uma combinação de produtos da pilha contendo uma mistura de instâncias compatíveis e não compatíveis com EJB 3.x do Application Server.

A seguir está uma lista das classes de exceção introduzidas no EJB:
  • javax.ejb.ConcurrentAccessException
  • javax.ejb.EJBAccessException
  • javax.ejb.EJBTransactionRequiredException
  • javax.ejb.EJBTransactionRolledbackException
  • javax.ejb.NoSuchEJBException

Consulte a etapa de implementação do módulo EJB para endereçar potenciais problemas de interoperabilidade.

Módulos EJB 2.x

Os módulos EJB 2.x que foram convertidos em módulos EJB 3.0 ou EJB 3.1 devem ter todos os arquivos gerados pelo WebSphere Application Server (incluindo classes de stub e de empate) removidos antes da implementação do EJB no produto Application Server.


Í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_deployejbfp
Nome do arquivo: cejb_deployejbfp.html