framework aplicação web

Prévia do material em texto

Guilherme Augusto Peron Borges 
0402028 - 8° Semestre 
 
 
 
 
 
 
 
FRAMEWORKS PARA O DESENVOLVIMENTO WEB 
 
 
 
 
 
 
 
 
 
Jaguariúna 
2007 
 
 
Guilherme Augusto Peron Borges 
0402028 - 8° Semestre 
 
 
 
 
 
 
 
FRAMEWORKS PARA O DESENVOLVIMENTO WEB 
 
 
 
 
Monografia apresentada à disciplina Trabalho de 
Conclusão de Curso, do curso de Ciência da 
Computação da Faculdade de Jaguariúna, sob 
orientação do Prof. Ms. Peter Jandl Jr., como 
exigência parcial para conclusão do curso de 
graduação. 
 
 
 
Jaguariúna 
2007 
 
BORGES, Guilherme Augusto Peron. Frameworks para o desenvolvimento web. 
Monografia defendida e aprovada na FAJ em 13 de dezembro de 2007 pela banca 
examinadora constituída pelos professores: 
 
 
 
 
 
Prof. Ms. Peter Jandl Jr. 
FAJ - Orientador 
 
 
 
 
 
 
Prof. Ms. Ricardo Menezes Salgado 
FAJ 
 
 
 
 
 
 
Prof. Ms. Christiane Nova Barbato 
FAJ 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
AGRADECIMENTOS 
 
 
Agradeço aos meus pais por terem me apoiado durante todo o curso e em minhas 
decisões. 
 
Agradeço também ao meu professor orientador, Peter Jandl Jr., pela grande ajuda 
durante todo o processo de desenvolvimento deste trabalho, na elaboração da monografia, na 
seleção dos frameworks que seriam utilizados e também na parte prática, onde foi realizado o 
desenvolvimento de dois protótipos de aplicação web. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
BORGES, Guilherme Augusto Peron. Frameworks para o desenvolvimento web. 2007. 
Monografia (Bacharelado em Ciência da Computação) – Curso de Ciência da Computação da 
Faculdade de Jaguariúna, Jaguariúna. 
 
 
RESUMO 
 
 
Uma área que já é de extrema importância para a sociedade atual, e que esta aumentando dia a 
dia, devido à facilidade e flexibilidade que proporciona a seus usuários, é a internet. Devido 
aos benefícios que esta oferece, aplicações são desenvolvidas para que possam ser acessadas 
de qualquer lugar, não ficando restrito ao ambiente de instalação. Para facilitar a construção 
das aplicações web, são utilizados frameworks específicos. Foi realizado um estudo 
comparativo de dois frameworks baseados em componente para o desenvolvimento web, o 
JSF e o Tapestry, ambos utilizando a tecnologia Java (que é amplamente utilizada no mercado 
atual). Como a tecnologia utilizada em comum nos frameworks é o Java, foi feito um estudo 
de como são construídas as aplicações web utilizando o Java, sem nenhum framework 
específico, ou seja, como funciona o JEE, que é uma API que o Java disponibiliza, sendo 
principalmente utilizada no desenvolvimento de aplicações web, um dos principais artefatos 
que o JEE possui, se tratando de aplicações web, são os servlets que são responsáveis pelo 
controle de requisições web que as aplicações geram e conseqüentemente é essencial para a 
construção das aplicações web que utilizam o Java, portanto foi realizado um estudo das 
funcionalidades básicas que os servlets possuem e como estas são utilizadas, já que 
implicitamente os frameworks utilizados no trabalho utilizam o JEE e conseqüentemente 
utilizam os servlets. Também foram tratados especificamente os frameworks JSF e Tapestry, 
explicando suas principais funcionalidades, foi desenvolvido um componente simples em 
ambos os frameworks com eventuais exemplos. Dois protótipos de aplicação web possuindo 
as mesmas funcionalidades e aparências foram desenvolvidos com ambos os frameworks. 
Com o conhecimento obtido na teoria dos estudos e na prática com o desenvolvimento dos 
protótipos, foi realizado um estudo comparativo entre os dois frameworks utilizados no 
desenvolvimento. Neste trabalho foram utilizados somente dois de muitos framewoks web 
baseados em componentes disponíveis no mercado, mas através destes é possível obter um 
conhecimento de como, no geral, são desenvolvidas e como funcionam as aplicações web e 
ter uma visão mais ampla deste paradigma de programação de aplicações web. 
 
 
Palavras-chave: FRAMEWORK, JEE, SERVLET, JSF, TAPESTRY. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
ABSTRACT 
 
 
An area that is already of extreme importance for the actual society, and that is increasing day 
by day, due to facility and flexibility that provides for your users, is the internet. Due to the 
benefits that it offers, applications are developed for being accessed from anywhere, not being 
restricted to the environment installation. To facilitate the construction of web applications, 
are used specifics frameworks. A comparative study was realized for two frameworks based 
on components for web development, the JSF and Tapestry, both using the Java technology 
(which is widely used in the current market). As the technology used in common on 
frameworks is Java, a study was made of how the web applications are built using Java, 
without any specific framework, i.e. how works the JEE, which is a API that Java provides, 
being principally used in the development of web applications, one of the principals artifacts 
that JEE has, been dealing of web applications, are the servlets that are responsible for the 
controlling of the web requests that the web applications generate and therefore it is essential 
for the construction of the web applications that use Java, so a study was realized of the basic 
features that servlets have and how they are used, since that implicitly the frameworks used in 
the work use the JEE and therefore use the servlets. Also was treated specifically the 
frameworks JSF and Tapestry, explaining their main features, was developed a simple 
component in both frameworks with some examples. Two prototypes of web application with 
the same features and appearance were developed with both frameworks. With the knowledge 
gained in the theoretical studies and in the practice with the development of prototypes, was 
realized a comparative study between the two frameworks used in the development. In this 
work were used only two of many web framewoks based on components available on the 
market, but through these it’s possible to get an knowledge of how, in general, are developed 
and how works the web applications and have a broader view of this paradigm of web 
applications programming. 
 
 
Key-words: FRAMEWORK, JEE, SERVLET, JSF, TAPESTRY. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
SUMÁRIO 
 
 
1. INTRODUÇÃO.....................................................................................................................1 
2. METODOLOGIA..................................................................................................................3 
3. APLICAÇÕES WEB .............................................................................................................4 
4. JEE.........................................................................................................................................6 
4.1 Segurança.............................................................................................................................7 
4.2 Componentes .......................................................................................................................7 
4.3 Aplicação em JEE................................................................................................................8 
4.4 Servlet..................................................................................................................................94.5 Exemplo de verificação de login em JEE..........................................................................10 
5. JSF .......................................................................................................................................16 
5.1 Internacionalização............................................................................................................18 
5.2 Backing Beans ...................................................................................................................19 
5.3 Eventos no JSF ..................................................................................................................20 
5.4 Componentes .....................................................................................................................22 
5.5 API para desenvolvimento de componentes gráficos no JSF............................................22 
6. TAPESTRY.........................................................................................................................33 
6.1 Estrutura ............................................................................................................................35 
6.2 Ciclo de processos no Tapestry .........................................................................................37 
6.3 Componentes no Tapestry .................................................................................................39 
6.4 Exemplo de criação de componente ..................................................................................40 
7. DESCRIÇÃO DO PROTÓTIPO.........................................................................................46 
7.1 Descrição do ambiente de teste e desenvolvimento ..........................................................47 
7.2 Desenvolvimento do Protótipo utilizando o JSF ...............................................................48 
7.3 Desenvolvimento do Protótipo utilizando o Tapestry .......................................................54 
8. COMPARAÇÃO JSF X TAPESTRY.................................................................................61 
8.1 Praticidade .........................................................................................................................61 
8.2 Complexidade do ambiente necessário para a utilização do framework ...........................62 
8.3 Quantidade de componentes nativos disponíveis para utilização......................................63 
8.4 Quantidade de componentes de terceiros disponíveis para o framework ..........................63 
8.5 Ferramentas disponíveis para a utilização do framework..................................................64 
8.6 Utilização do framework no mercado atual .......................................................................66 
8.7 Atualizações dos frameworks na atualidade......................................................................66 
 
9. CONCLUSÕES...................................................................................................................68 
10. REFERÊNCIAS BIBLIOGRÁFICAS ..............................................................................69 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Lista de Figuras 
 
 
Figura 3.1 - Ilustação do fluxo de aplicações web .....................................................................4 
Figura 4.1 - Ilustração de dois sistemas JEE multicamadas .......................................................6 
Figura 4.3.1 - Fluxo de sistemas JEE .........................................................................................8 
Figura 5.1 - Nível de abstração de tecnologias utilizadas no JSF ............................................17 
Figura 5.5.1 - Conteúdo do componente gerado no browser do cliente...................................32 
Figura 6.1 - Estrutura básica de uma aplicação Tapestry em um servidor de aplicações ........34 
Figura 6.3.1 - Estrutura de execução de componentes no Tapestry .........................................40 
Figura 6.4.1 - UML com as classes para a criação de componentes no Tapestry ....................43 
Figura 6.4.2 - Conteúdo do componente gerado no browser do cliente...................................45 
Figura 7.2.1 - Tela de login do protótipo desenvolvido em JSF ..............................................48 
Figura 7.2.2 - Menu do protótipo desenvolvido em JSF ..........................................................49 
Figura 7.2.3 - Tela de filtro de funcionário ..............................................................................49 
Figura 7.2.4 - Tela de dados do funcionário.............................................................................50 
Figura 7.2.5 - Tela de filtro do funcionário que será alterado ..................................................50 
Figura 7.2.6 - Tela de alteração do funcionário........................................................................51 
Figura 7.2.7 - Mensagem de alerta para o usuário, referente ao preenchimento dos campos ..51 
Figura 7.2.8 - Mensagem de alerta para o usuário, referente ao formato dos campos .............51 
Figura 7.2.9 - Tela de cadastro .................................................................................................52 
Figura 7.2.10 - Tela de exclusão de funcionários.....................................................................52 
Figura 7.2.11 - Página informando que o funcionário requisitado não existe no sistema........53 
Figura 7.2.12 - Página informando que a operação ocorreu com sucesso................................53 
Figura 7.2.13 - Página informando que a operação não foi realizada por algum erro .............54 
Figura 7.3.1 - Tela de login do protótipo desenvolvido em Tapestry ......................................54 
Figura 7.3.2 - Menu do protótipo desenvolvido em Tapestry ..................................................55 
Figura 7.3.3 - Tela de filtro de funcionário ..............................................................................55 
Figura 7.3.4 - Tela de dados do funcionário.............................................................................56 
Figura 7.3.5 - Tela de filtro do funcionário que será alterado ..................................................56 
Figura 7.3.6 - Tela de alteração do funcionário........................................................................57 
Figura 7.3.7 - Mensagem de alerta para o usuário, referente ao preenchimento dos campos ..57 
Figura 7.3.8 - Mensagem de alerta para o usuário, referente ao formato dos campos .............58 
Figura 7.3.9 - Tela de cadastro .................................................................................................58 
 
Figura 7.3.10 - Tela de exclusão de funcionários.....................................................................59 
Figura 7.3.11 - Página informando que o funcionário requisitado não existe no sistema........59 
Figura 7.3.12 - Página informando que a operação ocorreu com sucesso................................60 
Figura 7.3.13 - Página informando que a operação não foi realizada por algum erro .............60 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Lista de Siglas 
 
 
AJAX - Asynchronous Javascript and XML 
API - Application Programming Language 
CSS - Cascading Style Sheets 
EIS - Enterprise System Information 
EJB - Enterprise JavaBeans 
EL - Expression Language 
HTML - HyperText Markup Language 
HTTP - HyperText Trasfer Protocol 
IDE - Integrated Development Environmet 
JDBC - Java Database ConnectivityJEE - Java Enterprise Edition 
JRE - Java Runtime Environment 
JSF - JavaServer Faces 
JSP - JavaServer Pages 
JVM - Java Virtual Machine 
RAM - Random Access Memory 
SDK - Software Development Kit 
SQL - Structured Query Language 
TLD - Tag Library Descriptor 
UML - Unified Modeling Language 
URI - Uniform Resource Identifier 
URL - Uniform Resource Locator 
XML - Extensible Markup Language 
1 
1. INTRODUÇÃO 
 
 
A internet, ou a web, é de extrema importância para a sociedade, sendo uma das 
principais fontes de informações. De alguns anos para cá, a internet vem crescendo muito e 
conseqüentemente sendo mais exigida pelos usuários, tanto em hardware quanto em software. 
Como exemplo da importância da internet na sociedade e a facilidade que a mesma pode 
trazer, pode-se citar a utilização de sites de comércio, onde uma pessoa pode comprar 
produtos de várias categorias, sem sair de sua casa ou trabalho, ou sites de bancos onde se 
pode controlar uma determinada conta bancária ou até sites em que se pagam contas. 
Conforme Ship (2004), os web sites não permanecem estáticos por muito tempo, ao 
invés disso, são transformados em aplicações web. Uma aplicação web é interativa, o usuário 
final irá interagir com links que devem ser clicados, fomulários que devem ser preenchidos e 
com outras páginas que receberá como resposta, entre outros recursos que uma aplicação web 
oferece, deixando assim de ser somente um site estático. 
Dia a dia os usuários de sistemas ou sites na web estão mais exigentes quanto à rapidez, 
eficácia e qualidade destes sistemas/sites. Portanto para se obter esta qualidade e eficácia em 
um software, é necessário possuir um bom padrão de trabalho atentando-se aos requisitos 
funcionais e requisitos físicos. Um exemplo de requisito físico seria um site na web voltado 
especificamente para um determinado hardware ou sistema operacional, por exemplo, um site 
que necessariamente tem que ser mantido em um servidor Linux, todo o seu desenvolvimento 
tem que ser específico para este sistema operacional (no caso o Linux) e isso pode envolver 
pontos em que não funcione em outros sistemas operacionais, tornando este sistema ou site 
específico para os clientes que possuem servidor Linux. 
Muitas vezes o trabalho para o desenvolvimento de um sistema ou site voltado para a 
web torna-se repetitivo e pouco produtivo, fazendo com que se perca um tempo considerável 
em tarefas que poderiam ser reutilizadas. 
Por exemplo, um sistema de cadastro de produtos que terá dez telas, sendo que o padrão 
para as telas será o mesmo, ou seja, utilizará o mesmo layout, com os mesmos componentes e 
os mesmos formulários para o cadastro e edição de um determinado produto. Uma boa parte 
do processo de desenvolvimento deste produto seria utilizada para a criação dos layouts de 
cada tela e seus respectivos campos e formulários, porém esta tarefa como é repetitiva, 
poderia ser desenvolvida apenas uma vez e ser reutilizada quando fosse necessário, seria 
criado apenas um layout, um formulário e um componente de cada tipo que fosse necessário e 
reutilizado estes mesmos recursos em todas as telas, sem ter que criar especificamente para 
cada tela todo o layout, alterando-se somente o necessário, como os títulos ou nomes dos 
campos. 
Para evitar esse tempo desperdiçado conforme exemplificado, pode-se utilizar um 
framework para a criação destas telas que terão recursos em comum. Um framework, 
conforme a tradução para o português, é um molde de trabalho onde elementos em comum no 
sistema ou no desenvolvimento podem ser reutilizados, evitando assim o desperdício de 
tempo em algo que pode ser reutilizado. 
De acordo com Ship (2004), um framework é um conjunto de classes cooperadoras que 
fazem um padrão reutilizável para uma categoria específica de software. Um framework é 
diferente de uma ferramenta; uma ferramenta é uma coleção de classes reutilizáveis 
individuais, cada classe contendo uma pequena e isolada funcionalidade que é aplicável para 
uma grande variedade de utilidades. 
Voltando ao exemplo, se para a criação do sistema de cadastro fosse utilizado um 
framework, todo o trabalho da criação do layout das telas quem faria seria o framework, ao 
2 
invés de se criar o mesmo layout para cada tela, poderia apenas passar os títulos e nome dos 
campos dos formulários para o framework e o próprio montaria o layout no padrão desejado 
com os labels passados. 
O tempo que se desperdiçaria neste sistema não se restringe somente à criação dos 
layouts ou componentes para cada tela, mas também em eventuais customizações e 
manutenções que podem ser necessárias no decorrer da utilização do sistema. Possuindo um 
bom framework, essas customizações e manutenções muitas vezes podem ser feitas em apenas 
um lugar do sistema e afetaria todo o sistema, não precisando alterar parte a parte do sistema, 
portanto ganha-se tempo. 
Supondo que neste mesmo sistema o cliente quer que o layout tenha alguns pontos 
alterados, com a utilização do framework, poderia alterar o layout de acordo com o que o 
cliente deseja em apenas um ponto, pois o layout de todas as telas é construído a partir deste 
ponto que será alterado, ou seja, o framework será alterado e não tela por tela, sem a 
utilização deste framework que elabora o layout para o sistema, a alteração que o cliente 
deseja seria feita em todas as telas do sistema, ou seja, em vários trechos ao invés de apenas 
um, o que levaria um tempo muito maior. 
Segundo Lieberman (2007), a modelagem de um software complexo pode ser uma 
tarefa desafiadora. Padrões de desenho e análise de modelos são úteis, mas geralmente não 
mostram como aplicar técnicas ou demonstram exemplos de problemas que são similares aos 
que se desejam em um determinado momento. Felizmente, pode-se utilizar frameworks para 
coletar e organizar análise de padrões, modelos, ferramentas, técnicas de organização, 
exemplos e experiência de outros analistas que solucionaram problemas que podem ser 
similares a um determinado problema que se deseja uma solução confiável. 
Com a utilização do framework, o desenvolvedor pode utilizar o tempo disponível mais 
especificamente na camada de negócios do sistema, na parte funcional, o que contribui para 
uma qualidade maior no sistema e conseqüentemente menos problemas. 
A utilização de um bom framework traz muitas outras vantagens ao desenvolvedor e 
algumas dessas outras vantagens serão mostradas neste trabalho que desenvolverá um 
protótipo de uma aplicação web de cadastro de funcionários de uma determinada empresa, 
utilizando dois frameworks baseados em componentes para o desenvolvimento web, o JSF 
(Java Server Faces) (SUN, 2007b) e o Tapestry (ASF, 2007a), ambos utilizando a tecnologia 
Java (DEITEL, H.; DEITEL, P., 2005; JANDL, 2007). 
O trabalho terá os seguintes objetivos: estudar a importância de frameworks baseados 
em componentes para o desenvolvimento web; realizar um estudo comparativo entre dois 
frameworks baseados em componentes para o desenvolvimento web; desenvolver um sistema 
simples com os frameworks utilizados no estudo comparativo e apontar quais foram às 
vantagens e desvantagens entre os frameworks utilizados para o desenvolvimento do sistema. 
 
 
 
 
 
 
 
3 
2. METODOLOGIA 
 
 
O trabalho seguiu uma metodologia tradicional para seu desenvolvimento, sendo 
dividida em etapas, desde o levantamento bibliográfico até a escrita final da monografia, 
ficando da seguinte forma: 
 
1- Levantamento bibliográfico (referências referentes à Java e aos frameworks JSF e 
Tapestry). 
 
 
2- Estudo do framework Java Server Faces (início dos estudos do framework JSF). 
 
 
3- Estudo do framework Tapestry (início dos estudos do framework Tapestry). 
 
 
4- Especificação do protótipo (definição do propósito e das funcionalidadesdo 
protótipo). 
 
 
5- Escrita do relatório parcial. 
 
 
6- Desenvolvimento do protótipo (desenvolvimento dos dois protótipos, um utilizando 
JSF e outro utilizando Tapestry). 
 
 
7- Ajustes (eventuais correções e revisão do material). 
 
 
8- Análise dos resultados (recolhimento e conclusão dos resultados obtidos). 
 
 
9- Escrita da monografia (escrita final da monografia). 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
4 
3. APLICAÇÕES WEB 
 
 
Basicamente, todo sistema web ou site, possui o seguinte ciclo: é feita uma requisição 
pelo usuário, essa requisição é enviada para o servidor e o mesmo faz a devida lógica com a 
requisição recebida, podendo acessar um determinado banco de dados, após a execução da 
lógica, o servidor retorna uma resposta para o usuário. 
Exemplificando, um usuário faz seu login em um sistema web através de um browser, 
após o usuário clicar no botão para ser validado o login, são enviados para o servidor os dados 
informados pelo usuário. O servidor receberá estes dados e executará a lógica para determinar 
se o login daquele usuário é válido ou não, enviando assim uma resposta para o browser do 
usuário, essa resposta pode ser uma nova página redirecionando o sistema, ou uma página 
informando que o login do usuário é inválido. 
 
 
Figura 3.1 - Ilustação do fluxo de aplicações web 
 
Conforme a figura 3.1: 
 
• Browser: é o navegador para os usuários interagirem com páginas HTML (HyperText 
Markup Language); a interface entre o usuário e o servidor, indiretamente, pois o 
usuário apenas tem o trabalho de especificar o que se deseja, e não de enviar os dados 
para o servidor, essa tarefa quem faz é o próprio browser através do protocolo HTTP 
(HyperText Trasfer Protocol). 
 
• Servidor Web: basicamente é um computador que através de um determinado servidor 
instalado, recebe e envia os dados para o computador cliente (usuário), que conforme a 
ilustração são as requisições e as respostas (request e response). 
 
o Os componentes web que estão contidos no servidor web, são os elementos que 
são utilizados para o processamento da devida lógica das requisições recebidas. 
Esses componentes podem ser: 
 
� Serviços específicos do servidor; 
 
5 
� JSP’s (Java Server Pages), que são páginas desenvolvidas e 
processadas em Java, que resulta no final em uma página HTML para o 
processamento no browser do usuário; 
 
� Java Servlets, que basicamente são classes em Java que processa as 
requisições e constrói as respostas que são enviadas para o browser do 
computador cliente; 
 
� Container web, que é responsável pelo controle dos servlets, (neste 
trabalho de conclusão de curso, será utilizado o container web Tomcat 
(ASF, 2007b)); 
 
� Entre outros elementos. 
 
• Banco de Dados: Onde serão armazenadas e consultadas informações referentes ao 
sistema, portanto os componentes web podem também fazer o acesso a banco de dados 
para o armazenamento e consulta de informações, conforme a figura 3.1 (no 
desenvolvimento dos protótipos foi utilizado o banco de dados MySql (Mysql, 2007)). 
 
Os dois frameworks que serão utilizados para o desenvolvimento de um protótipo de um 
sistema web neste trabalho, que são, o JSF (Java Server Faces) e o Tapestry utilizam a 
tecnologia Java em sua implementação e mais especificamente utilizam o JEE (Java 
Enterprise Edition), anteriormente conhecido como J2EE (Java 2 Enterprise Edition), que 
será mais bem detalhado no próximo capítulo. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
6 
4. JEE 
 
 
O JEE é uma plataforma de programação voltada para aplicações web baseadas em 
componentes, que são executadas em um servidor. O JEE faz parte da plataforma Java. 
Através do JEE, pode-se criar sistemas web complexos e contendo portabilidade (pois 
utiliza a tecnologia Java que é independente de sistema operacional, necessitando apenas a 
máquina virtual Java (JVM) instalada no sistema operacional), segurança, e uma boa 
produtividade. No geral o JEE é modelado para o desenvolvimento de aplicações que 
implementam serviços coorporativos, podendo justificar assim o seu significado (Enterprise 
Edition), sendo a edição coorporativa do Java para o desenvolvimento web. 
A plataforma JEE utiliza um modelo de aplicações de multicamadas para aplicações 
coorporativas sendo que a lógica de aplicação é dividida em componentes de acordo com a 
sua função. 
 
 
 
 
Figura 4.1 - Ilustração de dois sistemas JEE multicamadas (SUN, 2007a) 
 
No geral, as aplicações web JEE, são compostas por três camadas dependentes, como 
ilustra a figura 4.1, as máquinas clientes (camada cliente), o servidor JEE (composto pela 
camada web e pela camada de negócio) e o banco de dados ou máquinas dependentes (camada 
de informações) conforme a ilustração. 
 
Camadas presentes em aplicações JEE: 
 
� A camada cliente (cujo termo em inglês é Client Tier), é executada na máquina do 
cliente, podendo ser o computador de um usuário acessando uma aplicação JEE 
através de uma aplicação client-server (que seria a aplicação JEE 1) ou através de 
7 
um browser (que seria a aplicação JEE 2) interagindo com páginas HTML 
dinâmicas. 
 
� A camada web (que possui o termo em inglês Web Tier), é executada no servidor 
JEE, esse servidor podendo ser, por exemplo, o Tomcat que foi utilizado neste 
trabalho para a implementação dos protótipos dos sistemas web. 
 
� A camada de negócio (cujo termo em inglês é Business Tier), também é executada 
no servidor JEE, é onde toda a regra funcional do sistema se localiza. 
 
� A camada de informações (também conhecida pelo termo em inglês EIS 
(Enterprise System Information) Tier), é executada no servidor de informações, 
sendo este um servidor de banco de dados. 
 
 
4.1 Segurança 
 
 
Existem modelos de desenvolvimento de aplicações web coorporativas em que a 
segurança depende de uma plataforma específica, o que não ocorre no JEE, pois o mesmo 
possui a portabilidade que o Java proporciona, tornando-se independente de plataforma. O 
JEE permite o controle de regras de acesso que são definidas pelo desenvolvedor e que são 
executadas no servidor quando requisitadas. 
Segundo Sun (2007a), uma mesma aplicação pode ser executada em vários ambientes de 
segurança sem ter o seu código fonte alterado. 
 
 
4.2 Componentes 
 
 
O JEE é composto por componentes. Um componente JEE é uma unidade funcional de 
software reservada que é agregada a uma aplicação JEE que é composta por classes e arquivos 
que se comunicam com outros componentes. 
 
A especificação do JEE define os seguintes componentes: 
 
• Aplicações clientes e applets que são componentes executados na máquina 
do cliente (são aplicações que no geral são independentes do que se encontra 
no servidor). 
 
• Java Servlets (que será explicado em um tópico posterior), JavaServer Faces 
(framework baseado em componentes que será utilizado na implementação 
de um protótipo de sistema web neste trabalho) e JSP (que também será 
explicado em um tópico posterior) são componentes web que são executados 
no servidor. 
 
• EJB (Enterprise JavaBeans) que são componentes voltados principalmente à 
lógica de negócio e que também são executados no servidor. 
 
Todos estes componentes são escritos na linguagem Java e são compilados e 
interpretados da mesma maneira que qualquer software ou classe desenvolvida em Java seria. 
As diferenças entre classes Java e estes componentes JEE são que os componentes estão 
8 
integrados em uma aplicação JEE, são desenvolvidos para obter uma melhor performance 
juntamente com aespecificação do JEE, são desenvolvidos para obter uma melhor 
produtividade e são executados e gerenciados pelo servidor JEE. 
 
 
4.3 Aplicação em JEE 
 
 
Em um sistema JEE, o fluxo ocorre através da interação entre os elementos do lado 
cliente e os elementos do lado servidor (estes sendo os componentes da camada web e da 
camada de negócio, conforme explicado anteriormente). Segue uma ilustração do fluxo que 
ocorre em sistemas JEE juntamente com sua explicação: 
 
 
 
 
Figura 4.3.1 - Fluxo de sistemas JEE (SUN, 2007a) 
 
Conforme figura 4.3.1: 
 
1. A camada cliente envia uma requisição HTTP (HTTP Request) para o servidor web. 
 
2. O servidor web converte esta requisição HTTP em um objeto HTTPServletRequest (que 
será utilizado em exemplo posteriormente). O objeto HTTPServletRequest é enviado para 
um componente web. 
 
3. O componente web que recebeu o HTTPServletRequest faz o tratamento da requisição 
podendo ter acesso à JavaBeans (uma espécie de componente Java simples). 
 
4. E o mesmo componente pode também ter acesso a um banco de dados. 
 
9 
5. Após o componente web realizar a lógica necessária e gerar conteúdo dinâmico, o 
componente gera o objeto HTTPServletResponse para retornar a resposta ao cliente, ou 
repassa a requisição para um outro componente tratá-la. 
 
6. E finalmente o componente web que ficou com o tratamento final da requisição envia o 
objeto HTTPServletResponse para o servidor web que converte este objeto para uma 
resposta HTTP (HTTP response) e envia para o cliente. 
 
De acordo com Sun (2007a), o processo para criar e executar uma aplicação web é 
diferente do processo de criação das tradicionais classes Java. O processo para a criação, 
organização e execução de uma aplicação web pode ser sumarizada da seguinte forma: 
 
1. Desenvolver o código do componente web. 
 
2. Desenvolver o descritor de construção da aplicação web. 
 
3. Compilar os componentes da aplicação e suas classes de ajuda referenciadas pelos 
componentes. 
 
4. Opcionalmente empacotar a aplicação em uma unidade de construção. 
 
5. Adaptar ou construir a aplicação em um container web (como o Apache Tomcat). 
 
6. Acessar a URL (Uniform Resource Locator) que referencia a aplicação web. 
 
 
4.4 Servlet 
 
 
Servlets são classes Java que são responsáveis pelo controle das requisições realizadas 
pela camada cliente do sistema. São executados através do container web, onde são 
configurados para isto. Uma aplicação JEE padrão é por definição baseada em servlets. 
As páginas HTML, que são visualizadas pelo browser do usuário, utilizam o protocolo 
HTTP, que é para conteúdos estáticos, portanto as páginas HTML são geralmente fixas, ou 
seja, o usuário não consegue uma interação como conseguiria em um sistema desktop, 
podendo apenas interagir com o conteúdo da página através de cliques em links. 
Os servlets conseguem retornar uma nova página HTML para o usuário, esta sendo 
criada dinamicamente de acordo com a lógica implementada no servlet. 
Conforme Ball et al. (2006), a tecnologia dos Java Servlets permite que seja feita a 
definição de classes servlets específicas para HTTP. Uma classe servlet estende as 
capacidades de servidores que mantém aplicações que são acessadas por um modelo de 
requisição-resposta. Contudo, os servlets podem responder a qualquer tipo de requisição, são 
geralmente utilizados para estender as aplicações mantidas por servidores web. 
A requisição do usuário chega até o servidor web sendo uma requisição HTTP, o 
servidor web converte esta requisição em um objeto do tipo HTTPServletRequest e envia para 
o servlet que irá interagir com a requisição do cliente através deste objeto recebido. Após 
realizar a lógica de negócio necessária com a requisição do cliente, o servlet através do objeto 
HTTPServletResponse gera o conteúdo necessário para ser exibido para o usuário (sendo 
portanto um conteúdo dinâmico) e envia este conteúdo para o servidor web, que converte o 
objeto HTTPServletResponse enviado pelo servlet em uma resposta HTTP e retorna esta 
resposta para o usuário, podendo ser uma nova página criada pelo servlet. 
Tecnicamente, os servlets podem ser utilizados para o tratamento de qualquer ambiente 
de requisição/resposta, não sendo necessariamente para ser utilizados apenas com o protocolo 
10 
HTTP. Neste trabalho será utilizado somente o protocolo HTTP incluso no package 
java.servlet.http da API de servlets no JEE. 
 
 
4.5 Exemplo de verificação de login em JEE 
 
 
Para exemplificar a utilização do JEE, será mostrado como é feita uma página de login 
de um sistema web que irá verificar os dados (login e senha) do usuário e fará conexão no 
banco de dados para verificar se esse login é válido, caso seja, é mostrada uma página para o 
usuário informando que o login é válido, caso contrário, será mostrada uma página 
informando que o login é inválido. 
Portanto esse exemplo que poderia ser o login de um sistema conterá: 
 
� Três JSP’s, a index.jsp que será responsável por recuperar as informações 
referente ao login do usuário, a loginValido.jsp que informará ao usuário que o 
login informado é valido e a loginInvalido.jsp que informará ao usuário que o 
login é inválido caso o mesmo não exista cadastrado no banco. 
 
� Um servlet para fazer a validação do login do usuário e redirecionar para as 
páginas loginValido.jsp e loginInvalido.jsp. 
 
� Uma classe para ser feita conexão e acesso ao banco de dados para verificar se 
o login informado existe cadastrado. 
 
Páginas 
 
A página index.jsp será composta por dois campos de texto contidos em um formulário, 
para serem informados o login e a senha, conforme seu código a seguir no exemplo 4.5.1. 
 
<form id="formulario" action="\ServletURL"> 
 <table> 
 <tr><td>Informe os dados para o login:</td></tr> 
 <tr><td>Login: </td><td><input type="text" name="login"/></td></tr> 
 <tr><td>Senha: </td><td><input type="password" name="senha"/></td></tr> 
 <tr><td><input type="submit" name="nome" value="OK"/></td></tr> 
 </table> 
</form> 
 
Exemplo 4.5.1 
 
O campo Login será identificado no servlet por login, conforme a propriedade name do 
campo de texto da JSP. 
Já o campo Senha será identificado no servlet por senha, conforme a propriedade name 
do campo de texto da JSP. Esse é o conteúdo que mais importa da index.jsp. 
 
Seguem nos exemplos 4.5.2 e 4.5.3 os códigos das páginas loginValido.jsp e 
loginInvalido.jsp respectivamente. 
 
• loginValido.jsp 
 
<html> 
 <head> 
 <title>.:: Usuário Logado ::.</title> 
11 
 </head> 
 <body> 
 <b>Login válido!</b> 
 </body> 
</html> 
 
Exemplo 4.5.2 
 
 
• loginInvalido.jsp 
 
<html> 
 <head> 
 <title>.:: Login Inválido ::.</title> 
 </head> 
 <body> 
 <b><font color="red">Login inválido!</font></b> 
 <br> 
 <b><font color="red">Verifique o login e senha 
informados.</font></b> 
 </body> 
</html> 
 
 Exemplo 4.5.3 
 
As duas páginas (exemplo 4.5.2 e 4.5.3) apenas exibem mensagens informando para o 
usuário se o login é válido ou não. 
 
Conexão com o banco de dados 
 
Para ser feita a conexão com o banco será utilizada a classe BancoDados. A classe 
realiza a conexão com o banco através de seu construtor, portanto assim que a classe for 
instanciada será feita a conexão com o banco de dados. 
A verificação do usuário, se o mesmo existe ou não cadastrado no banco de dados será 
realizada pelo método verificaLogin, que recebe como parâmetro o login e a senha do usuário 
e faz a consulta no banco de dados. 
Abaixo seguem os principais pontos do construtor e o método verificaLogin da classe. 
 
• Construtor 
Conforme já mencionado, o construtorserá responsável por realizar a conexão com o 
banco de dados (e consequentemente realizar tratamentos de exceções referente à 
conexão), portanto após a instanciação da classe BancoDados a conexão com o banco 
estará disponível para consulta, alterações e exclusões no banco. 
 
•••• VerificaLogin 
Este é o método responsável por validar se o usuário esta cadastrado no banco ou não. 
 
 public boolean verificaLogin(String pLogin, String pSenha) throws SQLException 
 { 
String sQuery = "SELECT * "+ 
 " FROM USUARIO "+ 
 " WHERE LOGIN='"+pLogin+"' "+ 
 " AND SENHA='"+pSenha+"'"; 
 
Statement st = this.connection.createStatement(); 
 
ResultSet rs = st.executeQuery(sQuery); 
if(rs.first()) 
12 
 return true; 
 
return false; 
 } 
 
 Exemplo 4.5.4 
 
 O trecho de código do exemplo 4.5.4, através dos dois parâmetros recebidos pelo 
servlet (que será explicado em seguida), o login e a senha que o usuário informou na página 
inicial (index.jsp), realiza uma consulta no banco verificando se existe cadastrado o usuário ou 
não, caso exista, é retornado true, caso não exista é retornado false para o servlet que invocará 
este método. 
 
Servlet 
 
O usuário entrará com os dados do login na página index.jsp e irá clicar no botão Salvar 
para submeter os dados ao servidor. 
O servidor web receberá os dados informados através de uma requisição HTTP e 
encaminhará a requisição do usuário para o servlet através do objeto HttpServletRequest 
(convertido de uma requisição HTTP). 
O servlet, conforme já explicado, é responsável pelo controle das requisições realizadas 
pelo cliente e é executado pelo servidor web. 
Para o servidor web executar um determinado servlet, é necessário que esse servlet 
esteja pré-configurado no servidor. No exemplo que segue, o servidor web utilizado é o 
Tomcat e a configuração de um servlet no Tomcat é feita através do arquivo web.xml, 
conforme exemplo 4.5.5. 
 
• web.xml 
 
Dentre outras configurações que o arquivo web.xml contém referente ao Tomcat, segue a 
configuração do servlet que será responsável por verificar se o login do usuário é válido 
ou não. 
 
<servlet> 
 <servlet-name>ServletExemplo</servlet-name> 
 <servlet-class>ServletBanco</servlet-class> 
</servlet> 
<servlet-mapping> 
 <servlet-name>ServletExemplo</servlet-name> 
 <url-pattern>/ServletURL</url-pattern> 
</servlet-mapping> 
 
Exemplo 4.5.5 
 
A tag <servlet> é onde se declara o nome e a classe do servlet, neste exemplo o nome 
do servlet será ServletExemplo e a classe Java do servlet será a ServletBanco. 
O servidor web executa um servlet de acordo com a URL que o usuário acessa, ou seja, 
um determinado servlet será executado quando a URL acessada pelo usuário for a que está 
configurada para este servlet. 
No exemplo 4.5.5 o servlet ‘ServletExemplo’ só será executado pelo servidor web (ou 
seja, pelo Tomcat) quando o usuário ou o sistema acessar a URL ServletURL, não só o 
usuário acessa uma determinada URL, como também o sistema pode redirecionar aplicação 
para uma determinada URL que é o que esta sendo feito pelo form de login da página 
index.jsp na propriedade action, conforme exemplo 4.5.1 (<form id="formulario" 
13 
action="\ServletURL">). Portanto a propriedade action do form é para onde será 
redirecionado o sistema após o clique no botão de submit do form, que neste exemplo é o 
botão OK, conforme consta no exemplo 4.5.1. 
Após o clique no botão de OK, o servidor web executará o servlet ‘ServletExemplo’, 
pois o form redireciona para a URL configurada para este servlet (/ServletURL). Segue os 
principais trechos da classe Java ‘ServletBanco’ também configurada no web.xml para o 
servlet ‘ServletExemplo’. 
Todo servlet deve herdar a classe HttpServlet a qual possui métodos utilizados para o 
tratamento de serviços HTTP. Portanto a classe deve possuir em sua declaração o extends 
HttpServlet, que no Java o extends é a palavra chave para herdar uma e somente uma classe 
(DEITEL, H.; DEITEL, P., 2005; JANDL, 2007). 
 
Declaração da classe: 
public class ServletBanco extends HttpServlet 
 
Em todo formulário de uma página HTML (form), pode ser feita uma requisição ao 
servidor web, esta podendo ser do tipo GET (default) ou POST. A diferença entre os dois 
métodos esta na codificação que o browser faz com os dados do formulário, no método GET 
os dados são passados através da URL sendo visível ao usuário (é passado como parâmetros 
na URL, separados por ‘?’ inicialmente e ‘&’ a partir do primeiro parâmetro’, por exemplo, a 
URL ‘http://www.testeparams.com/index.html?id=1&flag=2&teste=3’, estaria enviando os 
atributos id, flag e teste para o servidor com os respectivos valores 1, 2 e 3, sendo visível ao 
usuário através da URL), já no método GET os valores não ficam visíveis para o usuário na 
URL. Portanto é recomendável a utilização do GET somente quando se necessita do retorno 
de algum dado, já o POST pode envolver qualquer recurso, como armazenar ou alterar algo 
em um banco de dados ou enviar um e-mail. 
O servlet possui os métodos doGet e doPost que são executados de acordo com o 
método definido pelo form (GET ou POST), ou seja, se o método do formulário for o GET, ao 
executar o servlet, é invocado o método doGet e se for o método POST é invocado o método 
doPost do servlet. 
Como não foi definido nenhum método no formulário do exemplo 4.5.1, será utilizado o 
método GET, pois conforme mencionado o método GET é o default, ou seja, quando não se 
especifica qual o método que será utilizado em um formulário, é utilizado o método GET. 
No exemplo não faz diferença se o método do form é GET ou POST, independentemente 
do método, o servlet terá que realizar a mesma tarefa, que é a validação do login. Portanto 
conforme segue no exemplo 4.5.6, os método doGet e doPost invocam um mesmo método, o 
validaLogin que faz o tratamento da validação do login. 
 
protected void doGet(HttpServletRequest request, HttpServletResponse response) 
throws ServletException, IOException 
{ 
 validaLogin(request, response); 
} 
 
protected void doPost(HttpServletRequest request, HttpServletResponse response) 
throws ServletException, IOException 
{ 
 validaLogin(request, response); 
} 
 
Exemplo 4.5.6 
 
Segue no exemplo 4.5.7, o método invocado tanto pelo doGet quanto pelo doPost. 
14 
 
1. protected void validaLogin(HttpServletRequest request, HttpServletResponse 
response) 
2. throws ServletException, IOException 
3. { 
4. String login = request.getParameter("login"); 
5. String senha = request.getParameter("senha"); 
6. 
7. BancoDados con = new BancoDados(); 
8. RequestDispatcher dispatcher; 
9. try 
10. { 
11. if(con.verificaLogin(login, senha)) 
12. { 
13. dispatcher = request.getRequestDispatcher("/loginValido.jsp"); 
14. } 
15. else 
16. { 
17. dispatcher = request.getRequestDispatcher("/loginInvalido.jsp"); 
18. } 
19. } 
20. catch(SQLException sql) 
21. { 
22. dispatcher = request.getRequestDispatcher("/erro.jsp"); 
23. System.err.println("Erro em verificação no banco de dados"); 
24. sql.printStackTrace(); 
25. } 
26. 
27. dispatcher.forward(request, response); 
28. } 
 
Exemplo 4.5.7 
 
O método validaLogin primeiramente recupera os dados do login informados pelo 
usuário (o login e a senha) do request que é onde os dados do form estão armazenados, 
conforme as linhas 4 e 5 do exemplo 4.5.7. Para recuperar estes dados do request, é 
necessário invocar o método getParameter no request passando como parâmetro a 
propriedade name do campo que se deseja recuperar, especificado no formda página. 
Conforme o exemplo 4.5.1, os atributos name dos dois campos (Login e Senha), são: login e 
senha. Portanto o login e a senha informada pelo usuário estão armazenados respectivamente 
nas Strings login e senha do método validaLogin. 
Tendo o login e senha, é necessário agora verificar no banco de dados se este login 
informado pelo usuário existe ou não. Esta verificação é feita através do método verificaLogin 
do exemplo 4.5.4, este fazendo parte de uma classe chamada BancoDados que foi instanciada 
no servlet na linha 7. 
O método verificaLogin recebe por parâmetro, duas Strings, sendo o login e a senha do 
usuário e como já foi recuperado ambos, é chamado o método verificaLogin passando os dois 
dados do login do usuário na linha 11. Caso o login do usuário exista no banco de dados, o 
método retorna true, fazendo entrar na validação que insere no request a página 
loginValido.jsp através do método getRequestDispatcher (conforme linha 13) para 
posteriormente ser redirecionada a aplicação através do método forward, caso o login não 
exista no banco de dados, é redirecionado para a página loginInvalido.jsp (linha 17). 
Seguindo a boa prática de programação, foi feito um tratamento caso ocorra algum erro 
na verificação do login no banco, utilizando o recurso de tratamento de exceções que o Java 
disponibiliza (o bloco try/catch). Caso ocorra algum erro na verificação no banco de dados 
(este sendo a exeção), é inserido no request o redirecionamento da página erro.jsp. 
15 
E finalmente na linha 27 são redirecionados o request e o response para a página que foi 
determinada pela lógica aplicada. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
16 
5. JSF 
 
 
O JSF é um framework para o desenvolvimento web que utiliza a plataforma Java (JEE), 
portanto é multiplataforma (é um dos frameworks utilizados para o desenvolvimento do 
protótipo de um sistema web neste trabalho), todas as aplicações JSF são aplicações web Java 
padrão que controlam as requisições e respostas HTTP via Servlet e eventualmente utiliza 
tecnologias para a visualização do conteúdo gerado (que pode ser dinâmico) como a Java 
Server Pages (JSP). 
Também conhecido por Faces, o JSF faz com que se torne mais fácil o desenvolvimento 
web baseado em componentes, o framework possui vários componentes gráficos prontos, 
como tabelas, caixas de texto, botões, entre outros, sendo que cada componente não é um 
simples componente HTML, estes possuem suas propriedades no JSF que visa facilitar o 
desenvolvimento e conseqüentemente ganhar produtividade e tempo de desenvolvimento. 
Netbeans (2007a), o framework JSF é uma API (Application Programming Language) 
padrão Java para a construção de componentes de interface com o usuário em aplicações web. 
Pode-se pensar que o JSF seria uma caixa de ferramentas cheia de componentes prontos para 
serem utilizados e que podem ser facilmente e rapidamente reutilizados em aplicações web. 
Estes componentes podem ser simples, como um campo para a entrada de um texto, ou 
complexos, como um campo de data formatado que exibe uma janela pop-up para a seleção 
da data. 
Existem projetos como o MyFaces da Apache (ASF, 2007c) que possuem outros 
componentes prontos com suas próprias características, estendendo assim as possibilidades de 
usabilidade de componentes, não se limitando apenas aos componentes nativos do JSF, sendo 
que é possível também ser desenvolvido um componente de acordo com uma 
situação/problema que o desenvolvedor deparar. Portanto o JSF facilita muito o 
desenvolvimento de interfaces com o usuário para sistemas web em Java. 
 
As classes JSF podem ser organizadas em quatro principais categorias: 
 
• Aplicação: são divididas em duas áreas, a classe Application que representa a 
aplicação como um todo e as lógicas da aplicação que são organizadas em 
backing beans que serão explicados posteriormente. Similar ao ServletContext 
em relação à servlets. 
 
• Contexto: basicamente são classes utilizadas para ser feito o acesso nos dados 
contidos na requisição atual, podendo-se fazer uma analogia com o 
HttpServletRequest utilizado nos servlets. 
 
• Tratamento de eventos: responsável pelo tratamento da interação que o usuário 
faz com a aplicação, como acessar um botão ou alterar o valor de um campo de 
texto. Nos servlets os eventos são o request e no JSF os parâmetros do request 
são transformados em objetos de evento e podem ser escritos listeners pelo 
desenvolvedor para ser feito o tratamento destes eventos. 
 
• Componentes para interface gráfica com o usuário que é toda a visão que o JSF 
disponibiliza ao usuário que pode ser controlada com código Java. Estes 
componentes não tendo uma equivalência com os servlets, pois estes não 
possuem um modelo de componentes do mesmo nível. 
 
O JSF possui componentes que são orientados a evento, assim como uma aplicação 
desktop desenvolvida com a utilização de AWT/SWING trataria o evento do acionamento de 
17 
um botão, o JSF trataria basicamente da mesma forma, exceto pelo fato do tratamento das 
requisições e respostas HTTP. Entre algumas facilidades que o JSF proporciona, esta a 
validação que pode ser feita nos componentes, como por exemplo, a restrição de um valor 
inserido em um componente de inserção de texto na página será validada pelo framework, não 
necessitando assim o desenvolvedor construir uma classe específica para validação. 
Com este recurso de eventos que os componentes do JSF proporciona, o desenvolvedor 
em momento algum necessita ter contato direto com servlets, a não ser em casos extremos em 
que é necessária a implementação de servlets no framework, mas isso não quer dizer que o 
JSF não utiliza servlets, pois conforme já explicado, o JSF utiliza a tecnologia JEE, esta 
possuindo a interação com servlet, portanto, mesmo o desenvolvedor não tendo o contato 
direto com os servlets, o framework internamente faz todo o tratamento de requisições e 
respostas HTTP e faz a devida utilização de servlets quando necessário. 
 
 
Figura 5.1 - Nível de abstração de tecnologias utilizadas no JSF (MANN, 2005) 
 
A figura 5.1 mostra o nível de abstração entre as tecnologias que o JSF utiliza, desde o 
servidor web que começa o tratamento das requisições do usuário (requisições e respostas 
HTTP), a API de servlets, que são os métodos e classes disponibilizadas para a utilização dos 
servlets, as JSP’s que são as páginas escritas em Java que no final resultam em HTML, até a 
18 
própria utilização do framework que é onde se consegue obter o maior nível de abstração, 
conforme mostrado na figura 5.1. 
 
 
5.1 Internacionalização 
 
 
Uma funcionalidade importante que grandes aplicações devem ter é a 
internacionalização das mensagens que a mesma exibe. Se uma aplicação é utilizada em mais 
de um país, suas mensagens devem ser de acordo com o idioma acessado. Por exemplo, uma 
mesma aplicação é utilizada no Brasil e na Inglaterra, e esta aplicação possui uma mensagem 
de “Bem-Vindo” na página inicial, o desenvolvedor não precisaria criar duas páginas de 
início, uma contendo o “Bem-Vindo” para os usuários que acessam a aplicação no Brasil e 
outra contendo “Welcome” para os que acessam na Inglaterra, poderia-se criar arquivos que 
conteriam a devida tradução da mensagem e uma mesma página acessa estes arquivos para 
recuperar a mensagem devidamente traduzida, separando as páginas das mensagens de 
tradução, facilitando assim a manutenção do sistema. 
As aplicações JSF suportam a internacionalização de seu conteúdo, podendo assim 
modificar os labels e mensagens do sistema de acordo com o idioma que o usuário esta 
acessando. 
Uma aplicação é pré-configurada com os idiomas quese tem suporte e possui um 
ResourceBundle (arquivo que contém as mensagens utilizadas no sistema com sua devida 
tradução, cada idioma possui um ResourceBundle) contendo as mensagens traduzidas para 
cada idioma suportado. 
Para ser feita esta internacionalização, primeiramente é necessário que esteja 
configurado no arquivo faces-config.xml quais os idiomas suportados pela aplicação e 
posteriormente é feito a instanciação de um ResourceBudle (presente no Java SDK (Software 
Development Kit), na package java.util.ResouceBundle), para recuperar a localização base dos 
ResourceBundles do sistema é necessário invocar o método getMessageBundle do objeto que 
representa a aplicação, portanto se utilizaria o seguinte comando: 
application.getMessageBundle() e a partir do nome base do ResourceBundle, é criado um de 
acordo com o idioma do usuário, onde poderão ser recuperadas as mensagens pré traduzidas 
do idioma determinado. 
 
• Configuração dos idiomas da aplicação no arquivo faces-config.xml: 
 
 <application> 
 <locale-config> 
 <default-locale>pt</default-locale> 
 <supported-locale>en_US</supported-locale> 
 </locale-config> 
 <message-bundle> 
 resource.mensagens.ArquivoDeMensagens 
 </message-bundle> 
 </application> 
 
 Exemplo 5.1.1 
 
• Recuperação do local das mensagens: 
 
String diretorio = facescontext.getApplication().getMessageBundle(); 
19 
A string ‘diretorio’ após o comando realizado teria o valor 
‘resource.mensagens.ArquivoDeMensagens’ que foi recuperado do arquivo de 
configuração faces-config.xml, conforme exemplo 5.1.1. Tendo o caminho do 
ResourceBundle ‘ArquivoDeMensagens’ é feito o tratamento para a recuperação das 
mensagens traduzidas do ResourceBundle do idioma solicitado (este é recuperado 
através do local da aplicação do usuário, que se obtém no JSF pelo comando 
facescontext.getViewRoot().getLocale()). Se o idioma do usuário fosse o inglês dos 
Estados Unidos, o ResourceBundle que conteria as mensagens traduzidas para o inglês 
seria o ‘ArquivoDeMensagens_en_US’. 
 
 
5.2 Backing Beans 
 
 
Backing Bean é um dos recursos mais importantes e utilizados no JSF, são classes Java 
que fazem o tratamento de eventos e determinadas lógicas no JSF. São as classes que 
possuem os métodos que são executados ao usuário clicar em um link ou em botão por 
exemplo. 
Segundo Mann (2005), Backing Beans são JavaBeans especializados que coletam 
valores dos componentes de interface com o usuário e implementam métodos de listener 
events. Podem também tratar referências para os componentes de interface com o usuário. 
Os Backing Beans são configurados no arquivo de configuração do JSF, o faces-
config.xml, onde é mencionado qual a classe Java que o backing bean utilizará, o nome que 
será invocado nas JSP’s para ser feito o acesso a este backing bean e o escopo que terá na 
aplicação, podendo ser definido para ser uma classe que será instanciada somente uma vez na 
aplicação, podendo ser reutilizada essa instancia durante todo o ciclo da aplicação ou então 
ser definido este backing bean para manter sua instancia somente durante a sessão do 
usuário. 
Segue um exemplo de como é configurado um backing bean e como este é invocado por 
uma JSP. 
Primeiramente deve-se configurar o backing bean no arquivo faces-config.xml da maneira 
como segue no exemplo 5.2.1. 
 
 1. <managed-bean> 
 2. <description>Descrição do Backing Bean</description> 
 3. <managed-bean-name>teste</managed-bean-name> 
 4. <managed-bean-class>beans.BackingBeanTeste</managed-bean-class> 
 5. <managed-bean-scope>session</managed-bean-scope> 
 6. </managed-bean> 
 
 Exemplo 5.2.1 
 
Conforme exemplo 5.2.1, um backing bean é declarado através da tag <managed-
bean>, esta possuindo os seguintes atributos: 
 
• <description>: descricaçãodo backing bean declarado, pode ser utilizado para 
especificar qual a funcionalidade do backing bean na aplicação, facilitando a 
manutenção. 
 
• <managed-bean-name>: o nome pelo qual o backing bean será invocado nas 
JSP’s. 
 
• <managed-bean-class>: a classe Java que será o backing bean. 
 
20 
• <managed-bean-scope>: o escopo que a instância deste backing bean será 
mantido na aplicação. Pode-se utilizar os seguintes escopos: none (a cada 
acesso ao backing bean, uma nova instância é criada), session (o backing bean 
irá manter sua instância durante a sessão), application (manterá a instância do 
backing bean durante toda a aplicação) e request (a instância será mantida 
durante a requisição que esta sendo feita). 
 
Após o backing bean estar devidamente configurado, o mesmo já pode ser invocado por 
uma JSP da seguinte forma: 
 
1. <h:commandButton id="commandButton" 
2. type="submit" 
3. value="Invocar Backing Bean" 
4. action="#{teste.metodoTeste}"/> 
 
Exemplo 5.2.2 (Botão que ao ser clicado invoca o método ‘metodoTeste’ do backing bean 
‘teste’). 
 
Na JSP o backing bean é invocado através do nome determinado no arquivo de 
configuração na tag <managed-bean-name> (que conforme exemplo 5.2.1 é teste) 
juntamente com o método que será executado, ficando da seguinte forma: 
‘nomeDoBackingBean.nomeDoMetodo’, como se encontra no exemplo 5.2.2 na linha 4. 
 
 
5.3 Eventos no JSF 
 
 
Um evento é uma ação que usuário realiza no sistema, como o clique em um botão, o 
arrastar de um objeto ou a digitação de alguma tecla. 
O JSF suporta o tratamento de eventos em componentes, portanto se o usuário clicar em 
um botão ou em um link (componentes do JSF), essa ação irá gerar um evento que será 
tratado em uma classe Java especificada naquele componente em que o usuário provocou o 
evento. 
Tecnicamente, um evento é uma instância da classe ActionEvent que fica localizada na 
package javax.faces.event. A classe ActionEvent implementa a interface ActionListener, 
localizada também na package javax.faces.event. 
O eventos criados pelos componentes JSF são adicionados na instância corrente da 
classe FacesContext. 
Uma funcionalidade muito utilizada no JSF é a integração dos eventos com os backing 
beans, que clicando em um botão, por exemplo, é executado um determinado método de um 
backing bean. 
Para exemplificar o tratamento de eventos que o JSF proporciona, segue um exemplo de 
um botão que ao ser clicado, o framework envia o evento à classe Java respectiva daquele 
botão (o backing bean). 
O exemplo que segue é referente ao evento de um clique de botão em uma JSP que ao 
ser clicado é executado o método imprime de um backing bean que apenas imprime na saída 
padrão o texto ‘Método do Backing Bean Executado!’. 
 
Backing Bean 
 
• Configuração do Backing Bean no arquivo faces-config.xml: 
21 
 
 1. <managed-bean> 
 2. <description>Teste de Backing Bean</description> 
 3. <managed-bean-name>testeBackingBean</managed-bean-name> 
 4. <managed-bean-class>beans.TesteBackingBean</managed-bean-class> 
 5. <managed-bean-scope>session</managed-bean-scope> 
 6. </managed-bean> 
 
 Exemplo 5.3.1 
 
• Classe Java que será o backing bean: 
 
1. package beans; 
2. 
3. public class TesteBackingBean 
4. { 
5. public void imprime() 
6. { 
7. System.out.println("Método do Backing Bean Executado!"); 
8. } 
9. } 
 
Exemplo 5.3.2 
 
O backing bean possui apenas um método, o imprime (linha 5 do exemplo 5.3.2) que 
nada mais faz que imprimir na saída padrão o texto ‘Método do Backing Bean Executado!’. 
 
JSP 
 
Configurado o backing bean, será desenvolvida agora a JSP que conterá o botão que ao 
ser clicado executará o método imprime do backing bean. 
 
1. <%@ tagliburi="http://java.sun.com/jsf/core" prefix="f" %> 
2. <%@ taglib uri="http://java.sun.com/jsf/html" prefix="h" %> 
3. 
4. <f:view> 
5. <html> 
6. <body> 
7. <h:form> 
8. <h:commandButton id="commandLogar" 
9. type="submit" 
10. value="Clique Aqui" 
11. action="#{testeBackingBean.imprime}"/> 
12 . </h:form> 
13. </body> 
14. </html> 
15. </f:view> 
 
Exemplo 5.3.3 
 
Referente ao exemplo 5.3.3, primeiramente são incluídas as taglibs necessárias para a 
utilização da API do JSF, nas linhas 1 e 2. 
Dentro do <h:form> (responsável pela renderização de um form na página HTML que 
será gerada ao final) na linha 7 é inserido o botão e no JSF para inserir um botão com um 
evento que executa um determinado método de um backing bean é necessário a utilização do 
commandButton, conforme linha 8. O commandButton possui vários atributos, mas neste caso 
foram utilizados o id (identificador do botão na página HTML que será renderizada), type 
22 
(tipo do botão, neste caso será o botão de envio das informações do form, ou seja, o submit), 
value (texto que botão conterá) e finalmente o action que é ação que será realizada pelo 
commandButton ao ser clicado e neste exemplo será executado o método imprime do backing 
bean ‘TesteBackingBean’, quando se faz referência à backing beans em JSP’s, utiliza-se o 
nome do backing bean que foi determinado no arquivo de configuração faces-config.xml no 
atributo <managed-bean-name>, conforme linha 3 do exemplo 5.3.1 que neste caso é 
testeBackingBean, ficando portanto no atributo action do commandButton o nome do backing 
bean seguido por seu método que será invocado (testeBackingBean.imprime). 
Após o usuário clicar no botão ‘Clique Aqui’ na pagina HTML, será executado o 
método imprime (linha 5 do exemplo 5.3.2) e conseqüentemente será impresso na saída 
padrão o texto ‘Método do Backing Bean Executado!’. 
 
 
5.4 Componentes 
 
 
O JSF é um framework baseado em componentes e estes facilitam o desenvolvimento e 
aumentam a produtividade, uma vez utilizando-os, se obtém um reaproveitamento de código 
mais amplo. A utilização de componentes pode também trazer uma qualidade maior na 
aplicação, utilizando componentes de terceiros que possuem uma credibilidade boa no 
mercado e que é confiável, a aplicação estará implementando também a melhor maneira em 
que poderia ser feita aquela tarefa que o componente é responsável por fazer, sendo que o 
componente foi desenvolvido seguindo as melhores práticas e engenharias de software pela 
empresa que o disponibilizou. 
Além dos vários componentes prontos que o JSF possui, o framework contém também 
uma API específica para a construção de componentes, estes portanto podendo ser 
desenvolvidos por terceiros. Um exemplo de componentes de terceiro, são os componentes 
desenvolvidos pelo projeto MyFaces (ASF, 2007c), o projeto possui componentes para 
diversas tarefas, estendendo assim a quantidade de componentes em que se pode ter acesso na 
utilização do JSF. 
Mesmo existindo os componentes de terceiros e os nativos do JSF, um sistema ou uma 
aplicação pode se deparar em uma situação em que a utilização de um componente facilitaria 
muito, além de trazer todas as vantagens mencionadas referente à utilização de componentes, 
mas nem o JSF e nem terceiros possuem um componente com estas características desejadas 
pela solução. É partindo deste ponto em que se torna necessário a construção de seu próprio 
componente, fazendo com que este possua todas as características necessárias, ou seja, faça a 
tarefa exatamente da forma que se espera. Portanto, o ideal é pesquisar se não existe nenhum 
componente atualmente que faça a tarefa desejada de maneira coerente e se caso não existir 
nenhum componente com o comportamento desejado, é feito a construção de um componente 
específico, podendo posteriormente este ser disponibilizado para outros desenvolvedores que 
possam se depararar com a mesma situação que necessite da utilização do componente. 
 
 
5.5 API para desenvolvimento de componentes gráficos no JSF 
 
 
O JSF possui uma arquitetura extensível que permite a criação de componentes gráficos 
para ser feita a interface com o usuário, permitindo assim que terceiros desenvolvam seus 
próprios componentes gráficos fazendo utilização da API de criação de componentes do JSF. 
23 
Segundo Hightower (2007), a funcionalidade dos componentes JSF, tipicamente 
centraliza-se em duas ações: codificar e descodificar dados. Descodificar é o processo de 
converter os parâmetros das requisições recebidas para os valores do componente. Codificar é 
o processo de converter os valores correntes do componente no markup correspondente, ou 
seja, o HTML. 
A criação de um componente no JSF consiste de três tarefas: 
 
• Herdar as classes específicas e/ou implementar as interfaces específicas 
necessárias. Usualmente se torna necessário a utilização de uma classe ou 
interface específica para a criação de um componente. 
 
• Adicionar as configurações necessárias no arquivo de configuração do JSF. 
Assim como muitas outras tarefas no JSF, é necessário ser feita a configuração 
do componente no arquivo XML (Extensible Markup Language) de 
configuração do JSF, o faces-config.xml. Para toda extensão desenvolvida no 
JSF, é necessário possuir uma entrada de configuração correspondente. 
 
• Integrar a nova classe (o novo componente) com uma tecnologia de exibição, 
como por exemplo a JSP, este sendo portanto o último passo para a utilização 
do componente no processo de desenvolvimento. 
 
Para o desenvolvimento de um componente, primeiramente deve-se criar sua respectiva 
classe Java contendo seus atributos e esta herdando uma outra classe do framework JSF de 
acordo com a tarefa em que o componente será responsável por realizar. Por exemplo, se for 
desenvolver um componente que irá exibir algum atributo de um backing bean, este 
componente deve herdar a classe ‘javax.faces.component.UIOutput’ que é responsável pela 
ligação entre o componente e os atributos que serão recuperados os valores do backing bean. 
Caso o componente for renderizar um componente HTML para o cliente (possuir a 
tarefa de escrever algum código HTML para devolver para o cliente), é necessário este 
possuir uma classe que será responsável pela criação de todo o código HTML que será 
devolvido para o cliente, a classe é denominada como o renderer do componente e deve 
estender a classe ‘javax.faces.render.Renderer’, esta contendo métodos responsáveis pela 
renderização do código HTML que o componente irá escrever. 
E por último, é necessário o componente possuir outra classe que estenda a classe 
‘javax.faces.webapp.UIComponentTag’, é através desta classe juntamente com a tag library 
descriptor (que é um arquivo onde estão todos os atributos utilizados dos componentes e onde 
é feito a ligação destes atributos com suas respectivas classes Java) que serão encontrados os 
atributos que o componente possui e que são utilizados em uma JSP por exemplo. 
Exemplificando o que foi mencionado referente à criação de componentes gráficos no 
JSF, será desenvolvido um componente que renderiza para o cliente um formulário para o 
preenchimento de login, como a maioria das telas referente a login possui dois campos para a 
entrada dos dados, ou seja, o login e a senha, será desenvolvido um componente que 
rederizará estes dois campos para a entrada dos dados, sendo que estes dois campos possuíram 
relacionamento com atributos de um determinado backing bean de acordo com o que o 
desenvolvedor mencionar através de uma EL (Expression Language), ou seja, os dados 
inseridos estarão ligados diretamente com uma classe Java que posteriormente poderá utilizar 
estes dados informados pelo usuário para fazera validação do login, se o mesmo é válido ou 
não. 
 
 
 
 
24 
Classes Java: 
 
O componente possuirá três classes, a classe que representará o componente, uma classe 
que será o renderer do componente, que conforme já mencionado é responsável por criar os 
códigos HTML necessários para o componente, e por último possuirá uma classe que conterá 
as configurações referentes aos atributos que serão utilizados na JSP para a utilização do 
componente, estes atributos podendo ser denominados por tags. 
A classe que representará o componente irá herdar a classe 
‘javax.faces.component.UIOutput’, pois esta super classe (classe pai) contém implementações 
já prontas no que se refere a escrita de saída em HTML, e como o componente irá escrever 
códigos, será utilizada a classe UIOutuput, caso o componente fosse um campo que recebe 
entrada de dados, este deveria herdar a classe UIInput que da mesma forma que a UIOutput é 
para a saída de dados a UIInput é para a entrada de dados. 
 
1. public class Login extends UIOutput 
2. { 
3. public static final String FAMILY = "LOGIN_TCC"; 
4. 
5. public Login() 
6. { 
7. super(); 
8. } 
9. 
10. public String getFamily() 
11. { 
12. return FAMILY; 
13. } 
14. } 
 
Exemplo 5.5.1 
 
Conforme o exemplo 5.5.1, outra particularidade da classe é que ela possui o método 
getFamily() (linha 10) que retorna a família que este componente pertence, esta família é 
utilizada para saber posteriormente qual é o renderer do componente quando for feita a 
geração do HTML através do arquivo de configuração onde o componente será registrado 
(esta tarefa será feita posteriormente). Uma das tarefas da classe também é chamar o 
construtor de sua super classe (UIOutput) este contendo tarefas necessárias para os 
componentes que geram valores de saída conforme explicado anteriormente (linha 7). 
 
Renderer: 
 
Outra classe Java que o componente conterá é a classe que será o renderer (que 
conforme já explicado é onde são gerados os códigos HTML que serão enviados para o 
cliente), para uma classe ser um renderer, esta deve estender a classe 
‘javax.faces.render.Renderer’. Portanto o renderer do componente que renderizará o 
formulário para login ficará da seguinte forma: 
 
public class LoginRenderer extends Renderer 
 
Exemplo 5.5.2 
 
Uma classe renderer pode possuir os seguintes métodos que são (não obrigatoriamente) 
sobrescritos, pois estes pertencem a super classe Renderer (conforme exemplo 5.5.2) para o 
controle e geração do código HTML que irá ser devolvido ou enviado para o cliente: 
 
 
25 
• decode (FacesContext, UIComponent) 
o Este método é responsável por recuperar qualquer parâmetro passado pelo 
form do HTML e armazenar valores no componente. A primeira tarefa que 
este método deve realizar que faz parte de sua especificação é certificar de 
que os atributos e o contexto não estão nulos. 
 
• encodeBegin (FacesContext, UIComponent) 
o É onde é feita a implementação inicial do código HTML que será gerado, é 
o primeiro método a ser chamado para a renderização do HTML. 
 
• encodeChildren (FacesContext, UIComponent) 
o Caso o componente possua outros sub componentes, ou seja, componentes 
que serão filhos deste, é através deste método que será recuperado os 
componentes filhos e será feita a lógica necessária para o tratamento de 
seus sub componentes. Este método só é executado se a classe renderer 
possuir um outro método, o getRendersChildren() retornando true, este 
método pertence a super classe Renderer e caso este método não seja 
sobrescrito, é retornado false, portanto o default é não ser feita a execução 
do método encodeChildren, este só sendo executado quando a classe que 
representará o renderer possuir o método getRendersChildren() sobrescrito 
retornando true. 
 
• encodeEnd (FacesContext, UIComponent) 
o Onde é feita a implementação final do código HTML que será gerado, onde 
pode ser fechada uma tag table que foi iniciada no encodeBegin por 
exemplo. É o último método a ser invocado no processo de renderização de 
código HTML do componente que possui o renderer. 
 
Caso o componente não possuir sub componentes, ou seja, não possuir nenhum 
componente filho, toda a lógica de codificação do HTML pode ser desenvolvida apenas no 
método encodeBegin. 
Concluindo, a codificação do código HTML que o renderer do componente irá gerar 
possui o seguinte processo: primeiramente é chamado o método encodeBegin, após sua 
execução é chamado o método encodeChildren, este sendo chamado somente se a classe 
possuir o método getRendersChildren() retornando true e por último é chamado o método 
encodeEnd, finalizando assim o processo de geração do código HTML até onde o 
desenvolvedor possui o maior acesso. 
 
 1. public boolean getRendersChildren() 
 2. { 
 3. return true; 
 4. } 
 
 5. public void encodeBegin(FacesContext context, UIComponent component) throws 
 IOException 
 6. { 
 7. ResponseWriter writer = context.getResponseWriter(); 
 8. 
 9. writer.startElement("table", component); 
 10. writer.startElement("tr", component); 
 11. writer.startElement("td", component); 
 12. writer.write((String)component.getAttributes().get("label")); 
 13. writer.endElement("td"); 
26 
 14. writer.endElement("tr"); 
 15. writer.flush(); 
 16. } 
 17. 
 18. public void encodeChildren(FacesContext context, UIComponent component) 
 throws IOException 
 19. { 
 20. ResponseWriter writer = context.getResponseWriter(); 
 21. Iterator inputs = component.getChildren().iterator(); 
 22. 
 23. UIComponent componente = (UIComponent)inputs.next(); 
 24. writer.startElement("tr", component); 
 25. writer.startElement("td", component); 
 26. writer.write("Login: "); 
 27. writer.endElement("td"); 
 28. writer.startElement("td", component); 
 29. componente.encodeBegin(context); 
 30. componente.encodeEnd(context); 
 31. writer.endElement("td"); 
 32. writer.endElement("tr"); 
 33. writer.startElement("tr", component); 
 34. writer.startElement("td", component); 
 35. writer.write("Senha: "); 
 36. writer.endElement("td"); 
 37. writer.startElement("td", component); 
 38. componente = (UIComponent)inputs.next(); 
 39. componente.encodeBegin(context); 
 40. componente.encodeEnd(context); 
 41. writer.endElement("td"); 
 42. writer.endElement("tr"); 
 43. writer.flush(); 
 44. } 
 45. 
 46. public void encodeEnd(FacesContext context, UIComponent component) throws 
 IOException 
 47. { 
 48. ResponseWriter writer = context.getResponseWriter(); 
 49. writer.endElement("table"); 
 50. } 
 
 Exemplo 5.5.3 
 
O exemplo 5.5.3 mostra como fica o código que cria todo o conteúdo HTML referente 
ao componente. Primeiramente na linha 1, o método getRendersChildren esta retornando 
true, portanto o método encodeChildren será invocado pelo framework para o tratamento de 
seus respectivos filhos ou sub componentes. 
No método encodeBegin na linha 5, é recuperado o objeto onde será escrito o código 
HTML que será devolvido para o browser do cliente, este sendo o objeto writer do tipo 
ResponseWriter na linha 7, contendo o retorno do método context.getResponseWriter() que 
retorna o objeto de escrita (do tipo ResponseWriter) da requisição corrente para 
posteriormente ser devolvida com novos códigos HTML. 
Para ser inserida uma tag HTML no response que será enviado para o cliente, é 
utilizado o método startElement presente na classe ResponseWriter, através deste método é 
que se inicia uma tag, por exemplo, para iniciar a tag <table>, utilizaria-se