EJB - Enterprise Java Beans

EJB - Enterprise Java Beans

1. Arquitetura baseada em Componentes do lado do servidor(Server Side) que permite o desenvolvimento rápido e simplificado de aplicações transacionais, seguras e portáteis, baseadas na tecnologia Java. Seu objetivo é facilitar o trabalho do desenvolvedor para que ele não tenha de se preocupar com aspectos de infraestrutura.

2. Contém um container EJB que é implantado em um Servidor de Aplicação. É criado automaticamente quando o servidor é inicializado e oferece serviços,como: Gerenciamento do Ciclo de Vida, Segurança,Transações,Persistência,Estado.

3. São definidos em um Descritor de Implantação (Anotações XML). O descritor de Implantação do EJB 3.2 é o ejb-jar.xml

   • Em geral, anotações são usadas para gerar artefatos; outras para documentar o código; outras mapeiam classes Java para XML; outras mapeiam classes Java para bancos de dados; outras mapeiam métodos para operações; outras especificam dependências externas, entre outros.

4. Interoperabilidade com aplicações em outras linguagens (não Java)

5. Arquitetura EJB é neutra com relação aos seus protocolos, podendo ser utilizada com HTTP,IIOP,RMP,DOM,etc.

6. Os Componentes EJB podem ser acessados diretamente, no entanto ainda pode ser utilizadas as interfaces que são disponibilizadas para acesso remoto ou local

   • O Bean não implementa essas interfaces, cada fabricante de Servidores de Aplicação provê a implementação para as interfaces Remote e Home definidas para o componente - são respectivamente as interfaces EJB Object e EJB Home.
   • Interface EJBObject
     • Implementa a interface para acessos remotos e locais, e funciona como um wrapper, i.e., encapsulando a instância EJB solicitada pelo cliente.
   • Interface EJBHome
     • Faz exatamente a mesma coisa, no entanto ela também é responsável por auxiliar o contêiner a gerenciar o ciclo de vida de um Bean – realizando criações, buscas e remoções de objetos.

7. Existem 3 tipos de EJB: Entity Bean, Message-Driven Beans e Session Beans

   • Entity Bean: representa um objeto persistente que pode ser compartilhado por clientes. A persistência pode ser gerenciada pelo container ou pelo bean. Opcional a partir do EJB 3.2. Substituído pela JPA
     • Java Persistence API (ou simplesmente JPA) é uma API padrão da linguagem Java que descreve uma interface comum para frameworks de persistência de dados. A JPA define um meio de mapeamento objeto-relacional para objetos Java simples e comuns (POJOs), denominados beans de entidade. POJO - Objeto java plano ou regular (desenho simplificado) não segue modelos,convenções ou frameworks e não estende classes ou implementa interfaces. Um exemplo de POJO é o Java Beans, que é uma classe onde seu construtor não recebe parâmetros e os seus métodos são os getters e setters para acessar as variáveis de instância.
   • Message-driven Beans (MDB): trata-se de um objeto não-persistente que combina características de um Session Bean e uma escuta/monitor (listener) de mensagens, permitindo a um componente de negócio receber e tratar mensagens de forma assíncrona – geralmente, providas pelo JMS. Pode-se dizer que eles são executados após o recebimento de uma única mensagem do cliente. São stateless.
     • Java Message Service, ou JMS, é uma API da linguagem Java para middleware orientado à mensagens. Através da API JMS duas ou mais aplicações podem se comunicar por mensagens. Um Contêiner EJB provê um ambiente de execução escalável para executar um grande número de MDBs concorrentemente. Eles podem ser Stateless, apenas. Ademais, devem ser invocados por meio de programação por um cliente local ou remoto. Como são não-persistentes, o cliente não acessa um MDB diretamente, mas por meio do JMS enviando mensagens para o destinatário.
   • Session Beans (SB): trata-se de um objeto não-persistente que implementa alguma lógica de negócio ou fluxo de trabalho no servidor. Eles servem para executar alguma tarefa em nome de um único cliente e implementam a interface javax.ejb.SessionBean, podendo implementar Web Services. O Contêiner EJB provê um ambiente escalável para executar um grande número de SBs concorrentemente.
     • Um Session Bean encapsula a lógica de negócio que pode ser invocada programaticamente por um cliente localmente, remotamente ou por meio de webservices. Os SBs permitem enviar e receber mensagens JMS, porém somente de forma síncrona. Na versão 3.1 foi adicionado a invocação assíncrona de Beans de Sessão.
     • Seus dados não são persistidos em uma base de dados e eles podem ser de três tipos: stateful, stateless e singleton!
       • Stateless Session Beans: são objetos de negócio que não mantém estado entre invocações de métodos. Após cada chamada de método, o contêiner pode escolher destruir, recriar ou manter o Bean. Eles podem ter variáveis de instância armazenadas em um pool, no entanto elas serão compartilhadas por vários usuários (entretanto, não de forma concorrente).
         • Observem o ciclo de vida mostrado abaixo e percebam que ele tem dois estados: no estágio Does Not Exist, a instância simplesmente ainda não existe;  No estágio Ready, diversas instâncias podem ser criadas e posicionadas em um pool – prints para serem utilizadas. Percebam que ela nunca entra em modo passivo para economizar recursos.
       • Stateful Session Beans: são objetos de negócio que mantém estado entre chamadas de métodos. São projetados, em geral, para situações que requerem várias requisições simultâneas ou transações. Aqui as variáveis de instância representam o estado de uma sessão. Decorem isso: são objetos que mantém o estado entre as chamadas de métodos.
         • Observem o ciclo de vida mostrado acima e percebam que ele tem três estados:   No estágio Does Not Exist, a instância simplesmente ainda não existe; no estágio Ready, a instância está vinculada a um determinado cliente e ocupada em uma conversação; no estágio Passive, a instância sai da memória principal para amemória secundária para economizar recursos.
       • Singleton:são objetos de negócio instanciados uma única vez pela aplicação e existem por todo ciclo de vida da aplicação. São utilizados quando um Enterprise Bean é compartilhado e acesso por vários clientes. Percebam que ele também nunca entra em modo passivo para economizar recursos – assim como os Stateless Session Beans.
         • Observem o ciclo de vida mostrado acima e percebam que ele tem apenas dois estados: no estágio Does Not Exist, a instância simplesmente ainda não existe; já no estágio Ready uma única instância é criada e estará pronta para ter seus métodos de negócio invocados pelos clientes. Trata-se de um ciclo de vida bastante simples, concordam?

Imágenes y archivos del mapa