Programação para Web

Prévia do material em texto

2024
Programação Para 
Web
Prof. Cristiano Roberto Franco
Copyright © UNIASSELVI 2024
Elaboração:
Prof. Cristiano Roberto Franco
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.
Impresso por: 
Bibliotecária: Leila Regina do Nascimento - CRB- 9/1722.
Ficha catalográfica elaborada de acordo com os dados fornecidos pelo(a) autor(a).
Núcleo de Educação a Distância. FRANCO, Cristiano Roberto.
Programação para Web / Cristiano Roberto Franco. - Florianópolis, 
SC: Arqué, 2024.
200 p.
ISBN papel 978-65-6137-883-3
ISBN digital 978-65-6137-884-0
1. Programação 2. Web 3. EaD. I. Título. 
CDD - 005.276 
FICHA CATALOGRÁFICA
N964
III
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.
IV
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!
 Prof. Cristiano Roberto Franco
V
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!
NOTA
VI
VII
UNIDADE 1 – INTRODUÇÃO AO JAVA ENTERPRISE EDITION ............................................... 1
TÓPICO 1 – INTRODUÇÃO AO JAVA ENTERPRISE EDITION E PRINCIPAIS 
 TECNOLOGIAS ................................................................................................................escopo do MB é de request, ou seja, os valores da árvore de objetos 
devem ser mantidos somente durante o request. 
44
UNIDADE 1 | INTRODUÇÃO AO JAVA ENTERPRISE EDITION
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. 
TÓPICO 3 | JAVA SERVER FACES (JSF)
45
FIGURA 44 - DEPLOYMENT E EXECUÇÃO DO PROJETO
FONTE: O autor
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
46
UNIDADE 1 | INTRODUÇÃO AO JAVA ENTERPRISE EDITION
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.
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: .
ATENCAO
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. 
TÓPICO 3 | JAVA SERVER FACES (JSF)
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
UNIDADE 1 | INTRODUÇÃO AO JAVA ENTERPRISE EDITION
FONTE: O autor
FIGURA 47 - CICLO DE VIDA DO JSF
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.
TÓPICO 3 | JAVA SERVER FACES (JSF)
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
UNIDADE 1 | INTRODUÇÃO AO JAVA ENTERPRISE EDITION
FONTE: O autor
FIGURA 49 - MANAGED BEAN COM ESCOPO DE SESSÃO
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.
TÓPICO 3 | JAVA SERVER FACES (JSF)
51
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/
ATENCAO
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
UNIDADE 1 | INTRODUÇÃO AO JAVA ENTERPRISE EDITION
LEITURA COMPLEMENTAR
Artigo disponível em: .
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.
TÓPICO 3 | JAVA SERVER FACES (JSF)
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
UNIDADE 1 | INTRODUÇÃO AO JAVA ENTERPRISE EDITION
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 
TÓPICO 3 | JAVA SERVER FACES (JSF)
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
1 O JSF é um framework da plataforma Java, cujo funcionamento é baseado 
em objetos, os quais são mantidos no servidor de aplicação. Referente ao 
framework JSF, analise as afirmativas a seguir:
I- O JSF funciona através da arquitetura MVC.
II- O Managed Bean (MB) funciona como intermediário entre as camadas 
Model e View.
III- O Managed Bean (MB) não consegue instanciar objetos no lado do servidor, 
porém reage a eventos da camada View.
IV- A classe que implementa um Managed Bean (MB) não deve ser serializável, 
o que permite o acesso aos componentes.
Agora assinale a alternativa que apresenta as afirmaticas CORRETAS:
a) ( ) I e II
b) ( ) II e III
c) ( ) I, II e III
d) ( ) II, III e IV
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.
4 A linguagem de programação Java permite o desenvolvimento de 
aplicações robustas, atendendo tanto pequenas quanto grandes empresas., 
disponibilizando a vários frameworks de desenvolvimento. Referente ao 
framework JSF (Java Server Faces), estudado nesta disciplina, analise as 
afirmativas a seguir:
I- O JSF permite o desenvolvimento de aplicações web.
II- O JSF utiliza a arquitetura de desenvolvimento de componentes chamado 
MVC (Model-View-Controller).
III- O JSF não possui o gerenciamento do ciclo de vida dos componentes 
visuais.
IV- O JSF não possui suporte a funcionalidade ajax.
Agora assinale a alternative CORRETA:
a) ( ) Apenas as afirmativas I e II estão corretas
b) ( ) Apenas as afirmativas II e III estão corretas
c) ( ) Apenas as afirmativas I, II e III estão corretas
d) ( ) Apenas as afirmativas II, III e IV estão corretas
AUTOATIVIDADE
58
5 O framework JSF (Java Server Faces), permite o desenvolvimento de 
aplicações robustas e com vários recursos que facilitam o desenvolvimento. 
O JSF utiliza classes Managed Beans, as quais permitem o controle de 
formulários de páginas web dentro destas classes. Referente ao JSF e seus 
componentes, analise as afirmativas a seguir:
I- O Managed Bean permite que um método seu seja invocado pelo componente 
do tipo “commandButton”.
II- O Managed Bean funciona como intermediário entre as camadas model e 
view.
III- A anotação @RequestScoped possui a mesma funcionalidade da anotação 
@SessionScoped.IV- A anotação @SessionScoped não pode ser utilizada em um Managed Bean.
Agora assinale a alternative CORRETA:
a) ( ) Apenas as afirmativas I e II estão corretas.
b) ( ) Apenas as afirmativas II e III estão corretas.
c) ( ) Apenas as afirmativas I, II e III estão corretas.
d) ( ) Apenas as afirmativas II, III e IV estão corretas.
59
UNIDADE 2
COMPONENTES GRÁFICOS DO 
JAVA SERVER FACES E JAVA 
PERSISTENCE API
OBJETIVOS DE APRENDIZAGEM
PLANO DE ESTUDOS
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.
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 – COMPONENTES GRÁFICOS DO JAVA SERVER FACES
TÓPICO 2 – JAVA PERSISTENCE API (JPA)
60
61
TÓPICO 1
COMPONENTES GRÁFICOS DO JAVA SERVER FACES
UNIDADE 2
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. 
UNIDADE 2 | COMPONENTES GRÁFICOS DO JAVA SERVER FACES E JAVA PERSISTENCE API
62
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.
TÓPICO 1 | COMPONENTES GRÁFICOS DO JAVA SERVER FACES
63
FONTE: O autor
FIGURA 51 - CONFIGURAÇÃO DO PROJETO
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.
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: .
IMPORTANTE
UNIDADE 2 | COMPONENTES GRÁFICOS DO JAVA SERVER FACES E JAVA PERSISTENCE API
64
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.
TÓPICO 1 | COMPONENTES GRÁFICOS DO JAVA SERVER FACES
65
FONTE: O autor
FIGURA 53 - MANAGED BEAN
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.
UNIDADE 2 | COMPONENTES GRÁFICOS DO JAVA SERVER FACES E JAVA PERSISTENCE API
66
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 foirealizada 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 
TÓPICO 1 | COMPONENTES GRÁFICOS DO JAVA SERVER FACES
67
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. 
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.
IMPORTANTE
FIGURA 55 - MENSAGENS DE VALIDAÇÃO
FONTE: O autor
UNIDADE 2 | COMPONENTES GRÁFICOS DO JAVA SERVER FACES E JAVA PERSISTENCE API
68
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.
TÓPICO 1 | COMPONENTES GRÁFICOS DO JAVA SERVER FACES
69
FONTE: O autor
FONTE: O autor
FIGURA 57 - MÉTODO PARA VALIDAÇÃO DE EMAIL
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
É 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: .
IMPORTANTE
UNIDADE 2 | COMPONENTES GRÁFICOS DO JAVA SERVER FACES E JAVA PERSISTENCE API
70
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
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
TÓPICO 1 | COMPONENTES GRÁFICOS DO JAVA SERVER FACES
71
FONTE: O autor
FIGURA 61 - MÉTODO QUE FAZ O BINDING ENTRE O RADIO BUTTON E O ENUM
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. 
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.
IMPORTANTE
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, 
enquantoo 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
UNIDADE 2 | COMPONENTES GRÁFICOS DO JAVA SERVER FACES E JAVA PERSISTENCE API
72
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
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
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.
TÓPICO 1 | COMPONENTES GRÁFICOS DO JAVA SERVER FACES
73
FONTE: O autor
FONTE: O autor
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.
IMPORTANTE
FIGURA 65 - CADASTRO DE PESSOA
FIGURA 66 - SAÍDA NO CONSOLE
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.
UNIDADE 2 | COMPONENTES GRÁFICOS DO JAVA SERVER FACES E JAVA PERSISTENCE API
74
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 . 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.
TÓPICO 1 | COMPONENTES GRÁFICOS DO JAVA SERVER FACES
75
FIGURA 68 - CÓDIGO FONTE PARA A CRIAÇÃO DO DATATABLE
FONTE: O autor
O componente DataTable foi colocado dentro de um componente 
(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 
 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.
UNIDADE 2 | COMPONENTES GRÁFICOS DO JAVA SERVER FACES E JAVA PERSISTENCE API
76
FIGURA 69 - LISTAGEM DE PESSOAS
FONTE: O autor
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
TÓPICO 1 | COMPONENTES GRÁFICOS DO JAVA SERVER FACES
77
FONTE: O autor
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
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 FullPublish, o contexto antigo é substituído pelo novo, garantindo que as 
mudanças estejam refletidas no servidor.
IMPORTANTE
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.
UNIDADE 2 | COMPONENTES GRÁFICOS DO JAVA SERVER FACES E JAVA PERSISTENCE API
78
FIGURA 72 - PÁGINA INICIAL
FONTE: O autor
FONTE: O autor
FIGURA 73 - LINK QUE PERMITE RETORNO À PÁGINA INICIAL
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).
TÓPICO 1 | COMPONENTES GRÁFICOS DO JAVA SERVER FACES
79
FONTE: O autor
FONTE: O autor
FIGURA 74 - AJAX
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
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
IMPORTANTE
UNIDADE 2 | COMPONENTES GRÁFICOS DO JAVA SERVER FACES E JAVA PERSISTENCE API
80
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: . Neste endereço, você poderá ver demonstrações funcionais dos 
componentes, sempre com o código-fonte ao lado, ilustrando sua utilização.
TÓPICO 1 | COMPONENTES GRÁFICOS DO JAVA SERVER FACES
81
FONTE: O autor
FIGURA 77 - WEBSITE DO PRIMEFACES
As Figuras 78, 79 e 80 mostram os componentes calendar, chart e accordion, 
respectivamente:
FIGURA 78 - COMPONENTE CALENDAR
FONTE: Disponível em: .
Acesso em: 30 out. 2015.
UNIDADE 2 | COMPONENTES GRÁFICOS DO JAVA SERVER FACES E JAVA PERSISTENCE API
82
FIGURA 79 - COMPONENTE CALENDAR
FONTE: Disponível em: .
Acesso em: 30 out. 2015.
FIGURA 80 - COMPONENTE ACCORDION
FONTE: Disponível em: .
Acesso em: 30 out. 2015.
Para utilizar estes e outros componentes, a primeira etapa consiste 
em fazer o download da biblioteca do Prime Faces, disponível na URL: . 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.
TÓPICO 1 | COMPONENTES GRÁFICOS DO JAVA SERVER FACES
83
FIGURA 81 - CONFIGURAÇÃO DO PRIME FACES
FONTE: O autor
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
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. 
UNIDADE 2 | COMPONENTES GRÁFICOS DO JAVA SERVER FACES E JAVA PERSISTENCE API
84
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 apresentaa 
informação de forma mais destacada.
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.
IMPORTANTE
TÓPICO 1 | COMPONENTES GRÁFICOS DO JAVA SERVER FACES
85
FONTE: O autor
FIGURA 84 - ALTERAÇÃO DOS COMPONENTES
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: . 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.
UNIDADE 2 | COMPONENTES GRÁFICOS DO JAVA SERVER FACES E JAVA PERSISTENCE API
86
FIGURA 85 - DOWNLOAD DO TEMA VADER
FONTE: O autor
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
TÓPICO 1 | COMPONENTES GRÁFICOS DO JAVA SERVER FACES
87
FONTE: O autor
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
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). 
UNIDADE 2 | COMPONENTES GRÁFICOS DO JAVA SERVER FACES E JAVA PERSISTENCE API
88
FONTE: O autor
FONTE: O autor
FIGURA 88 - TEMAS GRATUITOS DO PRIME FACES
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
Observe que entre as linhas 16 e 20 está a declaração da tabela. Esta 
declaração ocorre logo após a declaração . 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.
TÓPICO 1 | COMPONENTES GRÁFICOS DO JAVA SERVER FACES
89
FONTE: O autor
 FIGURA 90 - DATATABLE COM O TEMA EXCITE-BIKE
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á!
90
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.
91
AUTOATIVIDADE
1 Implemente um mecanismo de persistência, para armazenar os dados 
enviados de um formulário da tela na memória do servidor através de uma 
classe Managed Bean. Implemente a inserção dos dados em uma coleção 
(List, Map, Set) e a exclusão de um objeto da lista.
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.
4 O JSF (Java Server Faces) pode ser entendido por ser um framework de 
componentes de servidor para aplicações web que funciona de acordo com o 
padrão MVC. Este framework possui várias funcionalidades, como api que 
representa componentes de interface gráfica e seu estado, gerenciamento de 
eventos, entre outros. Neste contexto, descreva as restrições que uma classe 
precisa ter para ser considerada um Java Bean. Implemente um exemplo de 
uma classe Java Bean.
5 Dentre os componentes mais utilizados em interfaces web no JSF é o DataTable, 
o qual recebe uma listagem de objetos, consumindo-a e montando um grid 
de dados, sendo apresentado no navegador de internet como uma tabela 
HTML. Neste contexto, apresente a implementação de um DataTable sendo 
utilizado.
92
93
TÓPICO 2
JAVA PERSISTENCE API
UNIDADE 2
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.
UNIDADE 2 | COMPONENTES GRÁFICOS DO JAVA SERVER FACES E JAVA PERSISTENCE API
94
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.
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: .
IMPORTANTE
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.
TÓPICO 2 | JAVA PERSISTENCE API
95
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.
UNIDADE 2 | COMPONENTES GRÁFICOS DO JAVA SERVER FACES E JAVA PERSISTENCE API
96
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.
TÓPICO 2 | JAVA PERSISTENCE API
97
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
NOTA
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, convertendoobjetos para registros e vice-versa.
UNIDADE 2 | COMPONENTES GRÁFICOS DO JAVA SERVER FACES E JAVA PERSISTENCE API
98
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. 
TÓPICO 2 | JAVA PERSISTENCE API
99
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
UNIDADE 2 | COMPONENTES GRÁFICOS DO JAVA SERVER FACES E JAVA PERSISTENCE API
100
• 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
FONTE: SOFTPLAN (2015)
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.
TÓPICO 2 | JAVA PERSISTENCE API
101
FIGURA 97 - MAPEAMENTO DE CLASSE PARA TABELA
FONTE: SOFTPLAN (2015)
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.
UNIDADE 2 | COMPONENTES GRÁFICOS DO JAVA SERVER FACES E JAVA PERSISTENCE API
102
FIGURA 98 - ENTIDADE PESSOA
FONTE: O autor
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
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.
TÓPICO 2 | JAVA PERSISTENCE API
103
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.
UNIDADE 2 | COMPONENTES GRÁFICOS DO JAVA SERVER FACES E JAVA PERSISTENCE API
104
FONTE: O autor
FIGURA 100 - DIRETÓRIO PARA O ARQUIVO DE CONFIGURAÇÃO PERSISTENCE.XML
Com isso,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
sumário
VIII
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 ........................................................................................................150no 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; 
TÓPICO 2 | JAVA PERSISTENCE API
105
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
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
NOTA
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 
UNIDADE 2 | COMPONENTES GRÁFICOS DO JAVA SERVER FACES E JAVA PERSISTENCE API
106
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.
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.
TÓPICO 2 | JAVA PERSISTENCE API
107
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.
NOTA
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.
FIGURA 103 - CADASTRO DE PESSOA
FONTE: O autor
UNIDADE 2 | COMPONENTES GRÁFICOS DO JAVA SERVER FACES E JAVA PERSISTENCE API
108
FONTE: O autor
FONTE: O autor
FONTE: O autor
FIGURA 104 - REGISTRO DA PESSOA NO BANCO DE DADOS
FIGURA 105 - LISTAGEM DE PESSOAS
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
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
NOTA
TÓPICO 2 | JAVA PERSISTENCE API
109
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: . Acesso em: 20 out. 2015.
UNIDADE 2 | COMPONENTES GRÁFICOS DO JAVA SERVER FACES E JAVA PERSISTENCE API
110
FONTE: O autor
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 paradecidir 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
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:
TÓPICO 2 | JAVA PERSISTENCE API
111
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 muitos (M:M) – 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.
UNIDADE 2 | COMPONENTES GRÁFICOS DO JAVA SERVER FACES E JAVA PERSISTENCE API
112
FIGURA 111 - NAVEGABILIDADE DOS RELACIONAMENTOS
FONTE: SOFTPLAN (2015)
FONTE: SOFTPLAN (2015)
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. 
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.
NOTA
TÓPICO 2 | JAVA PERSISTENCE API
113
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á!
UNIDADE 2 | COMPONENTES GRÁFICOS DO JAVA SERVER FACES E JAVA PERSISTENCE API
114
LEITURA COMPLEMENTAR
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 modificadada 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.
TÓPICO 2 | JAVA PERSISTENCE API
115
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. 
UNIDADE 2 | COMPONENTES GRÁFICOS DO JAVA SERVER FACES E JAVA PERSISTENCE API
116
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
TÓPICO 2 | JAVA PERSISTENCE API
117
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”
UNIDADE 2 | COMPONENTES GRÁFICOS DO JAVA SERVER FACES E JAVA PERSISTENCE API
118
É 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
MongoDB shell version: 1.8.1
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.
TÓPICO 2 | JAVA PERSISTENCE API
119
Listagem 7. Mensagem após abrir o shell
MongoDB shell version: 1.8.1
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.
UNIDADE 2 | COMPONENTES GRÁFICOS DO JAVA SERVER FACES E JAVA PERSISTENCE API
120
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: [
 {
TÓPICO 2 | JAVA PERSISTENCE API
121
 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 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);.
TÓPICO 2 | JAVA PERSISTENCE API
123
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)
UNIDADE 2 | COMPONENTES GRÁFICOS DO JAVA SERVER FACES E JAVA PERSISTENCE API
124
• $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: . Acesso 
em: 20 out. 2015
125
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.
126
 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.
127
AUTOATIVIDADE
1 Implemente uma funcionalidade de consulta de clientes utilizando JPA e 
JSF, apresentando os clientes encontrados em uma tabela, utilizando o 
componente DataTable.
2 Implemente uma funcionalidade de persistência de clientes utilizando JPA e 
JSF, possuindo a funcionalidade de inserir e atualizar um registro na tabela 
Cliente do banco de dados. Apresente a classe Managed Bean, controladora 
do formulário, a classe entidade, e a classe onde é realizada a persistência. 
Apresente também o formulário de cadastro ou alteração do cliente.
3 Implemente uma funcionalidade de consulta em uma tabela chamada 
“Grupo” utilizando o JPA, porém, esta consulta deve ser realizada através 
do JPAQL. Apresente a implementação das classe Managed Bean chamada 
GrupoMB, e a classe de persistência, onde é realizada a consulta, a qual 
pode ser chamada de GrupoRepository.
4 A maioria dos softwares desenvolvidos possuem a necessidade de 
armazenar dados em bancos de dados. Alguns dos bancos de dados mais 
utilizados são o Oracle, MySQL, SQLServer, entre outros. Porém, estes 
bancos são relacionais, e com isso, existe o problema mapeamento objeto 
relacional, o que pode ser resolvido na linguagem de programação Java com 
alguns recursos ou técnicas. Referente ao problema objeto relacional, analise 
as afirmativas a seguir:
I- O padrão de projeto DAO é uma das soluções para este problema.
II- O padrão DAO implementa uma camada para fazer o mapeamento entre 
os objetos e as tabelas do banco de dados.
III- O JPA é a api-padrão da plataforma Java para a persistência do estado de 
objetos em bancos de dados relacionais.
IV- O padrão DAO e o JPA funcionam da mesma forma, sendo apenas 
bibliotecas de fabricantes concorrentes.
Agora assinale a alternativa CORRETA:
a) ( ) I, II e III
b) ( ) II e III
c) ( ) I e III
d) ( ) II e IV
5 Com o problema do mapeamento objeto relacional, na linguagem de 
programação Java uma das soluções é a utilização da especificação JPA. O JPA 
permite a persistência do estado de qualquer classe Java, bastando utilizar as 
anotações obrigatórias. Referente ao JPA, analise as afirmativas a seguir:
128
I- @Entity é a anotação que define uma classe como entidade e tabela.
II- @Table é a anotação que define uma classe como entidade e tabela, sendo 
uma anotação sempre obrigatória.
III- @Id é a anotação que define o nome para uma classe.
IV- @Entity e @Id são as duas anotações que são obrigatórias.
Agora assinale a alternativa CORRETA:
a) ( ) I e IV
b) ( ) II e III
c) ( ) I e III
d) ( ) II e IV
129
UNIDADE 3
ENTERPRISE JAVA BEANS (EJB) 
E CONTEXT AND DEPENDENCY 
INJECTION (CDI)
OBJETIVOS DE APRENDIZAGEM
PLANO DE ESTUDOS
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.
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 
apropriação dos conteúdos.
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
130
131
TÓPICO 1
STATELESS SESSION BEANS
UNIDADE 3
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. 
UNIDADE 3 | ENTERPRISE JAVA BEANS (EJB) E CONTEXT AND DEPENDENCY INJECTION (CDI)
132
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.
TÓPICO 1 | STATELESS SESSION BEANS
133
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.
É 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.
IMPORTANTE
FIGURA 116 – STATELESS SESSION BEAN
FONTE: Adaptado de K19 (2015)
UNIDADE 3 | ENTERPRISE JAVA BEANS (EJB) E CONTEXT AND DEPENDENCY INJECTION (CDI)
134
Como estaclasse 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
FONTE: Adaptado de K19 (2015)
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. 
TÓPICO 1 | STATELESS SESSION BEANS
135
FIGURA 118 – STATELESS SESSION BEAN, VERSÃO 3.1
FONTE: Adaptado de K19 (2015)
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.
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: .
IMPORTANTE
UNIDADE 3 | ENTERPRISE JAVA BEANS (EJB) E CONTEXT AND DEPENDENCY INJECTION (CDI)
136
FIGURA 119 – MENSAGENS DE VALIDAÇÃO
FONTE: Adaptado de K19 (2015)
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.
TÓPICO 1 | STATELESS SESSION BEANS
137
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
FONTE: Adaptado de K19 (2015)
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.
UNIDADE 3 | ENTERPRISE JAVA BEANS (EJB) E CONTEXT AND DEPENDENCY INJECTION (CDI)
138
As regras para nomenclatura podem ser acessadas em: .
IMPORTANTE
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ãopode atender a outras 
chamadas. Depois de finalizar o atendimento, a instância volta para o estado 
PRONTO podendo receber outras chamadas.
TÓPICO 1 | STATELESS SESSION BEANS
139
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
FONTE: Adaptado de K19 (2015)
UNIDADE 3 | ENTERPRISE JAVA BEANS (EJB) E CONTEXT AND DEPENDENCY INJECTION (CDI)
140
FIGURA 123 – ANOTAÇÃO @PREDESTROY
FONTE: Adaptado de K19 (2015)
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.
TÓPICO 1 | STATELESS SESSION BEANS
141
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.
IMPORTANTE
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
FONTE: Adaptado de K19 (2015)
142
 Neste tópico você viu que: 
• 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.
RESUMO DO TÓPICO 1
143
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.
AUTOATIVIDADE
144
145
TÓPICO 2
STATEFUL SESSION BEAN E SINGLETON SESSION BEANS
UNIDADE 3
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)
146
UNIDADE 3 | ENTERPRISE JAVA BEANS (EJB) E CONTEXT AND DEPENDENCY INJECTION (CDI)
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.
TÓPICO 2 | STATEFUL SESSION BEAN E SINGLETON SESSION BEANS
147
FIGURA 128 – CONFIGURAÇÕES DO EJB
FONTE: K19 (2015)
É 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.
IMPORTANTE
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.
148
UNIDADE 3 | ENTERPRISE JAVA BEANS (EJB) E CONTEXT AND DEPENDENCY INJECTION (CDI)
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):
NÃO EXISTE -> PRONTO
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 aesse 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. 
PRONTO -> NÃO EXISTE
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).
TÓPICO 2 | STATEFUL SESSION BEAN E SINGLETON SESSION BEANS
149
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)
150
UNIDADE 3 | ENTERPRISE JAVA BEANS (EJB) E CONTEXT AND DEPENDENCY INJECTION (CDI)
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
FONTE: Adaptado de K19 (2015)
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.
TÓPICO 2 | STATEFUL SESSION BEAN E SINGLETON SESSION BEANS
151
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)
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: .
IMPORTANTE
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)
152
UNIDADE 3 | ENTERPRISE JAVA BEANS (EJB) E CONTEXT AND DEPENDENCY INJECTION (CDI)
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):
NÃO EXISTE -> PRONTO
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
TÓPICO 2 | STATEFUL SESSION BEAN E SINGLETON SESSION BEANS
153
PRONTO -> NÃO EXISTE
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)
Os callbacks @PostConstruct e @PreDestroy também estão disponíveis para os 
Singleton Session Beans através das anotações respectivas.
IMPORTANTE
154
 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.
RESUMO DO TÓPICO 2
155
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.
156
157
TÓPICO 3
CONTEXT AND DEPENDENCY INJECTION
UNIDADE 3
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 acoplamentoentre 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.
UNIDADE 3 | ENTERPRISE JAVA BEANS (EJB) E CONTEXT AND DEPENDENCY INJECTION (CDI)
158
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. 
O termo injeção de dependência foi criado por Martin Fowler. Maiores detalhes 
podem ser observados em: .
IMPORTANTE
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. 
TÓPICO 3 | CONTEXT AND DEPENDENCY INJECTION
159
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
FONTE: Adaptado de K19 (2015)
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.
UNIDADE 3 | ENTERPRISE JAVA BEANS (EJB) E CONTEXT AND DEPENDENCY INJECTION (CDI)
160
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. 
Caso você queira se aprofundar na especificação CDI, sugerimos o material 
disponível no link: .
IMPORTANTE
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.
TÓPICO 3 | CONTEXT AND DEPENDENCY INJECTION
161
FIGURA 141 – ANOTAÇÕES CDI
FONTE: Adaptado de K19 (2015)
162
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.
RESUMO DO TÓPICO 3
163
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.
164
165
TÓPICO 4
JAVA MESSAGE SERVICE (JMS)
UNIDADE 3
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 e lá faça as 
alterações conforme a Figura 142.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
1
UNIDADE 1
INTRODUÇÃO AO JAVA
ENTERPRISE EDITION
OBJETIVOS DE APRENDIZAGEM
PLANO DE ESTUDOS
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.
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)
2
3
TÓPICO 1
UNIDADE 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).
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: .
IMPORTANTE
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.
UNIDADE 1 | INTRODUÇÃO AO JAVA ENTERPRISE EDITION
4
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 
TÓPICO 1 | INTRODUÇÃO AO JAVA ENTERPRISE EDITION E PRINCIPAIS TECNOLOGIAS
5
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 importanteUNIDADE 3 | ENTERPRISE JAVA BEANS (EJB) E CONTEXT AND DEPENDENCY INJECTION (CDI)
166
FIGURA 142 – ARQUIVO DE CONFIGURAÇÃO
FONTE: O autor
FIGURA 143 – ARQUIVO DE CONFIGURAÇÃO
FONTE: Adaptado de K19 (2015)
Agora inicie o WildFly e procure pelas mensagens da Figura 143 no 
console. Estas mensagens indicam que a configuração foi feita com sucesso.
TÓPICO 4 | JAVA MESSAGE SERVICE (JMS)
167
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
UNIDADE 3 | ENTERPRISE JAVA BEANS (EJB) E CONTEXT AND DEPENDENCY INJECTION (CDI)
168
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
FONTE: Adaptado de K19 (2015)
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.
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
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
TÓPICO 4 | JAVA MESSAGE SERVICE (JMS)
169
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: 
.
IMPORTANTE
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
FONTE: Adaptado de K19 (2015)
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:
UNIDADE 3 | ENTERPRISE JAVA BEANS (EJB) E CONTEXT AND DEPENDENCY INJECTION (CDI)
170
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
TÓPICO 4 | JAVA MESSAGE SERVICE (JMS)
171
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
javax.jms.TextMessage
Um bloco de texto, representado em java como uma 
String. Pode ser utilizado para representar uma 
mensagem como um arquivo XML ou JSON. 
javax.jms.
ObjectMessage
Um objeto java serializável, como por exemplo um 
Java Bean.
javax.jms.MapMessage Um objeto contendo diversos pares de chave/valor.
javax.jms.
BytesMessage
Um bloco de dados binários representado em java 
como um array de bytes. Utilizado para interagir com 
sistemas de mensagens externos que possuem seus 
próprios protocolos binários de comunicação.
javax.jms.
StreamMessage
Uma lista de valores primitivos do Java que pode 
ser utilizado para representar certos tipos de dados 
usados por sistemas de mensagem externos.
FONTE: Adaptado de: . Acesso em: 12 fev. 2016.
UNIDADE 3 | ENTERPRISE JAVA BEANS (EJB) E CONTEXT AND DEPENDENCY INJECTION (CDI)
172
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.
IMPORTANTE
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 , 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
FONTE: Adaptado de K19 (2015)
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 comoAngularJS, 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!
TÓPICO 4 | JAVA MESSAGE SERVICE (JMS)
173
LEITURA COMPLEMENTAR
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 
UNIDADE 3 | ENTERPRISE JAVA BEANS (EJB) E CONTEXT AND DEPENDENCY INJECTION (CDI)
174
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 
TÓPICO 4 | JAVA MESSAGE SERVICE (JMS)
175
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).
UNIDADE 3 | ENTERPRISE JAVA BEANS (EJB) E CONTEXT AND DEPENDENCY INJECTION (CDI)
176
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.
TÓPICO 4 | JAVA MESSAGE SERVICE (JMS)
177
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.
UNIDADE 3 | ENTERPRISE JAVA BEANS (EJB) E CONTEXT AND DEPENDENCY INJECTION (CDI)
178
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 temsido 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).
TÓPICO 4 | JAVA MESSAGE SERVICE (JMS)
179
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).
UNIDADE 3 | ENTERPRISE JAVA BEANS (EJB) E CONTEXT AND DEPENDENCY INJECTION (CDI)
180
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 
Tecnologias
Necessidades
(Aplicações)
Visão
(Conceitos, Princípios)
TÓPICO 4 | JAVA MESSAGE SERVICE (JMS)
181
FIGURA 2 – VIDA ÚTIL DOSFATORES DE INOVAÇÃO
Tecnologias - 1 ano
- 10 anos
- 100 anos
Necessidades
(Aplicações)
Visão
(Conceitos, Princípios)
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).
UNIDADE 3 | ENTERPRISE JAVA BEANS (EJB) E CONTEXT AND DEPENDENCY INJECTION (CDI)
182
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: . Acesso em: 12 fev. 2016.
183
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.
RESUMO DO TÓPICO 4
184
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.
185
REFERÊNCIAS
ARANGO, J. World information architecture day 2012. [S.l: s.n.], 2012. Disponível 
em: . Acesso em: 15 set. 2013. 
ASHTON, K. That “Internet of Things” Thing. RFID Journal, 22 jun. 2009. 
Disponível em: . 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: . 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: 
. Acesso em: 8 jan. 2015.
CHUI, M.; LÖFFLER, M.; ROBERTS, R. The internet of things. McKinsey 
Quarterly, v. 2, 2010 Disponível em: . 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: . Acesso em: 20 jul. 2010. 
186
EUROPEAN COMMISSION. Conclusions of the Internet of Things public 
consultation, n. 9. Brussels: [s.n.], 12 abr. 2012. Disponível em: . 
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: . Acesso em: 14 jun. 2014. 
FOWLER, Martin. ORM Hate. 2012. Disponível em: . 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: . Acesso em: 1 jan. 2013. 
GARTNER. Gartner Says the Internetof Things installed base will grow to 
26 billion units by 2020. Disponível em: . 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: . Acesso em: 15 set. 2013. 
187
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: . 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: 
. Acesso em: 20 abr. 2014. 
K19. Desenvolvimento Web Avançado com JSF 2, EJB 3.1 e CDI. 2015. 
Disponível em: . Acesso em: 15 jan. 2015.
K19. Desenvolvimento Web Avançado com JSF2, EJB 3.1 e CDI. 2013. 
Disponível em: . Acesso em 14 ago. 2015.
KENDE, M. Global Internet report. Geneva: Internet Society, 2014. Disponível em: 
. Acesso em: 28 jul. 2014. 
KLYN, D. Dutch uncles, ducks and decorated sheds: reframing IA. Baltimore, 
MD, USA: [s.n.], 2013. Disponível em: . 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: . Acesso em: 19 abr. 2014. 
188
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: . Acesso em: 30 dez. 2012. 
NEGROPONTE, Nicholas. Learning by Doing: Don’t Dissect the Frog, Build it. 
2004. Disponível em: . Acesso em: 8 ago. 2015.
NETBEANS. Netbeans IDE Features. Disponível em: . 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: 
. Acesso em: 2 ago. 2015.
 
ORACLE. Java Platform, Enterprise Edition: The Java EE 5 Tutorial. 2010. 
Disponível em: . 
Acesso em: 15 ago. 2015.
189
ORACLE. Java Platform, Enterprise Edition: The Java EE Tutorial. 2014. Disponível 
em: . 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: . 
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: . 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: . 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: . Acesso em: 20 set. 2014. 
THIAGO, André. Vantagens e desvantagens da injeção de dependências. 2010. 
Disponível em: . Acesso em: 2 jan. 2015.
190
TODD, Spangler. Netflix bandwidth usage climbs to nearly 37% of internet 
traffic on peak hours. Disponível em: . 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: . Acesso em: 20 jul. 2010. 
W3C. Ubiquitous Web Domain. W3C. [S.l: s.n.], 2010. Disponível em: . 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: . Acesso em: 28 ago. 2013. 
WEISER, M.; BROWN, J. S. The coming age of calm technology. Palo Alto: 
Xerox PARC, 1996.
191
ANOTAÇÕES
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
________________________________________________________________________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
192
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
	INTRODUÇÃO AO JAVA
	ENTERPRISE EDITION
	INTRODUÇÃO AO JAVA ENTERPRISE EDITION
	E PRINCIPAIS TECNOLOGIAS
	1 INTRODUÇÃO
	2 PRINCIPAIS TECNOLOGIAS
	2.1 A ARQUITETURA DOS CONTAINERS
	RESUMO DO TÓPICO 1
	AUTOATIVIDADE
	CONSTRUÇÃO DO AMBIENTE DE
	DESENVOLVIMENTO E EPLOYMENT
	1 INTRODUÇÃO
	1.1 INSTALAÇÃO DO SERVIDOR DE APLICAÇÃO – WILDFLY
	2 INSTALAÇÃO DO NETBEANS
	3 INTEGRAÇÃO WILDFLY-MYSQL
	4 INTEGRAÇÃO GLASSFISH-MYSQL
	RESUMO DO TÓPICO 2
	AUTOATIVIDADE
	JAVA SERVER FACES (JSF)
	1 INTRODUÇÃO
	2 CRIAÇÃO DA PRIMEIRA APLICAÇÃO
	3 CICLO DE VIDA E ESCOPOS DO JSF
	LEITURA COMPLEMENTAR
	RESUMO DO TÓPICO 3
	AUTOATIVIDADE
	COMPONENTES GRÁFICOS DO 
	JAVA SERVER FACES E JAVA PERSISTENCE API
	COMPONENTES GRÁFICOS DO JAVA SERVER FACES
	1 INTRODUÇÃO
	2 COMPONENTES DE FORMULÁRIO
	3 TABELAS
	4 SUPORTE NATIVO A AJAX
	5 ADICIONANDO UMA BIBLIOTECA EXTERNA DE COMPONENTES VISUAIS
	RESUMO DO TÓPICO 1
	AUTOATIVIDADE
	JAVA PERSISTENCE API
	1 INTRODUÇÃO
	2 MAPEAMENTO OBJETO RELACIONAL
	2.1 ARQUITETURA DO DATA ACCESS OBJECT
	3 JAVA PERSISTENCE API (JPA)
	4 CONCEITOS E INTERFACES DO JPA
	4.1 MAPEAMENTO DE ENTIDADES
	4.2 RELACIONAMENTOS ENTRE ENTIDADES
	LEITURA COMPLEMENTAR
	RESUMO DO TÓPICO 2
	AUTOATIVIDADE
	ENTERPRISE JAVA BEANS (EJB) E CONTEXT AND DEPENDENCY INJECTION (CDI)
	STATELESS SESSION BEANS
	1 INTRODUÇÃO
	2 STATELESS SESSION BEANS
	2.1 EJB 3.0
	2.2 EJB 3.1
	2.3 TESTANDO O EJB
	2.4 CICLO DE VIDA
	2.5 ESCALABILIDADE, POOL E CALL-BACKS
	2.6 MÉTODOS ASSÍNCRONOS
	RESUMO DO TÓPICO 1
	AUTOATIVIDADE
	STATEFUL SESSION BEAN E SINGLETON SESSION BEANS
	1 INTRODUÇÃO
	2 STATEFULL SESSION BEANS 3.0
	3 STATEFULL SESSION BEANS 3.1
	3.1 CICLO DE VIDA DOS STATEFULL SESSION BEANS
	3.2 CALLBACKS
	4 SINGLETON SESSION BEANS
	4.1 CICLO DE VIDA
	RESUMO DO TÓPICO 2
	AUTOATIVIDADE
	CONTEXT AND DEPENDENCY INJECTION
	1 INTRODUÇÃO
	2 PRODUCER METHODS E ATTRIBUTES
	3 EXPRESSION LANGUAGE (EL) NAME
	4 ESCOPOS E CONTEXTOS
	RESUMO DO TÓPICO 3
	AUTOATIVIDADE
	3 MODOS DE RECEBIMENTO
	RESUMO DO TÓPICO 4
	AUTOATIVIDADE
	REFERÊNCIASé 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.
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: .
IMPORTANTE
UNIDADE 1 | INTRODUÇÃO AO JAVA ENTERPRISE EDITION
6
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.
TÓPICO 1 | INTRODUÇÃO AO JAVA ENTERPRISE EDITION E PRINCIPAIS TECNOLOGIAS
7
• 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.
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.
IMPORTANTE
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.
UNIDADE 1 | INTRODUÇÃO AO JAVA ENTERPRISE EDITION
8
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.
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.
IMPORTANTE
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 
TÓPICO 1 | INTRODUÇÃO AO JAVA ENTERPRISE EDITION E PRINCIPAIS TECNOLOGIAS
9
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)
UNIDADE 1 | INTRODUÇÃO AO JAVA ENTERPRISE EDITION
10
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!
11
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.
RESUMO DO TÓPICO 1
12
1 Diferencie um servidor de aplicação de um Servlet Container.
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 anualmente 
pelos desenvolvedores. Neste contexto, 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 apresenta as sentenças CORRETAS:
a) ( ) I, II e III.
b) ( ) II e III.
c) ( ) I e III.
d) ( ) II e IV.
4 A plataforma Java possui vários frameworks, os quais possuem suas próprias 
vantagens para equipes de desenvolvimento. Além disso, aplicações JEE 
são construídas por componentes, os quais são unidades encapsuladas de 
software. Através da plataformaJava, é possível desenvolver aplicações 
robustas, e realizar persistência em bancos relacionais através do JPA. Neste 
sentido, disserte sobre o JPA.
5 A linguagem de programação Java permite o desenvolvimento de aplicações 
simples e robustas, para os mais variados tipos de dispositivos, como 
notebooks, desktops ou aplicativos de celulares. O JEE oferece vários serviços 
que facilitam o desenvolvimento de aplicações. Analise as afirmativas a 
seguir sobre o JEE:
I- Enterprise Java Beans são componentes de negócio que executam no servidor.
II- Java Server Pages são componentes que executam no servidor.
III- JTA oferece uma interface-padrão para transações.
IV- CDI representa resolução para o problema do mapeamento objeto relacional.
Agora assinale a alternativa referente ao JEE:
a) ( ) I, II e III.
b) ( ) II e III.
c) ( ) I e III.
d) ( ) II e IV.
AUTOATIVIDADE
13
TÓPICO 2
CONSTRUÇÃO DO AMBIENTE DE
DESENVOLVIMENTO E EPLOYMENT
UNIDADE 1
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.
O projeto WildFly pode ser acessado através da URL: .
NOTA
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.
UNIDADE 1 | INTRODUÇÃO AO JAVA ENTERPRISE EDITION
14
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.
TÓPICO 2 | CONSTRUÇÃO DO AMBIENTE DE DESENVOLVIMENTO E EPLOYMENT
15
FIGURA 5 - SELEÇÃO DA ABA SERVERS NO ECLIPSE
FONTE: O autor
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
UNIDADE 1 | INTRODUÇÃO AO JAVA ENTERPRISE EDITION
16
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.
TÓPICO 2 | CONSTRUÇÃO DO AMBIENTE DE DESENVOLVIMENTO E EPLOYMENT
17
FONTE: O autor
FONTE: O autor
FIGURA 8 - INSTALAÇÃO DO WILDFLY
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
UNIDADE 1 | INTRODUÇÃO AO JAVA ENTERPRISE EDITION
18
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
FONTE: O autor
FIGURA 11 - PÁGINA INICIAL DO WILDFLY EXECUTANDO EM LOCALHOST
Por fim, para testarmos se a instalação foi bem-sucedida, devemos digitar 
a seguinte URL no navegador: . 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.
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.
TÓPICO 2 | CONSTRUÇÃO DO AMBIENTE DE DESENVOLVIMENTO E EPLOYMENT
19
FONTE: O autor
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 , 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
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.
UNIDADE 1 | INTRODUÇÃO AO JAVA ENTERPRISE EDITION
20
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. 
Aprenderemosque 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.
TÓPICO 2 | CONSTRUÇÃO DO AMBIENTE DE DESENVOLVIMENTO E EPLOYMENT
21
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.
UNIDADE 1 | INTRODUÇÃO AO JAVA ENTERPRISE EDITION
22
FIGURA 16 - INTERFACE DO NETBEANS
FONTE: O autor
Tutoriais sobre o NetBeans podem ser acessados gratuitamente no endereço:
.
ATENCAO
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 
TÓPICO 2 | CONSTRUÇÃO DO AMBIENTE DE DESENVOLVIMENTO E EPLOYMENT
23
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 , 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.
UNIDADE 1 | INTRODUÇÃO AO JAVA ENTERPRISE EDITION
24
FIGURA 18 - LOCAL DO DRIVER JDBC
FONTE: O autor
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
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 
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.
TÓPICO 2 | CONSTRUÇÃO DO AMBIENTE DE DESENVOLVIMENTO E EPLOYMENT
25
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 
e a url de conexão, dentro da tag . 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
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
UNIDADE 1 | INTRODUÇÃO AO JAVA ENTERPRISE EDITION
26
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.
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: .
ATENCAO
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
TÓPICO 2 | CONSTRUÇÃO DO AMBIENTE DE DESENVOLVIMENTO E EPLOYMENT
27
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.
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.ATENCAO
UNIDADE 1 | INTRODUÇÃO AO JAVA ENTERPRISE EDITION
28
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 , sem 
esquecer de antes inicializar o servidor dentro do Netbeans.
TÓPICO 2 | CONSTRUÇÃO DO AMBIENTE DE DESENVOLVIMENTO E EPLOYMENT
29
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.
UNIDADE 1 | INTRODUÇÃO AO JAVA ENTERPRISE EDITION
30
FIGURA 26 - INICIALIZAÇÃO DO GLASSFISH
FONTE: O autor
FONTE: O autor
FIGURA 27 - INTERFACE DE ADMINISTRAÇÃO DO GLASSFISH
TÓPICO 2 | CONSTRUÇÃO DO AMBIENTE DE DESENVOLVIMENTO E EPLOYMENT
31
FONTE: O autor
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
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
FONTE: O autor
Propriedade Valor
user 
ServerName localhost
DatabaseName jee7
Password 
Url jdbc:mysql://localhost:3306/jee7
URL jdbc:mysql://localhost:3306/jee7
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). 
UNIDADE 1 | INTRODUÇÃO AO JAVA ENTERPRISE EDITION
32
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.
TÓPICO 2 | CONSTRUÇÃO DO AMBIENTE DE DESENVOLVIMENTO E EPLOYMENT
33
FIGURA 31 - CONFIGURAÇÃO DO DATASOURCE
FONTE: O autor
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: 
.
ATENCAO
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.
34
RESUMO DO TÓPICO 2
 Neste tópico você viu que:
• 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.
35
1 Com a IDE Eclipse já instalada, apresente os passos para adicionar o WildFly 
ao Eclipse?
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.
4 A linguagem de programação Java possui vários frameworks de 
desenvolvimento, cada um com sua vantagem. Neste contexto, o JSF é um 
deles, e seu funcionamento é baseado em objetos. Referente ao framework 
JSF, analise as afirmativas a seguir:
I- O JSF é baseado em objetos que são mantidos em memória no servidor.
II- O JSF é baseado em objetos que são responsáveis pela geração do HTML 
enviado ao navegador.
III- Os objetos em que o JSF se baseia, não possuem a capacidade de manter valores 
em seu estado, não permitindo sua recuperação após várias requisições.
IV- A interface da aplicação em JSF é implementada em um arquivo xHTML.
Agora assinale a alternative CORRETA:
a) ( ) I, II e IV
b) ( ) II e III
c) ( ) I, II e III
d) ( ) II, III e IV
5 Existem várias tecnologias que fazem parte da especificação JEE, porém 
para implementar e testar aplicações web JEE, é necessário um servidor de 
aplicação. Referente especificações JEE e servidores de aplicação, analise as 
afirmativas a seguir:
I- O WildFly Application Server, conhecido anteriomente como JBoss.
II- Na IDE Eclipse, servidores de aplicação são disponibilizados na guia 
“Servers”.
III- Caso as configurações do WildFly estejam originais, a aplicação é acessível 
no navegador de internet pela URL “http://localhost:8080”.
IV- A IDE NetBeans não possui o servidor de aplicação GlassFish embutido.
Agora assinale a alternativa que apresenta as sentençasCORRETAS:
a) ( ) I, II e III
b) ( ) II e III
c) ( ) I, II e IV
d) ( ) II, III e IV
AUTOATIVIDADE
36
37
TÓPICO 3
JAVA SERVER FACES (JSF)
UNIDADE 1
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: . Acesso em: 20 set. 2015.
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): 
38
UNIDADE 1 | INTRODUÇÃO AO JAVA ENTERPRISE EDITION
FIGURA 33 - ARQUITETURA DO JSF
FONTE: 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. 
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. 
TÓPICO 3 | JAVA SERVER FACES (JSF)
39
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.
FIGURA 35 - CONFIGURAÇÃO DO PROJETO
FONTE: O autor.
40
UNIDADE 1 | INTRODUÇÃO AO JAVA ENTERPRISE EDITION
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.
FIGURA 36 - APIS UTILIZADAS
FONTE: O autor.
FIGURA 37 - CONFIGURAÇÃO DO JPA
FONTE: O autor.
TÓPICO 3 | JAVA SERVER FACES (JSF)
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
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
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
UNIDADE 1 | INTRODUÇÃO AO JAVA ENTERPRISE EDITION
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 é , 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 . 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.
TÓPICO 3 | JAVA SERVER FACES (JSF)
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