Programação para Web II

Programação para Web II
Prof. Cristiano Roberto Franco
2016
Copyright © UNIASSELVI 2016
Elaboração:
Revisão, Diagramação e Produção:

Centro Universitário Leonardo da Vinci – UNIASSELVI
Ficha catalográfica elaborada na fonte pela Biblioteca Dante Alighieri

UNIASSELVI – Indaial.
005.276
F825p Franco, Cristiano Roberto
Programação Web II / Cristiano Roberto Franco. Indaial :

UNIASSELVI, 2016.
192 p. : il.
ISBN 978-85-7830-950-3
1.Programação para internet.

I. Centro Universitário Leonardo Da Vinci.
Impresso por:
Apresentação
O mundo mudou! Enquanto você lê esse texto, muito provavelmente
na tela de seu computador desktop, notebook ou dispositivo móvel, milhões de
pessoas ao redor do globo estão trafegando dados digitalmente transformados
na autoestrada da informação conhecida como internet. Você não usa mais
essa autoestrada somente para estudar e trabalhar, você a usa para comprar,
viajar, ouvir música, ver TV, filmes e seriados, fazer operações bancárias,
pagar contas, falar com amigos e familiares distantes, namorar e até mesmo
para compartilhar com o mundo que você fez uma omelete no café da manhã.
E você quer poder fazer tudo isso a qualquer hora e de qualquer lugar.
Tamanha conectividade é possível, mas não vem de graça. Ela cobra

um preço caro. Além de antenas, redes, roteadores e demais dispositivos
físicos (que não são o objeto desta disciplina e por isso não serão abordados),
você precisa de software que possa atender a essa demanda voraz por
informação. E não é qualquer software... conforme a lei de Moore vai
chegando ao seu limite, decidimos por outras estratégias para ampliar o
desempenho dos computadores e consequentemente do software que executa
neles. Processadores multicores, virtualização, computação em grid e cloud
são apenas alguns dos artifícios que usamos para garantir o desempenho das
aplicações. Porque no final das contas, sempre que você compra, viaja, ouve
música, vê TV, filmes e seriados e compartilha com o mundo que fez uma
omelete no café da manhã, você o faz através de uma aplicação.
É nesse contexto que atua a tecnologia que estudaremos nesta disciplina.

A plataforma Java nos apresenta o Java Enterprise Edition (JEE), especialmente
desenvolvido e planejado para ambientes com grande demanda por desempenho
e robustez. É a mesma tecnologia que dá vazão a alguns dos serviços mais
conhecidos e utilizados da internet, como Twitter, Linkedin e Netflix. Destaque
especial para o fato de que, em momentos de pico, o Netflix concentra 37% de
todo o tráfego de internet da América do Norte (TODD, 2015).
Conforme Evans et al. (2011), os desenvolvedores de software

reconhecem cada vez mais a necessidade de aplicações que sejam distribuídas,
transacionais, portáveis e que permitam alavancar o desempenho, segurança e
confiabilidade das tecnologias server-side. Para atender à crescente demanda, as
tecnologias devem permitir que estas aplicações sejam projetadas e construídas
mais rapidamente, com menos recursos computacionais e menor custo. Parece
inacreditável, mas não... é simplesmente a evolução de uma tecnologia aberta
que já existe há aproximadamente 20 anos e que conta com o feedback intenso
do Java Community Process para definir seus rumos e roadmap.
III
Apesar de o JEE ter como um dos focos principais a facilidade de
desenvolvimento, a complexidade intrínseca do ambiente para o qual foi
projetado e o número de tecnologias envolvidas o tornam relativamente
denso. Tenha em mente que você não está estudando uma tecnologia para
fazer um “sitezinho para seu tio que tem uma quitanda”, mas sim para
construir aplicações distribuídas, robustas, portáveis e seguras.
Lembre-se de que você não está sozinho nesta jornada. O meu trabalho
ao longo deste caderno é tentar facilitar ao máximo a compreensão das
tecnologias envolvidas no JEE. Para atingir tal objetivo, farei uso de exemplos
pequenos e simples na demonstração de cada tecnologia, combinando-os em
um exemplo maior e mais complexo como autoatividade no final de cada
seção. Tal metodologia de ensino e aprendizagem é sugerida por Nicholas
Negroponte do MIT Media Lab, em seu artigo Learning by Doing: Don´t
dissect the frog. Built it (NEGROPONTE, 2004).
Aproveito esse momento para destacar que os exercícios NÃO SÃO

OPCIONAIS. O objetivo de cada exercício deste caderno é a fixação de
determinado conceito através da prática. É aí que reside a importância da
realização de todos. Sugerimos fortemente que em caso de dúvida em algum
exercício você entre em contato com seu tutor externo ou com a tutoria da
Uniasselvi e que não passe para o exercício seguinte enquanto o atual não
estiver completamente compreendido. Aprender a programar utilizando a
tecnologia JEE sem exercitar os conceitos de forma prática, somente com a
leitura do caderno, é equivalente a ir a um restaurante e tentar matar a fome
lendo o cardápio. Instruções detalhadas de como preparar o ambiente para
a resolução dos exercícios em seu computador são mostrados na Unidade 1.
Você precisará de muita determinação e força de vontade, pois o

conteúdo abordado neste caderno não é fácil e você levará mais do que um
semestre para compreendê-lo totalmente, entretanto, aqui forneceremos um
início sólido e consistente. Desta forma, passe por esse período de estudos
com muita dedicação, pois você que hoje é acadêmico(a), amanhã será um
profissional de Tecnologia da Informação com o compromisso de construir
uma nação melhor.
Lembre-se de que o encantamento com a programação deriva do

seu entendimento; a beleza desta área do conhecimento é a compreensão da
lógica envolvida na construção de programas. Por isso, bons programadores
são apaixonados por linguagens de programação e ambientes de
desenvolvimento e estão sempre buscando novos conhecimentos. Como
disse Drew Houston, criador do DropBox: “Programar é a coisa mais
parecida que temos com superpoderes”.
Bons códigos!
IV
NOTA
Você já me conhece das outras disciplinas? Não? É calouro? Enfim, tanto para
você que está chegando agora à UNIASSELVI quanto para você que já é veterano, há
novidades em nosso material.
Na Educação a Distância, o livro impresso, entregue a todos os acadêmicos desde 2005, é

o material base da disciplina. A partir de 2017, nossos livros estão de visual novo, com um
formato mais prático, que cabe na bolsa e facilita a leitura.
O conteúdo continua na íntegra, mas a estrutura interna foi aperfeiçoada com nova
diagramação no texto, aproveitando ao máximo o espaço da página, o que também
contribui para diminuir a extração de árvores para produção de folhas de papel, por exemplo.
Assim, a UNIASSELVI, preocupando-se com o impacto de nossas ações sobre o ambiente,

apresenta também este livro no formato digital. Assim, você, acadêmico, tem a possibilidade
de estudá-lo com versatilidade nas telas do celular, tablet ou computador.

Eu mesmo, UNI, ganhei um novo layout, você me verá frequentemente e surgirei para
apresentar dicas de vídeos e outras fontes de conhecimento que complementam o assunto
em questão.
Todos esses ajustes foram pensados a partir de relatos que recebemos nas pesquisas
institucionais sobre os materiais impressos, para que você, nossa maior prioridade, possa
continuar seus estudos com um material de qualidade.
Aproveito o momento para convidá-lo para um bate-papo sobre o Exame Nacional de

Desempenho de Estudantes – ENADE.

Bons estudos!
V
VI
Sumário
UNIDADE 1 – INTRODUÇÃO AO JAVA ENTERPRISE EDITION................................................ 1
TÓPICO 1 – INTRODUÇÃO AO JAVA ENTERPRISE EDITION E PRINCIPAIS

TECNOLOGIAS................................................................................................................. 3
1 INTRODUÇÃO...................................................................................................................................... 3
2 PRINCIPAIS TECNOLOGIAS............................................................................................................ 7
2.1 A ARQUITETURA DOS CONTAINERS....................................................................................... 9
RESUMO DO TÓPICO 1........................................................................................................................ 11
AUTOATIVIDADE.................................................................................................................................. 12
TÓPICO 2 – CONSTRUÇÃO DO AMBIENTE DE DESENVOLVIMENTO E EPLOYMENT..... 13

1 INTRODUÇÃO...................................................................................................................................... 13
1.1 INSTALAÇÃO DO SERVIDOR DE APLICAÇÃO – WILDFLY................................................. 13
2 INSTALAÇÃO DO NETBEANS......................................................................................................... 19
3 INTEGRAÇÃO WILDFLY-MYSQL.................................................................................................... 22
4 INTEGRAÇÃO GLASSFISH-MYSQL................................................................................................ 26
RESUMO DO TÓPICO 2........................................................................................................................ 34
AUTOATIVIDADE.................................................................................................................................. 35
TÓPICO 3 – JAVA SERVER FACES (JSF)............................................................................................ 37

1 INTRODUÇÃO...................................................................................................................................... 37
2 CRIAÇÃO DA PRIMEIRA APLICAÇÃO......................................................................................... 39
3 CICLO DE VIDA E ESCOPOS DO JSF............................................................................................. 46
LEITURA COMPLEMENTAR................................................................................................................ 53
RESUMO DO TÓPICO 3........................................................................................................................ 57
AUTOATIVIDADE.................................................................................................................................. 58
UNIDADE 2 – COMPONENTES GRÁFICOS DO JAVA SERVER FACES E JAVA

PERSISTENCE API........................................................................................................ 59
TÓPICO 1 – COMPONENTES GRÁFICOS DO JAVA SERVER FACES........................................ 61

1 INTRODUÇÃO...................................................................................................................................... 61
2 COMPONENTES DE FORMULÁRIO.............................................................................................. 61
3 TABELAS................................................................................................................................................. 73
4 SUPORTE NATIVO A AJAX............................................................................................................... 78
5 ADICIONANDO UMA BIBLIOTECA EXTERNA DE COMPONENTES VISUAIS............... 80
RESUMO DO TÓPICO 1........................................................................................................................ 90
AUTOATIVIDADE.................................................................................................................................. 91
TÓPICO 2 – JAVA PERSISTENCE API................................................................................................ 93

1 INTRODUÇÃO...................................................................................................................................... 93
2 MAPEAMENTO OBJETO RELACIONAL....................................................................................... 94
2.1 ARQUITETURA DO DATA ACCESS OBJECT............................................................................. 96
VII
3 JAVA PERSISTENCE API (JPA).......................................................................................................... 98
4 CONCEITOS E INTERFACES DO JPA............................................................................................. 99
4.1 MAPEAMENTO DE ENTIDADES.............................................................................................. 100
4.2 RELACIONAMENTOS ENTRE ENTIDADES........................................................................... 111
LEITURA COMPLEMENTAR.............................................................................................................. 114
RESUMO DO TÓPICO 2...................................................................................................................... 125
AUTOATIVIDADE................................................................................................................................ 127
UNIDADE 3 – ENTERPRISE JAVA BEANS (EJB) E CONTEXT AND DEPENDENCY

INJECTION (CDI)......................................................................................................... 129
TÓPICO 1 – STATELESS SESSION BEANS..................................................................................... 131

1 INTRODUÇÃO.................................................................................................................................... 131
2 STATELESS SESSION BEANS............................................................................................................ 132
2.1 EJB 3.0............................................................................................................................................... 132
2.2 EJB 3.1............................................................................................................................................... 134
2.3 TESTANDO O EJB.......................................................................................................................... 135
2.4 CICLO DE VIDA............................................................................................................................. 138
2.5 ESCALABILIDADE, POOL E CALL-BACKS.............................................................................. 139
2.6 MÉTODOS ASSÍNCRONOS......................................................................................................... 140
RESUMO DO TÓPICO 1...................................................................................................................... 142
AUTOATIVIDADE................................................................................................................................ 143
TÓPICO 2 – STATEFUL SESSION BEAN E SINGLETON SESSION BEANS............................... 145

1 INTRODUÇÃO.................................................................................................................................... 145
2 STATEFULL SESSION BEANS 3.0..................................................................................................... 146
3 STATEFULL SESSION BEANS 3.1................................................................................................... 147
3.1 CICLO DE VIDA DOS STATEFULL SESSION BEANS............................................................. 147
3.2 CALLBACKS.................................................................................................................................... 150
4 SINGLETON SESSION BEANS......................................................................................................... 150
4.1 CICLO DE VIDA.............................................................................................................................152
RESUMO DO TÓPICO 2......................................................................................................................154
AUTOATIVIDADE................................................................................................................................155
TÓPICO 3 – CONTEXT AND DEPENDENCY INJECTION............................................................157

1 INTRODUÇÃO....................................................................................................................................157
2 PRODUCER METHODS E ATTRIBUTES........................................................................................158
3 EXPRESSION LANGUAGE (EL) NAME..........................................................................................159
4 ESCOPOS E CONTEXTOS................................................................................................................160
RESUMO DO TÓPICO 3......................................................................................................................162
AUTOATIVIDADE................................................................................................................................163
TÓPICO 4 – JAVA MESSAGE SERVICE (JMS)............................................................................... 165

1 INTRODUÇÃO ...................................................................................................................................165
2 FILAS E TÓPICOS ..............................................................................................................................165
3 MODOS DE RECEBIMENTO......................................................................................................169
LEITURA COMPLEMENTAR .............................................................................................................173
RESUMO DO TÓPICO 4...................................................................................................................... 183
AUTOATIVIDADE................................................................................................................................ 184
REFERÊNCIAS........................................................................................................................................ 185
VIII
UNIDADE 1
INTRODUÇÃO AO JAVA
ENTERPRISE EDITION
OBJETIVOS DE APRENDIZAGEM
Ao final desta unidade, você será capaz de:
• identificar e descrever algumas das tecnologias que fazem parte da

especificação JEE;
• identificar quais tipos de situações e ambientes são mais adequados para

a utilização de tais tecnologias;
• montar um ambiente de desenvolvimento e deployment de aplicações

JEE usando a IDE Eclipse e o Servidor de Aplicações WildFly.
PLANO DE ESTUDOS
Esta unidade de ensino está dividida em três tópicos, sendo que no final
de cada um deles, você encontrará atividades que contribuirão para a
apropriação dos conteúdos.
TÓPICO 1 – INTRODUÇÃO AO JAVA ENTERPRISE EDITION E

PRINCIPAIS TECNOLOGIAS
TÓPICO 2 – CONSTRUÇÃO DO AMBIENTE DE DESENVOLVIMENTO E

DEPLOYMENT
TÓPICO 3 – JAVA SERVER FACES (JSF)
1
2
UNIDADE 1
TÓPICO 1
INTRODUÇÃO AO JAVA ENTERPRISE EDITION

E PRINCIPAIS TECNOLOGIAS
1 INTRODUÇÃO
O Java Enterprise Edition (JEE) inicialmente evoluiu como uma plataforma
de desenvolvimento para aplicações enterprise que focava em robustez,
webservices e facilidade. Continuamente moldado através do feedback fornecido
pelo Java Community Process (JCP), o JEE hoje representa um padrão universal
para TI empresarial, facilitando o desenvolvimento, instalação e gerenciamento
de aplicações multi-tier e server-centric. O sucesso na adoção da plataforma é
inegável. Em maio de 2013, os componentes JEE6 da Oracle e outros fornecedores
já contabilizavam 50 milhões de downloads (ORACLE, 2014).
E
IMPORTANT
O JCP é o mecanismo através do qual são definidas as especificações técnicas

para a tecnologia Java. Ele é aberto para a participação de qualquer pessoa. Maiores detalhes
em: <https://www.jcp.org/>.
Conforme Evans et al. (2011), o modelo de aplicação do JEE começa

com a linguagem de programação Java e a Java Virtual Machine. A já conhecida e
comprovada portabilidade, segurança e produtividade no desenvolvimento que
ela oferece formam a base deste modelo.
A plataforma JEE é projetada para suportar aplicações que possuem

elevado grau de complexidade, acessando dados das mais variadas fontes e
atendendo a um grande número de clientes e requisições. Sua arquitetura facilita
o gerenciamento da escalabilidade, pré-requisito para ambientes corporativos de
alto desempenho. Esta arquitetura divide o trabalho em duas partes:
1) A lógica de negócio e apresentação: implementadas pelo desenvolvedor.

2) Os serviços-padrão que tais aplicações necessitam: ofertadas pela plataforma
JEE através do servidor de aplicações.
3
UNIDADE 1 | INTRODUÇÃO AO JAVA ENTERPRISE EDITION
A Figura 1 apresenta uma arquitetura JEE típica:
FIGURA 1 - ARQUITURA JEE TÍPICA
FONTE: Evans et al. (2011)
Para compreender a figura, inicialmente é necessária a compreensão do

conceito de tier (camada lógica) e de layer (camada física). Tanto a tier quanto a
layer podem ser definidas como um conjunto de tecnologias que representa um
conceito que faz parte da aplicação. A tier é sempre composta por software, ou
seja, é lógica. A layer é sempre composta por hardware, ou seja, é física. No caso
da figura, temos quatro tiers e três layers:
1) Client Tier: representa a camada cliente, ou seja, o que os usuários efetivamente

acessam da aplicação. Perceba que a figura a define com duas tecnologias:
a aplicação cliente, normalmente uma aplicação desktop desenvolvida com
Swing ou JavaFX, e as páginas web, acessadas através de um navegador. Ambas
as tecnologias estão no layer representado pela máquina do usuário, ou seja, o
computador onde ele acessa a aplicação.
2) Web Tier: representa a camada responsável por fazer a ligação entre as páginas
web e a lógica de negócio, representada aqui pela tecnologia Java Server Faces
(JSF). Em alguns casos, esta camada é dispensável. Perceba que na figura,
as aplicações clientes acessam a lógica de negócio diretamente, sem esse
intermédio. Esta camada poderia ainda ser representada por tecnologias como
4
TÓPICO 1 | INTRODUÇÃO AO JAVA ENTERPRISE EDITION E PRINCIPAIS TECNOLOGIAS
Servlets e Java Server Pages, que não fazem parte do escopo deste caderno. Se
considerarmos a layer, esta parte fica alocada no JEEServer.
3) Business Tier: representa a lógica de negócios da aplicação, aqui implementada
em Enterprise Beans individuais para a aplicação cliente e para as páginas web.
Em termos de layer, ainda estamos no JEEServer.
4) Enterprise Information Server (EIS) Tier: representa as fontes de dados que as
aplicações acessam através da business tier, normalmente um SGBDR. Esta fonte
de dados também pode ser alguma aplicação legada já existente no ambiente
corporativo. Agora estamos na layer Database Server.
É importante mencionar alguns detalhes a respeito destas definições. A

Web Tier pode ser implementada em Servlet Containers, que são uma espécie de
“mini” servidores de aplicação mais leves e ágeis, entretanto não disponibilizam
todos os serviços dos servidores de aplicação. O Apache Tomcat é um exemplo de
Servlet Container. Em muitas situações, é mais produtivo desenvolver aplicações
somente com Servlet Containers, colocando a lógica de negócio em Plain Old Java
Objects (POJOs) do que acrescentar o peso de um servidor de aplicação com
Enterprise Beans. É por este motivo que a layer JEEServer é dividida em Web Tier e
Business Tier. Cada caso é um caso e deve ser avaliado pesando os prós e contras
de cada tecnologia. É o eterno tradeoff da arquitetura de software.
Outro detalhe importante é que as layers, com exceção da Client Machine,

podem ser todas implementadas em uma única camada física. É possível colocar
o JEEServer (com ou sem Web Tier) e o DataBase Server em um único computador,
embora isso não seja recomendado.
A grande premissa por trás do JEE é que o desenvolvedor pode confiar na

plataforma para facilitar a implementação destes serviços-padrão, normalmente
representados por requisitos não funcionais. Como tudo na plataforma Java, o JEE
é simplesmente uma especificação, ou seja, definições e documentos descrevendo
como a tecnologia deve se comportar, além de padrões que devem ser obedecidos
no desenvolvimento, definidos através do JCP.
No caso do JEE, um dos componentes principais (se não o principal) é o

servidor de aplicação. É este servidor de aplicação que encapsulará internamente
os serviços que a plataforma oferece. Cabe ao desenvolvedor utilizá-los através
das tecnologias definidas para tal. Como exemplos de implementações desta
especificação podemos citar o Jboss, o WildFly e o GlassFish.
E
IMPORTANT
O Swing e o JavaFX são tecnologias definidas pela Oracle para a criação de

interfaces em aplicações Desktop. Maiores detalhes podem ser encontrados em: <http://
docs.oracle.com/javase/8/javase-clienttechnologies.htm>.
5
Mas que serviços são estes? Com o advento e popularização da internet

e das tecnologias móveis, o número de usuários aumentou exponencialmente.
Para atender à estas demandas, diversos requisitos não funcionais passaram
a ter uma importância ainda maior para estas aplicações. Termos como
escalabilidade, segurança, gerenciamento do ciclo de vida de objetos,
remotabilidade, controle de transações, entre outros, vieram a fazer parte do
dia a dia dos desenvolvedores. Ou seja, se transformaram em preocupações
para os desenvolvedores, que agora não escrevem código somente para lidar
com a lógica de negócios e os requisitos funcionais.
Algumas das tecnologias disponibilizadas pelo JEE permitem que o

desenvolvedor simplesmente sinalize em seu código aspectos relacionados à
segurança, remotabilidade, transações etc., e o servidor de aplicações faz todo o
resto. Isto libera o desenvolvedor para fazer mais o que realmente é importante:
escrever código relacionado às necessidades do usuário e a lógica do negócio.
De acordo com ORACLE (2013), o modelo simplificado de programação

do JEE faz com que os descritores de deployment em XML sejam opcionais. Ao
invés disso, o desenvolvedor pode colocar uma informação diretamente no
código fonte através das annotations e o servidor irá configurar o componente em
tempo de execução. Estas annotations em geral servem para embutir no programa
dados que serial de outra forma fornecidos em um deployment descriptor. Com as
annotations, você pode colocar a especificação do serviço do servidor ao lado do
código que será afetado por ele.
Abaixo estão listados alguns dos serviços disponibilizados pelas

tecnologias envolvidas na plataforma K19 (2013).
• Transações: A arquitetura Enterprise Java Beans (EJB) define um suporte sofisticado

para utilização de transações. Esse suporte é integrado com a Java Transaction
API (JTA) e oferece inclusive a possibilidade de realizar transações distribuídas.
• Segurança: Suporte para realizar autenticação e autorização de forma
transparente. Os desenvolvedores das aplicações não precisam implementar a
lógica de segurança, pois ela faz parte da arquitetura JEE.
• Remotabilidade: Aplicações JEE podem ser acessadas remotamente através
de diversos protocolos de comunicação. Consequentemente, é possível
desenvolver aplicações clientes de diversos tipos. Por exemplo, aplicações EJB
podem ser acessadas como Web Services.
• Multithreading e Concorrência: A arquitetura JEE permite que as aplicações
sejam acessadas por múltiplos usuários simultaneamente de maneira
controlada para evitar problemas de concorrência.
• Persistência: Facilidades para utilizar os serviços dos provedores de persistência
que seguem a especificação JPA.
• Gerenciamento de Objetos: Mecanismos de injeção de dependências e controle
de ciclo de vida são oferecidos aos objetos de uma aplicação JEE. O mecanismo
de controle de ciclo de vida pode garantir a escalabilidade de uma aplicação.
6
• Integração: A arquitetura EJB é fortemente integrada com os componentes da

plataforma Java EE. Podemos, por exemplo, facilmente integrar os recursos do
JSF em uma aplicação EJB.
E
IMPORTANT
Os enterprise java beans, conhecidos como EJBs fazem parte da especificação

JEE e fornecem boa parte dos serviços da plataforma. Estudaremos detalhadamente esta
tecnologia na Unidade 3 deste Caderno de Estudos.
2 PRINCIPAIS TECNOLOGIAS
Como descrevemos anteriormente, o servidor de aplicação JEE tem
como principal característica o oferecimento de serviços para as aplicações nele
instalados. Serviços estes geralmente relacionados com requisitos não funcionais
como escalabilidade, remotabilidade etc. Para cada um destes serviços existe uma
ou mais tecnologias que, trabalhando individualmente ou em conjunto, abstraem o
desenvolvedor de detalhes específicos da implementação do mesmo.
A seguir faremos uma rápida introdução às principais tecnologias que

compõem o JEE, conforme definido em ORACLE (2014), destacando as que serão
abordadas neste Caderno de Estudos.
Componentes JEE: As aplicações JEE são feitas de componentes. Estes

componentes são unidades encapsuladas de software funcionais que fazem parte
das aplicações. Cada componente possui suas próprias classes e arquivos e se
comunica com outros componentes. A especificação JEE define os seguintes
componentes:
• Aplicação cliente e applets que executam no cliente.

• Servlets, Java Server Faces e Java Server Pages como componentes que executam
no servidor.
• Enterprise Java Beans, como componentes de negócio que executam no servidor.
Todos estes componentes são escritos na linguagem de programação Java

e compilados da mesma forma como qualquer outro programa. A diferença é
que estes componentes são “embutidos” dentro de aplicações que obedecem às
especificações JEE e são, portanto, gerenciadas pelo servidor de aplicação.
7
Java Server Faces (JSF): É um framework para a construção de aplicações

web. Permite a utilização de classes Java como implementações de componentes
HTML. Oferece validação de entrada, gerenciamento de eventos, conversão de
dados entre componentes e objetos de domínio, configuração de navegação,
controle do ciclo de vida dos objetos e a expression language (EL), que permite que
componentes da interface gráfica conversem diretamente com o controlador.
Java Persistence API (JPA): Apresenta uma solução para a persistência

de objetos em ambientes relacionais, usando uma estratégia de mapeamento
objeto relacional. A JPA também pode ser utilizada em aplicações não JEE fora
do ambiente do servidor. Consiste de uma api de persistência, uma linguagem de
query e metadados para mapeamento objeto relacional.
Java Transaction API (JTA): Oferece uma inferface-padrão para a

demarcação de transações. A arquitetura JEE possui auto commit como default
para gerenciar commits e rollbacks dentro de transações. Isso significa que qualquer
aplicação que está visualizando um dado que está sendo alterado verá o mesmo
atualizado depois de cada operação de leitura ou escrita. Entretanto, caso sua
aplicação realize duas operações de acesso a dados em bases diferentes que
dependem uma da outra, você pode utilizar a JTA API para demarcar onde a
transação inteira começa, termina ou mesmo execute um rollback.
E
IMPORTANT
Nas tecnologias de bancos de dados, um rollback significa que o banco de

dados pode voltar a determinado estado anterior, evitando que um erro seja propagado e
mantido no mesmo.
Context and Dependency Injection for Java EE (CDI): Define um conjunto

de serviços do JEE acessíveis via contexto. Projetado para uso com objetos que
possuam estado, o CDI tem aplicações diversas, pois representa a injeção de
recursos em uma classe através de annotations, garantindo a flexibilidade e o
baixo acoplamento no desenvolvimento.
Java Message Service API (JMS): Define um padrão de mensageria

que permite que os componentes das aplicações JEE criem, enviem, recebam
e leiam mensagens. Permite a comunicação distribuída de forma desacoplada,
confiável e assíncrona.
Java Authentication and Authorization Service (JAAS): É o serviço que

permite a autenticação e autorização de um usuário específico ou de um grupo
de usuários. Oferece uma maneira desacoplada para a definição de aspectos de
8
segurança em uma aplicação JEE. O modelo do JEE permite que as restrições de

segurança sejam definidas em tempo de deployment e torna as aplicações portáveis
para uma vasta gama de implementações de diferentes fornecedores. As regras de
controle de acesso são declarativas e definidas pelo desenvolvedor. Estas regras
são interpretadas quando a aplicação é instalada no servidor, protegendo os
desenvolvedores da complexidade da implementação de requisitos de segurança.
O JEE permite ainda a utilização de mecanismos de segurança externos, como Active
Directory e LDAP, por exemplo. A mesma aplicação pode fazer uso de diversos
mecanismos de segurança sem nenhuma alteração no código fonte da mesma.
Enterprise Java Beans (EJB): São componentes que possuem atributos

e métodos para implementar lógica de negócios. Você pode pensar neles como
um bloco de construção que pode ser utilizado individualmente ou em conjunto
com outros beans para executar lógica de negócios na aplicação JEE. Os Enterprise
Beans podem ser de dois tipos:
• Session beans: representa uma conversação transiente com o cliente. Quando o

cliente encerra a execução, o bean e seus dados são perdidos.
• Message driven beans: combina características de um session bean e um ouvinte
de mensagens, permitindo que um componente de negócios receba mensagens
de forma assíncrona.
2.1 A ARQUITETURA DOS CONTAINERS

Uma das vantagens do JEE é a possibilidade de utilizá-lo em aplicações
de praticamente qualquer porte. Seu modelo desacoplado e flexível facilita a
utilização somente dos componentes que fazem sentido para a aplicação. Para
entender esta arquitetura, é importante entender de que forma o servidor de
aplicação está dividido em containers. A figura a seguir ilustra o relacionamento
entre os containers JEE.
FIGURA 2 - RELACIONAMENTO ENTRE CONTAINERS
FONTE: Oracle (2014)
9
Perceba que o JEE Server possui dois containers, o Web Container e o EJB
Container. A compreensão do funcionamento destes dois containers é fundamental
para que se faça bom uso dos serviços do servidor de aplicação e da plataforma JEE.
Dentro do Web Container podemos perceber as tecnologias Java Server

Faces e Servlet. Uma figura mais completa conteria ainda as Java Server Pages
(JSP). Estas tecnologias representam uma forma de disponibilizar a aplicação
através de um navegador web. Sem um webcontainer não é possível publicar
páginas html, xhtml e outras, o que impede a criação de aplicações web. Caso
sua aplicação seja mandatoriamente acessada através de um navegador, você
precisará de um webcontainer.
Já o EJB Container é responsável pelo gerenciamento dos Enterprise

Java Beans. A maioria dos serviços referentes a requisitos não funcionais ficam
sob encargo deste container. Em geral, o acesso aos dados é feito através dele,
visto que a JTA não está disponível no Webcontainer. Já dissemos aqui que nada
impede a colocação de regras de negócio em POJOs dentro do Webcontainer e
mesmo de acessar dados através dele, é simplesmente uma questão de analisar
os prós e os contras. No modelo da figura, os componentes Web interagem com os
componentes EJB para a lógica de negócios e o acesso aos dados.
Na figura, ainda existe o que é chamado de Client System, composto

pelo Browser e pelo Application Client Container. Este componente representa a
interface da aplicação com o cliente, seja pelo navegador, seja por uma aplicação
Swing, JavaFX ou mesmo console. Perceba que o application client acessa os EJBs
sem intermédio do Webcontainer.
Chegando ao final deste tópico, onde fizemos a introdução da plataforma

Java Enterprise Edition e das principais tecnologias que a compõem, você
deve pensar “é muita coisa para estudar”. E realmente, você tem razão, se
considerarmos todo o conjunto das tecnologias que compõem o JEE, o volume
de APIs é imenso. Entretanto, analisando o escopo de nossa disciplina e deste
caderno, nos concentraremos nas tecnologias mais importantes e que impactarão
diretamente sua produtividade como desenvolvedor. Nosso objetivo não é
esgotar o tema, e sim colocar você produzindo aplicações JEE com as principais
tecnologias que a plataforma disponibiliza. Seu sucesso dependerá diretamente
de seus estudos futuros, entretanto, aqui forneceremos um embasamento sólido.
E então...que tal pôr nossas mãos à obra? Como disse Linus Torvalds,
criador do sistema operacional Linux: “Talk is cheap... show me the code”. No
próximo tópico aprenderemos como configurar e preparar o ambiente que dará
suporte ao desenvolvimento JEE.
Bons estudos!
10
RESUMO DO TÓPICO 1
Neste tópico você viu que:
• O Java Enterprise Edition (JEE) inicialmente evoluiu como uma plataforma

de desenvolvimento para aplicações enterprise que focava em robustez,
webservices e facilidade.
• A plataforma JEE é projetada para suportar aplicações que possuem elevado

grau de complexidade, acessando dados das mais variadas fontes e atendendo
a um grande número de clientes e requisições.
• A tier é sempre composta por software, ou seja, é lógica. A layer é sempre

composta por hardware, ou seja, é física.
• A Web Tier pode ser implementada em Servlet Containers, que são uma
espécie de “mini” servidores de aplicação mais leves e ágeis, entretanto não
disponibilizam todos os serviços dos servidores de aplicação.
• A grande premissa por trás do JEE é que o desenvolvedor pode confiar na

plataforma para facilitar a implementação destes serviços padrão, normalmente
representados por requisitos não funcionais.
• Para cada um destes serviços existe uma ou mais tecnologias que, trabalhando
individualmente ou em conjunto, abstraem o desenvolvedor de detalhes
específicos da implementação do mesmo.
• Algumas das tecnologias disponibilizadas pelo JEE permitem que o desenvolvedor

simplesmente sinalize em seu código aspectos relacionados à segurança,
remotabilidade, transações etc., e o servidor de aplicações faz todo o resto.
• Uma das vantagens do JEE é a possibilidade de utilizá-lo em aplicações de

praticamente qualquer porte. Seu modelo desacoplado e flexível facilita a
utilização somente dos componentes que fazem sentido para a aplicação.
11
AUTOATIVIDADE
1 Diferencie um servidor de aplicação de um webcontainer e forneça exemplos

da aplicabilidade de ambos.
2 Explique detalhadamente e exemplifique a diferença entre uma layer e uma

tier, no contexto de arquitetura de software.
3 Uma das vantagens da utilização de um AS que obedeça às especificações

JEE é a disponibilização de serviços que antes eram implementados
manualmente pelos desenvolvedores. Com vistas a isto, avalie a lista de
serviços abaixo.
I- Segurança através do JAAS.

II- Mensageria através do JMS.
III- Remotabilidade.
IV- Componentização através do JTA.
Agora assinale a alternativa que lista corretamente os serviços

disponibilizados pelos servidores de aplicação JEE 7:
a) I, II e III.
b) II e III.
c) I e III.
d) II e IV.
12
UNIDADE 1
TÓPICO 2
CONSTRUÇÃO DO AMBIENTE DE
DESENVOLVIMENTO E EPLOYMENT
1 INTRODUÇÃO
1.1 INSTALAÇÃO DO SERVIDOR DE APLICAÇÃO – WILDFLY

Conforme vimos nos tópicos anteriores, para podermos desenvolver,
implantar e testar aplicações que utilizem as tecnologias que fazem parte da
especificação JEE, precisamos de um servidor de aplicação – application server (AS).
Utilizaremos, neste caderno, o WildFly Application Server, conhecido

anteriomente como JBoss. A Red Hat, empresa que desenvolve o AS, justifica a
mudança dizendo que o nome WildFly representa melhor o software na atualidade,
pois lembra leveza, agilidade e liberdade. A figura a seguir mostra o website do projeto.
NOTA
O projeto WildFly pode ser acessado através da URL: <http://wildfly.org>.
Apesar de você poder fazer o download do software pelo website e instalação

separadamente através do arquivo, utilizaremos aqui uma abordagem diferente:
instalaremos através da própria Integrated Development Environment (IDE) Eclipse.
13
FIGURA 3 - WEBSITE DO SERVIDOR DE APLICAÇÃO WILDFLY
FONTE: O autor
Inicialmente precisaremos fazer com que o Eclipse mostre a aba dos

servidores, visto que passaremos a utilizá-la com bastante frequência. Na figura
a seguir mostramos a aba dos servidores na IDE.
FIGURA 4 - ABA SERVIDORES NO ECLIPSE
FONTE: O autor
Caso a aba não esteja aparecendo para você, é possível adicioná-la através da
seleção do menu Window -> Show View -> Other. Você deve digitar a palavra server,
de modo que esta opção fique acessível para seleção, conforme a figura a seguir.
14
TÓPICO 2 | CONSTRUÇÃO DO AMBIENTE DE DESENVOLVIMENTO E EPLOYMENT
FIGURA 5 - SELEÇÃO DA ABA SERVERS NO ECLIPSE
FONTE: O autor
Uma vez que a aba está disponível, devemos clicar com o botão direito
do mouse e selecionar a opção New - > Server. Esta ação abrirá um novo diálogo,
onde devemos selecionar a opção destacada na Figura 6.
A próxima tela traz os servidores disponíveis para instalação no Eclipse.

Devemos selecionar a opção JbossAS Tools, confirmar todas as licenças e prosseguir
com a instalação, conforme a Figura 7. Ao longo da instalação, algumas mensagens
de aviso serão mostradas e ao final, você será solicitado para reiniciar a IDE.
Finalize o procedimento e aguarde a reinicialização do Eclipse.
FIGURA 6 - DEFINIÇÃO DE UM NOVO SERVER
FONTE: O autor
15
FIGURA 7 - SELEÇÃO DO JBOSSAS TOOLS
FONTE: O autor
Ao concluir a instalação e reinicialização da IDE, na aba Servers, clique

com o botão direito do mouse e selecione a opção New -> Server. No momento
em que este caderno foi escrito, somente tínhamos a versão 8 do WildFly para
instalar. Caso a versão 9 ou posteriores aparecem para você, selecione a última
versão que for compatível com a o JEE 7. Esta informação está disponível no
website do WildFly.
Você deverá criar um novo runtime para o servidor, através das telas
mostradas nas figuras 8 e 9. Você deve deixar a configuração exatamente como
mostrado nas figuras, com exceção do Execution Environment, que deverá
respeitar a versão do Java utilizada por você na IDE, e do caminho de instalação
do servidor, ambas na Figura 9.
16
FIGURA 8 - INSTALAÇÃO DO WILDFLY
FONTE: O autor
Ao final, pressione Finish e estaremos prontos para testar a instalação de

nosso servidor de aplicação. Na aba Server do Eclipse, deverá aparecer o servidor
que acabamos de instalar. Clique com o botão direito no mouse no servidor e
selecione a opção Start. O tempo necessário para a inicialização do WildFly
dependerá diretamente do desempenho de seu computador. Automaticamente,
o Eclipse seleciona a aba Console e várias mensagens geradas pelo WildFly
aparecerão na tela. É vital que você se habitue a observar atentamente o console
quando for testar suas aplicações, pois as mensagens de erro aparecem nesta aba.
FIGURA 9 - INSTALAÇÃO DO WILDFLY
FONTE: O autor
17
Quando a inicialização do servidor encerrar, você deverá ver uma

mensagem semelhante à destacada na Figura 10, indicando que o processo foi
bem-sucedido. As mensagens acima da mensagem destacada e inclusive a versão
e codinome do servidor podem variar, de acordo com o que foi selecionado e
instalado nas etapas anteriores.
FIGURA 10 - INICIALIZAÇÃO DO WILDFLY
FONTE: O autor
Por fim, para testarmos se a instalação foi bem-sucedida, devemos digitar

a seguinte URL no navegador: <http://localhost:8080>. O navegador deverá
mostrar a seguinte página, que é a página inicial do WildFly, que está executando
localmente na porta 8080, conforme a Figura 11.
FIGURA 11 - PÁGINA INICIAL DO WILDFLY EXECUTANDO EM LOCALHOST
FONTE: O autor
Caso você prefira utilizar uma IDE que já tenha o ambiente de

Desenvolvimento completo embutido, pode utilizar o NetBeans, que já vem
com uma implementação de referência da especificação JEE 7, conhecida como
GlassFish. O procedimento para instalação do NetBeans será demonstrado a seguir.
18
2 INSTALAÇÃO DO NETBEANS
O NetBeans é uma IDE desenvolvida pela Oracle que permite que você
desenvolva aplicações desktop, web e mobile em Java, bem como aplicações com
HTML5, JavaScript e CSS. A IDE possui ainda uma vasta gama de ferramentas para
desenvolvedores PHP e C/C++. É gratuita, open source e tem uma grande comunidade
de usuários e desenvolvedores ao redor do mundo (NETBEANS, 2015).
Ela pode ser obtida através do endereço <https://netbeans.org/downloads/

index.html>, conforme a Figura 12. Neste endereço existem diversas versões para
download, para diversos sistemas operacionais e em diversos idiomas. Você deve
selecionar a opção destacada.
FIGURA 12 - DOWNLOAD DO NETBEANS
FONTE: O autor
Essa versão possui diversas ferramentas embutidas, o que praticamente

elimina a necessidade de configuração, além de dois servidores, o GlassFish e o
Tomcat. Em nossa disciplina precisaremos do GlassFish, visto que o Tomcat não é
um Application Server, mas sim um servlet container.
Uma vez feito o download, podemos proceder com a instalação do

NetBeans. O instalador da ferramenta é bem simples e, embora demore um
pouco para concluir todo o processo, exige pouca interação por parte do usuário.
Na Figura 13 podemos perceber uma janela informando quais softwares serão
instalados em seu computador.
19
FIGURA 13 - TELA DO INSTALADOR
FONTE: O autor
Caso deseje personalizar a instalação, retirando ou colocando itens, basta

selecionar a opção “Personalizar”. Esta opção leva para a tela de configuração
mostrada na Figura 14. Recomendamos que você mantenha todas as funcionalidades,
com exceção do PHP e C/C++, que são completamente opcionais. O Tomcat deve
ser selecionado pois, caso sua aplicação não utilize funcionalidades específicas
de servidores de aplicação, ele representa uma opção mais leve e performática.
Aprenderemos que funcionalidades específicas são essas ao longo do caderno.
A última tela antes da instalação propriamente dita é mostrada na Figura

15. Basta selecionar a opção onde você diz que aceita os termos da licença e clicar em
finalizar. O instalador procederá automaticamente com a cópia, descompactação
e download dos arquivos necessários ao NetBeans. Lembramos que a versão da
ferramenta poderá variar, dependendo de quando você fará a leitura do caderno
e download da mesma. O importante é sempre manter-se em versões superiores à
utilizada aqui, aumentando a probabilidade de compatibilidade.
20
FIGURA 14 - CONFIGURAÇÃO DO INSTALADOR
FONTE: O autor
FIGURA 15 - CONTRATO DE LICENÇA
FONTE: O autor
Uma vez que a instalação foi concluída, ao abrir a IDE nos deparamos
com a tela mostrada na Figura 16. Não é objetivo deste caderno a explicação das
funcionalidades do NetBeans, visto que inclusive utilizaremos o Eclipse para o
desenvolvimento de nossos exemplos. O Eclipse é melhor em algumas atividades
e o NetBeans em outras. Com o tempo e a utilização, você elegerá a sua favorita.
21
FIGURA 16 - INTERFACE DO NETBEANS
FONTE: O autor
ATENCAO
Tutoriais sobre o NetBeans podem ser acessados gratuitamente no endereço:

<https://netbeans.org/kb/docs/java/quickstart-gui.html>.
Para o desenvolvimento das aplicações, precisaremos estabelecer conexão

com bancos de dados relacionais. A plataforma Java, através do JDBC e mais
recentemente do JPA, permite a conexão com os principais players do mercado.
Para facilitar o aprendizado e reduzir a configuração, trabalharemos com o banco
de dados MySQL, que já foi utilizado por você em disciplinas anteriores.
3 INTEGRAÇÃO WILDFLY-MYSQL
Conforme K19 (2013), aplicações Java se comunicam com banco
de dados através de conexões JDBC. Para estabelecer uma conexão JDBC,
algumas informações como usuário, senha e base de dados são necessárias. As
configurações relativas às conexões JDBC podem ser definidas nas aplicações ou
nos servidores de aplicação. Em um servidor de aplicação, as configurações JDBC
são definidas em componentes chamados Data Sources. Os Data Sources permitem
que uma única configuração JDBC seja utilizada por diversas aplicações. Eles
22
também permitem que outros tipos de configurações sejam compartilhadas,

como por exemplo, a configuração de um Connection Pool. Além disso, através de
Data Sources podemos utilizar facilmente o serviço de transações dos servidores
de aplicação. Esse serviço é definido pela especificação Java Transaction API (JTA),
que será abordada na Unidade 3 deste Caderno de Estudos.
Inicialmente devemos fazer o download do driver jdbc para o MySQL,

disponível em <http://dev.mysql.com/downloads/connector/j/>, conforme a Figura
17. É recomendável fazer o download do driver independente de plataforma, visto
que ele funciona em qualquer sistema operacional.
Uma vez que o download foi concluído, passamos para a integração do

driver com o WildFly. Lembramos que a função do driver JDBC é estabelecer a
comunicação entre o Sistema Gerenciador de Banco de Dados Relacional (SGBDR)
e a plataforma Java, neste caso, representado pelo servidor de aplicações.
FIGURA 17 - DRIVER JDBC
FONTE: O autor
O próximo passo consiste em copiar o driver para o diretório adequado

dentro da instalação do WildFly. Inicialmente localize o diretório onde o WildFly
está instalado e lá dentro, localize o diretório modules/com. Agora crie um diretório
chamado mysql e, dentro deste, outro diretório chamado main. O driver MySQL
deverá ser copiado para esta pasta recém criada. Crie também neste diretório um
arquivo vazio chamado module.xml.
23
FIGURA 18 - LOCAL DO DRIVER JDBC
FONTE: O autor
O conteúdo deste arquivo deverá ser igual ao da imagem abaixo,

respeitando o nome do arquivo que você copiou para dentro da pasta após o
atributo path, na linha 4. Este arquivo representará a instalação de um módulo
adicional no WildFly. Ao encerrar, verifique o código fonte escrito com cuidado,
salve e feche o arquivo.
FIGURA 19 - ARQUIVO MODULE.XML
FONTE: O autor
A próxima (e última) etapa consiste na configuração do arquivo

standalone.xml, disponível no caminho /standalone/configuration, no diretório
de instalação do WildFly. Dentro deste arquivo, encontre a tag <datasources>
e insira a configuração de um novo datasource e um novo driver, conforme
mostrado na Figura 20. Caso já existam configurações para outros datasources
e drivers, você não precisa excluí-los, uma vez que eles em geral servem como
exemplo e o WildFly pode trabalhar com múltiplos datasources.
24
Na Figura 20 podemos ainda perceber o nome de nosso datasource (java:/

MYSQL_DS), representado pelo número 1 e também o nome do módulo que
instalamos no arquivo module.xml, representado pelo número 2. Outros aspectos
importantes a serem destacados são o usuário e senha dentro da tag <security>
e a url de conexão, dentro da tag <connection-url>. Estes valores deverão refletir
a condição de seu SGBD. No caso deste exemplo, o usuário e senha do banco de
dados são “root” e o nome da base de dados é JEE7. Faça as alterações de acordo
com as configurações do MySQL instalado em seu computador. Ao encerrar,
verifique o código fonte escrito com cuidado, salve e feche o arquivo.
FIGURA 20 - CRIAÇÃO DO DATASOURCE
FONTE: O autor
Para podermos realizar os testes da configuração que acabamos de fazer,

verifique se o MySQL está funcionando corretamente em seu computador, de outra
forma, não podemos nos conectar com ele através do WildFly. Feita esta verificação,
abra o Eclipse e encontre o WildFly na aba Servers, iniciando-o. Diversas mensagens
aparecerão no console, sendo que ao final devemos encontrar a mesma mensagem
que mostramos na Figura 10 desta unidade, o que demonstra que o servidor
iniciou sem erros. A garantia de que o datasource foi configurado corretamente vem
através de uma mensagem no console que mostra o nome de todos os datasources
configurados para aquela instância do servidor de aplicação. No nosso caso,
devemos buscar pelo nome java:/MYSQL_DS, conforme mostra a Figura 21.
FIGURA 21 - CONFIGURAÇÃO DEMONSTRADA NO CONSOLE
FONTE: O autor
25
4 INTEGRAÇÃO GLASSFISH-MYSQL
Neste tópico, demonstraremos de que forma fazer a integração entre o
MySQL e o Servidor de aplicações Glassfish através do NetBeans.
ATENCAO
Em nossos exemplos, o Netbeans está configurado para o idioma inglês,

ao invés do português que é instalado automaticamente. Caso deseja trocar o idioma, o
procedimento é demonstrado em: <http://www.frameworksystem.com/blog/alterando-a-
linguagem-no-netbeans/>.
Inicialmente, acesse a aba Services, demonstrada na Figura 22. Nesta

aba, clique com o botão direito no mouse na opção Databases, selecionando
New Connection. Selecionando esta opção, aparecerá uma janela que permitirá
selecionar a qual banco de dados nos conectaremos. Selecione a opção MySQL e
o próprio Netbeans sugerirá um driver, conforme a Figura 23.
FIGURA 22 - INTEGRAÇÃO GLASSFISH-MYSQL
FONTE: O autor
26
FIGURA 23 - MYSQL JDBC DRIVER
FONTE: O autor
Pressione o botão Next e preencha as configurações mostradas na Figura

24 de acordo com as configurações do MySQL instalado em seu computador.
Ao finalizar as configurações, pressione o botão Test Connection e aguarde pela
mensagem Conection Succeeded, indicando que o Netbeans encontrou o banco de
dados e conseguiu se conectar.
ATENCAO
Antes de realizar o procedimento de teste da conexão, certifique-se de que o

MySQL está funcionando corretamente em seu computador e de que o mesmo foi inicializado.
27
FIGURA 24 - CONFIGURAÇÃO DO MYSQL
FONTE: O autor
Existem algumas configurações adicionais, mas com o objetivo de

simplificar o processo de configuração, podemos pressionar o botão Finish
e aguardar o resultado demonstrado na Figura 25. O número 1 mostra a nova
conexão com o banco MySQL através de sua adição às databases. O número 2
indica os Schemas ou databases disponíveis no banco de dados com o qual nos
conectamos. Em seu computador, o número dois trará Schemas diferentes dos
mostrados na Figura.
Em nosso exemplo, a conexão foi renomeada para MYSQL_DS,

selecionando a mesma com o botão direito e clicando na opção renomear. Este
passo é opcional e não interferirá diretamente com o resto do procedimento. O
importante é você conseguir encontrar a conexão que criou dentro do Netbeans.
Seguindo este procedimento, você configurou uma nova conexão

com o banco de dados MySQL diretamente através do Netbeans. Para fazer a
configuração do datasource e do pool de conexões, devemos acessar a interface
de administrador do Glassfish, disponível na url <http://localhost:4848>, sem
esquecer de antes inicializar o servidor dentro do Netbeans.
28
FIGURA 25 - CONEXÃO COM O MYSQL
FONTE: O autor
Para inicializar o Glassfish, basta ir até a aba Services e escolher a opção

Server. Dentre os servidores listados, clique com o botão direito do mouse no
Glassfish e em seguinda na opção Start, conforme a Figura 26. Quando o servidor
terminar seu processo de inicialização, você pode ir até o navegador web e digitar
a URL supracitada.
Pronto! Você agora está na interface de administração do Glassfish (Figura

27). Da mesma forma que no WildFly, existem inúmeras configurações que podem
ser feitas para otimizar o desempenho e performance do servidor de aplicação,
mas como este não é o objetivo desta disciplina, faremos as configurações mínimas
necessárias para o funcionamento dos exemplos que utilizaremos.
29
FIGURA 26 - INICIALIZAÇÃO DO GLASSFISH
FONTE: O autor
FIGURA 27 - INTERFACE DE ADMINISTRAÇÃO DO GLASSFISH
FONTE: O autor
30
Uma vez na interface de administração, selecione a opção JDBC/JDBC

Connection Pools, onde criaremos o pool de conexões para nosso datasource. Um
pool de conexões é uma espécie de cache de conexões com o banco de dados,
mantidas de forma que possam ser reutilizadas quando futuras requisições forem
feitas, otimizando recursos computacionais. A próxima tela lista todos os pools
já existentes e, para criar um novo pool, clique no botão New. A Figura 28 mostra
as configurações do primeiro passo para a criação do pool. Após preencher estas
configurações, clique em Next.
FIGURA 28 - CONFIGURAÇÃO DO POOL DE CONEXÕES
FONTE: O autor
Na tela seguinte existem vários campos que permitem configuração,

mas para nossa finalidade, devemos alterar somente as propriedades adicionais
listadas na Tabela 1:
TABELA 1 - PROPRIEDADES DO POOL DE CONEXÕES

Propriedade Valor
user <usuário do seu banco de dados MySQL>
ServerName localhost
DatabaseName jee7
Password <senha do seu banco de dados MySQL>
Url jdbc:mysql://localhost:3306/jee7
URL jdbc:mysql://localhost:3306/jee7
FONTE: O autor
Para concluir o processo, clique em Finish e aguarde a criação do novo pool

de conexões. Ao final, o Glassfish exibirá todos os pools de conexão disponíveis,
entre os quais deverá estar o que você acabou de criar (Figura 29).
31
FIGURA 29 - LISTAGEM DOS POOLS DE CONEXÃO
FONTE: O autor
Ao clicar no pool recém criado, você será levado a uma tela que permite o
teste do mesmo através do botão Ping. Se o pool estiver funcionando, haverá uma
mensagem informando que o ping foi bem sucedido (Figura 30).
FIGURA 30 - TESTE DO POOL DE CONEXÕES
FONTE: O autor
Como último passo do processo, precisaremos criar o datasource

propriamente dito. Ainda na interface de administração do Glassfish, selecione
a opção JDBC/JDBC Resources. Nesta tela estão listados todos os datasources
disponíveis no Glassfish. Para criar um novo, clique no botão New e preencha as
configurações da tela seguinte conforme demonstrado na Figura 31.
32
FIGURA 31 - CONFIGURAÇÃO DO DATASOURCE
FONTE: O autor
ATENCAO
JNDI é o acrônimo de Java Naming and Directory Interface, cujo objetivo é

permitir a busca de objetos de forma distribuída simplesmente através de um nome. Com
essa tecnologia, o cliente abstrai totalmente os detalhes referentes à implementação do
recurso que está sendo buscado. Maiores detalhes sobre o JNDI podem ser obtidos em:
<http://docs.oracle.com/javase/tutorial/jndi/overview/>.
Assim encerramos o processo de criação dos DataSources nos servidores de

aplicação e IDEs que você poderá utilizar ao longo da disciplina. Agora estamos
prontos para efetivamente pôr a “mão na massa” e começar a fazer os exercícios e
criar nossas próprias aplicações utilizando JEE 7 e os servidores de aplicação WildFly
e Glassfish. Caso você queira utilizar o Glassfish com o Eclipse ou o WildFly com o
Netbeans, basta configurá-los da forma como demonstramos ao longo deste tópico.
33
RESUMO DO TÓPICO 2
• De modo a podermos desenvolver, implantar e testar aplicações que utilizem

as tecnologias que fazem parte da especificação JEE, precisamos de um servidor
de aplicação - application server (AS).
• Entre as principais opções estão o Wildfly Application Server, disponibilizado

pela Red Hat e o GlassFish Application Server, disponibilizado pela Oracle.
• Para desenvolver aplicações corporativas podemos utilizar o Netbeans ou o

Eclipse, bastando configurá-lo para acessar o AS.
• O servidor de aplicação disponibiliza serviços de persistência através de

JDBC, JPA e JTA, havendo necessidade de configuração de fontes de dados
(Datasources) para que os serviços funcionem.
34
AUTOATIVIDADE
1 Configure as duas IDEs (eclipse e netbeans) para trabalharem ambas com os

servidores de aplicação GlassFish e WildFly:
2 Configure mais um datasource para cada servidor de aplicação,

preferencialmente utilizando um banco de dados diferente do MySQL:
3 Encontre e descreva pelo menos mais três implementações de Servidores

de Aplicação compatíveis com a especificação JEE 7. Estes servidores de
aplicação podem ser tanto proprietários como open source.
35
36
UNIDADE 1
TÓPICO 3
JAVA SERVER FACES (JSF)
1 INTRODUÇÃO
O Java Server Faces (JSF) é o framework padrão da plataforma Java para

a construção de aplicações web com JEE. Ele define e implementa um modelo
de componentes visuais para WEB, utilizando uma arquitetura MVC (model-
view-controller). Esta arquitetura propõe a divisão das responsabilidades de uma
aplicação em três camadas distintas (Figura 32):
1. View: responsável pela renderização da interface gráfica da aplicação.

2. Controller: responsável por receber e tratar os eventos da View.
3. Model: responsável pela implementação da lógica de negócios.
FIGURA 32 - ARQUITETURA MVC
FONTE: Disponível em: <http://stackoverflow.com/questions/29594105/mvc-is-it-

model-to-view-or-controller-to-view>. Acesso em: 20 set. 2015.
37
Da mesma forma que as demais tecnologias que fazem parte da plataforma

Java, o JSF é definido por uma especificação mantida pelo JCP através de JSRs. Ele
define uma API padrão e extensível através de classes e interfaces, simplificando o
desenvolvimento e aumentando a produtividade de aplicações em Java para Web.
As principais funcionalidades que o JSF traz para uma aplicação web

incluem (SOFTPLAN, 2015):
• Gerenciamento do ciclo de vida dos componentes visuais e a responsabilidade
na geração do HTML a partir deles.
• Disponibilização de uma biblioteca de componentes visuais básicos análogos
aos componentes HTML.
• Suporte à templates de tela para reuso de estruturas de interfaces Web;
• Desenvolvimento de componentes visuais personalizados;
• Suporte embutido à ajax.
• Validação, conversão e formatação de dados de formulários.
• Tratamento de eventos entre telas Web.
• Gerenciamento da navegabilidade da aplicação.
O JSF funciona baseado em objetos que são mantidos em memória no

servidor e que ficam responsáveis pela geração do HTML que será enviado ao
navegador. Esta estratégia permite que os valores contidos nos componentes
mantenham seu estado, permitindo sua recuperação mesmo após várias
requisições. O objetivo desta arquitetura é a limitação imposta pela característica
stateless do HTTP.
A Figura 33, retirada de SOFTPLAN (2015), exemplifica o funcionamento

do JSF. Imagine um cliente que faz uma primeira requisição para uma aplicação
web em um AS. O JSF utiliza um arquivo no formato xHTML para descrever
uma interface da aplicação. Quando o recurso representado por esse arquivo
é solicitado, uma árvore de componentes é gerada no servidor e um HTML
é enviado ao cliente. Para as próximas requisições a este recurso pelo mesmo
cliente, o servidor utiliza a árvore já em memória para montar o HTML. Este
processo faz parte do ciclo de vida do JSF.
FIGURA 33 - ARQUITETURA DO JSF
FONTE: SOFTPLAN, 2015
38
TÓPICO 3 | JAVA SERVER FACES (JSF)
2 CRIAÇÃO DA PRIMEIRA APLICAÇÃO

Vamos agora demonstrar como criar uma pequena aplicação utilizando as
capacidades básicas do JSF. Abra o Eclipse e selecione um projeto do tipo Dynamic
Web Project, conforme a Figura 34.
FIGURA 34 - CRIAÇÃO DO PROJETO NO ECLIPSE
FONTE: O autor.
A próxima etapa consiste em configurar o projeto de forma que ele permita

a utilização das tecnologias que veremos ao longo do caderno. A Figura 35 ilustra a
interface de configuração deste tipo de projeto. Os números 1, 2 e 3 destacam o nome
do projeto, o AS que utilizaremos e quais APIs farão parte do projeto, respectivamente.
Para o nome do projeto, você pode colocar o que achar mais adequado.
O Servidor de Aplicação que utilizaremos será o mesmo que instalamos no tópico
anterior, o WildFly. A configuração, entretanto, exige um pouco mais de cuidado.
Clicando no botão modify, a imagem da Figura 36 permite que selecionemos
somente as APIs que utilizaremos no projeto. Para o nosso projeto, selecione as
mesmas APIs da figura e clique no botão OK.
39
FIGURA 35 - CONFIGURAÇÃO DO PROJETO
FONTE: O autor.
De volta a tela principal de configuração, prossiga clicando no botão

Next até encontrar a tela mostrada na Figura 37. Esta é a tela de configuração da
implementação para o JPA. Sugerimos configurar exatamente como mostrado na
figura, pois embora não iremos utilizar JPA no primeiro exemplo, a configuração
do mesmo neste momento nos poupará esforço futuro. Não se esqueça de
configurar também a conexão com o MySQL.
40
FIGURA 36 - APIS UTILIZADAS
FONTE: O autor.
FIGURA 37 - CONFIGURAÇÃO DO JPA
FONTE: O autor.
41
Prossiga pressionando o botão Next até se deparar com a tela mostrada

na Figura 38. Esta tela configura a geração automática do arquivo beans.xml,
necessário para se utilizar CDI. Mantenha a configuração como na figura e
pressione o botão Finish.
FIGURA 38 - CONFIGURAÇÃO DO CDI
FONTE: O autor
Pronto! A partir de agora utilizaremos este projeto para nossos exemplos.

Para conferir se a criação foi feita corretamente, basta expandir o projeto recém-criado
no Eclipse. A estrutura de diretórios deve ficar semelhante à mostrada na Figura 39.
FIGURA 39 - ESTRUTURA DO PROJETO
FONTE: O autor
Para criar nosso primeiro JSF, clique com o botão direito do mouse
no diretório WebContent e selecione a opção New XHTML Page. Dê o nome
formulario.xhtml para a mesma e clique no botão Next. Na tela apresentada a
seguir, mantenha a configuração mostrada na Figura a seguir e clique em Finish.
Isso criará um template XHTML vazio para nossa aplicação.
42
FIGURA 40 - CONFIGURAÇÃO DO TEMPLATE XHTML
FONTE: O autor
O Eclipse gera um template vazio para uma página XHTML, entretanto,

a importação das bibliotecas que contém os componentes visuais já está feita. Na
Figura 41 podemos perceber a existência destas bibliotecas e sua efetiva utilização.
Entre as linhas 2 e 5 são referenciadas URLs através dos prefixos ui, f e h. Estes
prefixos servirão para utilizar os componentes visuais, de acordo com sua natureza.
Isto pode ser percebido através do componente head que aqui ele é <h:head>, o que
indica que a importação ocorrerá através da URL referenciado no prefixo h.
O exemplo contendo o código fonte completo pode ser visualizado na

Figura 42. A linha 1 foi removida para simplificar o exemplo. Da mesma forma
que no HTML, os componentes visíveis ficam dentro da tag <body>. Na linha
11 criamos um formulário que contém um Label, um InputText e um Button,
todos componentes visuais do JSF. O InputText é mapeado diretamente para um
atributo do formularioMB e o Button é mapeado diretamente para um método
do mesmo arquivo. No exemplo em questão, não faremos a criação do model e
utilizaremos o controller para simular esta função.
43
Note que este mapeamento de um componente de formulário diretamente

para um atributo e de um botão diretamente para um método aumenta muito a
produtividade no desenvolvimento. Em algumas IDEs, é possível inclusive gerar
Views e Controllers automaticamente a partir de classes de domínio.
FIGURA 41 - IMPORTAÇÃO DAS BIBLIOTECAS
FONTE: O autor
FIGURA 42 - CÓDIGO FONTE DO ARQUIVO JSF
FONTE: O autor
Mas o que é o formularioMB? O JSF funciona através de uma arquitetura

MVC, o que exige a presença de um intermediário entre o model e a view. Este
intermediário é o controller, que no caso do JSF é chamado de Managed Bean (MB).
Cabe ao MB mapear os componentes para o model, instanciar os objetos no lado do
servidor e também reagir aos eventos gerados na view.
O MB sempre é uma classe serializável com métodos getters e setters para

permitir o acesso aos componentes visuais. A figura a seguir mostra o código-fonte
de um MB. Inicialmente, a anotação named permite que o MB seja visualizado
dentro dos arquivos XHTML. É por causa desta anotação que conseguimos
referenciar métodos públicos e atributos do MB. A anotação @RequestScoped
indica que o escopo do MB é de request, ou seja, os valores da árvore de objetos
devem ser mantidos somente durante o request.
44
FIGURA 43 – CÓDIGO-FONTE DO MB
FONTE: O autor
Para este exemplo utilizamos uma String como o objeto de domínio, para
fins de simplificação. Na verdade, o MB segue a convenção Java Bean: métodos
getters e setters para todos os atributos, um construtor vazio e a implementação da
interface Serializable. O método executar serve simplesmente para ilustrarmos o
funcionamento do botão.
Para criar esta classe, expanda o diretório Java Resources de seu projeto e
clique com o botão direito do mouse no diretório src. Selecione a opção Java Class e
copie o código-fonte contido na imagem do MB. Atenção para o nome do pacote,
pois o utilizaremos nos exemplos posteriores. Uma vez que a classe esteja pronta,
clique com o botão direito do mouse no arquivo formulario.xhml e selecione a
opção Run on Server.
45
FIGURA 44 - DEPLOYMENT E EXECUÇÃO DO PROJETO
FONTE: O autor
Ao seguir este procedimento, a aplicação então é exibida no navegador

interno do Eclipse. Ao testá-la, podemos ver mensagens sendo exibidas no
console do AS.
3 CICLO DE VIDA E ESCOPOS DO JSF

Para entendermos de que forma o JSF se comporta na questão da árvore
de objetos em memória, e consequentemente extrairmos o máximo da tecnologia,
é essencial entender o ciclo de vida e os escopos do JSF.
FIGURA 45 - TESTE DA APLICAÇÃO JSF
FONTE: O autor
46
Conforme SOFTPLAN (2015), o ciclo de vida do JSF é simplesmente a

sequência dos passos que o Front Controller do JSF executa ao receber uma
requisição de um cliente, conforme descrito a seguir:
1. O primeiro passo é a restauração da árvore de componentes. Caso seja o

primeiro acesso daquele cliente, o JSF cria a árvore de acordo com a descrição
do arquivo .xhtml. Caso não seja o primeiro acesso, a árvore é recuperada da
memória no servidor.
2. O segundo passo é a extração dos valores de campos de formulários vindos com

a requisição e atribuição dos mesmos aos respectivos componentes dentro da
árvore, atualizando-os. Neste momento ocorre também a conversão dos dados.
3. O terceiro passo consiste na validação dos valores dos componentes que

possuírem regras de validação associadas. Por exemplo, um campo obrigatório
que é submetido sem nenhum valor ou um campo numérico que vem com
um valor alfanumérico. Neste passo, caso alguma das validações não seja bem
sucedida, o JSF interrompe seu ciclo de vida retornando para o navegador do
usuário com uma mensagem de erro.
4. Caso a validação seja bem sucedida, o próximo passo é atualizar os valores dos
campos dentro do Managed Bean. Neste momento, todos os métodos setters
dentro do MB serão invocados.
5. Neste passo os métodos associados a ações de botões são executados dentro

do MB.
6. Aqui o JSF gera o HTML a ser enviado para o usuário com base na árvore de
componentes. Antes disso, os valores dos componentes são extraídos do MB,
através da invocação de todos os métodos getters. Quando o processo encerra, o
HTML é finalmente enviado ao navegador.
ATENCAO
O Front Controller é um padrão de projeto relacionado a aplicações web.

Consiste basicamente de um ponto central de entrada que gerencia as requisições de
usuários. É o que ocorre com o JSF. Maiores detalhes podem ser obtidos em: <http://www.
martinfowler.com/eaaCatalog/frontController.html>.
Faremos a seguir algumas modificações em nosso exemplo anterior que

permitirão a compreensão deste mecanismo. A primeira etapa já está pronta e
consiste na impressão de uma mensagem no momento em que o construtor vazio
do MB é invocado. Colocaremos mensagens ainda dentro do método getNome() e
do método setNome(), conforme ilustrado na Figura 46.
47
Agora faremos novamente a publicação da aplicação, clicando com o

botão direito do mouse sobre o arquivo formulario.xhtml e selecionando a opção
Run As->Run On Server. Essa ação permitirá a visualização das alterações em
nosso exemplo.
FIGURA 46 - O CICLO DE VIDA DO JSF
FONTE: O autor
Na Figura 47, podemos perceber que a aplicação carregou normalmente no

navegador, mas o importante é conseguir observar as mensagens do console. Neste
caso, o construtor do MB foi invocado e também o método getter. É possível ainda
notar que duas instâncias do MB são criadas, ao invés de somente uma. O motivo
para tal comportamento será explicado na Unidade 3 deste Caderno de Estudos.
Mas por que o valor de nome é igual a null? Isso ocorre devido ao próprio
ciclo de vida do JSF, onde o MB é instanciado e, como esta é a primeira requisição,
a árvore de componentes deve ser montada com base no arquivo xhtml e alocada
na memória. O último passo antes de renderizar o HTML é atribuir os valores
do MB aos componentes visuais. Como nosso MB não possui nenhum valor, o
getNome aparece retornando null.
48
FIGURA 47 - CICLO DE VIDA DO JSF
FONTE: O autor
Mas o que acontece quando colocamos um valor para Nome e clicamos em

executar? Faça o teste em sua aplicação que eu explicarei os resultados obtidos
aqui. Depois da primeira requisição, ciclo de vida do JSF é executado sempre da
mesma forma, como podemos avaliar observando a Figura 48.
Cada número indica um passo do ciclo de vida. A linha destacada pelo

número 1 ilustra a criação de uma nova instância do MB, enquanto a linha 2
trata da busca da árvore dos componentes visuais e dos valores dos atributos do
MB. Por enquanto o nome continua nulo. Na linha destacada pelo número 3, os
métodos setters do MB são invocados e, como agora possuímos o valor “Catarina”
no componente associado ao nome, o MB recebe este valor. O número 4 mostra
as duas linhas que são impressas ao invocarmos o método executar. Lembre-
se de que a ação que efetivamente faz essa invocação é o clique no botão. Por
fim, o número 5 trata da renderização dos componentes em HTML para envio
ao navegador. Neste passo, o valor dos componentes é atualizado com o valor
existente no atributo do MB associado através da expression language.
49
FIGURA 48 - CONTINUAÇÃO DO CICLO DE VIDA JSF
FONTE: O autor
Cada vez que você clicar no botão Executar, uma nova instância de
FormularioMB é criada e o getNome retornará null. Este comportamento
é característico da annotation @RequestScoped, onde uma nova instância de
FormularioMB é criada a cada requisição do usuário. Esta anotação define que o
tempo de vida deste objeto é marcado pela requisição do usuário.
Outro escopo existente é o SessionScope, onde o tempo de vida do MB é

marcado pela sessão do usuário. Caso nenhuma configuração adicional seja feita, o
MB se mantém desde pressionarmos o botão até fecharmos o navegador. Este tipo
de escopo é interessante para guardar uma sessão de login do usuário, garantindo
que ele tenha passado por uma página e se identificado antes de acessar a parte
protegida de uma aplicação. Você já deve ter visto aplicações web onde o tempo de
sessão é definido em minutos, para aumentar a segurança. Em geral, este tipo de
configuração é utilizado em aplicações de Home Banking e cartões de crédito.
Na figura a seguir demonstramos como alterar o escopo de nosso MB

para Session. Basta alterar a annotation @RequestScoped para @SessionScoped.
Perceba que o comportamento da primeira e segunda vez que executamos (1) é o
mesmo do @RequestScoped, entretanto, no terceiro acesso (2), o método getNome
busca o valor já existente no MB, agora persistente entre as requisições do usuário.
No próximo passo, o método setter é invocado e o nome Catarina é substituído
por Cecilia no MB (3). O método executar é invocado novamente (4) e, finalmente,
o HTML é renderizado com o valor atualizado no componente, obtido através do
método getNome (5).
50
FIGURA 49 - MANAGED BEAN COM ESCOPO DE SESSÃO
FONTE: O autor
Uma experiência interessante para comprovar o funcionamento deste

escopo é pegar a URL do navegador interno do Eclipse, copiá-la e acessar a
aplicação através de um navegador externo. Mas espere aí... os valores que eu
coloquei não aparecem fora do Eclipse. Isto ocorre porque o AS trata este acesso
como um segundo acesso feito por outro usuário. Se você observar os logs do
servidor, perceberá que ele obedecerá o mesmo ciclo de vida. Mas e por que ele
não cria uma nova instância do MB? Isto significa que os valores se confundirão
entre os usuários? Vou responder a esta pergunta com outra. Você se lembra
de quando acessamos nossa aplicação pela primeira vez e o servidor criou duas
instâncias do FormularioMB? O segundo usuário está acessando nossa aplicação
através daquela segunda instância, que o AS já criou para evitar o overhead
de instanciação de um novo objeto e melhorar a performance da aplicação.
Lembrando que esta característica é configurável.
A última experiência consiste em abrir uma instância da aplicação através

de outro navegador (se você abriu o Chrome, tente acessar a aplicação do Firefox
e, em último caso, do Internet Explorer). Observando o log no console, percebemos
que o mesmo mostra a criação de uma nova instância do FormularioMB, pois para o
servidor somos um novo usuário e nossas duas instâncias iniciais já estão ocupadas.
51
ATENCAO
Existem outros escopos no JSF além do Request e Session. Para maiores detalhes
acesse: http://uaihebert.com/jsf-mini-livro-dicas-conceitos-e-boas-praticas/
Nesta unidade percorremos bastante conteúdo... entendemos o contexto

onde são aplicadas as aplicações JEE, compreendemos a necessidade de um
servidor de aplicação, criamos e configuramos um ambiente para a criação
de aplicações enterprise e, por fim, introduzimos as Java Server Faces de forma
prática, enfatizando a caracterização de sua arquitetura e seu ciclo de vida. Nas
próximas unidades abordaremos aspectos avançados de JSF e demonstraremos
o funcionamento de outras tecnologias chave que fazem parte da especificação
JEE, como CDI e EJB. Novamente queremos destacar a necessidade de realização
das autoatividades e de todas as implementações que são solicitadas no caderno.
É somente através da prática que você alcançará a compreensão deste conteúco.
Nos veremos na próxima unidade.
Até lá e bons estudos!
52
LEITURA COMPLEMENTAR
Artigo disponível em: <http://www.devmedia.com.br/introducao-ao-

padrao-mvc/29308>.
INTRODUÇÃO AO PADRÃO DE PROJETO MODEL,

VIEW, CONTROLLER
1 Introdução
Na fase de Projeto começamos a nos preocupar com a arquitetura da

aplicação. Nesta fase damos realmente valor à tecnologia, diferente da fase de
análise onde ainda estamos esboçando o problema a ser resolvido. Definimos a
plataforma e como os componentes do sistema irão se organizar. Evidentemente
que os requisitos ainda são importantes, pois, por exemplo, um sistema Web ou
então uma aplicação de tempo real deverá influenciar na arquitetura.
Mesmo não possuindo uma definição consensual, afinal diversos livros,

artigos ou autores definem o que é arquitetura da sua forma, a arquitetura de
software de um sistema computacional pode ser definida como as suas estruturas,
que são compostas de elementos de software, de propriedades externamente
visíveis desses componentes, e do relacionamento entre eles. Ou seja, a arquitetura
define os elementos de software e como eles interagem entre si.
Para realizar a arquitetura de uma aplicação não basta estar num dia
inspirado ou acordar com bastante vontade de realizar uma arquitetura, muito
pelo contrário, precisamos de bastante experiência em diferentes organizações,
diferentes tipos de projetos, conhecimentos de diferentes arquiteturas etc. A
experiência prática ainda é a melhor solução. O trabalho em equipe também é uma
forma excelente de definir uma arquitetura. Muitas vezes, alguns programadores
possuem outras experiências ou conhecimentos e a troca dessa experiência é
sempre válida, mesmo quando temos um arquiteto bastante experiente na equipe.
A arquitetura de um sistema tem diversos elementos como: elementos

utilitários, elementos de interação, elementos que fazem parte do domínio do
problema, elementos de conexão, elementos de persistência etc. Dessa forma, na
arquitetura sempre definimos os seus elementos que precisarão ser utilizados no
software e como eles se conectam. Uma arquitetura complexa exige mais tempo
para desenvolvimento, porém, através de geração automática de aplicações isso
pode se tornar mais produtivo. Por isso algumas equipes definem um framework
para uma determinada aplicação, assim podemos utilizar muitas coisas pré-
prontas que facilitam o desenvolvimento.
53
No entanto, alguns padrões arquiteturais já foram pensados para resolver

problemas corriqueiros. Alguns projetos ou organizações combinam esses
padrões arquiteturais, pois atendem melhor às suas necessidades ou deram
certo para o seu tipo de aplicação. Por isso é sempre interessante entender as
características básicas de cada um dos estilos e escolher ou combinar aqueles que
atendem melhor às necessidades de um projeto específico, isso tudo deve ser feito
após uma análise do sistema a ser desenvolvido. Entre as arquiteturas existentes
temos: Cliente-servidor, P2P - Peer to Peer, Dados compartilhados, Máquina
virtual, Camadas, MVC e muitos outros.
No restante do artigo veremos mais sobre o padrão arquitetural MVC

(Model-View-Controller) que é um dos mais antigos e mais utilizados atualmente.
2 Padrão Model-View-Controller
O padrão arquitetural Model-View-Controller (MVC) é uma forma de

quebrar uma aplicação, ou até mesmo um pedaço da interface de uma aplicação,
em três partes: o modelo, a visão e o controlador.
O MVC inicialmente foi desenvolvido no intuito de mapear o método

tradicional de entrada, processamento, e saída que os diversos programas baseados
em GUI utilizavam. No padrão MVC, teríamos então o mapeamento de cada uma
dessas três partes para o padrão MVC conforme ilustra a imagem abaixo:
FIGURA 1: MAPEAMENTO DAS TRÊS PARTES DE UMA APLICAÇÃO PARA O MVC
A figura abaixo demonstra que a entrada do usuário, a modelagem do

mundo externo e o feedback visual para o usuário são separados e gerenciados
pelos objetos Modelo (Model), Visão (View) e Controlador (Controller).
FIGURA 2: OBJETOS UTILIZADOS NO MVC E SUAS INTERAÇÕES
54
Explicando cada um dos objetos do padrão MVC tem-se primeiramente o

controlador (Controller) que interpreta as entradas do mouse ou do teclado enviado
pelo usuário e mapeia essas ações do usuário em comandos que são enviados para
o modelo (Model) e/ou para a janela de visualização (View) para efetuar a alteração
apropriada. Por sua vez o modelo (Model) gerencia um ou mais elementos de
dados, responde a perguntas sobre o seu estado e responde a instruções para mudar
de estado. O modelo sabe o que o aplicativo quer fazer e é a principal estrutura
computacional da arquitetura, pois é ele quem modela o problema que está se
tentando resolver. Por fim, a visão (View) gerencia a área retangular do display
e é responsável por apresentar as informações para o usuário através de uma
combinação de gráficos e textos. A visão não sabe nada sobre o que a aplicação está
atualmente fazendo, tudo que ela realmente faz é receber instruções do controle e
informações do modelo e então exibir elas. A visão também se comunica de volta
com o modelo e com o controlador para reportar o seu estado.
Tão importante quanto explicar cada um dos objetos do padrão arquitetural

MVC é explicar como é o seu fluxo tipicamente. Primeiramente o usuário interage
com a interface (por exemplo, pressionando um botão) e o controlador gerenciar
esse evento de entrada da interface do usuário. A interface do usuário é exibida
pela visão (view), mas controlada pelo controlador. O controlador não tem
nenhum conhecimento direto da View, ele apenas envia mensagens quando ela
precisa de algo na tela atualizado. O controlador acessa o modelo, possivelmente
atualizando ela de forma apropriada para as ações do usuário (por exemplo, o
controlador solicita ao modelo que o carrinho de compras seja atualizado pelo
modelo, pois o usuário incluiu um novo item). Isto normalmente causa uma
alteração no estado do modelo tanto quanto nas informações. Por fim, a visão
usa o modelo para gerar uma interface com o usuário apropriada. A visão recebe
as informações do modelo. O modelo não tem conhecimento direto da visão.
Ele apenas responde a requisições por informações de quem quer que seja e
requisita por transformações nas informações feitas pelo controlador. Após isso,
o controlador, como um gerenciador da interface do usuário, aguarda por mais
interações do usuário, onde inicia novamente todo o ciclo.
Portanto, a principal ideia do padrão arquitetural MVC é a separação

dos conceitos - e do código. O MVC é como a clássica programação orientada a
objetos, ou seja, criar objetos que escondem as suas informações e como elas são
manipuladas e então apresentar apenas uma simples interface para o mundo. Entre
as diversas vantagens do padrão MVC estão a possibilidade de reescrita da GUI
ou do Controller sem alterar o nosso modelo, reutilização da GUI para diferentes
aplicações com pouco esforço, facilidade na manutenção e adição de recursos,
reaproveitamento de código, facilidade de manter o código sempre limpo etc.
3 Implementação do MVC
Existem diversos frameworks para Java que implementam o padrão

MVC e são muito utilizados em diversos projetos. Entre eles temos o JSF, Struts
1 e Struts 2, Spring MVC, Play Framework, Tapestry, e diversos outros. Existem
55
diversos artigos e sites especializados que comparam as diferenças e vantagens

entre esses diferentes frameworks. No entanto, o melhor é sempre verificar o que
cada framework disponibiliza para os desenvolvedores e analisar se ele atende às
nossas expectativas.
Outras linguagens/plataformas também possuem frameworks que

aderem ao padrão arquitetural MVC. Isso não inviabiliza que uma equipe crie
o seu próprio framework, mas é preciso lembrar que um desenvolvedor novo
precisa de tempo para aprender a desenvolver em determinada arquitetura
e caso a empresa/projeto já utilize um framework bastante popular a curva de
aprendizado será bem menor ou praticamente nula. Isso inclusive ajuda na
contratação de novos funcionários, onde a empresa já pode exigir como pré-
requisito conhecimentos neste framework.
4 Conclusão
Neste artigo, vimos o que é a arquitetura de software, quais são seus

elementos, o que são as suas interações. Também vimos mais detalhadamente o
padrão de arquitetura de software MVC (Model-View-Controller) que é muito
utilizado nos projetos de software. Analisamos os seus elementos e como eles
interagem entre si e, além disso, vimos as principais vantagens de adotar um
padrão como o MVC que se caracteriza pela facilidade na obtenção de múltiplas
visões dos mesmos dados, desacoplar a interface da lógica da aplicação, entre
outras vantagens. No entanto, vimos que definir a arquitetura de um software
é ainda mais do que escolher o seu padrão arquitetural, precisamos definir a
tecnologia (JEE ou .Net), linguagens a integrar, forma de persistência, interfaces
com o usuário e muito mais. Dessa forma, devemos sempre reunir o máximo de
pessoas experientes possíveis, conhecimentos, análise do projeto, todos os seus
requisitos funcionais e não funcionais, a fim de definirmos a melhor arquitetura
possível para o software que está sendo desenvolvido.
56
RESUMO DO TÓPICO 3
Neste tópico vimos que:
• O Java Server Faces (JSF) é o framework padrão da plataforma Java para a

construção de aplicações web com JEE.
• Da mesma forma que as demais tecnologias que fazem parte da plataforma

Java, o JSF é definido por uma especificação mantida pelo JCP através de JSRs.
• O JSF funciona baseado em objetos que são mantidos em memória no servidor e

que ficam responsáveis pela geração do HTML que será enviado ao navegador.
• Note que este mapeamento de um componente de formulário diretamente

para um atributo e de um botão diretamente para um método aumenta muito
a produtividade no desenvolvimento.
• O JSF funciona através de uma arquitetura MVC, o que exige a presença de um

intermediário entre o model e a view. Este intermediário é o controller, que no
caso do JSF é chamado de Managed Bean (MB).
• Cabe ao MB mapear os componentes para o model, instanciar os objetos no

lado do servidor e também reagir aos eventos gerados na view.
• O MB sempre é uma classe serializável com métodos getters e setters para

permitir o acesso aos componentes visuais.
• No escopo marcado pela anotação @SessionScoped o tempo de vida do MB é

marcado pela sessão do usuário. Caso nenhuma configuração adicional seja
feita, o MB se mantém desde pressionarmos o botão até fecharmos o navegador.
O escopo de Sessão é interessante para guardar uma sessão de login do usuário,
garantindo que ele tenha passado por uma página e se identificado antes de
acessar a parte protegida de uma aplicação.
57
AUTOATIVIDADE
1 Implemente a aplicação que utilizamos ao longo do capítulo para demonstrar

os conceitos e execute-a. Liste e descreva o que ocorre quando ela passa por
cada etapa do ciclo de vida do JSF.
2 Diferencie e descreva a aplicabilidade das anotações @RequestScoped e @

SessionScoped.
3 Implemente uma aplicação que contenha uma tela de login e senha

utilizando o JSF. Deve existir um MB que verifica os valores para ver se são
iguais a “admin” para o login e “admin” para a senha. Após a validação ou
não dos valores, uma mensagem deverá ser exibida no console do AS.
58
UNIDADE 2
COMPONENTES GRÁFICOS DO
JAVA SERVER FACES E JAVA
PERSISTENCE API
Ao final desta unidade você será capaz de:
• elaborar interfaces gráficas para web utilizando o Java Server Faces e seus
componentes gráficos.
• identificar o componente adequado para cada situação, de forma a

otimizar os recursos da tecnologia.
• persistir o estado de objetos em um banco de dados relacional através da

Java Persistence API.
PLANO DE ESTUDOS
Esta unidade de ensino está dividida em três tópicos, sendo que no final
de cada um deles, você encontrará atividades que contribuirão para a
TÓPICO 1 – COMPONENTES GRÁFICOS DO JAVA SERVER FACES
TÓPICO 2 – JAVA PERSISTENCE API (JPA)
59
60
UNIDADE 2
TÓPICO 1
COMPONENTES GRÁFICOS DO JAVA SERVER FACES
1 INTRODUÇÃO
Conforme já estudamos na unidade anterior, o Java Server Faces pode ser
definido como um framework de componentes de servidor para aplicações web
que funciona de acordo com o padrão MVC. Suas principais características e
funcionalidades são: api que representa componentes de interface gráfica e seu
estado, gerenciamento de eventos, validação e conversão de dados no servidor,
navegação entre páginas, internacionalização e extensibilidade para praticamente
todos os componentes (ORACLE, 2010).
Nesta unidade daremos ênfase aos principais componentes de interface

gráfica e sua utilização em aplicações web, demonstrando o relacionamento destes
componentes com os Managed Beans e com as funcionalidades de validação e
conversão no lado do servidor. Não é nossa intenção esgotar o tema, visto que
o JSF é uma especificação bastante extensa, mas sim capacitar você, acadêmico,
para a utilização prática destes componentes em aplicações web. Sempre que
mais recursos sobre a tecnologia estiverem disponíveis, estes serão sinalizados
para que você possa complementar nossos estudos.
2 COMPONENTES DE FORMULÁRIO
Para demonstrar os componentes faremos a simulação de uma tela de
cadastro de pessoa, conforme a Figura 50. Esta mesma interface será utilizada
posteriormente para o JPA no Tópico 2 desta unidade, persistindo estas informações
em um banco de dados relacional.
61
UNIDADE 2 | COMPONENTES GRÁFICOS DO JAVA SERVER FACES E JAVA PERSISTENCE API
FIGURA 50 - INTERFACE GRÁFICA PARA O CADASTRO DE PESSOA
FONTE: O autor
Na figura podemos observar que estão sendo utilizados diversos

componentes gráficos, como campos de texto, áreas de texto, radio buttons e
combo boxes. Cada um destes componentes que é renderizado como HTML é na
verdade um componente do JSF que é criado no servidor e obedece ao ciclo de
vida que vimos na Unidade 1.
Vamos começar pela entidade Pessoa, que é o objeto a ser gerenciado

pelo JSF. Crie um novo Dynamic Web Project no Eclipse, exatamente da mesma
forma como criamos na unidade anterior. A Figura 51 destaca quais as bibliotecas
e frameworks que devem ser selecionados na configuração do projeto. Esta
configuração é importante, pois dará suporte a diversas funcionalidades que
utilizaremos na criação do protótipo.
Uma vez que o projeto esteja configurado corretamente, crie um pacote

com o nome br.com.nead.model e dentro deste pacote uma classe Pessoa, com os
atributos mostrados na Figura 52.
62
TÓPICO 1 | COMPONENTES GRÁFICOS DO JAVA SERVER FACES
FIGURA 51 - CONFIGURAÇÃO DO PROJETO
FONTE: O autor
Nossa classe Pessoa servirá como entidade para a tela de cadastro

e para outras tecnologias que veremos ao longo deste caderno, portanto a
implementaremos conforme o padrão Java Bean. Este padrão define que para ser
considerada um Java Bean, uma classe deverá obedecer às seguintes restrições:
• Todos os atributos devem ser privados, com getters e setters.

• Deve possuir no mínimo um construtor default vazio, embora possa ter mais
construtores e métodos auxiliares.
• Deve implementar a interface Serializable.
E
IMPORTANT
A especificação Java Bean define um padrão para a criação de entidades na

linguagem de programação Java. Atualmente, diversos framworks como JPA, EJB e JSF
dependem desta especificação. Maiores detalhes sobre esta especificação podem ser obtidos
em: <http://www.oracle.com/technetwork/java/javase/documentation/spec-136004.html>.
63
FIGURA 52 - CLASSE PESSOA
FONTE: O autor
Um aspecto interessante é que, apesar de implementarmos a interface

Serializable, não implementamos nenhum método. Este tipo de interface é
conhecido como interface marcadora, onde a implementação implica que algo
pode ser feito com a classe. Neste caso, indica que uma instância pode ser
convertida em um array de bytes (serializada).
Note que existe uma discrepância entre a classe Pessoa e a interface gráfica
que criamos para o cadastro desta pessoa. Descobriu? Olhe novamente que eu
aguardo você aqui. Pois é, na tela de cadastro não existe o atributo id, presente
na entidade. Este atributo servirá como chave primária do objeto, uma vez que
este for persistido e faremos com que o JPA cuide da geração e gerenciamento
deste, ocultando-o de quem for utilizar a aplicação. Demonstraremos esta
funcionalidade com maiores detalhes na Unidade 3.
Não se esqueça de criar os getters e setters para todos os atributos em seu

projeto. É recomendável, ainda, criar os métodos equals e hashcode pelo atributo id
e um método toString. Lembre-se de que o Eclipse faz tudo isto automaticamente
para você. Se quiser criar construtores adicionais, fique à vontade.
Para o funcionamento do JSF, é sempre necessária a criação de um Managed

Bean, que funcionará como controlador entre a interface gráfica e a entidade.
No exemplo da unidade anterior, nosso model era composto simplesmente por
uma String e o managed bean fornecia acesso à mesma. Neste exemplo, o managed
bean terá que fornecer acesso a uma instância inteira de pessoa. Vamos para a
implementação? Acompanhe na Figura 53.
64
FIGURA 53 - MANAGED BEAN
FONTE: O autor
Novamente utilizamos as anotações para marcar a classe PessoaMB. A

anotação de sessão pode ser substituída aqui por uma de request sem prejuízo
momentâneo para nossa aplicação. Na linha 24 temos o atributo que representa a
entidade pessoa. Como esta entidade é privada, precisamos novamente dos getters
e setters. Estes getters e setters transformam pessoa em uma propriedade e, através
dela, é possível acessar também todos os seus atributos. Note que esta classe
também segue o padrão Java Bean. Mais adiante faremos nesta classe um método
para validar o formato do e-mail e também para converter uma enumeração para
um radio button.
Como última etapa, criaremos passo a passo a interface gráfica que será
suportada por estas classes. Clique com o botão direito na pasta Web Content e
selecione a opção New XHTML Page, chamando-a de cadastro. Parte do código
fonte para esta página pode ser visto na Figura 54.
65
FIGURA 54 - PARTE DO CÓDIGO FONTE PARA A PÁGINA DE CADASTRO
FONTE: O autor
Até a linha 11, com exceção da mensagem de título, o código é gerado pelo
Eclipse. Na linha 13 utilizamos o componente formulário, visto que o objetivo
central desta página é exibir um formulário que permita o cadastro de dados
de uma pessoa. Na linha 14, utilizamos um componente de mensagens. Este
componente fará com que todas as mensagens de validação sejam exibidas neste
local da página. Caso este componente não exista, cada mensagem será exibida
próxima ao componente onde a validação não foi realizada com sucesso.
Para alinharmos os componentes da página em duas colunas, utilizamos

o PanelGrid, que funciona determinando o número de colunas para cada linha de
componentes. Neste caso, a cada dois componentes é feita uma quebra de linha.
Na linha 16 utilizamos um componente do tipo facet conhecido como header. Este
componente não segue as determinações do panelGrid e utiliza a linha inteira.
Nas linhas 20 e 21 estão os componentes que formarão a primeira linha

de nossa tela de cadastro. O componente outputText simplesmente imprime a
String “Nome” e é associado através do atributo for ao componente chamado de
itNome. Na linha 20 é definido o componente inputText, com função análoga à do
HTML. Algumas ressalvas são importantes aqui. O atributo name indica que o
outputText anterior está associado a este campo de texto. O atributo required faz
com que o preenchimento deste seja obrigatório, causando uma mensagem de
erro caso o mesmo não seja preenchido. Caso o atributo requiredMessage não seja
preenchido, a mensagem-padrão de erro é retornada em caso de erro. O atributo
size define o tamanho do campo e o atributo value associa este campo de texto
66
automaticamente ao valor do atributo nome, da classe pessoa, acessada pelo

managed bean. Esta associação acontece através da instrução “#{pessoaMB.pessoa.
nome}”. Por padrão, o nome da instância do managed bean é o mesmo da classe, só
que iniciando com letra minúscula. O mesmo ocorre para o objeto pessoa e seus
atributos, acessados aqui como propriedades.
Na linha 25 começamos novamente com o outputText para a segunda linha do

formulário. Os atributos de validação são semelhantes aos do componente anterior,
mas neste componente fazemos uso de uma funcionalidade de conversão e outra de
validação. Na linha 30 convertemos o valor do campo para um número (lembre-se de
que tudo que vem de um formulário HTML é originalmente String) usando atributos
para definir seu formato e locale (localização). Na linha 31 utilizamos um componente
de validação de valores máximo e mínimo, definindo-os arbitrariamente.
Nas linhas 34 a 37 fazemos uso novamente do facet, colocando dois botões

dentro deste. Os command buttons serão associados a métodos dentro do managed bean.
A Figura 55 mostra as mensagens de erro e a interface de cadastro até

aqui. Perceba que a validação que colocamos não foi realizada com sucesso para
os campos e as mensagens de texto foram exibidas agrupadas em um só local.
E
IMPORTANT
Tanto o Eclipse quanto o Netbeans permitem a criação automática de Managed

Beans e interfaces através de classes de entidade. Nosso foco neste momento não é a
produtividade, mas sim a compreensão e por este motivo estamos criando tudo manualmente.
FIGURA 55 - MENSAGENS DE VALIDAÇÃO
FONTE: O autor
67
Dando continuidade ao formulário de cadastro, agora criaremos o

componente de área de texto e dois inputs com estratégias distintas para validação.
O código fonte para estes componentes pode ser visto na Figura 56. Este código
fonte poderá ser digitado a partir da linha 33 do código mostrado na Figura 54.
FIGURA 56 - CONTINUAÇÃO DA INTERFACE DE CADASTRO
FONTE: O autor
Entre as linhas 34 e 39 colocamos um componente de área de texto, análogo

ao componente do HTML. A diferença, neste caso é que tivemos que utilizar
um componente chamado de panelGroup para podermos colocar mais de dois
componentes em uma mesma linha. O panelGrid que mostramos anteriormente
estabelece a utilização de somente dois componentes em uma só linha para todo o
nosso formulário. Mas e se eu quiser colocar uma mensagem de auxílio ao usuário
ao lado de alguns componentes? Esta é exatamente a situação demonstrada acima.
Perceba que colocamos dois componentes outputText e um componente textArea,
totalizando três componentes. Neste caso, colocamos dois ou mais componentes
dentro de um panelGroup, pois este permite a colocação de quantos componentes
você quiser ao mesmo tempo que é percebido pelo panelGrid externo como um
componente único.
O componente de email (linhas 41 até 48) é um inputText como os demais,

com a ressalva de que agora estabelecemos um validador personalizado e
novamente usamos o panelGroup. Perceba que o atributo validador é relacionado
com um método existente dentro de pessoaMB. Esta é uma característica
importante do JSF: ele permite a criação de validadores personalizados para os
componentes, colocando-os dentro do managed bean. E se eu tiver meus métodos
de validação dentro da entidade? Basta você chamar a entidade referenciada pelo
managed bean e invocar o método. A Figura 57 ilustra o código-fonte deste método,
que deve ser colocado dentro da classe PessoaMB.
68
FIGURA 57 - MÉTODO PARA VALIDAÇÃO DE EMAIL
FONTE: O autor
A assinatura do método de validação não muda, bastando a você escrever

o código da validação e a mensagem de retorno. Neste caso a validação é bastante
simples, perguntando somente se existe o símbolo “@” na String recebida. O
detalhe é que esta implementação é adicionada ao ciclo de vida do JSF de forma
transparente e será executada junto com as demais validações.
Por fim, utilizamos um inputText para registrar a data de nascimento da

pessoa, convertendo automaticamente o valor do campo para um DateTime com
o padrão descrito (dd/MM/yyyy). A Figura 58 mostra como fica a interface até o
momento, ilustrando o email inválido colocado propositalmente.
FIGURA 58 - VALIDAÇÃO DO EMAIL
FONTE: O autor
E
IMPORTANT
É possível criar classes específicas para a validação do valor de determinado

componente. Uma implementação exemplo deste tipo de funcionalidade pode ser acessada
em: <http://www.mkyong.com/jsf2/custom-validator-in-jsf-2-0/>.
69
Para encerrar nosso cadastro de pessoa, colocaremos um campo do tipo

combo box e um campo do tipo radio button, este último alimentado por um enum
que representa o sexo da pessoa. O código-fonte para estes componentes está
demonstrado na Figura 59, e deve ser inserido logo após o código da Figura 56.
FIGURA 59 - COMPONENTES COMBO BOX E RADIO BUTTON
FONTE: O autor
Na linha 58 criamos o componente radio button, escolhendo aquele que

somente permite a seleção de um valor para o sexo. Este valor está atrelado ao
atributo sexo da classe Pessoa. É possível criar manualmente os valores e colocar
um a um, mas neste caso fizemos uso de uma funcionalidade que alimenta o
componente selectItems automaticamente de acordo com o enum. Isso significa
que, em caso de alteração do enum, o radio button é automaticamente alterado.
Para que o componente seja exibido corretamente, são necessários dois passos:
1) Criação do enum que representa o sexo (Figura 60).

2) Implementação do método que permite a alimentação do componente de
forma automática (Figura 61) na classe PessoaMB.
FIGURA 60 - ENUMERAÇÃO PARA O SEXO
FONTE: O autor
70
FIGURA 61 - MÉTODO QUE FAZ O BINDING ENTRE O RADIO BUTTON E O ENUM
FONTE: O autor
Perceba que o nome do método é getSexos, o que implica que o

componente fará uma chamada através da instrução “#{pessoaMB.sexos}”,
demonstrada na linha 59.
E
IMPORTANT
Para o Cargo, o ideal seria criar uma nova classe com um id e uma descrição.
Por motivos de simplificação, deixaremos esta implementação para as autoatividades.
Quanto ao componente combo box, optamos por fazer a inicialização manual

do mesmo, embora um procedimento semelhante ao do radio button funcionaria
da mesma forma. Entre as linhas 65 e 69 é feita a criação do componente, através
do selectOneMenu e dos diversos selectItems, que representam os itens mostrados
no comboBox. O atributo itemValue indica o que será enviado para o objeto pessoa,
enquanto o atributo itemLabel representa o texto que será exibido para cada item.
Uma vez concluída a codificação, nossa interface para cadastro de

usuário fica conforme está ilustrado na Figura 62. Os botões Salvar e Novo são
componentes do tipo commandButton, ou seja, são associados a algum método da
classe PessoaMB que reflita sua funcionalidade.
FIGURA 62 - CADASTRO DE PESSOA
FONTE: O autor
71
Criaremos um método para demonstrar o objeto que acabamos de salvar

e outro para apagar o conteúdo dos campos preenchidos na tela e criar um novo
objeto. O código fonte para estes métodos está demonstrado na Figura 63. Note
que a implementação é simples para ambos os métodos com o objetivo único de
demonstrar a associação.
FIGURA 63 - MÉTODOS DE AÇÃO DOS BOTÕES
FONTE: O autor
A última etapa consiste em associar o atributo action dos commandButtons

com os métodos respectivos, fazendo com que o usuário acione uma ação ao clicá-
los. O código-fonte para esta associação está listado na Figura 64. Basta inserir a
action no código-fonte já existente para os commandButtons.
FIGURA 64 - BINDING DOS MÉTODOS AOS BOTÕES
FONTE: O autor
Para encerrar este tópico, faremos a demonstração de um objeto completo

sendo salvo, com a mensagem escrita no console. Lembre-se de que para
imprimir o objeto pessoa, há a necessidade de se criar o método toString dentro
do mesmo, caso contrário imprimiremos somente o full qualified name do objeto
e o endereço do mesmo. Nossa sugestão é de que você gere o toString através do
Eclipse, colocando todos os atributos para verificar se a associação entre a tela, o
managed bean e o objeto pessoa foi feita corretamente. Para testarmos a interface
de cadastro, salvaremos os dados de uma pessoa (Figura 65) e mostraremos o
resultado no console (Figura 66) ao pressionarmos o botão salvar. O id possui
o valor null, pois ainda não foi feita a utilização do JPA para gerar este valor
de forma automática, como uma chave surrogada e a data foi convertida para o
formato DateTime do Java.
72
E
IMPORTANT
Uma chave surrogada é um campo que não existe na entidade modelada,

servindo apenas como chave primária em uma tabela relacional, no sentido de facilitar
relacionamentos com outras tabelas.
FONTE: O autor
FIGURA 66 - SAÍDA NO CONSOLE
FONTE: O autor
3 TABELAS
Um dos componentes mais utilizados em interfaces web com JSF é o
DataTable. Sua função consiste em receber uma listagem de objetos, consumindo-a
e montando um grid de dados, a partir do qual é possível editar ou mesmo
remover objetos da listagem. Em nosso caso, esta interface complementará o
cadastro da pessoa, permitindo a visualização, alteração e remoção dos mesmos.
73
Como ainda não dispomos de um mecanismo de persistência,

simularemos uma listagem de pessoas diretamente na classe PessoaMB, local de
onde o DataTable buscará suas informações. Futuramente, este método sofrerá
uma alteração e fará acesso a uma fonte de dados. É importante criar este método
de forma transparente para a view, ou seja, a alteração futura terá o mínimo de
impacto para a aplicação como um todo.
Inicialmente faremos a criação de uma lista que supostamente trará objetos

do tipo Pessoa dentro da classe PessoaMB. Criamos três objetos, você pode criar
quantos quiser (Figura 67).
FIGURA 67 - SIMULAÇÃO DO MECANISMO DE PERSISTÊNCIA
FONTE: O autor
Agora, você deve criar um novo arquivo XHTM, dentro da pasta

WebContent, chamado listagemDePessoas. Neste arquivo criaremos o código-
fonte que será apresentado para o usuário, dividido em duas partes:
1) A DataTable propriamente dita.

2) O formulário para alteração dos objetos do tipo Pessoa.
A Figura 68 mostra o código-fonte para a criação da DataTable, a partir do

componente <h:body>. Lembre-se de que a parte inicial do arquivo é criada pelo
template do Eclipse. Você perceberá que parte dos atributos do objeto e parte do
código-fonte foram omitidos para fins de simplicidade.
74
FIGURA 68 - CÓDIGO FONTE PARA A CRIAÇÃO DO DATATABLE
FONTE: O autor
O componente DataTable foi colocado dentro de um componente <h:form>

(linha 13), pois utilizaremos esses dados para alterar e remover objetos da lista. A
criação do DataTable propriamente dita ocorre na linha 14. Note os atributos value
e var. O primeiro remete à fonte de alimentação da tabela e o segundo remete ao
tipo de objeto que populará cada linha da tabela. A única restrição é que o tipo de
var deve ser igual ao tipo contido na lista que alimenta a tabela. No nosso caso, o
método do managed bean retorna uma lista de Pessoas e cada pessoa é listada em
uma linha da tabela, conforme a Figura 69. A variável pessoa representa o objeto
e dá acesso às propriedades do mesmo.
O número de colunas é determinado pelos número de componentes

<h:column> que é colocado dentro da DataTable. Perceba que criamos facets
do tipo Header para cada atributo, com componentes outputText distintos para
descrevê-los e para conter o valor do atributo de cada objeto. Na última coluna são
colocados os botões para acionar os métodos que alteram ou excluem as pessoas
da lista. Esta implementação será mostrada mais adiante.
75
FIGURA 69 - LISTAGEM DE PESSOAS
FONTE: O autor
O botão remover simplesmente remove a pessoa da lista que alimenta a

dataTable, enquanto o botão editar altera as informações do objeto selecionado. Para
realizar esta alteração com um objeto, necessitamos de um formulário que permita
a colocação de novos dados. Mas espere aí...nós já implementamos este formulário
quando criamos o cadastro de pessoas e tudo que temos a fazer é reutilizá-lo.
Antes de sair abrindo o arquivo cadastro.xhtml para copiar e colar o

código (argh!!!), vamos pensar um pouco. Em aplicações web é extremamente
comum sermos redirecionados a uma nova página após completar alguma ação,
como finalizar um cadastro ou fazer um pagamento. É exatamente este tipo de
comportamento que precisamos aqui. Ao clicar no botão editar, precisamos “levar”
o objeto para nossa interface de cadastro e lá fazer as alterações que desejamos.
Aqui é que entra uma das características do JSF que facilita o trabalho
dos desenvolvedores. Em outras linguagens de programação, você precisaria
colocar o objeto em uma variável de sessão (ou manter o estado dela de alguma
forma) e então fazer o redirecionamento manual da página, o que é relativamente
trabalhoso e entediante. Lembre-se de que o controlador do JSF é o managed bean,
então, se conseguirmos colocar o objeto que está na tabela dentro da variável
gerenciada por ele, já temos o que precisamos e precisaremos somente fazer o
redirecionamento. Basta mudar a assinatura de nosso método editar e fazer com
que ele retorne uma String com o nome do arquivo para onde queremos ir. Em
nosso caso, a mudança está ilustrada na Figura 70.
FIGURA 70 - ALTERAÇÃO DO MÉTODO EDITAR
FONTE: O autor
76
Basta salvar e tentar acessar novamente o arquivo de listagem de pessoas.

Ao clicar no botão editar em qualquer uma das linhas, os dados do objeto
selecionado serão mostrados na interface de cadastro (Figura 71). Logicamente, ao
alterarmos os dados nada acontece, pois, nosso sistema de persistência é somente
simulado dentro do managed bean e não inclui a operação de salvamento.
FIGURA 71 - ALTERAÇÃO DE PESSOA
FONTE: O autor
E
IMPORTANT
Nem sempre o simples salvamento do arquivo e novo acesso a URL traz

as atualizações do código fonte no servidor. Caso isso aconteça, encontre a aba Servers
no Eclipse, expanda seu servidor e clique com o botão direito do mouse no projeto. Ao
selecionar a opção Full Publish, o contexto antigo é substituído pelo novo, garantindo que as
mudanças estejam refletidas no servidor.
Para deixar nosso CRUD mais completo, adicionaremos uma página

inicial e links que permitam a navegação. O componente que funciona como link
é chamado de outputLink e tem o comportamento similar ao dos links do HTML.
Existe um outro tipo de link, conhecido como commandLink, mas este possui
comportamento similar aos componentes do tipo commandButton.
Criaremos um novo arquivo XHTM, chamado de index.xhtml, cujo

código fonte está na Figura 72. Os componentes outputLink possuem dentro um
componente outputText, que contém o texto que descreve o link. Para exercitar,
sugerimos que você coloque nos arquivos cadastro e listagemDePessoas um link
que permita voltar à página inicial, conforme o exemplo mostrado na Figura 73.
77
FIGURA 72 - PÁGINA INICIAL
FONTE: O autor
FIGURA 73 - LINK QUE PERMITE RETORNO À PÁGINA INICIAL
FONTE: O autor
4 SUPORTE NATIVO A AJAX

Conforme SOFTPLAN (2015), AJAX é o acrônimo para asyncronous javascript
and XML, uma técnica utilizada para capturar eventos em uma página web e enviar
requisições para o servidor sem a necessidade de submeter a página inteira. Na
prática, isto significa que o ciclo request/response do servidor ocorre de forma mais
transparente ao usuário, deixando a aplicação mais agradável de usar.
O JSF possui suporte nativo à AJAX desde a versão 2.0, o que facilita mais
uma vez o trabalho dos desenvolvedores. Faremos uma alteração simples em
nosso exemplo para demonstrar de que forma o JSF interage com o AJAX. Vamos
supor que exista uma regra de negócio em nosso sistema que, caso a pessoa seja
do sexo FEMININO, seu salário é aumentado em 10%. Para implementar esta
funcionalidade, precisamos de duas alterações em nosso exemplo:
1) Colocar o código que faz o bind do AJAX com o componente (Figura 74).
2) Escrever o método no managed bean para alterar o salário (Figura 75).
78
FIGURA 74 - AJAX
FONTE: O autor
Conforme ilustrado na Figura 74, a alteração será feita no combo box que
define o sexo da pessoa. Perceba que queremos ativar um método utilizando ajax
sempre que o sexo for selecionado ou alterado (event=”change”). O atributo listener
define qual método será ouvinte deste evento, enquanto os atributos render e
execute informam qual o id do componente que será renderizado. O JSF permite
a utilização de AJAX com métodos no managed bean para os seguintes eventos:
• Formulários: change, focus e blur.

• Teclado: keydown, keyup e keypress.
• Mouse: click, mousedown, mouseup, mouseover, mouseout e mousemove.
Na linha 99 utilizamos um componente do tipo UIInput para armazenar o

objeto que deu origem ao evento, o combo box. Na linha 101, obtemos o valor deste
componente e o convertemos para um enum. Na linha 103, definimos o valor do novo
salário de acordo com o sexo selecionado e por fim, na linha 105, a pessoa recebe o
novo salário. Nas linhas 101 e 103 utilizamos expressões ternárias para a atribuição.
FIGURA 75 - AJAX NO MANAGED BEAN
FONTE: O autor
E
IMPORTANT
Uma expressão ternária é uma maneira mais simples de atribuir um valor a

uma variável que depende de uma condição if else. Maiores detalhes podem ser obtidos em:
http://www.guj.com.br/java/106380-operador-condicional-ternario
79
Uma vez prontas as alterações, podemos proceder com o teste da

funcionalidade. Basta reexecutar a aplicação e cadastrar uma nova pessoa do sexo
Feminino e o salário dela será acrescido em 10% sem a necessidade de a página
carregar totalmente (Figura 76).
FIGURA 76 - ALTERAÇÃO DO SALÁRIO VIA AJAX
FONTE: O autor
5 ADICIONANDO UMA BIBLIOTECA EXTERNA DE

COMPONENTES VISUAIS
O JSF permite que você modifique o layout dos componentes da interface
gráfica através de bibliotecas visuais de terceiros. Estas bibliotecas facilitam o
trabalho de deixar a aplicação mais agradável para os usuários, pois eliminam o
css e demais frameworks como o bootstrap.
Existem algumas bibliotecas de terceiros que são bastante conhecidas e

utilizadas em JSF, com destaque para o ICE Faces, o Rich Faces e o Prime Faces.
Neste tópico demonstraremos como alterar a interface de nossa aplicação para
cadastro de pessoas através da adição de componentes do Prime Faces. O website
do projeto pode ser visto na Figura 77.
A empresa que desenvolve o Prime Faces disponibiliza diversos layouts e

temas pré-prontos, entretanto, a maioria deles é paga. Para observar a diversidade
dos componentes oferecidos pela biblioteca, acesse a url: <http://www.primefaces.
org/showcase/>. Neste endereço, você poderá ver demonstrações funcionais dos
componentes, sempre com o código-fonte ao lado, ilustrando sua utilização.
80
FIGURA 77 - WEBSITE DO PRIMEFACES
FONTE: O autor
As Figuras 78, 79 e 80 mostram os componentes calendar, chart e accordion,

respectivamente:
FIGURA 78 - COMPONENTE CALENDAR
FONTE: Disponível em: <http://www.primefaces.org/showcase/>.

Acesso em: 30 out. 2015.
81
FIGURA 79 - COMPONENTE CALENDAR

FIGURA 80 - COMPONENTE ACCORDION

Para utilizar estes e outros componentes, a primeira etapa consiste

em fazer o download da biblioteca do Prime Faces, disponível na URL: <http://
mvnrepository.com/artifact/org.primefaces/primefaces/5.0>. Faça o download do
arquivo .jar e o adicione ao projeto do Eclipse. Para adicioná-lo, basta copiar o
arquivo para a pasta WEB-INF/lib de seu projeto, conforme a Figura 81.
82
FIGURA 81 - CONFIGURAÇÃO DO PRIME FACES
FONTE: O autor
Conforme aprendemos no início do estudo sobre JSF, existem prefixos

que devem ser informados no início de um arquivo xhtml e que permitem a
utilização dos componentes, de acordo com a sua natureza. Com o Prime Faces
não é diferente...para utilizar os componentes desta biblioteca, adicionaremos o
prefixo p: em todos os arquivos xhtml que a utilizarão (Figura 82).
FIGURA 82 - PREFIXO P NO INÍCIO DAS PÁGINAS
FONTE: O autor
Para ilustrar o funcionamento do Prime Faces, utilizaremos nossa

interface de Cadastro de Pessoas e trocaremos três componentes padrão do JSF
por componentes Prime Faces. O código fonte para a troca dos componentes é
mostrado na Figura 83.
Neste exemplo utilizamos o componente inputText do Prime Faces (linha

46), alterando o prefixo para p:. Para os componentes que são similares aos do
JSF, a única substituição a ser feita é esta. Note que o restante do código fonte
permanece inalterado. A segunda alteração que fizemos foi a substituição do
inputText do JSF pelo Calendar do Prime Faces (linha 55). Neste caso, como não
possuímos componentes análogos no JSF, vale a pena observar os atributos.
O atributo mode define o layout do calendário. Uma vez que você tiver feito o
teste com estes componentes, substitua o valor “inline” por “popup” e perceba a
diferença. Por fim, alteramos um componente do tipo selectOneMenu (linha 74),
mantendo seus itens inalterados.
83
FIGURA 83 - ALTERAÇÃO DOS COMPONENTES
FONTE: O autor
Execute o arquivo index.xhtml e veja a diferença (Figura 84). Os inputs

apresentam um tamanho de fonte maior, bordas arredondadas e são circulados
em vermelho quando ganham o foco. O componente Calendar apresenta um
calendário que permite a escolha da data, não havendo necessidade de digitá-la e
o componente selectOneMenu apresenta uma estética mais elegante e apresenta a
informação de forma mais destacada.
E
IMPORTANT
Sugerimos que você troque TODOS os componentes da interface gráfica pelos

correspondentes no Prime Faces e inclusive coloque componentes adicionais, observando o
seu comportamento. Somente desta forma você consolidará o aprendizado.
84
FIGURA 84 - ALTERAÇÃO DOS COMPONENTES
FONTE: O autor
Mas as possibilidades não se esgotam aqui. O Prime Faces disponibiliza

gratuitamente temas para seus componentes. Utilizaremos dois temas para
esta demonstração, disponíveis na url: <http://repository.primefaces.org/org/
primefaces/themes/>. Faremos o download dos temas vader e excite-bike. Estes temas
são arquivos jar que você adiciona ao projeto e depois os referencia. A Figura 78
destaca o arquivo a fazer download para utilizar o tema vader. O procedimento é o
mesmo para o tema excite-bike.
85
FIGURA 85 - DOWNLOAD DO TEMA VADER
FONTE: O autor
Uma vez que o arquivo estiver em seu computador, faremos a configuração

do projeto para que o mesmo passe a “enxergar” os temas do Prime Faces.
Inicialmente copie os dois arquivos para o diretório WEB-INF/lib de sua aplicação,
o mesmo onde o arquivo jar do Prime Faces foi copiado. A segunda configuração
consiste na inserção de um trecho de código fonte dentro do arquivo web.xml,
localizado dentro de WEB-INF. O código fonte está listado na Figura 86.
FIGURA 86 - CONFIGURAÇÃO DO WEB.XML
FONTE: O autor
86
O código que responde pelo tema do primefaces está entre as linhas 15 e 18.
Na linha 16 fazemos a configuração geral, e na linha 17 selecionamos o tema. As
alterações causadas pela utilização deste tema podem ser observadas na Figura 87.
FIGURA 87 - TEMA VADER
FONTE: O autor
Agora que você fez a configuração inicial, basta adicionar o arquivo de

tema ao diretório correspondente e fazer a alteração no arquivo web.xml que o
novo tema está automaticamente instalado e refletirá em suas interfaces. Você
pode inclusive criar seus próprios temas personalizados, embora existam muitos
prontos para utilização (Figura 88).
87
FIGURA 88 - TEMAS GRATUITOS DO PRIME FACES
FONTE: O autor
Para encerrar este tópico, faremos a listagem de pessoas através de um

componente do Prime Faces com o tema excite-bike. Este mesmo componente
poderia ser utilizado diretamente do JSF com o código abaixo, bastando para
isso remover a configuração referente ao tema. A Figura 89 traz o código fonte
necessário para esta alteração.
FIGURA 89 - COMPONENTE DATA TABLE
FONTE: O autor
Observe que entre as linhas 16 e 20 está a declaração da tabela. Esta

declaração ocorre logo após a declaração <h:form>. O atributo rows define
quantas linhas serão mostradas na tela, enquanto o paginator define se a tabela
terá paginação. A paginação é feita de forma automática, obedecendo ao template
definido nos atributos paginatorTemplate e rowsPerPageTemplate. Este último define
os intervalos de registros que o usuário pode selecionar na tabela. No código
fonte acima, mostramos somente duas colunas, mas a alteração deverá ser feita
em todas. A Figura 90 mostra de que forma ficou a tabela de pessoas com as
alterações feitas. Não esqueça de alterar o arquivo web.xml.
88
FIGURA 90 - DATATABLE COM O TEMA EXCITE-BIKE
FONTE: O autor
A funcionalidade da tabela não mudou, entretanto, o usuário agora pode

escolher quantos registros quer em tela. Um teste interessante é inserir mais
valores na lista que alimenta a tabela e observar seu comportamento.
Pronto! Graças ao JSF e ao Prime Faces você virou um web designer em

sete páginas e algumas horas de estudo. A facilidade de uso do Java Sever Faces
é uma de suas principais vantagens. Perceba que o layout da página muda
completamente simplesmente ao adicionarmos um novo tema, sem precisarmos
de implementações adicionais de css, javascript, bootstrap etc. Como dissemos
no início do tópico, JSF é uma especificação extensa e existe muito mais para
aprender sobre o tema. Nossa intenção é fornecer uma introdução sólida, para
que você possa continuar evoluindo por conta própria.
Na próxima unidade trabalharemos com o mapeamento objeto relacional

e a Java Persistence API. Bons estudos e até lá!
89
RESUMO DO TÓPICO 1
Caro acadêmico, neste tópico você viu que:
• O Java Server Faces pode ser definido como um framework de componentes de

servidor para aplicações web que funciona de acordo com o padrão MVC.
• Suas principais características e funcionalidades são: api que representa

componentes de interface gráfica e seu estado, gerenciamento de eventos,
validação e conversão de dados no servidor, navegação entre páginas,
internacionalização e extensibilidade.
• Para o funcionamento do JSF, é sempre necessária a criação de um Managed

Bean, que funcionará como controlador entre a interface gráfica e a entidade.
• Um Java Bean é uma classe que implementa a interface Serializable, possui um

construtor vazio e getters e setters para todos os atributos.
• O JSF implementa as tags do HTML como objetos java no servidor, mantendo

o estado destes entre requisições.
• É possível criar classes específicas para a validação ou conversão do valor de

componentes.
• O JSF possui suporte nativo à AJAX desde a versão 2.0, permitindo a utilização
desta tecnologia em vários componentes.
• O JSF permite que você modifique o layout dos componentes da interface

gráfica através de bibliotecas visuais de terceiros.
• Existem algumas bibliotecas de terceiros que são bastante conhecidas e

utilizadas em JSF, com destaque para o ICE Faces, o Rich Faces e o Prime Faces.
90
AUTOATIVIDADE
1 Implemente um mecanismo de persistência completo para o exemplo deste

tópico, associando-o com as ações da interface gráfica. Dica: Utilize um
singleton com uma coleção (List, Map, Set) para armazenar os objetos.
2 O componente Calendar do JSF originalmente imprime os valores em

inglês, conforme vimos no exemplo deste tópico. Através de buscas na
Internet, descubra de que forma proceder com a alteração do idioma deste
componente para o português.
3 Descreva detalhadamente o ciclo de vida do JSF, considerando a ação de

executar a página listagemDePessoas.xhtml que foi implementada neste tópico.
91
92
UNIDADE 2 TÓPICO 2
JAVA PERSISTENCE API
1 INTRODUÇÃO
Conforme Franco (2014), a grande maioria das aplicações desenvolvidas
no mercado tem a necessidade de persistir suas informações em alguma espécie
de repositório que permita a recuperação das mesmas em um momento posterior.
Por exemplo, ao realizar uma venda para um cliente, é interessante que os dados
desta e das próximas vendas sejam armazenados e posteriormente consultados,
no sentido de determinar o perfil deste cliente.
Atualmente, o tipo de repositório mais utilizado para persistir essas

informações é o banco de dados relacional. Provavelmente você já ouviu falar em
Oracle, MySQL, SQLServer, DB2, PostgreeSQL, entre outros, pois são os bancos de
dados mais comumente utilizados na atividade de desenvolvimento de software. O
grande volume de utilização dos bancos de dados relacionais ocorre basicamente
devido a duas razões básicas:
1) Os bancos de dados relacionais já estão no mercado por um longo período de

tempo, portanto, possuem um grau de confiabilidade alto.
2) Os paradigmas que vieram antes do paradigma de programação orientada a
objetos eram completamente compatíveis com os bancos de dados relacionais.
A linguagem de programação Java possui uma API projetada unicamente

para se trabalhar com bancos de dados relacionais, conhecida como JDBC (Java
Database Conectivity) e que dá suporte a um grande número de produtos existentes
no mercado. O detalhe aqui é o seguinte: existe um grande problema ao utilizar
a linguagem de programação Java (e qualquer outra linguagem de programação
orientada a objetos) em combinação com os bancos de dados relacionais. Antes de
demonstrarmos a utilização do JDBC, é importante ilustrar esse problema e fazer
uma contextualização no conceito conhecido como mapeamento objeto relacional.
93
2 MAPEAMENTO OBJETO RELACIONAL

Toda a teoria da programação orientada a objetos é baseada na teoria dos
grafos. Essencialmente, quando temos uma cadeia de objetos inter-relacionados,
podemos vê-los na memória como um grafo direcionado e navegável.
E
IMPORTANT
Grafos são estruturas normalmente utilizadas para representar dados

relacionados de forma não convencional. Um exemplo clássico desse tipo de representação
são os mapas utilizados em serviços de GPS. Maiores detalhes sobre os grafos podem ser
obtidos em: <http://www.ime.usp.br/~pf/teoriadosgrafos/>.
Por outro lado, os bancos de dados relacionais são baseados na teoria dos
conjuntos, o que pode ser facilmente comprovado quando se faz uma pesquisa
buscando dados de mais de uma tabela através dos conectivos E e OU.
A verdade é que precisamos instanciar objetos em nossas aplicações

e armazenar seus estados em algum mecanismo de persistência eficiente.
Analisando friamente, os bancos de dados relacionais não são a resposta mais
coerente para esse problema, entretanto, como dissemos antes, um grande
número de aplicações legadas utiliza os bancos de dados relacionais há anos (se
não décadas), o que os consolidou no mercado. A combinação de um modelo
com forte base científica e a vasta disponibilidade de literatura e ferramentas
fazem com que as bases relacionais sejam uma escolha sólida para a maioria das
aplicações em desenvolvimento (CARDIM, 2010).
Existem alguns bancos de dados não relacionais e até mesmo orientados

a objetos, mas a fatia de mercado ocupada por este tipo de mecanismo de
persistência é, até o momento, praticamente insignificante. Faremos uma breve
menção a estes bancos de dados ainda neste tópico.
Cardim (2010) afirma que objetos, relações e registros são conceitos

de natureza fundamentalmente diferente, apesar de apresentarem algumas
similaridades deceptivas. A navegação entre objetos ocorre através de ponteiros
e referências, enquanto as relações são unidas através de produtos cartesianos
e chaves estrangeiras, o que acaba levando a soluções de otimização diferentes
para ambos os casos, além das próprias operações de acesso.
Ainda sobre o tema, Fowler (2012) coloca que o problema de mapeamento

objeto relacional é um problema difícil de ser resolvido, pois o que se faz é
sincronizar dois tipos completamente diferentes de representação de dados, um
contido em uma base de dados relacional e outro na memória.
94
TÓPICO 2 | JAVA PERSISTENCE API
A Figura 91 (Martin Fowler) exemplifica uma tentativa de sincronização.

Perceba que os objetos relacionados entre si, representados do lado esquerdo da
figura, são mapeados para as tabelas do lado esquerdo. Enquanto os objetos possuem
como única limitação a memória do computador, as tabelas precisam representar
cada objeto em forma de um registro único, o que torna a tarefa complicada.
FIGURA 91 - MAPEAMENTO OBJETO RELACIONAL
FONTE: Adaptado de: FOWLER (2012)
Este problema é comumente conhecido como diferença de impedância

e resolvido através de um conjunto de técnicas e ferramentas conhecido como
mapeamento objeto relacional. Para entender a complexidade de tal problema,
imagine uma estrutura de classes que represente parte do domínio de uma
aplicação, conforme ilustrado na Figura 92.
95
FIGURA 92 - ESTRUTURA DE HERANÇA
FONTE: O autor
Aqui temos um relacionamento de herança envolvendo três classes.

Lembre-se de que tanto FuncionarioComissionado quanto FuncionarioHorista
compartilham os atributos de Funcionario (que é abstrato) e ainda possuem seus
próprios atributos. Como faremos para armazenar objetos deste tipo em um
banco de dados relacionais?
Existem diversas técnicas documentadas e exemplificadas na literatura

e internet para o mapeamento do relacionamento de herança entre objetos
para tabelas relacionais, entretanto, visando cumprir com os objetivos de
aprendizado deste caderno, nos ateremos a mapeamentos menos complexos e
de representação mais fácil.
2.1 ARQUITETURA DO DATA ACCESS OBJECT

Uma das soluções mais aplicadas para o problema do mapeamento
objeto relacional é a utilização do padrão de projeto conhecido como DAO (data
access object). Esse padrão consiste em implementar uma camada para fazer o
mapeamento entre os objetos e as tabelas do banco de dados. Essa camada pode
conter diversas classes e ser construída de forma manual ou até mesmo através
da utilização de frameworks para automatizar o processo.
96
NOTA
Um framework provê uma solução para uma família de problemas semelhantes,

usando um conjunto de classes e interfaces que mostra como decompor a família de
problemas e como objetos dessas classes colaboram para cumprir suas responsabilidades.
O conjunto de classes deve ser flexível e extensível para permitir a construção de várias
aplicações com pouco esforço, especificando apenas as particularidades de cada aplicação.
Fonte: http://www.dsc.ufcg.edu.br/~jacques/cursos/map/html/frame/oque.htm
Essencialmente, o que o DAO propõe é a criação de um conjunto de classes

onde cada classe representa um conceito de objeto mapeado para uma ou mais
tabelas do banco de dados. Em geral, cada DAO possui operações que permitem
a criação, leitura, atualização e busca de registros no banco de dados. A função
primordial do DAO é fazer a tradução de objetos em registros e de registros em
objetos. Quando a implementação é bem feita, algumas vantagens adicionais
podem ser obtidas, tais como:
• Abstração completa do mecanismo de persistência: a aplicação em si não

precisa conhecer absolutamente nada sobre o mecanismo de persistência,
bastando conhecer somente a interface externa do DAO.
• Troca de mecanismo de persistência: caso o mecanismo de persistência deva
ser trocado, basta trocar o DAO e todo o resto poderia continuar funcionando
perfeitamente.
• Coesão: uma camada DAO bem implementada concentra TODAS as funções
de persistência e configuração de banco, facilitando alterações futuras.
A Figura 93 ilustra a arquitetura de uma camada de mapeamento objeto

relacional. Perceba que temos essencialmente três partes essenciais. O storage
representa o banco de dados relacional, com suas tabelas e registros individuais.
A data access layer é a camada de mapeamento entre os dois mundos. Atente
para o fato de que existe uma classe DAO que é responsável pelas informações
de conexão com o banco de dados e pela operação de buscar um estudante.
Finalmente, a application é responsável por conter as classes que representam
o domínio da área de negócios da aplicação. Através das setas podemos inferir
que a camada de mapeamento atua nos dois sentidos das operações, convertendo
objetos para registros e vice-versa.
97
FIGURA 93 - ARQUITETURA DO DAO
FONTE: Cardim (2010)
3 JAVA PERSISTENCE API (JPA)

Para suplantar as limitações das estratégias de mapeamento objeto
relacional, surgiram diversos frameworks no mercado, sendo que o mais conhecido
é o Hibernate. Este framework acabou tendo uma grande aceitação, principalmente
devido à produtividade que trazia ao desenvolvedor, poupando-o de mapear
as classes para tabelas manualmente. Observando a popularidade e a qualidade
do framework, a Oracle resolveu, através do JCP, criar uma especificação para o
mapeamento objeto relacional. Surgiu então o JPA, que é a api-padrão da plataforma
Java para a persistência do estado de objetos em bancos de dados relacionais.
O JPA fornece um conjunto de interfaces e classes para serem utilizadas

em aplicações Java, fazendo parte da especificação JEE desde a versão 5.0. Para
entender a arquitetura de funcionamento do JPA, observe a Figura 94.
Imagine que uma aplicação escrita usando a linguagem de programação

Java deseja armazenar e recuperar informações de um banco de dados relacional.
A abordagem tradicional consistia em utilizar o JDBC para fazer esta comunicação,
através de suas interfaces implementadas pelos drivers JDBC específicos para
cada banco. A abordagem do JPA é semelhante, pois também consiste de um
conjunto de classes e interfaces que são implementadas por um provedor JPA.
Este provedor JPA interage diretamente com o JDBC, estabelecendo comunicação
com o banco de dados desejado. Uma das principais vantagens desta abordagem
é que nenhum código SQL fica na aplicação Java, ao contrário por exemplo,
do padrão de projeto DAO. Perceba ainda que temos drivers JDBC para os
bancos de dados específicos e vários provedores JPA, que podem ser utilizados
independentemente do driver.
98
FIGURA 94 - ARQUITETURA DO JPA
FONTE: SOFTPLAN (2015)
4 CONCEITOS E INTERFACES DO JPA

Existem alguns conceitos e interfaces que precisamos conhecer para poder
trabalhar com o JPA, conforme destacado a seguir:
• Unidade de Persistência (Persistency Unit): Arquivo que apresenta um conjunto

de configurações utilizadas pelo JPA para se conectar com o banco de dados,
como login, senha, e url de conexão. É possível ainda definir neste arquivo quais
são os objetos que serão persistidos no banco. Uma aplicação pode ter mais de
uma unidade de persistência, caso seja necessário utilizar mais de um banco de
dados. Cada unidade de persistência é definida por um nome único, conforme
a Figura 95, linha 3. Entre as linhas 7 e 10 estão colocadas as configurações
específicas para acesso ao banco. A linha 12 traz configurações de criação e
deleção (drop) de tabelas. As linhas 13 e 14 fazem com que o sql gerado pelo JPA
seja visível no console, o que é muito útil para depuração de código.
FIGURA 95 - UNIDADE DE PERSISTÊNCIA
FONTE: O autor
99
• Gerenciador de persistência (EntityManager): Interface implementada pelo

provedor JPA que disponibiliza métodos para realizar as operações de
persistência (Figura 96). Representa um canal de comunicação com o banco de
dados, embora internamente ainda faça uso do JDBC.
FIGURA 96 - INTERFACE ENTITY MANAGER
4.1 MAPEAMENTO DE ENTIDADES

O JPA permite a persistência do estado de qualquer classe Java, bastando
para tal colocar as anotações obrigatórias. É recomendável que a classe siga as
especificações JavaBeans e que tenha ou possa ter uma tabela associada, visto que, se
a tabela não existir, o JPA faz a criação da mesma de acordo com o que foi mapeado
nas classes. A Figura 97 traz um exemplo de mapeamento de classe para tabela.
Observe que neste caso os nomes dos atributos se mantiveram iguais na classe e na
tabela. Isto não é obrigatório, embora em casos de criação de tabelas seja a prática
recomendada. O campo id está presente na classe e na tabela, pois de acordo com
a especificação JPA, esta é uma boa prática para a definição de chaves primárias
em tabelas. Os tipos de dados são convertidos automaticamente, de acordo com o
provedor JPA e o banco de dados onde se estiver armazenando os objetos.
100
FIGURA 97 - MAPEAMENTO DE CLASSE PARA TABELA
Praticamente toda a configuração do mapeamento entre tabelas e classes é

feita através de anotações. A seguir estão listadas as principais anotações do JPA:
• @Entity – Marca uma classe como entidade e tabela;

• @Table – Referencia o nome da tabela. Esta anotação somente é necessária
quando o nome da tabela será diferente do nome da classe;
• @Id – Marca um atributo como chave primária;
• @Temporal – Marca um atributo como sendo do tipo datetime;
• @GeneratedValue – utilizado em conjunto com a anotação @Id, determinando a
estratégia adotada para a geração deste valor;
• @Column – Permite a definição de configurações para a coluna no banco de dados.
Um dos princípios do JPA é o da simplicidade. O conceito de Convention

Over Configuration (Coc) permite que se trabalhe com uma configuração mínima,
pois o resto é convenção e o JPA assume valores default. As únicas anotações
obrigatórias são @Entity e @Id. Logicamente, nestes casos o nome da tabela é o
mesmo da classe e os nomes das colunas coincidem com os atributos.
Para entender como o JPA funciona, demonstraremos as principais

operações de persistência com a mesma entidade Pessoa que utilizamos no tópico
anterior. O código fonte da entidade é demonstrado na Figura 98. Na linha 14
definimos a classe como uma Entidade, o que significa que ela poderá ser salva e
gerará uma tabela. Sobre o atributo id, colocamos uma anotação definindo-o como
chave primária e outra dizendo que a geração da chave é de responsabilidade do
banco de dados. A notação @Temporal marca o atributo como sendo de um tipo
relacionado a data e/ou hora. Em nosso caso, armazenaremos somente a data.
101
FIGURA 98 - ENTIDADE PESSOA
FONTE: O autor
Nosso exemplo anterior simulava a existência de um banco de dados através

da geração arbitrária de pessoas na classe PessoaMB. Já que agora trabalharemos
com um sistema de banco de dados real, eliminaremos esse código da classe.
Temporariamente, o método getPessoas() ficará como está demonstrado na Figura 99.
FIGURA 99 - MÉTODO PARA LISTAR PESSOAS
FONTE: O autor
Para a configuração do arquivo que fará a conexão com o banco de dados,

inicialmente precisamos criar o diretório que conterá este arquivo dentro do
projeto. Clique com o botão direito do mouse dentro do diretório src e lá selecione
a opção New Folder. O Eclipse exibirá um diálogo conforme o ilustrado na Figura
100. O nome deste diretório deve obrigatoriamente ser META-INF.
Apenas ressaltando que, para utilizar a classe List, é necessário realizar a

sua importação, e para isso, na IDE Eclipse, clique com o botão esquerdo do mouse
sobre o X em vermelho, o qual sinaliza erro de importação, sendo apresentado na
frente do número da linha com erro, conforme ilustrado na figura a seguir.
102
Com este passo, é aberta uma lista de possíveis bibliotecas a serem

importadas na classe PessoaMB, sendo que a importação necessária é a classe List
do pacote “java.util”, conforme selecionado na tela ilustrada na figura a seguir.
O mesmo procedimento deve ser realizado para a classe ArrayList, sendo

clicado com o botão direito do mouse sobre o indicador de erro da linha (X em
vermelho), e então selecionar a opção ArrayList do pacote “java.util”, conforme
ilustrado na figura a seguir.
103
Com isso, no início do código fonte da classe PessoaMB, devem ter as

importações ilustradas no código fonte a seguir.
import java.io.Serializable;
import java.util.ArrayList;
import java.util.List;
import javax.enterprise.context.SessionScoped;
import javax.inject.Named;
FIGURA 100 - DIRETÓRIO PARA O ARQUIVO DE CONFIGURAÇÃO PERSISTENCE.XML
FONTE: O autor
104
Dentro deste arquivo, você deverá criar um novo arquivo xml, com o
nome persistence.xml. O conteúdo deste arquivo deverá ser igual ao da Figura
101. Cada arquivo persistence.xml pode ter uma ou n unidades de persistência
(definidas entre as linhas 3 e 14), sendo que cada unidade deve ser identificada
com um nome único e acessar uma única base de dados. Desde que a conexão
configurada no Wildfly esteja correta, uma aplicação pode se conectar com quantos
bancos de dados quiser, um para cada unidade de persistência definida. Na linha
4 está declarado o tipo de transação. Neste caso utilizaremos Java Transaction API,
disponível no AS. Na linha 5 está declarado o DataSource que criamos dentro do
WildFly na Unidade I deste caderno, o que nos libera da definição de usuário,
senha e até mesmo base de dados neste arquivo.
FIGURA 101 - PERSISTENCE.XML
FONTE: O autor
NOTA
A Java Transaction API especifica interfaces padrão entre um gerenciador de

transações e as partes envolvidas em um sistema de transações distribuídas. Para maiores
informações acesse: http://www.oracle.com/technetwork/java/javaee/jta/index.html
O próximo passo consiste na implementação da classe que fará a persistência

propriamente dita do objeto. O JTA exige a existência de duas anotações na classe
que utilizará o EntityManager, afinal ainda estamos trabalhando com o JPA.
Nesta implementação cabe um questionamento interessante: vale a pena

ainda utilizar uma camada DAO para as operações de persistência? A resposta é
que depende da implementação. O DAO tradicional trabalha de forma a encapsular
as operações que envolvam SQL e mapeamento objeto relacional, enquanto aqui
o DAO simplesmente chamaria a api JPA e receberia um objeto para persistência.
Caso sua aplicação tenha como característica a utilização futura de outro tipo
105
de banco de dados relacional ou mesmo bancos de dados NoSQL (atente-se

para a leitura complementar desta unidade), talvez valha a pena desacoplar a
implementação do MB das operações do JPA. Contudo, esta estratégia acarretaria
em mais uma camada entre as operações, o que notadamente reduz desempenho
e aumenta o volume de manutenção. Novamente, todas as decisões arquiteturais
envolvem um perde-ganha, mais conhecido como tradeoff. Na implementação
exemplo deste tópico, não criaremos uma camada distinta DAO e as operações
de persistência serão feitas diretamente no MB. A Figura 102 traz as alterações de
código-fonte na classe PessoaMB.
FIGURA 102 - PESSOAMB
FONTE: O autor
Na linha 33 vemos a anotação @PersistenceContext, acima do atributo que

representa o EntityManager. Note que em nenhum momento fizemos a instanciação
do objeto manager. Mas como evitaremos o NullPointerException? Com essa anotação,
solicitamos ao AS que faça o gerenciamento do ciclo de vida deste objeto. Não há
necessidade de instanciá-lo ou mesmo de fechar a conexão. Tudo ficará a cargo do
AS. Mas e a tabela no banco de dados? Preciso criá-la? A resposta é não... a criação
das tabelas necessárias será feita pelo JPA (através do AS). A única coisa que você
deve fazer é criar a database (schema) no banco de dados conforme o nome que foi
dado na configuração do DataSource dentro do WildFly.
Na linha 35 temos a anotação @Resource. Esta anotação solicita que o

AS faça a injeção de um recurso quando este for necessário na classe. A injeção
implica que a instanciação e remoção do objeto ocorrerá de forma transparente
em nosso código fonte.
106
NOTA
A injeção de dependência é um padrão de projeto através do qual se diminui

o acoplamento entre as classes, pois as dependências não ocorrem programaticamente e
sim através da configuração de uma infraestrutura de software. Este conceito será visto em
detalhes na Unidade 3 deste caderno.
As linhas 69, 70 e 71 contém o código que faz a persistência do objeto

pessoa no banco de dados. Como estamos em um MB, a persistência deve ocorrer
em um contexto transacional, por isso devemos iniciar e encerrar a transação. Na
Unidade 3 trabalharemos com os Enterprise Java Beans, onde não há essa exigência
e o nível de configuração é maior. As Figuras 103 e 104 ilustram o cadastro de
uma pessoa e o registro no banco de dados.
Continuando nossa funcionalidade CRUD, agora implementaremos a

listagem de pessoas, obtida dos registros armazenados em nosso banco de dados
(Figura 105). Sugerimos que você faça pelo menos dez cadastros de pessoas
diferentes, pois para esta implementação, quanto mais registros melhor. Faremos
uma única alteração na classe PessoaMB, dentro do método getPessoas(), conforme
ilustrado na Figura 106.
FONTE: O autor
107
FIGURA 104 - REGISTRO DA PESSOA NO BANCO DE DADOS
FONTE: O autor
FIGURA 105 - LISTAGEM DE PESSOAS
FONTE: O autor
Na linha 84 criamos o objeto que armazena a instrução JPAQL de busca,

utilizando novamente o objeto manager. Na linha 86 obtemos uma lista de resultados
do banco através da query e atribuímos este resultado para uma lista de pessoas.
FIGURA 106 - MÉTODO DE LISTAGEM DE PESSOAS
FONTE: O autor
NOTA
JPAQL é uma linguagem análoga ao SQL, utilizada para fazer busca de objetos
que foram persistidos em bancos de dados. Para maiores informações acesse:
http://docs.oracle.com/javaee/6/tutorial/doc/bnbtg.html
108
Na implementação da operação de deleção de registros, o processo é

semelhante, bastando alterar o método remover da classe PessoaMB. O código
alterado é mostrado na Figura 106. Na linha 98, destacamos o método que faz
efetivamente a remoção do objeto do banco de dados. Mas por que eu não
posso simplesmente invocar o método remove enviando diretamente o objeto
que eu pretendo excluir? O EntityManager não funciona assim. Ele não pode
simplesmente alterar ou excluir um objeto recebido por parâmetro. Este objeto
deve entrar no contexto do EntityManager, para que então possa ser removido. É
isto que está acontecendo na linha destacada.
FIGURA 107 - MÉTODO PARA A EXCLUSÃO DE OBJETOS
FONTE: O autor
A Figura 107 ilustra o ciclo de vida de um objeto dentro do EntityManager.

Note que um objeto só pode passar para o estado Removed se ele estiver dentro
do estado Managed. Considere que um objeto qualquer, como aquele recebido no
código fonte do método remover, está no estado Detached e precisa passar pelo
método merge para entrar no estado Managed. Uma vez no estado Managed, ele
pode simplesmente passar para o estado Removed.
FIGURA 108 - CICLO DE VIDA DO ENTITYMANAGER DENTRO DO JPA
FONTE: Adaptado de: <http://openjpa.apache.org/builds/1.2.3/apache-openjpa/docs/

jpa_overview_em_lifecycle.html>. Acesso em: 20 out. 2015.
109
No processo de alteração de algum dado do objeto, o mesmo princípio

é adotado. O objeto precisa passar de DETACHED para MANAGED para
somente então ser alterado. Este processo de alteração exige um pouco mais de
implementação, pois utilizamos a mesma interface para o cadastro e para a alteração
do objeto. O problema é o fato de nossa tela de cadastro não possuir o id do objeto.
No caso do cadastro, isso não gera nenhum problema, pois o id é gerado pelo banco
e na interface de listagem o objeto é mostrado com este atributo. Entretanto, ao
clicarmos no botão Editar, somos levados para a mesma interface de cadastro, onde
o botão Salvar chama o método salvar da classe PessoaMB. Este método não tem
inteligência para decidir se o objeto deve ser criado ou atualizado no banco. Cabe
a nós implementar esta inteligência através da alteração mostrada na Figura 109.
FIGURA 109 - MÉTODO SALVAR
FONTE: O autor
Na linha destacada (70), questionamos se o objeto que está sendo

utilizado pelo método possui ou não um valor para o id. A lógica por trás dessa
implementação consiste no seguinte: caso o objeto venha de um cadastro pela
primeira vez, o que implica que este objeto não existia anteriormente no banco
de dados, seu id será igual a null. Caso o objeto venha da interface de listagem,
existirá um id, pois o mesmo foi recuperado do banco de dados.
Contudo, ainda existe uma questão a ser solucionada... o objeto na tela

de cadastro não possui o atributo id. Isso implica que nosso algoritmo falhará
e em todas as situações persistirá um novo objeto no banco de dados. Como
poderemos resolver isso? Pense na resposta por alguns minutos e somente então
veja a resposta no parágrafo a seguir.
Criaremos um campo do tipo oculto dentro da interface de cadastro que

conterá o id do objeto. Da mesma forma que existe um campo do tipo hidden no
HTML, existe um campo hidden no JSF. A associação ao id do objeto não trará
problemas quando se trata de cadastro, pois o atributo não é visível e não pode
ser editado. Já na situação em que o objeto vem da interface de listagem, o id
do mesmo estará lá e nosso algoritmo funcionará perfeitamente. A alteração do
arquivo cadastro.xhtml é mostrada na figura a seguir:
110
FIGURA 110 - ALTERAÇÃO NA INTERFACE DE CADASTRO
FONTE: O autor
O campo oculto vem logo abaixo do texto do cabeçalho, o que o torna

invisível dentro do formulário, ao mesmo tempo em que conterá o id do objeto e
permitirá sua atualização ao invés de criar um novo objeto. Um aspecto importante
a ser observado é que esta não é a única estratégia possível para lidar com este
tipo de situação e que aqui a adotamos por entender que o aprendizado é maior.
4.2 RELACIONAMENTOS ENTRE ENTIDADES

No mundo real, dificilmente uma tabela existirá isolada das demais. Na
orientação a objetos isto não ocorre de maneira diferente. Um objeto Pessoa,
por exemplo, pode estar associado a um ou mais objetos Endereco. Um objeto
NotaFiscal pode estar associado a uma coleção de objetos do tipo Item, onde cada
Item possuirá ainda uma associação a um objeto do tipo Produto. O JPA trata este
tipo de situação através de anotações específicas, onde é possível determinar o tipo
de associação entre os objetos. As multiplicidades possíveis são as seguintes:
• Um para um (1:1) – mapeado por atributo simples e pela anotação @OneToOne;

• Muitos para um (M:1) – mapeado por atributo simples e pela anotação @
ManyToOne;
• Um para muitos (1:M) – mapeado por coleção e pela anotação @OneToMany;
• Muitos para um (M:1) – mapeado por coleção e pela anotação @ManyToMany;
É possível ainda considerar a navegabilidade das associações na utilização

das anotações. Na figura a seguir é possível observar dois exemplos distintos. No
primeiro exemplo, o objeto Pedido está relacionado a um objeto do tipo Endereco
de forma unidirecional, ou seja, a classe Pedido possui um atributo do tipo
Endereco. Neste caso, dizemos que Pedido vê Endereco, mas Endereco não vê
Pedido. No segundo exemplo, a navegabilidade é bidirecional, pois cada uma das
classes possui um atributo do tipo ao qual está associada. Tanto Empresa quanto
Pessoa conseguem ver o outro lado da associação.
111
FIGURA 111 - NAVEGABILIDADE DOS RELACIONAMENTOS
Exemplificaremos os relacionamentos através de um relacionamento @

OneToMany, onde uma empresa possui uma coleção de objetos do tipo Pessoa.
Quando o JPA cria as tabelas no banco de dados, ele automaticamente cria também
os relacionamentos entre elas e as chaves estrangeiras de acordo com as anotações
de associação e navegabilidade. Na figura a seguir é possível observar o exemplo.
FIGURA 112 - @ONETOMANY
Neste caso, a persistência dos objetos ocorreria de forma hierárquica. Um

objeto Empresa seria criado, os objetos Pessoa seriam criados e adicionados na
coleção para somente então o objeto Empresa ser persistido. Todos os objetos pessoa
que estão dentro da coleção serão automaticamente inseridos no banco de dados.
NOTA
Para exemplos completos de implementações das demais associações acesse http://

cafe.algaworks.com/livro-jpa-e-hibernate/ e faça o download do livro digital sobre JPA e Hibernate.
112
As anotações de associação aceitam um atributo chamado fetch. Através

deste atributo, é possível configurar de que forma ocorrerá a recuperação dos
objetos associados. Dois valores são possíveis:
1) FetchType.EAGER: O atributo ou coleção de atributos é carregado quando a
classe principal é carregada.
2) FetchType.LAZY: O atributo ou coleção de atributos é carregado somente
quando for acessado explicitamente via get na entidade principal.
A Figura 113 ilustra as duas utilizações:
FIGURA 113 - UTILIZAÇÃO DO ATRIBUTO FETCH
FONTE: SOFTPLAN (2015).
Com este exemplo encerramos esta unidade. Da mesma forma que o JSF,
o JPA também é uma API extremamente rica e que possui muito mais conteúdo
a ser visto. Neste tópico buscamos introduzir de forma sólida os principais
conceitos e também implementar algumas funcionalidades simples, de forma
que você tenha embasamento suficiente para continuar estudando. Na próxima
unidade abordaremos o EJB e o CDI.
Bons estudos e até lá!
113
EXPLORE O MONGODB
Neste artigo, aprenderemos sobre o MongoDB, o sistema de gerenciamento

de banco de dados de software livre e orientado a documentos, escrito em C++,
que fornece recursos para a escalada de seus bancos de dados em um ambiente de
produção. Descubra os benefícios que os bancos de dados orientados a documentos
têm em relação aos tradicionais sistemas de gerenciamento de banco de dados
relacionais (RDBMS). Instale o MongoDB e comece a criar bancos de dados,
coleções e documentos. Examine os recursos de consulta dinâmica do Mongo, que
fornecem eficiência de armazenamento de chave/valor de uma maneira familiar a
administradores e desenvolvedores de bancos de dados RDBMS.
O que é o MongoDB?
Nos últimos anos, vimos um interesse crescente em sistemas de

gerenciamento de bancos dados que diferem do modelo relacional tradicional.
No centro disso está o conceito de NoSQL, um termo usado coletivamente para
denotar software de banco de dados que não usa SQL (Structured Query Language)
para interagir com o banco de dados. Um dos projetos NoSQL mais notáveis
até o momento é o MongoDB, um banco de dados orientado a documentos e de
software livre que armazena dados em coleções de documentos semelhantes a
JSON. O que distingue o MongoDB de outros bancos de dados NoSQL é a sua
poderosa linguagem de consulta baseada em documento, que torna a transição
de um banco de dados relacional para o MongoDB fácil, porque as consultas são
convertidas com bastante facilidade.
O MongoDB é escrito em C++. Ele armazena dados dentro de documentos

semelhantes a JSON (usando BSON — uma versão binária de JSON), que retém
os dados usando pares de chave/valor. Um recurso que diferencia o MongoDB de
outros bancos de dados de documentos é que é muito simples converter instruções
SQL em chamadas de função de consulta do MongoDB. Isso facilita a migração
de organizações que atualmente usam bancos de dados relacionais fazerem a
migração. Ele também é muito simples de instalar e usar, com binários e drivers
disponíveis para os principais sistemas operacionais e linguagens de programação.
O MongoDB é um projeto de software livre, com o banco de dados em

si licenciado sob a GNU AGPL (Affero General Public License) versão 3.0. Essa
licença é uma versão modificada da GNU GPL que fecha uma brecha na qual
as restrições de copyleft não se aplicam ao uso do software, mas apenas à sua
distribuição. Isso, naturalmente, é importante em software armazenada na
nuvem e geralmente não instalado em dispositivos cliente. Usar a GPL regular
poderia resultar em alguém perceber que nenhuma distribuição de fato acontece
e, portanto, potencialmente contornar os termos da licença.
114
A AGPL aplica-se apenas ao próprio aplicativo de banco de dados, e

não a outros elementos do MongoDB. Os drivers oficiais que permitem que os
desenvolvedores conectem o MongoDB a várias linguagens de programação são
distribuídos sob a Licença Apache, Versão 2.0. A documentação do MongoDB
está disponível sob a licença Creative Commons.
Bancos de dados orientados a documentos
Os bancos de dados orientados a documentos são bastante diferentes

dos tradicionais bancos de dados relacionais. Em vez de armazenar dados em
estruturas rígidas, como tabelas, eles os armazenam em documentos vagamente
definidos. No caso de tabelas de sistemas de gerenciamento de bancos de dados
relacionais (RDBMS), se for preciso acrescentar uma nova coluna, será necessário
mudar a definição da própria tabela, que acrescentará aquela coluna a todos os
registros existentes (embora potencialmente com valor nulo). Isso se deve ao
estrito design baseado em esquema do RDBMS. No entanto, em documentos,
é possível acrescentar novos atributos aos documentos individuais sem que
outros sejam alterados. Isso porque o design de bancos de dados orientados a
documentos costuma ser sem esquema.
Outra diferença fundamental é que bancos de dados orientados a

documentos não fornecem relacionamentos estritos entre documentos, o que
ajuda a manter seu design sem esquema. Isso difere muito de bancos de dados
relacionais, que dependem fortemente de relacionamentos para normalizar o
armazenamento de dados. Em vez de armazenar dados “relacionados” em uma
área de armazenamento separada, em bancos de dados de documentos eles são
integrados ao próprio documento. Isso é muito mais rápido do que armazenar
uma referência a outro documento onde os dados relacionados são armazenados,
visto que cada referência exigiria uma consulta adicional.
Isso funciona muito bem para muitos aplicativos nos quais faz sentido
os dados ficarem autocontidos dentro de um documento pai. Um bom exemplo
(encontrado também na documentação do MongoDB) são posts e comentários
de blogs. Os comentários se aplicam somente a um único post, de modo que
não faz sentido separá-los dele. No MongoDB, seu documento de post de blog
teria um atributo comments para armazenar esses comentários referentes a esse
post. Em um banco de dados relacional provavelmente haveria uma tabela de
comentários com uma chave de ID primária, uma tabela de posts com uma chave
de ID primária e uma tabela de mapeamento intermediária post_comments
que definiria que comentários pertencem a qual post. Isso é muito complexo,
desnecessariamente, para algo que deveria ser muito simples
Contudo, se for preciso armazenar dados relacionados em separado,

é possível fazer isso facilmente no MongoDB usando uma coleção separada.
Outro bom exemplo é armazenar informações de pedidos de clientes em
documentos do MongoDB. Geralmente isso inclui informações sobre o cliente,
o próprio pedido, itens de linha do pedido e informações sobre o produto.
115
Usando o MongoDB, provavelmente seriam armazenados os clientes, produtos

e pedidos em coleções individuais, mas seriam integrados dados de itens de
linha dentro do documento de pedido relevante. Seria então feito referência às
coleções products e customers usando IDs em estilo de chave estrangeira, assim
como faria em um banco de dados relacional. A simplicidade dessa abordagem
híbrida faz do MongoDB uma escolha excelente para quem está acostumado
a trabalhar com SQL. Isso posto, tire tempo e tome cuidado para decidir a
abordagem que precisará ser usada em cada caso de uso individual, visto que os
ganhos de desempenho podem ser significativos ao incorporar os dados dentro
do documento, em vez de fazer referência a eles em outras coleções.

Visão rápida dos recursos
MongoDB é muito mais do que apenas um armazenamento básico de

chaves/valores. Vamos dar uma breve olhada em algum de seus recursos:
• Binários oficiais disponíveis para Windows®, Mac OS X, Linux® e Solaris,

distribuição de código de origem disponível para autoconstrução.
• Drivers oficiais disponíveis para C, C#, C++, Haskell, Java™, JavaScript, Perl,
PHP, Python, Ruby e Scala, com uma ampla variedade de drivers suportados
pela comunidade, disponíveis para outras linguagens.
• Consultas JavaScript ad-hoc que permitem localizar dados usando qualquer
critério de qualquer atributo de documento. Essas consultas são um espelho da
funcionalidade de consultas SQL, o que torna muito fácil para desenvolvedores
SQL escreverem consultas em MongoDB.
• Suporte a expressões regulares em consultas.
• Os resultados da consulta em MongoDB são armazenados em cursores
que fornecem muitas funções para filtragem, agregação e classificação,
incluindo limit(), skip(), sort(), count(), distinct() e group().
• map/reduce -- implementação para agregação avançada
• Armazenamento de arquivos grandes usando GridFS
• Suporte a indexação de atributo semelhante a RDBMS, onde é possível criar
índices diretamente em atributos selecionados de um documento
• Recursos de otimização de consulta usando dicas, planos de explicação e perfis
• Replicação mestre/escravo similar ao MySQL
• Armazenamento de objeto baseado em coleta, permitindo consulta referencial
onde forem necessários dados normalizados
• Escalada horizontal com autosharding
• Atualizações no local para simultaneidade de alto desempenho e livre de
disputas
• Shell on-line que permite testar o MongoDB sem instalá-lo
• Documentação detalhada, com vários livros publicados e outros sendo escritos
116
Instalando o MongoDB
Felizmente, o MongoDB é muito simples de instalar em uma grande

variedade de plataformas. Estão disponíveis distribuições binárias para
Windows, Mac OS X, Linux e Solaris, enquanto diversos gerenciadores de
pacotes oferecem instalação fácil e opções de configuração para outros sistemas.
Para quem é corajoso, é possível compilar o código de origem sozinho. Nesta
seção, aprenderemos a instalar o MongoDB em Windows e Mac OS X, definindo
o processo como serviço no Windows ou como daemon no OS X.

Instalando no Windows
A instalação do MongoDB no Windows é muito simples. No seu navegador

da Web favorito, acesse http://www.mongodb.org/downloads e faça o download
do mais recente release de produção estável para Windows. Recomendamos a
versão de 64 bits, mas ela só pode ser usada se estivermos utilizando o sistema
operacional Windows de 64 bits. Em caso de dúvida, basta usar a versão de 32 bits.
Extraia o arquivo zip na unidade C:\, o que criará uma nova pasta chamada
mongodb-win32-i386-1.6.4, ou algo assim. Para facilitar a sua vida, renomeie essa
pasta para mongo. Depois, é preciso criar um diretório de dados. No Windows
Explorer, vá até a raiz da unidade C:\ e crie uma pasta chamada data. Dentro
dela, crie outra pasta chamada db.
Agora é possível iniciar o servidor do MongoDB. Use o Windows Explorer

para navegar até C:\mongo\bin e dê dois cliques em mongod.exe. Feche a janela
de prompt de comando que aparece para parar o servidor do MongoDB. Ou seja,
é mais conveniente configurar o servidor do MongoDB como um serviço que o
Windows controle. Vamos fazer isso.
Abra uma janela de prompt de comando (Start>Run>, digite cmd e

pressione OK) e dê os comandos da Listagem 1.
Listagem 1. Configuração do servidor do MongoDB como serviço

> cd \mongo\bin
> mongod --install --logpath c:\mongo\logs --logappend
--bind_ip 127.0.0.1 --directoryperdb
É possível ver o resultado na Listagem 2.
Listagem 2. Serviço criado com êxito

all output going to c:\mongo\logs
Creating service MongoDB.
Service creation successful.
Service can be started from the command line via ‘net start “MongoDB”’.
Com o Mongo instalado como serviço, é possível iniciá-lo com o seguinte

comando: > net start “MongoDB”
117
É possível ver o resultado na Listagem 3.
Listagem 3. Mongo iniciado com êxito

The Mongo DB service is starting.
The Mongo DB service was started successfully.
Agora é possível executar o cliente de shell do MongoDB. Se a janela

de prompt de comando estiver aberta, confirme se está na pasta c:\mongo\bin
folder e digite o seguinte comando: > mongo.
Como opção, no Windows Explorer navegue até C:\mongo\bin e dê dois

cliques em mongo.exe. Não importa sua opção para iniciar o shell, deve aparecer
um prompt semelhante à Listagem 4.
Listagem 4. Iniciando o shell

MongoDB shell version: 1.8.1
connecting to: test
>
Listagem 5. Iniciando o cliente

connecting to: test
>
Na próxima seção, aprenderemos a usar o shell do MongoDB para criar

bancos de dados, coleções, documentos, e assim por diante.
Guia de introdução para o uso do MongoDB
Incluído com a distribuição do MongoDB há um aplicativo de shell que

permite o controle completo sobre seus bancos de dados. Usando o shell, é possível
criar e gerenciar bancos de dados, coleções, documentos e índices usando funções
JavaScript do lado do servidor. Isso facilita começar a usar o MongoDB rapidamente.
Nesta seção, aprenderemos a iniciar o shell e verem os exemplos de alguns comandos
básicos para fazer o armazenamento e a recuperação básicos de dados.
Shell do MongoDB
O aplicativo de shell do MongoDB está incluído na distribuição deste, na

pasta bin. No Windows, está na forma do aplicativo mongo.exe. Dê dois cliques
nesse programa no Windows Explorer para iniciar o shell. Em sistemas operacionais
baseados em UNIX® (incluindo o Mac OS X) inicie o shell do MongoDB executando
o comando mongo na janela de terminal (desde que tenham sido seguidas as
instruções acima para acrescentar o diretório do MongoDB no seu caminho).
Quando o shell é aberto pela primeira vez, aparece a mensagem

da Listagem 7.
118
Listagem 7. Mensagem após abrir o shell

connecting to: test
>
A conexão com seu servidor MongoDB local estará pronta, em especial,

com o banco de dados “test”. Na próxima seção, aprenderemos a criar bancos de
dados, documentos e coleções. Se em qualquer momento for preciso obter ajuda,
basta dar o comando “help” na linha de comando do shell do Mongo A Figura
1 mostra a saída típica de um comando de ajuda.
FIGURA 1 – SAÍDA DO COMANDO HELP DO SHELL DO MONGO
Se quiser ver o código de origem por trás de uma função do MongoDB,

basta digitar o nome da função no shell, e ele imprimirá o código de origem em
JavaScript. Por exemplo, digite connect e pressione a tecla Enter para ver o código
de origem usado para se conectar a um banco de dados do MongoDB.

Criando bancos de dados, coleções e documentos
Por padrão, o shell do Mongo se conecta ao banco de dados "test". Para mudar
para outro banco de dados, use o comando "use dbname". Se o banco de dados não
existir, o MongoDB o criará assim que forem incluídos dados nele. Vamos mudar
para o banco de dados "mymongo" com o seguinte comando: > use mymongo.
O shell deve apresentar a mensagem: switched to db mymongo.
119
Nesse ponto, o banco de dados ainda não existe, porque não contém
dados. No MongoDB, os dados são armazenados em coleções, permitindo separar
documentos, se necessário. Vamos criar um documento e armazená-lo em uma
nova coleção chamada "colors": > db.colors.save({name:"red",value:"FF0000"});.
Vamos verificar se o documento foi armazenado procurando o banco de

dados: > db.colors.find();.
Deve aparecer uma resposta similar à seguinte (o atributo _id é um

identificador exclusivo e provavelmente será diferente no seu resultado): { "_id" :
ObjectId("4cfa43ff528bad4e29beec57"), "name" : "red", "value" : "FF0000" }.
Os documentos no MongoDB são armazenados como BSON (JSON

binário). Usando o shell do Mongo, podemos inserir dados utilizando uma sintaxe
semelhante à JSON, na qual cada documento é um objeto de pares de chave/
valor. Nesse exemplo, criamos um documento com dois atributos: name e valor,
que têm os valores red e FF0000 (a representação hexadecimal da cor vermelha
padrão), respectivamente.
Como talvez tenha notado, não é preciso predefinir a coleção colors ; isso

é feito automaticamente ao inserir um item usando a função save.
Nesse exemplo, criamos um documento bem simples. Contudo, a sintaxe

semelhante à JSON usada também pode ser utilizada para criar documentos
mais complexos. Veja o seguinte documento JSON, que representa uma ordem
de compra ou fatura (consulte a Listagem 8).
Listagem 8. Criando um documento simples

{
order_id: 109384,
order_date: new Date("12/04/2010"),
customer: {
name: "Joe Bloggs",
company: "XYZ Inc.",
phone: "(555) 123-4567"
},
payment: {
type: "Cash",
amount: 4075.99,
paid_in_full: true
},
items: [
{
120
sku: "ABC1200",
description: "A sample product",
quantity: 1,
price_per_unit: 75.99,
}, {
sku: "XYZ3400",
description: "An expensive product",
quantity: 2,
price_per_unit: 2000
}
],
cashier_id: 340582242
}
Como se pode ver, esses documentos podem armazenar vários tipos

de dados, incluindo cadeias de caractere, números inteiros, flutuantes, datas,
objetos, arrays, e muito mais. Na Listagem 8, os itens do pedido foram integrados
diretamente ao documento da ordem, agilizando a recuperação dessas informações
ao consultar o documento posteriormente.
Visto que o shell do MongoDB usa JavaScript, é possível escrever construções

regulares em JavaScript ao interagir com os bancos de dados. Veja a Listagem 9, que
cria uma coleção de documentos de caracteres, cada um contendo a representação
da cadeia de caractere do caractere e seu código ASCII associado.
Listagem 9. Criando uma coleção de documentos de caracteres

> var chars = "abcdefghijklmnopqrstuvwxyz"
> for(var i =0; i<chars.length; i++) {
... var char = chars.substr(i, 1);
... var doc = {char:char, code: char.charCodeAt(0)};
... db.alphabet.save(doc);
... }
Este loop criará 26 documentos, um para cada letra minúscula do alfabeto,

cada documento contendo o caractere em si e seu código de caractere ASCII. Na
próxima seção, veremos como recuperar esses dados de várias maneiras.
Recuperando dados
Na última seção, não só aprendemos a inserir dados em um banco de

dados do MongoDB, mas também a usar a função mais básica de recuperação de
dados, find. Vamos começar usando o comando find na coleção de alfabeto que
criamos no final da seção anterior:db.alphabet.find();.
Isso deve gerar uma resposta semelhante à Listagem 10.
121
Listagem 10. Resposta gerada

> db.alphabet.find()
{ "_id" : ObjectId("4cfa4adf528bad4e29beec8c"), "char" : "a", "code" : 97 }
{ "_id" : ObjectId("4cfa4adf528bad4e29beec8d"), "char" : "b", "code" : 98 }
{ "_id" : ObjectId("4cfa4adf528bad4e29beec8e"), "char" : "c", "code" : 99 }
{ "_id" : ObjectId("4cfa4adf528bad4e29beec8f"), "char" : "d", "code" : 100 }
{ "_id" : ObjectId("4cfa4adf528bad4e29beec90"), "char" : "e", "code" : 101 }
{ "_id" : ObjectId("4cfa4adf528bad4e29beec91"), "char" : "f", "code" : 102 }
{ "_id" : ObjectId("4cfa4adf528bad4e29beec92"), "char" : "g", "code" : 103 }
{ "_id" : ObjectId("4cfa4adf528bad4e29beec93"), "char" : "h", "code" : 104 }
{ "_id" : ObjectId("4cfa4adf528bad4e29beec94"), "char" : "i", "code" : 105 }
{ "_id" : ObjectId("4cfa4adf528bad4e29beec95"), "char" : "j", "code" : 106 }
{ "_id" : ObjectId("4cfa4adf528bad4e29beec96"), "char" : "k", "code" : 107 }
{ "_id" : ObjectId("4cfa4adf528bad4e29beec97"), "char" : "l", "code" : 108 }
{ "_id" : ObjectId("4cfa4adf528bad4e29beec98"), "char" : "m", "code" : 109 }
{ "_id" : ObjectId("4cfa4adf528bad4e29beec99"), "char" : "n", "code" : 110 }
{ "_id" : ObjectId("4cfa4adf528bad4e29beec9a"), "char" : "o", "code" : 111 }
{ "_id" : ObjectId("4cfa4adf528bad4e29beec9b"), "char" : "p", "code" : 112 }
{ "_id" : ObjectId("4cfa4adf528bad4e29beec9c"), "char" : "q", "code" : 113 }
{ "_id" : ObjectId("4cfa4adf528bad4e29beec9d"), "char" : "r", "code" : 114 }
{ "_id" : ObjectId("4cfa4adf528bad4e29beec9e"), "char" : "s", "code" : 115 }
{ "_id" : ObjectId("4cfa4adf528bad4e29beec9f"), "char" : "t", "code" : 116 }
has more
>
Por padrão, a função find() recupera todos os documentos da coleção,

mas exibe apenas os 20 primeiros documentos. O comando itrecuperará os 6
documentos restantes (veja a Listagem 11).
Listagem 11. Recuperando os 6 documentos restantes

> it
{ "_id" : ObjectId("4cfa4adf528bad4e29beeca0"), "char" : "u", "code" : 117 }
{ "_id" : ObjectId("4cfa4adf528bad4e29beeca1"), "char" : "v", "code" : 118 }
{ "_id" : ObjectId("4cfa4adf528bad4e29beeca2"), "char" : "w", "code" : 119 }
{ "_id" : ObjectId("4cfa4adf528bad4e29beeca3"), "char" : "x", "code" : 120 }
{ "_id" : ObjectId("4cfa4adf528bad4e29beeca4"), "char" : "y", "code" : 121 }
{ "_id" : ObjectId("4cfa4adf528bad4e29beeca5"), "char" : "z", "code" : 122 }
>
A função find() na verdade, retorna um cursor para o conjunto de

resultados da consulta, nesse caso retrieve all documents. Quando isso não
é atribuído a uma variável ou não são executadas outras funções, por padrão
será impresso um conjunto de resultados de amostra na tela. Para exibir todo o
conjunto de resultados, podemos usar o seguinte comando: > db.alphabet.find().
forEach(printjson);.
122
Isso imprime todos os registros no conjunto de resultados, em vez de exibir

um subconjunto. A seguir, veremos mais sobre como usar cursores e consultas
para filtrar dados.
Consultando dados
Um dos maiores pontos fortes do MongoDB é seu suporte poderoso a

consulta ad-hoc que funciona mais ou menos da mesma maneira que em bancos de
dados relacionais tradicionais, embora filtre e retorne documentos BSON em vez
de linhas da tabela. Essa abordagem o destaca em relação a outros armazenamentos
de documentos, que muitas vezes são difíceis para que desenvolvedores SQL se
familiarizem. Com o MongoDB, consultas SQL relativamente complexas podem
ser facilmente convertidas em chamadas de função JavaScript. Nesta seção,
aprenderemos as várias funções disponíveis que permitem consultar os dados no
MongoDB, e como configurar índices para ajudar a otimizar suas consultas, como
se faria de forma semelhante em DB2, MySQL ou Oracle.
Consultas básicas
Na seção anterior, aprendemos a usar a função find para recuperar todos

os documentos. A função find aceita uma série de argumentos que permitem
filtrar os resultados retornados. Por exemplo, na coleção de alfabeto que criamos
anteriormente, é possível encontrar todos os registros em que o atributo "char"
tem valor "q" com o seguinte comando: > db.alphabet.find({char: "o"});.
Isso retorna a seguinte resposta: { "_id" :

ObjectId("4cfa4adf528bad4e29beec9a"), "char" : "o", "code" : 111 }.
Se quisermos retornar todos os caracteres com código menor ou igual a

100, podemos usar o seguinte comando: > db.alphabet.find({code:{$lte:100}});.
Isso retorna o resultado na Listagem 12, como é de esperar.
Listagem 12. Resultado

{ "_id" : ObjectId("4cfa4adf528bad4e29beec8c"), "char" : "a", "code" : 97 }
{ "_id" : ObjectId("4cfa4adf528bad4e29beec8d"), "char" : "b", "code" : 98 }
{ "_id" : ObjectId("4cfa4adf528bad4e29beec8e"), "char" : "c", "code" : 99 }
{ "_id" : ObjectId("4cfa4adf528bad4e29beec8f"), "char" : "d", "code" : 100 }
O MongoDB suporta uma variedade de operadores condicionais,

incluindo:
• $lt (menor que)
• $lte (menor ou igual a)
• $gt (maior que)
• $gte (maior ou igual a)
• $all (corresponder a todos os valores em um array)
• $exists (verificar se um campo existe ou não)
123
• $mod (módulo)
• $ne (não igual)
• $in (corresponder a um ou mais valores em um array)
• $nin (corresponder a valores zero em um array)
• $or (corresponder uma consulta a outra)
• $nor (não corresponder uma consulta nem outra)
• $size (corresponder qualquer array com número definido de elementos)
• $type (corresponder valores com tipo de dados BSON especificado)
• $not (não igual a)
Para obter mais detalhes sobre todos esses operadores, consulte a

documentação do MongoDB.
É possível restringir os campos que são retornados por suas consultas

usando um segundo argumento na função find. Por exemplo, a seguinte consulta
retornará apenas o atributo char para qualquer documento com valor de código
entre 102 e 105: > db.alphabet.find({code:{$in:[102,103,104,105]}}, {char: 1});.
Isso deve produzir o resultado da Listagem 13.
Listagem 13. Resultado

{ "_id" : ObjectId("4cfa4adf528bad4e29beec91"), "char" : "f" }
{ "_id" : ObjectId("4cfa4adf528bad4e29beec92"), "char" : "g" }
{ "_id" : ObjectId("4cfa4adf528bad4e29beec93"), "char" : "h" }
{ "_id" : ObjectId("4cfa4adf528bad4e29beec94"), "char" : "i" }
Conclusão
Neste artigo, aprendemos sobre o sistema de gerenciamento de banco de

dados MongoDB e por que é uma das opções que mais cresce na seção NoSQL
popular do mercado de DBMS. Aprendemos por que escolher um banco de
dados orientado a documentos em vez de um RDBMS tradicional, e os diversos
recursos excelentes que o MongoDB tem a oferecer. Aprendemos a instalar e
usar o MongoDB para armazenamento e recuperação de dados, e conhecemos as
várias ferramentas e opções de escalabilidade que ele proporciona.
FONTE: Adaptado de: <https://www.ibm.com/developerworks/br/library/os-mongodb4/>. Acesso
em: 20 out. 2015
124
RESUMO DO TÓPICO 2
Neste tópico apresentamos:
De modo a podermos desenvolver, implantar e testar aplicações que

utilizem as tecnologias que fazem parte da especificação JEE, precisamos de um
servidor de aplicação – application server (AS).
O JSF é um framework baseado no padrão MVC, onde o model são as

classes de entidade, a view são as interfaces desenvolvidas em JSF e o controller é
representado pelos Managed Beans, também conhecidos como Backing Beans.
Para ser considerada um Java Bean, uma classe deverá obedecer às

seguintes restrições:
• Todos os atributos devem ser privados, com getters e setters.

• Deve possuir no mínimo um construtor default vazio, embora possa ter mais
construtores e métodos auxiliares.
• Deve implementar a interface Serializable.
É possível implementar métodos de validação ou conversão de dados

personalizados no JSF.
O JSF implementa em forma de componentes a maioria dos elementos

HTML.
O JSF possui suporte nativo à AJAX desde a versão 2.0, o que facilita mais
uma vez o trabalho dos desenvolvedores.
O JSF permite que você modifique o layout dos componentes da interface

gráfica através de bibliotecas visuais de terceiros. Estas bibliotecas facilitam o
trabalho de deixar a aplicação mais agradável para os usuários, pois eliminam o
css e demais frameworks como o bootstrap.
A grande maioria das aplicações desenvolvidas no mercado tem a

necessidade de persistir suas informações em alguma espécie de repositório que
permita a recuperação das mesmas em um momento posterior.
A linguagem de programação Java possui uma API projetada

unicamente para se trabalhar com bancos de dados relacionais, conhecida
como JDBC (Java Database Conectivity) e que dá suporte a um grande número
de produtos existentes no mercado.
O problema de mapeamento objeto relacional é um problema difícil de ser

resolvido.
125
Observando a popularidade e a qualidade do Hibernate, a Oracle resolveu,
através do JCP, criar uma especificação para o mapeamento objeto relacional.
O JPA fornece um conjunto de interfaces e classes para serem utilizadas

em aplicações Java, fazendo parte da especificação JEE desde a versão 5.0.
O JPA permite a persistência do estado de qualquer classe Java, bastando

para tal colocar as anotações obrigatórias
O JPA fica responsável pela criação das tabelas no banco de dados e

posteriores operações de mapeamento objeto relacional.
126
AUTOATIVIDADE
1 Implemente uma funcionalidade de pesquisa de pessoas pelo nome,

utilizando JPA e JSF. O resultado deverá ser uma lista de pessoas cujo nome
seja igual ao nome digitado na pesquisa. Utilize o comando LIKE para
atingir este resultado.
2 Configure e utilize outro datasource com um banco de dados diferente do

MYSQL para fazer a persistência de objetos pessoa.
3 Implemente o CRUD de Pessoa utilizando pelo menos mais uma

implementação da especificação JPA diferente do Hibernate. Você sentiu
alguma diferença? Qual?
127
128
UNIDADE 3
ENTERPRISE JAVA BEANS (EJB)

E CONTEXT AND DEPENDENCY
INJECTION (CDI)
Ao final desta unidade você será capaz de:
• entender as características e o funcionamento dos EJB;
• identificar o componente adequado para cada situação, de forma a

otimizar os recursos da tecnologia;
• utilizar os recursos de injeção de dependência nativos ao AS.
PLANO DE ESTUDOS
Esta unidade de ensino está dividida em quatro tópicos, sendo que no
final de cada um deles, você encontrará atividades que contribuirão para a
TÓPICO 1 – STATELESS SESSION BEANS
TÓPICO 2 – STATEFULL SESSION BEANS E SINGLETON SESSION BEANS
TÓPICO 3 – CONTEXT AND DEPENDENCY INJECTION
TÓPICO 4 – JAVA MESSAGING SERVICES
129
130
UNIDADE 3
TÓPICO 1
STATELESS SESSION BEANS
1 INTRODUÇÃO
Nas tecnologias da família EJB é que percebemos a verdadeira extensão
das capacidades do JAVAEE.
Conforme K19 (2015), muitos sistemas corporativos são desenvolvidos

seguindo a arquitetura definida pelo padrão EJB. Ao utilizar esta arquitetura,
alguns recursos são disponibilizados automaticamente pelo AS. Entre estes
recursos, podemos destacar:
• Transações: A arquitetura EJB define um suporte para utilização de transações.

Esse suporte é integrado com a Java Transaction API (JTA), incluindo a
possibilidade de realizar transações distribuídas.
• Segurança: Suporte para realizar autenticação e autorização de forma

declarativa. Os desenvolvedores das aplicações não precisam implementar a
lógica de segurança pois ela faz parte da arquitetura.
• Remotabilidade: Aplicações EJB podem ser acessadas remotamente através

de diversos protocolos de comunicação. Consequentemente, é possível
desenvolver aplicações clientes de diversos tipos.
• Multithreading e Concorrência: A arquitetura EJB permite que as aplicações

sejam acessadas por múltiplos usuários simultaneamente de maneira
controlada. A concorrência é controlada pelo AS.
• Persistência: Persistência através da especificação JPA.
• Gerenciamento de Objetos: Mecanismos de injeção de dependências e

controle de ciclo de vida são oferecidos aos objetos de uma aplicação EJB. A
escalabilidade de uma aplicação é garantida através deste mecanismo.
• Integração: A arquitetura EJB é fortemente integrada com os componentes da

plataforma Java EE.
131
UNIDADE 3 | ENTERPRISE JAVA BEANS (EJB) E CONTEXT AND DEPENDENCY INJECTION (CDI)
2 STATELESS SESSION BEANS

Um objeto é geralmente composto de estado e comportamento, entretanto,
em muitas situações encontramos procedimentos, regras de negócio e fluxos que
representam somente um comportamento e não precisam de estado. Você já está
familiarizado com esse conceito ao utilizar algumas classes da plataforma Java
que possuem métodos estáticos. Um exemplo é demonstrado na figura a seguir,
onde se pode perceber que a classe Integer não precisa de instanciação e não
possui estado. Ao solicitar que a String seja convertida para um inteiro, basta
chamar o método estático que o mesmo retornará o resultado, sem que o objeto
mantenha estado.
FIGURA 114 – MÉTODOS ESTÁTICOS
FONTE: O autor
Para exemplificar, vamos considerar um sistema bancário, onde os

empréstimos, transferências, saques, depósitos, cobranças etc. são as regras de
negócio. Cada aplicação possui suas próprias regras de negócio, consequência do
ramo de atuação e do contexto da mesma.
Ao utilizar a arquitetura EJB para implementar estas regras de negócio,

cada regra ou conjunto de regras é implementada em componentes específicos,
conhecidos como stateless session beans, cuja principal característica é a não
manutenção de estado conversacional.
2.1 EJB 3.0

Conforme K19 (2015), o primeiro passo para implementar um
stateless session bean é definir os métodos de negócio através de uma interface.
Considerando um componente para a realização de operações matemáticas, uma
possível interface é demonstrada na figura a seguir.
132
TÓPICO 1 | STATELESS SESSION BEANS
FIGURA 115 – INTERFACE DE NEGÓCIOS
FONTE: Adaptado de K19 (2015)
Os métodos dentro desta interface são chamados de métodos de negócio.

O próximo passo seria a implementação dos métodos de negócio propriamente
ditos e a definição das características do stateless session bean através de annotations,
conforme a figura que segue.
E
IMPORTANT
É importante perceber que nem toda a aplicação se beneficia destas facilidades

oferecidas pelo AS. Remotabilidade, concorrência e transações distribuídas podem ser úteis
em alguns cenários, mas a complexidade da configuração e definição destes serviços no AS
pode não compensar sua utilização em cenários mais simples.
FIGURA 116 – STATELESS SESSION BEAN
133
Como esta classe implementa a interface Calculadora, somos obrigados a

fornecer implementação para todos os métodos que nela forem definidos, conforme
pode ser observado nos métodos soma, subtrai, multiplica e divide (linhas 13 a
27). As anotações definidas nas linhas 10 e 11 é que caracterizam a classe como
um stateless session bean. A anotação @Stateless especifica a característica de não
manutenção de estado conversacional, enquanto a anotação @Local define que
este é um EJB local que implementa os métodos de negócio de Calculadora.class.
Um stateless session bean pode implementar várias interfaces, porém, apenas os
métodos das interfaces que estiverem dentro da anotação são considerados como
métodos de negócio.
Caso o stateless session bean deve ser utilizado também na forma remota,
a anotação muda, conforme pode ser visto na figura a seguir. Ao marcá-lo desta
forma, estamos permitindo que a aplicação possa ser colocada em instâncias
diferentes do AS. Em termos práticos, essa prática auxilia a colocação de uma
aplicação na nuvem, pois a escalabilidade é atingida de forma transparente para o
desenvolvedor. Uma instância do AS pode ficar em uma máquina e ser responsável
pela interface web e mobile em android ou html, enquanto outra instância mantém os
ejb e uma terceira máquina poderia ser responsável pelo banco de dados.
FIGURA 117 – STATELESS SESSION BEAN REMOTO
2.2 EJB 3.1

Na versão 3.1, quando o acesso ao stateless session bean é local, não é mais
necessário definir a interface nem utilizar a anotação @Local, bastando anotar
uma classe com @Stateless, conforme a figura a seguir.
134
FIGURA 118 – STATELESS SESSION BEAN, VERSÃO 3.1
2.3 TESTANDO O EJB

Considerando que os stateless session beans são utilizados para a
implementação das regras de negócio que não necessitam de estado conversacional,
precisaremos de uma interface para testá-los.
Para simplificar o acesso ao EJB, faremos seu acesso através de servlets.

Nosso stateless session bean pode ser injetado em um servlet através da anotação @
EJB. A figura a seguir traz a implementação do servlet propriamente dito.
E
IMPORTANT
Apesar dos servlets não fazerem parte do escopo deste caderno, eles são
extremamente importantes no ecossistema JAVAEE. Maiores detalhes sobre os servlets
podem ser acessados em: <https://www.caelum.com.br/apostila-java-web/servlets/>.
135
FIGURA 119 – MENSAGENS DE VALIDAÇÃO
Agora é hora de paramos um pouco para entender o que aconteceu. A linha

16 traz a anotação que define a URL de seu servlet, cuja função, essencialmente
é receber dois doublés como parâmetro via request (a e b) para então exibir um
html com o resultado da operação de soma. O detalhe interessante é que na linha
20 anotamos o tipo Calculadora como um EJB. Mas por que definimos como
calculadora ao invés de calculadora Bean? Vou esperar 30 segundos para lhe dar
a resposta. Vá em frente... pense e responda que eu aguardo.
É isso mesmo! Definimos como Calculadora porque a Calculadora Bean

implementa a interface Calculadora e, esta é uma boa prática, como você já viu
em disciplinas anteriores.
Voltando ao EJB, a anotação utilizada faz com que o ciclo de vida deste
objeto seja completamente gerenciado pelo AS. Sua criação, utilização e destruição
não é responsabilidade do desenvolvedor, que pode gastar seu tempo com coisas
mais úteis, como por exemplo, implementar regras de negócio ou jogar Playstation
4. Uma característica bastante interessante é que, digamos que cada instância da
calculadora pode atender a um usuário de cada vez e, ocorra que 11 usuários
estejam tentando acessar seu importante serviço de cálculo ao mesmo tempo.
O que acontece? O AS automaticamente instância um novo objeto para atender
a estes 10 usuários. Isso pode ser configurado no AS, de forma que sua classe
atenda mais ou menos do que 10 usuários simultâneos, bem como o número de
instâncias que serão geradas.
Outra característica relevante é que tudo isto faz parte da especificação, ou

seja, se você escolher GlassFish, Wildfly, WebLogic ou qualquer outro servidor de
aplicação que obedeça à especificação EJB, esta característica de controle do ciclo de
vida vem embutida. Se você achou isso legal, espere até chegarmos no CDI.
136
Os EJB são desconectados da interface gráfica e da persistência (afinal,

podemos utilizar JPA), o que permite que ao invés de HTML puro com um servlet,
criemos um JSF conectado a um Managed Bean que declara o EJB, conforme
ilustrado na figura a seguir.
FIGURA 120 – MANAGED BEAN INJETANDO O EJB
Na linha 6 está a anotação @Named, que faz o bind entre o arquivo

JSF e managed bean. Na linha 9, da mesma forma que no servlet, injetamos a
calculadora com a anotação EJB. O restante do comportamento é o mesmo que
foi exemplificado anteriormente.
Até agora trabalhamos somente com os stateless session beans sendo

acessados localmente por aplicações web e através da anotação @EJB. Isso ocorre
somente quando o EJB é instalado no mesmo AS onde seus acessos são feitos, ou
seja, a aplicação que faz chamadas ao componente deve estar no mesmo AS.
Quando o acesso é remoto, em outro servidor de aplicação, não dispomos

do recurso de injeção de dependência. Por este motivo, todo stateless session bean
implantado em um servidor de aplicação deve receber um nome único, que é
utilizado para se obter a referência remota a este componente.
Conforme K19 (2015), antes da versão 3.1, os nomes dos sessions beans não
seguiam nenhum padrão, o que dificultava o desenvolvimento em servidores
de aplicação distintos. A partir da versão 3.1 os nomes são padronizados e,
portanto, portáveis entre os servidores de aplicação. Uma aplicação remota deve
acessar o serviço de nomes (JNDI) do AS no qual o EJB que ela deseja utilizar está
implantado, conforme a Figura 121. Uma vez com a referência do stateless session
bean, o acesso remoto ocorre exatamente como o local, de forma transparente para
a aplicação. Logicamente, como o acesso ocorre em outro servidor, o tempo de
resposta geralmente é mais lento.
137
E
IMPORTANT
As regras para nomenclatura podem ser acessadas em: <https://jcp.org/en/jsr/

detail?id=318>.
FIGURA 121 – LOOKUP DO NOME DO EJB
FONTE: K19 (2015)
2.4 CICLO DE VIDA

As instâncias dos stateless session beans são administradas pelo EJB Container
dentro do servidor de aplicação. Devemos entender o ciclo de vida desses objetos
para utilizar corretamente a tecnologia EJB. Três aspectos fundamentais dos
stateless session beans ajudam a entender o ciclo de vida das instâncias (K19, 2015).
1. Uma única instância de um SLSB pode atender às chamadas de diversos
clientes.
2. Uma instância de um SLSB não atende a duas chamadas ao mesmo tempo.
3. O EJB Container pode criar várias instâncias do mesmo SLSB para atender
mais rapidamente às chamadas dos clientes.
O ciclo de vida das instâncias de um stateless session bean possui apenas

dois estados: NÃO EXISTE e PRONTO onde as variações de estado são as
seguintes (K19, 2015):
NÃO EXISTE -> PRONTO

Antes de ser criada, dizemos que uma instância de um SLSB se encontra
no estado NÃO EXISTE. Neste estado, uma instância não pode atender a
chamadas dos clientes. De acordo com a quantidade de chamadas e critérios de
cada servidor de aplicação, o EJB Container pode criar novas instâncias de um
SLSB. Cada instância criada passa para o estado PRONTO, onde pode começar a
receber chamadas.
PRONTO -> PRONTO

Quando uma chamada é realizada, o EJB Container seleciona uma instância
entre as que estejam no estado PRONTO para realizar o atendimento. Enquanto
uma instância está atendendo a uma chamada ela não pode atender a outras
chamadas. Depois de finalizar o atendimento, a instância volta para o estado
PRONTO podendo receber outras chamadas.
138
PRONTO -> NÃO EXISTE

Novamente, de acordo com a quantidade de chamadas e critérios de cada
servidor de aplicação, o EJB Container pode destruir instâncias que estejam no
estado PRONTO, levando-as ao estado NÃO EXISTE.
2.5 ESCALABILIDADE, POOL E CALL-BACKS

K19 (2015) coloca que as características dos stateless session beans favorecem
a escalabilidade da aplicação pois, de acordo com a demanda, o EJB Container cria
novas instâncias e cada instância pode atender vários clientes.
O EJB Container administra as instâncias criadas através de um Pool.

Cada servidor de aplicação oferece configurações específicas para melhorar a
eficiência no atendimento das chamadas. Por exemplo, o Glassfish permite que
uma quantidade máxima de instâncias de um determinado stateless session beans
seja definida pela aplicação (K19, 2015).
Através dos call-backs podemos associar algoritmos nas transições de

estado dos stateless session beans. Isso ocorre através de anotações definidas para
esta finalidade, conforme demonstrado nas Figuras 122 e 123.
FIGURA 122 – ANOTAÇÃO @POSTCONSTRUCT
139
FIGURA 123 – ANOTAÇÃO @PREDESTROY
Na linha 15 da Figura 122, colocamos a anotação @PostConstruct. Como

o nome indica, o objetivo desta anotação é fazer com que este método execute
quando uma nova instância é criada. Já na linha 32 da Figura 123, o objetivo da
anotação @PreDestroy é executar o que estiver definido no método logo antes
da instância ser destruída pelo AS. Ambas as anotações somente podem ser
colocadas antes de métodos.
2.6 MÉTODOS ASSÍNCRONOS

A partir da versão 3.1 dos EJBs, é possível definir métodos assíncronos. Tais
métodos são utilizados para implementar tarefas longas que não podem bloquear o
resto da aplicação até que sejam encerradas. Por exemplo, um processo de compra
on-line possui alguns passos que não podem ser assíncronos como a seleção dos
produtos, o fechamento da conta e o processo de pagamento. Já a comunicação do
sistema de compra com a parte de logística não precisa ser síncrona. É possível,
após a realização da compra de um produto, chamar um método assíncrono para
agendar a entrega. Neste contexto, assíncrono significa que será atendido em algum
momento próximo. Em geral, o servidor de aplicação coloca a execução destes
métodos em pilhas e os executa em sequência. Observe que isto não significa um
atraso de dias ou semanas na execução, mas sim de minutos.
140
E
IMPORTANT
Nem todas as operações podem ou devem ser colocadas para executar de forma
assíncrona. O modelo de negócios deve ser avaliado para ver se permite este tipo de flexibilidade.
Para utilizarmos os métodos assíncronos, basta anotar a classe ou o(s)

método(s) que deve(m) ser definido(s) como assíncrono(s) através da anotação
@Asynchronous (Figura 124). Podemos observar que o retorno dos métodos
assíncronos é feito através da interface Future, pertencente ao pacote java.util.
concurrent. Através desta interface é possível verificar se a tarefa já foi concluída
pelo método isDone() e também recuperar o resultado através do método get().
FIGURA 124 – MÉTODOS ASSÍNCRONOS
141
RESUMO DO TÓPICO 1
• Muitos sistemas corporativos são desenvolvidos seguindo a arquitetura

definida pelo padrão EJB. Ao utilizar esta arquitetura, alguns recursos são
disponibilizados automaticamente pelo servidor de aplicação.
• Os dois principais tipos de EJB são os stateless session beans e os statefull session
beans.
• Transações, segurança, remotabilidade e concorrência são alguns dos recursos

disponibilizados automaticamente pelo servidor de aplicação.
• A principal característica dos stateless session beans é a não manutenção de

estado conversacional.
• Os stateless session beans podem ser locais ou remotos.
• Os EJBs podem ser injetados em aplicações web, independentemente de se

utilizar Servlets ou Managed Beans no back end.
142
AUTOATIVIDADE
1 Implemente uma interface web para a calculadora do exemplo utilizando

html. A interface deve permitir a utilização de todas as operações.
2 Faça o mesmo que foi solicitado na questão 1, utilizando JSF. Você deve
implementar a interface através de um xhtml e o managed bean que fará a
interação com o stateless session bean.
3 Descreva detalhadamente o ciclo de vida de um stateless session bean.
143
144
UNIDADE 3
TÓPICO 2
STATEFUL SESSION BEAN E SINGLETON SESSION BEANS
1 INTRODUÇÃO
Enquanto a ideia dos stateless session beans era representar um processo
ou uma regra de negócio através de um componente composto por uma ou mais
classes e seus métodos, os stateful session bean trabalham de modo a representar
um conceito da aplicação cujo estado deva ser mantido, como um cliente, um
produto ou um carrinho de compras (Figura 125). Para resumir...um STATEFUL
session bean tem por objetivo manter estado conversacional.
K19 (2015) coloca que existem duas necessidades fundamentais para

serem observadas nos STATEFUL session bean:
1) Cada instância de CarrinhoBean pode atender somente a uma requisição.

Imagine a confusão se os produtos de um cliente se misturassem com os
produtos de outro.
2) Os produtos adicionados devem ser mantidos entre as chamadas dos métodos
da classe, o que configura o estado conversacional.
FIGURA 125 – CARRINHOBEAN
FONTE: K19 (2015)
145
2 STATEFULL SESSION BEANS 3.0

Da mesma forma que os stateless session beans, o primeiro passo é a
definição de sua interface. Considerando o exemplo de carrinho de compras, uma
possível implementação da interface é mostrada na figura a seguir.
FIGURA 126 – INTERFACE PARA O BEAN
FONTE: K19 (2015)
Após a definição desta interface, agora, implementaremos a classe java

que utiliza a Interface.
FIGURA 127 – CADASTRO DE PESSOA
FONTE: K19 (2015)
Para encerrar, precisaremos definir o tipo statefull para o session bean e

se ele será acessado localmente ou remotamente. Ambas as configurações são
feitas através de anotações, conforme demonstrado na figura a seguir. Podemos
perceber as linhas 9 e 10 que fazem estas configurações.
146
TÓPICO 2 | STATEFUL SESSION BEAN E SINGLETON SESSION BEANS
FIGURA 128 – CONFIGURAÇÕES DO EJB
FONTE: K19 (2015)
E
IMPORTANT
É notório que os stateless e statefull session beans são configurados exatamente

da mesma forma. O que muda é a característica do componente, que deve ser utilizado de
acordo com o contexto de sua aplicação.
3 STATEFULL SESSION BEANS 3.1

Na versão 3.1 quando o acesso é local, não há mais necessidade de se
definir uma interface ou utilizar a anotação @Local, bastando anotar uma classe
com @Stateful, conforme a Figura 129.
3.1 CICLO DE VIDA DOS STATEFULL SESSION BEANS

Todas as instâncias criadas pelo AS, mais especificamente pelo EJB
Container, têm seu ciclo de vida administrado de forma transparente para o
desenvolvedor. Um statefull session bean possui somente três estados: NÃO
EXISTE, PRONTO, PASSIVADO.
147
FIGURA 129 – VERSÃO 3.1
FONTE: K19 (2015)
As transições de estado possíveis para um statefull session bean são

demonstradas abaixo K19(2015):

Antes de ser criada, dizemos que uma instância de um statefull session
bean se encontra no estado NÃO EXISTE. Neste estado, uma instância não pode
atender às chamadas do seu cliente. Quando um cliente recebe por injeção ou
recupera por lookup um statefull session bean, o EJB Container cria uma nova
instância desse componente para atender exclusivamente a esse cliente. Nesse
instante, logo após ser criada, a instância se encontra no estado PRONTO e pode
atender às chamadas do seu respectivo cliente.
PRONTO -> PASSIVADO

Uma instância de um statefull session bean fica ociosa enquanto não estiver
processando uma chamada do seu cliente. Para não consumir a memória do
computador, depois de um certo tempo de ociosidade, o EJB Container pode
transferir o conteúdo de uma instância ociosa para dispositivos secundários de
armazenamento (hard disk), em um processo conhecido como passivação e deixa
a instância no estado PASSIVADO. Outros fatores, além da ociosidade, podem
levar o EJB Container decidir passivar instâncias dos SFSBs. Por exemplo, quando
um certo limite de instâncias no estado PRONTO for atingido.
PASSIVADA -> PRONTO

Se o cliente de uma instância passivada realizar uma chamada a ela, o
EJB Container realizará automaticamente o processo de ativação. Esse processo
consiste na transferência do conteúdo da instância passivada para a memória
principal novamente, deixando-a apta a atender chamadas no estado PRONTO.

Em determinadas situações, uma instância de um stateful session bean pode
não ser mais útil. Por exemplo, quando o cliente de um carrinho de compras finaliza
a compra, a instância que representa o carrinho pode ser destruída. É possível ainda
adicionar um método de negócio anotado com @Remove, declarando que após a
execução desse método a instância não é mais necessária (Figura 130).
148
FIGURA 130 – MÉTODO REMOVE
FONTE: Adaptado de K19(2015)
PASSIVADO -> PRONTO -> NÃO EXISTE
Uma instância pode ser passivada porque ficou ociosa quando estava no
estado PRONTO. Isto ocorre quando um cliente não realiza chamada durante um
tempo. Quando uma instância passivada não é mais útil, o EJB Container a ativa e
depois a destrói (Figura 131).
FIGURA 131 – MUDANÇA DE ESTADO
FONTE: K19 (2015)
149
3.2 CALLBACKS
Da mesma forma que nos stateless session beans, os stateful session beans
permitem a associação de lógicas específicas nas transições de estado de seu
ciclo de vida.
As anotações @PostConstruct e @PreDestroy estão disponíveis nos stateful

session beans e, como existe um estado novo no ciclo de vida, foram adicionadas
as anotações @PrePassivate e @PostActivate. Estas novas anotações permitem
a adoção de lógica em métodos antes da passivação e logo depois da ativação.
Todas estas anotações estão demonstradas na figura a seguir.
FIGURA 132 – ANOTAÇÕES DISPONÍVEIS NOS STATEFUL SESSION BEANS
4 SINGLETON SESSION BEANS

Surgido na versão 3.1 da especificação Enterprise Java Beans, a ideia
fundamental deste tipo de componente é o compartilhamento de dados transientes
entre todos os usuários de uma aplicação. Um exemplo típico seria um contador
para o número de usuários conectados na aplicação cujo possível código está
demonstrado na Figura 133.
150
Para que este código contabilize corretamente o número de usuários

conectados, deve ser mantida uma única instância deste EJB.
FIGURA 133 – CÓDIGO FONTE PARA A CRIAÇÃO DO DATATABLE
FONTE: K19 (2015)
E
IMPORTANT
Este tipo de EJB é baseado no Padrão de Projeto conhecido como Singleton.

Maiores detalhes sobre este padrão de projeto podem ser obtidos em: <http://www.devmedia.
com.br/padrao-de-projeto-singleton-em-java/26392>.
Para implementar um Singleton Session Bean, é uma boa prática definir uma
interface com as assinaturas dos métodos de negócio (Figura 134). No exemplo
abaixo criaremos um singleton session bean para implementar um sistema de chat.
FIGURA 134 – LISTAGEM DE PESSOAS
FONTE: K19 (2015)
151
Os próximos passos seriam a implementação dos métodos propriamente

ditos dentro de uma classe java que serviria como o Singleton Session Bean, a
definição de que o mesmo seria um singleton, através da anotação @Singleton e,
finalmente, a especificação do tipo de acesso deste bean através da anotação @
Local ou @Remote. Caso o acesso ao Singleton Session Bean seja local, basta anotá-
lo com o @Singleton.
4.1 CICLO DE VIDA

De forma análoga aos session beans já estudados nesta unidade, os
singleton session beans tem seu ciclo de vida gerenciado pelo EJB Container
(parte integrante do AS... não esqueça). O singleton session bean possui dois
estados: NÃO EXISTE e PRONTO.
As variações entre estes estados são descritas abaixo, conforme K19 (2015):

Antes de ser criada, dizemos que uma instância de um Singleton Session
Bean se encontra no estado NÃO EXISTE. Neste estado, uma instância não pode
atender às chamadas dos clientes da aplicação. O EJB Container cria apenas uma
instância para cada Singleton Session Bean. Por padrão, o EJB Container é quem
decide quando a criação da instância de um Singleton Session Bean deve ser
realizada, apesar de ser possível determinar que essa criação seja realizada na
inicialização da aplicação através da anotação @Startup (Figura 135).
FIGURA 135 – ANOTAÇÃO @STARTUP
FONTE: O autor
152

Quando a aplicação é finalizada, o EJB Container destrói as instâncias
dos Singleton Session Beans, passando do estado PRONTO para o NÃO EXISTE
(Figura 136).
FIGURA 136 – CICLO DE VIDA DOS SINGLETON SESSION BEANS
FONTE: K19 (2015)
E
IMPORTANT
Os callbacks @PostConstruct e @PreDestroy também estão disponíveis para os

Singleton Session Beans através das anotações respectivas.
153
RESUMO DO TÓPICO 2
Neste tópico você viu:
• Os statefull session beans possuem praticamente as mesmas funcionalidades dos

stateless session beans, entretanto, são caracterizados pela manutenção do estado
conversacional.
• Os singleton session beans são um terceiro tipo de session bean que permite a
manutenção e compartilhamento de estado entre todos os usuários de uma
aplicação.
• O conhecimento do ciclo de vida dos session beans permite sua utilização mais
efetiva.
• Tanto os stateful quanto os singleton session beans permitem a utilização de

métodos de callback que podem possuir lógica de negócios a ser realizada após
a mudança de estado no ciclo de vida dos mesmos.
154
AUTOATIVIDADE
1 Implemente uma interface web para a loja virtual do exemplo de stateful

session bean, utilizando
2 Faça uma implementação de singleton session bean, que permita contar o

número de usuários simultâneos de sua loja virtual.
3 Descreva detalhadamente o ciclo de vida de um statefull session bean.
155
156
UNIDADE 3
TÓPICO 3
CONTEXT AND DEPENDENCY INJECTION
1 INTRODUÇÃO
Conforme K19 (2015), as aplicações corporativas trabalham mesclando o
container WEB para a camada de apresentação e o container EJB para a camada
de negócios. A especificação JEE permite que a integração entre estes dois
containers possa ser feita de forma mais fácil através da especificação Context and
Dependency Injection (CDI). Os dois pontos que destacaremos na arquitetura CDI
são o mecanismo de injeção de dependência e o gerenciamento do ciclo de vida
dos objetos por contextos.
Conforme Thiago (2010), existem vantagens e desvantagens na utilização

da injeção de dependência. Algumas das vantagens são:
1) Simplificação no código da aplicação. Com a injeção de dependência, os objetos

da aplicação são liberados da tarefa de trazer suas próprias dependências
(redução de código para inicialização e configuração de dependências); eles
ficam livres para executar apenas suas regras negociais, pois, sabem que as
suas dependências estarão lá quando necessárias.
2) Testabilidade. Se as dependências podem ser injetadas em um componente,
torna-se possível injetar implementações mocks destas dependências.
3) Baixo acoplamento entre os objetos. O objeto conhece suas dependências apenas
por sua interface pública (não por sua implementação, nem por como foram
instanciadas). Assim, a dependência pode ser trocada por uma implementação
diferente, sem que o objeto dependente conheça a diferença.
4) Flexibilidade no gerenciamento do ciclo de vida dos objetos. Objetos podem ser
colocados em um cache, serem um singleton ou ter uma vida curta – tudo passa
a ser controlado por meio de configurações e/ou pelo container.
Thiago (2010) também lista algumas desvantagens na injeção de

dependência:
1) Dificuldade no acompanhamento do código. Você vê a existência de um método no

código, você sabe que ele está sendo chamado por alguém para injetar um valor,
mas não se tem certeza de quando isso irá acontecer ou qual o valor que é injetado,
o que pode dificultar a rastreabilidade.
157
2) Quando se utiliza a DI baseada em propriedades (através de métodos), faz-se necessário

marcar suas dependências como públicas. Para que se utilize uma injeção via
setXxx(), por exemplo, esse método tem de ser tornado público. Desta forma
devemos tomar cuidado para não quebrar o encapsulamento de nossos objetos.
3) A cadeia de objetos pode se tornar muito grande. Mesmo que seja necessário fazer
apenas uma operação, todas as dependências são criadas e/ou precisam ser
resolvidas.
E
IMPORTANT
O termo injeção de dependência foi criado por Martin Fowler. Maiores detalhes
podem ser observados em: <http://martinfowler.com/articles/injection.html>.
2 PRODUCER METHODS E ATTRIBUTES

Na especificação CDI, os seguintes tipos de objetos possuem suporte aos
recursos do container:
• Managed beans e session beans;

• Criados por producer methods ou producer fields;
• Recursos em geral (Persistence Contexts, Persistence Units, EJBs locais ou remotos
e web services);
Os producer methods são métodos que produzem objetos a serem

administrados pelo container CDI para serem injetados em outros objetos (K19,
2015). Um exemplo de método produtor pode ser visto na Figura 137. Na linha 1
está a anotação que define o método como um Producer Method.
FIGURA 137 – PRODUCER METHOD
FONTE: K19 (2015)
O funcionamento dos atributos é bastante semelhante, bastando marcar

um atributo com a anotação @Produces para fazer com que o mesmo possa ser
injetado e ter seu ciclo de vida gerenciado pelo container. Um exemplo de código
fonte pode ser visto na Figura 138.
158
TÓPICO 3 | CONTEXT AND DEPENDENCY INJECTION
FIGURA 138 – CDI COM ATRIBUTOS
FONTE: K19 (2015)
3 EXPRESSION LANGUAGE (EL) NAME

Na arquitetura CDE, os objetos gerenciados pelo container podem ser
acessados através de EL. Para que isso ocorra, devemos aplicar a anotação @
Named aos objetos que possuirão um EL Name. Um exemplo de código fonte
pode ser visto na Figura 139. Nas linhas 9 e 10 podemos perceber as anotações
que definem que a classe é um stateless session bean, que pode ser injetada com
o nome geradorDeApostas. Ainda nesta classe, definimos o atributo produtos
como um objeto a ser gerenciado pelo container CDI, chamado pelo EL name
produtos. O mesmo foi feito com os dois métodos entre as linhas 18 e 28.
FIGURA 139 – COMPONENTE DATA TABLE
Para que o CDI seja ativado no AS, é necessário fazer uma modificação
nas configurações do mesmo através da adição de um arquivo chamado beans.
xml no diretório src/main/resources/META-INF/. O conteúdo do arquivo está
demonstrado na Figura 140.
159
FIGURA 140 – BEANS.XML
FONTE: CDI-SPEC (2015)
A funcionalidade da tabela não mudou, entretanto, o usuário agora pode

escolher quantos registros quer em tela. Um teste interessante é inserir mais
valores na lista que alimenta a tabela e observar seu comportamento.
E
IMPORTANT
Caso você queira se aprofundar na especificação CDI, sugerimos o material

disponível no link: <http://www.cdi-spec.org/>.
4 ESCOPOS E CONTEXTOS
Os objetos administrados pelo container CDI são administrados em
contextos, que são coleções de objetos relacionados logicamente que devem
perdurar durante um período de tempo (K19, 2015). Quatro tipos de contextos
são definidos pela especificação:
1) Request: utilizado em aplicações web, onde a cada requisição http um novo

contexto de request é criado pelo container e destruído no final do processamento.
2) Session: tem seu ciclo de vida associado a uma http session, onde o que acontece
quando a http session acontece com o context session;
3) Application: existe apenas um application context por aplicação, que é criado
quando a aplicação é inicializada e destruído quando a aplicação é finalizada.
4) Conversation: existe o transient, semelhante ao request e o long running,
semelhante ao session. A diferença é que nos conversations context a criação e
destruição dos contextos acontece através da chamada de métodos.
Para definir o escopo dos objetos, são utilizadas as anotações @

rRequestScope, @SessionScoped, @ApplicationScoped e @ConversationScoped.
A Figura 141 traz um exemplo de código fonte com a utilização das anotações.
160
TÓPICO 3 | CONTEXT AND DEPENDENCY INJECTION
FIGURA 141 – ANOTAÇÕES CDI
161
RESUMO DO TÓPICO 3
Neste tópico, vimos que:
• O context and dependency injection permite que se utilize injeção de dependência

para integrar a camada de interface com a camada de negócios.
• Através da injeção de dependência, o ciclo de vida de alguns objetos passa a ser

controlado por uma parte especial do AS conhecida como EJB Container.
• Os objetos utilizados no CDI podem ser atributos ou mesmo objetos criados

em métodos, conhecidos como producers.
• Para utilizar CDI, um arquivo beans.xml deve ser criado em um diretório

específico da aplicação.
• Existem basicamente quatro tipos de contextos onde os objetos administrados

pelo container CDI são armazenados: Request, Session, Application e Conversation.
162
AUTOATIVIDADE
1 Implemente uma aplicação web utilizando JSF que faça uso do contexto
CDI conhecido como SessionContext.
2 Descreva detalhadamente de que forma funciona a injeção de dependências

dentro de uma aplicação JavaEE.
163
164
UNIDADE 3
TÓPICO 4
JAVA MESSAGE SERVICE (JMS)
1 INTRODUÇÃO
Conforme K9 (2015), os ambientes corporativos são geralmente compostos
por diversos sistemas para auxiliar o funcionamento dos processos. Em algum
momento, tais sistemas deverão trocar informações entre si. Existem diversas
abordagens para esta integração e a especificação JavaEE traz uma solução robusta
através de um Middleware Orientado a Mensagens (MOM). Através do MOM é
possível enviar mensagens para outros sistemas de forma assíncrona, além de
permitir que essa transmissão aconteça de forma completamente desconectada,
onde os sistemas conhecem o Middleware, mas não conhecem uns aos outros.
Todo servidor de aplicação que implemente a especificação JavaEE deve

implementar um MOM de acordo com a arquitetura definida pela JMS, o que
acaba por envolver outras tecnologias da especificação, como EJB por exemplo.
2 FILAS E TÓPICOS
Os dois tipos de mensagens possíveis na arquitetura JMS são as filas ou os
tópicos, sendo que ambos devem estar previamente configurados no middleware.
Uma mensagem que for enviada para uma fila pode ser recebida por apenas
um sistema, no que é conhecido como point-to-point, enquanto uma mensagem
enviada para um tópico pode ser recebida por diversos sistemas no mecanismo
conhecido como publish-and-subscribe (K19, 2015).
Para configurar uma fila e um tópico JMS no AS (em nosso caso

consideramos o Wildfly) você deve alterar o arquivo de configuração standalone-full.
xml disponível dentro da pasta de instalação do AS\standalone\configuration\
(Figura 142). Dentro deste arquivo procure pela tag <jms-destination> e lá faça as
alterações conforme a Figura 142.
165
FIGURA 142 – ARQUIVO DE CONFIGURAÇÃO
FONTE: O autor
FIGURA 143 – ARQUIVO DE CONFIGURAÇÃO
Agora inicie o WildFly e procure pelas mensagens da Figura 143 no

console. Estas mensagens indicam que a configuração foi feita com sucesso.
166
TÓPICO 4 | JAVA MESSAGE SERVICE (JMS)
FIGURA 144 – MENSAGENS DO CONSOLE
FONTE: K19 (2015)
Todo sistema que desejar trocar mensagens através de filas ou tópicos deve
obter uma conexão JMS através das fábricas cadastradas no MOM. De acordo com a
especificação, os provedores JMS em ambientes JavaEE devem ofertar uma fábrica
de conexões-padrão, que pode ser obtida através do serviço JNDI executando um
JNDI para o nome java:comp:DefaultJMSConnectionFactory (K19, 2015).
As fábricas de conexão, as filas e os tópicos são objetos administrados pelos

provedores JMS e obtidos através de pesquisas ao serviço de nomes conforme
definido pela especificação JNDI (Figura 145).
FIGURA 145 – SERVIÇO DE NOMES
FONTE: K19 (2015)
As aplicações JavaEE podem obter tópicos, fábricas de conexão e filas através

de injeção de dependência, conforme pode ser visto na Figura 146. A anotação @
Resource marca o Topic, o ConnectionFactory e a Queue como recursos gerenciados
pelo AS, sendo que cada um faz um lookup para o endereço definido no atributo.
FIGURA 146 – INJEÇÃO DE DEPENDÊNCIA
FONTE: O autor
167
Os contextos são responsáveis pela criação dos produtores, consumidores

e das mensagens propriamente ditas. Estes contextos, demonstrados na Figura
147, podem ser obtidos através de fábrica de conexões (linha 36) ou através de
injeção de dependência (linhas 38 e 39).
FIGURA 147 – CONTEXTOS
Os produtores e consumidores podem ser criados já com um destino

específico, seja uma fila ou um tópico, conforme demonstrado na Figura 148.
FIGURA 148 – PRODUTOR E CONSUMIDOR
FONTE: O autor.
As mensagens são produzidas através do tipo String e enviadas pelo

método send de um objeto do tipo JmsProducer (Figura 149). Entre as linhas 51 e
53 podemos observar o envio de uma mensagem.
FIGURA 149 – ENVIO DE MENSAGEM
FONTE: O autor.
O consumo de mensagens pode ser feito através do método receiveBody()

de um objeto JMSConsumer, conforme a Figura 150.
FIGURA 150 – CONSUMO DE MENSAGEM
FONTE: O autor
168
E
IMPORTANT
Na linha 54 é utilizado o parâmetro String.class, que utiliza a api de

Reflection do Java. Para conhecer mais sobre esta importante api, acesse o site:
<http://www.caelum.com.br/apostila-java-testes-xml-design-patterns/reflection-e-
annotations/>.
Para demonstrar o funcionamento destas tecnologias de modo integrado,

criaremos um exemplo de uma classe que envia mensagens para a fila que
registramos no WildFly. O código-fonte está demonstrado na Figura 151. É
possível observar que fizemos o lookup para o nome que configuramos no arquivo
de configuração do AS através do JNDI (linha 30).
FIGURA 151 – CLASSE PARA ENVIO DE MENSAGENS
3 MODOS DE RECEBIMENTO
Um objeto do tipo JMSConsumer pode receber mensagens JMS de três
maneiras distintas: Não bloqueante, semibloqueante e bloqueante. Estas maneiras
de recebimento dizem respeito à forma como o sistema se comporta em relação ao
fato de as mensagens serem assíncronas. Um detalhamento de cada maneira está
mostrado abaixo e o exemplo de código fonte pode ser observado na Figura 151:
169
1. Não bloqueante: a execução do sistema não é interrompida, caso a mensagem

não seja recebida imediatamente.
2. Semibloqueante: a execução do sistema é bloqueada até que a mensagem seja
recebida ou até o término de um período estipulado no método de recebimento
da mensagem.
3. Bloqueante: a execução do sistema não continua até que a mensagem seja
efetivamente recebida.
FIGURA 151 – MANEIRAS DE RECEBER MENSAGENS
FONTE: Adaptado de K19 (2015).
É possível percorrer as mensagens de uma fila sem removê-las da mesma,

através de um objeto do tipo QueueBrowser, criado exclusivamente para esta
finalidade. Uma demonstração da utilização do objeto QueueBrowser pode ser
vista na Figura 152.
FIGURA 152 – PERCORRENDO UMA FILA DE MENSAGENS
FONTE: O autor
170
De modo a facilitar a busca de mensagens em uma fila, é possível anexar

propriedades a estas mensagens. Estas propriedades podem ser utilizadas por
todos os assinantes de determinado tópico para filtrar somente o conteúdo que
realmente os interessa (Figura 153).
FIGURA 153 – ADICIONANDO PROPRIEDADES A MENSAGENS
FONTE: O autor.
Para simplificar seu aprendizado, em nossos exemplos estamos utilizando

mensagens simples de texto. Em aplicações reais você pode criar mensagens de
diversos tipos distintos. Os tipos de formato de mensagem disponibilizados pelo
JMS são os seguintes:
TABELA 2 – TIPOS DE FORMATO DE MENSAGEM

Interface Tipo do corpo da mensagem
Um bloco de texto, representado em java como uma
javax.jms.TextMessage String. Pode ser utilizado para representar uma
mensagem como um arquivo XML ou JSON.
javax.jms. Um objeto java serializável, como por exemplo um
ObjectMessage Java Bean.
javax.jms.MapMessage Um objeto contendo diversos pares de chave/valor.
Um bloco de dados binários representado em java
javax.jms. como um array de bytes. Utilizado para interagir com
BytesMessage sistemas de mensagens externos que possuem seus
próprios protocolos binários de comunicação.
Uma lista de valores primitivos do Java que pode
javax.jms.
ser utilizado para representar certos tipos de dados
StreamMessage
usados por sistemas de mensagem externos.
FONTE: Adaptado de: <https://docs.oracle.com/cd/E23095_01/Platform.93/
ATGProgGuide/html/s1102jmsmessageformats01.html>. Acesso em: 12 fev. 2016.
171
E
IMPORTANT
JSON ou JavaScript Object Notation é um formato de transmissão de

informações através de texto, muito utilizado para aplicações que trabalham com REST.
Supostamente apresenta um desempenho maior do que os webservices criados através de
SOAP e XML.
O envio de mensagens JMS através de tópicos apresenta-se como uma

alternativa interessante para sistemas que necessitem de funcionalidades
assíncronas. Mas o que acontece se um ou mais assinantes não estiverem logados
no sistema no momento do envio? Estas mensagens serão perdidas e não podem
ser recuperadas. A especificação JMS apresenta um tipo especial de tópico que
funciona armazenando as mensagens dos assinantes ATÉ QUE eles as recebam.
Este tipo de tópico é conhecido como tópico durável. Por exemplo, se determinado
assinante estiver desconectado no momento do envio de uma mensagem que este
se escreveu para receber, o provedor JMS percebe que o tópico é do tipo durável
e armazena a mensagem para envio quando o assinante se conectar novamente.
Para criar um tópico durável, é necessário liberar uma permissão no AS. No

caso do WildFly, ela ocorre alterando o elemento <security-settings>, disponível
no arquivo standalone-full.xml. A alteração necessária para que se possa criar
tópicos duráveis via código é demonstrada na Figura 154.
FIGURA 154 – CONFIGURAÇÃO PARA TÓPICOS DURÁVEIS
Pronto! Graças ao JavaEE e sua vasta gama de tecnologias, você está pronto
para desenvolver aplicações web mais robustas e com mais qualidade. Como
dissemos no início do tópico, JavaEE é uma especificação extensa e existe muito
mais para aprender sobre o tema. Nossa intenção é fornecer uma introdução
sólida, para que você possa continuar evoluindo por conta própria.
Sugerimos fortemente que você não limite seus estudos a tecnologias

da família Java. Estude frameworks novos como AngularJS, Node.js etc., afinal, a
tecnologia evolui dia a dia e não podemos ficar para trás.
Bons estudos e até uma próxima oportunidade!
172
DA NECESSIDADE DE PRINCÍPIOS DE ARQUITETURA DA

INFORMAÇÃO PARA A INTERNET DAS COISAS
Analisa-se neste artigo o cenário da Internet das Coisas (IdC) e seus impactos
para a sociedade. Identifica-se a necessidade de uma abordagem humanista e
sistêmica na área de Arquitetura da Informação, baseada essencialmente em
princípios, que componha um arcabouço teórico transdisciplinar para lidar com
questões tecnológicas, informacionais e sociais emergentes do fenômeno da IdC.
1 INTRODUÇÃO
O contexto da sociedade atual aponta para uma realidade de convergência,

em que os limites entre concreto e digital se tornam cada vez mais tênues. Na
trilogia “A Era da Informação: economia, sociedade e cultura”, Castells (1999) faz
um amplo diagnóstico da revolução promovida pelas tecnologias da informação
e da comunicação, analisando de que forma o advento da Internet redefiniu e
continua estabelecendo novas formas de organização da sociedade.
Castells (2003) entende a Internet como “a base tecnológica para a forma

organizacional da Era da Informação: a rede”. Este fato fica mais evidente na atual
geração - caracterizada pela chamada Internet das Coisas (IdC): são sistemas, no
sentido amplo, interligados entre si em diferentes escalas, formando ecossistemas
com componentes biológicos, materiais, urbanos – tendo em comum a informação
como substrato, que passa a fluir e estar presente literalmente em toda parte. Por
isso, a IdC é conhecida também como Internet Ubíqua.
Na IdC, informações passam a se mover em sentido inverso do que ocorria

na formação do chamado ciberespaço. O mundo físico é alimentado pelo digital,
a realidade é aumentada por aplicações centradas no usuário que promovem
consumo e produção de informações. É como se o ciberespaço, que antes era um
universo paralelo, transbordasse (KUNIAVSKY, 2010; RESMINI; ROSATI, 2011).
O extraordinário potencial da IdC é o poder que confere aos objetos

de uso cotidiano de capturar, processar, armazenar, transmitir e apresentar
informações. Interligados em rede, os objetos são capazes de realizar ações de
forma independente e gerar dados em quantidade e variedade exponenciais,
como produto das interações. Nesse contexto, a informação passa a fazer parte
do ambiente, e configuram-se novas formas de atuação das pessoas no mundo.
Considere-se ainda a abrangência, a perversidade e o crescimento

expressivo das aplicações da IdC. A Internet conta atualmente com quase 3 bilhões
de usuários conectados, conforme o “Global Internet Report” (KENDE, 2014). A
previsão do Gartner (2014) é de que o número de dispositivos conectados seja
173
de 26 bilhões em 2020. Em uma análise mais otimista, a Cisco prevê 50 bilhões

de objetos no mesmo período, movimentando um mercado de US$ 14,4 trilhões
até 2022 (EVANS, 2011). Lucas, Ballay e McManus (2012) anunciam para breve a
marca dos trilhões de nós conectados à Rede, número que utilizaram como título
do livro dedicado ao tema. Os autores acreditam que a revolução promovida pela
IdC representa o futuro da Era da Informação.
A IdC é compreendida, neste cenário, como um fenômeno complexo,

observável a partir de múltiplos pontos de vista – social, cultural, econômico,
organizacional, tecnológico, informacional – que tem como consequência direta a
materialização de ambientes permeados por informação. O objetivo deste artigo
é argumentar sobre a necessidade de uma Arquitetura da Informação baseada em
princípios para lidar com as questões emergentes deste fenômeno.
2 INTERNET DAS COISAS (IdC)
O termo Internet of Things (Internet das Coisas) foi cunhado em 1999

por Kevin Ashton, cofundador do Auto-ID Center do Massachusetts Institute of
Technology (MIT). Em recente artigo, Ashton (2009) afirmou que a ideia original
da IdC previa a conexão de todos os objetos físicos à Internet, com capacidade
de capturar informações por meio de identificação por radiofrequência (RFID)
e tecnologias de sensoriamento – as quais os permitiriam observar, identificar
e compreender o mundo independentemente das pessoas e suas limitações de
tempo, atenção e precisão. Em 2005 a União Internacional de Telecomunicações
(UIT) previu que a possibilidade de identificação única de itens, associada a
tecnologias de sensores e a capacidade de interagir com o ambiente criaria uma
Internet das Coisas (ITU-T, 2012).
Em abordagem didática, Davis (2008) define quatro estágios de evolução da

Internet – Web 1.0, voltada para a conexão e obtenção de informações na Rede; Web
2.0 ou Web Social, caracterizada pela preocupação com a experiência do usuário e
a colaboração por meio das redes sociais; Web 3.0 ou Web Semântica, com esforços
concentrados na atribuição de significado e contexto às informações; e o estágio
atual, a Web Ubíqua, constituída pela Internet das Coisas (IdC), fundamentada pela
conectividade e interatividade entre pessoas, informações, processos e objetos, por
meio de tecnologias que possibilitam acesso à rede por qualquer pessoa, de qualquer
lugar, a qualquer tempo, utilizando quaisquer dispositivos, incluindo equipamentos
multifuncionais com sensores inteligentes, tais como eletrodomésticos, automóveis,
roupas etc., a partir de aplicações que se adaptam dinamicamente às necessidades
dos usuários (DAVIS, 2008; W3C, 2010). Estamos, portanto, na era da computação
embutida e distribuída pelo ambiente (KUNIAVSKY, 2010).
3 DESAFIOS E QUESTÕES EMERGENTES DA IDC
O mundo físico está se tornando um grande ecossistema de informação.

Os objetos tanto podem sentir o ambiente como se comunicar independentemente
de intervenções humanas. Tornam-se, portanto, participantes ativos nos
174
processos de negócio, e passam a ser reconhecidos e identificados em ambientes

inteligentes, que recuperam dinamicamente informações na Internet, promovendo
sua funcionalidade adaptativa e responsiva (CHUI; LÖFFLER; ROBERTS,
2010; WEBER, 2013).
A IdC afeta a humanidade em diferentes escalas. Envolve

desde nanochips implantados em seres vivos a objetos de uso comum
interconectados, equipados com sensores e identificados por RFID – capazes
de trocar informações entre si, com as pessoas ou com o ambiente – até cidades
inteiras sendo projetadas de maneira totalmente conectada e automatizada
(as chamadas smart cities ou cidades inteligentes). As formas de manifestação
da IdC são heterogêneas, incluindo dispositivos de múltiplos propósitos
(celulares, tablets, relógios e óculos inteligentes) e dispositivos especializados
(sensores de temperatura, dispositivos ativos e passivos etc.), suportados por uma
variedade de plataformas de software e hardware. O desafio de projetar espaços na
IdC é contemplar os diferentes níveis de granularidade de forma transparente,
garantindo a interoperabilidade.
As inovações que surgem no âmbito da IdC ampliam o potencial humano

em diversas áreas - tais como planejamento urbano (cidades, edifícios e trânsito
inteligentes), meio ambiente (energia, água), indústria, comércio, turismo, educação,
saúde, trabalho, segurança, programas sociais, governo – com soluções capazes de
promover desenvolvimento econômico, sustentabilidade e qualidade de vida.
O problema é que a velocidade com a qual a tecnologia se difunde na

vida das pessoas é maior do que a possibilidade de previsão de seus impactos,
sejam positivos ou negativos. E, dada a infinidade de aplicações e a abrangência
da IdC, os efeitos negativos são temerários, considerando que o processo de
mudança tem sido conduzido em grande medida por empresas privadas,
com interesses nem sempre coincidentes com os da sociedade. Lucas, Ballay e
McManus (2012), Greenfield e Kim (2013), Greenfield (2006), Norman (2009), e
outros autores alertam para os riscos de definições impulsionadas essencialmente
por forças de mercado moldarem o futuro.
O urbanista e crítico Adam Greenfield (2006) denomina o fenômeno da

IdC de everyware, em alusão aos objetos conectados em toda parte. Ele acredita
que a IdC deve ser cuidadosamente arquitetada no momento presente, pois
trará cada vez mais implicações para a humanidade. Ressalta que everyware é
inevitável, e toda a infraestrutura necessária para sua implantação já existe. Mas
a forma que tomará ainda é passível de mudanças e a articulação de padrões
essenciais para um desenvolvimento ético e responsável é urgente. A dificuldade
está em compreender o significado das escolhas de futuros possíveis em um
curto intervalo de tempo, e fazer opções conscientes, considerando os impactos
de uma “vida colonizada pela tecnologia da informação”. Dependendo de como
for definida, everyware pode ser uma questão imediata ou um “problema para
cem anos [nas palavras de Gene Becker, da HP]: um desafio técnico, social, ético
e político de extraordinária sutileza e dificuldade [...]. Mapear as necessidades e
vontades de pessoas reais em qualquer situação está longe de ser tarefa óbvia”.
(GREENFIELD, 2006, p. 179).
175
A questão do poder de atuação (ou agência) conferida aos objetos na

IdC é um dos pontos mais críticos para discussão. Objetos tornam-se ativos,
capazes de promover ações independentemente dos seres humanos. Santucci
(2014) preocupa-se com a autonomia das pessoas em um mundo onde os objetos
conectados inteligentes superam os humanos em uma proporção de pelo menos 1
a 10. Como observa Floridi (2013, min. 1:14), as pessoas podem simplesmente não
querer interagir com entidades-robôs. “Quem vai se adaptar a quem?”, afirma.
Objetos ganham vida, passam a ser agentes, a perceber estímulos do

ambiente, produzir informações e interagir com as pessoas e outros objetos.
Mas a responsividade e a interatividade foram concebidas a partir de premissas,
baseadas no modelo mental e nas motivações de quem as idealizou. É preciso
investigar até que ponto as respostas inteligentes e decisões independentes dos
objetos estão de acordo com as necessidades e vontades dos seres humanos que
os utilizam. Um dos perigos apontados por Donald Norman (2009) é o de pessoas
criativas e produtivas tornarem-se servos dos objetos, preocupando-se mais com
seu funcionamento do que usufruindo de seus benefícios.
“Como mudar a forma de interação com nossas máquinas para obter

melhores vantagens de suas virtudes e forças, ao mesmo tempo eliminando as
ações inoportunas e perigosas?”, indaga Norman (2009, p. 8). A melhor maneira
de promover a interação suave entre pessoas e dispositivos inteligentes é
aumentando a coordenação e a cooperação entre ambos, sugere o autor. Afirma
ainda que os produtos estão ficando mais espertos, inteligentes, exigentes e
presunçosos. Passam a fazer parte de um ecossistema social, portanto, precisam
de traquejo, habilidades comunicativas, e até mesmo emoções. O autor ressalta a
dificuldade de ignorar um sistema que não conseguiu antecipar a necessidade de
um usuário: “ele pode simplesmente ignorá-lo, se for possível ignorar uma casa
que constantemente pisca sugestões sobre contadores, paredes e pisos”. McEwen
e Cassimally (2013, p. 24) observam que este problema ganha dimensões mais
amplas ao incluírem-se as centenas de novos serviços e aplicações espalhadas
pelos objetos ao redor do mundo: “haverá uma cacofonia em busca de atenção”.
“Como pode uma máquina discernir o que é importante, se os contextos

de importância variam?”, continua Norman (2009, p. 11). Para o autor, a falta de
senso comum é a maior causa da inabilidade de comunicação entre pessoas e
máquinas. O senso comum das máquinas é a medida do senso comum daqueles
que as programaram, em um momento desprovido de contexto. O contexto é
apenas inferido. Quando isso ocorre com uma pessoa, é esperado que utilize
criatividade para a solução de problemas”. Nesse sentido, o autor indaga: “seriam
estes sistemas realmente inteligentes” e afirma: “não, são apenas responsivos”.
(NORMAN, 2009, p. 29). A inteligência está na mente daqueles que os projetaram,
e que cuidadosamente tentam antecipar todas as condições e reações possíveis em
cada situação, para programar respostas adequadas. Nessa linha, Floridi (2013,
min. 00:43) concorda que os dispositivos sejam espertos (smart) – capazes de fazer
coisas interessantes; mas não inteligentes.
176
Em geral, defende Norman (2009), as soluções são valiosas e úteis, mas

ocorrem falhas, pois raramente é possível inferir o conjunto de informações
contextuais e circunstanciais com a mesma acurácia e riqueza dos sensores
próprios dos seres humanos, que além de tudo criam representações complexas do
mundo e de suas ações, bem como expectativas precisas com base em uma longa
história de interação. Ele acredita que o risco não significa que o melhor caminho
seja “rejeitar a ajuda das máquinas inteligentes, pois podem ser verdadeiramente
proveitosas; mas é preciso socializá-las, para que aprimorem a forma com a qual
se comunicam e interagem com as pessoas”.
A questão da agência dos objetos traz ainda dificuldades na determinação

da responsabilidade sobre os atos, notadamente em situações imprevistas que
gerem dano, prejuízo ou consequências indesejáveis. É preciso haver uma espécie
de contrato social entre pessoas e objetos, com as respectivas ramificações éticas.
Em um exemplo concreto: deve haver maior preocupação com as bases éticas
e consequências de delegar decisões para sistemas automotivos do que com
as questões tecnológicas dos carros inteligentes (EUROPEAN COMMISSION,
2012). No caso de um acidente provocado pela ação de um automóvel smart, por
exemplo, quem seria responsabilizado?
Em uma perspectiva mais ampla, Greenfield e Kim (2013, p. 519) questionam:

“estariam os arquitetos das cidades inteligentes suscetíveis a responsabilização
(accountability) democrática, considerando o nível de interferência que podem
exercer na vida das pessoas no contexto atual?”. Decisões de arquitetos são atos
políticos em âmbito urbano – do mesmo modo como a autoria de um algoritmo
destinado a promover a distribuição de recursos cívicos em uma cidade.
Outro ponto é o problema do consentimento informado. Greenfield

(2006, p. 66) alerta: “as pessoas podem entrar em everyware de forma inadvertida,
inconsciente ou indesejada. A natureza passiva da exposição dos indivíduos a essa
infraestrutura de rede pervasiva e os métodos de coleta de dados têm implicações
sobre sua vida, saibam ou não, queiram ou não”. Nesses ambientes, a informação
está sempre sendo coletada e utilizada como base para ação, arquivada e recuperada
de maneira sutil. Os equipamentos operam em conjunto para produzir significado
- mas “de que forma a parafernália tecnológica universal se adapta a práticas,
atividades, leis e hábitos locais?”, questiona. (GREENFIELD, 2006, p. 29).
Greenfield (2006) indaga se as aplicações ubíquas cumprirão a promessa

de uma “tecnologia calma” - conforme imaginado por Weiser e Brown (1996) –
onde a sobrecarga cognitiva envolvida nas interações entre pessoas e objetos é
reduzida, resultando em interfaces compreensíveis, úteis e usáveis. Ele acredita
que as atuais práticas de desenvolvimento em tecnologia da informação (TI)
aplicadas a everyware resultarão em experiências de uso inaceitavelmente ruins
caso não sejam repensadas; e lembra que o design adequado para everyware é
infinitamente mais complexo do que o design de websites ou aplicações desktop.
177
Em relatório do Gartner (2013), a IdC foi apontada como uma das
dez tendências estratégicas mundiais de tecnologia de prestação de serviços
eletrônicos. O tema tem sido tratado como prioritário pelo setor público de
diversos países, especialmente os europeus e asiáticos, com programas de
governo dedicados a identificar impactos e potenciais oportunidades trazidas
pelas inovações. Nessa conjuntura, a preocupação com a governança da Internet,
traduzida na capacidade de definir modelos de funcionamento da rede, torna-
se fundamental para garantir seu desenvolvimento sustentável e o atendimento
pleno aos interesses da sociedade.
Tecnologias e mercados não podem existir independentemente de

princípios abrangentes de um sistema ético e social. A IdC terá um amplo impacto
em muitos dos processos que caracterizam a vida cotidiana, portanto, é primordial
que seu desenvolvimento seja fundamentado em estratégias orientadas a pessoas.
Para isso, aqueles que as projetam devem estar próximos aos que irão utilizá-las
(MENDES, 2011).
Numa das palestras de abertura do evento Internet of Things: Philosophy, que

teve como mote examinar o que significa ser humano na Internet das Coisas, Gérald
Santucci (2014) indagou: como a Internet das Coisas irá transformar-nos – e em
quê? Segundo ele, se tivéssemos de escolher uma palavra para descrever o que
é a IdC, certamente seria inteligente: objetos, cidades, redes, saúde e transporte
inteligentes etc., mas o que inteligente implica em termos de desafios sociais?
Quais as formas de governança necessárias em um ambiente inteligente? Como
a IdC afeta e transforma a relação entre seres humanos e objetos? Que ética deve
orientar a concepção e implementação de objetos inteligentes conectados? Não
seriam objetos forçando os seres humanos a se comportarem de acordo com
padrões que podem privá-los de sua autonomia ou liberdade?
O grupo de especialistas da Comissão Europeia (IoT Expert Group) identificou

seis questões éticas fundamentais no âmbito da IdC: justiça social (combate à exclusão
digital e de conhecimentos); confiabilidade (garantia de privacidade e segurança,
proteção de dados); clareza sobre contextos (responsabilidades dos atores no
ecossistema, privado versus público), clareza sobre metáforas (conveniência versus
perigos das coisas inteligentes), clareza sobre agência de objetos (contrato entre
pessoas e objetos) e autonomia dos indivíduos (consentimento informado sobre
funcionalidades e ações dos objetos) (EUROPEAN COMMISSION, 2012). Estamos
caminhando para “um mundo rico em informações, com novas possibilidades e
problemas. Indivíduos e instituições obterão maior flexibilidade e produtividade.
No entanto, teremos que lutar para equilibrar privacidade, liberdade, conveniência
e segurança”. (MORVILLE, 2005, p. 3).
4 PRINCÍPIOS DE ARQUITETURA DA INFORMAÇÃO PARA A IDC
Informações estão sendo incorporadas em objetos de uso comum em toda

parte. Isto muda fundamentalmente a maneira de compreender a Arquitetura da
Informação, a forma de lidar com suas questões científicas e, definitivamente, a
forma de praticá-la. (LACERDA; LIMA-MARQUES, 2014, p. 7).
178
Resmini e Rosati (2011, p. 681) preveem a “necessária adoção de uma

visão abrangente para o design de espaços de informação” nessa realidade de
convergência física e digital. No prefácio da obra de Resmini e Rosati (2011, p.
97), Peter Morville questiona: “como responder aos novos desafios de criação de
caminhos e lugares que conectem espaços físicos, digitais e cognitivos?”
Em Digital Ground, McCullough (2004) parte de princípios arquitetônicos

para abordar a modelagem de espaços onde ocorrem ações mediadas digitalmente.
Observa que a computação pervasiva cria tais espaços, que subitamente
reconfiguram-se de acordo com seus ocupantes, cujo uso pode causar paranoia
ou satisfação, dependendo de quão inteligentemente são projetados. E coloca em
pauta questões do tipo: “é preferível ser sujeito passivo de monitoramento ou
precisar fornecer ativamente identificação?”. “Arquiteturas instanciam intenções,
etiquetas e ações particulares”, conclui (MCCULLOUGH, 2004, p. 47).
A conferência “Internet of Things: Philosophy”, ocorrida em 2014, propôs

um debate sobre as ramificações da IdC em um contexto filosófico. Dentre as
questões levantadas no evento estão: influência da tecnologia sobre as emoções;
autopercepção do ser humano e do modo como se relaciona com as coisas;
aumento do potencial humano de ação e criação pela tecnologia; mudanças
na forma de comunicação, e significado da comunicação homem-máquina e
máquina-máquina.
A comunidade de Arquitetura da Informação está se movendo para a

expansão das visões de mundo, de seu escopo de ação e de suas motivações,
como demonstram os discursos de Morville (2012), Arango (2012), Resmini
(2013), Hinton (2013), e Klyn (2013), entre outros. As discussões estão sendo
realizadas em publicações, redes sociais e eventos, como as edições do IA
Summit 2013, em Baltimore (EUA) e 2014 em San Diego, onde ocorreram mesas
redondas sobre o tema Reframing Information Architecture (Reenquadrando a
Arquitetura da Informação) (LACERDA; LIMA-MARQUES, 2014).
Chamar para uma renovação epistemológica significa pedir aos estudiosos

da disciplina para elevarem-se ao meta-nível do sistema de investigação, a fim
de questionar algumas das abordagens atuais. A produção de trabalho inovador
duradouro sinaliza o advento de um novo paradigma, ou, pelo menos, a
modificação do existente (VAN GIGCH, 1990, p. 127).
No livro “Pervasive Information Architecture”, Resmini e Rosati

(2011) propõem o conceito de Arquitetura da Informação Pervasiva como uma
abordagem voltada às questões relativas ao design de ecossistemas de informação
em ecologias ubíquas. Pela definição dos autores:
Nós denominamos esses novos espaços estendidos de informação – nos

quais interagimos tanto com entidades digitais quanto físicas – ecologias ubíquas:
são sistemas que conectam pessoas, informações, processos, que estão em toda
parte. São arquiteturas da informação pervasivas. São a camada estruturante que
atravessa as diferentes mídias, canais e processos: na qual expressamos nosso eu
expandido, socialmente. (RESMINI; ROSATI, 2011, p. 140).
179
Lucas, Ballay e McManus (2012, p. 171) buscam em sua obra identificar

padrões de design e processos que possam ser utilizados na intersecção entre
sistemas de informação e pessoas. O que eles chamam de “rede de trilhões de nós”
irá requerer “a emergência de um estilo de Arquitetura da Informação”. “Em uma
camada acima da arquitetura de sistemas (que trata de como os computadores
em si são construídos), e abaixo da camada de interface de usuários (que é sobre
como os sistemas se comunicam com usuários), a Arquitetura da Informação
trata do design da informação em si. A rede de trilhões implica em um vasto
e heterogêneo fluxo de informações. O único ponto em comum desse fluxo é a
informação, e é onde devemos concentrar esforços de design se quisermos buscar
integridade global”.
Hiroshi Ishii (2012), cientista e professor do Massachusetts Institute of

Technology (MIT), acredita que a inovação tecnológica deve ser direcionada por
uma visão (conceitos, princípios) que fundamente o desenvolvimento de aplicações
para atender a necessidades de usuários, materializando-se em tecnologias
(Figura 1). Proporcionalmente, e considerando a atual conjuntura, as tecnologias
teriam a vida útil estimada em um ano, as aplicações atenderiam necessidades
de usuários por aproximadamente dez anos, e os princípios perdurariam por
mais de cem anos (Figura 2). Segundo Ishii (2012, p. 50), “princípios raramente
mudam, mas práticas sempre dependem de contexto. Ao associar um método
a uma coleção de princípios, é sempre possível criar novas práticas, desde que
aderentes aos princípios”.
FIGURA 1 – FATORES DE INOVAÇÃO TECNOLÓGICA
Visão
(Conceitos, Princípios)
Necessidades
(Aplicações)
Tecnologias
180
FIGURA 2 – VIDA ÚTIL DOS FATORES DE INOVAÇÃO
Visão
(Conceitos, Princípios)
- 100 anos
Necessidades
(Aplicações)
- 10 anos
Tecnologias - 1 ano
Greenfield (2006, p. 257) defende que um conjunto explícito de princípios

será extremamente útil tanto para desenvolvedores quanto para usuários
em everyware. E alerta que "os princípios são necessários, mas não suficientes:
constituem não um fim, mas um começo". Há que se construir um everyware que se
adapte às pessoas, não o contrário. Mas não será trivial projetar sistemas ubíquos
sofisticados o suficiente para capturar a riqueza de nuances da vida cotidiana
(GREENFIELD, 2006).
Diretrizes serão claramente úteis para quem está adquirindo ou

utilizando everyware, ainda que limitadas por serem contingentes, provisionais e
incompletas. Se houver um conjunto de critérios compacto, objetivo, e amplamente
acordado, haverá compatibilidade e interoperabilidade. Os princípios focam
não em como alcançar uma quantidade de finalidades, mas em que finalidades
devem ser perseguidas prioritariamente. É preciso desenvolver um arcabouço de
conhecimentos, padrões e convenções, começando pelas interfaces pelas quais
acessaremos everyware (GREENFIELD, 2006).
Desde que a Arquitetura da Informação é baseada em princípios que são

amplamente independentes de qualquer mídia específica – afinal diz respeito à
estruturação de espaços de informação tanto quanto a Arquitetura preocupa-se
com a estruturação de espaços físicos – [a área] fornece um modelo conceitual
flexível, porém sólido, para o design de experiências em múltiplos canais [cross-
channel] e múltplos contextos [cross-context], que se estendem a diversas mídias
e ambientes. (RESMINI; ROSATI, 2011, p. 1369).
181
Shin (2010) destaca que ainda são poucos os esforços de pesquisa

concentrados nas imensas repercussões sociais, culturais e comportamentais da
IdC, que tenham a finalidade de promover sua implantação, gestão e evolução
na qualidade de inovação sociotécnica (BIJKER, 1997), que deve ser projetada e
desenvolvida como um sistema centrado nos humanos. Lucas, Ballay e McManus
(2012) projetos de sistemas de informação para a IdC devem considerar: métodos
profundamente interdisciplinares; foco humanista; design de interação centrado
em informações; e computação em contexto.
5 CONCLUSÃO
O cenário da IdC é multifacetado e vem sendo tratado na literatura sob

perspectivas socioculturais, econômicas, filosóficas, mas predominantemente
tecnológicas. As questões emergentes deste contexto são de natureza e proporções
variadas – como privacidade, usabilidade, consentimento, para citar alguns – e
afetam desde o domínio individual até o global, passando pelas esferas doméstica,
social, urbanística, governamental.
A pesquisa voltada para aspectos tecnológicos é fundamental para o avanço

da IdC. Entretanto, é necessário compreender os tipos de tarefas e padrões de
interatividade que emergem no momento em que o usuário transcende o modelo
de interação com computadores para interagir com interfaces que permeiam seu
ambiente e aumentam suas capacidades individuais, mas que, ao mesmo tempo,
conferem autonomia e poder de decisão aos objetos.
Há uma série de desafios tecnológicos e informacionais que devem ser

tratados para viabilizar o funcionamento adequado da IdC. Mas está nos aspectos
humanos e sociais a oportunidade de fazer a diferença em termos de projetos de
ecossistemas de informação direcionados às necessidades das pessoas.
A questão central de interesse da Internet das Coisas para a Arquitetura

da Informação, na qualidade de disciplina da Ciência da Informação, é a
concretização de um mundo onde o processamento de informações estará em
toda parte. São novos espaços de informação, com diferentes propriedades, que
precisam ser compreendidas e arquitetadas. A Internet das Coisas requer de
uma abordagem humanista e sistêmica, baseada essencialmente em princípios,
com vistas a evitar soluções pautadas em valores comerciais ou tecnicistas.
Indica-se, nesse sentido, a necessidade de estruturação de um arcabouço teórico
transdisciplinar no âmbito da área de Arquitetura da Informação para lidar com
as questões emergentes da IdC.
FONTE: Disponível em: <http://www.scielo.br/scielo.php?script=sci_arttext&pid=S1413-
99362015000200158&lang=pt>. Acesso em: 12 fev. 2016.
182
RESUMO DO TÓPICO 4
Neste tópico, vimos que:
• O context and dependency injection permite que se utilize injeção de dependência

para integrar a camada de interface com a camada de negócios.
• Através da injeção de dependência, o ciclo de vida de alguns objetos passa a ser

controlado por uma parte especial do AS conhecida como EJB Container.
• Os objetos utilizados no CDI podem ser atributos ou mesmo objetos criados

em métodos, conhecidos como producers.
• Para utilizar CDI, um arquivo beans.xml deve ser criado em um diretório

específico da aplicação.
• Existem basicamente quatro tipos de contextos onde os objetos administrados

pelo container CDI são armazenados: Request, Session, Application e Conversation.
183
AUTOATIVIDADE
1 Implemente uma aplicação web utilizando JSF que faça uso do contexto
CDI conhecido como SessionContext.
2 Descreva detalhadamente de que forma funciona a injeção de dependências

dentro de uma aplicação JavaEE.
184
REFERÊNCIAS
ARANGO, J. World information architecture day 2012. [S.l: s.n.], 2012. Disponível
em: <http://www.youtube.com/watch?v=kY5CC2QfevE&feature=youtube_gdata_
player>. Acesso em: 15 set. 2013.
ASHTON, K. That “Internet of Things” Thing. RFID Journal, 22 jun. 2009.

Disponível em: <http://www.rfidjournal.com/articles/view?4986>. Acesso em:
31 ago. 2013.
BIJKER, W. E. Of bicycles, bakelites, and bulbs toward a theory of

sociotechnical change. Cambridge Mass.: MIT Press, 1997.
CARDIM, Eder. Bancos de dados relacionais, orientação a objetos e DBIX-

Class. 2010. Disponível em: <http://sao-paulo.pm.org/pub/bancos-de-dados-
relacionais-orientacao-a-objetos-e-dbix-class>. Acesso em: 2 maio 2015.
CASTELLS, M. A galáxia internet: reflexões sobre a internet, negócios e a

sociedade. Rio de Janeiro: Zahar, 2003.
CASTELLS, M. A sociedade em rede. São Paulo: Paz e Terra, 1999 v. 1. (A Era

da Informação: economia, sociedade e cultura).
CDI-SPEC. Contexts and Dependency Injection for Java. 2015. Disponível em:
<http://www.cdi-spec.org/>. Acesso em: 8 jan. 2015.
CHUI, M.; LÖFFLER, M.; ROBERTS, R. The internet of things. McKinsey

Quarterly, v. 2, 2010 Disponível em: <http://scholar.google.com.br/scholar?cluste
r=4109556744406282630&hl=pt-BR&as_sdt=0,5>. Acesso em: 3 jan. 2013.
DAVIS, M. Semantic wave 2008 report: industry roadmap to Web 3.0 &
Multibillion Dollar Market Opportunities. Executive Summary, 2008. Disponível
em: <http://www.project10x.com>. Acesso em: 20 jul. 2010.
185
EUROPEAN COMMISSION. Conclusions of the Internet of Things public
consultation, n. 9. Brussels: [s.n.], 12 abr. 2012. Disponível em: <ec.europa.
eu//digital-agenda/en/news/conclusions-internet-things-public-consultation>.
Acesso em: 1 jan. 2015.
EVANS, D. The internet of things: how the next evolution of the internet is
changing everything. CISCO white paper, 2011, 11 p.
EVANS, Ian; GOLLAPUDI, Devika; HAASE, Kim; JENDROCK, Eric;

SRIVATSHA, Chinmayee. The Java EE 6 Tutorial: Basic Concepts. 4ª Ed.
Boston: Addison Wesley, 2011.
FLORIDI, L. Internet of things: atart of a revolution. [S.l: s.n.], 2013. Disponível

em: <http://vimeo.com/77209992>. Acesso em: 14 jun. 2014.
FOWLER, Martin. ORM Hate. 2012. Disponível em: <http://martinfowler.com/

bliki/OrmHate.html>. Acesso em: 8 maio 2014.
FRANCO, Cristiano Roberto. Programação orientada a objetos. Uniasselvi,

Indaial. 2014;
GARTNER. Gartner identifies the top 10 strategic technology trends for

2013. [S.l: s.n.], mar. 2013. Disponível em: <http://www.gartner.com/it/page.
jsp?id=2209615>. Acesso em: 1 jan. 2013.
GARTNER. Gartner Says the Internet of Things installed base will grow to
26 billion units by 2020. Disponível em: <http://www.gartner.com/newsroom/
id/2636073>. Acesso em: 28 jul. 2014.
GREENFIELD, A. Everyware: the dawning age of ubiquitous computing. San

Francisco: New Riders Publishing, 2006.
GREENFIELD, A.; KIM, N. Against the smart city: the city is here for you to
use. [S.l.]: Do projects, 2013.
HINTON, A. A model for information environments: reframe IA. In: IA

SUMMIT, abr. 2013, Baltimore, MD, USA Anais... Baltimore, MD, USA: [s.n.],
abr. 2013 Disponível em: <http://www.slideshare.net/andrewhinton/a-model-for-
information-environments-reframe-ia-workshop-2013>. Acesso em: 15 set. 2013.
186
INTERNET OF THINGS: Philosophy. 3 jul. 2014, York St John University, UK.
Anais... York St John University, UK: [s.n.], 3 jul. 2014 Disponível em: <http://
internetofthingsphilosophy.com/slides-proceedings-etc/>. Acesso em: 1 ago. 2014.
ISHII, H. Defy gravity: beyond tangible bits, toward radical atoms. In: DW/AD ‘12,
4 dez. 2012, Kyoto International Conference Center, Kyoto, Japan. Anais... Kyoto
International Conference Center, Kyoto, Japan: [s.n.], 4 dez. 2012. Disponível em:
<http://www.youtube.com/watch?v=SMdFus2nPyw&feature=youtube_gdata_
player>. Acesso em: 20 abr. 2014.
K19. Desenvolvimento Web Avançado com JSF 2, EJB 3.1 e CDI. 2015.
Disponível em: <http://www.k19.com.br/downloads/apostilas/java/k19-k22-
desenvolvimento-web-avancado-com-jsf2-ejb3.1-e-cdi>. Acesso em: 15 jan. 2015.
K19. Desenvolvimento Web Avançado com JSF2, EJB 3.1 e CDI. 2013.
Disponível em: <http://www.k19.com.br/downloads/apostilas/java/k19-k12-
desenvolvimento-web-com-jsf2-e-jpa2>. Acesso em 14 ago. 2015.
KENDE, M. Global Internet report. Geneva: Internet Society, 2014. Disponível em:
<http://www.internetsociety.org/doc/global-internet-report>. Acesso em: 28 jul. 2014.
KLYN, D. Dutch uncles, ducks and decorated sheds: reframing IA. Baltimore,
MD, USA: [s.n.], 2013. Disponível em: <http://www.slideshare.net/danfnord/
dutch-uncles-ducks-and-decorated-sheds-reframing-ia>. Acesso em: 18 set. 2013.
KUNIAVSKY, M. Smart things: ubiquitous computing user experience design:

ubiquitous computing user experience design. [S.l.]: Elsevier, 2010.
LACERDA, F.; LIMA-MARQUES, M. Information architecture as a discipline:

a methodological approach. In: RESMINI, A. (Org). Reframing Information
Architecture. Human-Computer Interaction Series. Switzerland: Springer, 2014
Disponível em: <http://www.springer.com/computer/hci/book/978-3-319-06491-
8>. Acesso em: 19 abr. 2014.
187
LUCAS, P.; BALLAY, J.; McMANUS, M. Trillions thriving in the emerging
information ecology. Hoboken, N.J: Wiley, 2012.
McCULLOUGH, M. Digital ground: architecture, pervasive computing, and

environmental knowing. Cambridge, Mass: MIT Press, 2004.
McEWEN, A.; CASSIMALLY, H. Designing the internet of things. 1 ed.

Chichester: Wiley, 2013.
MENDES, P. Social-driven internet of connected objects. [S.l.]: Citeseer, 2011.
MORVILLE, P. Ambient findability: what we find changes who we become.

Sebastopol: O’Reilly Media, 2005.
MORVILLE, P. Ubiquitous information architecture: cross-channel strategy.

[S.l: s.n.], 2012. Disponível em: <http://www.slideshare.net/morville/ubiquitous-
information-architecture-crosschannel-strategy>. Acesso em: 30 dez. 2012.
NEGROPONTE, Nicholas. Learning by Doing: Don’t Dissect the Frog, Build it.
2004. Disponível em: <http://archive.wired.com/wired/archive/2.07/negroponte_
pr.html>. Acesso em: 8 ago. 2015.
NETBEANS. Netbeans IDE Features. Disponível em: <https://netbeans.org/

features/index.html>. Acesso em: 4 ago. 2015.
NORMAN, D. The design of future things. New York: Basic Books, 2009.
ORACLE. Introduction to Java Enterprise Edition 7. 2013. Disponível em:
<http://www.oracle.com/technetwork/java/javaee/javaee7-whitepaper-1956203.
pdf>. Acesso em: 2 ago. 2015.
ORACLE. Java Platform, Enterprise Edition: The Java EE 5 Tutorial. 2010.

Disponível em: <http://docs.oracle.com/javaee/5/tutorial/doc/bnaph.html>.
Acesso em: 15 ago. 2015.
188
ORACLE. Java Platform, Enterprise Edition: The Java EE Tutorial. 2014. Disponível
em: <https://docs.oracle.com/javaee/7/tutorial/>. Acesso em: 15 ago. 2015.
RESMINI, A. The poetics of information architecture. In: ASIS & T EUROIA,

2013, Edinburgh. Anais... Edinburgh: [s.n.], 2013. Disponível em: <http://
pt.slideshare.net/resmini/the-poetics-of-information-architecture-26991604>.
Acesso em: 3 ago. 2014.
RESMINI, A.; ROSATI, L. Pervasive information architecture: designing cross-

channel user experiences. Boston: Morgan Kaufmann, 2011.
SANTUCCI, G. On the philosophy of the internet of things. In: INTERNET

OF THINGS PHILOSOPHY, 3 jul. 2014, York St John University. Anais...
York St John University: [s.n.], 3 jul. 2014. Disponível em: <http://www.
theinternetofthings.eu/content/g%C3%A9rald-santucci-internet-things-window-
our-future>. Acesso em: 2 fev. 2015.
SHIN, D.-H. A realization of pervasive computing: Ubiquitous city. In:

TECHNOLOGY MANAGEMENT FOR GLOBAL ECONOMIC GROWTH
(PICMET), 2010 PROCEEDINGS OF PICMET ‘10: jul. 2010. Proceedings... [S.l:
s.n.], jul. 2010. p. 1 -10.
SOFTPLAN. Curso EAD JEE 6. Disponível em: <http://oncourse.softplan.com.

br/pluginfile.php/109/mod_resource/content/2/jsf/pdf-slides/parte-2-slides.pdf
>. Acesso em: 12 ago. 2015.
TELECOMMUNICATION STANDARDIZATION SECTOR (ITU-T). ITU-T

Y.2060: overview of the internet of things. [S.l: s.n.]. Disponível em: <http://www.
itu.int/ITU-T/recommendations/rec.aspx?rec=11559>. Acesso em: 20 set. 2014.
THIAGO, André. Vantagens e desvantagens da injeção de dependências. 2010.

Disponível em: <http://andrethiago.com/2010/04/01/vantagens-e-desvantagens-
da-injecao-de-dependencia/>. Acesso em: 2 jan. 2015.
189
TODD, Spangler. Netflix bandwidth usage climbs to nearly 37% of internet
traffic on peak hours. Disponível em: <http://variety.com/2015/digital/news/
netflix-bandwidth-usage-internet-traffic-1201507187/>. Acesso em: 2 ago. 2015.
VAN GIGCH, J. P. Systems science, the discipline of epistemological domains,

contributes to the design of the intelligent global web. Behavioral Science, v. 35,
n. 2, p. 122, 1990 Disponível em: <http://onlinelibrary.wiley.com/doi/10.1002/
bs.3830350205/abstract>. Acesso em: 20 jul. 2010.
W3C. Ubiquitous Web Domain. W3C. [S.l: s.n.], 2010. Disponível em: <http://
www.w3.org/UbiWeb/>. Acesso em: 20 jul. 2010 .
WEBER, R. H. Internet of things: governance quo vadis? Computer Law & Security
Review, v. 29, n. 4, p. 341-347, ago 2013 Disponível em: <http://www.sciencedirect.
com/science/article/pii/S0267364913001015>. Acesso em: 28 ago. 2013.
WEISER, M.; BROWN, J. S. The coming age of calm technology. Palo Alto:
Xerox PARC, 1996.
190
ANOTAÇÕES
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
191
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
192

Programação para Web II

Enviado por

Dados do documento

Título original

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

Programação para Web II

Enviado por

Direitos autorais:

Formatos disponíveis

Programação para Web II

Prof. Cristiano Roberto Franco

Revisão, Diagramação e Produção:

Ficha catalográfica elaborada na fonte pela Biblioteca Dante Alighieri

Programação Web II / Cristiano Roberto Franco. Indaial :

1.Programação para internet.

Tamanha conectividade é possível, mas não vem de graça. Ela cobra

É nesse contexto que atua a tecnologia que estudaremos nesta disciplina.

Conforme Evans et al. (2011), os desenvolvedores de software

Aproveito esse momento para destacar que os exercícios NÃO SÃO

Você precisará de muita determinação e força de vontade, pois o

Lembre-se de que o encantamento com a programação deriva do

Prof. Cristiano Roberto Franco

Na Educação a Distância, o livro impresso, entregue a todos os acadêmicos desde 2005, é

Assim, a UNIASSELVI, preocupando-se com o impacto de nossas ações sobre o ambiente,

Aproveito o momento para convidá-lo para um bate-papo sobre o Exame Nacional de

TÓPICO 1 – INTRODUÇÃO AO JAVA ENTERPRISE EDITION E PRINCIPAIS

TÓPICO 2 – CONSTRUÇÃO DO AMBIENTE DE DESENVOLVIMENTO E EPLOYMENT..... 13

TÓPICO 3 – JAVA SERVER FACES (JSF)............................................................................................ 37

UNIDADE 2 – COMPONENTES GRÁFICOS DO JAVA SERVER FACES E JAVA

TÓPICO 1 – COMPONENTES GRÁFICOS DO JAVA SERVER FACES........................................ 61

TÓPICO 2 – JAVA PERSISTENCE API................................................................................................ 93

UNIDADE 3 – ENTERPRISE JAVA BEANS (EJB) E CONTEXT AND DEPENDENCY

TÓPICO 1 – STATELESS SESSION BEANS..................................................................................... 131

TÓPICO 2 – STATEFUL SESSION BEAN E SINGLETON SESSION BEANS............................... 145

TÓPICO 3 – CONTEXT AND DEPENDENCY INJECTION............................................................157

TÓPICO 4 – JAVA MESSAGE SERVICE (JMS)............................................................................... 165

• identificar e descrever algumas das tecnologias que fazem parte da

• identificar quais tipos de situações e ambientes são mais adequados para

• montar um ambiente de desenvolvimento e deployment de aplicações

TÓPICO 1 – INTRODUÇÃO AO JAVA ENTERPRISE EDITION E

TÓPICO 2 – CONSTRUÇÃO DO AMBIENTE DE DESENVOLVIMENTO E

TÓPICO 3 – JAVA SERVER FACES (JSF)

INTRODUÇÃO AO JAVA ENTERPRISE EDITION

O JCP é o mecanismo através do qual são definidas as especificações técnicas

Conforme Evans et al. (2011), o modelo de aplicação do JEE começa

A plataforma JEE é projetada para suportar aplicações que possuem

1) A lógica de negócio e apresentação: implementadas pelo desenvolvedor.

A Figura 1 apresenta uma arquitetura JEE típica:

FIGURA 1 - ARQUITURA JEE TÍPICA

FONTE: Evans et al. (2011)

Para compreender a figura, inicialmente é necessária a compreensão do

1) Client Tier: representa a camada cliente, ou seja, o que os usuários efetivamente

É importante mencionar alguns detalhes a respeito destas definições. A

Outro detalhe importante é que as layers, com exceção da Client Machine,

A grande premissa por trás do JEE é que o desenvolvedor pode confiar na

No caso do JEE, um dos componentes principais (se não o principal) é o

O Swing e o JavaFX são tecnologias definidas pela Oracle para a criação de

Mas que serviços são estes? Com o advento e popularização da internet

Algumas das tecnologias disponibilizadas pelo JEE permitem que o

De acordo com ORACLE (2013), o modelo simplificado de programação

Abaixo estão listados alguns dos serviços disponibilizados pelas

• Transações: A arquitetura Enterprise Java Beans (EJB) define um suporte sofisticado

• Integração: A arquitetura EJB é fortemente integrada com os componentes da

Os enterprise java beans, conhecidos como EJBs fazem parte da especificação

A seguir faremos uma rápida introdução às principais tecnologias que

Componentes JEE: As aplicações JEE são feitas de componentes. Estes

• Aplicação cliente e applets que executam no cliente.

Todos estes componentes são escritos na linguagem de programação Java

Java Server Faces (JSF): É um framework para a construção de aplicações

Java Persistence API (JPA): Apresenta uma solução para a persistência

Java Transaction API (JTA): Oferece uma inferface-padrão para a

Nas tecnologias de bancos de dados, um rollback significa que o banco de