JJAW

Atualizado e revisado por
ELISAMARA DE OLIVEIRA
Professor autor/conteudista
EMÍLIO CELSO DE SOUZA
É vedada, terminantemente, a cópia do material didático sob qualquer
forma, o seu fornecimento para fotocópia ou gravação, para alunos
ou terceiros, bem como o seu fornecimento para divulgação em
locais públicos, telessalas ou qualquer outra forma de divulgação
pública, sob pena de responsabilização civil e criminal.
SUMÁRIO
Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1. WEB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.1. O nascimento da www e da Internet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2. O Protocolo HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3. Servidores Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.4. Aplicações Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.4.1. Módulo web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15
1.4.2. Contexto de uma aplicação e o arquivo WEB.XML . . . . . . . . . . . . . .16
2. Configurando servidor, criando projeto, criando e executando um servlet . . . . . . 21

2.1. Configurando o servidor Apache Tomcat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.2. Criando o projeto no Eclipse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.3. Criando e executando um Servlet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3. Servlets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.1. Definição de Servlets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.2. Localização das classes de um Servlet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.3. Criação de Servlets – Até a versão 2.5 (Java EE 5.0) . . . . . . . . . . . . . . . . . . . . . . . . 35
3.4. Estrutura do Servlet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.5. Métodos do ciclo de vida de um Servlet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.6. Transferência de requisições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.7. Redirecionamento de Servlets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.8. Anotações em Servlets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.9. Considerações sobre mapeamento do Servlet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.10. ServletConfig . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.11. ServletContext . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4. Sessão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.1. Definição de gerenciamento de sessão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.2. Modelo do controle de sessão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.3. A classe HttpSession . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.4. Campos ocultos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.5. Reescrita de URL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.6. Escopo de armazenamento de dados na memória do servidor . . . . . . . . . . . . . . . 49
5. Java Server Pages (JSP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

5.1. Definição de JSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.2. Arquitetura JSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6. Diretivas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
6.1. Diretiva page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
7. Formulários . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
8. Definição de objetos implícitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
9. Declarações de variáveis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
10. Expressões ou ScriptLets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
11. Ações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
12. Passando parâmetros para uma página JSP via URL . . . . . . . . . . . . . . . . . . . . . . . 59
13. Bean . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
14. Valores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
14.1. Atribuindo valores para as propriedades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
14.2. Obtendo valores das propriedades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
15. Definição de JSTL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
16. Expression Language (EL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
17. Bibliotecas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
17.1. Bibliotecas de tags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
17.2. Biblioteca Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
17.3. Biblioteca Sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
17.4. Biblioteca Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
17.5. Biblioteca XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
18. Definição de JSF e Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
19. JSF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
19.1. A arquitetura MVC (Model–View–Controller) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
19.2. O MVC de JSF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
19.3. Exemplo de uma aplicação JSF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
19.4. Tags JSF Fundamentais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
19.5. Principais Tags HTML JSF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
20. Beans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
20.1. Anotações em beans gerenciáveis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
20.2. Escopos de beans gerenciáveis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
21. Navegação condicional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

21.1. Elementos do JSF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
22. Fases do ciclo de vida do JSF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
23. Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

23.1. ValueChange Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
23.2. Action Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
23.3. Phase Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
24. Criando uma classe Phase Listener . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
25. Conversão de números, datas e textos em JSF . . . . . . . . . . . . . . . . . . . . . . . . . . 105

25.1. Uso de propriedades e o arquivo de propriedades . . . . . . . . . . . . . . . . . . . . . . . . 105
26. Definição de web services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
27. SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

27.1. Definição de SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
27.2. Estrutura de um arquivo SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
27.3. Atributos SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
28. WSDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

28.1. Definição de WSDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
28.2. Estrutura WSDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
28.3. WSDL ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
29. Bindings SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

29.1. Definição de JAX-WS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
30. Vinculando WSDL a Java com JAXB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
31. Processamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

31.1. Processamento Síncrono . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
31.2. Processamento Assíncrono . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .124
31.2.1. Exemplo de chamada assíncrona . . . . . . . . . . . . . . . . . . . . . . 124
Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Glossário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Referências . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
INTRODUÇÃO
Iremos realizar a investigação de outra vertente importante do mundo Java: os conceitos de
Java web. Para tanto, torna-se imprescindível um bom conhecimento e domínio do que foi estudado
até a disciplina que trata do Java SE avançado.
Estudaremos os conceitos de desenvolvimento web em Java, incluindo o mecanismo de requisição

e resposta, os componentes que são executados no servidor, como a resposta é entregue ao cliente,
além dos detalhes de como escrever códigos para os dois lados: cliente e servidor.
Aqui, cliente é o browser e servidor é o local em que a aplicação está hospedada. Por exemplo,
suponha que você deseja acessar o site do banco no qual você mantém uma conta corrente. O
acesso é realizado a partir de um navegador através de uma interface gráfica desenhada, na sua
maior parte, por HTML. Essas informações são enviadas a um servidor, que as recebe e as processa,
gerando uma resposta que pode ser um extrato, um comprovante de pagamento, dentre outras.
Em muitos casos, os sistemas necessitam de informações de outro sistema, geralmente

desenvolvido em outra linguagem. Para esse tipo de acesso são necessários os web services, ou
seja, elementos que trocam informações com outros sistemas externos sem se importarem em
qual plataforma esses sistemas foram desenvolvidos.
Além dos conceitos da linguagem Java, o mecanismo de acesso ao banco de dados é fundamental
nesse contexto web. O banco de dados pode fazer parte do mesmo servidor em que a aplicação
web está hospedada, ou em outro servidor, exclusivo para os dados.
Uma grande quantidade de códigos nos exercícios será proposta, pois não se trata mais de
simples programas escritos em uma única classe, mas de diversas classes e códigos HTML,
interagindo entre si.
Pág. 6 de 130
1. WEB
1.1. O nascimento da www e da Internet

O conceito de internet surgiu nos anos 1960 e início da década de 1970 quando se vivia o auge
da Guerra Fria e os laboratórios militares americanos sentiam a necessidade de compartilhar de
forma segura informações sigilosas, armazenadas em computadores espalhados pelo país, a fim
de evitar que um ataque nuclear soviético interrompesse essa comunicação. Foi criada, então, uma
rede de comunicação militar interligando esses computadores, um esquema para a transmissão
foi desenvolvido no qual as informações seriam divididas em pacotes. Esses pacotes tomariam
caminhos diferentes para chegar ao mesmo local. Caso um trecho de comunicação fosse destruído,
os pacotes pegariam outro caminho e chegariam ao mesmo destino. Foi assim que surgiu a ARPANET,
o antecessor da Internet.
Saiba Mais
ARPANET, em inglês ,de Advanced Research Projects Agency Network (ARPANET) do Departamento
de Defesa dos Estados Unidos, foi a primeira rede operacional de computadores à base de comutação
de pacotes, e o precursor da Internet foi criada só para fins militares.
A ARPANET ou ARPANet foi, pode-se dizer, a “mãe” da internet. Desenvolvida pela agência
Americana ARPA em 1969, tinha o objetivo de interligar as bases militares e os departamentos de
pesquisa do governo americano. Esta rede teve o seu berço dentro do Pentágono e foi batizada
com o nome de ARPANET No início da década de 1970, universidades e outras instituições que
faziam trabalhos relacionados com a defesa, tiveram permissão para se conectarem à ARPANet e
em meados de 1975 existiam aproximadamente 100 sites. Pesquisadores que trabalhavam
na ARPANet estudaram como o crescimento da rede alterou o modo como as pessoas a utilizavam.
No final dos anos 70, a ARPANet tinha crescido tanto que o seu protocolo de comutação de
pacotes original, chamado Network Control Protocol (NCP), tornou-se inadequado. Foi então que
a ARPANet começou a usar um novo protocolo chamado TCP/IP. Fonte: https://pt.wikipedia.org/wiki/
ARPANET
Do âmbito militar o projeto passou para o campo acadêmico com o objetivo de:
[...] coligar universidades para que fosse possível uma transmissão de dados de
forma mais eficaz, rápida e segura. No Brasil, a internet iniciou no final da década de
1980 quando no Laboratório Nacional de Computação Científica (LNCC), localizado
no Rio de Janeiro, conseguiu acesso à Bitnet, através de uma conexão de 9 600 bits
por segundo, estabelecida com a Universidade de Maryland (TOTALIZE, 2014).
Com o surgimento da WWW (World Wide Web) na década de 1990, a Internet avançou rapidamente
alcançando quase todos os países do planeta, disseminando e interligando informações e pessoas
por todo o mundo (MULLER, 2011).
Pág. 7 de 130
1.2. O Protocolo HTTP
Saiba Mais
Podemos definir “HTTP” da seguinte forma:
HTTP - Hyper Text Transfer Protocol é um protocolo de comunicação utilizado para transferência de
páginas HTML do computador para a WWW na Internet. Por isso, os endereços dos websites (URLs)
utilizam no início a expressão “http://”, definindo o protocolo usado.
Esta informação é necessária para estabelecer a comunicação entre a URL e o servidor Web que
armazena os dados, enviando então a página HTML solicitada pelo usuário. Fonte: adpatado de
<http://www.significados.com.br/http/>.
O funcionamento do protocolo HTTP pode ser visto na figura 1, possui as características:
• Baseado em Request-Response;
• Cliente abre conexão e envia request para o servidor;
• Cliente recebe response e fecha conexão;
• Comunicação sem estado (stateless);
• Para o servidor cada request é o primeiro request enviado pelo cliente;
• Cada recurso é identificado por um exclusivo Uniform Resource Identifier (URI);
• URL (Uniform Resource Locator) são URIs que especificam protocolos de Internet (HTTP,
FTP, mailto);
Figura 1 – Mecanismo de requisição e resposta

HTTP REQUEST
HTML. Javascript. PHP, MySQL &

Flash processed other server-side
and run languages
processed,
generates HTML
HTTP RESPONSE & CSS as output.
CLIENT SERVER
(Web page, imaes, JavaScript etc)
Fonte: http://www.wonko.info/ipt/sse/php/server-side.jpg
Pág. 8 de 130
Aconteceu
Coordenado pela World Wide Web Consortium e a Internet Engineering Task Force, culminou na
publicação de uma série de Requests for Comments; mais notavelmente o RFC 2616, de junho de
1999, que definiu o HTTP/1.1. Em junho de 2014 foram publicados 6 RFCs para maior clareza do
protocolo HTTP/1.1. Em março de 2015, foi divulgado o lançamento do HTTP/2. A atualização deixará
o navegador com um tempo de resposta melhor e mais seguro. Ele também melhorará a navegação
em smartphones. Fonte: https://pt.wikipedia.org/wiki/Hypertext_Transfer_Protocol
As partes de uma mensagem HTTP são:
• Linha inicial: Especifica o propósito da mensagem ou response;

• Seção Header: Especifica meta-informações, tais como tamanho, tipo e encoding, sobre o
conteúdo da mensagem;
• Linha em branco;
• Corpo da mensagem;
• O conteúdo principal do request ou reponse.
A primeira linha de um HTTP request tem três partes, separadas por espaço:
• Nome do método;
• O path do recurso solicitado (URI);
• A versão do HTTP sendo utilizado.
Os métodos do protocolo HTTP são:
• Método GET (GET /hello/HelloApp?userid=Joao HTTP/1.1): Obtém informações do servidor –

usualmente um documento – especificando qual documento e eventuais parâmetros através
de um URI (Universal Resource Identifier). O método GET é usado para requisitar informações
do servidor, mas pode ser empregado no envio de um conjunto dos dados do formulário junto
com a URL (endereço e nome da aplicação especificada pelo atributo action). Os dados são
separados da URL pelo caracter “?” e são agrupados por nome e valor, separados entre si pelo
caracter “&”.
• Método HEAD: Obtém informações sobre um determinado documento no servidor, mas não
necessariamente o documento em si.
• Método POST (PUT /hello/HelloServlet HTTP/1): Envia informações para o servidor processar
ou armazenar. O método POST envia o conjunto de dados do formulário para a aplicação
que irá fazer o tratamento como um bloco de dados separado da requisição. Esse método é
utilizado quando o bloco de dados ultrapassa o tamanho máximo da URL ou quando não é
seguro anexar os dados no final da URL.
Pág. 9 de 130
• Método OPTIONS: Por meio desse método, o cliente obtém as propriedades do servidor.
• Método DELETE: Informa por meio do URL o objeto a ser deletado.
• Método TRACE: Para enviar mensagem do tipo loopback para teste.
• Método PUT: Aceita criar ou modificar algum objeto do servidor.
• Método CONNECT: Comunicar com servidores Proxy. Os dois principais métodos do request
são GET e POST.
A passagem de parâmetros é realizada como mostra o quadro 1, e é ilustrado na figura 2.
Quadro 1: Requisição a um recurso web via URL
http://localhost:1234/hello/HelloServlet?userid=10&nome=Ze
Fonte: elaborado pelo autor
• Cada parâmetro tem um identificador, seguido pelo sinal de igual e valor;

• Cada par parâmetro/valor é separado pelo caracter &;
• Todos os parâmetros são separados da URL através do caracter ? (somente quando utilizado
GET);
• Toda URL é case sensitive.
Figura 2 – Passagem de parâmetro via método GET
http://localhost:8080/myapp/LoginServlet?login=jose&senha=1234
Login jose
Senha 1234
Enviar <FORM action=”LoginServlet”>
Login<INPUT type=”text” name=”login”>
Senha<INPUT type=”text” name=”senha”>
<INPUT type=”submit” name=”enviar”>
</FORM>
Fonte: elaborada pelo autor
O método GET é ilustrado na figura 3:
• Envia dados através da URI;

• É menos seguro;
• Pode navegar dados de um site para outro.
Pág. 10 de 130
Figura 3 – Cabeçalho do método GET
O método POST é ilustrado na Figura 4:
• Envia dados através do fluxo da requisição;

• É mais seguro;
• Dados navegam somente no mesmo contexto.
Figura 4 – Cabeçalho do método POST
1.3. Servidores Web

Servidores Web são softwares que ficam em execução em uma máquina permanentemente
conectada à Internet, preparados para se comunicar usando o protocolo TCP/IP. Ficam monitorando
uma porta (usualmente a porta 80) em um ou mais endereços IP, aguardando conexões. Ao receber
Pág. 11 de 130
uma conexão, o servidor analisa os dados recebidos através da conexão, em busca de uma requisição
HTTP, e então processa a requisição e, por meio da mesma conexão, retorna o resultado.
O servidor (no nosso caso, o Tomcat ou o GlassFish) recebe informações do browser, processa
as informações e retorna uma resposta no formato HTML para o cliente (browser), como mostra
a figura 5.
Figura 5 – Requisição e resposta
Requisição (request)
Internet
Cliente Resposta (response) Servidor
No servidor existe uma estrutura de diretórios devidamente configurada. O acesso externo

(cliente) aos arquivos nas pastas desse diretório é realizado através de uma URL, definida para
apontar para aquela estrutura de pastas. A figura 6 ilustra este processo.
Figura 6 – Requisição e resposta – cliente e servidor em diferentes computadores
Local Disk (C:)
Aplicacao
web
Cliente Servidor
http://www.sitequalquer.com/index.html
ou IP: 200.69.188.18
http://200.69.188.18/index.html Arquivo “index.html” na pasta web
Pág. 12 de 130
É comum, para fins de testes ou de desenvolvimento, executar um programa no servidor, sendo
o servidor o próprio computador cliente. Ou seja, não é necessário ter uma infraestrutura complexa
para testar uma aplicação, como mostra a figura 7.
Figura 7 – Requisição e resposta – cliente e servidor no mesmo computador
http://127.0.0.1:8000/index.html (LAN) Local Disk (C:)
http://200.69.188.18:8080/index.html Aplicacao
(internet) web
http://localhost:8080/index.html
(cliente e servidor no mesmo computador)
IP: 20
Arquivo “inde
Browser Servidor
Atividade reflexiva
Reflita e discuta com seus colegas sobre a facilidade e os usos das máquinas virtuais para testes, já
que através delas é possível emular diversos ambientes e condições.
1.4. Aplicações Web

Há dois tipos de aplicações web:
• Orientadas à apresentação: Páginas interativas contendo linguagens tais como HTML, XML,
DHTML, XHTML etc .
• Orientadas aos serviços: Acesso aos serviços externos, como os web services.
Na plataforma Java, componentes web fornecem funcionalidades dinâmicas para um servidor

web. Os componentes web são:
• Java Servlets;
• Páginas JSP;
• Web services.
Pág. 13 de 130
A iteração entre o cliente e o servidor ocorre de acordo com os passos descritos a seguir:
1. O cliente envia uma requisição HTTP para o servidor.

2. O servidor converte a requisição para um objeto HttpServletRequest.
3. O componente web recebe o HttpServletRequest e interage com componentes JavaBeans.
4. Os componentes JavaBeans interagem com um banco de dados para gerar o conteúdo
dinâmico.
5. O conteúdo dinâmico é processado e um HttpServletResponse é gerado.
6. Servidor web converte HttpServletResponse para uma resposta HTTP e a retorna para o
cliente web.
Esses passos estão ilustrados na Figura 8.
Figura 8 – Requisições em aplicações web
1
Web HttpServlet
2 4
Client HTTP
Request Web
Componentes
Request
3
5 Database
6
HttpServlet
Response Web
HTTP Componentes
Response
Database
Fonte: http://docs.oracle.com/javaee/6/tutorial/doc/geysj.html
As aplicações web essencialmente são constituídas por Servlets e páginas JSP:
• Servlets: São classes Java que processam requisições dinamicamente e constroem a resposta.
Recomendados para controlarem a camada de apresentação (controller) de aplicações
orientadas à apresentação e para implementar serviços em aplicações orientadas aos serviços
(web services são normalmente implementados como Servlets).
• Páginas JSP: Documentos texto que são executados como Servlets. Recomendadas para
páginas baseadas em HTML, WML, DHTML, Web Designers.
Pág. 14 de 130
Mesmo alguns frameworks, como JavaServer Faces ou Struts, são constituídos por Servlets.
Todos os componentes web devem estar dentro de um web container. Um web container fornece
serviços tais como:
• Encaminhamento de requests (request dispatching);

• Segurança;
• Acesso concorrente;
• Gerenciamento do ciclo de vida dos componentes web;
• Controle de transações;
• E-mail;
• etc.
Componentes Web (Servlets, JSPs) e componentes estáticos (imagens, arquivos) são chamados
de recursos web que devem ser empacotados dentro de um módulo web. Um módulo web é a menor
unidade que pode ser instalada (deployed) em um servidor web. Um módulo web corresponde a
uma aplicação web.
1.4.1. Módulo web
Um módulo web possui uma estrutura específica. O diretório inicial é a raiz da aplicação, em
que JSPs, applets, classes utilitárias e recursos estáticos (html, imagens) são armazenados.
O módulo web possui um subdiretório chamado WEB-INF, no qual são armazenados:
• web.xml – Descritor da aplicação;

• tld – Tag library descriptor;
• classes servidoras – Servlets, javabeans etc.;
• lib – Diretório que contém jar’s de bibliotecas.
A Figura 9 ilustra a estrutura de um módulo web.
Pág. 15 de 130
Figura 9 – Estrutura do módulo web
Assembly Root
WEB-INF
lib classes
Web pages
web.xml
glassfish-web.xml
(optional)
All server-side
.class files for this
web module
Library archive
files
Fonte: http://docs.oracle.com/javaee/6/tutorial/doc/bnadx.html
Se a sua aplicação não possui nenhum Servlet, filtro ou Listener, então não precisa de um
descritor web.xml. Um módulo web pode ser instalado (deployed) com um pacote WAR ou como
uma estrutura de diretórios e arquivos desempacotados.
1.4.2. Contexto de uma aplicação e o arquivo WEB.XML
Cada aplicação possui seu próprio contexto, que consiste em um espaço em memória e em
disco reservado para cada aplicação e uma área exclusiva para cada aplicação.
• No disco, o contexto recebe o nome da própria aplicação, o pacote .war ou o nome da pasta
inicial (root) da aplicação.
• Cada aplicação possui acesso somente ao seu próprio contexto.
• Dentro do contexto podem ser armazenados parâmetros e atributos visíveis por todos os
componentes, independenteemente de sessão de usuário.
• Um contexto é implementado pelo container através da interface javax.Servlet.ServletContext
A Figura 10 mostra um exemplo de um contexto.
Pág. 16 de 130
Figura 10 – Estrutura do módulo web – diretórios
nome-do-contexto
WEB-INF
classes
lib
web.xml
Quando criamos um novo projeto web, de uma forma geral o nome do projeto representa o nome
do contexto, embora seja possível alterar esse nome.
O contexto é representado por um arquivo XML presente em uma pasta específica do servidor,
com as informações de localização da aplicação. Os passos para definição do contexto são:
• Definir a estrutura de pastas no servidor;

• Escolher um nome adequado para o contexto;
• Escrever um arquivo xml, com o mesmo nome do contexto;
• Salvar o arquivo na pasta [TOMCAT_HOME]/conf/Catalina/localhost.
Exemplo:
• Estrutura de pastas: C:\Aplicacao\web

• Nome do contexto: app
• Nome do arquivo: app.xml
• Conteúdo do arquivo app.xml:
Quadro 2 - Configuração de um contexto no servidor
<?xml version=”1.0” encoding=”ISO-8859-1” ?>

<Context path=”\app” docBase=”C:/Aplicacao/web” />
Pág. 17 de 130
O acesso a um arquivo (HTML, JSP etc.) localizado no nosso novo contexto é acessado, então,
da seguinte forma:
Arquivo: início.jsp
Pasta: C:\Aplicacao\web
Contexto: app
Quadro 3 - Acesso a um recurso web usando o contexto configurado
http://localhost:8080/app/início.jsp
Existe um arquivo web.xml para cada contexto definido para as aplicações. Este arquivo é
chamado de descritor de implantação do aplicativo Web e deve estar na pasta WEB-INF.
No exemplo da estrutura de pasta anterior, o arquivo servirá para as páginas JSP usadas na
aplicação e para as classes referentes aos Servlets.
Atenção: Caso contenha algum erro de descrição do XML a aplicação não será iniciada.
Esse arquivo era obrigatório para uma aplicação web até a versão 2.5 do Servlet. A partir do
Servlet 3.0 (JEE 6.0), a maior parte das configurações dispensa o uso desse arquivo.
As partes do arquivo são descritas no que se segue.
O quadro 4 configura parâmetros para o contexto da aplicação.
Quadro 4 - Configuração de um parâmetro de contexto
<context-param>
<param-name>qtd</param-name>
<param-value>1</param-value>
</context-param>
O Quadro 5 configura um Servlet, criando também um parâmetro de inicialização (Servlet 2.5

e anterior).
Pág. 18 de 130
Quadro 5 - Configuração de um parâmetro de Servlet
<Servlet>
<Servlet-name>Cadastrar</Servlet-name>
<Servlet-class>com.ead.Servlet.Cadastrar</Servlet-class>
<init-param>
<param-name>tipo</param-name>
<param-value>2</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</Servlet>
Quadro 6 - Configuração do mapeamento de um Servlet (Servlet 2.5 e anterior)
<Servlet-mapping>
<Servlet-name>Cadastrar</Servlet-name>
<url-pattern>/Cadastrar</url-pattern>
</Servlet-mapping>
Quadro 7 - Configuração do tempo de vida de um Servlet (timeout de sessão do usuário)
<session-config>
<session-timeout>60</session-timeout >
</session-config>
Quadro 8 - Configuração de página de erro padrão para uma aplicação
<error-page>
<error-code>404</error-code>
<location>/erro.jsp</ location>
</error-page >
Quadro 9 - Configuração da página inicial de uma aplicação (as páginas serão chamadas automaticamente ao
chamar o contexto)
<welcome-file-list>
<welcome-file>index.jsp</welcome-file>
</welcome-file-list>
Pág. 19 de 130
No material complementar a tabela 1 apresenta uma breve descrição das principais tags usadas
no arquivo web.xml.
A tabela 2 traz os principais códigos de erro usados como conteúdo de <error-code> (elemento
filho de <error-page>).
Um exemplo completo do descritor de aplicativo está mostrado no quadro 10.
Quadro 10 - Exemplo de um arquivo web.xml
<?xml version=”1.0” encoding=”UTF-8”?>

<web-app xmlns=”http://java.sun.com/xml/ns/j2ee”
xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”
xsi:schemaLocation=”http://java.sun.com/xml/ns/j2ee
http://java.sun.com/xml/ns/j2ee/web-app_2_5.xsd”
version=”2.5”>
<Servlet>
<Servlet-name>Servlet01</Servlet-name>
<Servlet-class>ead.si.Servlet01</Servlet-class>
<init-param>
<param-name>titulo</param-name>
<param-value>JSP</param-value>
</init-param>
</Servlet>
<Servlet-mapping>
<Servlet-name>Servlet01</Servlet-name>
<url-pattern>/portalead</url-pattern>
</Servlet-mapping>
<session-config>
<session-timeout>30</session-timeout>
</session-config>
<error-page>
<error-code>404</error-code>
<location>/erro404.jsp</location>
</error-page >
<welcome-file-list>
</web-app>
Pág. 20 de 130
2. CONFIGURANDO SERVIDOR, CRIANDO PROJETO, CRIANDO E
EXECUTANDO UM SERVLET
2.1. Configurando o servidor Apache Tomcat

Para criar um um projeto web no Eclipse, será necessário um servidor de aplicações para hospedar
nossas aplicações e escolheremos o servidor Tomcat por ser suficiente para nossos propósitos,
além de ser bastante leve. Esse servidor deve ser obtido por download no site <http://tomcat.apache.
org/>. A figura 11 mostra a página na qual o download deve ser realizado. Nesta página, você deve
selecionar Tomcat 7.0 no menu do lado esquerdo.
Figura 11 - Portal do Apache Tomcat
Fonte: https://tomcat.apache.org/
Clicando na opção Tomcat 7.0 chegamos às opções de download, conforme mostrado na figura
12. Escolher a opção “zip” indicada.
Pág. 21 de 130
Figura 12 - Opções de download do Tomcat
Fonte: http://tomcat.apache.org/download-70.cgi
Esse arquivo deve ser descompactado em uma pasta de sua preferência. Nesta disciplina
usaremos a pasta C:\Servidor como local para o servidor. Vamos descompactar o arquivo apache-
tomcat-7.0.42.zip nesta pasta, resultando em C:\Servidor\apache-tomcat-7.0.42.
2.2. Criando o projeto no Eclipse

Para criarmos um projeto web no Eclipse temos de manter a perspectiva Java EE. Com essa
perspectiva criamos um projeto “Dynamic Web Project”. A figura 13 ilustra esse procedimento.
Figura 13 - Procedimento para criação de um projeto Java Web
Pág. 22 de 130
Ao selecionar esta opção, seguimos os passos descritos a seguir. É importante ficar atento aos
passos a fim de evitar falhas no projeto.
Na figura 14, temos as opções do projeto, em que informamos um nome para ele e, em seguida,
selecionamos o servidor de aplicações clicando no botão “New Runtime...”.
Figura 14: Definição do projeto
Pág. 23 de 130
Clicando no botão “New Runtime...” abrimos a janela para seleção do servidor, conforme
mostrado na Figura 14. Como estamos trabalhando com a versão 7.0 do Tomcat, selecionamos a
opção indicada na figura 15 para que o Eclipse reúna as configurações adequadas para essa versão.
Figura 15: Seleção do servidor de aplicações
Clicando em “Next” obtemos uma nova janela na qual indicamos a pasta de instalação do Tomcat
e a versão do JRE. A figura 16 mostra essas informações devidamente configuradas.
Pág. 24 de 130
Figura 16 - Configuração do servidor
Ao finalizar esta configuração devemos selecionar a versão do módulo web. Módulo web está
relacionado à versão do Servlet a ser utilizada no projeto. Para os componentes que necessitam
de configurações fora do Servlet, este arquivo ainda se faz necessário. Por isso, vamos mantê-lo
no projeto. A figura 17 mostra a seleção da versão, e para este exemplo manteremos a versão 3.0.
Pág. 25 de 130
Figura 17 - Seleção da versão do módulo web
Clicamos em Next até chegarmos à configuração mostrada na figura 18. Nesta tela
marcamos a opção “Generate web.xml deployment descriptor”. Depois clique em Finish e
nosso projeto está pronto.
Pág. 26 de 130
Figura 18 - Procedimento para criação de um projeto Java Web
2.3. Criando e executando um Servlet

Para ilustrar a criação do nosso primeiro componente web, iniciaremos com o Servlet. Vamos
seguir os passos indicados:
1. Clique com o botão direito do mouse sobre o projeto, e selecione Servlet (Figura 19):
Figura 19 - Procedimento para inclusão de um Servlet
Pág. 27 de 130
2. Forneça o pacote e o nome da classe conforme indicado na figura 20:
Figura 20 - Configuração do Servlet (Classe e pacote)
Fonte: elaboarada pelo autor
Pág. 28 de 130
3. No próximo passo defina o nome para o Servlet (não precisa ser o mesmo nome que a classe).
Defina o mapeamento (url pattern) como “/exemplo”. Para alterar o nome do mapeamento,
selecione-o na janela e clique em “Edit...” (vide Figura 21):
Figura 21 - Configuração do Servlet (nome e mapeamento)
Pág. 29 de 130
4. Clique em “Finish”. Observe que o Eclipse cria uma nova classe chamada ServletExemplo.
Nesta classe existem diversos comentários. Para tornar o código mais limpo, vamos remover
estes comentários, deixando a classe da forma mostrada na figura 22:
Figura 22 - Classe ServletExemplo, representativa do Servlet
Pág. 30 de 130
5. Observe que a classe foi criada com dois métodos: doGet() e doPost(). Escreva o código
indicado na figura 23 no método doGet() (os detalhes serão apresentados em módulos
posteriores):
Figura 23: Método doGet() da classe ServletExemplo
6. Para visualizar a execução, selecione o ícone de execução, clique na seta à direita e, em

seguida, clique na opção “Run on Server”, conforme figura 24:
Figura 24 - Execução da aplicação
Pág. 31 de 130
7. Aceite as opções seguintes. Você verá o resultado da aplicação no browser embutido no
Eclipse, conforme figura 25:
Figura 25 - Browser interno do Eclipse com o resultado
8. Para visualizar o resultado no seu browser preferido, altere a opção no menu Window,
conforme indicado na figura 26:
Figura 26 - Configuração do Browser no Eclipse
Fonte: Autoria própria
Pratique o que você aprendeu até agora com os exercícios no arquivo anexo!
Pág. 32 de 130
3. SERVLETS
3.1. Definição de Servlets

Servlets são classes Java derivadas da classe HttpServlet. Sua instanciação ocorre pelo web
container, e no container existe apenas uma instância. Havendo mais de uma requisição, o container
cria múltiplas threads para as requisições que ele recebe através do protocolo HTTP.
Servlets não possuem interface gráfica e suas instâncias são executadas dentro de um ambiente
Java denominado container. Isso significa que elas evitam todos os problemas de portabilidade
associados às diferentes interfaces de exibição.
O container gerencia as instâncias dos Servlets e provê os serviços de rede necessários para
as requisições e respostas. O container atua em associação com servidores Web recebendo as
requisições reencaminhada por eles.
Tipicamente existe apenas uma instância de cada Servlet, no entanto, o container pode criar
vários Servlets (múltiplas linhas de execução), como mostra a figura 27.
Figura 27 - Requisições simultâneas a um Servlet
Request
cliente web Thread
Request Thread
cliente web
Thread Servlet
Request
cliente web
Thread
Request
cliente web
Depois de executado, um Servlet em geral residirá na memória do servidor. Isso evita a sobrecarga
da construção de um novo processo de Servlet para cada acesso, economiza memória e torna
Pág. 33 de 130
o acesso à página eficiente. Como os Servlets permanecem na memória, eles podem manter
referências a outros objetos Java.
Por exemplo, se seu servidor de banco de dados contém licenças de conexão simultânea
suficientes, uma conexão a banco de dados pode ser compartilhada entre as linhas de execução,
reduzindo assim a sobrecarga associada ao estabelecimento e manutenção da conexão. O esquema
de execução de um Servlet está ilustrado na figura 28:
Figura 28 - Esquema de requisição a um Servlet
Solicitação
browser Servidor HTTP
Contêiner SERVLET
SERVLET
Documento HTML
Resposta
3.2. Localização das classes de um Servlet

Conforme descrito no capítulo anterior, as classes correspondentes a um Servlet devem ser
colocadas na pasta classes ou na pasta lib, conforme esteja ou não definida em um arquivo.jar,
ambas abaixo da pasta WEB-INF.
Pág. 34 de 130
3.3. Criação de Servlets – Até a versão 2.5 (Java EE 5.0)
Quando o Servlet estava na versão 2.5, correspondendo ao JEE 5, o Servlet usava o arquivo de
configurações web.xml para definir suas configurações. O quadro 11 apresenta a classe que define
um Servlet.
Quadro 11 - Classe ServletExemplo01, representando um Servlet
package com.Servlet;
import java.io.IOException;
import javax.Servlet.ServletException;
import javax.Servlet.http.HttpServlet;
import javax.Servlet.http.HttpServletRequest;
import javax.Servlet.http.HttpServletResponse;
public class ServletExemplo01 extends HttpServlet {
@Override
protected void doGet(HttpServletRequest request,
HttpServletResponse response)
throws ServletException, IOException {
}
@Override
protected void doPost(HttpServletRequest request,
}
}
Pág. 35 de 130
O Quadro 12 apresenta o Deployment Descriptor (web.xml).
Quadro 12 - Arquivo web.xml para o Servlet ServetExemplo01

<web-app version=”2.5” xmlns=”http://java.sun.com/xml/ns/
javaee” xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”
xsi:schemaLocation=”http://java.sun.com/xml/ns/javaee http://java.sun.
com/xml/ns/javaee/web-app_2_5.xsd”>
<Servlet>
<Servlet-name>ServletExemplo01</Servlet-name>
<Servlet-class>com.Servlet.ServletExemplo01</Servlet-class>
</Servlet>
<Servlet-mapping>
<Servlet-name>ServletExemplo01</Servlet-name>
<url-pattern>/exemplo01</url-pattern>
</Servlet-mapping>
<session-config>
<session-timeout>
30
</session-timeout>
</session-config>
<welcome-file-list>
</web-app>
3.4. Estrutura do Servlet

Os pacotes javax.Servlet e javax.Servlet.http definem as interfaces e classes para implementação
de Servlets. O mais usual é criar uma classe que estenda à classe javax.Servlet.http.HttpServlet.
A classe javax.Servlet.http.HttpServlet fornece métodos, tais como: doGet() e doPost() para

tratar serviços HTTP.
Para cada método HTTP há um método correspondente na classe HttpServlet do tipo:
public void doXXX(HttpServletRequest, HttpServletResponse) throws

ServletException, IOException {}
Pág. 36 de 130
doXXX() depende do método HTTP, conforme o esquema:
Método HTTP Método HttpServlet
GET doGet()
POST doPost()
3.5. Métodos do ciclo de vida de um Servlet

A hierarquia de classes ilustrada na Figura 29 mostra a sequência de eventos HttpServlet.
Observe que o Servlet que criamos possui os métodos doGet() e doPost() sobrescritos, e estes são
chamados pelo método service(). O método service() é responsável pelo ciclo de vida do Servlet.
Ele reconhece a requisição e decide por chamar doGet() ou doPost().
Figura 29 - Hierarquia de classes para um Servlet
HTTP request
Servlet
service(ServletRequest req. ServletResponse resp)
GenericServlet
service(ServletRequest req. ServletResponse resp)
HttpServlet
service(HttpServletRequest req. ServletResponse resp)
MeuServlet
doGet(...) doPost...)
O ciclo de vida de um Servlet é controlado pelo container. A classe HttpServlet fornece métodos
para controle do ciclo de vida do Servlet pelo container, como:
• init()
• destroy()
• service()
Pág. 37 de 130
Se o método service() for sobrescrito, os métodos doXXX() não serão chamados.
A figura 30 ilustra o ciclo de vida do Servlet.
Figura 30 - Ciclo de vida de um Servlet
Request
Não Existe Sim

instância?
Crie uma
instância do Localiza
servlet instância já
Container
inicializada
Chama
método init()
Chama
método
service()
Todos os métodos doXXX() recebem dois parâmetros, ambos criados pelo container e passados
para o Servlet como argumentos:
• HttpServletRequest: Define um objeto que fornece informações do request HTTP para o Servlet.
Provê dados, tais como parâmetros e valores enviados pelo browser, atributos e streams de
entrada, informações sobre o protocolo, endereço IP do cliente etc. Ele estende a interface
ServletRequest.
• HttpServletResponse: Define um objeto que permite ao Servlet enviar resposta ao cliente web.
Permite definir atributos no header HTTP e criar cookies. Ele estende a interface ServletResponse.
Cheque os materiais complementares para conhecer os principais métodos de requisição. Eles

estão descritos na tabela 3.
Pág. 38 de 130
3.6. Transferência de requisições
O Servlet pode receber uma requisição e transferir seu conteúdo para outro componente,
mantendo a execução (o controle) na Servlet atual. Este processo é usado normalmente quando
se deseja incluir e/ou remover atributos na requisição e transferi-la para outro recurso utilizá-la. O
mecanismo de transferência pode ocorrer de duas formas:
• enviando a requisição para um recurso externo (forward);

• recebendo a requisição de um recurso externo (include).
A Figura 31 ilustra esse procedimento.
Figura 31 - Transferência de requisições
Servlet A
Servlet B
request.getRequestDispatcher(”ServletB”).forward(req,resp)
CLIENTE WEB
Servlet A Servlet B
request.getRequestDispatcher(”ServletB”).include(req,resp)
CLIENTE WEB
Cheque os materiais complementares para conhecer os principais métodos de requisição. Eles

estão descritos na tabela 4.
3.7. Redirecionamento de Servlets

Ao contrário da transferência de requisições, o redirecionamento abandona o recurso atual e
executa, via método GET, o novo recurso. Esse processo equivale a realizar uma chamada ao novo
recurso através da URL. Exemplo:
response.sendRedirect(“cadastro”);
Neste exemplo, “cadastro” representa o mapeamento do Servlet destino.
Pág. 39 de 130
3.8. Anotações em Servlets
A versão 3.0 do Servlet corresponde ao Java EE 6.0 e incluiu algumas funcionalidades, além de
dispensar o uso do arquivo de configurações web.xml.
Para ilustrar, considere um Servlet chamado ServletLogin, contendo como parâmetros de

inicialização: usuario e senha, conforme mostra o quadro 13.
Quadro 13 - Classe ServletLogin representando um Servlet na versão 3.0
package com.Servlet;
import java.io.PrintWriter;
import javax.Servlet.annotation.WebServlet;
import javax.Servlet.annotation.WebInitParam;
@WebServlet(name=”ServletLogin”,urlPatterns = {“/login”}, initParams =
{
@WebInitParam(name = “usuario”, value = “admin”),
@WebInitParam(name = “senha”, value = “admin”)})
public class ServletLogin extends HttpServlet {
@Override
}
@Override
}
}
Observe as anotações na classe:
@WebServlet(name=”ServletLogin”, urlPatterns = {“/login”}, initParams

= {
@WebInitParam(name = “usuario”, value = “admin”),
@WebInitParam(name = “senha”, value = “admin”)})
Isso equivale à configuração mostrada no quadro 14.
Pág. 40 de 130
Quadro 14 - Configuração equivalente na versão 2.5 do Servlet
<Servlet>
<Servlet-name>ServletLogin</Servlet-name>
<Servlet-class>com.Servlet.ServletLogin</Servlet-class>
<init-param>
<param-name>usuario</param-name>
<param-value>admin</param-value>
</init-param>
<init-param>
<param-name>senha</param-name>
<param-value>admin</param-value>
</init-param>
</Servlet>
<Servlet-mapping>
<Servlet-name>ServletLogin</Servlet-name>
<url-pattern>/login</url-pattern>
</Servlet-mapping>
Atenção: Se houver tanto anotações na classe quanto a presença do arquivo web.xml, a

prioridade é das informações contidas no arquivo web.xml. O objetivo é manter a compatibilidade
com versões anteriores.
A configuração do Servlet 3.0 se dá através de anotações, como já vimos. Estas anotações

estão no pacote javax.Servlet.annotation, e são elas:
• @WebServlet – usada nas classes representativas de Servlets.

• @WebInitParam – usada para definir parâmetros de inicialização do Servlet.
• @WebFilter – usada em Filtros (assunto a ser abordado posteriormente).
• @WebListener - usada para definir Listeners (assunto abordado posteriormente).
• @MultipartConfig – usada para definir que um Servlet receberá uma requisição do tipo mime/
multipart.
Consulte a tabela 5 do material complementar para ver a tabela com os atributos de @WebServlet.
Na tabela 6 do material complementar está a lista de atributos da anotação @WebInitParam. Na
tabela 7 do material complementar temos a lista de atributos da anotação @WebFilter.
Com a anotação @WebListener os seguintes Listeners podem ser registrados:
• Context Listener (javax.Servlet.ServletContextListener)

• Context Attribute Listener (javax.Servlet.ServletContextAttributeListener)
• Servlet Request Listener (javax.Servlet.ServletRequestListener)
Pág. 41 de 130
• Servlet Request Attribute Listener (javax.Servlet.ServletRequestAttributeListener)
• Http Session Listener (javax.Servlet.http.HttpSessionListener)
• Http Session Attribute Listener (javax.Servlet.http.HttpSessionAttributeListener)
3.9. Considerações sobre mapeamento do Servlet

O exemplo do quadro 14 definiu um Servlet acessível através do mapeamento/login. Esse
tipo de mapeamento permite o acesso ao Servlet apenas desta forma, mas é possível que vários
mapeamentos sejam estabelecidos para o mesmo Servlet, além da utilização de um curinga.
Por exemplo, considere o mapeamento:
@WebServlet(name = “ServletLogin”, urlPatterns = {“*.do”}
Ele permite a execução do Servlet ServletLogin através de diversos mapeamentos, como:
• programa.do
• cadastro.do
• login.do
• etc.do
Ou seja, qualquer expressão pode ser usada, desde que tenha o termo “.do” anexado ao final.
Esse mecanismo é útil para Servlets que centralizam requisições e geram respostas adequadas
para cada uma destas requisições. Frameworks (JSF, por exemplo) utilizam esta abordagem.
3.10. ServletConfig
No ciclo de vida do Servlet, o método init() recebe como parâmetro uma referência ServletConfig,
fornecida pelo container. É a partir desta referência que são obtidos os valores de configuração do
Servlet, incluindo os parâmetros de inicialização.
O quadro 15 mostra um exemplo obtendo os valores dos parâmetros de inicialização do Servlet

ServletLogin.
Pág. 42 de 130
Quadro 15 - Método doGet() obtendo parâmetros de inicialização
protected void doGet(HttpServletRequest request, HttpServletResponse

response)
String usuario = getServletConfig().
getInitParameter(“usuario”);
String senha = getServletConfig().getInitParameter(“senha”);
PrintWriter out = response.getWriter();
out.print(usuario);
out.print(senha);
}
O método getServletConfig() retorna uma referência ao ServletConfig informado pelo container.

A partir desta referência podemos executar:
• getInitParameter(String): acesso aos parâmetros de inicialização

• getInitParameterNames(): acesso aos nomes dos parâmetros de inicialização
Uma estratégia interessante é carregar os parâmetros no método init() do Servlet.
3.11. ServletContext
Permite o acesso às configurações do contexto, ou seja, da aplicação. Ele é criado no momento
em que o servidor de aplicações é iniciado. Alguns métodos de ServletContext são:
• getInitParameter(String): permite acesso aos parâmetros de inicialização do contexto;

• getInitParameterNames(): permite acesso aos nomes dos parâmetros de inicialização do
contexto;
• setAttribute(String,Object): grava um objeto no contexto, ou seja adiciona um item no contexto;
• getAttribute(String): obtém um objeto do contexto;
• removeAttribute(String): remove um objeto do contexto.
Para obter um parâmetro de inicialização de um contexto, definir os nós no arquivo web.xml,

como mostra o quadro 16.
Pág. 43 de 130
Quadro 16 - Configuração de parâmetro de inicialização de um contexto
<context-param>
<param-name>aplicacao</param-name>
<param-value>Contas a pagar</param-value>
</context-param>
Os parâmetros de inicialização do Servlet são muito parecidos. É importante verificar que os

parâmetros de inicialização do contexto são definidos fora do elemento <Servlet>, enquanto que
os parâmetros de inicialização do Servlet são definidos, obviamente, dentro do elemento <Servlet>.
O acesso a esses parâmetros é realizado através de uma referência a ServletContext, como

mostra o quadro 17.
Quadro 17 - Método doGet() obtendo os parâmetros de inicialização do contexto
protected void doGet(HttpServletRequest request, HttpServletResponse

response)
String app = getServletContext().getInitParameter(“aplicacao”);
//restante do código
}
Geralmente os parâmetros de inicialização do contexto são usados para definir configurações

para toda a aplicação.
Pág. 44 de 130
4. SESSÃO
4.1. Definição de gerenciamento de sessão

Quando uma requisição é realizada, ocorrem quatro etapas mostradas na figura 32.
Figura 32 - Mecanismo de requisição e resposta
1 HTTP Request
2 HTTP Response + Set-Cookie
3 HTTP Request + Cookie
WEB CLIENT WEB SERVER

4 HTTP Response
Fonte: <http://www.codeproject.com/KB/IP/478485/o_3b90980886416e5f_html_m69db3cd5.png>. Acesso em: 12 set. 2014.
Se uma nova requisição é realizada, esta não possui nenhuma informação a respeito da requisição
anterior. Sendo assim, dizemos que uma requisição HTTP é por padrão stateless (não mantém
o estado entre requisições). No entanto, o servidor gera um número de identificação para cada
requisição realizada, e essa identificação é única para cada cliente.
Aplicações web, por natureza, diferentemente de aplicações desktop, não possuem uma “instância”,
portanto não possuem um espaço de memória onde se podem guardar variáveis que serão usadas
durante a execução do processo, no caso de uma visita a uma aplicação web durante uma sessão.
Uma forma de preservar informações, levando em consideração a natureza desconectada

de solicitação ou resposta da web, seria utilizar formulários e páginas dinâmicas: por exemplo, o
usuário seleciona um produto e, ao postar para a página de outra categoria de produtos, o código
do produto selecionado deveria ser postado junto, preservado na página como um campo oculto,
ao longo de várias requisições.
Muitas vezes é necessário preservar em memória uma informação sensível que não poderia ser
postada e uma reposta sem oferecer riscos, como o login e senha do usuário. Estes casos requerem
Pág. 45 de 130
que a informação seja preservada durante toda a visita do usuário ao site, entre as chamadas a
diversas páginas dele.
O container Java oferece um sistema robusto e sofisticado de controle de sessão, que permite
armazenar praticamente qualquer tipo de objeto na memória do servidor, preservando o seu valor
durante um limite de tempo que é renovado a cada requisição.
A cada requisição de página emitida pelo mesmo usuário através da mesma conexão e do
mesmo navegador (situação esperada na navegação normal em um site), o tempo de vida da sessão
é renovado e os valores armazenados são mantidos. Após o limite de tempo ter se esgotado, o
servidor descarta as informações de sessão, para preservar seus recursos.
4.2. Modelo do controle de sessão

A sessão é gerada no servidor, como ilustra a figura 33 e armazenada no cliente em forma de
cookie, em um campo oculto ou na URL, como mostra a figura 34.
Figura 33: Geração de sessão no servidor
Clientes Servidor
Sessão
Sessão
Sessão
Sessão
Pág. 46 de 130
Figura 34 - Transferência da sessão para o cliente
Clientes Servidor
Sessão
Sessão
Sessão
Sessão
O servidor fornece um identificador para a sessão (ID da sessão) que é enviada para o cliente.
Na próxima vez que o mesmo cliente realizar outra requisição, o ID é lido e enviado juntamente com
a requisição, de forma que o servidor reconhece o usuário. Assim, a cada requisição, a informação
desejada é transferida para o servidor e, então, é enviada de volta para o cliente.
4.3. A classe HttpSession

A sessão é implementada no web container através da interface: javax.Servlet.http.HttpSession.
O container cria um objeto HttpSession para um usuário quando ele inicia a aplicação. Há um
HttpSession para cada usuário ativo.
Se o usuário não executar nenhuma ação por um determinado período de tempo, o servidor
assume que o usuário está inativo e invalida a sessão por timeout. O tempo de permanência da
sessão é configurável, tanto no deployment descriptor como de forma programática.
Na tabela 8 dos materiais complementares veremos os principais métodos da classe HttpSession.
Dentro da sessão podem ser armazenados parâmetros e atributos que são visíveis somente
dentro uma sessão de usuário, como pode ser visto na figura 35.
Pág. 47 de 130
Figura 35 – Escopos do contexto da sessão e do contexto
Por padrão, a sessão é armazenada no cliente através de cookies. É possível que os cookies
estejam desabilitados no cliente. Neste caso, a sessão pode ser armazenada em campos ocultos
ou através do mecanismo de reescrita de URL.
4.4. Campos ocultos

Campos ocultos são acessados pelo formulário, como outros elementos. Para o servidor não
existe diferença entre campos visíveis ou ocultos, daí sua possibilidade de utilização. Um exemplo
de utilização é:
<input type=”hidden” name=”cmpHidden” value=”true” >
A desvantagem é que ele só funciona para uma sequência de formulários gerados dinamicamente,
e a técnica falha se houver um erro antes que os dados sejam permanentemente armazenados em
algum lugar.
Pág. 48 de 130
4.5. Reescrita de URL
Nem todos os navegadores suportam cookies e, mesmo que suportem, podem estar configurados
para não armazenarem-nos. Para contornar este problema, o Servlet pode ser configurado para
usar reescrita de URL, como alternativa de controlar sessão.
Com esse procedimento, o servidor adiciona informações extras dinamicamente na URL.

Normalmente esta informação é a ID de sessão (uma ID exclusiva associada a um objeto HttpSession
quando ele é criado).
Podemos usar o método HttpServletResponse.encodeURL() para codificar a ID de sessão dentro

de uma resposta, como um parâmetro adicional.
Por exemplo:
out.println(“<form action=’ “ + response.encodeURL(“/JSPPage” + “ ‘>”);
adiciona a ID de sessão na URL de ação do formulário, como segue:
http://localhost:8080/execicio02/JSPPage;jsessionid=30F76DE281982B57B4BEFC2434B6F5E
4.6. Escopo de armazenamento de dados na memória do servidor

É possível manipularmos atributos em:
• requisição (request);
• sessão (session);
• contexto (application).
Cada um tendo seus benefícios, aplicações e vantagens. A figura 36 ilustra estes três componentes
no servidor.
Pág. 49 de 130
Figura 36 - Web container com os objetos Request, Session e Context
Servidor Web
Aplicação web
Clientes Web HttpServletRequest HttpSession
ServlentContext
Fonte:elaborada pelo autor
Na tabela 9 que está nos materiais complementares apresentaremos o tempo de vida para
casa situação.
Pág. 50 de 130
5. JAVA SERVER PAGES (JSP)
5.1. Definição de JSP

A tecnologia Java Server Pages (JSP) é uma extensão da tecnologia de Servlets. Ambas são
tecnologias web JEE que utilizam o conceito de container, responsável por gerar conteúdo dinâmico
via protocolo HTTP e fornecer o runtime para aplicações, entre outras tarefas.
Assim sendo, a arquitetura geral das páginas JSP tem muito em comum com os Servlets, tendo
em vista que a especificação JSP é definida como uma extensão da API Servlet. Além das classes e
interfaces para programar Servlets (pacotes javax.Servlet e javax.Servlet.http), as classes e interfaces
específicas à programação de Java Server Pages encontram-se nos pacotes javax.Servlet.
Atuando na camada de apresentação, as páginas JSP utilizam a tecnologia Java no formato

de Servlets no lado do servidor para a criação de conteúdo dinâmico, junto às tags HTML para o
conteúdo estático.
Quando um servidor compatível com JSP recebe a primeira solicitação para uma JSP, o container
de JSP traduz essa JSP em um Servlet Java que trata a solicitação atual e as solicitações futuras
para a JSP. Se houver algum erro na compilação do novo Servlet, esses erros resultam em erros
em tempo de tradução.
Alguns containers de JSP traduzem as JSPs para Servlets em tempo de instalação. Isso elimina
o overhead de tradução para o primeiro cliente que solicita cada JSP
Podemos observar as seguintes características do JSP:
• Separação do conteúdo estático do dinâmico: como vimos, a lógica de geração de conteúdo

dinâmico é mantida separada das tags HTML responsáveis pela interface para o usuário. A
parte lógica é encapsulada em componentes Java do tipo JavaBeans, que são utilizados pelas
páginas JSP através de scriptlets ou tags especiais, chamadas taglibs.
• “Escreva uma vez, rode em qualquer lugar”: como a tecnologia JSP é uma extensão da plataforma
Java, as páginas JSP têm a vantagem da independência de plataforma.
• Diversos formatos: possibilidade de implementação de linguagens como HTML, XML, DHTML,
WML, etc.
Pág. 51 de 130
• Utilização de código Java: é possível utilizar os chamados scriplets, que são trechos de código
Java puro, inseridos dentro da página JSP, tendo assim as vantagens tanto da Orientação a
Objetos quanto de Java.
5.2. Arquitetura JSP

Há componentes-chaves para JSPs, que são diretivas, ações e scriptlets, assim descritos:
• As diretivas são mensagens para o container de JSP que permite ao programador especificar
as configurações de uma página, incluir conteúdo a partir de outros recursos e especificar
bibliotecas de marcas personalizadas para utilização em uma JSP.
• As ações encapsulam funcionalidades em marcas predefinidas que os programadores podem
incorporar a uma JSP. As ações são frequentemente realizadas com base nas informações
enviadas ao servidor como parte de uma solicitação feita pelo cliente. Eles também podem
criar objetos Java para a utilização em scriptlets JSP.
• Os scriptlets permitem inserir código Java que interaja com os componentes em uma JSP
(e, possivelmente, outros componentes de aplicativos web) para realizar processamento de
solicitações.
Durante o processamento de uma requisição, várias páginas JSP podem estar envolvidas.
Diversos objetos podem ser criados, tanto usando diretivas JSP, como por ações definidas na página
JSP ou ainda por trechos de código Java embutidos na página JSP.
Qualquer objeto criado pode ser associado com um atributo de escopo, que define onde existe
uma referência ao objeto e quando a referência é removida. Assim sendo, temos seguintes atributos:
• page: objetos acessíveis somente nas páginas em que foram criados;

• request: objetos acessíveis nas páginas que processam a mesma requisição;
• session: objetos acessíveis nas páginas que pertençam à mesma sessão em que os objetos
foram criados;
• application: objetos acessíveis nas páginas que pertençam a mesma aplicação.
Pág. 52 de 130
6. DIRETIVAS
As diretivas são elementos da página que não dependem de quaisquer solicitações, e funcionam
como um pré-processamento para a página. A sintaxe básica de uma diretiva é:
<%@ diretiva %>
As diretivas são:
• page – associada ao comportamento da página atual;

• include – usada para incluir arquivos texto ou jsp no documento atual;
• taglib – usada para definir uma biblioteca de tags personalizadas.
6.1. Diretiva page

Considerada a mais extensa das diretivas. Os principais atributos podem ser consultados na
tabela 10 de material complementar.
Exemplos:
<%@ page import=“java.sql.*” %>

<%@ page import=“java.sql.*,java.io.*” %>
<%@ page errorPage=”erroGeral.jsp” %>
Pág. 53 de 130
7. FORMULÁRIOS
Um formulário consiste em um ou mais campos de entrada de dados, descritos pela tag <input>,
em que o atributo type permite a criação de campos de texto, senhas, caixa e lista de seleção,
menus, botão de opção, entre outros. A forma geral é:
<input type=.. name=... value=... size=... maxlength=...>
Formulários são usados para enviar dados pela web. Sozinhos, formulários são inúteis, eles
devem estar vinculados a um programa que irá processar seus dados. Esses programas podem
ser elaborados em diversas linguagens, incluindo o ASP.Net.
Os elementos de um formulário são:
• form: define o formulário. Dentro desse elemento existe um atributo obrigatório, o action, que
diz o endereço do programa para onde os dados do formulário serão enviados.
• O atributo opcional method diz a forma em que o formulário será enviado, e pode ter o valor
get (que é o default) ou post. Frequentemente usa-se post que esconde a informação (get
manda a informação através da URL).
Um elemento form vai se parecer com:
<form action=”script.jsp” method=”post”>

elementos
</form>
Geralmente os elementos de um formulário são inseridos com a tag <input .. > e o tipo do
elemento. A tabela 11 do material complementar apresenta uma lista com o conjunto de elementos
usados em um formulário.
Pág. 54 de 130
8. DEFINIÇÃO DE OBJETOS IMPLÍCITOS
É possível criar, dentro de scriptlets na página JSP, instâncias de uma classe Java e manipulá-
las a fim de produzir um conteúdo dinâmico. Por exemplo, podemos criar um objeto de uma classe
que acessa uma base de dados e então usar métodos desse objeto para exibir na página uma
consulta ou transação com a base de dados. Ou seja, através da manipulação desse objeto, quer seja
acessando seus métodos e suas variáveis, podemos gerar conteúdo dinâmico para a página JSP.
Além de objetos como esses, que estão completamente sob o controle do programador, o
container JSP se encarrega de instanciar automaticamente, durante a execução de uma página
JSP, alguns objetos. Tais objetos podem ser usados dentro da página JSP e são conhecidos como
objetos implícitos. Assim como todo objeto em Java, cada objeto implícito é uma instância de uma
classe ou interface e segue uma API correspondente.
A tabela 12 do material complementar apresenta um resumo dos objetos implícitos disponíveis

em JSP, suas respectivas classes ou interfaces e uma pequena descrição do objeto.
Pág. 55 de 130
9. DECLARAÇÕES DE VARIÁVEIS
Um conjunto de variáveis pode ser declarado separadamente em uma página, desde que estejam
contidas nas tags:
<%! variáveis %>
Exemplo:
<%!
int idade;
double salario;
String endereco;
%>
Pág. 56 de 130
10. EXPRESSÕES OU SCRIPTLETS
São mais largamente usadas em páginas JSP. Todo código JSP deve ser escrito dentro das tags.
<% expressões %>
Exemplos:
<%
String nome = request.getParameter(“txtNome”);
int codigo = request.getParameter(“txtCodigo”);
%>
<%
if (idade < 18) {
out.println(“<b>Você é menor de idade</b>”);
}
%>
<%
if (idade < 18) {
%>
<b>Você é menor de idade</b>
<%
}
%>
Pág. 57 de 130
11. AÇÕES
São informações empregadas na fase de execução. Elas podem ser separadas em dois grupos:
1. Ações padrões
2. Ações personalizadas
As ações padrão são definidas pela especificação JSP e, as personalizadas, em tags personalizadas.
Ambas empregam a sintaxe XML.
As principais ações padrão são mostradas na tabela 13 do material complementar.
Exemplo:
Suponha que se queira incluir na página atual, a página chamada DadosPessoais.jsp com o
conteúdo:
<%
String código = request.getParameter(“txtCodigo”);
String email = request.getParameter(“txtEmail”);
%>
Na página atual há:
<jsp:include page=”DadosPessoais.jsp”>
<jsp:param name=”txtCodigo” value = “100” />
<jsp:param name=”txtNome” value = “João” />
<jsp:param name=”txtEmail” value = “joão@ninguem.com” />
</jsp:include>
Observe o fechamento das tags. No caso da tag include, houve uma linha para fechamento, com
um conteúdo entre a abertura e o fechamento. Neste caso a tag é chamada de tag com conteúdo
não vazio ou de corpo não vazio.
No caso da tag jsp:param, o fechamento ocorreu na mesma linha. Esta tag é chamada de , ou
sem conteúdo.
Pág. 58 de 130
12. PASSANDO PARÂMETROS PARA UMA PÁGINA JSP VIA URL
Normalmente uma página JSP recebe os dados de um formulário. É possível executar uma
página JSP sem a necessidade de um formulário.
Suponha uma página chamada Cadastro.jsp com as expressões abaixo:
<%
String código = request.getParameter(“txtCodigo”);
%>
Normalmente seria necessário um formulário com os componentes txtcodigo, txtNome e

txtEmail. Para chamá-la no browser diretamente, deve-se inserir a informação abaixo:
http://localhost:8080/Cadastro.jsp?txtCodigo=10&txtNome=João&txtEmail=joao@ninguem.com.br
No que se segue, alguns exemplos são apresentados.
Pág. 59 de 130
• Exemplo 1: envio de dados usando o método GET. Assumindo que o programa a seguir se
chame arquivo.jsp e que faça parte de um contexto chamado arquivos, seu acesso é realizado
através da seguinte url:
http://localhost:8080/arquivos/arquivo.jsp?txtNome=Carlos&txtIdade=10&txtSalario=1000
O código a seguir no quadroi leria os parâmetros txtNome; txtIdade e txtSalario da url e os

gravaria no arquivo c:/arquivo.txt.
<%@ page import=”java.io.*,java.util.*” %>

<%
String id = request.getParameter(“txtIdade”);
String sal = request.getParameter(“txtSalario”);
int idade = Integer.parseInt(id);
double salario = Double.parseDouble(sal);
String linha = nome + “;” + id + “;” + sal + “\r\n”;
try {
FileWriter f = new FileWriter(“c:/arquivo.txt”,true);
f.write(linha);
f.close();
%>
<center><h2>Dados gravados com sucesso !</h2></center>
<%
}
catch( Exception e) {
%>
<h1>OCORREU UM ERRO AO TENTAR GRAVAR O ARQUIVO</h1>
<%
}
%>
Pág. 60 de 130
• Exemplo 2: No exemplo a seguir, não é necessário informar nenhum parâmetro: o programa,
chamado abreArquivo.jsp, se encarrega de abrir o arquivo e exibir seus dados no browser:
<%@ page import=”java.io.*,java.util.*” %>

<%
try {
FileReader f = new FileReader(“c:/arquivo.txt”);
BufferedReader b = new BufferedReader(f);
do {
String l = b.readLine();
if (l == null) break;
String [] s1 = l.split(“;”);
%>
<b>Nome : </b><%=s1[0]%><br>
<b>Idade : </b><%=s1[1]%><br>
<b>Salario : </b><%=s1[2]%><br><hr>
<%
} while(true);
b.close();
f.close();
}
catch(Exception e) {
%>
<h1>ERRO AO LER ARQUIVO !</h1>
<%
}
%>
• Exemplo 3: envio de dados usando o método POST.
Neste caso é conveniente ter um formulário HTML para realizar o envio, como:
Figura 37 – Formulário de dados de envio
O código para o formulário é o seguinte:
Pág. 61 de 130
Quadro 18 – Código de leitura do formulário
<html xmlns=”http://www.w3.org/1999/xhtml”>
<head>
<meta http-equiv=”Content-Type” content=”text/html;
charset=iso-8859-1” />
<title>Untitled Document</title>
</head>
<body bgcolor=”#FFCC99”>
<form method=”post” action=”arquivo.jsp”>
<table width=”425” border=”0”>
<tr>
<td width=”83”>Nome:</td>
<td width=”332”>
<input name=”txtNome” type=”text” id=”txtNome”
size=40/>
</td>
</tr>
<tr>
<td>Idade:</td>
<td>
<input name=”txtIdade” type=”text” id=”txtIdade”
/>
</td>
</tr>
<tr>
<td>Salário:</td>
<td>
<input name=”txtSalario” type=”text”
id=”txtSalario” />
</td>
</tr>
<tr>
<td colspan=”2”>
<input name=”btnEnviar” type=”submit”
id=”btnEnviar” value=”Enviar” />
<input name=”btnLimpar” type=”reset”
id=”btnLimpar” value=”Limpar” />
</td>
</tr>
</table>
</form>
</body>
</html>
Pág. 62 de 130
13. BEAN
JavaBeans consiste em uma tecnologia que permite escrever componentes Java acessíveis
como propriedades. São necessárias classes Java para que funcionem corretamente e estas
classes devem:
• possuir um construtor padrão

• implementar a interface Serializable (se não implementar, funcionará normalmente, mas não
constitui formalmente um JavaBeans)
JavaBeans são, portanto, classes Java que encapsulam informações a serem executadas em
páginas JSP.
Um objeto instanciado a partir destas classes é chamado de bean. Veja o exemplo a seguir.
Classe Java:
Quadro 19 – Bean de definição de pesso
package com.javabeans;
import java.io.Serializable;
public class Pessoa implements Serializable{
private String nome;
private int idade;
private char sexo;
public String getNome() {
return nome;
}
public void setNome(String nome) {
this.nome = nome;
}
public int getIdade() {
return idade;
}
public void setIdade(int idade) {
this.idade = idade;
}
public char getSexo() {
return sexo;
}
public void setSexo(char sexo) {
this.sexo = sexo;
}
}
Pág. 63 de 130
Nesta classe, cada par setter / getter representa no JSP, uma propriedade, cujo nome é obtido
removendo-se o prefixo set e/ou get, e passando a primeira letra para minúsculo.
Exemplo: os métodos abaixo descritos representam a propriedade nome na página JSP.

return nome;
}
this.nome = nome;
}
A utilização desta propriedade requer que uma instância da classe seja criada, mas a nomenclatura
JavaBeans não utiliza código Java. Os elementos usados na página JSP que manipulam beans são:
<jsp:useBean >
<jsp:setProperty >
<jsp:getProperty >
O elemento <jsp:useBean > é usado para criar o objeto:
<jsp:useBean id=”pessoa” class=”com.javabeans.Pessoa” scope=”request”/>
Nesta instrução, temos:
• id – declara o bean, ou seja, o objeto

• class – classe a partir da qual o bean é criado
• scope (opcional) – indica o escopo do bean na aplicação. Os possíveis valores são: request,
page, session e application.
Pág. 64 de 130
14. VALORES
14.1. Atribuindo valores para as propriedades

As instruções a seguir mostram como atribuir valores para as propriedades, usando o objeto
pessoa criado na instrução anterior.
<jsp:setProperty name=”pessoa” property=”nome” value=”Jose”/>

<jsp:setProperty name=”pessoa” property=”idade” value=”25”/>
<jsp:setProperty name=”pessoa” property=”sexo” value=”m”/>
• name – indica o bean, representado pelo atributo id no elemento <jsp:useBean>.

• property – nome da propriedade. Implicitamente, este elemento executa o setter correspondente
a esta propriedade.
• value – valor a ser atribuído à propriedade. Pode ser fixo ou proveniente de um parâmetro
(formulário ou URL).
É possível atribuir valores variáveis para as propriedades, de duas formas. A primeira é:
<jsp:setProperty name=”pessoa” property=”nome” value=”<%= request.

getParameter(“nome”) %>”/>
A segunda forma é usando o objeto implícito param através de “Expression Language (EL)”:
<jsp:setProperty name=”pessoa” property=”nome” value=”${param.nome}”/>
14.2. Obtendo valores das propriedades

A leitura das propriedades é realizada através do elemento <jsp:getProperty>. Este elemento
encapsula a funcionalidade da instrução out.print().
Nome: <jsp:getProperty name=”pessoa” property=”nome”/>

Idade: <jsp:getProperty name=”pessoa” property=”idade”/>
Sexo: <jsp:getProperty name=”pessoa” property=”sexo”/>
Pág. 65 de 130
15. DEFINIÇÃO DE JSTL
JSTL é uma API Java que contém um conjunto de tags agrupadas de acordo com sua aplicabilidade.
O objetivo é simplificar o desenvolvimento de páginas JSP, eliminando boa parte de código escrito
em scriptlets.
A JSTL encapsulou, em tags simples, toda a funcionalidade que diversas páginas web
precisam, como controle de laços (for), comandos de decisão (if .. else), manipulação de dados
xml, internacionalização da aplicação, além de acesso e manipulação de bancos de dados.
Enfim, JSTL foi a forma encontrada de padronizar o trabalho de programação em JSP.
Na data da elaboração deste material, a API JSTL foi obtida em: https://mvnrepository.com/artifact/
javax.servlet.jsp.jstl/javax.servlet.jsp.jstl-api/1.2.2
Pág. 66 de 130
16. EXPRESSION LANGUAGE (EL)
JSTL faz uso extensivo de Expression Language (EL). EL representa um conjunto de operadores
e objetos implícitos, semelhantes àqueles definidos no JSP, mas com o objetivo de tornar possível
o uso do JSTL.
Por padrão ${algumaCoisa} procura por uma variável com o nome algumaCoisa em algum dos
escopos, porém podemos deixar explícito o escopo usando um nome de variável que representa
cada um dos escopos.
Por exemplo, ${sessionScope.usuarioLogado} ou ${pageScope.pessoas}. sessionScope e

pageScope são variáveis implícitas do contexto EL.
A tabela 14 do conteúdo complementarxibe os contextos implícitos disponíveis em EL.
Cada uma dessas variáveis representa um objeto Java. EL também possui operadores aritméticos,
relacionais e lógicos. A tabela 15 do conteúdo complementar mostra quais são estes operadores
e como usá-los.
Pág. 67 de 130
17. BIBLIOTECAS
17.1. Bibliotecas de tags

As bibliotecas de tags se dividem nas categorias:
• Core manipulação de dados

• SQL manipulação de banco de dados
• Format formatação de dados
• XML configuração de arquivos XML
17.2. Biblioteca Core

Propósitos:
1. Manipulação de variáveis de escopo e tratamentos de erros;

2. Facilidade no processamento condicional em páginas JSP;
3. Iteração entre coleções e dados;
4. Criação de links, importação e redirecionamento para URLs.
As principais tags contidas na biblioteca Core são:
• <c:out>
• <c:set>
• <c:remove>
• <c:catch>
• <c:if>
• <c:choose>
• <c:forEach>
• <c:forTokens>
• <c:param>
• <c:url>
• <c:import>
• <c:redirect>
• <c:when>
Pág. 68 de 130
<c:out>
Atributos:
value valor a ser avaliado
default valor (opcional) retornado caso value seja vazio ou nulo
escapeXml flag (opcional) indicando se caracteres especiais devem ser convertidos
Utilização:
Para utilizar tags da biblioteca Core nas páginas JSP é necessário inserir no cabeçalho:
<%@ taglib uri=”http://java.sun.com/jsp/jstl/core” prefix=”c” %>
Exemplos de aplicação:
Especificando o prefixo “c”:
<%@ taglib uri=”http://java.sun.com/jsp/jstl/core” prefix=”c” %>
Apresentando uma mensagem no browser:
<c:out value=”Iniciando o estudo do JSTL” />
<c:set>
Atributos:
var nome da variável
value valor a ser atribuído a variável
scope escopo da variável (page, request, session ou application)
target e property objeto e propriedade (ao invés de var)
Obtendo o valor de uma variável:
<c:set var=”nome” value=“José Maria” scope=”page”/>
Pág. 69 de 130
Apresentando o conteúdo da variável:
<c:out value=“${nome}”/>
Observe que o acesso a variável é realizado através do símbolo “${ }”:
É possível receber valores de parâmetros obtidos através da URL:
<c:set var=”nome” value=”${param.nome}” />
O que é equivalente à expressão:
String nome = request.getParameter(“nome”);
<c:remove>
Observe as instruções a seguir:
<c:set var=“idade” value=“45“/>

<c:out value=“${idade}”/>
<c:remove var=“idade“/>
<c:out value=“${idade}” escapeXml=“false”>
A variável <b>idade</b> foi removida do escopo!
</c:out>
A variável idade, primeiro foi criada, apresentada, e depois, removida do escopo através da tag
<c:remove>. O texto no corpo de <c:out > ... </c:out> é apresentado porque a variável não tem valor
default nem existe mais.
<c:catch>
Atributos:
var nome da variável
Esse atributo é opcional e, se não colocado, a exceção será ignorada.
Define a variável que irá capturar a exceção:
<c:catch var=“erro”>
<c:set target=“${usuario}” property=“SeuNome” value=“Zé”/>
</c:catch>
Pág. 70 de 130
Exceção gerada:
<c:out value=“${erro}”>Nenhuma</c:out>
<c:if>
Atributos:
test expressão a ser testada
var variável (opcional) a receber o valor da expressão
scope escopo (opcional) da variável
target e property objeto e propriedade (ao invés de var)
Corpo da tag bloco a ser executado se a expressão for verdadeira
A expressão a seguir verifica o nome do usuário:
<c:if test=“${usuario == ‘Vivaneide Rocha’}”>

Usuário cadastrado!
</c:if>
Ou:
<c:if test=“${usuario == ‘Vivaneide Rocha’}” var=“acesso”>

</c:if>
A variável acesso apresentará o resultado da pesquisa: true ou false.
<c:choose>, <c:when>, <c:otherwise>

Usado para condições de múltipla escolha.
Atributos:
test condição a ser testada (<c:when>)
• <c:choose>: tags <c:when> e <c:otherwise>

• <c:when>:executado quando teste for verdadeiro
• <c:otherwise>:executado caso nenhum <c:when> seja aplicado
Pág. 71 de 130
<c:choose>
<c:when test=“${usuario == ‘Vivaneide Rocha’}”>
</c:when>
<c:otherwise>
Usuário não cadastrado!
</c:otherwise>
</c:choose>
Equivalente a um comando if ... else
<c:forEach>
Executa o corpo da tag várias vezes.
Atributos:
itens coleção (opcional) a ser iterada.
var variável a receber cada valor da iteração.
varStatus variável a receber status de cada iteração.
begin e end índice do primeiro e último passos da iteração.
step frequência das iterações.
Apresenta o resultado de uma estrutura de repetição:
<c:forEach var=”i” begin=”1” end=”10”>

<c:out value=”${i}”/><br>
</c:forEach>
Apresenta o resultado de um formulário:
<c:forEach itens=”${param.txtNome}” var=”p”>

<c:out value=”${p}”/>
</c:forEach>
A expressão param.txtNome é equivalente à request.getParameter(“txtNome”);
Pág. 72 de 130
<c:forTokens>
Interage com os símbolos de uma string:
Atributos:
itens coleção (opcional) a ser iterada
delims variável a receber cada valor da iteração
varStatus variável a receber status de cada iteração
begin,end,varStatus e step mesmo significado que em <c:forEach>
<c:forTokens itens=”nome;idade” delims=”;” var=”tok” varStatus=”st”>

<c:out value=”${st.count}”/><br>
<c:out value=”${tok}”/><br>
</c:forTokens>
O resultado dessa execução será:
1
nome
2
idade
<c:url>
Cria uma string representando uma URL.
Atributos:
value valor da url
var variável (opcional – caso omitido, a URL será impressa na página) que receberá a url
scope (opcional) escopo da variável
context (opcional) contexto da página
Pág. 73 de 130
<c:url value=”resultado.jsp” var=”url”>

<c:param name=”txtNome” value= “Felipe” />
<c:param name=”txtEmail” value= “felipe@felipe” />
</c:url>
<c:out value=”${url}”/>
O resultado dessa execução será:
resultado.jsp?txtNome=Felipe&txtEmail=felipe%40felipe
Aqui convém relembrar que os dados para um formulário podem ser enviados através da barra
de endereços do browser. Por exemplo, seja o arquivo chamado recebe.jsp, que contém os campos
nome e idade a serem preenchidos:
<%
...
%>
Os valores podem ser chamados assim:
recebe.jsp?txtNome=Felipe&txtEmail=felipe%40felipe
17.3. Biblioteca Sql

Propósitos:
1. Trabalhar com DataSources/Connections;

2. Realizar consultas;
3. Realizar inclusão, alteração ou exclusão.
As principais tags contidas na biblioteca Sql são:
• <sql:query>
• <sql:update>
• <sql:transaction>
• <sql:param>
• <sql:setDataSource>
Pág. 74 de 130
<sql:setDataSource>
Define um DataSource e o exporta como variável de escopo ou DataSource padrão
Atributos:
dataSource origem do banco de dados (conexão)
driver/url/user/password valores usados pelo DriverManager para obter a conexão
var variável que conterá o DataSource
scope (opcional) escopo da variável (request, page, session, application)
<sql:update>
Executa instruções SQL do tipo INSERT, UPDATE e DELETE.
Atributos:
sql instrução a ser executada
var variável (opcional) que conterá o nº de linhas afetadas
Exemplo:
<sql:setDataSource
var=”dataSource” driver=”sun.jdbc.odbc.JdbcOdbcDriver”
url=”jdbc:odbc:Driver={Microsoft Access Driver
(*.mdb)};dbq=C:/jstl.mdb”
scope=”session” />
<sql:update dataSource=”${dataSource}”>
INSERT INTO CLIENTES VALUES (5,’USER’)
</sql:update>
Pág. 75 de 130
<sql:query>
Executa uma instrução SELECT.
Atributos:
sql instrução a ser executada
maxRows (opcional) nº máx. de linhas retornadas
startRow (opcional) primeira linha retornada
var variável (opcional) que conterá o nº de linhas afetadas
Exemplo:
<sql:setDataSource
var=”dataSource” driver=”sun.jdbc.odbc.JdbcOdbcDriver”
url=”jdbc:odbc:Driver={Microsoft Access Driver (*.mdb)};dbq=C:/
jstl.mdb”
scope=”session” />
<sql:query var = “users” dataSource=”${dataSource}”>
select ID, NOME from CLIENTES
</sql:query>
<table border=1>
<c:forEach var=”row” itens=”${users.rows}”>
<tr>
<td><c:out value=”${row.ID}”/></td>
<td><c:out value=”${row.NOME}”/></td>
</tr>
</c:forEach>
</table>
<sql:param>
Atribui o valor para um parâmetro “?” numa query
Atributos:
value valor do parâmetro
Pág. 76 de 130
Exemplo:
<sql:update dataSource=”${dataSource}”>
UPDATE CLIENTES SET NOME=’CARLOS’ WHERE ID=?
<sql:param value=”${param.cod}” />
</sql:update>
<sql:transaction>
Define um contexto transacional dentro do qual <> e <> serão utilizados.
Atributos:
dataSource String de conexão para o banco de dados
isolationLevel nível de isolamento da transação
Exemplo:
<sql:transaction>
<sql:update>UPDATE CLIENTES set NOME=? where ID=?
<sql:param value=”${vnome}” />
<sql:param value=”${vID}” />
</sql:update>
</sql:transaction>
17.4. Biblioteca Format

Propósitos:
1. Formatação de datas.
2. Formatação de números.
3. Formatação de horas.
4. Formatos customizáveis.
As principais tags contidas na biblioteca Format são:
• <fmt:formatNumber>
• <fmt:parseNumber>
• <fmt:formatDate>
• <fmt:timeZone>
• <fmt:parseDate>
Pág. 77 de 130
<fmt:formatNumber>
Atributos:
value valor a ser formatado
type (opcional) number, currency ou percentage
pattern (opcional) padrão de formatação
currencyCode (opcional) código ISO da moeda
currencySymbol (opcional) símbolo da moeda
maxIntegerDigits/ (opcional) dígitos máximos/mínimos da parte inteira da saída

minIntegerDigits
maxFractionalDigits/ (opcional) dígitos máximos/mínimos da parte fracionária da saída

minFractionalDigits
var (opcional) variável que conterá a saída
Exemplos:
<fmt:formatNumber value=”9876543,21“ type=”currency”/>
Saída: R$ 9.876.543,21
<fmt:formatNumber value=”12,3” pattern=”.000”/>
Saída: 12,300
<fmt:formatNumber value=”123456,7891“ pattern=”#,#00.0#”/>
Saída: 123.456,79
<fmt:formatNumber value=”123456789” type=”currency“ var=”cur”/>
O resultado é armazenado em cur: R$ 123.456.789,00
Pág. 78 de 130
<fmt:parseNumber>
Atributos:
type number, currency ou percentage
parseLocale padrão de formatação, de acordo com o local
Exemplo:
<c:set var=”reais” value=”R$ 5,00” />

<fmt:parseNumber value=”${reais}” type=”currency” parseLocale=”pt_BR” />
Saída: 5
<fmt:formatDate>
Atributos:
type date, time, ou both
dateStyle (opcional) padrão de formatação da data
timeStyle (opcional) padrão de formatação da hora
pattern (opcional) padrão de formatação customizado
timeZone (opcional) TimeZone da data/hora a ser formatada
var (opcional) Variável que conterá a saída
Exemplo:
<jsp:useBean id=”now” class=”java.util.Date” />

<fmt:formatDate value=”${now}” timeStyle=”long” dateStyle=”long”/>
<fmt:formatDate value=”${now}” pattern=”dd.MM.yy”/>
Pág. 79 de 130
Saída:
18 de Agosto de 2006
18.08.06
<fmt:parseDate>
Atributos:
value valor a ser convertido
type date, time, ou both
dateStyle (opcional) padrão de formatação da data
timeStyle (opcional) padrão de formatação da hora
pattern (opcional) padrão de formatação customizado
timeZone (opcional) TimeZone da data/hora a ser formatada
parseLocale (opcional) Local a ser usado como base de conversão
var (opcional) variável que conterá a saída
Exemplo:
<fmt:parseDate value=”13:15” pattern=”HH:mm” />
Saída:
Thu Jan 01 13:15:00 GMT-03:00 1970
17.5. Biblioteca XML

Propósitos:
1. Parsing de documentos XML.

2. Manipulação de elementos XML.
Pág. 80 de 130
3. Fluxo condicional.
4. Iterações.
5. Transformações.
As principais tags contidas na biblioteca XML são:
• <x:parse>
• <x:out>
• <x:set>
• <x:if>
<x:parse>
Faz o parsing de um documento XML
Atributos:
xml documento a ser “parseado”
var e scope nome e escopo da variável que receberá o documento parseado
systemId URI identificando o documento
Exemplo:
<c:import url=“http://localhost:8080/doc.xml” varReader=“xmlReader” />

<x:parse xml=”${xmlReader}” var=“documento” />
<x:out>
Avalia uma expressão XPath e imprime o resultado na página.
Atributos:
select expressão XPath
escapeXml flag (opcional) indicando se os caracteres especiais devem ser substituídos
Exemplo:

<x:out select=”${documento/titulo}” />
<x:out select=”${documento/autor}” />
Pág. 81 de 130
<x:set>
Avalia uma expressão XPath e atribui o resultado a uma variável de escopo.
Atributos:
escapeXml flag (opcional) indicando se caracteres especiais devem ser substituídos
var nome da variável que receberá o valor da expressão
scope escopo da variável
Exemplo:

<x:set select=”${documento/titulo}” var=“tit” scope=“page”/>
<x:set select=”${documento/autor}” var=“aut” scope=“page”/>
<x:if>
Executa o corpo da tag caso uma expressão XPath seja avaliada em verdadeiro.
Atributos:
var nome da variável que receberá o valor da expressão de teste
scope escopo da variável
Exemplo:

<x:if select=”${documento/[titulo==‘JSTL’]}” />
Introdução a bibliotecas JSTL
<x:if />
Pág. 82 de 130
18. DEFINIÇÃO DE JSF E FRAMEWORK
A tecnologia JavaServer Faces (JSF) é constituída de um framework para desenvolvimento de
aplicações web, executada em um servidor Java e que retorna ao cliente uma interface gráfica.
Os principais componentes do JSF são:
• Uma API para representação de componentes de interface gráfica, manipulação de eventos,

validação de dados, conversão de dados, internacionalização, definição de regras de navegação.
• Uma biblioteca de tags personalizadas, semelhante à JSTL, para representar os componentes
JSF dentro da página.
• Um modelo de componentes que permite a desenvolvedores independentes fornecerem
componentes adicionais.
A JSF contém todos os códigos necessários para a manipulação de eventos e organização de

componentes. Sendo assim, existem ambientes de desenvolvimento (IDE) para a construção desses
componentes. O NetBeans (utilizado neste curso) já contém a API JSF.
Um framework é uma aplicação “quase” completa, com partes faltantes. Essas partes são
justamente as implementações peculiares de cada problema. Apresenta as características:
• Captura a funcionalidade comum a várias aplicações;

• Providencia uma solução para um conjunto de problemas;
• Utiliza um conjunto de classes e interfaces que mostram como decompor o problema;
• Define como os objetos dessas classes colaboram para cumprir suas responsabilidades.
A figura 38 mostra dois cenários que ajudam a entender o conceito de framework.
Figura 38 - Conceito de framework
A B A B
F
C
C
Impossível criar um framework F = Domínio do
A, B e C = Implementações específicas framework
Pág. 83 de 130
A API JSF providencia justamente a parte comum às aplicações, ou seja, o domínio do framework.
O desenvolvedor é o responsável pelas partes complementares ou aplicações específicas.
O foco da JSF é oferecer um framework que suporte componentes gráficos, eventos e

gerenciamento de estado.
Pág. 84 de 130
19. JSF
19.1. A arquitetura MVC (Model–View–Controller)

O Model-view-controller (MVC) é um padrão de arquitetura de software. Em aplicações complexas,
que enviam uma série de dados para o usuário, o desenvolvedor frequentemente necessita separar
os dados (Model) da interface (View). Desta forma, alterações feitas na interface não afetarão a
manipulação dos dados e estes poderão ser reorganizados sem alterar a interface do usuário. O MVC
resolve esse problema através da separação das tarefas de acesso aos dados e lógica do negócio
da apresentação e iteração com o usuário, introduzindo um componente entre os dois: o Controller.
MVC é usado em padrões de projeto de software, mas o MVC abrange mais da arquitetura de
uma aplicação do que é típico para um padrão de projeto. Cada um dos elementos da arquitetura
MVC é descrito a seguir:
Model: É a representação do elemento que contém a informação ou as informações de interesse

para o sistema. Por exemplo, um sistema de cadastro de alunos e cursos possui como modelos a
entidade Aluno, a entidade Curso e a relação existente entre eles.
• View: Refere-se à parte visual da aplicação como definida pela camada Model. É a parte do
sistema que interage com o usuário.
• Controller: Responsável pelo processamento das informações, como a manipulação de eventos
e execução de propriedades.
No MVC destacam-se dois modelos essenciais: Arquitetura Page-Centric e Arquitetura Servelet-

Centric, mostradas nas figuras 39 e 40.
Figura 39 - Arquitetura MVC Model 1
1
Request
Browser JPS page Data
4
Response store
3 Business
Java bean
logic
Application server Enterprise servers or

data sources
Fonte: <https://www.ibm.com/support/knowledgecenter/SSRTLW_9.1.1/com.ibm.etools.struts.doc/images/cstrdoc001.gif>.
Pág. 85 de 130
Figura 40 - Arquitetura MVC Model 2
(Controller)
1 Servlet Data
Request store
Browser
In
st
an 2
3 tia
te
(Model)
Java bean
5
(View) Business
Response
JSP page 4 logic
Application server Enterprise servers or

data sources
Fonte: <https://www.ibm.com/support/knowledgecenter/SSRTLW_9.5.0/com.ibm.etools.struts.doc/topics/cstrdoc001.html>.
19.2. O MVC de JSF

O funcionamento do JSF consiste no registro do Servlet FacesServlet. Com esse registro,
as requisições são controladas pela classe javax.faces.webapp.FacesServlet (o Controller do
MVC), uma implementação de javax.Servlet.Servlet, roteando o tráfego e administrando o ciclo
de vida dos beans e componentes de Interface do Usuário ou User Interface (UI). A figura 41
ilustra este esquema.
Figura 41 - Mecanismo de requisições JSF 2.0
TrabComJSF HTTP Request

Controller
Some text ForcesServlet Cria e gerencia
HTTP Response
Enviar texto
Some text
Manipula e redireciona Model

bean
View Acessa
Páginas XHTML
Fonte: <http://www.edsongoncalves.com.br/wp-content/uploads/2010/02/Figura-51.jpg>. Acesso em: 12 set. 2014.
Os componentes UI são organizados em uma estrutura de árvore em que cada componente

pode ser associado com os métodos e atributos de um bean. Cada componente também pode ser
associado com uma função de validação ou classe.
Pág. 86 de 130
19.3. Exemplo de uma aplicação JSF
Para melhor compreender o uso do JSF, caro aluno, vamos mostrar uma aplicação de exemplo
com o objetivo de ilustrar o uso das tags JSF, das classes que representam os beans e da regra
de navegação.
O JSF 2.x utiliza Facelets desenvolvidos em XHTML, diferentemente das versões anteriores do
JSF que adotavam JSP como suas páginas que renderizam a visualização.
Neste exemplo vamos considerar a aplicação representada no diagrama da figura 42.
Figura 42 - Diagrama base da aplicação JSF
sucesso.xhtml
index.xhtml
erro.xhtml
Esse exemplo representa uma simulação de login. A página index.xhtml é a página em que o
usuário fornece seus dados de usuário e senha. Se estiver correto, ele é direcionado para sucesso.
xhtml e, caso contrário, direcionado para erro.xhtml.
O arquivo index.xhtml possui o código mostrado no quadro 18.
Pág. 87 de 130
Quadro 20 – arquivo index.xhtml
<html xmlns=”http://www.w3.org/1999/xhtml”
xmlns:h=”http://java.sun.com/jsf/html”
xmlns:f=”http://java.sun.com/jsf/core”>
<h:head>
<title>Login</title>
</h:head>
<h:body>
<f:view>
<h:form>
<h3>Por favor, informar seu usuário e sua senha.</h3>
<table>
<tr>
<td>Nome:</td>
<td>
<h:inputText value=”#{usuarios.nome}”/>
</td>
</tr>
<tr>
<td>Senha:</td>
<td>
<h:inputSecret value=”#{usuarios.senha}”/>
</td>
</tr>
</table>
<p>
<h:commandButton value=”Login”
action=”#{usuarios.validarUsuario}”/>
</p>
</h:form>
</f:view>
</h:body>
</html>
A maior parte da página é semelhante ao formato HTML, com as diferenças:
• Todas as tags JSF estão contidas dentro de uma tag <f:view>.

• Ao invés de usar uma tag HTML form, os componentes foram incluídos dentro de uma tag
<h:form>.
• Ao invés de usar tags input para os componentes da interface, foram utilizados os elementos
<h:inputText>, <h:inputSecret> e <h:commandButton>. Esses componentes estão definidos
no framework.
Pág. 88 de 130
Os valores dos campos de entrada são ligados às propriedades do bean de nome usuarios.
O bean usuários é o que em JSF chamamos de Bean Gerenciado (Managed Bean), e é definido
na classe mostrada no quadro 21.
Quadro 21 – classe UsuariosBean
package com.jsf2;
import javax.faces.bean.ManagedBean;
import javax.faces.bean.SessionScoped;
@ManagedBean(name = “usuarios”)
@SessionScoped
public class UsuariosBean {
private String nome, senha;
this.nome = nome;
}
public void setSenha(String senha) {
this.senha = senha;
}
return nome;
}
public String getSenha() {
return senha;
}
public String validarUsuario(){

if(nome.equals(“user”) && senha.equals(“123”)){
return “/sucesso”;
}
else {
return “/erro”;
}
}
}
Observe as anotações no início da classe: @ManagedBean(name = “usuarios”) e @SessionScoped.

Elas definem a classe como sendo um bean gerenciado, acessível através do nome “usuários” e
armazenado na sessão, quando acessado.
A anotação @ManagedBean possui, além do atributo name, o atributo eager, de tipo boolean,
que somente é considerado quando o escopo do bean é gerenciável para application. Caso o valor
Pág. 89 de 130
desse atributo seja true e o escopo application, o bean gerenciável será criado e colocado nesse
escopo quando a aplicação iniciar.
O componente <h:inputText value=”#{usuarios.nome}”/> renderiza uma caixa de textos, aguardando

um valor de entrada. O valor informado nesta caixa de textos é atribuído à propriedade nome através
do bean usuarios. Por ser um componente de entrada, implicitamente o valor da caixa de textos
é passado como parâmetro para o setter correspondente a esta propriedade. Elementos de saída
usam o getter correspondente.
Quando o formulário é preenchido, ele é submetido através do botão:
<h:commandButton value=”Login” action=”#{usuarios.validarUsuario}”/>
É importante observar que esse botão não acessa uma propriedade do bean, mas um método.
Este método representa um action a ser executado, ou seja, um evento de ação padrão. O conteúdo
deste método executa a tarefa de validação do usuário e retorna a navegação entre as páginas,
como mostra o quadro 22.
Quadro 22 – método validarUsuario
public String validarUsuario(){

if(nome.equals(“user”) && senha.equals(“123”)){
return “/sucesso”;
}
else {
return “/erro”;
}
}
O retorno “/sucesso” indica que o usuário será transferido para sucesso.xhtml, e o retorno “/
erro”, para a página erro.xhtml. A transferência ocorre através de um objeto RequestDispacher.
As páginas sucesso.xhtml e erro.xhtml são mostradas nos quadros 23 e 24.
Pág. 90 de 130
Quadro 23 – Página sucesso.xhtml

<!DOCTYPE html>
<h:head>
<title>Sucesso</title>
</h:head>
<h:body>
<f:view>
<h:form>
<h3>Seja benvindo, <h:outputText
value=”#{usuarios.nome}”/></h3>
</h:form>
</f:view>
</h:body>
</html>
Quadro 24 – Página erro.xhtml

<!DOCTYPE html>
<h:head>
<title>Erro!!</title>
</h:head>
<h:body>
<f:view>
<h:form>
<h3>Usuário ou senha inválidos!!</h3>
</h:form>
</f:view>
</h:body>
</html>
19.4. Tags JSF Fundamentais

As tags fundamentais representam objetos que podemos adicionar a componentes. A biblioteca
fundamental também contém tags para definir visões e subvisões, carregar recursos “bundle” e
Pág. 91 de 130
adicionar texto arbitrário a uma página. Essas tags são definidas pelo namespace “http://java.sun.
com/jsf/core”, indicado no início da página xhtml. A tabela 16 do material complementar mostra
estas tags.
19.5. Principais Tags HTML JSF

Essa categoria inclui formulários, mensagens e componentes que geram layout para outros
componentes. Está definida no namespace “http://java.sun.com/jsf/html”. A tabela 17 do material
complementar mostra estas tags.
Pág. 92 de 130
20. BEANS
20.1. Anotações em beans gerenciáveis

Ao registrarmos no JSF uma classe criada em nosso projeto web, ela se torna um Managed
Bean (ou bean gerenciável). Quando isso acontece, esta classe fica gerenciável pelo framework,
ou seja, a partir de qualquer página JSF é possível acessar seus métodos públicos. Daí o nome
Managed Bean.
No JSF ele corresponde ao Modelo da arquitetura Model-View-Controller (MVC), para os

componentes da UI.
Na versão 1.2 do JSF, para que uma classe se tornasse um bean gerenciável, era necessário
registrá-la através do faces-config.xml. Isso trazia um inconveniente, pois na medida em que crescia
o número de beans gerenciáveis, o arquivo de configuração também crescia na mesma proporção. E
com um número grande desses beans, se tornava complicado gerenciar todas as alterações em três
lugares distintos, porém relacionados: o faces-config.xml, a página JSF e o próprio bean gerenciável.
No exemplo apresentado neste módulo, os beans gerenciados e a regra de navegação poderiam

ter sido configurados no arquivo faces-config.xml da forma mostrada no quadro 25.
Pág. 93 de 130
Quadro 25 - Arquivo faces-config.xml
<?xml version=”1.0”?>
<faces-config xmlns=”http://java.sun.com/xml/ns/javaee”
xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”
xsi:schemaLocation=”http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-facesconfig_1_2.xsd”
version=”1.2”>
<navigation-rule>
<from-view-id>/index.xhtml</from-view-id>
<navigation-case>
<from-outcome>sucesso</from-outcome>
<to-view-id>/sucesso.xhtml</to-view-id>
</navigation-case>
<navigation-case>
<from-outcome>erro</from-outcome>
<to-view-id>/erro.xhtml</to-view-id>
</navigation-case>
</navigation-rule>
<managed-bean>
<managed-bean-name>usuarios</managed-bean-name>
<managed-bean-class>com.jsf2.UsuariosBean</managed-
bean-class>
<managed-bean-scope>session</managed-bean-scope>
</managed-bean>
</faces-config>
No JSF 2.0 não é necessário registrar um bean no arquivo de configuração. Podem-se utilizar
anotações para isso. Dessa forma, o bean e o seu registro ficam no mesmo lugar, na mesma classe
Java. Isso facilita bastante o controle dos beans gerenciáveis, como também deixa mais limpo o
faces-config.xml. Porém, em alguns casos, você será obrigado a registrar os beans no arquivo de
configuração, por falta de alternativa via anotações.
20.2. Escopos de beans gerenciáveis

No JSF 2.0 existem as seguintes anotações para a definição de escopo de beans gerenciáveis:
• @NoneScoped: os beans gerenciáveis de escopo none não são instanciados nem salvos em
nenhum escopo. Eles são instanciados, sob demanda, por outros beans gerenciáveis. Um bean
gerenciável de escopo somente pode instanciar outros beans gerenciáveis de escopo none.
Pág. 94 de 130
• @RequestScoped: os beans gerenciáveis de escopo request são instanciados e permanecem
disponíveis durante uma mesma requisição HTTP. Eles podem instanciar outros beans
gerenciáveis de escopo: none, request, view, session e application.
• @ViewScoped: os beans gerenciáveis de escopo view permanecem disponíveis enquanto o
usuário permanecer em uma mesma página de uma aplicação. Eles podem instanciar beans
de escopo: none, view, session e application.
• @SessionScoped: os beans gerenciáveis de escopo session são salvos na sessão HTTP de
um usuário. Podem instanciar beans de escopo: none, session e application.
• @ApplicationScoped: os beans gerenciáveis de escopo application permanecem disponíveis
equanto à aplicação estiver no ar e podem ser acessados por todos os usuários da aplicação.
Podem instanciar outros beans de escopo: none e application.
• @CustomScoped: os beans gerenciáveis de escopo custom são beans que possuem um
tempo de vida personalizado. Por exemplo, você pode definir um escopo de conversação,
como existe no JBoss Application Server, no qual um bean permanece disponível para um
conjunto de páginas.
Pág. 95 de 130
21. NAVEGAÇÃO CONDICIONAL
Diferentemente da navegação implícita, a navegação condicional é definida juntamente com as
regras de navegação da aplicação, no arquivo faces-config.xml.
Conforme as versões anteriores do JSF, as regras de navegação do JSF 2.0 no faces-config.

xml são definidas através das tags <navigation-rule> e <navigation-case>, dentro de um elemento
<navigation-rule>, os itens <navigation-case> são processados na ordem em que aparecem.
A primeira condição satisfeita fará com que a próxima página a ser mostrada no fluxo de
navegação seja aquela definida na tag <to-view-id>. Para que um <navigation-case> seja satisfeito,
basta que o resultado de um método do bean gerenciável, ou da página de origem, seja igual ao valor
da tag <from-outcome>. A navegação condicional possibilita definir uma verificação a mais dentro
de um <navigation-case>, com o uso da nova tag <if>. O esquema do quadro 26 mostra um exemplo.
Quadro 26 – Exemplo de regra de navegação
<navigation-rule>
<from-view-id>/confirmacao.xhtml</from-view-id>
<navigation-case>
<from-outcome>index</from-outcome>
<if>#{clienteBean.novoCadastro}</if>
<to-view-id>/cadastro.xhtml</to-view-id>
</navigation-case>
<navigation-case>
<from-outcome>index</from-outcome>
<to-view-id>/index.xhtml</to-view-id>
</navigation-case>
</navigation-rule>
21.1. Elementos do JSF

Os elementos do JSF são:
• Estado dos componentes: Mantém automaticamente o estado dos componentes web entre
uma requisição e outra.
• Renderização de componentes: Endereça várias plataformas clientes web.
• Processamento de formulários: Provê mecanismos para o processamento de telas com um
ou vários formulários (sub-views).
Pág. 96 de 130
• Validação: Provê mecanismos para validação de campos e mensagens de erro.
• Internacionalização: Suporte nativo para internacionalização.
• Componentes Visuais: Provêm componentes básicos padrões que podem ser estendidos.
Permite adicionar bibliotecas de terceiros.
• Árvore de componentes: Realiza o alinhamento de um componente dentro de outro para formar
uma interface gráfica. Cada componente possui acesso ao seu pai e filho.
• Facets: Permite adicionar componentes independentes da ordem da árvore. Define uma
relação especial com o componente externo. Muito utilizado em tabelas para definição de
‘cabeçalho’ e ‘rodapé’.
• Eventos: Permite acionamento de listeners sob determinados eventos, exemplo: alteração do
valor de um campo.
Pág. 97 de 130
22. FASES DO CICLO DE VIDA DO JSF
Por trás dos bastidores, FacesServlet aceita requisições de entrada e controla o ciclo de vida
da aplicação através da classe javax.faces.lifecycle.Lifecycle. Usando uma “fábrica”, ela cria um
objeto do tipo javax.faces.context.FacesContext, que contém todos os processos.
O objeto Lifecycle usa o objeto FacesContext em seis fases que compõem o ciclo de vida de
uma aplicação JSF. Cada fase tem uma ação importante em sua aplicação e tem papel importante
no desenvolvimento da aplicação, como mostra a figura 43.
Figura 43 - Ciclo de vida do JSF

Response Response
complete complete
Faces
request
Restore Apply Process Process Process
view requests events validations events
Render response Response Response

complete complete
Faces
response Invoke Update
Render Process Process
response events application events model values
Conversion errors/
render response
Validations/conversion
errors/render response
Fonte: <https://docs.oracle.com/javaee/5/tutorial/doc/bnaqq.html>. Acesso em: 03 set. 201
As seis fases são executadas na seguinte ordem:
1. Restaurar Apresentação: Esta fase inicia o processamento da requisição do ciclo de vida

por meio da construção da árvore de componentes do JSF. Cada árvore de componentes
possui um identificador único durante todo o aplicativo. O JSF constrói a apresentação da
página e salva na instância FacesContext para processamento das fases seguintes.
2. Aplicar Valores Requisitados: Quaisquer novos valores inseridos são extraídos e armazenados
por seus apropriados componentes. Se o valor do componente não for uma string, então ele
é convertido para o seu determinado tipo. Se a conversão falhar, ocorrem diversas situações:
◊ Uma mensagem de erro é gerada e associada com o componente;
Pág. 98 de 130
◊ Uma mensagem de erro é armazenada no FacesContext e depois mostrada posteriormente
na fase de Renderizar a Resposta;
◊ O ciclo de vida pula a fase de Renderizar a Resposta quando esta se completou.
3. Processar Validações: Depois do valor de cada componente ser atualizado, na fase de
processo de validações, os componentes serão validados naqueles valores, se necessário.
Um componente que necessita de validação deve fornecer a implementação da lógica de
validação. Por exemplo, em um carrinho de compras, podemos determinar a quantidade
mínima e máxima a ser digitada. O valor requisitado é um inteiro (verificado na fase anterior)
e, como passou pela fase 2, nessa fase pode ser barrado por estar além do determinado
(com uma quantidade mínima ou máxima diferente da estipulada).
4. Atualizar Valores do Modelo: Alcança-se essa fase após todos os componentes serem
validados. Nesta fase são atualizados os dados do modelo do aplicativo. Na página em
que foi criada para enviar um texto, a informação digitada foi armazenada no Managed
Bean durante esta fase. Por ter passado pelo processo de validação, temos garantias que
o valor armazenado será garantido nessa fase. Entretanto, os dados podem violar a lógica
de negócios, cuja validação ocorre na fase seguinte.
5. Invocar Aplicação: Durante esta fase, a implementação JSF manipula quaisquer eventos
do aplicativo, tal como enviar um formulário ou ir a outra página através de um link. Esses
eventos são ações que retornam geralmente uma string que está associada a uma navegação
a qual se encarrega de chamar a página determinada.
6. Renderizar Resposta: Esta é a fase final, na qual é renderizada a página. Se este é um
pedido inicial para esta página, os componentes são acrescentados à apresentação neste
momento. Se este é um postback, os componentes já foram acrescidos à apresentação. Se há
mensagens de conversão ou erros de validação e a página contém um ou mais componentes
<message /> ou um componente <messages />, estes serão exibidos. Reciprocamente,
se a página não contém um componente de mensagem, nenhuma informação aparecerá.
JSF suporta três tipos de eventos: ValueChange, Action e Phase, descritos no que se segue.
Pág. 99 de 130
23. EVENT
23.1. ValueChange Event

Gerado por componentes UIInput. Um componente tradicional que utiliza esse evento é o
controle <h:selectOneMenu>.
O componente <h:selectOneMenu> é muitas vezes usado para atualizar uma página, atualizar
informações com base no item selecionado ou mesmo para acessar outra página.
A codificação desse componente no JSF 2.0 envolve a utilização de um evento chamado

valueChangeListener. Veja um exemplo:
Quadro 27 – Exemplo de codificação de um evento valueChangeListener
<f:view>
<h:head>
<title>ValueChangeListenet</title>
</h:head>
<h:form>
<table border=”1”>
<tr>
<td>
<h:selectOneMenu value=”#{aluno.curso}”
onchange=”submit()”
valueChangeListener=”#{aluno.valueChangeCurso}”>
<f:selectItems value=”#{aluno.cursos}”/>
</h:selectOneMenu>
</td>
<td>
<h:outputText value=”#{aluno.curso}”/>
</td>
</tr>
</table>
</h:form>
</f:view>
No ManagedBean deve haver o seguinte método:
public void valueChangeCurso(ValueChangeEvent evt){

aluno.setCurso(evt.getNewValue().toString());
}
Pág. 100 de 130

A atualização da página e, consequentemente, das informações, está condicionada à submissão
da página.
Se for desejável uma execução Ajax, a estrutura deve ser como mostrada a seguir:
<f:view>
<h:head>
<title>ValueChangeListenet</title>
</h:head>
<h:form>
<a4j:region>
<table border=”1”>
<tr>
<td>
<h:selectOneMenu value=”#{aluno.curso}” >
<f:selectItems value=”#{aluno.cursos}”/>
<f:ajax listener=”#{aluno.valueChangeCurso2}”
render=”resultado”/>
</h:selectOneMenu>
</td>
<td>
<h:outputText id=”resultado”value=”#{aluno.
curso}”/>
</td>
</tr>
</table>
</a4j:region>
</h:form>
</f:view>
E no ManagedBean, o seguinte método:
public void valueChangeCurso2(AjaxBehaviorEvent evt){

String s = evt.getComponent().
getAttributes().get(“value”).toString();
aluno.setCurso(s);
}
A execução de uma tarefa assíncrona (baseada em Ajax), consiste na API Ajax For JSF (a4j)
disponível com algumas bibliotecas que manipulam Ajax. As mais populares são RichFaces e
PrimeFaces.
Pág. 101 de 130

O atributo render, do elemento <f:ajax> permite transferir o resultado para o controle cujo id é
seu valor. No nosso exemplo, “resultado” é o id da caixa de textos na qual o resultado será exibido
assincronamente.
23.2. Action Event

Gerado por componentes UICommand, esse evento é usado em controles que produzem ação,
como é o caso do commandButton e do commandLink.
23.3. Phase Event

Disparado pelas mudanças de fase do ciclo de vida do JSF. A figura 44 ilustra os eventos nas
diferentes fases.
Figura 44 - Eventos no JSF

Resposta finalizada Resposta finalizada
Requisição
Restaurar Aplicar Processar
Processar Processar
visão valores de validações
eventos eventos
requisição
Renderizar resposta
Nenhum dado
Resposta finalizada Resposta finalizada
requisitado
Resposta Invocar Atualizar

Renderizar Processar Processar
aplicação valores do
resposta eventos eventos
modelo
Erros de conversão/
renderizar resposta Validação ou erros de conversão/
Renderizar resposta
Fonte: <http://www.devmedia.com.br/imagens/javamagazine/wmmejsfp1fig01.jpg>.
Para confirmar como todas as fases do ciclo de vida são usadas e quais são, basta criar um
simples PhaseListener e mandá-lo gerar a saída antes e depois de cada fase.
Pág. 102 de 130

24. CRIANDO UMA CLASSE PHASE LISTENER
Criar uma classe que implemente a PhaseListener exige dois passos:
• Criar uma classe que implemente PhaseListener;

• Registrar essa classe no arquivo de configurações do JSF.
A classe PhaseListener deve implementar a classe javax.faces.event.PhaseListener. O código

do quadro 28 mostra como criar essa classe.
Quadro 28 – Classe TestPhaseLIstener, usada para eventos de mudança de fase
package br.jsf2.listener;
public class TestPhaseListener implements javax.faces.event.
PhaseListener {
public void afterPhase(PhaseEvent event) {
event.getFacesContext().getExternalContext().
log(“AFTER: “+event.getPhaseId());
}
public void beforePhase(PhaseEvent event) {
event.getFacesContext().getExternalContext().
log(“BEFORE: “+event.getPhaseId());
}
public PhaseId getPhaseId() {
return PhaseId.ANY_PHASE;
}
}
Na classe do quadro 28, três métodos são implementados: afterPhase(), beforePhase() e

getPhaseId():
• Os dois primeiros, afterPhase() e beforePhase(), definem o que ocorre ANTES e DEPOIS de

cada fase. Nesses métodos foram incluídos a capacidade de imprimir na saída console o que
ocorreu.
• O terceiro método, getPhaseId(), especifica em qual das fases é invocado este ouvinte
(Listener) e PhaseId.ANY_PHASE menciona que será para todas as fases.
Com a classe criada, o próximo passo é registrar esta classe TestPhaseListener no arquivo de
configurações do JSF (faces-config.xml).
Pág. 103 de 130

Para fazer isso, no arquivo faces-config.xml, adicionaremos os seguintes elementos do trecho
a seguir:
…
<lifecycle>
<phase-listener>
br.jsf2.listener.TestPhaseListener
</phase-listener>
</lifecycle>
…
Pág. 104 de 130

25. CONVERSÃO DE NÚMEROS, DATAS E TEXTOS EM JSF
Apesar do grande número de dados, na web apenas strings são tratados. Por exemplo, um objeto
Date que deva ser analisado, é manipulado como String e, ao ser enviado ao servidor, convertido
para Date. O mesmo comportamento se aplica aos números.
Para exemplificar, suponha uma caixa de textos que receba números representando um dado
monetário. Devemos vincular um conversor ao campo atual com pelo menos dois dígitos após o
ponto decimal, veja:
<h:inputText value=”#{user.amount}”>
<f:convertNumber minFractionDigits=”2”/>
</h:inputText>
Para testar, caro aluno, digite um valor, acrescentando vírgula para separar os centavos e
verifique o resultado. O JavaServer Faces atribuiu 2 casas decimais, no mínimo, como a quantidade
de dígitos decimais.
A manipulação de datas obedece a um padrão específico. Por exemplo, se desejar formatar uma
data para o padrão brasileiro, considere os símbolos: d – dia, M – mês e y – ano. Assim, o padrão
para formatação de datas segue o exemplo a seguir:
<h:outputText id=”date” value=”#{user.date}”>

<f:convertDateTime pattern=”dd/MM/yyyy”/>
</h:outputText>
Analogamente, para formatar um texto, podemos usar:
<h:inputText id=”cartao” value=”#{user.cartao}”>

<f:validateLength minimum=”4” />
</h:inputText>
Apresentamos nas tabelas 18, 19 e 20 do material complementar os principais atributos para

cada formatação.
25.1. Uso de propriedades e o arquivo de propriedades

Propriedades representam pares chave-valor, alguns definidos pelo programador e outras pré-
definidas pela API.
Pág. 105 de 130

As propriedades a serem usadas em um aplicativo são definidas em um arquivo de propriedades
específico, com a extensão .properties, por exemplo, messages.properties. Geralmente o arquivo é
localizado na mesma estrutura de pastas que contém as classes de usuários na aplicação.
Apresentaremos aqui, caro aluno, os passos para criar e manipular propriedades para uma
interface JSF.
Supondo que esse arquivo exista, o próximo passo é definir um grupo de propriedades apropriadas
ao seu aplicativo. Por exemplo, suponha que se deseja criar a interface mostrada na figura 45.
Figura 45 - Formulário JSF
O código Fonte é mostrado no quadro 29.
Pág. 106 de 130

Quadro 29 - Implementação do formulário da Figura 15.2
<f:view>
<h:head>
<f:loadBundle basename=”com.jsf2.messages” var=”msgs” />
<title><h:outputText value=”#{msgs.title}”/></title>
</h:head>
<h:body>
<h:form>
<h1><h:outputText value=”#{msgs.enterPayment}”/></h1>
<h:panelGrid columns=”3”>
<h:outputText value=”#{msgs.amount}”/>
<h:inputText id=”amount” label=”#{msgs.amount}”
value=”#{payment.amount}” >
<f:convertNumber minFractionDigits=”2”/>
</h:inputText>
<h:message for=”amount” />
<h:outputText value=”#{msgs.creditCard}”/>
<h:inputText id=”card” label=”#{msgs.creditCard}”
value=”#{payment.card}” />
<h:panelGroup/>
<h:outputText value=”#{msgs.expirationDate}”/>
<h:inputText id=”date”
label=”#{msgs.expirationDate}”
value=”#{payment.date}”>
<f:convertDateTime pattern=”MM/yyyy”/>
</h:inputText>
<h:message for=”date” />
</h:panelGrid>
<h:commandButton value=”#{msgs.process}” action=”process”/>
</h:form>
</h:body>
</f:view>
</html>
Analisando o código, podemos perceber que todo o texto da interface não está definido no
código, mas são representados por propriedades de um objeto chamado msgs. Esse objeto foi
definido na linha:
<f:loadBundle basename=”com.corejsf.messages” var=”msgs” />
Pág. 107 de 130

Em outras palavras, o arquivo de propriedades é semelhante a uma classe e sua referência
envolve a pasta em que está localizado. O elemento f:loadBundle permite definir um objeto msgs
para acessar as propriedades. Observe, agora, o quadro 30.
Quadro 30 - conteúdo do arquivo de propriedades (messages.properties)
title=An Application to Test Data Conversion

enterPayment=Please enter the payment information
amount=Amount
creditCard=Credit Card
expirationDate=Expiration date (Month/Year)
process=Process
paymentInformation=Payment information
Uma vez definido o arquivo e o objeto referenciado na página jsp, é necessário realizar esta
alteração no arquivo faces-config.xml:
<application>
<message-bundle>com.corejsf.messages</message-bundle>
</application>
Uma das várias utilidades do arquivo de propriedades é a definição de diferentes idiomas, de

acordo com o idioma do usuário. Chamamos este conceito de internacionalização.
Existem diversas variáveis pré-definidas na API JSF, especialmente no que diz respeito às
mensagens de erro para o usuário. Consulte a documentação para maiores detalhes.
Pág. 108 de 130

26. DEFINIÇÃO DE WEB SERVICES
Um requisito básico de qualquer aplicação é prover serviços. Cada empresa oferece serviços para
a sua comunicação com outras pessoas, sejam pessoas físicas ou jurídicas, internas ou externas.
Web services foram criados para construir aplicações que são serviços na internet. Porém, não faz
parte do conceito de Web service a criação de interfaces gráficas para os usuários, deixando esta
parte para outras pessoas desenvolverem.
Web services é a tecnologia ideal para comunicação entre sistemas, sendo muito usado em
aplicações B2B (Business 2 Business). A comunicação entre os serviços é padronizada, possibilitando
a independência de plataforma e de linguagem de programação.
Por exemplo, um sistema de reserva de passagens aéreas feito em Java e rodando em um servidor
Linux pode acessar, com transparência, um serviço de reserva de hotel feito em .net rodando em
um servidor Microsoft.
Para comunicar com o Web service, é necessário uma implementação do protocolo SOAP (Simple
Object Access Protocol) definido no W3C. Esse protocolo é o responsável pela independência que
o Web service precisa.
Na Figura 46 encontra-se um diagrama mostrando as mensagens trocadas entre cliente e

servidor em uma comunicação SOAP. Existem duas aplicações se comunicando, um Client Wrapper
e um Server Wrapper que estão disponibilizando a transparência para as aplicações. Entre eles só
trafega XML, seguindo o protocolo SOAP sobre HTTP.
Figura 46 - Processamento de um web service
SOAP processor
Response
Discrete
WSDL business
logic
Application
Service
Request
SOAP
client SOAP processor
One-Way
Application
WSDL
Application
UDDI
registry Service
Fonte: (KALIN, 2010).
Pág. 109 de 130

Um Web service será publicado, e para que outras pessoas possam utilizá-lo, é necessário definir
como ele é, como deve ser acessado e que valores ele retornará. Estas definições são descritas em
um arquivo XML de acordo com a padronização Web service Description Language (WSDL). Este
arquivo deve ser construído para que os usuários do serviço possam entender o funcionamento
do Web service e será de acesso público.
Os Web services são “escritos” basicamente em SOAP e WSDL, ambas baseadas em XML. Como
SOAP é a mensagem e WSDL o descritor desta mensagem, é importante compreender o conceito
de XML e XSD, usados posteriormente para interpretar informações no formato XML, através do
JAX-WS.
Um Web service é uma lógica de aplicativo acessível a programas através de protocolos web de
um modo independente de plataforma. Um Web service expõe a lógica de aplicativo ou de código.
Esse código pode realizar diversas tarefas.
O conceito de Web services é baseado em um conjunto de protocolos web, como HTTP, XML,
SOAP, WSDL e UDDI e podem ser implementados em qualquer plataforma. O Web service é acessado
por uma aplicação, de qualquer natureza, como mostrado na figura 47.
Figura 47 - Requisição / resposta SOAP em um Web service
Application Application
XML
4 1 2 3
Request
(service invocation)
SOAP SOAP
Network protocol Response Network protocol
Fonte: <http://www.developer.com/java/creating-soap-web-services-with-jax-ws.html>. Acesso em: 04 set. 2014.
Pág. 110 de 130

27. SOAP
27.1. Definição de SOAP

O protocolo SOAP (Simple Object Access Protocol) realiza a comunicação entre o cliente e o
servidor através do protocolo HTTP. Por meio do SOAP especificamos o endereço da máquina para
a qual se estabelece a comunicação.
SOAP é um protocolo simples e leve baseado em XML que proporciona troca de informações
em cima do protocolo HTTP. É um protocolo para acessar Web services.
A arquitetura tem sido desenhada para ser independente de qualquer modelo particular de
programa e de outras implementações específicas.
Os dois maiores objetivos do SOAP são a simplicidade e extensibilidade, e esse protocolo obedece
a esses requisitos, pois trafega em cima do HTTP e o HTTP é suportado por todos os servidores e
browsers do mercado, com diferentes tecnologias e linguagens de programação.
27.2. Estrutura de um arquivo SOAP

Uma requisição para um servidor em SOAP possui a seguinte estrutura:
<SOAP-ENV:envelope>
<SOAP-ENV:header>

</SOAP-ENV:header>
<SOAP-ENV:body>

</SOAP-ENV:body>
</SOAP-ENV:envelope>
Agora vejamos a estrutura da resposta:
<SOAP-ENV:envelope>
<SOAP-ENV:body>

</SOAP-ENV:body>
</SOAP-ENV:envelope>
Pág. 111 de 130

Pela requisição e pela resposta, podemos verificar que um arquivo SOAP possui a seguinte
estrutura:
• Elemento Envelope: Responsável por definir o conteúdo da mensagem

• Elemento Header (opcional): Dados do cabeçalho
• Elemento Body: Contém as informações de chamada de resposta ao servidor
• Elemento Fault: Possui as informações dos erros ocorridos no envio da mensagem. Esse
elemento, obviamente, só aparece nas mensagens de resposta do servidor.
O namespace padrão (o namespace define as regras de codificação que o documento deve

seguir) para o elemento Envelope possui a estrutura:
<soap:Envelope xmlns:soap=http://schemas.xmlsoap.org/soap/envelope/
soap:encodingstyle=http://schemas.xmlsoap.org/soap/encoding/>

</soap:Envelope>
À medida que se avança na estrutura do SOAP, é possível ver que sua codificação é bastante
simples.
27.3. Atributos SOAP

A estrutura de atributos do SOAP é semelhante à estrutura de atributos da XML, e é formada por:
• actor: o atributo actor define a URI (equivalente à URL do HTTP). a qual o HEADER se refere.
Lembrando que o elemento HEADER é opcional dentro do SOAP. Veja a sintaxe deste atributo:
<soap:Header>

<r:mercado xmlns:r=”http://www.mercadao.com.br/valores/”
soap:actor=”http://www.mercadao.com.br/descricao” />
<r:lingua>port</r:lingua>
<r:dinheiro>REAL</r:dinheiro>
</r:mercado>
</soap:Header>
• encodingStyle: esse atributo serve para definir um estilo de codificação do documento. Veja:
<soap:Envelope
xmlns:soap=http://schemas.xmlsoap.org/soap/envelope/
soap:encodingstyle=http://schemas.xmlsoap.org/soap/encoding/>
Mensagem aqui
</soap:Envelope>
Pág. 112 de 130

• mustUnderstand: define qual elemento do HEADER deve aparecer para o receptor da mensagem.
O valor “0” deste atributo significa que o elemento não deve aparecer para o receptor e o valor
“1” significa que esse elemento deve ser visto pelo receptor da mensagem.
<soap:Header>
<r:mercado xmlns:r=”http://www.mercadao.com.br/valores/”/>
<r:lingua soap:mustUnderstand=”0”>port</r:lingua>
<r:dinheiro soap:mustUnderstand=”1”>REAL</r:dinheiro>
</r:mercado>
</soap:Header>
Pág. 113 de 130

28. WSDL
28.1. Definição de WSDL

WSDL é um formato XML para descrever serviços de rede, contendo um conjunto de operações
a serem executadas no sistema remoto, ele é extensível para permitir a descrição do serviço. Suas
mensagens não levam em consideração quais formatos de mensagens ou protocolos de rede são
usados para a comunicação.
Como protocolos de comunicação e formatos de mensagens são padronizadas na comunidade

web, torna-se importante ser capaz de descrever as comunicações em uma forma estruturada. Os
endereços WSDL necessitam, por definição, de uma gramática XML para descrever serviços de rede
como coleções de endpoints capazes de definir mensagens a serem transferidas como serviços.
Um serviço WSDL define documentos como coleções de endpoints de rede, ou portas. No

WSDL, a definição abstrata de pontos finais e mensagens são separadas de suas organizações de
redes concretas ou formatos de dados de comunicação. Isto permite a reutilização de definições
abstratas: mensagens, que são descrições abstratas dos dados sendo trocados, e tipos de portas,
que são coleções abstratas de operações.
28.2. Estrutura WSDL

A estrutura do WSDL é assim composta:
<definitions>
<types>
definition of types........
</types>
<message>
definition of a message....
</message>
<portType>
definition of a port.......
</portType>
<binding>
definition of a binding....
</binding>
</definitions>
Nesta estrutura, podem ser identificados:
Pág. 114 de 130

• Types (tipos) – Um recipiente para definição de tipos de dados usando alguns tipos de sistemas.
WSDL usa sintaxe XML para definir tipos de dados.
• Message (mensagens) – Um resumo de definições de tipos de dados sendo trafegados, pode
conter uma ou mais partes, essas partes podem ser comparadas a parâmetros de uma função.
• portType (Tipo de porta) – Um resumo da configuração das operações suportadas por um
ou mais endpoints.
• Binding (Ligação): Define o formato da mensagem e detalhes de protocolos para cada porta.
28.3. WSDL ports

WSDL Ports são o elemento mais importante no WSDL. Este elemento define o local onde o
serviço será encontrado. Operation Types (Tipos de operação) – são os modos como os serviços
recebem requisições e enviam suas respostas, quais sejam:
• One-Way – A operação pode receber uma mensagem, mas não irá retornar uma resposta.
• Request-response – A operação pode receber uma requisição e retornar uma resposta.
• Solicit-response – A operação pode enviar uma requisição e esperar por uma resposta.
Pág. 115 de 130

29. BINDINGS SOAP
O elemento Binding tem dois atributos, name e type. O atributo name define o nome da ligação
e o type indica o ponto para a ligação da porta, nesse caso o “glossary terms port”.
O elemento soap:binding tem dois atributos, style e transport. O atribiuto style pode ser o “rpc”
ou “documento”, o transport define o protocolo SOAP a ser usado, no caso o http.
29.1. Definição de JAX-WS

A API Java para Web services XML (JAX-WS), JSR 224, é uma parte importante das plataformas
Java EE 5 e EE 6. O JAX-WS simplifica a tarefa de desenvolvimento de Web services utilizando
a tecnologia Java. Aborda alguns dos problemas em JAX-RPC 1.1, fornecendo suporte a vários
protocolos, como SOAP 1.1, SOAP 1.2, XML, e fornecendo um recurso para dar suporte a protocolos
adicionais junto com HTTP. O JAX-WS dá suporte a personalizações para controlar interfaces de
ponto final de serviço geradas. Com suporte a anotações, o JAX-WS simplifica o desenvolvimento
do Web service e reduz o tamanho de arquivos JAR do run-time.
Pág. 116 de 130

30. VINCULANDO WSDL A JAVA COM JAXB
O XML baseado em JAXB facilita o acesso aos documentos XML com base em aplicações escritas
na linguagem de programação Java. O JAXB é uma alternativa ao uso de parser SAX ou DOM para
acessar os dados em um documento XML. Pode-se usar JAXB para construir um documento XML.
Para construir um documento XML com JAXB, primeiro vincule o esquema do documento
XML que deseja construir. Depois, crie uma árvore de conteúdo. Por último, empacote a árvore de
conteúdo em um documento XML.
O diagrama da figura 48 mostra os processos para acessar e construir documentos XML com
base em aplicações Java.
Figura 48 - Arquitetura JAXB
Binding Binding Schema-derived

compiler compiler classes &
interfaces
Application
Unmarshal Content
objects
XML JAXB
document
API
Marshal
Fonte: <https://www.ibm.com/developerworks/cn/websphere/library/techarticles/0910-
jaxb-cbe-ejb3monitor/image001.jpg>. Acesso em: 04 out. 2017.
A seguir apresentaremos um exemplo de um Web service JAX-WS. Após criar o Web service,
escreveremos um cliente Java Servlet.
Vamos criar um Web service que contenha duas operações:
• a primeira recebe como parâmetro uma String e a retorna em ordem invertida.

• a segunda retorna uma lista de cidades com base em um estado, fornecido como parâmetro.
Nosso Web service se chamará OperacoesWS e seu conteúdo será o apresentado no quadro 31.
Pág. 117 de 130

Quadro 31 – Web service OperacoesWS
package com.webservice;
import java.util.ArrayList;
import java.util.List;
import javax.jws.WebService;
import javax.jws.WebMethod;
import javax.jws.WebParam;
@WebService(serviceName = “OperacoesWS”)
public class OperacoesWS {
@WebMethod(operationName = “reverterTexto”)
public String reverterTexto(@WebParam(name = “texto”)
String texto) {
return new StringBuilder(texto).reverse().toString();
}
@WebMethod(operationName = “ListarCidades”)
public List<String> ListarCidades(@WebParam(name = “estado”)
String estado) {
List<String> lista = new ArrayList<String>();
if(estado.equals(“SP”)){
lista.add(“São Paulo”);
lista.add(“Campinas”);
lista.add(“Ribeirão Preto”);
}
else if(estado.equals(“AC”)){
lista.add(“Rio Branco”);
lista.add(“Sena Madureira”);
lista.add(“Cruzeiro do Sul”);
}
return lista;
}
}
Observe as anotações @WebService, @WebMethod e @WebParam. Elas representam,

respectivamente, as definições para um WebService, um método de serviço e um parâmetro de
serviço.
Os parâmetros para cada anotação são apresentados nas tabelas 21, 22 e 23 do material
complementar.
A execução deste Web service produz o resultado mostrado na figura 49, usando-se o servidor
Tomcat:
Pág. 118 de 130

Figura 49 - Resultado da execução do Web service
http://localhost:8084/Operacoes/OperacoesWS
Um cliente deste serviço é gerado a partir do WSDL produzido através da URL:
http://localhost:8084/Operacoes/OperacoesWS?wsdl
Ele permite o download do WSDL para verificar os dados fornecidos pelo cliente. O conteúdo
do WSDL é mostrado no quadro 32.
Quadro 32 – Conteúdo do WSDL

<definitions xmlns:wsu=”http://docs.oasis-open.org/wss/2004/01/
oasis-200401-wss-wssecurity-utility-1.0.xsd” xmlns:wsp=”http://
www.w3.org/ns/ws-policy”xmlns:wsp1_2=”http://schemas.xmlsoap.
org/ws/2004/09/policy” xmlns:wsam=”http://www.w3.org/2007/05/
addressing/metadata”xmlns:soap=”http://schemas.xmlsoap.org/wsdl/
soap/” xmlns:tns=”http://webservice.com/” xmlns:xsd=”http://
www.w3.org/2001/XMLSchema”xmlns=”http://schemas.xmlsoap.org/
wsdl/” targetNamespace=”http://webservice.com/” name=”OperacoesWS”>
<types>
<xsd:schema>
<xsd:import namespace=”http://webservice.com/”
schemaLocation=”http://localhost:8084/Operacoes/OperacoesWS?xsd=1”/>
</xsd:schema>
</types>
<message name=”ListarCidades”>
<part name=”parameters” element=”tns:ListarCidades”/>
</message>
<message name=”ListarCidadesResponse”>
<part name=”parameters” element=”tns:ListarCidadesResponse”/>
</message>
<message name=”reverterTexto”>
<part name=”parameters” element=”tns:reverterTexto”/>
</message>
<message name=”reverterTextoResponse”>
<part name=”parameters” element=”tns:reverterTextoResponse”/>
Pág. 119 de 130

</message>
<portType name=”OperacoesWS”>
<operation name=”ListarCidades”>
<input wsam:Action=”http://webservice.com/OperacoesWS/
ListarCidadesRequest”
message=”tns:ListarCidades”/>
<output wsam:Action=”http://webservice.com/OperacoesWS/
ListarCidadesResponse”
message=”tns:ListarCidadesResponse”/>
</operation>
<operation name=”reverterTexto”>
reverterTextoRequest”
message=”tns:reverterTexto”/>
reverterTextoResponse”
message=”tns:reverterTextoResponse”/>
</operation>
</portType>
<binding name=”OperacoesWSPortBinding” type=”tns:OperacoesWS”>
<soap:binding transport=”http://schemas.xmlsoap.org/soap/http”
style=”document”/>
<soap:operation soapAction=””/>
<input>
<soap:body use=”literal”/>
</input>
<output>
</output>
</operation>
<soap:operation soapAction=””/>
<input>
</input>
<output>
</output>
</operation>
</binding>
<service name=”OperacoesWS”>
<port name=”OperacoesWSPort” binding=”tns:OperacoesWSPortBinding”>
<soap:address
location=”http://localhost:8084/Operacoes/OperacoesWS”/>
</port>
</service>
</definitions>
Pág. 120 de 130

O cliente, como dito anteriormente, é um Servlet. Este Servlet recebe de um formulário um texto
e um estado, e apresenta o resultado. O código para o cliente é mostrado no quadro 33.
Quadro 33 – Código para o cliente

package com.webservice.client;
import java.io.PrintWriter;
import javax.Servlet.annotation.WebServlet;
@WebServlet(name = “ClienteWSServlet”, urlPatterns = {“/clientews”})
public class ClienteWSServlet extends HttpServlet {
@Override
}
@Override
PrintWriter out = response.getWriter();
response.setContentType(“text/html”);
String texto = request.getParameter(“texto”);
String estado = request.getParameter(“estado”);

out.print(“Texto fornecido: “ + texto);
out.print(“<br>Texto invertido: “ +
reverterTexto(texto));
out.print(“<br><br>Estado fornecido: “ + estado);
out.print(“<br>Cidades: “ + listarCidades(estado));
}
private static List< String> listarCidades(String estado) {
com.webservice.OperacoesWS_Service service = new
com.webservice.OperacoesWS_Service();
com.webservice.OperacoesWS port =
service.getOperacoesWSPort();
return port.listarCidades(estado);
}
private static String reverterTexto(String texto) {
Pág. 121 de 130

return port.reverterTexto(texto);
}
}
Uma vez que o Web service é exposto, o cliente executa seus métodos (remotos) seguindo a
forma tradicional.
Pág. 122 de 130

31. PROCESSAMENTO
31.1. Processamento Síncrono

Operações síncronas consistem de chamadas que são executadas sem interrupção. Esta
chamada bloqueia o processo até que a operação seja completada. O diagrama da figura 50 ilustra
o processo síncrono.
Figura 50 - Processamento Síncrono
Oracle e-business suite

Client side
web services
Request Request
Receive synchronous Enqueue the SOAP
SOAP request and request and send
Invoke synchronous response response
web service Response Response
Continue with other

processes
Fonte: https://docs.oracle.com/cd/E26401_01/doc.122/e20925/T511175T626069.htm
Pág. 123 de 130

31.2. Processamento Assíncrono
Uma operação assíncrona não irá bloquear a chamada ao processo, que simplesmente inicia
a operação. Esta operação deverá retornar uma chamada se a aplicação chamadora precisar ser
notificada sobre a operação.
O diagrama da figura 51 ilustra o conceito do processo assíncrono.
Figura 51 - Processamento Assíncrono

Oracle e-business suite
Client side
web services
Request Request
Receive asynchronous Enqueue the SOAP
Invoke asynchronous SOAP request request to asynchronous
web service request queue
(with replyTo address) Response Response
Async queue
Continue with other

processes
Execute service request
Send SOAP response

Receive SOAP response
back via replyTo address
Fonte: https://docs.oracle.com/cd/E26401_01/doc.122/e20925/T511175T626069.htm
O procedimento de uma chamada assíncrona não é tão trivial como uma chamada síncrona,
veja as etapas:
• O cliente obtém um ponteiro para o servidor e chama o método assincronamente.

• O cliente inclui um ponteiro para função chamada função callback.
• A chamada retorna imediatamente e a thread chamada é livre para executar outras linhas de
instrução.
• Quando o processamento do método é finalizado, o servidor notifica o cliente através da
função callback.
31.2.1. Exemplo de chamada assíncrona
Chamar um web service envolve fazer uma chamada por uma rede que poderia potencialmente
causar atrasos por fatores acima de seu controle (por exemplo, tráfico pesado de rede). Em muitos
Pág. 124 de 130

casos, você poderá querer iniciar uma chamada e continuar a executar sua aplicação enquanto
espera o retorno do web service. Isto pode ser feito através da chamada assíncrona do Web service.
Por padrão, as chamadas a Web services são síncronas.
No nosso exemplo de aplicação, o WSDL deve ser alterado para que operações assíncronas
sejam permitidas. Isso é mostrado no quadro 34.
Na aplicação cliente, uma chamada assíncrona deve ser prevista, como mostra o quadro 35. No
código do quadro 34, junto com a chamada do Web service, observa-se que a resposta do serviço
ReverterTexto é manipulada por meio de um objeto AsynchHandler. Enquanto isso, um objeto Future
verifica se foi retornado um resultado e inativa o thread até que o resultado seja concluído.
Quadro 34 – Alterações no WSDL
...
<portType name=”OperacoesWS”>
ListarCidadesRequest” message=”tns:ListarCidades” />
ListarCidadesResponse” message=”tns:ListarCidadesResponse” />
</operation>
reverterTextoRequest” message=”tns:reverterTexto” />
reverterTextoResponse” message=”tns:reverterTextoResponse” />
</operation>
<jaxws:bindings>
<jaxws:enableAsyncMapping>
true
</jaxws:enableAsyncMapping>
</jaxws:bindings>
</portType>
...
Pág. 125 de 130

Quadro 35 - Chamada assíncrona
public void callAsyncCallback(String text){

try { // Call Web service Operation(async. callback)
// TODO initialize WS operation arguments here
java.lang.String texto = text;
AsyncHandler<com.webservice.ReverterTextoResponse>
asyncHandler = new
AsyncHandler<com.webservice.ReverterTextoResponse>() {
public void handleResponse(javax.xml.ws.Response<com.
webservice.ReverterTextoResponse> response) {
try {
// TODO process asynchronous response here
System.out.println(“Result = “ + response.get());
} catch (Exception ex) {
// TODO handle exception
}
}
};
java.util.concurrent.Future<? extends java.lang.Object> result = port.
reverterTextoAsync(texto, asyncHandler);
while (!result.isDone()) {
// do something
Thread.sleep(100);
}
} catch (Exception ex) {
// TODO handle custom exceptions here
}
}
Pág. 126 de 130

CONCLUSÃO
Pudemos aplicar os conceitos de herança, polimorfismo, interfaces, tratamento de erros, acesso
a banco de dados e threads na criação de aplicativos para web, especialmente no tratamento de
thread, gerenciamento de sessão e definição de beans em um framework: o JavaServer Faces!
Pudemos constatar que todas as classes que criamos no Java SE puderam ser aproveitadas
nas nossas aplicações web. Constatamos, também, a importância da orientação a objetos, quando
definimos classes capazes de interagir com outros tipos de aplicações além da web, por exemplo,
aplicações swing.
Da mesma forma que usamos o mecanismo de acesso a dados baseado em JDBC, podemos
também utilizar outros frameworks, como o Hibernate, o JPA, o Ibatis, dentre outros, todos usando
classes capazes de serem reaproveitadas. Todas essas aplicações utilizam tudo o que estudamos.
Pág. 127 de 130

GLOSSÁRIO
Case sensitive - é um anglicismo que se refere a um tipo de análise tipográfica da informática. Em
língua portuguesa, significa algo como “sensível à caixa das letras” ou “sensível a maiúsculas e
minúsculas”. Fonte: wikipedia.
Comunicação sem estado (stateless) - é um protocolo de comunicação que considera cada requisição
como uma transação independente que não está relacionada a qualquer requisição anterior, de
forma que a comunicação consista de pares de requisição e resposta independentes. Um protocolo
sem estado não requer que o servidor retenha informação ou estado de sessão sobre cada parceiro
de comunicação para a duração de várias requisições. Em contraste, um protocolo que exija a
manutenção do estado interno no servidor é conhecido como um protocolo com estado. Fonte:
wikipedia.
Postback - é uma medida tomada por uma página interativa, quando a página inteira e seus conteúdo
são enviados para o servidor para processamento de algumas informações e, em seguida, o servidor
mostra a mesma página de volta ao seu navegador. Fonte: wikipedia.
Request-Response - os objetos Response e Request ainda existem e podem usados em páginas ASP.
NET. Estes objetos representam a informação chegando no servidor Web a partir do navegador(Request)
e a informação saindo do servidor para o navegador(Response). O objeto Request representa o objeto
input e o objeto Response representa o objeto output. Fonte: macoratti.net.
Pág. 128 de 130

REFERÊNCIAS
DELISLE, P. Java Server Pages Standard Tag Library: (Version 1.2). Sun Microsystems, 2006.
GONÇALVES, A. Beginning Java EE 6 Platform with GlassFish 3. Disponível em: <http://digitus.itk.

ppke.hu/~farba/Beginning_Java_EE_6_with_GlassFish_3.pdf>. Acesso em: 05 set. 2014.
GONÇALVES, E. Ajax com JSF 2.0. 2011. Disponível em: <http://www.edsongoncalves.com.br/tag/jsf-2-

0/>. Acesso em: 25 jul. 2014.
IBM . Struts framework and model-view-controller design pattern. Disponível em: <https://www.ibm.
com/support/knowledgecenter/SSRTLW_9.5.0/com.ibm.etools.struts.doc/topics/cstrdoc001.html>. Acesso em:
28 jun. 2014.
IBM KNOWLEDGE CENTER. JAXB. Disponível em: <http://pic.dhe.ibm.com/infocenter/radhelp/v9/

index.jsp?topic=%2Fcom.ibm.webservice.doc%2Ftopics%2Fcore%2Fcjaxb.html>. Acesso em: 12
set. 2014.
INTACCT. Responses from the gateway. Disponível em: <http://developer.intacct.com/wiki/responses-

gateway>. Acesso em: 28 jun. 2014.
JAVA FORUM. JavaServer Faces: Basics. 2008. Disponível em: <http://www.java-forums.org/java-

tutorial/9637-javaserver-faces-basics.html>. Acesso em: 28 jun. 2014.
JUNIOR, E. P. Web services: uma solução para aplicações distribuídas na internet. Disponível em:
<http://www.apostilando.com/download.php?cod=415&categoria=Internet. Acesso em: 14 Ago. 2014.
KALIN, M. Java Web services: Implementando. Porto Alegre: Alta Books Editora, 2010.
MULLER, Nicolas. Internet, intranet e extranet o que são, e quais as diferenças?. Disponível em:
<http://www.oficinadanet.com.br/artigo/1276/internet_intranet_e_extranet_o_que_sao_e_quais_as_diferencas>.
Acesso em: 07 ago. 2014.
NETBEANS. Binding WSDL to Java with JAXB. Disponível em: <https://netbeans.org/kb/74/websvc/jaxb.

html>. Acesso em: 28 jun. 2014.
Pág. 129 de 130

ORACLE. The Java EE 6 Tutorial: Web Applications. Disponível em: <http://docs.oracle.com/javaee/6/
tutorial/doc/geysj.html>. Acesso em: 28 jun. 2014.
REDDY, L. Creating SOAP Web services with JAX-WS. Disponível em: <http://www.developer.com/java/
creating-soap-web-services-with-jax-ws.html>. Acesso em: 28 jun. 2014.
SIGNIFICADOS.COM.BR. Significado de HTTP: O que é HTTP. Disponível em: <http://www.significados.

com.br/http/>. Acesso em: 28 ago. 2014.
Pág. 130 de 130

JJAW

Enviado por

Direitos autorais:

Formatos disponíveis

JJAW

Enviado por

Dados do documento

Descrição original:

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

JJAW

Enviado por

Direitos autorais:

Formatos disponíveis

Atualizado e revisado por

2. Configurando servidor, criando projeto, criando e executando um servlet . . . . . . 21

5. Java Server Pages (JSP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

10. Expressões ou ScriptLets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

12. Passando parâmetros para uma página JSP via URL . . . . . . . . . . . . . . . . . . . . . . . 59

15. Definição de JSTL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

16. Expression Language (EL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

18. Definição de JSF e Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

21. Navegação condicional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

22. Fases do ciclo de vida do JSF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

23. Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

24. Criando uma classe Phase Listener . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

25. Conversão de números, datas e textos em JSF . . . . . . . . . . . . . . . . . . . . . . . . . . 105

27. SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

28. WSDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

29. Bindings SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

30. Vinculando WSDL a Java com JAXB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

31. Processamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

Estudaremos os conceitos de desenvolvimento web em Java, incluindo o mecanismo de requisição

Em muitos casos, os sistemas necessitam de informações de outro sistema, geralmente

1.1. O nascimento da www e da Internet

Podemos definir “HTTP” da seguinte forma:

O funcionamento do protocolo HTTP pode ser visto na figura 1, possui as características:

Figura 1 – Mecanismo de requisição e resposta

HTML. Javascript. PHP, MySQL &

As partes de uma mensagem HTTP são:

• Linha inicial: Especifica o propósito da mensagem ou response;

Os métodos do protocolo HTTP são:

• Método GET (GET /hello/HelloApp?userid=Joao HTTP/1.1): Obtém informações do servidor –

A passagem de parâmetros é realizada como mostra o quadro 1, e é ilustrado na figura 2.

Quadro 1: Requisição a um recurso web via URL

Fonte: elaborado pelo autor

• Cada parâmetro tem um identificador, seguido pelo sinal de igual e valor;

Fonte: elaborada pelo autor

O método GET é ilustrado na figura 3:

• Envia dados através da URI;

Fonte: elaborada pelo autor

O método POST é ilustrado na Figura 4:

• Envia dados através do fluxo da requisição;

Fonte: elaborada pelo autor

1.3. Servidores Web

Figura 5 – Requisição e resposta

Cliente Resposta (response) Servidor

Fonte: elaborada pelo autor

No servidor existe uma estrutura de diretórios devidamente configurada. O acesso externo

Figura 6 – Requisição e resposta – cliente e servidor em diferentes computadores

Local Disk (C:)

Fonte: elaborada pelo autor

Figura 7 – Requisição e resposta – cliente e servidor no mesmo computador

http://127.0.0.1:8000/index.html (LAN) Local Disk (C:)

(cliente e servidor no mesmo computador)

Fonte: elaborada pelo autor

1.4. Aplicações Web

Na plataforma Java, componentes web fornecem funcionalidades dinâmicas para um servidor

1. O cliente envia uma requisição HTTP para o servidor.

Esses passos estão ilustrados na Figura 8.

Figura 8 – Requisições em aplicações web

As aplicações web essencialmente são constituídas por Servlets e páginas JSP:

• Encaminhamento de requests (request dispatching);