Jakarta Enterprise Beans - Jakarta Enterprise Beans

Jakarta Enterprise Beans ( EJB ; anteriormente Enterprise JavaBeans) é uma das várias APIs Java para construção modular de software empresarial . EJB é um componente de software do lado do servidor que encapsula a lógica de negócios de um aplicativo. Um contêiner de web EJB fornece um ambiente de tempo de execução para componentes de software relacionados à web, incluindo segurança de computador , gerenciamento de ciclo de vida de servlet Java , processamento de transações e outros serviços da web . A especificação EJB é um subconjunto da especificação Java EE .

Especificação

A especificação EJB foi originalmente desenvolvida em 1997 pela IBM e posteriormente adotada pela Sun Microsystems (EJB 1.0 e 1.1) em 1999 e aprimorada no Java Community Process como JSR 19 (EJB 2.0), JSR 153 (EJB 2.1), JSR 220 (EJB 3.0), JSR 318 (EJB 3.1) e JSR 345 (EJB 3.2).

A especificação EJB fornece uma maneira padrão de implementar o software de 'negócios' do lado do servidor (também chamado de " back-end ") normalmente encontrado em aplicativos corporativos (em oposição ao software de interface de usuário 'front-end' ). Esse software aborda os mesmos tipos de problema e as soluções para esses problemas são frequentemente reimplementadas repetidamente pelos programadores. Jakarta Enterprise Beans se destina a lidar com questões comuns como persistência , integridade transacional e segurança de uma forma padrão, deixando os programadores livres para se concentrarem nas partes específicas do software corporativo em questão.

Responsabilidades gerais

A especificação EJB detalha como um servidor de aplicativos fornece as seguintes responsabilidades:

• Processamento de transação
• Integração com os serviços de persistência oferecidos pelo Jakarta Persistence (JPA)
• Controle de simultaneidade
• Programação orientada a eventos usando Jakarta Messaging (JMS) e Jakarta Connectors (JCA)
• Invocação de método assíncrono
• Agendamento de trabalho
• Serviços de nomenclatura e diretório via Java Naming and Directory Interface (JNDI)
• Comunicação entre processos usando RMI-IIOP e serviços da Web
• Segurança ( JCE e JAAS )
• Implantação de componentes de software em um servidor de aplicativos

Além disso, a especificação Jakarta Enterprise Beans define as funções desempenhadas pelo contêiner EJB e os EJBs, bem como como implantar os EJBs em um contêiner. Observe que a especificação EJB não detalha como um servidor de aplicativos fornece persistência (uma tarefa delegada à especificação JPA), mas detalha como a lógica de negócios pode se integrar facilmente com os serviços de persistência oferecidos pelo servidor de aplicativos.

História

As empresas descobriram que o uso de EJBs para encapsular a lógica de negócios trazia uma penalidade de desempenho. Isso ocorre porque a especificação original permitia apenas a chamada de método remoto por meio do CORBA (e, opcionalmente, outros protocolos), embora a grande maioria dos aplicativos de negócios realmente não exija essa funcionalidade de computação distribuída . A especificação EJB 2.0 abordou essa preocupação ao adicionar o conceito de interfaces locais que poderiam ser chamadas diretamente sem penalidades de desempenho por aplicativos que não eram distribuídos em vários servidores.

A especificação EJB 3.0 ( JSR 220) foi uma partida de seus predecessores, seguindo um novo paradigma de leveza. EJB 3.0 mostra uma influência do Spring em seu uso de objetos Java simples e seu suporte para injeção de dependência para simplificar a configuração e integração de sistemas heterogêneos. Gavin King, o criador do Hibernate, participou do processo EJB 3.0 e é um defensor declarado da tecnologia. Muitos recursos originalmente no Hibernate foram incorporados na Java Persistence API , a substituição dos beans de entidade no EJB 3.0. A especificação EJB 3.0 depende muito do uso de anotações (um recurso adicionado à linguagem Java com sua versão 5.0) e convenção sobre configuração para permitir um estilo de codificação muito menos detalhado. Assim, em termos práticos, o EJB 3.0 é muito mais leve e quase um API completamente novo, tendo pouca semelhança com as especificações EJB anteriores.

Exemplo

O seguinte mostra um exemplo básico de como um EJB se parece no código:

@Stateless 
public class CustomerService { 
  

  private EntityManager entityManager; 
   
  public void addCustomer(Customer customer) { 
    entityManager.persist(customer); 
  } 
}

O acima define uma classe de serviço para persistir um objeto Cliente (via mapeamento O / R ). O EJB cuida do gerenciamento do contexto de persistência e o método addCustomer () é transacional e thread-safe por padrão. Conforme demonstrado, o EJB se concentra apenas na lógica de negócios e na persistência e não sabe nada sobre nenhuma apresentação específica.

Esse EJB pode ser usado por uma classe, por exemplo, na camada da web da seguinte forma:

@Named	
@RequestScoped
public class CustomerBacking {
   @EJB 
   private CustomerService customerService;

   public String addCustomer(Customer customer) {
      customerService.addCustomer(customer);
      context.addMessage(...); // abbreviated for brevity
      return "customer_overview";
   }
}

O acima define um bean de apoio JavaServer Faces (JSF) no qual o EJB é injetado por meio da anotação @EJB. Seu método addCustomer é normalmente vinculado a algum componente de IU, como um botão. Ao contrário do EJB, o bean de apoio não contém nenhuma lógica de negócios ou código de persistência, mas delega essas preocupações ao EJB. O bean de apoio conhece uma apresentação específica, da qual o EJB não tinha conhecimento.

Tipos de Enterprise Beans

Um contêiner EJB contém dois tipos principais de feijão:

• Beans de sessão que podem ser "Stateful", "Stateless" ou "Singleton" e podem ser acessados ​​por meio de uma interface Local (mesma JVM) ou Remota (JVM diferente) ou diretamente sem uma interface, caso em que a semântica local se aplica. Todos os beans de sessão suportam execução assíncrona para todas as visualizações (local / remoto / sem interface).
• Message Driven Beans (MDBs, também conhecidos como Message Beans). Os MDBs também oferecem suporte à execução assíncrona, mas por meio de um paradigma de mensagens.

Beans de sessão

Stateful Session Beans

Beans de sessão com estado são objetos de negócios com estado : ou seja, eles controlam com qual cliente de chamada estão lidando durante uma sessão e, portanto, o acesso à instância do bean é estritamente limitado a apenas um cliente por vez. Se o acesso simultâneo a um único bean for tentado de qualquer maneira, o contêiner serializará essas solicitações, mas por meio da anotação @AccessTimeout, o contêiner poderá lançar uma exceção. O estado dos beans de sessão com estado pode ser persistido (passivado) automaticamente pelo contêiner para liberar memória depois que o cliente não acessar o bean por algum tempo. O contexto de persistência estendida JPA é explicitamente suportado por Stateful Session Beans.

Exemplos

• O check-out em uma loja da web pode ser manipulado por um bean de sessão com estado que usaria seu estado para rastrear onde o cliente está no processo de checkout, possivelmente mantendo bloqueios nos itens que o cliente está comprando (do ponto de vista da arquitetura do sistema , seria menos ideal que o cliente gerencie esses bloqueios).

Beans de sessão sem estado

Beans de sessão sem estado são objetos de negócios que não possuem estado associado a eles. No entanto, o acesso a uma única instância do bean ainda é limitado a apenas um cliente por vez, o acesso simultâneo ao bean é proibido. Se o acesso simultâneo a um único bean for tentado, o contêiner simplesmente roteia cada solicitação para uma instância diferente. Isso torna um bean de sessão stateless automaticamente thread-safe. Variáveis ​​de instância podem ser usadas durante uma única chamada de método de um cliente para o bean, mas o conteúdo dessas variáveis ​​de instância não tem garantia de ser preservado em diferentes chamadas de método de cliente . As instâncias de beans de sessão sem estado são normalmente agrupadas. Se um segundo cliente acessar um bean específico logo após a conclusão de uma chamada de método feita por um primeiro cliente, ele pode obter a mesma instância. A falta de sobrecarga para manter uma conversa com o cliente de chamada torna-os menos intensivos em recursos do que os beans com estado.

Exemplos

• O envio de um e-mail para o suporte ao cliente pode ser tratado por um bean sem estado, pois esta é uma operação única e não faz parte de um processo de várias etapas.
• Um usuário de um site clicando em uma caixa "mantenha-me informado sobre atualizações futuras" pode acionar uma chamada para um método assíncrono do bean de sessão para adicionar o usuário a uma lista no banco de dados da empresa (esta chamada é assíncrona porque o usuário não precisa esperar para ser informado sobre seu sucesso ou fracasso).
• A busca de várias partes independentes de dados para um site, como uma lista de produtos e o histórico do usuário atual, pode ser tratada por métodos assíncronos de um bean de sessão também (essas chamadas são assíncronas porque podem ser executadas em paralelo dessa forma, o que potencialmente aumenta o desempenho). Nesse caso, o método assíncrono retornará uma instância Future .

Feijões de Sessão Singleton

Beans de sessão singleton são objetos de negócios que possuem um estado compartilhado global em uma JVM. O acesso simultâneo à única instância de bean pode ser controlado pelo contêiner (simultaneidade gerenciada por contêiner, CMC) ou pelo próprio bean (simultaneidade gerenciada por bean, BMC). O CMC pode ser ajustado usando a anotação @Lock, que designa se um bloqueio de leitura ou gravação será usado para uma chamada de método. Além disso, os Singleton Session Beans podem solicitar explicitamente que sejam instanciados quando o contêiner EJB for inicializado, usando a anotação @Startup.

Exemplos

• O carregamento de uma lista de preços diária global que será a mesma para todos os usuários pode ser feito com um único bean de sessão, pois isso evitará que o aplicativo tenha que fazer a mesma consulta a um banco de dados repetidamente ...

Feijões acionados por mensagem

Message Driven Beans são objetos de negócios cuja execução é acionada por mensagens em vez de chamadas de método. O Message Driven Bean é usado entre outros para fornecer uma abstração fácil de usar de alto nível para a especificação JMS ( Java Message Service ) de nível inferior . Ele pode se inscrever em filas de mensagens JMS ou tópicos de mensagens, o que normalmente acontece por meio do atributo activationConfig da anotação @MessageDriven. Eles foram adicionados ao EJB para permitir o processamento orientado a eventos. Ao contrário dos beans de sessão, um MDB não tem uma visão do cliente (Local / Remoto / Sem interface), i. e. os clientes não podem consultar uma instância do MDB. Um MDB apenas escuta qualquer mensagem recebida em, por exemplo, uma fila ou tópico JMS e os processa automaticamente. Apenas o suporte JMS é requerido pela especificação Java EE, mas Message Driven Beans pode suportar outros protocolos de mensagens. Esses protocolos podem ser assíncronos, mas também podem ser síncronos. Uma vez que os beans de sessão também podem ser síncronos ou assíncronos, a principal diferença entre os beans controlados por sessão e mensagem não é a sincronicidade, mas a diferença entre chamada de método (orientada a objeto) e mensagem .

Exemplos

• O envio de uma atualização de configuração para vários nós pode ser feito através do envio de uma mensagem JMS para um 'tópico de mensagem' e pode ser tratado por um Message Driven Bean ouvindo este tópico (o paradigma de mensagem é usado aqui, pois o remetente não precisa saber o número de consumidores, sua localização ou mesmo seu tipo exato).
• O envio de um trabalho para um cluster de trabalho pode ser feito enviando uma mensagem JMS para uma 'fila de mensagens' e também pode ser tratado por um Message Driven Bean, mas desta vez escutando uma fila (o paradigma de mensagem e a fila são usados, desde o remetente não precisa se preocupar com qual trabalhador executa o trabalho, mas precisa ter a garantia de que o trabalho é executado apenas uma vez).
• O processamento de eventos de tempo do agendador Quartz pode ser tratado por um Message Driven Bean; quando um gatilho Quartz dispara, o MDB é automaticamente invocado. Como o Java EE não conhece o Quartz por padrão, um adaptador de recursos JCA seria necessário e o MDB seria anotado com uma referência a isso.

Execução

Os EJBs são implementados em um contêiner EJB, geralmente em um servidor de aplicativos . A especificação descreve como um EJB interage com seu contêiner e como o código do cliente interage com a combinação contêiner / EJB. As classes EJB usadas pelos aplicativos estão incluídas no javax.ejb pacote. (O javax.ejb.spi pacote é uma interface de provedor de serviços usada apenas por implementações de contêiner EJB.)

Os clientes de EJBs não instanciam esses beans diretamente por meio do novo operador do Java, mas, em vez disso, precisam obter uma referência por meio do contêiner EJB. Essa referência geralmente não é uma referência ao bean de implementação em si, mas a um proxy , que implementa dinamicamente a interface de negócios local ou remota que o cliente solicitou ou implementa dinamicamente um subtipo do bean real. O proxy pode então ser lançado diretamente na interface ou bean. Diz-se que um cliente tem uma 'visualização' no EJB, e a interface local, a interface remota e o próprio tipo de bean correspondem, respectivamente, à visualização local, visualização remota e visualização sem interface.

Esse proxy é necessário para dar ao contêiner EJB a oportunidade de fornecer serviços transversais ( semelhantes ao AOP ) para um bean como transações, segurança, interceptações, injeções e comunicação remota. Como exemplo, um cliente invoca um método em um proxy, que primeiro iniciará uma transação com a ajuda do contêiner EJB e, em seguida, chamará o método de bean real. Quando o método do bean retorna, o proxy termina a transação (isto é, confirmando-a ou fazendo um rollback) e transfere o controle de volta para o cliente.

O Contêiner EJB é responsável por garantir que o código do cliente tenha direitos de acesso suficientes a um EJB. Os aspectos de segurança podem ser aplicados declarativamente a um EJB por meio de anotações.

Transações

Os contêineres EJB devem suportar transações ACID gerenciadas por contêiner e transações gerenciadas por bean.

As transações gerenciadas por contêiner (CMT) são, por padrão, ativas para chamadas a beans de sessão. Ou seja, nenhuma configuração explícita é necessária. Este comportamento pode ser ajustado declarativamente pelo bean por meio de anotações e, se necessário, tal configuração pode ser substituída posteriormente no descritor de implantação. O ajuste inclui desligar transações para todo o bean ou métodos específicos, ou solicitar estratégias alternativas para a propagação da transação e iniciar ou ingressar em uma transação. Essas estratégias lidam principalmente com o que deve acontecer se uma transação estiver ou ainda não em andamento no momento em que o bean é chamado. As seguintes variações são suportadas:

Como alternativa, o bean também pode declarar por meio de uma anotação que deseja manipular transações programaticamente por meio da API JTA . Este modo de operação é denominado Bean Managed Transactions (BMT), uma vez que o próprio bean trata a transação ao invés do contêiner.

Eventos

JMS ( Java Message Service ) é usado para enviar mensagens de beans para clientes, para permitir que os clientes recebam mensagens assíncronas desses beans. Os MDBs podem ser usados ​​para receber mensagens de clientes de forma assíncrona usando uma Fila JMS ou um Tópico.

Serviços de nomenclatura e diretório

Como alternativa à injeção, os clientes de um EJB podem obter uma referência ao objeto proxy do bean de sessão (o stub EJB) usando Java Naming and Directory Interface (JNDI) . Essa alternativa pode ser usada nos casos em que a injeção não está disponível, como em código não gerenciado ou clientes Java SE remotos independentes, ou quando é necessário determinar programaticamente qual bean obter.

Os nomes JNDI para os beans de sessão EJB são atribuídos pelo contêiner EJB por meio do seguinte esquema:

(entradas entre colchetes indicam peças opcionais)

Um único bean pode ser obtido por qualquer nome que corresponda aos padrões acima, dependendo da 'localização' do cliente. Clientes no mesmo módulo que o bean necessário podem usar o escopo do módulo e escopos maiores, clientes no mesmo aplicativo que o bean necessário podem usar o escopo do aplicativo e superior, etc.

Por exemplo, o código em execução no mesmo módulo que o bean CustomerService (conforme dado pelo exemplo mostrado anteriormente neste artigo) poderia usar o seguinte código para obter uma referência (local) a ele:

CustomerServiceLocal customerService =
    (CustomerServiceLocal) new InitialContext().lookup("java:module/CustomerService");

Execução remota / distribuída

Para comunicação com um cliente que está escrito na linguagem de programação Java, um bean de sessão pode expor uma visão remota por meio de uma interface anotada @Remote. Isso permite que esses beans sejam chamados de clientes em outras JVMs que podem estar localizados em outros sistemas (remotos). Do ponto de vista do contêiner EJB, qualquer código em outra JVM é remoto.

Os beans de sessão stateless e Singleton também podem expor uma "visão do cliente de serviço da Web" para comunicação remota via WSDL e SOAP ou XML simples. Isso segue as especificações JAX-RPC e JAX-WS . O suporte JAX-RPC, entretanto, é proposto para remoção futura. Para suportar JAX-WS, o bean de sessão é anotado com a anotação @WebService e os métodos que devem ser expostos remotamente com a anotação @WebMethod.

Embora a especificação EJB não mencione a exposição como serviços da Web RESTful de nenhuma forma e não tenha suporte explícito para essa forma de comunicação, a especificação JAX-RS oferece suporte explicitamente ao EJB. Seguindo a especificação JAX-RS, os beans de sessão Stateless- e Singleton podem ser recursos raiz por meio da anotação @Path e os métodos de negócios EJB podem ser mapeados para métodos de recurso por meio das anotações @GET, @PUT, @POST e @DELETE. No entanto, isso não conta como uma "visualização do cliente de serviço da web", que é usada exclusivamente para JAX-WS e JAX-RPC.

A comunicação por meio de serviços da web é típica para clientes não escritos na linguagem de programação Java, mas também é conveniente para clientes Java que têm problemas para acessar o servidor EJB por meio de um firewall. Além disso, a comunicação baseada em serviços da web pode ser usada por clientes Java para contornar os requisitos misteriosos e mal definidos para as chamadas "bibliotecas-cliente"; um conjunto de arquivos jar que um cliente Java deve ter em seu caminho de classe para se comunicar com o servidor EJB remoto. Essas bibliotecas-cliente podem entrar em conflito com as bibliotecas que o cliente já pode ter (por exemplo, se o próprio cliente também for um servidor Java EE completo) e tal conflito é considerado muito difícil ou impossível de resolver.

Legado

Interfaces de casa e interface de negócios necessária

Com o EJB 2.1 e anterior, cada EJB precisava fornecer uma classe de implementação Java e duas interfaces Java. O contêiner EJB criou instâncias da classe de implementação Java para fornecer a implementação EJB. As interfaces Java foram utilizadas pelo código do cliente do EJB.

Descritor de implantação necessário

Com o EJB 2.1 e anterior, a especificação EJB exigia a presença de um descritor de implantação. Isso era necessário para implementar um mecanismo que permitisse que os EJBs fossem implantados de maneira consistente, independentemente da plataforma EJB específica escolhida. As informações sobre como o bean deve ser implantado (como o nome da interface inicial ou remota, se e como armazenar o bean em um banco de dados, etc.) devem ser especificadas no descritor de implantação.

O descritor de implantação é um documento XML com uma entrada para cada EJB a ser implantado. Este documento XML especifica as seguintes informações para cada EJB:

• Nome da interface inicial
• Classe Java para o Bean (objeto de negócios)
• Interface Java para a interface inicial
• Interface Java para o objeto de negócios
• Armazenamento persistente (apenas para Entity Beans)
• Funções e permissões de segurança
• Stateful ou Stateless (para Session Beans)

Os contêineres EJB antigos de muitos fornecedores exigiam mais informações de implantação do que na especificação EJB. Eles exigiriam as informações adicionais como arquivos XML separados ou algum outro formato de arquivo de configuração. Um fornecedor de plataforma EJB geralmente fornecia suas próprias ferramentas que liam esse descritor de implantação e, possivelmente, geravam um conjunto de classes que implementariam as interfaces Home e Remota, agora obsoletas.

Desde o EJB 3.0 ( JSR 220 ), o descritor XML é substituído por anotações Java definidas na implementação do Enterprise Bean (no nível de origem), embora ainda seja possível usar um descritor XML em vez de (ou além) das anotações. Se um descritor XML e anotações forem aplicados ao mesmo atributo dentro de um Enterprise Bean, a definição XML substitui a anotação de nível de origem correspondente, embora alguns elementos XML também possam ser aditivos (por exemplo, uma propriedade de configuração de ativação em XML com um nome diferente do já definido por meio de uma anotação @ActivationConfigProperty será adicionado em vez de substituir todas as propriedades existentes).

Variações de contêineres

A partir do EJB 3.1, a especificação EJB define duas variantes do contêiner EJB; uma versão completa e uma versão limitada. A versão limitada segue um subconjunto apropriado da especificação chamado EJB 3.1 Lite e faz parte do perfil da web do Java EE 6 (que é um subconjunto da especificação completa do Java EE 6).

EJB 3.1 Lite exclui suporte para os seguintes recursos:

• Interfaces remotas
• Interoperabilidade RMI-IIOP
• Terminais de serviço da Web JAX-WS
• Serviço de cronômetro EJB (@Schedule, @Timeout)
• Invocações de bean de sessão assíncronas (@Asynchronous)
• Feijões acionados por mensagem

EJB 3.2 Lite exclui menos recursos. Particularmente, ele não exclui mais @Asynchronous e @ Schedule / @ Timeout, mas para @Schedule ele não suporta o atributo "persistente" que o EJB 3.2 completo suporta. A lista completa de excluídos para EJB 3.2 Lite é:

• Interfaces remotas
• Interoperabilidade RMI-IIOP
• Terminais de serviço da Web JAX-WS
• Cronômetros persistentes (atributo "persistente" em @Schedule)
• Feijões acionados por mensagem

Histórico de versão

EJB 4.0, versão final (2020-05-22)

Jakarta Enterprise Beans 4.0 , como parte do Jakarta EE 9, era uma versão de ferramentas que movia principalmente nomes de pacotes de API do pacote de nível superior javax.ejb para o jakarta.ejb pacote de nível superior .

Outras mudanças incluíram a remoção de APIs obsoletas que eram inúteis para mudar para o novo pacote de nível superior e a remoção de recursos que dependiam de recursos que foram removidos do Java ou de outro lugar em Jakarta EE 9. As seguintes APIs foram removidas:

• métodos baseados em java.security.Identity que foi removido do Java 14.
• métodos baseados em Jakarta XML RPC para refletir a remoção de XML RPC da plataforma Jakarta EE 9.
• EJBContext.getEnvironment() método obsoleto .
• "Suporte para interoperabilidade distribuída" para refletir a remoção do CORBA do Java 11 e da plataforma Jakarta EE 9.

Outras pequenas alterações incluem marcar o Enterprise Beans 2.x API Group como "Opcional" e tornar a Schedule anotação repetível.

EJB 3.2.6, versão final (23/08/2019)

Jakarta Enterprise Beans 3.2 , como parte do Jakarta EE 8, e apesar de ainda usar a abreviatura "EJB", este conjunto de APIs foi oficialmente renomeado para "Jakarta Enterprise Beans" pela Eclipse Foundation para não pisar no Oracle "Java " marca comercial.

EJB 3.2, versão final (28/05/2013)

JSR 345 . Enterprise JavaBeans 3.2 foi um lançamento relativamente menor que continha principalmente esclarecimentos de especificações e levantou algumas restrições que foram impostas pela especificação, mas com o tempo pareceu não servir a nenhum propósito real. Alguns recursos EJB completos existentes também deveriam estar no EJB 3 lite e a funcionalidade que foi proposta para ser removida no EJB 3.1 foi de fato removida (tornada opcional).

Os seguintes recursos foram adicionados:

• A passivação de um bean de sessão com estado pode ser desativada via atributo na anotação @Stateful (passivationCapable = false)
• TimerService pode recuperar todos os cronômetros ativos no mesmo módulo EJB (anteriormente só podia recuperar cronômetros para o bean em que o TimerService foi chamado)
• Os métodos de ciclo de vida (por exemplo, @PostConstruct) podem ser transacionais para beans de sessão com estado usando a anotação @TransactionAttribute existente
• Interface que pode ser fechada automaticamente implementada por um contêiner incorporável

EJB 3.1, versão final (10/12/2009)

JSR 318 . O objetivo da especificação Enterprise JavaBeans 3.1 é simplificar ainda mais a arquitetura EJB, reduzindo sua complexidade do ponto de vista do desenvolvedor, ao mesmo tempo que adiciona nova funcionalidade em resposta às necessidades da comunidade:

• Visualização local sem interface (visualização sem interface)
• embalagem .war de componentes EJB
• EJB Lite: definição de um subconjunto de EJB
• Nomes JNDI globais de EJB portáteis
• Singletons (feijões de sessão singleton)
• Eventos de inicialização e desligamento do aplicativo
• Melhorias no serviço de cronômetro EJB
• Assincronia Simples (@Asynchronous para beans de sessão)

EJB 3.0, versão final (11/05/2006)

JSR 220 - Principais mudanças : esta versão tornou muito mais fácil escrever EJBs, usando 'anotações' em vez dos complexos 'descritores de implantação' usados ​​na versão 2.x. O uso de interfaces iniciais e remotas e o arquivo ejb-jar.xml também não eram mais necessários nesta versão, tendo sido substituídos por uma interface de negócios e um bean que implementa a interface.

EJB 2.1, versão final (2003-11-24)

JSR 153 - Principais mudanças :

• Suporte a serviço da Web (novo): beans de sessão sem estado podem ser chamados por SOAP / HTTP . Além disso, um EJB pode acessar facilmente um serviço da Web usando a nova referência de serviço.
• Serviço de cronômetro de EJB (novo): mecanismo baseado em evento para invocar EJBs em horários específicos.
• Os beans controlados por mensagem aceitam mensagens de fontes diferentes de JMS .
• Destinos de mensagem (a mesma ideia que referências EJB, referências de recursos, etc.) foram adicionados.
• Adições de linguagem de consulta EJB (EJB-QL): ORDER BY, AVG, MIN, MAX, SUM, COUNT e MOD.
• O esquema XML é usado para especificar descritores de implantação, substitui DTDs

EJB 2.0, versão final (22/08/2001)

JSR 19 - Principais mudanças : Objetivos gerais :

• A arquitetura de componente padrão para construir aplicativos de negócios orientados a objetos distribuídos em Java .
• Torne possível construir aplicativos distribuídos combinando componentes desenvolvidos com ferramentas de diferentes fornecedores .
• Facilite a escrita de aplicativos (corporativos): os desenvolvedores de aplicativos não precisarão entender os detalhes de gerenciamento de estado e transação de baixo nível, multithreading, pool de conexão e outras APIs complexas de baixo nível.
• Seguirá a filosofia "Escreva uma vez, execute em qualquer lugar" do Java . Um enterprise Bean pode ser desenvolvido uma vez e, em seguida, implantado em várias plataformas sem recompilação ou modificação do código-fonte.
• Aborde os aspectos de desenvolvimento, implantação e tempo de execução do ciclo de vida de um aplicativo corporativo.
• Defina os contratos que permitem que ferramentas de vários fornecedores desenvolvam e implantem componentes que podem interoperar em tempo de execução.
• Ser compatível com as plataformas de servidor existentes. Os fornecedores poderão estender seus produtos existentes para oferecer suporte a EJBs.
• Seja compatível com outras APIs Java .
• Fornece interoperabilidade entre componentes enterprise Beans e Java EE, bem como aplicativos de linguagem de programação não Java.
• Ser compatível com os protocolos CORBA (RMI-IIOP).

EJB 1.1, versão final (17/12/1999)

Principais mudanças :

• Descritores de implantação XML
• Contextos JNDI padrão
• RMI sobre IIOP
• Segurança - orientada por função, não orientada por método
• Suporte para Entity Bean - obrigatório, não opcional

Metas para a versão 1.1:

• Fornece melhor suporte para montagem e implantação de aplicativos.
• Especifique com mais detalhes as responsabilidades das funções EJB individuais.

EJB 1.0 (24/03/1998)

Anunciado no JavaOne 1998 , a terceira conferência de desenvolvedores Java da Sun (24 a 27 de março) Objetivos para a versão 1.0:

• Definiu as "Funções EJB" distintas que são assumidas pela arquitetura do componente.
• Definiu a visão do cliente de enterprise Beans.
• Definiu a visão do desenvolvedor do enterprise Bean.
• Definiu as responsabilidades de um provedor de container EJB e provedor de servidor; Juntos, eles formam um sistema que suporta a implantação e execução de Beans corporativos.

Referências

links externos

• Website oficial
• Java EE 8 API Javadocs
• Javadocs da API EJB 3.0
• A Especificação EJB 3.0
• Tutorial EJB 3.0 da Sun
• Glossário EJB (3.0)
• EJB FAQ
• JSR 345 (EJB 3.2)
• JSR 318 (EJB 3.1)
• JSR 220 (EJB 3.0)
• JSR 153 (EJB 2.1)
• JSR 19 (EJB 2.0)
• "Working with Message-Driven Beans" de EJB3 em ação, segunda edição
• O cliente invoca um EJB