Tecnologias JPA e JEE

04/06/2024, 12:07 Tecnologias JPA e JEE
Tecnologias JPA e JEE

Prof. Marcos Castro Jr.
Descrição
Você vai compreender a utilização de tecnologias JPA (Java Persistence

API) e EJB (Enterprise JavaBeans), elementos centrais do JEE (Java
Enterprise Edition), tanto na descrição quanto na organização de uma
arquitetura MVC (Model, View e Controller). Além disso, vamos vai
descobrir como construir um exemplo completo, observando o padrão
Front Controller, com a utilização das tecnologias estudadas. Esses
conhecimentos são fundamentais para o profissional de
desenvolvimento web.
Propósito
Preparação
Antes de iniciar seus estudos, é necessário configurar o ambiente, com

a instalação do JDK e Apache NetBeans, definindo a plataforma de
desenvolvimento. Também é necessário instalar o Web Server Tomcat e
o Application Server GlassFish, definindo o ambiente de execução e
testes. Sugerimos que você configure a porta do servidor Tomcat como
8084, para evitar conflitos com o GlassFish na porta 8080.
Objetivos
https://stecine.azureedge.net/repositorio/00212ti/00965/index.html?brand=estacio# 1/100
Módulo 1
JPA no desenvolvimento web
Descrever as características do JPA.
Módulo 2
Implementação de regras de negócio com

EJBs
Empregar componentes EJB na construção de regras de negócio.
Módulo 3
Arquitetura MVC no Java

Descrever a utilização da arquitetura MVC na plataforma Java.
Módulo 4
Padrão Front Controller em sistemas MVC
Empregar o padrão Front Controller em sistema MVC, com interface

Java Web.
meeting_room
Introdução
Neste conteúdo, abordaremos a tecnologia JPA (Java

Persistence API) para o mapeamento objeto-relacional e o uso de
componentes do tipo EJB (Enterprise Java Bean), elemento
central do JEE (Java Enterprise Edition), para a implementação de
regras de negócio.
Após compreender ambas as tecnologias, analisaremos os

elementos estruturais da arquitetura MVC (Model, View e
Controller) e desenvolveremos um sistema cadastral com base
nessa arquitetura, utilizando JPA, EJB e componentes web. Além
disso, adotaremos o padrão Front Controller na camada de
visualização para web.
Neste vídeo você verá os principais tópicos do nosso estudo

sobre as tecnologias JPA e JEE.
Material para download

Clique no botão abaixo para fazer o download do
conteúdo completo em formato PDF.
Download material
1 - JPA no desenvolvimento web

Ao final deste módulo, você será capaz de descrever as características do JPA.
Mapeamento objeto-relacional
Nos bancos de dados relacionais, a estrutura é baseada em tabelas que
armazenam valores em registros, que se relacionam a partir de campos
identificadores ou chaves primárias. A manutenção desses
relacionamentos é realizada por meio de chaves estrangeiras. Por outro
lado, na programação orientada a objetos temos as classes, cujas
instâncias comportam valores, e que podem se relacionar com outras
classes por meio de coleções ou atributos. Não existe uma estrutura de
indexação, mas uma relação bilateral, que ocorre por meio de
propriedades dos objetos envolvidos.
Neste vídeo, você verá o que é o mapeamento objeto-relacional e como

através dele se torna possível fazer com que uma aplicação orientada a
objetos se comunique adequadamente com um banco de dados.
Temos, então, duas filosofias distintas. Como o ambiente de

programação deve gerenciar toda a lógica, ocorre um esforço natural
para minimizar o uso de tabelas e registros, substituindo-os por classes
e objetos. Essa abordagem fica clara quando utilizamos o padrão de

desenvolvimento DAO (data access object), no qual temos uma classe
de entidade, e as consultas e operações sobre o banco de dados são
concentradas em uma classe gestora, com a conversão para objetos e
coleções, abstraindo o enfoque relacional no SGBD.
ORM (mapeamento objeto-relacional)

O uso de DAO deu origem à técnica de mapeamento objeto-relacional,
ou ORM, na qual uma entidade (objeto) é preenchida com os dados de
um registro (relacional). Esse processo, inicialmente realizado de
maneira programática, foi modificado com o advento de frameworks de
persistência, geralmente baseados no uso de XML (eXtended Markup
Language) ou anotações.
Mapeamento objeto-relacional.
Com base nas configurações, que indicam a relação entre atributos da

classe e colunas do banco, bem como chaves e relacionamentos, o
framework gera automaticamente todos os comandos SQL (Structured
Query Language) necessários, transmitindo-os para o banco de dados.
Entity Beans
São parte integrante do J2EE (Java 2 Enterprise Edition) e operam de
acordo com o padrão Active Record, no qual cada operação com um
objeto equivale a um comando executado no banco de dados. Assim, o
padrão pode ser ineficiente, devido à grande quantidade de comandos
SQL que poderiam ser executados em blocos.
JAVA content_copy
No fragmento de código, temos o início da definição de um entity bean,

em que o objeto é gerado pelo servidor de aplicativos e as classes de
entidade apresentam apenas as propriedades, além de alguns métodos
utilitários. O mapeamento do entity bean para a tabela deve ser feito
com base na sintaxe XML, conforme o exemplo a seguir.
XML content_copy
Hibernate
Já no framework Hibernate, o padrão DAO é implícito, com os
comandos sendo gerados a partir dos métodos de um gestor de
persistência, com base no conjunto de elementos de mapeamento e nos
dados presentes nas entidades.
JAVA content_copy
Para o Hibernate, as entidades são apenas classes comuns, sem

métodos de negócios, com um conjunto de propriedades e um
construtor padrão. O mapeamento é realizado via XML, como no trecho
apresentado a seguir.
XML content_copy
Com o XML, temos um modelo documental para o mapeamento,

retirando do código as referências aos elementos do banco de dados, o
que garante maior flexibilidade e menor acoplamento.
Atividade 1
O uso de mapeamento objeto-relacional se tornou uma necessidade

básica para os sistemas modernos. Entre as tecnologias utilizadas,
temos os entity beans, do J2EE, baseado no padrão de

desenvolvimento
A Active Record.
B DAO.
C Facade.
D Adapter.
E Front Controller.
Parabéns! A alternativa A está correta.
Ao utilizar os Entity Beans, que operam de acordo com o padrão Active

Record, qualquer operação efetuada sobre as entidades causa um
efeito diretamente no banco de dados.
Java Persistence API

Além de ser verboso, o uso de XML faz com que alguns problemas
surjam apenas no momento da execução. Um dos maiores avanços do
Java foi a criação do JPA, que permitiu padronizar a arquitetura dos
frameworks de persistência e concentrou as configurações no arquivo
persistence.xml. Não é apenas uma biblioteca, mas uma API que define
a interface comum, configurável por meio de anotações, que deve ser
seguida pelos frameworks de persistência.
Neste vídeo, você vai conferir o Java Persistence API (JPA), um

framework de mapeamento objeto-relacional (ORM) para Java. Também
verá como o JPA simplifica a persistência de dados em aplicações Java,
padroniza o desenvolvimento e torna o código mais legível.
A JPA tem o padrão DAO implícito, o que traz grande eficiência na

persistência. Não é por menos que, na plataforma JEE atual, temos a
substituição dos entity beans pelo JPA.
Definindo uma entidade JPA

Para definir uma entidade JPA, devemos criar uma classe sem métodos
de negócios, também conhecida como POJO (plain old java object). A
entidade definida deve receber anotações para o mapeamento entre a
classe e sua tabela, ou seja, o mapeamento objeto-relacional.
JAVA content_copy
A anotação Entity define a classe Produto como uma entidade para o

JPA, enquanto Table especifica a tabela para a qual será mapeada no
banco de dados, com base no parâmetro name. Utilizamos ainda a
anotação NamedQueries para criar consultas por meio de uma sintaxe
denominada JPQL (Java Persistence Query Language).
Vejamos, a seguir, as principais anotações do JPA.
Entity: marca a classe como uma entidade para o JPA.
Table: especifica a tabela que será utilizada no mapeamento.
Column: mapeia o atributo para o campo da tabela.
Id: especifica o atributo mapeado para a chave primária.
Basic: define a obrigatoriedade do campo ou o modo utilizado para

a carga de dados.
OneToMany: mapeia a relação 1XN do lado da entidade principal

por meio de uma coleção.
ManyToOne: mapeia a relação 1XN do lado da entidade

dependente, com base em uma classe de entidade.
OneToOne: mapeia o relacionamento 1X1 com atributos de

entidade em ambos os lados.
ManyToMany: mapeia o relacionamento NXN com atributos de

coleção em ambos os lados.
OrderBy: define a regra que será adotada para ordenar a coleção.
JoinColumn: especifica a regra de relacionamento da chave

estrangeira ao nível das tabelas.
As entidades JPA devem conter um construtor vazio e um outro

baseado na chave primária, como podemos verificar no código de
Produto, além dos métodos equals e hashCode. Ambos os métodos
utilitários são baseados no atributo codigo, que identifica a instância.
Ainda precisamos do atributo serialVersionUID, referente à versão da

classe e utilizado nos processos de migração da base de dados. Por fim,
a implementação de toString nos dá controle sobre a representação da
entidade como texto.
Além das anotações nas entidades, precisamos configurar o arquivo

persistence.xml, definindo os aspectos gerais da conexão com o banco
de dados. O arquivo deve ser criado na pasta META-INF, e os parâmetros
podem incluir elementos como a classe de conexão JDBC (Java
Database Connectivity) ou o pool de conexões do servidor, sendo
sempre presente a especificação do framework de persistência
utilizado.
JAVA content_copy
A primeira informação relevante é o nome da unidade de persistência

(ExemploSimplesJPAPU), com o tipo de transação que será utilizado.
Transações são necessárias para garantir o nível de isolamento
adequado entre tarefas, como no caso de múltiplos usuários acessando
o mesmo banco de dados.
O controle transacional pode ocorrer a partir de um gestor próprio, para

uso no ambiente JSE (Java Standard Edition) ou pelo JEE (Java
Enterprise Edition) no modelo não gerenciado, mas também permite o
modo gerenciado, por meio da integração com JTA (Java Transaction
API).
Em que temos:
RESOURCE_LOCAL JTA
Utiliza o gestor de Ativa a integração com

transações do JPA, para JTA, para utilizar o
execução no JSE ou no close gerenciamento de
modelo não gerenciado transações pelo JEE.
do JEE.
Em seguida, definimos o provedor de persistência no elemento provider.

O elemento class define as classes de entidade e as propriedades da
conexão são definidas no grupo properties.
Atividade 2
Qual é o objetivo principal da Java Persistence API (JPA)?
Simplificar o desenvolvimento de interfaces gráficas

A
em aplicações Java.
Fornecer uma API para criação de serviços web em

B
Java.
Padronizar o desenvolvimento de aplicações Java que

C
utilizam ORM.
Gerenciar a camada de apresentação em aplicações

D
Java.
E Implementar a lógica de negócio em aplicações Java.
Parabéns! A alternativa C está correta.
A JPA padroniza o desenvolvimento de aplicações Java que utilizam

ORM, fornecendo uma solução consistente para mapear objetos Java
para tabelas em bancos de dados. Trata-se de uma API que define a
interface comum, e que deve ser seguida pelos frameworks de
persistência.
Consulta e manipulação de dados

Com as entidades mapeadas e a conexão configurada, podemos
consultar e manipular os dados utilizando um gestor de entidades
(EntityManager).
Neste vídeo, você verá como é possível manipular dados em aplicações

Java utilizando as tecnologias JPA, entity manager e JPQL. Acompanhe!
Entity Manager
Concentra os métodos que invocam os comandos SQL montados pelo
JPA a partir das anotações da entidade, de uma forma totalmente
transparente.
JAVA
content_copy
Passo 1
O primeiro passo é a definição do EntityManagerFactory, utilizando o

nome da unidade de persistência (ExemploSimplesJPAPU). Em seguida,
obtemos uma instância de EntityManager a partir da fábrica de gestores,
utilizando o método createEntityManager.
Passo 2
Com o gestor instanciado, obtemos um objeto do tipo Query, com a

chamada para createNamedQuery, que utiliza uma NamedQuery da
classe Produto. As consultas nomeadas devem apresentar nomes
únicos pois, do contrário, poderiam gerar dualidade durante a execução.
Passo 3
O método getResultList retorna o resultado da consulta ao SGBD em um
objeto List<Produto>. Em termos práticos, a instrução JPQL é
transformada em um comando SQL, que é transmitido para o banco de

dados via JDBC, e o resultado da consulta é convertido em uma coleção
de objetos, a partir do mapeamento efetuado com as anotações do JPA.
Ao final, encerramos a comunicação com o banco de dados, utilizando o
método close do EntityManager.
Atenção!
Note que o JPA não elimina o uso de JDBC, pois gera apenas os
comandos SQL de forma automatizada, utilizando anotações.
Inclusão de dados
Agora, podemos verificar como é feita a inclusão de um produto em
nossa base de dados.
JAVA
content_copy
Inclusões podem gerar erros, portanto, o ideal é utilizar transações para

executá-las. Na verdade, qualquer manipulação de dados efetuada a
partir do JPA exige uma transação.
Após obtermos uma instância de EntityManager na variável em, é

definido um bloco de código protegido, no qual a transação é iniciada
com begin, seguida da inclusão do produto na base de dados por meio
do método persist, e temos a confirmação da transação com o uso de
commit.
Caso ocorra um erro, todas as alterações efetuadas são desfeitas com o

uso de rollback, e ainda temos um trecho finally, em que fechamos a
comunicação com o uso de close, independentemente da ocorrência de
erros.
Para efetuar a alteração dos dados de um registro, temos um processo

muito similar, trocando apenas o método persist por merge.
JAVA content_copy
Exclusão de dados
Para excluir um registro, devemos utilizar o método find para recuperá-
lo. A exclusão em si será executada por meio do método remove, que
receberá a instância em questão.
JAVA
content_copy
Podemos concluir que os métodos find, persist, merge e remove

correspondem, respectivamente, aos comandos SELECT, INSERT,
UPDATE e DELETE, ao nível do banco de dados.
Atividade 3
A tecnologia JPA permite abstrair os comandos SQL, trabalhando com

entidades e coleções, que são retornadas a partir de comandos JPQL.
O resultado de uma consulta pode ser obtido por meio do método
getResultList, pertencente à classe
A Persistence.
B EntityManager.
C Query.
D Transaction.
E EntityManagerFactory.
A classe Query apresenta diversos métodos para consulta e

manipulação de dados, com base na sintaxe JPQL, como getResultList,
para a obtenção do resultado meio de uma coleção.
Execução do aplicativo
Vamos evitar aqui algumas complexidades do ambiente corporativo,

direcionando nosso foco apenas para a interação com bancos de
dados. Para isso, vamos utilizar uma aplicação Java simples.
Neste vídeo, você aprenderá a criar e organizar um projeto utilizando os

exemplos demonstrados ao longo do conteúdo estudado.
Veja, a seguir, como criamos a aplicação Java que iremos utilizar.
"Wizard" para criação de projetos.
Neste estudo, trabalharemos com o banco de dados Derby, também

chamado de Java DB, exigindo a inclusão da biblioteca jdbc
correspondente.
Adicionando a biblioteca JDBC e o framework EclipseLink

Para adicionar a biblioteca JDBC do Derby, vamos clicar com o botão
direito sobre a divisão Libraries, e escolher a opção Add Library. Na
janela seguinte, selecionaremos Java DB Driver e clicaremos no botão
Add Library.
"Wizard" para inclusão de bibliotecas no projeto do NetBeans.
Precisamos acrescentar o framework JPA escolhido, no caso, o

EclipseLink. Veja como fazer o download desse framework na seção
Explore +.
Após efetuar o download da versão mais recente do EclipseLink no

formato zip e extrair para algum diretório de fácil acesso, crie uma
biblioteca utilizando a opção de menu Tools.Libraries. Em seguida,
clique em New Library. A essa nova biblioteca daremos o nome
EclipseLink2.7, e adicionaremos o arquivo eclipselink.jar, presente no
diretório jlib, além de todos os arquivos no formato jar do subdiretório
jpa. Veja na imagem a seguir.
"Wizard" para inclusão de bibliotecas no projeto do NetBeans.
Após a definição da biblioteca, vamos adicionar ao projeto, da mesma

forma que fizemos para o driver JDBC. Ao final, teremos a configuração
de bibliotecas para o projeto conforme a imagem a seguir.
Navegador do projeto no NetBeans.
Criando o banco de dados Derby

Agora, só precisamos de um banco de dados Derby, que será criado de
forma simples, por meio da aba Services do NetBeans, na divisão
Databases. Veja na imagem a seguir.
Navegador de serviços no NetBeans.
Para criarmos um banco de dados, clique com o botão direito sobre o

driver Java DB da árvore de Databases e escolha da opção Create
Database. Na janela seguinte, preencha o nome do banco de dados, o
usuário e a senha com o valor bancoJPA. Veja na imagem a seguir.
"Wizard" para criação de banco de dados derby no NetBeans.
A conexão é aberta com um duplo-clique sobre o identificador do banco

de dados. Após conectado, execute os comandos SQL de criação da
tabela, clicando com o botão direito sobre a conexão e escolhendo a
opção Execute Command.
Veremos que a janela de edição de SQL será aberta, permitindo que seja
digitado o script apresentado a seguir. Para executar nosso script,
devemos pressionar CTRL+SHIFT+E, ou clicar no botão de execução de
SQL na parte superior do editor.
SQL
content_copy
Resultado da execução do aplicativo

Ao rodar o programa, a listagem da tabela com os registros inseridos
será apresentada na própria janela de edição, em uma divisão própria.
Agora, podemos executar nosso projeto, gerando a saída apresentada a
seguir.
Saída do programa apresentada no console.
Atividade 4
Com relação à execução do projeto no ambiente local, marque a

alternativa correta:
O NetBeans possui todas as bibliotecas necessárias ao

A
projeto.
Caso o projeto necessite de bibliotecas externas, deve

B
ser executado apenas no servidor.
Não há necessidade de preparar o servidor, pois o

C ambiente de produção possui as bibliotecas
necessárias.
É necessário incluir as bibliotecas no projeto para

D
garantir seu funcionamento.
Sem a inclusão das bibliotecas, o sistema funciona a

E
penas no servidor.
Parabéns! A alternativa D está correta.
Para que o programa funcione de maneira correta, precisamos incluir

as bibliotecas externas. Portanto o ambiente local e o servidor de
produção devem possuir as dependências.
Manipulando dados com

NamedQueries
Como já vimos, é extremamente necessário estabelecer a comunicação
entre a aplicação e o banco de dados. Normalmente, precisamos
realizar alguma consulta parametrizada, o que inclui receber os
parâmetros, como uma chave primária para identificação, e enviar a
instrução para o banco de dados.
Neste vídeo, você verá na prática como utilizar parâmetros em

NamedQueries para recuperar registros da tabela.
Roteiro de prática
Avançaremos um pouco mais, propondo a você o seguinte desafio:
alterar o programa apresentado anteriormente, de forma que a classe
principal.Principal utilize o código para selecionar um produto
específico. Para isto, é importante realizar as etapas a seguir.
Utilizar uma anotação para criar uma NamedQuery na classe

Produto
Alterar a NamedQuery utilizada em Principal
Incluir os parâmetros no objeto query
Veja o resultado dessa prática.
Resultado expand_more
Classe “modelo.Produto”:
JAVA content_copy
Classe "principal.Principal":
JAVA content_copy
Faça você mesmo!

Qual é o resultado da execução do trecho de código Java a seguir?
JAVA content_copy
O código define uma única named query para a

entidade "Employee". A named query
A "Employee.findByDepartment" retorna todos os
registros da tabela de Employee que pertencem a um
departamento específico.
O código define duas named queries para a entidade

"Employee". A primeira named query, "Employee.findAll",
retorna todos os registros da tabela de Employee, sem
B critérios de filtragem. A segunda named query,
"Employee.findByDepartment", retorna os registros de
Employee que pertencem a um departamento
específico.

"Employee". A primeira named query, "Employee.findAll",
retorna todos os registros da tabela de Employee. A
C
segunda named query, "Employee.findByDepartment",
retorna os registros de Employee que pertencem a
qualquer departamento.

Employee. A primeira named query, Employee.findAll,
retorna todos os registros da tabela de Employee. A

D
segunda named query, Employee.findByDepartment,
retorna os registros de Employee que pertencem a um
departamento específico.
E O código não possui nenhuma named query definida.
O trecho de código define duas named queries para a entidade

Employee. A primeira named query, Employee.findAll, utiliza a consulta
"SELECT e FROM Employee e" para retornar todos os registros da
tabela de Employee. A segunda named query,
"Employee.findByDepartment", utiliza a consulta "SELECT e FROM
Employee e WHERE e.department = :department" para retornar os
registros de Employee que pertencem a um departamento específico,
utilizando um parâmetro ":department".
2 - Implementação de regras de negócio com EJBs

Ao final deste módulo, você será capaz de empregar componentes EJB na construção de
regras de negócio.
Enterprise Java Beans (EJB)

No ambiente Java, a arquitetura de objetos distribuídos geralmente é o
elemento central dos servidores corporativos. Podemos observar a
importância dessa arquitetura no uso de componentes EJB (Enterprise

Java Bean) em servidores de aplicação, como o Glassfish.
Neste vídeo, você verá a importância dos EJBs, bem como suas
aplicações e vantagens em um ambiente corporativo.
Os EJB são componentes corporativos utilizados de forma indireta

dentro de um ambiente de objetos distribuídos, suportando elementos
da plataforma JEE (Java Enterprise Edition). Todo EJB é executado em
um pool de objetos, cujo número de instâncias varia de acordo com a
demanda, segundo um intervalo de tempo estabelecido.
Podemos acessar os serviços oferecidos pelo pool de EJBs por meio de

interface local (EJBLocalObject) ou remota (EJBObject), gerada a partir
de componentes de fábrica, criados com a implementação de
EJBLocalHome, para acesso local, ou EJBHome, para acesso remoto.
Como é padrão na plataforma Java, as fábricas são registradas e
localizadas via JNDI (Java Naming and Directory Interface). O processo
para acessar o pool de EJBs envolve três passos:
computer Passo 1
Acesso à fábrica de interfaces, por meio de JNDI.
computer Passo 2
Geração da interface de acesso pela fábrica.
computer Passo 3
Entrega da interface ao cliente, permitindo iniciar o

diálogo com o pool.
Veja a representação desses passos na imagem a seguir.
Servidor e contêineres Java EE.
O acesso ao banco de dados é realizado por meio de um pool de

conexões JDBC, representado por um objeto do tipo DataSource, que é
registrado via JNDI. Quando solicitamos uma conexão ao DataSource,
não estamos abrindo uma nova conexão, mas reservando uma das
disponíveis no pool. Quando invocamos o método close, não ocorre a
desconexão, mas sim a liberação da conexão para a próxima requisição.
No código a seguir, temos um exemplo de utilização de pool de

conexões. Após obter o recurso via JNDI, por meio do método lookup de
InitialContext, efetuamos a conversão para o tipo correto, no caso, um
DataSource que fornece conexões através do método getConnection. O
restante da programação é a mesma de um acesso local ao banco de
dados.
JAVA
content_copy
O JPA abstrai a localização e utilização do pool, que fica a cargo do

framework de persistência. No fluxo normal de execução, o cliente faz
uma solicitação para a interface de acesso, que é repassada para o
pool. O pool disponibiliza um EJB para responder à solicitação. Já na
programação do EJB, utilizamos o JPA para obter acesso ao banco de
dados.
A programação, no modelo adotado a partir do JEE5, é bastante

simples, e precisaremos apenas das anotações corretas para que os
application servers, como o JBoss ou o GlassFish, se encarreguem de
montar toda a estrutura necessária. Isso é bem diferente do processo de
criação adotado pelo J2EE, envolvendo uma grande quantidade de
interfaces, classes e arquivos XML, com a verificação sendo realizada
apenas no momento da implantação do sistema.
Atividade 1
Qual das seguintes afirmações sobre os Enterprise Java Beans (EJBs)

é verdadeira?
Os EJBs fornecem uma arquitetura baseada em

A componentes para desenvolver aplicativos distribuídos,
transacionais e escaláveis.
Os EJBs só podem ser usados para desenvolver

B aplicativos desktop autônomos, e não são adequados
para desenvolver aplicativos web.
C Os EJBs só podem ser implantados em um único
servidor de aplicativos, como JBoss ou WebSphere.
Os EJBs não oferecem suporte à gestão de transações

D
ou acesso a banco de dados.
Os EJBs são uma tecnologia obsoleta e não são mais

E amplamente utilizados na indústria de desenvolvimento
de aplicativos.
Um dos principais objetivos dos EJBs é fornecer um framework para

construir aplicativos empresariais distribuídos que possam ser
implantados em vários servidores e consigam lidar com transações em
vários recursos.
Session beans
Esses componentes fundamentais no desenvolvimento de aplicações
empresariais em Java são responsáveis por encapsular a lógica de
negócios e fornecer serviços específicos para os clientes. Os session
beans são amplamente utilizados para implementar transações, acesso
a bancos de dados e outras operações relacionadas à lógica de
negócios.
Neste vídeo, você vai ver os session beans no Java Enterprise Edition
(Java EE), que são componentes de negócios essenciais em aplicativos
empresariais. Também verá os dois tipos de session beans, além de
suas vantagens, como gerenciamento de transações, concorrência e
escalabilidade.
Os EJBs são utilizados para implementar as regras de negócio do nosso

aplicativo com base nas entidades e nos requisitos definidos. Esses
componentes não podem acumular a responsabilidade sobre a estrutura
de persistência utilizada. Também devemos observar que as regras de
negócio devem ser totalmente independentes das interfaces do
sistema.
O primeiro tipo de EJB que deve ser observado é o de sessão (session

beans), responsável por efetuar processos de negócios de forma
síncrona, e configurável, podendo apresentar três comportamentos
distintos:
Stateless
Não permite a manutenção de estado, ou seja, não guarda valores entre
chamadas sucessivas.
Stateful
É utilizado quando é necessário manter valores entre chamadas
sucessivas, como no caso de somatórios.
Singleton
Permite apenas uma instância por máquina virtual, garantindo o
compartilhamento de dados entre todos os usuários.
Stateless e stateful
Utilizamos stateless quando não precisamos de informações dos
processos anteriores ao corrente. Qualquer instância do pool de EJBs
pode ser escolhida, e não é necessário efetuar a carga de dados
anteriores, definindo o padrão de comportamento mais ágil para um
session bean.
O comportamento stateful deve ser utilizado apenas quando

precisamos de informações anteriores, como em uma cesta de compras
virtual, ou processos com acumuladores em cálculos estatísticos, entre
outras situações com necessidade de gerência de estados.
Interface de acesso
Antes de definir um session bean, devemos definir sua interface de
acesso, com base na anotação Local, para acesso interno, ao nível do
servidor, ou Remote, permitindo que o componente seja acessado
remotamente. Em nossos estudos, será suficiente o uso de acesso local,

já que teremos o acionamento dos EJBs a partir dos servlets.
JAVA
content_copy
Ao criarmos o EJB, ele deverá implementar a interface de acesso, além

de ser anotado como stateless ou stateful, dependendo da necessidade
do negócio. Para uma calculadora simples, não precisaríamos de
gerência de estados.
JAVA
content_copy
Singleton
O session bean que implementa o Singleton é utilizado para
compartilhar dados entre os usuários conectados, mesmo na execução
em ambientes distribuídos. É importante observar que a tecnologia de
EJBs é empregada em sistemas de missão crítica, que costumam
trabalhar com clusters de computadores.
Session bean com Servlet
O código a seguir representa o processo de utilização de um session

bean a partir de um Servlet.
JAVA
content_copy
Tudo que precisamos fazer é anotar um atributo, do tipo da interface

local, com EJB. No exemplo, temos a interface CalculadorLocal
referenciada no atributo facade, o que permite invocar o método somar,
sendo executado pelo pool.
Quase todos os processos de negócio de um sistema corporativo são

implementados por meio de session beans. Contudo, alguns
comportamentos não podem ser definidos de forma síncrona, exigindo
comunicação com mensagerias, seguindo um modelo assíncrono.
Atividade 2
Qual das alternativas a seguir descreve corretamente a diferença entre

stateless e stateful session beans?
Stateless session beans são mantidos pelo contêiner

EJB por toda a vida do aplicativo, enquanto stateful
A
session beans são criados e destruídos a cada
chamada de método.
Stateless session beans são criados e destruídos a

cada chamada de método, enquanto stateful session
B
beans são mantidos pelo contêiner EJB por toda a vida
do aplicativo.
Ambos, stateless e stateful session beans, são

C mantidos pelo contêiner EJB por toda a vida do
aplicativo.
Ambos, stateless e stateful session beans, são criados

D
e destruídos a cada chamada de método.
Os stateless não são mantidos no contêiner, enquanto

E os stateful armazenam apenas uma instância do
recurso.
Parabéns! A alternativa B está correta.
Session beans do tipo stateful armazenam estado, enquanto os

stateless podem ser destruídos e recriados sem perda de informações.
Message-driven beans (MDB)

Protocolos de mensageria desempenham um papel fundamental em
sistemas Java. Esses protocolos definem conjuntos de regras e
formatos utilizados para facilitar a troca de mensagens entre diferentes
sistemas. Eles determinam como as mensagens são enviadas,
recebidas, processadas e entregues aos MDBs (message-driven Beans).
Esses protocolos oferecem recursos como persistência de mensagens,
filas de mensagens e garantia de entrega, possibilitando uma
comunicação confiável e assíncrona para os MDBs.
Neste vídeo, você verá o que são os message-driven beans (MDB) e

como eles são usados para processar mensagens assíncronas em
aplicativos empresariais. Você também aprenderá sobre as vantagens

de escalabilidade e tolerância a falhas que os MDBs oferecem.
Mensagerias
As mensagerias atuam de forma assíncrona e podem ser:
Publish/subscribe.
Modelo publish/subscribe
As mensagens são depositadas em tópicos para que os

assinantes as recuperem.
Point to point.
Modelo point to point
As mensagens são enfileiradas para um tratamento sequencial

no destinatário.
O uso de mensagerias permite a construção de sistemas B2B quase

sem acoplamento, em que o único elemento de ligação entre os
sistemas das duas empresas é a mensagem transmitida entre elas.
Após o emissor publicar uma mensagem, a gerência passa a ser da

mensageria, até a retirada pelos receptores. Mesmo que o receptor
esteja inativo, as mensagens não se perdem, sendo acumuladas até o
momento em que o receptor seja ativado.
Para criar filas ou tópicos no GlassFish, é necessário utilizar o comando

asadmin, como no exemplo seguinte, para a criação de uma fila
denominada jms/SimpleQueue.
COMANDO DO POWERSHELL.
content_copy
Também podemos abrir o console do asadmin sem a passagem de

parâmetros e invocar os comandos internamente. Vejamos.
Comandos executados no shell do asadmin.
MDB (message-driven bean)

Existe um tipo de EJB denominado MDB (message-driven bean), que
tem como finalidade a comunicação com mensagerias via JMS (Java
Message Service), possibilitando o processamento assíncrono no JEE.
Com o MDB, é possível trabalhar nos dois domínios de mensagerias,
com o tratamento via pool de EJBs, a partir do método onMessage,
representando os eventos de recepção de mensagens.
JAVA
content_copy
No código de exemplo, o MDB é definido utilizando a anotação

MessageDriven, com a configuração para acesso a jms/SimpleQueue,
do tipo javax.jms.Queue, por meio de anotações
ActivationConfigProperty. Também é possível utilizar canais internos do
projeto, mas o uso de canais do servidor viabiliza o comportamento
B2B, com acesso a partir de qualquer plataforma que dê suporte ao uso
de mensagerias.
Para o tratamento das mensagens, devemos implementar a interface

MessageListener, que contém apenas o método onMessage. A
mensagem é recebida no parâmetro do tipo Message, sendo necessário
converter para o tipo correto, como no exemplo, em que temos a captura
de um texto enviado via TextMessage, e a impressão da mensagem no
console do GlassFish.
Saiba mais
O MDB foi projetado exclusivamente para receber mensagens a partir de

filas ou tópicos, o que faz com que não possa ser acionado diretamente,
como os session beans. Para sua ativação, basta que um cliente poste
uma mensagem.
O código é feito da seguinte forma:
JAVA content_copy
O processo é um pouco mais complexo que o adotado para os session

beans, mas apresenta menor acoplamento. Veja o passo a passo:
computer Passo 1
Mapear a fábrica de conexões da mensageria e a

fila de destino do MDB, por meio de anotações
Resource.
computer Passo 2
Definir o método putMessage para envio da

mensagem, criando uma conexão a partir da
fábrica, uma sessão a partir da conexão, e o
produtor de mensagens (MessageProducer) a partir
da sessão.
computer Passo 3
Criar a mensagem de texto (TextMessage) por meio

da sessão, definir o texto que será enviado com
setText, e finalmente enviar a mensagem,
finalizando a definição do método putMessage.
Veja a representação na imagem a seguir:
Console do Glassfish exibindo as mensagens de teste.
Atividade 3
Um componente do tipo MDB (message-driven bean) é voltado para o

processamento de regras de negócio de forma assíncrona, com base
na recepção de mensagens a partir de ferramentas como JBoss MQ e
MQ Series. A conexão com as mensagerias é feita com base na
biblioteca:
A JTA
B JDBC
C JMS
D JAAS
E JTS
A conexão entre o aplicativo e a mensageria deve ser feita por meio de

um middleware adequado, classificado como MOM (message-oriented
middleware), e na plataforma Java, temos o JMS (Java Message
Service) como biblioteca para fornecimento de MOM.
Aplicativo corporativo
Aplicativos Java corporativos são softwares desenvolvidos para atender
às necessidades complexas e específicas das organizações. Eles são
construídos utilizando tecnologias Java Enterprise Edition (Java EE),

fornecendo recursos avançados, como gerenciamento de transações,
segurança, escalabilidade e integração com sistemas legados. Esses
aplicativos são projetados para lidar com grandes volumes de dados e
suportar operações críticas para o funcionamento das empresas.
Neste vídeo você verá a estrutura de um aplicativo corporativo baseado

no Java Enterprise Edition (Java EE) e como os Enterprise JavaBeans
(EJB) e Message Driven Beans (MDB) desempenham um papel
importante nessa estrutura.
EJBs
Para que possamos trabalhar com EJBs, por meio do ambiente do
NetBeans, devemos definir um projeto corporativo. A sequência de
passos para criar o aplicativo corporativo pode ser observada a seguir.
Passo 1
Criar um projeto do tipo Enterprise Application, na categoria Java
Enterprise.
"Wizard" para criação de aplicação do NetBeans.
Passo 2
Preencher o nome (ExamploEJB) e local do projeto.
Passo 3
Escolher o servidor (GlassFish) e versão do JEE (Java EE7), além de
marcar as opções de criação para os módulos EJB e web.
Seguindo corretamente os passos apresentados, você vara que serão

gerados três projetos. Poderemos visualizá-los na interface do
NetBeans.
Navegador de projeto do NetBeans.
A seguir, apresentamos as características de cada um dos projetos.
ExemploEJB-ejb
Utilizado na definição das entidades JPA e dos componentes EJB, sendo

compilado com a extensão "jar".
ExemploEJB-war
Contém os elementos para web, como servlets, facelets e páginas
XHTML, compilados para um arquivo "war".
ExemploEJB
Agrupa os dois projetos anteriores, compactados em apenas um
arquivo, com adoção da extensão "ear", para implantação.
Quando trabalhamos com um projeto corporativo, devemos implantar o

projeto principal, com extensão ear (enterprise archived), cujo ícone é
um triângulo, pois qualquer tentativa de implantar os dois projetos
secundários irá impedir a execução correta do conjunto, exigindo que
seja feita a remoção manual dos projetos anteriores pela aba de
serviços.
Remoção de aplicação web do servidor Glassfish.
Agora, vamos criar nosso primeiro session bean, configurado como

stateless, no projeto secundário ExemploEJB-ejb, adicionando um novo
arquivo e seguindo alguns passos:
Passo 1
Selecionar o tipo de session bean na categoria Enterprise Java Beans.
"Wizard" de criação de arquivos do NetBeans.
Passo 2
Definir o nome (Calculadora) e pacote (ejbs) do novo session bean,
escolher o tipo como Stateless e marcar apenas a interface Local
"Wizard" de criação de arquivos do NetBeans.
Em diversas situações, a IDE mostra um erro de compilação decorrente

da importação dos componentes da biblioteca javax.ejb. Caso esse
problema ocorra, a solução é simples com a inclusão da biblioteca Java
EE 7 API no projeto.
Navegador de projeto do NetBeans.
Após incluir as bibliotecas necessárias, podemos completar os códigos

de Calculadora e CalculadoraLocal, de acordo com os exemplos
apresentados anteriormente, e iremos testar o EJB, ainda seguindo os
exemplos, por meio de um servlet. Como os componentes web são
criados ao nível de ExemploEJB-war, devemos acessar o projeto e

adicionar um novo arquivo do tipo servlet, na categoria web, com o
nome ServletSoma e pacote servlets, sem adicionar informações ao
arquivo web.xml.
Com o componente ServletSoma criado, utilizamos o código de exemplo

definido antes, com a chamada para o EJB, executamos o projeto
principal (ExemploEJB), e efetuamos a chamada apropriada:
http://localhost:8080/ExemploSimplesJPA-war/ServletSoma.
Saída do servlet ServletSoma.
MDBs
Para criar o EJB do tipo MDB, devemos adicionar, no projeto
ExemploEJB-ejb, um novo arquivo do tipo message-driven bean, na
categoria Enterprise Java Beans.
Precisamos definir o nome (Mensageiro001) e o pacote do componente,

além de escolher a fila para as mensagens no servidor
(jms/SimpleQueue), como na imagem a seguir.
"Wizard" para criação de um MDB.
Todos os passos para a codificação de Mensageiro001 foram descritos

anteriormente, bem como a do servlet para postagem da mensagem,
com o nome ServletMessage, mas lembre-se de que o servlet deve ser
criado no projeto ExemploEJB-war. Com todos os componentes
implementados, basta implantar o sistema, a partir do projeto principal,
e efetuar a chamada correta no navegador pelo endereço:

"http://localhost:8080/ExemploSimplesJPA-war/ServletMessage".
Após efetuar a chamada, você verá a página com a informação de que

ocorreu o envio da mensagem, o que poderá ser verificado no console
de saída do GlassFish, conforme descrito anteriormente.
Atividade 4
Qual das opções a seguir é uma das principais partes de um aplicativo

corporativo em Java Enterprise Edition (Java EE), sendo empregada no
processamento de mensagens assíncronas?
A JRE (Java Runtime Environment).
B JDK (Java Development Kit).
C EJB (Enterprise JavaBeans).
D MDB (Message Driven Beans).
E JNDI (Java Naming and Directory Interface).
Os MDBs são usados para processamento de mensagens assíncronas

em aplicativos corporativos Java EE. Eles são implantados em um
servidor de aplicativos Java EE e ativados quando uma mensagem é
enviada para uma fila ou tópico.
Aplicando os MDBs
No mundo web é bastante comum a utilização de recursos externos,
sejam eles de outro projeto da sua organização ou mesmo de outra
organização. Esses recursos podem ser desenvolvidos utilizando
linguagens e respeitando diferentes padrões. Para facilitar a
comunicação, uma excelente alternativa é a troca de mensagens.
Neste vídeo você verá como são utilizados Message-Driven Beans

(MDBs) baseados em tópicos para processar mensagens assíncronas
em aplicativos corporativos. Também a configuração do ambiente e a
implementação do MDB.
Roteiro de prática
No mundo Java, utilizamos muito os MDB (message-driven beans).
Portanto, vamos exercitar a criação desse tipo de componente
desenvolvendo duas classes no mesmo projeto: uma para receber
mensagens e outra para produzir. Para isso, vamos usar o padrão point-
to-point, conforme as etapas a seguir:
Crie a fábrica de conexões e a fila no glassfish, utilizando o

asadmin.
No projeto ejb, desenvolva a classe MeuReceptor, responsável por

tratar as mensagens.
No projeto war, desenvolva uma classe MeuProdutor, que contenha

um servlet para enviar uma mensagem para o receptor.
No projeto war, altere o index.html com um formulário de envio de

mensagem.
Verifique o resultado no console do glassfish.
"MeuReceptor.java"
JAVA content_copy
"MeuProdutor.java"
JAVA content_copy
"Index.html"
HTML
content_copy
Faça você mesmo!

No contexto de message-driven beans (MDBs) Java Message Service
(JMS), qual é o objetivo do trecho de código Java a seguir?
JAVA
content_copy
O código define um MDB chamado ExampleMDB, que

escuta uma fila JMS chamada “exampleQueue” e
implementa a interface MessageListener. O método
A
onMessage é chamado sempre que uma mensagem é

recebida na fila, permitindo que a lógica de
processamento seja executada.

envia mensagens para uma fila JMS chamada
B
"exampleQueue" sempre que uma ação específica
ocorre no sistema.
O código define um MDB chamado ExampleMDB, que é

C responsável por criar e gerenciar filas JMS no servidor
de aplicativos.

escuta um tópico JMS chamado "exampleQueue" e
implementa a interface MessageListener. O método
D
onMessage é chamado sempre que uma mensagem é
publicada no tópico, permitindo que a lógica de
processamento seja executada.
O código não possui nenhuma relação com o uso de

E
MDBs ou JMS.
O trecho de código define um MDB chamado ExampleMDB utilizando a

anotação @MessageDriven. Essa anotação configura o MDB para
escutar uma fila JMS, especificada pela propriedade "destination" com
valor "exampleQueue". A propriedade "destinationType" indica que se
trata de uma fila. Ao implementar a interface MessageListener e definir
o método onMessage, o código estabelece que o MDB responderá a
mensagens recebidas na fila, permitindo a execução de uma lógica de
processamento específica.
3 - Arquitetura MVC no Java

Ao final deste módulo, você será capaz de descrever a utilização da arquitetura MVC na
plataforma Java.
Padrões de desenvolvimento
A orientação a objetos representou um grande avanço na
implementação de sistemas, pois aproximou a modelagem da
codificação. Nesse contexto, os padrões de desenvolvimento fornecem
ainda mais vantagens ao desenvolvimento, definindo soluções
reutilizáveis, com nome, descrição da finalidade, modelagem UML e
modo de utilização.
Neste vídeo, você entenderá sobre padrões de desenvolvimento,

soluções reutilizáveis para problemas comuns na programação, bem
como sua importância, e alguns exemplos, como Singleton e o Abstract
Factory.
Entre os diversos padrões de projeto, alguns se destacam nos sistemas

corporativos, como Facade, Proxy, Flyweight, Front Controller e DAO
(data access object). Na tecnologia JPA observamos o padrão DAO,
com comandos para acesso ao banco de dados agrupados em classes

específicas, separadas do restante do sistema.
Descrição dos padrões de desenvolvimento

Vejamos uma descrição formal dos padrões de desenvolvimento
citados, além de alguns outros, comuns em sistemas criados para o
ambiente JEE.
Abstract Factory: definição de uma arquitetura abstrata para a

geração de objetos, muito comum em frameworks.
Command: encapsula o processamento da resposta para algum

tipo de requisição, muito utilizado para o tratamento de solicitações
feitas no protocolo HTTP.
Data Access Object: utiliza classes específicas para concentrar as

chamadas para o banco de dados.
Facade: encapsula as chamadas para um sistema complexo, muito

utilizado em ambientes corporativos.
Flyweight: cria grupos de objetos que respondem a uma grande

quantidade de chamadas.
Front Controller: concentra as chamadas para o sistema, efetuando

os direcionamentos corretos para cada chamada.
Iterator: permite acesso sequencial aos objetos de uma coleção, o

que é implementado nativamente no Java.
Proxy: Define um objeto para substituir a referência de outro,

utilizado nos objetos remotos para deixar a conexão transparente
para o programador.
Service Locator: gerencia a localização de recursos

compartilhados, com base em serviços de nomes e diretórios.
Singleton: garante a existência de apenas uma instância para a

classe, como em controles de acesso.
Strategy: seleciona algoritmos em tempo de execução, com base

em algum parâmetro fornecido.
Atualmente, os sistemas combinam diversos padrões de projeto em

suas implementações.
Exemplo
Criação de um pool de processadores de resposta para solicitações de
usuários remotos, o que poderia ser caracterizado por um Flyweight de
Strategies para a escolha de Commands, além da utilização de Proxy na

comunicação com os clientes.
Atividade 1
Qual é a importância dos padrões de desenvolvimento na

programação?
A Ajudam a aumentar a complexidade do código.
B Reduzem a legibilidade do código.
C Tornam o código mais difícil de manter.
Facilitam a reutilização de soluções já testadas e

D
comprovadas.
E São irrelevantes para a qualidade do código.
Os padrões de desenvolvimento são soluções consolidadas para

problemas comuns na programação. Eles facilitam o processo de
desenvolvimento por meio da reutilização, além de contribuírem para a
qualidade do código.
Padrões arquiteturais
A arquitetura de um sistema define sua estrutura de alto nível,

formalizando a organização em termos de componentes e interações.
Um dos objetivos é aproximar a visão de projeto da implementação do
sistema, impedindo que ocorra a previsão de funcionalidades inviáveis
para a fase de codificação.
Neste vídeo, você entenderá sobre padrões de projeto, bem como

exemplos com 3 entre os diversos que existem: camadas, broker e
Event-driven. Os padrões arquiteturais podem ser combinados de forma
a entregar soluções robustas para problemas complexos.
As especificações da arquitetura também definem as interfaces de

entrada ou saída de informações, forma de comunicação com outros
sistemas, e regras para o agrupamento dos componentes com base em
suas áreas de atuação, entre outras características. Entenda:
Modelo arquitetural
Define a arquitetura de forma abstrata, com foco apenas no objetivo ou
característica principal.
Padrão arquitetural
Define o perfil dos componentes estruturais, o modelo de comunicação
e até os padrões de desenvolvimento mais adequados.
Por exemplo, o modelo de objetos distribuídos define apenas atributos

essenciais para delimitar um ambiente com coleções de objetos
respondendo a requisições.
Existem diferentes definições de modelos para os padrões arquiteturais,

e alguns deles satisfazem a mais de um modelo. Vejamos.
Padrão arquitetural Modelo(s)
Broker Sistemas Distribuídos
Padrão arquitetural Modelo(s)
Mud to structure, chamada e

Camadas
retorno
Orientado a objetos Chamada e retorno
Programa principal e sub-

Chamada e retorno
rotina
Mud to structure, fluxo de

Pipes/Filters
dados
Mud to structure, centrada em

Blackboard
dados
Lote Fluxo de dados
Repositório Centrada em dados
Processos comunicantes Componentes independentes
Event-Driven Componentes independentes
Interpretador Máquina virtual
Baseado em regras Máquina virtual
MVC Sistemas interativos
PAC Sistemas interativos
Microkernel Sistemas adaptáveis
Reflexiva Sistemas adaptáveis
Tabela: Modelos dos padrões arquiteturais.

Marcos Castro Jr.
A arquitetura de referência mapeia um padrão arquitetural para

componentes de software, que são capazes de implementar as
funcionalidades requeridas de forma cooperativa. Definida a referência,
finalmente pode ser construída uma arquitetura, com todos os
componentes adequadamente codificados.
Um exemplo de arquitetura é o VisiBroker, da fabricante Inprise, que

utiliza como referência o CORBA (common object request broker
architecture), baseado no modelo de objetos distribuídos, segundo o
padrão arquitetural Broker. Veja essa representação na imagem a
seguir.
Diagrama da arquitetura VisiBroker.
Para utilizar uma arquitetura, é necessário compreender sua finalidade,

de acordo com o padrão arquitetural adotado. Veja:
Sistemas de baixa Sistemas de alta

complexidade complexidade
Podem basear a Exigem uma

arquitetura nos padronização mais
paradigmas adotados close robusta, incluindo a
para a codificação, forma de comunicação
como a orientação a em rede, gerência de
objetos. pools de objetos, entre
outros aspectos.
Ambientes de execução remota, como RPC (remote procedure call) e

Web Services, são baseados em arquiteturas no padrão de processos
comunicantes. Nesses ambientes, servidores e clientes podem ser
criados utilizando plataformas de desenvolvimento distintas, e o único
fator de acoplamento é o protocolo de comunicação adotado.
É comum o uso de mensagerias nos sistemas corporativos, nas quais

utilizamos o padrão arquitetural event-driven, baseado na ativação de
processos de forma indireta, a partir de mensagens. O papel das
mensagerias é tão importante que o componente adotado na
comunicação é chamado de MOM (message-oriented middleware). As
vantagens no uso desse padrão são o acoplamento quase nulo e o
processamento assíncrono.
Um sistema simples pode responder a um único padrão arquitetural,

mas os sistemas corporativos são complexos e heterogêneos, sendo
muito comum a adoção de múltiplos padrões combinados.

Normalmente, é adotado um padrão principal, que, no caso dos
sistemas cadastrais, é o MVC.
Atividade 2
Os programas que executam sobre sistemas operacionais baseados

no UNIX utilizam amplamente um padrão arquitetural específico, no
qual efetuamos o direcionamento do fluxo de saída do primeiro
programa para o fluxo de entrada do segundo. O texto faz referência a
qual padrão arquitetural?
A Broker.
B MVC.
C PAC.
D Batch.
E Pipes/filters.
Parabéns! A alternativa E está correta.
Um exemplo de comando comum no UNIX, seria "ls -s | more", em que

temos a listagem de um diretório, obtida no primeiro comando, sendo
direcionada para um comando que efetua a paginação do resultado. Os
comandos representam os filtros, que são concatenados pelo símbolo
de pipe.
Arquitetura MVC
A arquitetura MVC (model-view-controller) divide o sistema em três
camadas, com responsabilidades específicas.
Model: nessa camada, temos as entidades e as classes para

acesso ao banco de dados.
Controller: aqui, concentramos os objetos de negócio.
View: nessa camada, são definidas as interfaces do sistema com o

usuário ou com outros sistemas.
Para saber um pouco mais sobre a arquitetura MVC, não deixe de

assistir o vídeo a seguir.
Neste vídeo, você vai entender a arquitetura MVC no desenvolvimento

web. Essa arquitetura consiste em separar a aplicação em três partes
(modelo, visualização e controlador), permitindo o seu gerenciamento
de forma independente.
Camadas da MVC
A seguir, vamos ver as principais características de cada camada que
compõe a arquitetura MVC.
Model (modelo)
Controla toda a persistência do sistema.
Concentra as chamadas ao banco de dados.
Encapsula o estado do sistema.
Pode utilizar mapeamento objeto-relacional.
Padrão DAO é aplicável.
Controller (controlador)
Implementa as regras de negócio do sistema.
Solicita os dados à camada Model.
Não pode ser direcionada para uma interface.
Pode utilizar objetos distribuídos.
Padrão Facade facilita a utilização da camada.
View (visualização)
Define a interface do sistema.
Faz requisições para a camada Controller.
Contém apenas regras de formatação.
Podem ser definidas múltiplas interfaces.
Não pode acessar a camada Model.
Uma regra fundamental para a arquitetura MVC é a de que os elementos

da camada View não podem acessar a camada Model. Somente os
objetos de negócio da camada Controller podem acessar os
componentes da model, e os elementos da View devem fazer suas
requisições exclusivamente para os objetos de negócio.
A arquitetura MVC é baseada em camadas, e cada camada

enxerga apenas a camada imediatamente abaixo.
Em uma arquitetura MVC, as entidades são as unidades de informação

para o trânsito entre as camadas. Todos os comandos SQL ficam
concentrados nas classes DAO. Como apenas a camada Controller pode
acessar a Model, e nela estão as classes DAO, garantimos que as
interfaces não acessem o banco de dados diretamente.
Como as instruções SQL são bastante padronizadas, é possível criar

ferramentas para a geração dos comandos e preenchimento das
entidades, bastando expressar a relação entre atributos da entidade e
campos do registro.
A camada Controller precisa ser definida de maneira independente de

ambiente específico, como interfaces SWING ou protocolo HTTP. A
única dependência aceitável para os objetos de negócio deve ser com
relação à camada Model. Como são os modelos que gerenciam os
componentes DAO, isso diminui a complexidade nas atividades
cadastrais iniciadas na View.
Da mesma forma, a camada Controller é o melhor local para definir as

regras de autorização para o uso de funcionalidades do sistema, tendo
como base o perfil de um usuário autenticado. Com relação à
autenticação, ela pode ser iniciada por uma tela de login na camada
View, com a efetivação na camada Controller. Nos modelos atuais, é
comum a geração de um token, mantendo a independência entre as
camadas.
Atividade 3
Qual é a camada da arquitetura MVC responsável por apresentar as

informações ao usuário?
A Model.
B Controller.
C View.
D Interface.
E Camada de apresentação.
A camada de visualização (View) é responsável por apresentar as

informações ao usuário, de forma que ele possa interagir com a
aplicação. Essa camada é responsável por garantir uma interface clara
e organizada, de modo que o usuário possa entender e utilizar a
aplicação sem dificuldades.
Componentes Java para MVC

Uma grande vantagem do MVC é o direcionamento do desenvolvedor e
das ferramentas para as necessidades de cada camada. Com a divisão
funcional, foram criados diversos frameworks, como o JSF (Java Server
Faces), que define interfaces web na camada View, Spring ou EJB, para
implementar as regras de negócio da camada Controller, e Hibernate,
para a persistência ao nível da camada Model.
Neste vídeo, você verá o papel de quatro componentes Java para o

padrão MVC: JSF, Spring, EJB e Hibernate.
O uso de camadas especializadas permite a divisão da equipe entre

profissionais cujo perfil seja voltado para criação visual, negócios ou
banco de dados. Veja na imagem:
Componentes Java em cada camada do MVC.
Os frameworks facilitam a manutenção e evolução do sistema, pois

tendem a acompanhar as tecnologias que surgem ao longo do tempo,
mas apenas empresas de grande porte e comunidades de código aberto
são capazes de garantir as atualizações, não sendo raros os casos em

que uma ferramenta menos conhecida é descontinuada.
Em nosso contexto, a camada Model utiliza JPA, e como deve ser

utilizada apenas pela camada Controller, é definida no mesmo projeto
em que estão os componentes do tipo EJB. Note que a camada
Controller oferece apenas as interfaces para os EJBs, com os dados
sendo transitados na forma de entidades, sem acesso ao banco de
dados, já que anotações não são serializáveis.
Com a abordagem adotada, definimos o núcleo funcional e lógico de

nosso sistema, sem a preocupação de satisfazer a qualquer tipo de
tecnologia para construção de interfaces de usuário. A independência
do núcleo garante que ele possa ser utilizado por diversas interfaces
simultâneas, como:
SWING
HTTP
Web Services
Sem que ocorra qualquer modificação nos componentes do tipo JPA ou

EJB.
Nos sistemas Java para web, um erro comum é definir os controladores

no formato de servlets, pois as regras de negócio se confundem com as
rotinas de conversão utilizadas entre o protocolo HTTP e as estruturas
da linguagem Java. Essa abordagem errônea faz com que qualquer
nova interface, como SWING, Web Services, ou até uma linha de
comando, seja obrigada a solicitar os serviços utilizando o protocolo
HTTP, algo que, de forma geral, não é uma exigência das regras de
negócio dos sistemas.
Considere que a entidade Produto, definida anteriormente, com uso de

tecnologia JPA, seja criada no projeto ExemploEJB-ejb, no qual
codificamos nosso session bean de teste com o nome Calculadora.
Com a presença da entidade no projeto, podemos adicionar outro
session bean do tipo Stateless, com o nome ProdutoGestor e uso de
interface Local, para as operações cadastrais.
JAVA
content_copy
Repare que nossos códigos de exemplos anteriores foram aproveitados

aqui, com leves adaptações, para que as operações sejam
disponibilizadas por meio do session bean.
Precisamos adicionar o arquivo persistence.xml, definido em nosso

exemplo de JPA, ao diretório conf do projeto ExemploEJB-ejb, sem
modificações, o que levará à utilização de controle transacional de
forma local.
Com nossas camadas Model e Controller completamente codificadas,

podemos definir um Servlet, no projeto ExemploEJB-war, com o nome
ServletListaProduto, que será parte da camada View do sistema, no
modelo web. O objetivo do novo componente será a exibição da
listagem dos produtos presentes na base de dados.
JAVA
content_copy
No código, temos o atributo facade, do tipo ProdutoGestorLocal,

utilizando a anotação EJB para injetar o acesso ao pool de Session
Beans. Após configurar o acesso, invocamos o método obterTodos, na
construção da resposta ao HTTP no modo GET, aceitando uma
chamada como a apresentada a seguir.
http://localhost:8080/ExemploEJB-war/ServletListaProduto
Caso esteja tudo correto, teremos uma saída similar à que vemos a
seguir, na tela do navegador.
Saída do servlet.
Atividade 4
Em uma arquitetura MVC que utiliza componentes Java, é comum
adotar ferramentas de mapeamento objeto-relacional, como Hibernate
ou JPA, em que a persistência pode ocorrer em transições gerenciadas
via JTA, ou de forma programática. Complete as lacunas do código-
fonte a seguir, no modelo programático, com os termos corretos.
JAVA
content_copy
A EntityManagerFactory; EntityManager; persist
B EntityFactory; EntityManager; save
C Connection; Statement; execute
D Database; Entity; put
E Connection; EntityManager; execute
Um elemento essencial no JPA é a classe EntityManager, responsável

pelo manuseio das diversas entidades. Objetos dessa classe são
gerados a partir do EntityManagerFactory, e o método persist viabiliza a
gravação de uma entidade no banco de dados.
Implementação de MVC no ambiente

Java
A maioria dos sistemas possui diversas entidades de negócio que
podem se relacionar. Esse relacionamento deve ser implementado nas
camadas de banco e modelos. Contudo, esse tipo de situação costuma
extrapolar as camadas mais baixas, reverberando até nas visualizações.
Neste vídeo, você verá a implementação de um sistema simples de

gerenciamento de tarefas. Esta atividade envolve desde o registro nos
bancos de dados até a elaboração de uma visualização correspondente,
passando por criação de EJBs e modelos.
Roteiro de prática
Utilize o exemplo de sistema de produtos e adicione as camadas
correspondentes à entidade "empresa". Um produto deverá possuir a
apenas uma empresa. A empresa, por sua vez, pode possuir diversos
produtos. Para executar os novos requisitos, siga as etapas:
Criar as tabelas e inserir os dados de empresas e produtos.
Crie a entidade "empresa" a partir do banco de dados.
Desenvolva um EJB para intermediar a comunicação com o modelo

Produto.
Crie um Servlet responsável pela Listagem de produtos.
cria_registros.sql:
SQL content_copy
Produto.java
JAVA content_copy
Empresa.java
JAVA
content_copy
ProdutoGestorLocal.java
JAVA
content_copy
ProdutoGestor.java
JAVA
content_copy
ListaProduto.java
JAVA
content_copy
Faça você mesmo!

Qual das seguintes afirmações melhor descreve o trecho de código JSP
a seguir de acordo com o conceito de MVC?
JSP
content_copy
O trecho de código JSP acima representa a camada do

modelo (model) de uma aplicação em que os usuários
são renderizados em uma tabela HTML. Os dados são
A
obtidos por meio de um loop que percorre a lista de
usuários retornada pelo controlador (controller) e exibe
o nome e o e-mail de cada usuário.
O trecho de código JSP acima representa a camada de

controle (controller) de uma aplicação em que os
B usuários são listados em uma tabela HTML. Os dados
são obtidos diretamente do modelo (model) e exibidos

na interface do usuário.

visualização (view) de uma aplicação em que os
C usuários são apresentados em uma tabela HTML. Os
dados são passados diretamente pelo modelo (model)
e exibidos na interface do usuário.
O trecho de código JSP acima não está relacionado ao

D conceito de MVC e não representa nenhuma das
camadas do modelo, controle ou visualização.

modelo (model) de uma aplicação em que são
E definidos os atributos e comportamentos dos usuários.
Por meio de um loop, os usuários são iterados e suas
propriedades são renderizadas na tabela HTML.
O trecho de código JSP apresenta a estrutura da página HTML que

representa a camada de visualização (view) de uma aplicação. Utiliza a
tag '' para iterar sobre a lista de usuários (obtida do modelo) e exibe o
nome e o e-mail de cada usuário em uma tabela HTML. Portanto, a
alternativa C é a correta, pois o código JSP representa a camada de
visualização onde os dados do modelo são exibidos na interface do
usuário.
4 - Padrão Front Controller em sistemas MVC

Ao final deste módulo, você será capaz de empregar o padrão Front Controller em sistema
MVC, com interface Java Web.
Padrão Front Controller

O objetivo do padrão Front Controller é a centralização das chamadas
em um único ponto de acesso, direcionando os resultados para a
interface correta. A implementação do padrão Front Controller deve
ocorrer na camada View, pois lida apenas com conversão de formatos,
fluxo de chamadas e redirecionamentos, isolado das regras de negócio.
Neste vídeo, você verá o padrão Front Controller. Além disso, será
abordada a centralização de ações e chamadas por meio de servlets, de
forma a utilizar apenas uma classe para gerenciar as chamadas e
controlar as ações subsequentes no sistema.
Criaremos um projeto do tipo Enterprise Application, com o nome

CadastroEJB, configurando para utilização do servidor GlassFish e do
Java EE 7. Antes de iniciarmos a codificação, precisamos entender o
modelo funcional do sistema e criar as tabelas necessárias, conforme o
SQL a seguir.
SQL
content_copy
Nesse projeto, temos as tabelas EMPRESA e DEPARTAMENTO, para a

persistência de dados de um cadastro simples, com um relacionamento
por meio do campo COD_EMPRESA, da tabela DEPARTAMENTO.
Também podemos observar uma terceira tabela, com o nome SERIAIS,
que viabilizará o autoincremento, através de anotações do JPA. Para a
interface de nosso sistema, utilizaremos cinco páginas, descritas a
seguir.
index.html: página inicial do aplicativo cadastral de exemplo, com

acesso às listagens de empresas e departamentos.
ListaEmpresa.jsp: listagem das empresas e acesso às opções

oferecidas para inclusão e exclusão de empresas.
DadosEmpresa.jsp: entrada de dados da empresa que será incluída.
ListaDepartamento.jsp: listagem dos departamentos e acesso às

opções de inclusão e exclusão de departamentos.
DadosDepartamento.jsp: entrada de dados do departamento que

será incluído.
Agora, vamos definir os fluxos das chamadas, que ocorrerão a partir do

HTTP, o que pode ser representado por meio de uma Rede de Petri, uma
ferramenta que permite expressar os estados de um sistema. Ao
modelar um sistema web, os estados definem páginas e as transições
são chamadas HTTP.
Rede de Petri com as transições da aplicação.
Em nossa rede de Petri, temos as páginas dentro de figuras elípticas,

que representam os estados do sistema e as transições expressas por
meio de figuras retangulares. A alternância entre páginas, ou estados,
sempre ocorrerá com a passagem por uma transição, por meio de um
Front Controller.
Como as chamadas HTTP utilizam parâmetros, com valores do tipo

texto, vamos adotar um parâmetro para identificação da transição
requerida, no qual teremos o nome acao e o valor correspondente a um
dos valores de nosso diagrama. Podemos observar, a seguir, os valores
utilizados e operações que devem ser realizadas.
listaDep expand_more
Obter a lista de departamentos
Direcionar o fluxo para ListaDepartamento.jsp
listaEmp expand_more
Obter a lista de empresas
Direcionar o fluxo para ListaEmpresa.jsp
excDepExec expand_more
Remover o departamento, de acordo com o código

informado
Direcionar a informação para ListaDepartamento.jsp
excEmpExec expand_more
Remover a empresa, de acordo com o código informado
incDep expand_more
Direcionar o fluxo para DadosDepartamento.jsp
incDepExec expand_more
Receber os dados para inclusão do departamento
Converter para o formato de entidade
Incluir o departamento na base de dados
Direcionar o fluxo para ListaDepartamento.jsp
incEmp expand_more
Direcionar o fluxo para DadosEmpresa.jsp
incEmpExec expand_more
Receber os dados para inclusão da empresa
Converter para o formato de entidade
Incluir a empresa na base de dados
Nos aplicativos Java para Web, o padrão Front Controller pode ser
implementado com base em um servlet. O processo envolve a recepção
de uma chamada HTTP, por meio dos métodos doGet ou doPost,
execução de operações que envolvam chamadas aos EJBs,
relacionadas às atividades de consulta ou persistência, e
redirecionamento para uma página, normalmente JSP.
Atividade 1
Qual é a definição do padrão Front Controller na web?
Um padrão que define a estrutura de um banco de

A
dados.
Um padrão de design para a organização dos

B
elementos de interface do usuário.
Um padrão de projeto que centraliza o controle do fluxo

C
de requisições em uma aplicação web.
Um padrão de codificação para a formatação de

D
arquivos CSS.
Um padrão de autenticação e autorização de usuários

E
em uma aplicação web.
O padrão Front Controller centraliza o controle do fluxo das requisições

realizadas a uma aplicação, facilitando a implementação de recursos
comuns e separando a lógica de controle do restante da aplicação.
Camadas Model e Controller

Nossas camadas Model e Controller serão criadas no projeto
CadastroEJB-ejb, por meio das tecnologias JPA e EJB, iniciando com a
codificação da camada Model, baseada na tecnologia JPA.
Neste vídeo, você vai conferir as camadas Model e Controller do padrão

MVC, e verá como a camada Model gerencia dados e regras de negócio,
enquanto o Controller coordena a interação entre usuário e Model. Por
fim, acompanhe também a separação de responsabilidades e benefícios
da arquitetura MVC.
Criação da camada Model

Para a criação dessa camada, utilizaremos as ferramentas de
automação do NetBeans e, para gerar as entidades do sistema, iremos
executar os passos apresentadas a seguir:
Passo 1
Adicionar novo arquivo, escolhendo Entity Classes from Database, na
categoria Persistence.
"Wizard" de criação de arquivo do NetBeans.
Passo 2
Na configuração de Data Source, escolha New Data Source, com a

definição do nome JNDI (jdbc/cadastro), e escolha da conexão para o
banco de dados.
"Wizard" de criação de entidades do NetBeans.
Passo 3
Escolha as tabelas DEPARTAMENTO e EMPRESA, deixando marcada a
opção de inclusão das tabelas relacionadas.
"Wizard" de criação de fonte de dados do NetBeans.
Passo 4
Na tela seguinte, defina o nome do pacote como model, deixando
marcada apenas a opção de criação da unidade de persistência.
Passo 5
Escolha, ao chegar na última tela, o tipo de coleção como List, além de
desmarcar todas as opções.
Teremos a geração das entidades Departamento e Empresa, no pacote

model, embora com possíveis erros de compilação, que serão resolvidos
com o acréscimo da biblioteca Java EE 7 API ao projeto CadastroEJB-
ejb. As entidades geradas irão precisar apenas de uma pequena
modificação para configurar o uso de autoincremento.
JAVA content_copy
A anotação TableGenerator define um gerador sequencial baseado em

tabelas, sendo necessário definir a tabela que armazena os valores
(SERIAIS), o campo da tabela que individualiza o gerador
(NOME_TABELA), e o valor utilizado para o campo, sendo aqui adotado
o próprio nome da tabela para cada entidade, além do campo que irá
guardar o valor corrente para o sequencial (VALOR_CHAVE). Após definir
o gerador, temos a aplicação do valor ao campo da entidade, com base
na anotação GeneratedValue, tendo como estratégia o tipo

GenerationType.TABLE, e a relação com o gerador a partir do nome
escolhido.
Durante a execução, quando uma entidade é criada e persistida no

banco de dados, o gerador é acionado, incrementa o valor do campo
VALOR_CHAVE para a linha da tabela SERIAIS referente à entidade, e
alimenta a chave primária com o novo valor. Existem outras estratégias
de geração, como o uso de SEQUENCE, mas a adoção de uma tabela de
identificadores deixa o sistema muito mais portátil.
Criação da camada Controller

Com a camada Model pronta, vamos criar a camada Controller, usando
componentes do tipo EJB, de acordo com os seguintes passos:
Passo 1
Adicionar arquivo, escolhendo Session Beans For Entity Classes, na
categoria Persistence.
"Wizard" de criação de arquivo do NetBeans.
Passo 2
Selecionar todas as entidades do projeto.
"Wizard" de criação de beans do NetBeans.
Passo 3
Definir o nome do pacote (control), além de adotar a interface Local.
"Wizard" de criação de beans do NetBeans.
Será gerada uma classe abstrata, com o nome AbstractFacade, que

concentra todos os processos de acesso e manipulação de dados com
o uso de elementos genéricos.
JAVA
content_copy
Observe que a classe é iniciada com um construtor, onde é recebida a

classe da entidade gerenciada, e um método abstrato para retornar uma
instância de EntityManager, ao nível dos descendentes, elementos
utilizados pelos demais métodos da classe.
Métodos create, edit e remove expand_more
Esses métodos são voltados para as ações de inclusão, edição e

exclusão da entidade, são implementados por meio da
invocação dos métodos de EntityManager, semelhante aos
nossos exemplos anteriores, utilizando tecnologia JPA, bem
como find, que retorna uma entidade a partir de sua chave
primária.
Métodos findAll e findRange expand_more
Esses métodos utilizam o JPA no modo programado, com base

em CriteriaQuery, que apresenta métodos para substituir o uso
de comandos na sintaxe JPQL.
Método from expand_more
Esse método, que tem como parâmetro a classe da entidade,

combinada com o método select, permite efetuar uma consulta
que retorna todas as entidades do tipo gerenciado a partir do
banco de dados. Entretanto, em findRange, temos ainda o
recurso de paginação, com a definiçãodo índice inicial
(setFirstResult) e a quantidade de entidades (setMaxResults).
Método count expand_more
Esse método obtém a quantidade total de entidades, também

temos a adoção de CriteriaQuery, agora de uma forma mais
complexa, com a definição de um elemento Root, envolvendo o
conjunto completo de entidades, e aplicação do operador count

sobre o conjunto.
Construção dos session beans

Com a definição do modelo funcional genérico, a construção dos
session beans se torna muito simples, com base na herança e uso de
anotações.
JAVA
content_copy
Em todos os três EJBs temos o mesmo tipo de programação, nos quais

ocorre a herança com base em AbstractFacade, passando o tipo da
entidade. O método getEntityManager retorna o atributo em, e a
superclasse é chamada no construtor, com a passagem da classe da
entidade.
Os EJBs seguem o padrão Facade, e enquanto a anotação Stateless

configura a classe para se tornar um Stateless session bean, o uso da
anotação PersistenceContext, com a definição da unidade de
persistência, instancia um EntityManager no atributo em.
Ainda são necessárias as interfaces de acesso ao pool de EJBs, o que

deve ser feito sem o uso de elementos genéricos.
JAVA
content_copy
Observe que as interfaces apresentam métodos equivalentes aos que

foram definidos em AbstractFacade, mas com a especificação da
entidade, o que faz com que a herança ocorrida nos session beans
implemente as interfaces relacionadas naturalmente.
Para que o controle transacional ocorra da forma indicada, temos o

atributo transaction-type com valor JTA, no arquivo persistence.xml.
Entretanto, há uma discrepância entre o NetBeans e o GlassFish, em
termos da convenção de nomes, invalidando o identificador JNDI.
Vamos alterar o atributo jndi-name, no arquivo glassfish-resources.xml,

bem como o elemento jta-data-source, no arquivo persistence.xml,
adotando o valor jdbc/cadastro para ambos. A modificação é necessária
pelo fato do servidor GlassFish não aceitar o uso do sinal de dois
pontos no identificador JNDI.
XML
content_copy
Caso ocorra um erro na implantação mesmo após a alteração dos

arquivos, execute o programa asadmin.
Em seguida, invoque o comando add-resources, com a passagem do

nome completo do arquivo glassfish-resources.xml.
Execução de comandos no shell do asadmin.
O arquivo glassfish-resources.xml fica disponível na divisão de

configurações do projeto CadastroEJB-ejb, e foi gerado quando criamos
as entidades a partir do banco de dados.
Navegador do projeto no NetBeans.
Atividade 2
Qual é a função da camada Model e da camada Controller no padrão

MVC?
A camada Model lida com a interface do usuário,

A enquanto a camada Controller gerencia os dados e as
regras de negócio.
A camada Model gerencia os dados e as regras de

B negócio, enquanto a camada Controller lida com as
requisições do usuário.
A camada Model e a camada Controller são

C responsáveis pela manipulação dos dados e das regras
de negócio.
A camada Model cuida da lógica de apresentação,

D enquanto a camada Controller coordena as requisições
do usuário.
A camada Model e a camada Controller são sinônimos

E
e desempenham as mesmas funções no padrão MVC.
Parabéns! A alternativa B está correta.
A camada Model cuida dos dados e das regras de negócio, enquanto a

camada Controller coordena a interação do usuário com esses dados.
Camada View
A camada View no modelo MVC é responsável por apresentar as
informações aos usuários e fornecer a interface com a qual eles
interagem. É na camada View que são definidas as páginas, formulários
e elementos visuais que compõem a interface do usuário. Ela desacopla
a lógica de apresentação da lógica de negócios, permitindo a
reutilização e a manutenção separada das duas partes do sistema.
Neste vídeo, você descobrirá como a Camada View atua no processo de

interface dos usuários e interação, exibindo dados de forma
compreensível e permitindo a interação do usuário. Entenda sua
importância na arquitetura MVC.
A construção da camada View ocorrerá no projeto CadastroEJB-war, e

será iniciada com a geração das páginas JSP consideradas na Rede de
Petri do sistema, começando pela página DadosEmpresa.jsp, que não
apresenta conteúdo dinâmico.
HTML
content_copy
Observando o código-fonte, temos apenas um formulário comum, com

um parâmetro do tipo hidden guardando o valor de acao, no caso
incEmpExec, e um campo de texto para a razão social da empresa. Os
dados serão enviados para CadastroFC, um servlet no padrão Front
Controller que iremos criar posteriormente.
O cadastro de um departamento será mais complexo, pois envolverá a

escolha de uma das empresas do banco de dados. Vamos adicionar o
arquivo DadosDepartamento.jsp, com o conteúdo apresentado a seguir.
HTML/JSP
content_copy
A coleção de empresas será recuperada a partir de um atributo de

requisição, com o nome listaEmp, por meio do método getAttribute e,
com base na coleção, preenchemos as opções de uma lista de seleção
para o parâmetro cod_empresa. Os outros campos são apenas um
parâmetro do tipo hidden, definindo o valor de acao como incDepExec, e
um campo de texto para o nome do departamento.
Agora vamos criar o primeiro arquivo para listagem, com o nome

ListaEmpresa.jsp.
HTML/JSP
content_copy
A página é iniciada com a definição de um link para CadastroFC, com o

parâmetro acao contendo o valor incEmp. Em seguida, é definida uma
tabela para exibir os dados de cada empresa do banco de dados,

contendo os títulos Código, Razão Social e Opções.
Recuperamos a coleção de empresas com um atributo de requisição

com o nome lista, e preenchemos as células de cada linha da tabela a
partir dos dados da entidade, além de um link para exclusão montado
dinamicamente. Essa exclusão será efetuada com a chamada para
CadastroFC, com o valor excEmpExec no parâmetro acao e o código da
empresa corrente no parâmetro cod. Finalmente, temos a listagem de
departamentos, no arquivo ListaDepartamento.jsp.
HTML/JSP
content_copy
Em termos práticos, a listagem de departamentos é muito semelhante à

de empresas, com a definição de um link de inclusão, contando com o
valor incDep para acao e a exibição dos dados por meio de uma tabela
com os títulos Código, Nome, Empresa e Opções.
Agora, temos uma coleção de departamentos para o preenchimento das

células, e o link para exclusão faz a chamada para CadastroFC, com o
valor excDepExec no parâmetro acao e o código do departamento
corrente no parâmetro cod. Observe como a razão social da empresa é
facilmente recuperada utilizando o atributo presente na entidade
departamento, alimentado por meio de uma anotação ManyToOne. Com
a modificação de index.html, terminamos a construção das interfaces
de usuário.
HTML
content_copy
Podemos observar que os links utilizados fazem referência a

CadastroFC com os valores de acao para obtenção de listagens para as
entidades, que no caso são listaDep para departamentos e listaEmp
para empresas.
Atividade 3
Qual é a função da camada View no padrão MVC?
A camada View gerencia os dados e as regras de

A
negócio.
B A camada View coordena as requisições do usuário.
A camada View lida com a interface do usuário e a

C
apresentação dos dados.
D A camada View realiza operações de banco de dados.
A camada View atua como intermediária entre a

E
camada Model e a camada Controller.
A camada View é responsável por cuidar da interface do usuário,

exibindo os dados da camada Model de forma compreensível. Ela lida
com a apresentação visual dos dados, como a exibição de telas,
páginas web ou interfaces gráficas, permitindo a interação com o
usuário.
Implementação do Front Controller

Em Java, implementar um Front Controller permite a centralização do
processamento de todas as requisições recebidas pelo sistema. Esse
componente atua como um ponto de entrada, gerenciando as
requisições para os respectivos controladores. Assim obtemos a
modularidade, a reutilização e a facilidade de manutenção, além de
possibilitar o tratamento de tarefas comuns a todas as requisições,
como autenticação e controle de acesso.
Neste vídeo, você verá como implementar o padrão Front Controller em

Java usando o filtro. Descubra como centralizar o controle do fluxo de
requisições e executar ações comuns antes de processar as
solicitações específicas. Aprenda a otimizar o desenvolvimento de
aplicações web.
Com as interfaces concluídas, devemos iniciar a construção do Front

Controller, levando à conclusão da camada View. Utilizaremos também
um padrão Strategy, com o objetivo de segmentar as chamadas aos
EJBs, e todas as classes serão criadas no pacote view, do projeto
ExemploEJB-war.
JAVA
content_copy
Com base em uma classe abstrata e uso de elemento genérico,

definimos um padrão Strategy, em que a execução ocorrerá a partir do
valor para acao e da requisição HTTP, além de um construtor recebendo
a interface para o EJB por meio do elemento genérico.
Em seguida, definimos a estratégia para empresas, herdando da classe

Strategy, com a adoção da interface EmpresaFacadeLocal.
JAVA
content_copy
Durante a execução, temos a definição da página de destino como

ListaEmpresa.jsp, que será diferente apenas quando o parâmetro acao
tiver valor incEmp, que temos a página DadosEmpresa.jsp como
destino. O método executar irá retornar o nome da página para o Front
Controller, e ele efetuará o redirecionamento.
Além da definição da página correta, temos as operações efetuadas a

partir do atributo facade, como a remoção da entidade, quando acao
vale excEmpExec, ou a inclusão para o valor incEmpExec. Para todas as

ações que direcionam para a página de listagem, temos ainda a
definição do atributo de requisição com o nome lista, contendo a
coleção de empresas, obtida a partir do método findAll do facade,
permitindo que ocorra sua recuperação posterior, na página JSP.
Agora, podemos definir a classe DepartamentoStrategy com facade

baseado em uma interface do tipo DepartamentoFacadeLocal, e
acessando um segundo EJB por meio do atributo facadeEmpresa, do
tipo EmpresaFacadeLocal. Note que o construtor deve ser modificado
para receber as duas interfaces utilizadas.
JAVA content_copy
A estratégia para departamentos é um pouco mais complexa, o que

exige a utilização de duas interfaces para EJBs. Durante a execução,
teremos a página de destino definida como ListagemDepartamento.jsp,
a não ser para acao com valor incDep, em que a página de destino
utilizada será DadosDepartamento.jsp. Veja o passo a passo:
Passo 1
Da mesma forma que na estratégia de empresa, temos as operações
efetuadas a partir do atributo facade, como a remoção da entidade,
quando acao tem valor excDepExec, ou a inclusão para o valor
incDepExec, além da chamada para findAll para o preenchimento do
atributo lista, nas ações que direcionam para a página de listagem.
Passo 2
Também temos a utilização de facadeEmpresa para definir o atributo

listaEmp, quando acao tem valor incDep e, para recuperar a empresa
selecionada, quando acao vale incDepExec.
Passo 3
Com as estratégias definidas, podemos executar o último passo na
construção de nosso aplicativo, adicionando um servlet com o nome
CadastroFC, que será criado de acordo com o padrão Front Controller.
Faremos da seguinte forma:
JAVA
content_copy
Como toda a complexidade foi distribuída entre os descendentes de

Strategy, o servlet irá funcionar como um simples redirecionador de
fluxo. Inicialmente, temos os atributos anotados para acesso aos EJBs,
e a definição de dois HashMaps, um para armazenar as estratégias de
empresa e departamento, com o nome estrategia, e outro para
relacionar as ações do sistema com os identificadores dos gestores,
com o nome acoes.
No método init temos a inicialização de ambos os HashMaps, e

consequente criação das instâncias para os elementos Strategy. Note
que as ações são facilmente relacionadas com o identificador de
estratégia, apoiadas no uso de vetores de texto.
Agora, com o aplicativo completo, podemos executá-lo, testando a

inclusão e a listagem, tanto para empresas quanto para departamentos.
Algumas das telas de nosso sistema podem ser observadas a seguir.
Tela inicial da aplicação.
Temos a tela de cadastro:
Tela de cadastro de empresas.
Temos a tela de listagem:
Tela listagem de empresas.
Atividade 4
Como o padrão Strategy é utilizado na implementação do Front

Controller em Java?
O padrão Strategy é responsável por gerenciar a

A
interação entre a camada View e a camada Model.
O padrão Strategy é utilizado para implementar a lógica

de controle na camada View.
O padrão Strategy permite que diferentes algoritmos de

C controle sejam encapsulados em classes separadas e
selecionados dinamicamente durante a execução.
O padrão Strategy é utilizado para encapsular as regras

D
de negócio na camada Model.
O padrão Strategy é responsável por interceptar e

E manipular as requisições do usuário na camada
Controller.
O padrão Strategy é utilizado na implementação do Front Controller em

Java para permitir a seleção dinâmica de abordagens para o
tratamento das requisições.
Aplicação MVC com padrão Front

Controller
O exercício que veremos no roteiro de prática a seguir permitirá que
você aplique os conceitos do padrão Front Controller e do padrão MVC
na implementação de uma aplicação web em Java. Lembre-se de seguir
as boas práticas de programação e a separação de responsabilidades
entre as camadas Model, View e Controller.
Neste vídeo, você verá como implementar o padrão Front Controller

utilizando filtro no Java, centralizar o controle das requisições, direcioná-
las para os controladores apropriados e retornar as respostas corretas.
Uma abordagem prática e eficiente para o desenvolvimento de
aplicações web.
Roteiro de prática
Vamos simular a criação de uma aplicação web simples para uma
livraria on-line. Seu objetivo é implementar o padrão Front Controller e o
padrão MVC para essa aplicação. Para isso, é necessário seguir
algumas etapas:
1. Implemente a camada de modelo utilizando ejbs. Para simplificar,

utilize uma coleção de livros estática no método "findAll".
2. Crie as seguintes classes:
FrontController: classe responsável por receber todas as

requisições e direcioná-las para o controlador apropriado.
Controller: interface que define os métodos que os

controladores devem implementar.
HomeController: controlador responsável por lidar com as

requisições relacionadas à página inicial.
BookController: controlador responsável por lidar com as

requisições relacionadas aos livros.
3. Defina as possíveis ações da aplicação no Front Controller,

mapeando as ações para os controladores adequados. Por
exemplo:
"acao=welcome": direciona para o HomeController.
Rota " acao=books": direciona para o BookController.
4. Implemente as classes Controller (HomeController e

BookController) de acordo com a interface Controller, definindo os
métodos necessários para lidar com as requisições.
5. Teste sua implementação chamando os seguintes endereços:

http://localhost:8080/EnterpriseApplication1-war/FrontController?
acao=welcome
http://localhost:8080/EnterpriseApplication1-war/FrontController?
acao=books
Classe FrontController:
JAVA content_copy
Interface Controller:
JAVA
content_copy
Classe HomeController:
JAVA
content_copy
Classe BookController:
JAVA
content_copy
Classe Book
JAVA content_copy
Faça você mesmo!

Qual das seguintes afirmações melhor descreve o trecho de código Java
a seguir de acordo com o padrão Front Controller?
JAVA content_copy
O trecho de código implementa o Front Controller, que é

responsável por autenticar o usuário antes de
redirecionar a requisição para o respectivo controlador
A específico. Se o usuário estiver autenticado, a
requisição é encaminhada para o dispatcher. Caso
contrário, o usuário é redirecionado para a página de
login.
O trecho de código implementa o Front Controller, que é

responsável por encaminhar a requisição para o
controlador adequado. Se o usuário estiver autenticado,
B
a requisição é enviada diretamente para o controlador
correspondente. Caso contrário, a requisição é
redirecionada para a página de login.
O trecho de código implementa um controlador

específico responsável por verificar se o usuário está
C autenticado. Caso esteja autenticado, a requisição é
encaminhada para o dispatcher. Caso contrário, o
usuário é redirecionado para a página de login.
O trecho de código implementa uma função

intermediária que verifica se o usuário está autenticado
antes de redirecionar a requisição para o controlador
D adequado. Se o usuário estiver autenticado, a
requisição é enviada diretamente para o controlador
correspondente. Caso contrário, a requisição é
redirecionada para a página de login.
O trecho de código não está relacionado ao conceito de

E Front Controller, pois apenas redireciona o usuário para
a página de login caso ele não esteja autenticado.
O trecho de código implementa o padrão Front Controller, que é

responsável por controlar o fluxo de requisições, realizar autenticação
e direcionar a requisição para o controlador apropriado. Nesse caso, o
método handleRequest do Front Controller verifica se o usuário está

autenticado utilizando o método isAuthenticated. Se o usuário estiver
autenticado, a requisição é encaminhada para o dispatcher por meio do
método dispatch. Caso contrário, o usuário é redirecionado para a
página de login.
O que você aprendeu neste

conteúdo?
Utilização da Java Persistence API
Ecossistema Java EE
Estrutura de um aplicativo corporativo
Utilização de Enterprise Java Beans
Arquitetura MVC (Model-View-Controller)
Arquitetura MVC (Model-View-Controller)
Explore +
Leia o artigo da Oracle comparando Entity Beans CMP e JPA. Disponível
na página da Oracle.
Leia o tutorial de Java Persistence API, disponível na página Vogella
Pesquise a documentação da Oracle sobre componentes do tipo EJB.
Pesquise a documentação interativa acerca de padrões de

desenvolvimento, disponível na página Refactoring Guru.
O EclipseLink está disponível para download na página da Eclipse

Foundation.
Referências
CASSATI, J. P. Programação Servidor em Sistemas Web. Rio de Janeiro:
Estácio, 2016.
CORNELL, G.; HORSTMANN, C. Core JAVA. 8ª ed. São Paulo: Pearson,

2010.
DEITEL, P.; DEITEL, H. AJAX, Rich Internet Applications e

Desenvolvimento Web para Programadores. São Paulo: Pearson
Education, 2009.
DEITEL, P.; DEITEL, H. JAVA, Como Programar. 8ª ed. São Paulo:

Pearson, 2010.
FONSECA, E. Desenvolvimento de Software. Rio de Janeiro: Estácio,

2015.
MONSON-HAEFEL, R.; BURKE, B. Enterprise Java Beans 3.0. 5ª ed. USA:

O’Reilly, 2006.
SANTOS, F. Programação I. Rio de Janeiro: Estácio, 2017.
Material para download

Clique no botão abaixo para fazer o download do
conteúdo completo em formato PDF.
Download material
O que você achou do conteúdo?
Relatar problema

Tecnologias JPA e JEE

Enviado por

Direitos autorais:

Formatos disponíveis

Tecnologias JPA e JEE

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Tecnologias JPA e JEE

Enviado por

Direitos autorais:

Formatos disponíveis

04/06/2024, 12:07 Tecnologias JPA e JEE

Tecnologias JPA e JEE

Você vai compreender a utilização de tecnologias JPA (Java Persistence

Antes de iniciar seus estudos, é necessário configurar o ambiente, com

JPA no desenvolvimento web

Descrever as características do JPA.

Implementação de regras de negócio com

Empregar componentes EJB na construção de regras de negócio.

Arquitetura MVC no Java

Padrão Front Controller em sistemas MVC

Empregar o padrão Front Controller em sistema MVC, com interface

Neste conteúdo, abordaremos a tecnologia JPA (Java

Após compreender ambas as tecnologias, analisaremos os

Neste vídeo você verá os principais tópicos do nosso estudo

Material para download

1 - JPA no desenvolvimento web

Neste vídeo, você verá o que é o mapeamento objeto-relacional e como

Temos, então, duas filosofias distintas. Como o ambiente de

e objetos. Essa abordagem fica clara quando utilizamos o padrão de

ORM (mapeamento objeto-relacional)

Com base nas configurações, que indicam a relação entre atributos da

No fragmento de código, temos o início da definição de um entity bean,

Para o Hibernate, as entidades são apenas classes comuns, sem

Com o XML, temos um modelo documental para o mapeamento,

O uso de mapeamento objeto-relacional se tornou uma necessidade

temos os entity beans, do J2EE, baseado no padrão de

Parabéns! A alternativa A está correta.

Ao utilizar os Entity Beans, que operam de acordo com o padrão Active

Java Persistence API

Neste vídeo, você vai conferir o Java Persistence API (JPA), um

A JPA tem o padrão DAO implícito, o que traz grande eficiência na

Definindo uma entidade JPA

A anotação Entity define a classe Produto como uma entidade para o

Vejamos, a seguir, as principais anotações do JPA.

Entity: marca a classe como uma entidade para o JPA.

Table: especifica a tabela que será utilizada no mapeamento.

Column: mapeia o atributo para o campo da tabela.

Id: especifica o atributo mapeado para a chave primária.

Basic: define a obrigatoriedade do campo ou o modo utilizado para

OneToMany: mapeia a relação 1XN do lado da entidade principal

ManyToOne: mapeia a relação 1XN do lado da entidade

OneToOne: mapeia o relacionamento 1X1 com atributos de

ManyToMany: mapeia o relacionamento NXN com atributos de

OrderBy: define a regra que será adotada para ordenar a coleção.

JoinColumn: especifica a regra de relacionamento da chave

As entidades JPA devem conter um construtor vazio e um outro

Ainda precisamos do atributo serialVersionUID, referente à versão da

Além das anotações nas entidades, precisamos configurar o arquivo

A primeira informação relevante é o nome da unidade de persistência

O controle transacional pode ocorrer a partir de um gestor próprio, para

Utiliza o gestor de Ativa a integração com

Em seguida, definimos o provedor de persistência no elemento provider.

Qual é o objetivo principal da Java Persistence API (JPA)?

Simplificar o desenvolvimento de interfaces gráficas

Fornecer uma API para criação de serviços web em

Padronizar o desenvolvimento de aplicações Java que

Gerenciar a camada de apresentação em aplicações

E Implementar a lógica de negócio em aplicações Java.

Parabéns! A alternativa C está correta.

A JPA padroniza o desenvolvimento de aplicações Java que utilizam