INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DA PARAÍBA

Campus Monteiro

Apostila

Enterprise Java Beans - EJB:

uma visão geral

Professor: João Paulo Lopes de Souza

JOÃO PESSOA

2019
SUMÁRIO
Introdução 3

1.1 Limitação de aplicações web 3

1.2 Aplicações corporativas 3

1.2.1 Definição 3

1.2.2 Exemplos de aplicações corporativas 4

1.3 Java EE 5

1.3.1 Definição 5

1.3.2 Containers 6

1.3.4 Histórico 6

2.EJB 7

2.1 O que é EJB? 7

2.2 Principais características 7

2.3 Histórico das mudanças 8

2.4 Modelo de desenvolvimento simplificado 8

2.5 Modelo de computação distribuído 9

2.6 Session Beans (stateless, stateful e singleton) 9

2.6.1 Interface de Negocio – Local e Remota 10

2.6.2 Métodos assíncronos 10

2.6.3 Stateless Session Beans 10

2.6.3.1 Ciclo de vida 11

2.6.3.2 Exemplo de stateless 12

2.6.4 Stateful Session Beans 13

2.6.4.1 Ciclo de vida 13

2.6.4.2 Exemplo 14

2.6.5 Singleton Session Beans 15

2.6.5.1 Ciclo de vida 16

2.6.5.2 Exemplo 16

2.7 Message-Driven Beans – MDBs 17

2.7.1 Ciclo de vida 20

1
 2.7.2 Exemplo 20

2.8 EJB e Persistência 23

2.8.1 Exemplo 23

2.9 EJB, Web Services e Micro Serviços 26

3. Exemplo de um sistema integrado 30

4. Panorama atual do Java EE e EJB 31

Referências 33

2
1. Introdução

1.1 Limitação de aplicações web

Johnson (2004) expõe algumas limitações das aplicações web convencionais, figura abaixo, que foram
estudadas até agora:

● Não existe uma separação clara com a camada de negócio;

● Falta de um ambiente padronizado para gerenciar os objetos de negócio;
● Falta de uma solução pronta para gerenciamento transações declarativa;

Além dessas limitações, podemos incluir também a falta de suporte para desenvolvimento baseado em
componentes distribuídos, de tal forma que permitisse escalar determinados componentes de negócio que
estão mais sobrecarregados.

Figura 01 - aplicação web convencional

Fonte: WETHERBEE (2018)

1.2 Aplicações corporativas

1.2.1 Definição
Fowler (2007) informa as características das aplicações corporativas: grande quantidade de dados
persistente, muitos usuários acessam esses sistemas concorrentemente, existem muitas interfaces de
usuários diferentes, frequentemente existe integração com outras aplicações corporativas, os mesmos
dados podem ter diferentes significados para diferentes atores, lógica de negócio complexa.

Já o glossário do Gartner define que eles são projetados para integrar sistemas que executam todas as
fases das operações de uma companhia, facilitando a cooperação e coordenação do trabalho através da
empresa. O objetivo é integrar os processos principais (exemplo vendas, contabilidade, finanças, recursos
humanos, estoque e manufatura). Esses sistemas estão expandindo seu escopo para integrar fornecedores,
parceiros de negócio e consumidores.

3
Segundo Devmedia (2012), grandes empresas possuem sistemas corporativos integrando setores,
melhorando a produtividade, otimizando processos e agregando valores nas mais variadas áreas de
atuação. Tais sistemas são desenvolvidos levando em consideração a segurança, a grande quantidade de
acessos simultâneos, a integridade das informações, a estabilidade, entre outros aspectos.

Para Oracle (2017b), aplicações corporativas fornecem a lógica de negócio para uma organização. Elas são
gerenciadas de forma centralizadas e frequentemente interagem com outras aplicações da empresa.

1.2.2 Exemplos de aplicações corporativas

Fowler (2004,2007), Watts (2017) e Gartner fornecem alguns exemplos de aplicações que podem ser
definidas como corporativas:

● Folha de pagamento;
● Registros de pacientes;
● Lojas de varejo na internet - e-commerce;
● Rastreamento de remessas;
● Classificação de risco de crédito;
● Seguro;
● Contabilidade;
● Negociação de câmbio e ações;
● Sistemas financeiros - bancos;
● Reservas de viagens ou de quartos de um hotel;
● Processamento de pedidos;
● Aquisições;
● Gerenciamento de energia;
● Gerenciamento de relacionamento com o cliente - CRM;
● Enterprise Resource Planning - ERP;
● Gerenciamento de relacionamento com os fornecedores - SCM;

Figura 02 - Exemplos de aplicações corporativas

Fonte: FOWLER (2004)

Eles também fornecem uma lista do que não pode ser enquadrado como aplicações corporativas:

4
 ● Software de injeção de combustível;
● Processadores de texto;
● Controladores de elevadores;
● Sistemas operacionais;
● Compiladores;
● Jogos;

1.3 Java EE

1.3.1 Definição
É uma plataforma projetada para ajudar os desenvolvedores a construírem aplicações corporativas
(ORACLE, 2017a). Ela reduz a complexidade do desenvolvimento dessas aplicações provendo um modelo
de desenvolvimento, API, e um ambiente de execução que permite aos desenvolvedores se concentrarem
nas funcionalidades.

Segundo Oracle (2017b), Java EE é uma plataforma que fornece aos desenvolvedores um poderoso
conjunto de APIs que ajudam a reduzir o tempo de desenvolvimento, a complexidade das aplicações,
enquanto melhoram o seu desempenho. Ela usa um modelo de programação simplificado, no qual os
desenvolvedores podem simplesmente incluir uma anotação no código fonte que o servidor irá configurar o
componente em tempo de deployment e execução. Java EE usa fortemente o conceito de injeção de
dependência que permite inserir referências para outros componentes e recursos usando anotações. Essa
injeção pode ser usada nos containers EJB, Web e Cliente. A plataforma Java EE usa um modelo de
aplicações multicamadas distribuído, conforme figura abaixo.

Figura 03 - modelo de aplicações multicamadas Java EE

Fonte: ORACLE (2017b)

Ainda segundo Oracle (2017b), as aplicações Java EE são compostas dos seguintes componentes:

● Aplicações clientes e applets executam no cliente;

● Os componentes web que executam no servidor são: Java Servlet, JavaServer Faces, and
JavaServer Pages (JSP);

5
 ● Os componentes de negócio que executam no servidor são os EJB (Enterprise Jav Beans).

1.3.2 Containers
Containers são a interface entre um componente e as funcionalidades ou serviços de baixo nível que
fornece suporte para esses componentes.

Os tipos de container do Java EE são (ORACLE, 2017b):

● Container EJB: gerencia a execução dos Enterprise Java Beans;

● Container Web: gerencia a execução de páginas Web, Servlets e componentes JSP e JSF;
● Container Application client: gerencia a execução de componentes da aplicação cliente;
● Container Applet: gerencia a execução de applets.

Figura 04 - containers Java EE

Fonte: ORACLE (2017b)

Os containers fornecem serviços para os componentes que eles hospedam, como exemplo: segurança,
agendamento de execução (timer), injeção de dependência, interceptadores, gerenciamento de transações,
serviço de localização - JNDI, conectividade remota, gerenciamento de recursos - Pool, gerenciamento de
ciclo de vida, e-mail, mensagens.

1.3.4 Histórico
Oracle (2017b) informa que a última versão é Java EE 8. Suas metas são modernizar a infraestrutura para
Java corporativo nos ambientes de nuvem e microserviços, com ênfase no suporte ao HTML5 e HTTP/2,
realçando a facilidade de desenvolvimento através da injeção de dependências e melhoria na segurança e
confiabilidade.

6
2.EJB

2.1 O que é EJB?

Para Rubinger e Burke (2010) EJB é mais que um conjunto de APIs, é um modelo de programação
simplificado que transforma classes Java em poderosos componentes com a lógica de negócio.

Essa definição é complementada por Oracle (2013), o qual informa que EJB é uma arquitetura para
aplicações corporativas transacionais e baseadas em componentes.

Para Devmedia (2012), EJB é um dos principais componentes da plataforma Java Enterprise Edition (Java
EE) para desenvolvimento de sistemas corporativos. Com ele é possível criar aplicações modulares,
separar suas funcionalidades e as reutilizar de forma simples e objetiva. Ao utilizar EJB é possível construir
aplicações distribuídas, seguras e com um eficaz tratamento de transações. Além disso, o EJB oferece
serviços de persistência de dados, controle de concorrência, envio de mensagens, serviço de agendamento,
chamadas a métodos remotos e a web services.

2.2 Principais características

EJB tipicamente contém a lógica de negócio que opera sobre os dados da organização e uma instância é
gerenciado pelo Container EJB.

Segundo Wetherbee (2018) e Oracle (2013), são algumas características chave dos EJB:

● Metadados declarativos - habilidade do desenvolvedor especificar o comportamento de

um componente de forma declarativa usando anotações e/ou descritores XML. No caso de
conflito o XML tem precedência;
● Configuração por exceção - muitos comportamentos são incluídos automaticamente no
EJB sem sua declaração explícita. Por exemplo, o comportamento transacional dos
métodos dos session beans. Uma anotação ou seu similar no XML precisam ser
especificados explicitamente somente quando o comportamento não padrão é desejado.
Outro exemplo é o mapeamento feito nas entidades para suas respectivas tabelas;
● Escalabilidade - aplicações de larga-escala exigem a habilidade de escalar bem quando a
carga de clientes aumenta. O servidor EJB emprega o pool de recursos para maximizar o
reuso de recursos, utiliza o cache de persistência para evitar a repetição de consultas e a
criação dos mesmos objetos, implementa uma estratégia de lock otimista para reduzir a
carga no banco e evitar problemas de concorrência como bloqueios. Ele também gerencia o
ciclo de vida dos EJBs, permitindo a liberação de recursos dependentes não necessários;
● Transparência de localização - EJBs podem ser configurados para acesso remoto,
permitindo o acesso através da rede de forma transparente;
● Transação - A JTA é uma API padrão para transações distribuídas e o container EJB atua
como um gerenciador de transações JTA para os EJBs;
● Segurança multiusuário - controle de acesso a nível de método pode ser especificado
declarativamente nos EJBs, impondo uma definição de privilégios a nível de papel/usuário
pelos administradores do servidor de aplicação;
● Portabilidade - atualmente os componentes EJBs podem ser implantados em qualquer
servidor de aplicação que implementa a especificação EJB. Isso nem sempre foi verdade no
passado uma vez que cada fabricante criava seus próprios metadados;
● Reusabilidade - EJBs são componentes com baixo acoplamento e podem ser reusado e
empacotado em diversas aplicações;

7
 ● Persistência - embora não seja mais coberta pela especificação EJB, entidades JPA são
um complemento essencial aos EJBs. Uma classe de entidade representa um mapeamento
para uma tabela de banco. Cada instância dessa classe é uma linha da tabela;

2.3 Histórico das mudanças

Wetherbee (2018) informa que a especificação EJB nasceu em 1996 e teve sua primeira
implementação comercial em 1998. Em seguida mostra o histórico de mudanças na especificação:

● EJB 1.0 - release inicial - ofereceu suporte aos bens de sessão, stateless e stateful, e
opcionalmente aos entity beans, que eram objetos de domínio persistentes. A interface
remota apresentava um grande overhead na infraestrutura de comunicação remota e
problemas na semântica de passagem por valor;
● EJB 1.1 - o suporte aos beans de entidade se tornou obrigatório e foi introduzido o
deployment descriptor em XML para substituir o armazenamento de metadados em
arquivos de classe serializados especiais;
● EJB 2.0 - enfrentou o overhead e os problemas na semântica de passagem por valor da
interface remota, introduzindo uma interface local. Somente clientes executando dentro do
mesmo container Java EE poderiam ter acesso a um EJB através da interface local, mas foi
permitido a chamada de métodos com passagem por referência para troca de informações
mais eficientes entre componentes. Foi introduzido um novo tipo de EJB, os
Message-driven beans - MDBs, que poderiam participar de sistemas de mensagem
assíncronas. Também foi incluído a Enterprise JavaBeans Query Language (EJB QL), a
qual permitia ao desenvolvedor realizar consultas em linguagem similar ao SQL. E os Entity
Beans agora podem ter os relacionamentos de persistência gerenciados pelo container
EJB;
● EJB 2.1 - adicionou suporte a Web services, permitindo aos beans de sessão expor suas
interfaces como serviço. Foi criado o serviço de timer, que permite a execução agendada
dos EJBs. Também foram expandidas as funções EJB QL;
● EJB 3.0 - foi a maior evolução do padrão. Componentes EJB se tornam POJOs (plain old
Java objects), ou seja, uma classe comum. Não é mais exigido que uma classe bean EJB
implemente interfaces específicas e as propriedades que fazem de uma classe Java um
EJB podem ser configuradas em anotações ou externamente no arquivo descritor XML
ejb-jar.xml. A parte da especificação que tratava dos beans de entidade foi substituída pela
especificação JPA, simplificando o modelo;
● EJB 3.1 - EJBs locais agora suportam a opção sem interface. O suporte a timer foi
melhorado. E foi introduzido suporte a comunicação assíncrona nos beans de sessão, bem
como foi criado um novo tipo de sessão, o Singleton. Foi criado também um subconjunto
das funcionalidades do container EJB, o EJB Lite, que permite aos componentes EJB serem
executados na mesma JVM como um EJB cliente;
● EJB 3.2 - 2013 - funcionalidades de comunicação assíncrona e as melhorias de timer foram
adicionadas ao subconjunto EJB Lite. Foi melhorado o comportamento transacional do ciclo
de vida dos métodos interceptadores, bem como foram simplificadas as regras que
governam a declaração dos comportamentos local e remoto. Uma opção para desabilitar a
passivação do bean de sessão stateful foi melhorada.

2.4 Modelo de desenvolvimento simplificado

Segundo Wetherbee (2018), os arquitetos de EJB 3 fizeram um redesenho da experiência de
desenvolvimento para introduzir um modelo de desenvolvimento simplificado e reduzir a complexidade dos
EJBs.

8
 ● XML e Anotações – os EJBs agora permitem que os metadados sejam definidos tanto dentro dos
arquivos fontes usando anotações java como usando o tradicional deployment descriptor XML.
Caso haja necessidade de desacoplar os metadados do arquivo java, recomenda-se usar a
segunda estratégia, permitindo que a mesma entidade ou classe enterprise bean seja usada em
diferentes contextos, onde a informação específica de contexto será capturada no XML;

● Injeção de dependência – EJB 3 introduziu o uso de injeção de dependência em Java. Com ela, o
container EJB fica responsável por inicializar as propriedades de uma instância de objeto e em
seguida a disponibiliza para o EJB. Essa funcionalidade agora tem sua própria especificação,
JSR-330: Dependency Injection for Java TM e estendida pela through JSR 346: Contexts and
Dependency Injection for Java TM EE 1.1. Casos típicos de uso de injeção de dependência em Java
incluem: injeção do EntityManager em um session bean para interação com a unidade de
persistência e injeção do UserTransaction para demarcação de transações em um session bean;

● Interceptadores: métodos de callback – são métodos que são chamados quando certos eventos
do ciclo de vida ocorrem. Eles podem ser métodos de entidades ou enterprise beans ou de outras
classes. Eles permitem que desenvolvedores participem programaticamente da interação entre os
beans ou entidades e seus containers;
● Implementação POJO​ – métodos Home não são mais obrigatórios, embora eles ainda sejam
suportados. Para beans de sessão e MDBs, um construtor padrão substitui o método ejbCreate(),
que era exigido nas versões anteriores. Para entidades, a interface Home foi substituída por uma
instância EntityManagerFactory que produz instâncias EntityManager para a unidade de
persistência.
● Uso inteligente de convenções – o comportamento convencionado provê funcionalidades ricas
sem a necessidade de nenhuma codificação ou declaração de metadados. Um exemplo é anotar
uma classe POJO com ​@Entity realiza o mapeamento de todas as propriedades públicas em
campos persistentes e os nomes da tabela e dos campos são derivados dos nomes da entidade e
de seus campos. Uma consequência de utilizar essa convenção é que a classe não irá descrever
todo o comportamento, exigindo um bom conhecimento do comportamento convencionado que está
sendo aplicado;

2.5 Modelo de computação distribuído

Segundo Wetherbee (2018), é essencial para qualquer aplicação corporativa a habilidade de executar
tarefas e componentes em threads ou processos separados. Através de serviços remotos baseados em
RMI, clientes na camada de aplicação cliente podem acessar EJBs que estão executando em um servidor
de aplicação em qualquer lugar da rede.

O comportamento da passagem por valor dos métodos de interface remota fornecem um modelo projetado
para reduzir o tráfego de rede entre cliente e servidor que são fracamente acoplados.

2.6 Session Beans (stateless, stateful e singleton)

Para Wetherbee (2018), os session beans são a parte mais importante da tecnologia EJB porque eles
modelam o processo de negócio e encapsulam a sua lógica. Eles são componentes Java que executam
tanto em um container EJB stand-alone como em um container que faz parte do servidor de aplicação Java
EE. Eles podem ser Stateless, Stateful e Singleton.

Na visão do autor, devem ser usados quando se necessita escrever a lógica de negócio, manter o estado da
interação com o cliente, modelar processos de back-end ou tarefas do usuário que realizam uma ou mais
operações do negócio.

9
2.6.1 Interface de Negocio – Local e Remota
A interface de negócio é uma interface Java convencional. Essa interface irá listar todas as definições dos
métodos de negócio que estarão disponíveis para as aplicações clientes (WETHERBEE, 2018).
A anotação ​@Remote é usada para definir a interface remota, na qual a aplicação cliente está em uma JVM
diferente do componente EJB. JVMs separadas podem está na mesma máquina física ou em separadas.
Se nenhuma anotação é definida na interface, então todos os métodos públicos presentes na classe do
bean de sessão serão a interface local. É possível que a arquitetura da aplicação exija tanto a interface local
quanto a remota.
Por exemplo, uma organização tem uma aplicação para processamento de pedidos desenvolvida usando
beans de sessão que tem métodos para incluir um novo pedido e também para realizar tarefas
administrativas, como incluir os dados dos produtos. Nesse caso, existem duas aplicações clientes
diferentes. Uma aplicação web cliente que executa na mesma JVM e permite adicionar novos pedidos. E
uma outra aplicação cliente desktop que executa na máquina do usuário e é usada para tarefas
administrativas.

2.6.2 Métodos assíncronos

Session beans podem ter alguns de seus métodos, a partir do EJB 3.1, que permitem execução assíncrona.
Quando um método é invocado de forma assíncrona, ele retorna o controle para o cliente imediatamente.
Esse tipo de método é usado normalmente para tarefas que tenham intenso processamento ou cuja
execução seja demorada.

Para configurar um método como assíncrono utiliza-se a anotação ​@Asynchronous​. Ele pode ou retornar
Void ou a implementação da interface ​java.lang.concurrent.Future.​ Essa interface permite as seguintes
operações:

● recuperar o resultado final usando o método ​get();​

● verificar o status do método usando o método ​isDone();​
● cancelar a invocação do método usando ​cancel(boolean);​
● verificar se o método foi cancelado usando ​isCancelled().​

2.6.3 Stateless Session Beans

Tipo de bean que não mantém qualquer estado de conversação com a aplicação cliente. Esse estado de
conversação ou interação é a informação que é trocada e relembrada no contexto de uma série de
requisições entre um cliente e o EJB. A partir da versão 3.1 do EJB uma classe bean de sessão pode ser
uma subclasse de outra do mesmo tipo (WETHERBEE, 2018).
Para Rubinger e Burke (2010), uma classe de um bean stateless é uma classe Java padrão que recebe uma
anotação a nível de classe ​@Stateless.​ Essa definição também pode ocorrer no descritor XML ​ejb-jar.xml
ou ainda das duas formas ao mesmo tempo, e nesse último caso, a definição do XML irá prevalecer.
Os autores ainda definem que esse tipo de bean são uma resposta EJB para aplicações que processam
transações tradicionais e são executadas usando chamada de procedimento. Esse procedimento executa
do início ao fim e retorna um resultado. Uma vez que o procedimento foi completamente executado, nada
sobre os dados manipulados ou detalhes das requisições estarão disponíveis. E nesse momento, a
instância do session bean pode ser reusada para atender uma outra requisição.

10
 Figura 05 – invocação de beans de sessão
Fonte: RUBINGER, BURKE (2010)

Não manter estado da interação não significa que o bean não possa ter variáveis de instância ou manter
algum tipo de estado interno. É importante pontuar que um cliente de um stateless não pode assumir que a
mesma instância irá atender todas as suas requisições.
Para Oracle (2017b), stateless session beans podem oferecer uma melhor escalabilidade para aplicações
que precisam atender um grande número de clientes quando o estado do bean não tiver dados específicos
de um cliente e ele realizar uma tarefa genérica para todos os clientes. E também esse tipo de bean de
sessão pode implementar um web service, enquanto que o stateful não pode.

2.6.3.1 Ciclo de vida

Stateless só tem dois estágios: Não existe ou método-pronto.
Um container tipicamente cria e mantém um pool de stateless, iniciando o seu ciclo de vida. O container
realiza qualquer injeção de dependência e chama os métodos anotados com ​@PostConstruct se existir.
Nesse ponto eles estarão prontos para atender as requisições dos clientes. E para encerrar o ciclo, o
container chama o método anotado como ​@PreDestroy​ se existir.

Figura 06 - ciclo de vida do stateless

Fonte: RUBINGER, BURKE (2010)

11
2.6.3.2 Exemplo de stateless
Pala ilustrar o uso de um stateless session bean segue um exemplo do bean SearchFacadeBean que provê
funcionalidades para pesquisar os vinhos disponíveis em uma loja. Os usuários irão escolher alguns
critérios de pesquisa e irão submeter essa pesquisa ao bean. Na sequência, o bean irá pesquisar no banco
de dados. Para facilitar o entendimento, a lista dos vinhos foi inserida de forma estática​.
import java.util.ArrayList;
import java.util.HashMap;
import java.util.List;
import javax.annotation.PostConstruct;
import javax.annotation.PreDestroy;
import javax.ejb.Stateless;

@Stateless(name = "SearchFacade")
public class SearchFacadeBean
{
public SearchFacadeBean() {
}

HashMap countryMap = new HashMap();

public List wineSearch(String wineType) {

List wineList = new ArrayList();
if (wineType.equals("Red")) {
wineList.add("Bordeaux");
wineList.add("Merlot");
wineList.add("Pinot Noir");
}
else if (wineType.equals("White")) {
wineList.add("Chardonnay");
}

return wineList;
}

@PostConstruct
public void initializeCountryWineList() {
//countryMap is HashMap

countryMap.put("Australia", "Sauvignon Blanc");

countryMap.put("Australia", "Grenache");
countryMap.put("France", "Gewurztraminer");
countryMap.put("France", "Bordeaux");
}

12
@PreDestroy
public void destroyWineList() {
countryMap.clear();
}
}
Listagem 1 – Exemplo de um Stateless

2.6.4 Stateful Session Beans

De acordo com Rubinger (2010), o bean stateful mantém estado da interação com o cliente. Isso quer dizer
que as variáveis de instância podem manter dados específicos de um cliente entre requisições. Uma
instância fica associada às requisições de um determinado cliente durante toda a sessão, conforme figura
abaixo.
Uma classe stateful session bean é uma classe Java convencional com a anotação ​@Stateful​. Stateful não
usa um pool de instâncias.

Figura 07 - relacionamento do cliente com o container EJB e o Stateful

Fonte: RUBINGER, BURKE (2010)

Rubinger (2010) informa que embora esse tipo de bean de sessão mantenha estado, ele em si não é
persistente. O estado é perdido quando a sessão é removida, ocorre um ​time out​ ou o servidor é reiniciado.
Esse bean permite encapsular alguma lógica de negócio e o estado da interação do cliente e transporta isso
para o servidor. Movendo a lógica para o servidor é possível criar clientes mais simples e deixa o sistema
como um todo mais fácil de gerenciar e manter. O stateful session bean age como um agente para o cliente,
gerenciando processos ou fluxos de tarefas que podem ser compostos por um conjunto de tarefas.

2.6.4.1 Ciclo de vida

Segundo Rubinger (2010), um detalhe que difere esse bean do anterior é quando ele está inativo por um
certo tempo, a instância é simplesmente removida da memória. O EJB permanece conectado ao cliente,
mas a instância do bean perde a referência e é coletada pelo garbage collector durante esses períodos. Isso
significa que cada stateful deve ser passivado antes de ser removido para preservar o estado de
conversação da instância, e deve ser ativado para restaurar esse estado quando o bean se tornar ativo
novamente.
O seu ciclo de vida é composto por três estados, conforme figura abaixo: não existe, método pronto e
passivado.

13
 Figura 08 - Ciclo de vida convencional do StatefulFonte: RUBINGER, BURKE (2010)

No primeiro estado, não existe, o bean ainda não foi instanciado. Ele não existe na memória do sistema.
Quando o cliente chama o primeiro método na referência do stateful, o ciclo de vida começa. O container
invoca newInstance() na classe e cria uma nova instância. Em seguida, o container injeta qualquer
dependência na instância. Nesse ponto, a instância do bean é atribuída para o cliente. Por fim, são
chamados os métodos de ​calllback ​@PostConstruct se existir. O bean atinge o segundo estado,
método-pronto.
A instância do bean deixa o estado anterior para o estado passivado ou de volta para o primeiro.
Dependendo de como o cliente usa o stateful, da carga no container EJB e do algoritmo de passivação
usado, a instância do bean pode ser passivada e ativada muitas vezes durante sua vida ou nenhuma vez. O
cliente pode remover o bean acionando o método com ​@Remove​. A transição para o estado não existe
também pode acontecer quando ocorre um ​time out​.
Durante períodos de inatividade para conservar recursos o container pode passivar a instância preservando
o estado de interação e retirando a instância da memória. Quando o bean está para ser passivado, o
container chama o método de ​callback ​@PrePassivate​. Containers podem usar o padrão de serialização
Java ou outro mecanismo para armazenar o estado. Alguns fornecedores, por exemplo, armazenam os
campos em um cache. Após a passivação, quando a instância é ativada com sucesso, é chamado o método
de ​callback​ ​@PostActivate​.

2.6.4.2 Exemplo
Como exemplo do Stataful temos o bean ShoppingCartBean que irá manter todos os itens e suas
quantidades adicionados pelo usuário ao seu carrinho de compras. Para facilitar o entendimento, nesse
ponto, usaremos uma lista de itens estática.
import java.util.ArrayList;
import javax.annotation.PostConstruct;
import javax.annotation.PreDestroy;
import javax.ejb.Remove;
import javax.ejb.Stateful;

@Stateful(name = "ShoppingCart")
public class ShoppingCartBean
{
public ArrayList cartItems;

public ShoppingCartBean() {

14
}

public void addWineItem(String wine) {

cartItems.add(wine);
}

public void removeWineItem(String wine) {

cartItems.remove(wine);
}

@PostConstruct
public void initialize() {
cartItems = new ArrayList();
}

@PreDestroy
public void exit() {
System.out.println("Saved items list into database");
}

@Remove
public void stopSession() {
// The method body can be empty.
System.out.println("From stopSession method with @Remove annotation");
}
public void setCartItems(ArrayList cartItems) {
this.cartItems = cartItems;
}

public ArrayList getCartItems() {

return cartItems;
}
}
Listagem 2 – Exemplo Stateful

2.6.5 Singleton Session Beans

Tipo de bean que é instanciado somente uma vez por aplicação. Eles existem durante todo o tempo da
aplicação e mantém seu estado entre interações com o cliente, porém não pode armazenar esse estado
após desligamento ou falha do servidor.
O singleton bean foi introduzido na versão 3.1 do EJB. Esse bean é uma classe Java convencional com
uma anotação ​@Singleton.​ O singleton pode ser inicializado quando for chamado pela primeira vez ou no
momento da implantação(deployment) no container quando usada a anotação ​@Startup.​
Segundo Rubinger (2010), o singleton tem um modelo conceitual mais simples que os beans de sessão
anteriores, conforme figura abaixo.

15
 Figura 09 - modelo conceitual do singleton
Fonte: RUBINGER, BURKE (2010)

O autor alerta ainda que um ponto muito importante, e que diferencia esse tipo de bean de sessão dos dois
anteriores, é a concorrência. Como o estado de uma única instância é compartilhado por diversas
requisições concorrentes, a utilização responsável de estratégias de lock e controle de concorrência são
primordiais.
Para Wetherbee (2018), quando uma aplicação utiliza múltiplos singleton session beans, pode ser
necessário definir a ordem de inicialização pelo container. Isso é feito usando a anotação ​@DependsOn e
informando o bean que o atual depende. Na seção abaixo de exemplo, mostramos uma amostra desse tipo
de requisito em ação, é o bean LogShopperCount que necessita da inicialização anterior do bean
ShopperCount.

2.6.5.1 Ciclo de vida

O ciclo de vida do singleton é igual ao ciclo do stateless.

2.6.5.2 Exemplo
Como exemplo foi criado o bean singleton ShopperCount que irá armazenar o número de clientes logados
na loja.
import javax.annotation.PostConstruct;
import javax.annotation.PreDestroy;
import javax.ejb.Singleton;
import javax.ejb.Startup;

@Singleton (name = "ShopperCount")

@Startup
public class ShopperCountBean {
private int shopperCounter;

// Increment number of shopper counter

public void incrementShopperCount() {
shopperCounter++;
}

// Return number of shoppers

public int getShopperCount() {
return shopperCounter;
}

16
 // Reset counter
public void resetCounter() {
shopperCounter = 0;
}

// Reset counter
@PostConstruct
public void applicationStartup() {
System.out.println("From applicationStartup method.");
resetCounter();
}

@PreDestroy
public void applicationShutdown() {
System.out.println("From applicationShutdown method.");
}
}
Listagem 3 - exemplo de singleton session bean

@Singleton
@Startup
@DependsOn("ShopperCount")
public class LogShopperCount {
private final Logger log = Logger.getLogger("LogShopperCount.class");
public void logShopperCount() {
// Log shopper count
}
}
Listagem 4 - exemplo de um singleton que especifica a ordem de inicialização

2.7 Message-Driven Beans – MDBs

Segundo Wetherbee (2018), esse tipo de bean utiliza uma arquitetura orientada a mensagens. Sistemas de
mensagens são uma das soluções mais viáveis para integração de novas aplicações com sistemas
existentes usando um modelo transacional fracamente acoplado e com comunicação assíncrona.
Alguns conceitos de mensagens usadas pelos MDBs:
● processo de envio de mensagem assíncrona;
● a parte que envia não sabe quando a mensagem é recebida;
● a parte que envia pode garantir que a mensagem não será perdida no caminho.
Para entender esse tipo de bean é preciso conhecer que JMS é uma API de middleware orientado a
mensagens - MOM do Java. Ela permite enviar e receber mensagens assincronamente. JMS é parte do
padrão Java EE. Wetherbee (2018) ​detalha que MOM armazena mensagens em uma localização
especificada pela parte que envia e mais tarde será coletada por um consumidor.

17
A arquitetura JMS consiste nos seguintes componentes:
● Provedor JMS - sistema de mensagem que trata do encaminhamento e entrega das mensagens.
Pode ser um componente de mensagem de um servidor de aplicação (JBOSS, Oracle WebLogic,
IBM Websphere, etc);
● Cliente JMS - aplicação Java ou componente Java EE que usa JMS para consumir ou produzir uma
mensagem;
● Consumidor JMS - aplicação cliente JMS que consome mensagens. Na figura abaixo é Inventory,
Billing e Shipping;
● Produtor JMS - Cliente JMS que gera a mensagem. No exemplo da figura abaixo é Order Entry ou
Inventory;
● Mensagem JMS - consiste em cabeçalho, propriedades e corpo. O cabeçalho identifica a
mensagem e contém informações padrão, por exemplo, o momento que foi enviada pelo MOM. As
propriedades definem atributos adicionais que são configurados pela aplicação ou provedor. Elas
podem ser dos tipos: Boolean, byte, double, float, int, long, short, String, Object, etc. Já o corpo
contém o conteúdo da mensagem e pode ser ObjectMessage, ByteMessage, MapMessage,
StreamMessage e TestMessage.

Figura 10 - sistema de mensagem JMS

Fonte: WETHERBEE (2018)

MDBs são consumidores de mensagens assíncronos que processam mensagens entegues usando JMS.
Segundo o autor, aplicações cliente não podem acessar um MDB diretamente assim como fazem com
session beans e entidades. A única maneira de se comunicar com um MDB é enviando uma mensagem
JMS para um destino no qual o MDB está escutando.
Modelos de aplicação de mensagens:
● Modelo Point-to-point (Filas ou Queue) - nesse modelo somente um consumidor irá processar
uma dada mensagem. O destino das mensagens nesse tipo são Filas (Queue), conforme figura 11;
● Modelo Publish-Subscribe (Tópico ou Topic) - no modelo publish-subscribe cada assinante
(subscriber) recebe uma cópia da mensagem, conforme ilustrado na figura 12. Esse é um modelo
de aplicação do tipo broadcast;

18
 Figura 11 - modelo com filas
Fonte: WETHERBEE (2018)

Figura 12 - modelo com tópicos

Fonte: WETHERBEE (2018)

Esse tipo de bean deve ser usado quando a aplicação necessitar de comunicação assíncrona e
desacoplada para integração entre sistemas. Assim como o stateless, esse bean não mantém estado e é
altamente escalável.
Wetherbee (2018) descreve uma aplicação que usa MDBs, conforme figura 13. Essa é uma aplicação que
trata de compras feitas em uma loja online. Ela inicia quando acontece uma nova compra que envia o
pedido para o sistema de processamento de pedidos, Order Entry. O pedido é processado e envia uma
mensagem para a fila novo pedido, New Order. Na sequência, o sistema de estoque, Inventory, captura
essa mensagem e verifica se o item está disponível no estoque. Caso não esteja é enviada uma mensagem
para a fila Fornecedores, Suppliers. Mas, se existe em estoque é enviada mensagem para a fila pedido
pronto, Order Ready. Nesse momento, o sistema de faturamento lê a mensagem e realiza seu faturamento
e envia mensagem para a fila remessa, Shipping. Por fim, o sistema de gerenciamento de remessa procede
o envio do pedido.

Figura 13 - exemplo de uso de MDBs

Fonte: WETHERBEE (2018)

O MDB é uma classe Java convencional com a anotação a nível de classe ​@MessageDriven​. E diferente
dos beans de sessão, ele não possui interfaces de negócio. Existem alguns requisitos para a classe do
MDB:
● A classe deve implementar a interface listener ​javax.jms.MessageListener e disponibilizar o
método ​onMessage​;
● Ela não pode ser final ou abstract;
● Deve existir um construtor público sem argumentos;
A anotação ​@MessageDriven possui parâmetros que podem ser especificados usando a anotação
@ActivationConfigProperty.​ Com ela podemos definir o nome e tipo do destino (​destinationName e

19
destinationType​), o modo de confirmação do recebimento da mensagem(​acknowledgeMode​), critérios de
filtro e durabilidade da assinatura(​subscriptionDurability​).

2.7.1 Ciclo de vida

Segundo Rubinger (2010), o ciclo de vida é parecido com aquele do stateless, conforme figura abaixo. Ele
inicia no estado não existe quando ainda não existe nada na memória. Posteriormente, quando o servidor
inicia, ele cria um determinado número de instâncias e as coloca em um pool. Quando esse número de
instâncias é insuficiente para tratar as mensagens que estão chegando, o servidor cria mais instâncias.
A transição do estado não existe para o método pronto - pool acontece com a criação das instâncias e
segue com a injeção de recursos. Por fim, o container chama os métodos de ​callback ​@PostConstruct​.
Quando uma instância não é mais necessária são chamados os métodos de ​callback ​@PreDestroy antes
de liberar a memória.

Figura 14 - ciclo de vida de um Message-Driven Bean - MDB

Fonte: RUBINGER, BURKE (2010)

2.7.2 Exemplo
Exemplo de um MDB:
import javax.annotation.Resource;
import javax.ejb.ActivationConfigProperty;
import javax.ejb.MessageDriven;
import javax.jms.MapMessage;
import javax.jms.Message;
import javax.mail.Transport;
import javax.mail.internet.InternetAddress;
import javax.mail.internet.MimeMessage;

@MessageDriven(activationConfig =
{ @ActivationConfigProperty(propertyName = "destinationName",
propertyValue = "StatusMessageTopic"),
@ActivationConfigProperty(propertyName = "destinationType",
propertyValue = "javax.jms.Topic")
},

20
 mappedName = "StatusMessageTopic")
public class StatusMailerBean implements javax.jms.MessageListener
{

@Resource(name = "mail/wineappMail")
private javax.mail.Session ms;

public void onMessage(Message message) {

try {
if (message instanceof MapMessage) {
MapMessage orderMessage = (MapMessage)message;
String from = orderMessage.getStringProperty("from");
String to = orderMessage.getStringProperty("to");
String subject = orderMessage.getStringProperty("subject");
String content = orderMessage.getStringProperty("content");
javax.mail.Message msg = new MimeMessage(ms);
msg.setFrom(new InternetAddress(from));
InternetAddress[] address = { new InternetAddress(to) };
msg.setRecipients(javax.mail.Message.RecipientType.TO, address);
msg.setSubject(subject);
msg.setSentDate(new java.util.Date());
msg.setContent(content, "text/html");
System.out.println("MDB: Sending Message...");
Transport.send(msg);
System.out.println("MDB: Message Sent");
}
else {
System.out.println("Invalid message ");
}

}
catch (Exception ex) {
ex.printStackTrace();
}
}
}
Listagem 5 - exemplo de um bean MDB

Exemplo de um Stateless que envia uma mensagem:

import javax.annotation.Resource;
import javax.ejb.Stateless;
import javax.jms.Connection;
import javax.jms.JMSException;

21
import javax.jms.MapMessage;
import javax.jms.MessageProducer;
import javax.jms.Session;
import javax.jms.Topic;
import javax.jms.TopicConnectionFactory;

@Stateless(name = "OrderProcessing")
public class OrderProcessingBean
{
public OrderProcessingBean() {
}

@Resource(mappedName = "StatusMessageTopicConnectionFactory")
private TopicConnectionFactory statusMessageTopicCF;

@Resource(mappedName = "StatusMessageTopic")
private Topic statusTopic;

public String SendOrderStatus() {

String from = "wineapp@yahoo.com";
String to = "wineapp@yahoo.com";
String content =
"Your order has been processed " + "If you have questions" +
" call EJB Application with order id # " + "1234567890";

try {
Connection connection = statusMessageTopicCF.createConnection();
connection.start();
Session topicSession =
connection.createSession(false, Session.AUTO_ACKNOWLEDGE);

MessageProducer publisher = topicSession.createProducer(statusTopic);

MapMessage message = topicSession.createMapMessage();
message.setStringProperty("from", from);
message.setStringProperty("to", to);
message.setStringProperty("subject", "Status of your wine order");
message.setStringProperty("content", content);
publisher.send(message);
}
catch (JMSException e) {
e.printStackTrace();
}

22
 return "Created a MapMessage and sent it to StatusTopic";
}
}
Listagem 6 - exemplo de um bean stateless que envia mensagem que será tratada pelo MDB

2.8 EJB e Persistência

De acordo com Rubinger (2010), persistência é uma peça chave da plataforma Java EE. Até as versões 2.x
do EJB, ele foi responsável pela definição dessa camada. Depois disso, a persistência ganhou sua própria
especificação dentro da plataforma, chamado de Java Persistence API - JPA. Atualmente, a JPA está na
sua versão 2.2 e faz parte do Java EE 8.

A persistência provê uma abstração simples sobre JDBC, no qual o código ficará isolado de otimizações e
peculiaridades específicas dos fornecedores de banco de dados. Ele também pode ser descrito como um
motor que realiza o mapeamento objeto-relacional (ORM). Além do mapeamento, esse serviço também
fornece uma linguagem de consultas similar ao SQL que trabalha com objetos em vez de esquemas
relacionais.

EJB provê uma conveniente integração com JPA via Entity Beans. Diferente dos beans de sessão ou MDBs,
os entity beans não são componentes do servidor. Eles são objetos simples cujo estado é sincronizado com
a camada de persistência. As entidades representam tabelas do banco e suas instâncias se referem a
linhas dessa tabela. Sua criação ocorre da forma convencional usando new e não precisam implementar
nenhuma API especial.

Contudo, para o autor, assim como os demais EJBs, os entity beans ganham poderosos serviços quando
usados no contexto de um container. No caso da persistência, as instâncias de entity beans podem se
tornar objetos gerenciados sob o controle do serviço chamado ​javax.persistence.EntityManager.​

O EntityManager gerencia o mapeamento objeto-relacional, provê APIs para criação de consultas e para
localizar objetos, sincronização, inserção de objetos no banco, fornece cache e gerencia a interação entre a
entidade e o serviço de transações - Java Transaction API (JTA).

2.8.1 Exemplo
Exemplo de uma entidade:

import java.io.Serializable;

import java.math.BigDecimal;

import javax.persistence.Column;

import javax.persistence.Entity;

import javax.persistence.GeneratedValue;

import javax.persistence.GenerationType;

import javax.persistence.Id;

import javax.persistence.NamedQueries;

import javax.persistence.NamedQuery;

23
import javax.persistence.Table;

import javax.persistence.TableGenerator;

import javax.persistence.Version;

@Entity

@NamedQueries({

@NamedQuery(name = "Address.findAll",

query = "select o from Address o")})

@Table(name = "CH03_ADDRESS")

@TableGenerator(name = "Address_ID_Generator",

table = "CH03_ADDRESS_ID_GEN",

pkColumnName = "PRIMARY_KEY_NAME",

pkColumnValue = "Address.id",

valueColumnName = "NEXT_ID_VALUE")

public class Address implements Serializable {

@Column(length = 4000)

private String city;

@Id

@Column(nullable = false)

@GeneratedValue(strategy = GenerationType.TABLE,

generator = "Address_ID_Generator")

private BigDecimal id;

private String state;

@Column(length = 4000)

private String street1;

@Version

private Integer version;

@Column(name = "ZIP_CODE")

private int zipCode;

public String getCity() { return city; }

24
 public void setCity(String city) { this.city = city; }

public BigDecimal getId() { return id; }

public void setId(BigDecimal id) { this.id = id; }

public String getState() { return state; }

public void setState(String state) { this.state = state; }

public String getStreet1() { return street1; }

public void setStreet1(String street1) { this.street1 = street1; }

public int getZipCode() { return zipCode; }

public void setZipCode(int zipCode) { this.zipCode = zipCode; }

Listagem 7 - exemplo de uma entidade

Exemplo de um stateless que faz acesso ao banco e usa as entidades:

import java.util.List;

import javax.ejb.Stateless;

import javax.persistence.EntityManager;

import javax.persistence.PersistenceContext;

@Stateless

public class CustomerOrderManager {

@PersistenceContext(unitName = "Chapter03PersistenceUnit")

private EntityManager em;

public CustomerOrderManager() {

public <T> T persistEntity(T entity) {

em.persist(entity);

return entity;

public <T> T mergeEntity(T entity) {

return em.merge(entity);

/** <code>select o from Customer o</code> */

25
 public List<Customer> getCustomerFindAll() {

return em.createNamedQuery("Customer.findAll", Customer.class).getResultList();

public void removeAddress(Address address) {

address = em.find(Address.class, address.getId());

em.remove(address);

/** <code>select o from Address o</code> */

public List<Address> getAddressFindAll() {

return em.createNamedQuery("Address.findAll", Address.class).getResultList();

/** <code>select o from CustomerOrder o</code> */

public List<CustomerOrder> getCustomerOrderFindAll() {

return em

.createNamedQuery("CustomerOrder.findAll", CustomerOrder.class)

.getResultList();

Listagem 8 - exemplo de stateless que utiliza entidades

2.9 EJB, Web Services e Micro Serviços

Wetherbee (2018) informa que web services é um sistema de software projetado para suportar interação
interoperável através da rede. Ele possui uma interface descrita no formato de máquina (especialmente
WSDL). Outros sistemas interagem com o web services na maneira descrita na interface usando
mensagens SOAP, tipicamente transportadas sobre HTTP/XML.

Essa arquitetura basicamente provê um modelo de comunicação fracamente acoplado, no qual o

consumidor do serviço não conhece os detalhes da tecnologia ou infraestrutura que implementa a lógica de
negócio exposta como web services.

Para Oracle (2013), web services provê um meio padrão de interoperabilidade entre aplicações executando
em uma variedade de plataformas e frameworks.

Existem dois tipos de web services: 1 - Web services baseados em SOAP que, em Java, são especificados
pela Java API for XML Web Services - JAX-WS e 2 - Web services RESTful(Representational State
Transfer) que, em Java, são especificados pela Java API for RESTful Web Services;

Os web services do tipo 1 - JAX-WS - usa a arquitetura abaixo, na qual o consumidor pesquisa a descrição
do serviço publicado em um repositório/registro através do protocolo Universal description, discovery and
integration - UDDI. No repositório obtém a interface descrita usando Web services description Language -

26
WSDL. Com essa descrição, agora o consumidor pode acessar e se comunicar com o provedor usando
Simple object access protocol - SOAP. Tanto WSDL quanto SOAP usam fortemente o XML.

Figura 15 - arquitetura web services

Fonte: WETHERBEE (2018)

Por outro lado, o web services do tipo 2 - JAX-RS - são um padrão de arquitetura que usa o HTTP para
descoberta, consultas e manipulação de recursos em um ambiente descentralizado e distribuído.
Atualmente, esse tipo tem ganhado popularidade em relação ao anterior em função de sua simplicidade.

Para Wetherbee (2018) usando REST, o cliente acessa um recurso no servidor usando uma URI(Universal
Resource Identifier) e o conjunto de métodos HTTP padrão (GET, POST, PUT e DELETE) para realizar
operações no servidor, conforme quadro abaixo.

Método HTTP Operação

GET Recupera/Consulta

POST Cria

PUT Atualiza

DELETE Apaga/Remove
Quadro 1 - mapeamento das operações REST no HTTP

Fonte: WETHERBEE (2018)

O quadro da figura abaixo mostra uma comparação entre as características dos dois tipos de web services
abordados, segundo Wetherbee (2018):

27
 Figura 16 - Comparação web services baseado em REST e em SOAP

Fonte: WETHERBEE (2018)

Algumas especificações chave do Java EE relacionados a web services:

● Java Architecture for XML Binding - JAXB - API para representar documentos XML como objetos
Java;
● Java API for XML Registries - JAXR - conjunto de APIs que permitem que aplicações Java acessem
o registro UDDI;
● SOAP with Attachments API for Java - SAAJ - conjunto de APIs que permitem que componentes
Java criem mensagens SOAP com anexos como o modelo de anexos no sistema de e-mail.

Tanto Stateless quanto Singleton Session Beans podem ter seus métodos expostos como web services.

Segue o exemplo de um EJB stateless exposto como web services baseado SOAP. Para fazer isso basta
usar a anotação ​@WebService​.

import javax.ejb.Stateless;

import javax.jws.WebMethod;

import javax.jws.WebService;

@Stateless(name = "CreditCheckEndpointBean")

@WebService(serviceName = "CreditService", targetNamespace = "http://www.apress.com/ejb/credit")

public class CreditCheckEndpointBean

public CreditCheckEndpointBean() {

28
 @WebMethod(operationName = "CreditCheck")

public boolean validateCC(String cc) {

return true;

Listagem 9 - Stateless exposto como web services baseado em SOAP

Segue um exemplo de um EJB stateless exposto como web services baseado REST. Para fazer isso basta
usar a anotação ​@Path​.

@Path("creditCheck")

public class CreditCheck {

@PUT

@Consumes("text/plain")

@Produces("text/plain")

@Path("isValid")

public boolean isValid(@PathParam("cardNumber")String ccNumber) {

return true;

Listagem 10 - Stateless exposto como web services baseado em REST

Segue um exemplo de um EJB stateless cliente de um web service. Para acessar o web service utiliza-se a
anotação ​@WebServiceRef​.

@Stateless(name = "OrderProcessFacade", mappedName = "OrderProcessFacade")

public class OrderProcessFacadeBean {

@PersistenceContext(unitName = "Chapter07-WineAppUnit-JTA")

private EntityManager em;

@WebServiceRef(type = CreditService.class)

CreditService service;

private boolean performCreditCheck(Individual individual) {

String ccnum = individual.getCcNum().toString();

CreditCheckEndpointBean creditService = service.getCreditCheckEndpointBeanPort();

29
 return creditService.creditCheck(ccnum);

Listagem 11 - Stateless cliente de um web service

Outro tópico relacionado a serviços bastante estudado atualmente são os microserviços. Wetherbee (2018)
define como uma variante do estilo arquitetural SOA(Service Oriented Architecture). Nesse modelo uma
aplicação é desenvolvida como um conjunto de serviços simples e leves.

A figura abaixo mostra a diferença entre o modelo tradicional de uma aplicação monolítica e a arquitetura de
microserviços.

Figura 17 - Diferença entre uma aplicação monolítica e microserviços

Fonte: WETHERBEE (2018)

3. Exemplo de um sistema integrado

Utilizamos o exemplo de um sistema de uma loja de vinhos na internet disponibilizado por Wetherbee
(2018). O código fonte do sistema está disponível no git hub:
https://github.com/joaopaulopbjp/beginning-ejb-java-ee-8​. O exemplo foi desenvolvido utilizando a IDE
NetBeans e o servidor Glassfish.

Nessa seção explicaremos a arquitetura lógica do referido sistema, ilustrado na figura 18 abaixo.

30
 Figura 18 - Arquitetura lógica do sistema da loja de vinhos

Fonte: Elaboração própria

O sistema da loja de vinhos apresenta uma arquitetura lógica em camadas. Existe uma camada web
desenvolvida usando a tecnologia JSF. Ela acessa os serviços disponibilizados pela camada de negócio.
Nessa camada, Existem diversos EJBs (stateless, stateful, MDB), inclusive um deles expõe sua interface
como serviço. Esses EJBs cooperam se comunicando tanto da forma síncrona quanto assíncrona
disponibilizando pesquisa e criação de clientes, pesquisas de vinhos por diversos critérios, processamento
de pedidos de compras, atualização e controle do estoque, verificação do cartão de crédito e notificação do
status das compras aos clientes.

Os clientes acessam a interface web ou app mobile para pesquisar os vinhos. Para essa pesquisa, eles
utilizam o EJB stateless ​PesquisaFachadaBean.​ Selecionam os itens de interesse e adicionam ao seu
carrinho de compras, usando o EJB stateful ​CarrinhoComprasBean​. Para seguir, será necessário
cadastrar o usuário através do EJB stateless ​ConsumidorFachadaBean,​ caso ainda não seja registrado, e
realizar login. Quando concluída compra, o cliente fornece o cartão de crédito que será validado utilizando o
serviço ​CreditoService,​ e então irá finalizar o pedido. Nesse ponto, será enviada mensagem para um tópico
JMS ​CompraPedidoTopico​. Na sequência, essa mensagem é consumida pelo EJB MDB
ProcessaPedidoMDBBean​, que verifica e atualiza o estoque através do EJB stateless ​EstoqueBean.​ Esse
MDB, em seguida, envia uma mensagem para o tópico JMS ​MessagemStatusTocios​. Por fim, o MDB
StatusNotificaMDBBean ​consome essa mensagem e envia uma notificação através do e-mail informando
o status do pedido para o cliente.

4. Panorama atual do Java EE e EJB

Desde meados de 2018 está ocorrendo a migração do Java EE da Oracle para a fundação Eclipse. A
Oracle cedeu os direitos sobre a plataforma para a referida fundação. Segundo Devmedia (2019), o grande
objetivo do Jakarta EE é manter o Java corporativo sempre atual em relação às tendências e demandas do
mercado. A idéia é ter releases mais constantes.

31
A figura abaixo mostra o interesse pelo termo Jakarta EE de acordo com Google Trends. O interesse por
esse tema tem crescido desde janeiro de 2018 até hoje. Isso demonstra a expectativa da comunidade pela
mudança.

Figura 19 - pesquisa no Google Trends por Jakarta EE

Fonte: Pesquisa realizada no Google Trends em 15/08/2019

De acordo com pesquisa realizada em março/2019 pela equipe do Jakarta EE (2019), as áreas de maior
interesse pela comunidade Java são:

● Melhor suporte a microserviços;

● Integração na nuvem;
● Implementação de referência de qualidade de produção.

Outra expectativa também é pelo lançamento de uma API voltada para tratar bancos noSQL que deverá ter
o nome JNoSQL (SANTANA, 2018) .

Uma outra resposta interessante da pesquisa mostrou as áreas da indústria que utilizam Java. Veja o
resultado na figura abaixo.

Figura 20 - áreas da indústria que utilizam Java

Fonte: Jakaerta EE (2019)

32
Referências
JOHNSON, R.; HOELLER J. ​J2EE Development without EJB​. Indianapolis: Wiley Publishing, 2004.

RUBINGER A. L.; BURKE B. ​Enterprise JavaBeans 3.1​. Sixth Edition. Sebastopol: O’Reilly Media, 2010.

ORACLE. ​JSR 345: ​Enterprise JavaBeans,Version 3.2, EJB Core Contracts and Requirements. Redwood
City: Oracle, 2013.

WETHERBEE, J. et al. ​Beginning EJB in Java EE 8 Building Applications With Enterprise Javabeans​.
3rd ed. New York: Apress, 2018.

FOWLER, M. ​Padrões de Arquitetura de Aplicações Corporativas​. Tradução Acauan Fernandes.

Porto Alegre: Bookman, 2007.

FOWLER, M. ​Enterprise Application​, 2004. Disponível em:

https://martinfowler.com/bliki/EnterpriseApplication.html​. Acesso em: 12 ago. 2019.

GARTNER. ​Glossário​. Disponível em: ​https://www.gartner.com/it-glossary/enterprise-applications​. Acesso

em: 12 ago. 2019.

DEVMEDIA. ​Enterprise JavaBeans​, 2012. Disponível em:

https://www.devmedia.com.br/enterprise-javabeans/26402​. Acesso em: 30 jul. 2019.

DEVMEDIA. ​Jakarta EE, o futuro do Java EE​, 2019. Disponível em:

https://www.devmedia.com.br/jakarta-ee-o-futuro-do-java-ee/40322​. Acesso em: 11 ago. 2019.

ORACLE. ​Java Platform, Enterprise Edition (Java EE) 8 - Your First Cup: ​An Introduction to the Java EE
Platform, 2017. Disponível em: ​https://javaee.github.io/firstcup/toc.html​. Acesso em: 31 jul. 2019.

ORACLE. ​Java Platform, Enterprise Edition (Java EE) 8 - ​The Java EE Tutorial, 2017. Disponível em:
https://javaee.github.io/tutorial/toc.html​. Acesso em: 31 jul. 2019.

SANTANA, O. ​Java EE, passado, presente e futuro com Jakarta EE e NoSQL​. InfoQ, 2018. Disponível
em: ​https://www.infoq.com/br/news/2018/11/javaee-passado-presente-futuro/​. Acesso em: 31 jul. 2019.

WATTS, S. ​Enterprise Application Software Defined: ​How Is It Different from Other Software?, 2017.
Disponível em:
https://www.bmc.com/blogs/enterprise-application-software-defined-how-is-it-different-from-other-software/​.
Acesso em: 02 ago. 2019.

JAKARTA EE. ​2019 Jakarta EE Developer Survey Report​. Eclipse Foundation, 2019. Disponível em:
https://jakarta.ee/documents/insights/2019-jakarta-ee-developer-survey.pdf​. Acesso em: 11 ago. 2019.

33