Trabalho Desenvolvimento de Portal Web E-commerce

Prévia do material em texto

UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ 
CAMPUS PATO BRANCO 
CURSO SUPERIOR DE TECNOLOGIA EM 
ANÁLISE E DESENVOLVIMENTO DE SISTEMAS 
 
 
 
 
 
 
 
 
MARCOS BERWANGER 
 
 
 
 
 
 
 
DESENVOLVIMENTO DE PORTAL WEB E-COMMERCE 
 
 
 
 
 
 
 
 
 
 
 
Pato Branco - PR 
2008 
 
 
MARCOS BERWANGER 
 
 
 
 
 
 
 
 
 
DESENVOLVIMENTO DE PORTAL WEB E-COMMERCE 
 
 
 
 
 
 
Monografia apresentada como requisito parcial 
para obtenção de título de Tecnólogo no Curso 
Superior de Tecnologia em Análise e 
Desenvolvimento de Sistemas da Universidade 
Tecnológica Federal do Paraná, Campus Pato 
Branco. 
 
Orientador: Prof. Géri Natalino Dutra, M.Sc 
 
 
 
 
 
 
 
 
 
 
Pato Branco – PR 
2008 
 
 II
DEDICATÓRIA 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Este trabalho é dedicado as incríveis 
pessoas que fazem parte da minha vida, 
aos meus pais, ao meu querido irmão 
Gustavo, e a minha namorada Cristiane. 
Por sua paciência e compreensão. 
 
 III
AGRADECIMENTOS 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Ao colega Tarlis Tortelli Portela pela 
imensurável contribuição na realização 
deste trabalho. 
 
 
 
 
 IV 
RESUMO 
O presente estudo apresenta uma análise sobre ferramentas de auxílio no 
desenvolvimento de softwares, denominados frameworks, para o desenvolvimento 
de uma aplicação voltada para o ambiente de Internet. Trata-se de um comparativo 
entre frameworks Struts1, JavaServer Faces2 e Mentawai3, destinados ao controle de 
aplicações Web. Além da exploração do suporte a persistência através do 
paradigma do mapeamento Objeto-Relacional. Por fim, o foco na ferramenta 
Mentawai e na Java Persistence API4 resulta em uma aplicação voltada para o 
comércio eletrônico. As conclusões apontam que estas ferramentas são alternativas 
dinâmicas a altura das atuais necessidades e imposições do mercado de software. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1 http://struts.apache.org/ 
2 http://java.sun.com/javaee/javaserverfaces/ 
3 http://www.mentaframework.org 
4 http://java.sun.com/javaee/technologies/persistence.jsp 
 
 V
ABSTRACT 
This study presents an analysis of tools to help in the development of softwares, 
known as frameworks, for the development of an application dedicated to the 
environment of Internet. It is a comparison between Struts, JavaServer Faces and 
Mentawai, for the control of Web applications. Besides the exploration of the support 
to the persistence through the paradigm of Object-Relational mapping. Finally, the 
focus in the Mentawai platform and in the Java Persistence API results in an 
application dedicated to e-commerce. The conclusions suggest that these tools are 
dynamic alternatives at the same level as the current needs and requirements of the 
software market. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 VI 
LISTA DE FIGURAS 
Figura 1: Arquitetura MVC ____________________________________________ 8 
Figura 2: Ciclo interativo MVC. ________________________________________ 10 
Figura 3: Controle descentralizado do Model 1. ___________________________ 11 
Figura 4: Controle centralizado do Model 2. ______________________________ 11 
Figura 5: Ciclo de vida Struts. _________________________________________ 15 
Figura 6: Infra-estrutura de aplicações Web. _____________________________ 24 
Figura 7: Ciclo de vida do JavaServer Faces. ____________________________ 26 
Figura 8: Resultado final para o usuário. ________________________________ 30 
Figura 9: Equivalência entre elementos do projeto orientado a objetos e o modelo 
relacional. ________________________________________________________ 33 
Figura 10: Ciclo de vida de software baseado em ciclos interativos. ___________ 35 
Figura 11: EJB são objetos Java configurados através de annotations._________ 41 
Figura 12: Os componentes oferecidos pelo EJB. _________________________ 42 
Figura 13: Organização geral da API EJB 3. _____________________________ 42 
Figura 14: Interface resultante do arquivo JSP. ___________________________ 47 
Figura 15: Interface resultante após a autenticação. _______________________ 49 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 VII 
LISTA DE TABELAS 
Tabela 1: Pontos fracos do Struts. _____________________________________ 20 
Tabela 2: Pontos fortes do Struts. _____________________________________ 20 
Tabela 3: Comparativo de algumas funcionalidades Struts vs. JSF. ___________ 31 
Tabela 4: Comparativo de algumas funcionalidades Struts, JSF e Mentawai. ____ 51 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 VIII 
LISTA DE ABREVIATURAS E SIGLAS 
API: Application Programming Interface. Interface de Programação de Aplicativos; 
CD-ROM: Disco compacto de armazenamento de dados. Mídia removível. 
CE: Comércio Eletrônico. 
CRUD: Create, Retrieve, Update, Delete. Criar, Consultar, Atualizar e Excluir. 
EJB: Enterprise JavaBean. 
HTML: HyperText Markup Language. Linguagem de Marcação de Hipertexto. 
HTTP: Hypertext Transfer Protocol. Protocolo de Transferência de Hipertexto. 
IDE: Integrated Development Environment. Ambiente Integrado de Desenvolvimento. 
JCP: Java Community Process. 
JEE: Java Enterprise Edition. 
J2EE: Java 2 Enterprise Edition. 
JPA: JavaPersistence API. 
JSF: JavaServer Faces. 
JSP: JavaServer Pages. 
JSR: Java Specification Requests. 
MVC: Model, View, Controller. Modelo, Visão e Controle. 
ORM: Object-Relational Mapping. Mapeamento Objeto Relacional. 
POJO: Plain Old Java Objects. 
RAD: Rapid Application Development. Desenvolvimento Rápido de Aplicação. 
SQL: Structured Query Language. Linguagem de Consulta Estruturada. 
TI: Tecnologia da Informação. 
UML: Unified Modeling Language. Linguagem de Modelagem Unificada. 
URI: Uniform Resource Identifier. Identificador Uniforme de Recursos. 
URL: Uniform Resource Locator. Localizador de Recursos Universal. 
Web: World-Wide-Web. Rede Mundial de Computadores. 
XML: eXtensible Markup Language. Linguagem de Marcação Extensível. 
 
 
 
 
 
 IX 
SUMÁRIO 
RESUMO _________________________________________________________ IV 
ABSTRACT _______________________________________________________ V 
LISTA DE FIGURAS ________________________________________________ VI 
LISTA DE TABELAS _______________________________________________ VII 
LISTA DE ABREVIATURAS E SIGLAS ________________________________ VIII 
SUMÁRIO _________________________________________________________ IX 
1 INTRODUÇÃO ___________________________________________________ 1 
1.1 JUSTIFICATIVA _______________________________________________ 3 
1.2 OBJETIVOS __________________________________________________ 4 
1.2.1 Objetivo Geral ______________________________________________ 4 
1.2.2 Objetivos Específicos ________________________________________ 4 
2 FUNDAMENTACAO TEORICA ______________________________________ 5 
2.1 COMÉRCIO ELETRÔNICO ______________________________________ 5 
2.2 FRAMEWORKS _______________________________________________ 6 
2.2.1 Frameworks MVC ___________________________________________ 8 
2.2.1.1 Framework Apache Struts ________________________________ 12 
2.2.1.2 Framework JavaServer Faces (JSF) ________________________ 22 
2.2.2 Frameworks ORM _________________________________________ 31 
3 MATERIAIS E MÉTODOS _________________________________________ 34 
3.1 ANÁLISE E PROJETO ORIENTADO A OBJETOS ___________________ 34 
3.2 LINGUAGEM DE PROGRAMAÇÃO JAVA __________________________ 36 
3.2 CAMADA DE VISÃO - FRAMEWORK MVC MENTAWAI _______________ 37 
3.3 CAMADA DE PERSISTÊNCIA – FRAMEWORK EJB 3 ________________ 41 
3.4 BANCO DE DADOS MYSQL ____________________________________ 44 
4 RESULTADOS __________________________________________________ 45 
4.1 DESCRIÇÃO DO SISTEMA _____________________________________46 
4.2 FUNCIONALIDADES __________________________________________ 46 
4.3 COMPARATIVO MENTAWAI vs. STRUTS vs. JSF ___________________ 51 
4.4 PRODUTIVIDADE E TRANSPARÊNCIA ___________________________ 52 
4.5 PUBLICAÇÃO ________________________________________________ 54 
5 CONCLUSÃO ___________________________________________________ 55 
REFERÊNCIAS ___________________________________________________ 58 
 
 
 
 
 
1 INTRODUÇÃO 
Nos últimos anos, o ambiente organizacional tem experimentado 
profundas mudanças, relacionadas, em sua maioria, com as tecnologias da 
comunicação. A globalização de mercados e integração interna e externa das 
empresas, por exemplo, caracterizam um novo ambiente empresarial, no qual as 
organizações dos mais variados setores têm realizado significativos investimentos 
em Tecnologia da Informação (TI), passando a oferecer produtos e serviços 
amplamente apoiados nessa tecnologia. 
Assim, seja pelo novo ambiente empresarial ou por força das influências 
entre os setores, todas as organizações têm sido afetadas pela nova realidade do 
mercado e comércio eletrônico. Essa situação tem exigido das organizações grande 
esforço para a assimilação e a utilização das tecnologias de informação referentes a 
comércio eletrônico, em sua operacionalização e em sua estratégia competitiva. 
(Albertin, 1999). 
Nos primeiros seis meses de 2008, o comércio eletrônico (e-commerce) 
no Brasil faturou 3,8 bilhões de reais, o que representa um crescimento nominal de 
45% em relação aos meses de janeiro a junho de 2007, segundo dados da E-BIT 
Informação, empresa brasileira especializada em fornecimento de informações sobre 
o e-commerce. (E-BIT empresa, 2008) 
De acordo com a E-BIT, o volume faturado no primeiro semestre de 2008 
corresponde a praticamente todo montante faturado durante o ano de 2006, quando 
o e-commerce brasileiro alcançou a marca de R$ 4,4 bilhões em vendas de bens de 
consumo. De acordo com a empresa, a justificativa para a grande e contínua 
expansão do comércio pela Internet está no incremento no número de consumidores 
que, do primeiro semestre de 2007 até o primeiro semestre de 2008, cresceu 
aproximadamente 42%, ou seja, um acréscimo de 3,5 milhões de novos 
compradores, totalizando 11,5 milhões de pessoas que já experimentaram comprar 
na Web até Junho de 2008, o que representa cerca de 6,1% da população brasileira. 
Inúmeros são os fatores que tem levado os consumidores a mudar o 
comportamento de compra, com destaque para a inclusão digital, incentivada pelo 
Governo Federal, a conveniência da compra on-line, principalmente nas grandes 
cidades e, a eficiência dos sites de busca e comparadores de preços. (E-BIT 
empresa, 2008) 
 
 
 
2
O grande motor de todo este movimento, a Internet, proporciona uma 
imensa rede de oportunidades, abrindo mercados impensáveis e infinitos. Um “ser” 
de crescimento orgânico, natural, e principalmente, veloz. É neste meio que esta 
proposta se insere, buscando suprir novas necessidades da sociedade moderna. 
Necessidades estas, que uma vez supridas tornar-se-ão parte fundamental do 
cotidiano dos indivíduos. 
A Web vem modificando a forma como se estabelecem as relações 
interpessoais, ou seja, muda-se a forma como as pessoas fazem negócios e se 
comunicam. A noção de espaço é perdida quando se passa, subitamente, a 
trabalhar com horizontes globais. Superando-se barreiras, surpreende com a 
velocidade com que os novos produtos podem passar a fazer parte da realidade dos 
consumidores. De modo geral, a Internet vem modificando o modo de se relacionar, 
o modo de comprar e de vender, enfim, a maneira de pensar da sociedade moderna. 
Segundo Pinho (2000), montar uma loja virtual é, sem dúvida, muito mais 
complicado do que fazer um site na Internet. Mas tem futuro: as amplas e ainda 
promissoras possibilidades do comércio eletrônico na Internet despertam a atenção 
de empresas e comerciantes, estimulando os empreendedores a se tornarem os 
novos “Webmilionários” do e-commerce. 
Esta evolução constitui instrumento motivador para a entrada de novas 
ferramentas e sistemas capazes de suprir espaços ainda não explorados pelos 
“empresários virtuais”. 
Diante deste movimento acelerado e consistente, onde os consumidores 
vem mudando sua maneira de comprar, observa-se a oportunidade para criação de 
plataformas de comércio voltadas para a Internet: portais de comércio eletrônico. Em 
suma, propõe-se a criação de um canal capaz de intermediar a negociação entre 
consumidores e vendedores a fim de permitir que os mais variados produtos e 
serviços possam ser veiculados e o seu respectivo processo de entrega, gerenciado. 
Atualmente, tal qual a evolução existente no âmbito comercial, a 
tecnologia de informação, que dá sustentabilidade a esta realidade, também está em 
constante processo de aprimoramento. Ferramentas e técnicas surgem a todo o 
momento e, entre elas as plataformas (Frameworks) MVC e ORM que são voltadas 
especificamente para o ambiente da Web. Frameworks desta modalidade serão 
objetos de estudo deste trabalho e deverão auxiliar no desenvolvimento da aplicação 
em questão. 
 
 
3
1.1 JUSTIFICATIVA 
 
 
A evolução do ambiente da Internet vivenciado atualmente requer não 
apenas redes mais rápidas e internacionalizadas, exige também revisões constantes 
do processo de desenvolvimento de software em busca do uso do aparato 
tecnológico condizente, aliado a adoção das melhores práticas de desenvolvimento. 
A interatividade compõe fator primordial das aplicações voltadas para a 
Internet, sem ela as aplicações seriam incapazes de oferecer a imensa gama de 
serviços hoje existentes. As aplicações devem atender às requisições dos usuários, 
realizando acesso a dados, executando tarefas de negócios, exibindo dados e, 
controlando seu próprio fluxo, sempre através de uma interface amigável e uma 
estrutura robusta. 
Assim, tão importante quanto visar o conhecimento envolvido no ambiente 
de comércio eletrônico, faz-se o estudo aprofundado das plataformas que objetivam, 
justamente, facilitar e agilizar o desenvolvimento, conduzindo analistas e 
desenvolvedores a focar seus esforços em processos de negócio. 
O estudo e a adoção de plataformas tornam-se imprescindíveis quando 
estas permitem otimizar o desenvolvimento. Os Frameworks MVC desoneram a 
camada de visão da aplicação, enquanto as plataformas ORM proporcionam uma 
camada de persistência quase que automatizada, aliviando o programador de 
tarefas repetitivas cuja implementação manual exigirá conhecimentos específicos. 
 
Comparar as formas de utilização dessas ferramentas, salientando suas 
características essenciais, permite conduzir empresas e desenvolvedores em busca 
das melhores alternativas, contribuindo para o aprimoramento geral do processo de 
criação de software. 
No que tange o comercio eletrônico observa-se a possibilidade de 
aprimorar características e até mesmo traduzir processos tradicionais para o 
ambiente da Internet, introduzindo tecnologia de informação em processos 
populares e largamente utilizados. 
 
 
 
 
 
4
1.2 OBJETIVOS 
 
Arquitetar e desenvolver um portal de comércio eletrônico (e-commerce), 
através do qual os usuários possam vender produtos e serviços, gerenciando seus 
processos de entrega. 
 
 
1.2.1 Objetivo Geral 
 
Através de técnicas de orientação a objetos, elaborar análise e projeto, 
implementando, com auxilio de Frameworks e ferramentas específicas, um portal de 
Internet capaz de executar e gerenciar processos de venda e entrega de produtos e 
serviços. 
 
 
1.2.2 Objetivos Específicos 
 
a) Desenvolver um estudo bibliográfico sobre o ambiente de comércio 
eletrônico; 
b) Explorar a tecnologia Java voltada para a Internet, e alguns dos 
principais Frameworks MVC e ORM existentes; 
c) Efetuar análise do sistema; 
d) Implementar o Sistema utilizando a linguagem de programação Java 
paraWeb, desenvolvida pela Sun Microsystems, com o auxilio do framework MVC 
Mentawai e da JavaPersistence API (JPA). 
e) Publicar o sistema como portal na Internet. 
 
 
 
 
 
 
 
 
 
 
5
2 FUNDAMENTACAO TEORICA 
Com vistas a analisar e exemplificar algumas das tecnologias existentes 
destinadas ao desenvolvimento voltado para a Internet serão demonstrados 
detalhadamente os Frameworks MVC JavaServer Faces e o Apache Struts, além de 
uma visão geral sobre a técnica ORM e, inicialmente, a respeito do Comércio 
Eletrônico. 
 
 
2.1 COMÉRCIO ELETRÔNICO 
 
 
O comércio eletrônico é a mais recente e promissora aplicação criada 
com a TI (Tecnologia da Informação), que não se restringe apenas à compra e à 
venda de produtos e serviços por meio de redes de computadores. Os sistemas de 
comércio eletrônico (CE) podem ser explorados para fins de comunicação entre 
filiais, conectividade com clientes e com fornecedores, publicidade e, naturalmente, 
a realização de transações comerciais. O conceito de comércio eletrônico, segundo 
Kalakota & Whinston (apud Albertin, 1999), deve então ser entendido sobre quatro 
diferentes perspectivas: 
1. De uma perspectiva de comunicações, o CE é a entrega de 
informações, produtos/serviços ou pagamentos por meio de linhas de telefone, redes 
de computadores ou qualquer outro meio eletrônico; 
2. De uma perspectiva de processo de negócio, o CE é a aplicação de 
tecnologia para a automação de transações de negócio e fluxos de dados; 
3. De uma perspectiva de serviço, o CE é uma ferramenta que endereça 
o desejo das empresas, dos consumidores e da gerência para cortar custos de 
serviços, enquanto melhora a qualidade das mercadorias e aumenta a velocidade da 
entrega do serviço; 
4. De uma perspectiva on-line, o CE prevê a capacidade de comprar e 
vender produtos e informações na Internet e em outros serviços on-line. 
A disseminação do sistema de comércio eletrônico, em todas as suas 
formas, tem como peça-chave a grande adoção desses tipos de tecnologias por 
clientes, fornecedores e empresas. A disseminação nas novas tecnologias enfrenta 
 
 
 
6
sempre obstáculos – entre eles, a natural resistência a mudanças, os aspectos 
percebidos com a nova tecnologia, a necessidade de infra-estrutura e os benefícios 
percebidos, mas pode ser beneficiada pela curva de aprendizagem acumulada pelas 
tecnologias anteriores. Por isso, os tempos de adoção de tecnologias como o pager, 
fax, videocassete, telefone celular, computador pessoal, CD-ROM e Web são cada 
vez mais curtos. (PINHO, 2000, p. 211). 
Paralelamente ao crescimento extensivo e a imensa gama de 
oportunidades que surgem com o advento do comércio eletrônico, é fundamental 
que as novas propostas sejam avaliadas sob aspectos como concorrência, 
publicidade e segurança. Segundo Felipini (2007), é fundamental que o site seja 
visto pela rede, tendo em vista que cerca de 50% dos consumidores on-line 
pesquisaram seus produtos através de sites de busca como Google, Yahoo, MSN, 
entre outros, antes de realizar suas compras. 
Além dos desafios comerciais existentes neste ambiente competitivo, 
outro fator preponderante é a grande quantidade de variáveis existentes em 
sistemas distribuídos como é o caso da Web, o que amplia consideravelmente o 
grau de complexidade das aplicações desenvolvidas para este fim. Com o intuito de 
tornar estes desafios mais palpáveis a indústria de software, proprietário ou open 
source (software de código aberto), vem buscando constantemente desenvolver 
ferramentas e técnicas capazes de facilitar o trabalho dos desenvolvedores. 
Algumas destas ferramentas recebem o nome de Framework, ou, plataforma de 
trabalho. A seguir descreve-se sua funcionalidade básica e duas de suas variações, 
os Frameworks MVC e os Frameworks ORM. 
 
 
2.2 FRAMEWORKS 
 
 
Frameworks são conjuntos de classes que colaboram a fim de oferecer 
suporte a outros sistemas que podem ser sobre ele desenvolvidos. São projetados 
com a intenção de facilitar o desenvolvimento de software, habilitando designers5 e 
 
5 Profissionais responsáveis pela elaboração do projeto estético e funcional de um Web Site. 
 
 
7
programadores a gastarem mais tempo determinando as exigências do software do 
que com detalhes de baixo nível do sistema. 
Os softwares, assim como as pessoas, são mais semelhantes do que 
diferentes. Eles são executados nos mesmos computadores, esperam entradas dos 
mesmos dispositivos, produzem as mesmas exibições e gravam os dados nos 
mesmos discos rígidos. (HUSTED, 2004, p. 5) 
Ainda de acordo com Husted (2004), os Frameworks fornecem aos 
desenvolvedores conjuntos de componentes estruturais que têm as seguintes 
características: 
• São conhecidos por funcionarem bem em outras aplicações; 
• Estão prontos para serem usados com o próximo projeto; 
• Podem também ser usados por outras equipes na organização. 
 
De modo geral os Frameworks estão presentes na grande maioria das 
empresas especializadas em desenvolvimento de software por trazerem vantagens 
como: 
• Redução de custos; 
• Redução do tempo de resposta aos clientes; 
• Maximização da reutilização (análise, design, código, testes); 
• Foco no desenvolvimento dos processos de negócio; 
• Menor necessidade de manutenção; 
• Maior consistência e compatibilidade entre aplicações. 
 
Entre os Frameworks mais conhecidos e utilizados na atualidade estão os 
Object-Relational Mapping (ORM) e os Model-View-Controller (MVC). O primeiro 
utilizado nas tarefas de persistência de dados e o segundo na simplificação dos 
trabalhos voltados a camada de controle e visão de uma aplicação Web. As 
subseções 2.2.1 e 2.2.2 tratam dessas tecnologias. 
 
 
 
 
 
 
 
8
2.2.1 Frameworks MVC 
 
 
No final dos anos 70, quando as interfaces gráficas do usuário (GUIs) 
estavam sendo inventadas, arquitetos de software viam as aplicações como tendo 
três partes maiores: a parte que gerencia os dados, a parte que cria as telas e os 
relatórios e a parte que lida com as interações entre o usuário e outros subsistemas 
(REENSKAUG, 1995). No início dos anos 80, o ambiente de programação 
ObjectWorks/SmallTalk introduziu esse grupo de três partes como uma estrutura de 
desenvolvimento. Na linguagem Smalltalk 80, o sistema de dados é denominado 
Model (Modelo), o sistema de apresentação é chamado de View (Exibição) e o 
sistema de interação é o Controller (Controlador). Muitos ambientes de 
desenvolvimento moderno, inclusive o Swing6 do Java, usam essa arquitetura 
Model/View/Controller (MVC) como a base de suas próprias estruturas (HUSTED, 
2004, p. 28). 
O MVC destaca-se dos demais padrões JEE como um padrão arquitetural 
para construção de aplicações interativas. Dividindo a aplicação em três tipos de 
objetos (Figura 1): (1) o Model: representa o modelo de dados e as lógicas de 
negócio da aplicação; (2) o View: trata a entrada dos dados pelo usuário e a 
apresentação das informações e (3) o Controller: define a maneira como a interface 
do usuário reage às entradas do mesmo, responsabilizando pelo controle do fluxo da 
aplicação (NASCIMENTO, 2004). 
 
 
Figura 1: Arquitetura MVC 
 
 
6 http://java.sun.com/j2se/1.5.0/docs/api/javax/swing/package-frame.html 
 
 
9
O Model sabe sobre qualquer View, eles são chamados dependentes e 
esta é a única relação que deve existir a partir do Model para a View. Views e 
Controllers aparecem em pares. A View conhece exatamente o Controller, e um 
Controller conhece exatamente uma View. A View e o Controller conhecem o 
mesma Model, mas o Model não conhece o Controller (REENSKAUG, 1995, p. 
335). 
O princípio do padrão MVC consiste em dividir as tarefas (atender às 
requisições dos usuários, realizar acesso a dados, executar tarefas de negócios, 
exibir dados e, controlar seu próprio fluxo), assumindoque atividades como 
apresentação dos dados e o seu acesso devem estar separadas, visto que, caso a 
fonte de dados seja alterada, a interface com o usuário não deverá ser reescrita, e 
que mesmo que esta interface mude, as regras de negócio permanecerão as 
mesmas. 
O uso do MVC oferece muitos benefícios ao projeto de aplicações. Por 
separar os conceitos de apresentação, controle de fluxo e lógica de negócios, ele 
reduz a duplicação de código, centraliza o controle e torna a aplicação mais robusta 
e portável. O MVC também favorece a clara divisão de tarefas entre componentes 
de uma mesma equipe de desenvolvimento. Enquanto alguns membros 
especializam-se e são responsáveis pelo design de interfaces, outros podem cuidar 
da codificação das lógicas de negócios, da representação do fluxo de controle da 
aplicação e outros ficarão dedicados a tratar das funcionalidades relativas ao banco 
de dados. Este é um modelo apropriado, por exemplo, para uma fábrica de software. 
Além disso, novas fontes de dados e novos tipos de clientes são facilmente 
adicionados à aplicação, adaptando-os para operarem como parte da arquitetura 
MVC. Por exemplo, se uma aplicação desktop (executada localmente) precisar 
oferecer recursos Web, uma camada de componentes de apresentação será 
construída, acoplada ao controlador de fluxo da aplicação e compartilhará regras de 
negócio com a aplicação desktop (STEARNS, 2002). 
“A camada de aplicação J2EE serve solicitações HTTP (Figura 2). Ao 
mais alto nível, a camada da Web faz quatro coisas básicas em uma ordem 
específica: interpreta a solicitação do cliente, expede os pedidos para a lógica de 
negócio, seleciona a próxima tela para exibição e, gera e distribui a próxima Visão 
(View)” (STEARNS, 2002). 
 
 
 
10
 
Figura 2: Ciclo interativo MVC. 
Fonte: STEARNS, 2002. 
 
Os benefícios trazidos pelo uso da arquitetura MVC são evidentes, no 
entanto, a construção independente de um framework que a implemente, pode 
tornar-se inviável. Segundo Stearns (2002), é altamente recomendável optar por um 
framework existente ao invés de projetar e construir um personalizado. De acordo 
com o autor, as vantagens que um framework pode proporcionar à aplicação: 
• Desacopla apresentação e lógica em componentes distintos; 
• Separa os papéis dos desenvolvedores; 
• Fornece um ponto central de controle; 
• Contribui com a unidade de teste e manutenção; 
• Pode ser comprado ao invés de construído; 
• Proporciona um rico conjunto de funções; 
• Incentiva o desenvolvimento e a utilização de componentes 
padronizados; 
• Proporciona estabilidade; 
• Tem o apoio da comunidade de desenvolvimento para solução de 
problemas, aprendizado e implantação de melhorias; 
• Pode reduzir os custos de formação dos profissionais; 
• Simplifica a internacionalização; 
• Facilita a validação de entradas; 
• Podem ser compatíveis com ferramentas de desenvolvimento (IDE). 
 
Na plataforma JEE existem duas formas de se projetar uma aplicação 
WEB, “Model 1” e “Model 2”. Na primeira o fluxo da aplicação é controlado 
diretamente pelos arquivos JSP, ou seja, cada página indica qual é a próxima e a 
anterior. Ao contrário deste, no Model 2 - MVC propriamente dito - a navegação é 
 
 
11
gerenciada por Servlets7 intermediários, que conduzem o usuário e efetuam o 
controle da aplicação. No Model 1 as lógicas de apresentação e navegação ficam 
misturadas, ou seja, o controle é descentralizado (Figura 3). 
 
 
Figura 3: Controle descentralizado do Model 1. 
Fonte: MILLS, 2003. 
 
Para Stearns (2002), o Model 1 é indicado para aplicações pequenas, 
cujos fluxos são simples e não requerem controle centralizado. Já o Model 2 é 
recomendado para aplicações maiores, pois o controle do fluxo é centralizado. Tal 
arquitetura permite tornar as páginas JSP independentes e, normalmente, 
reutilizáveis. Fazendo com que as aplicações sejam mais facilmente mantidas e, da 
mesma forma, as funções de autenticação, autorização e auditoria realizadas. 
A Figura 4 demonstra a proposição do Model 2 (MVC): 
 
 
 
Figura 4: Controle centralizado do Model 2. 
Fonte: MILLS, 2003. 
 
 
A utilização de um framework MVC pode simplificar muito a construção de 
aplicações com a arquitetura Model 2. O Apache Struts Web Application Framework 
é um dos Frameworks mais utilizado neste segmento e vem adquirindo maturidade 
ao longo de alguns anos de evolução. Outro framework que vem atraindo a atenção 
 
7 Classes Java capazes de gerar conteúdo dinâmico executadas sobre um container Web. 
 
 
12
da comunidade Java é o Java Server Faces. Ambos oferecem um servlet de controle 
configurável, além de bibliotecas de classes e tag libraries8 para a construção de 
páginas JSP. Muitas ferramentas integradas de desenvolvimento para a plataforma 
JEE vêm aderindo à arquitetura MVC, através do suporte aos Frameworks. 
 
 
2.2.1.1 Framework Apache Struts 
 
O Struts é um framework de fonte aberta mantido pela Apache Software 
Fundation (ASF) como parte integrante do projeto Jakarta. Seu nome, do inglês 
“pilastra”, é uma analogia às bases que mantêm casas, prédios, pontes etc. 
Struts é um framework MVC para desenvolvimento de aplicações Web 
que usa uma arquitetura do Model 2, provendo três componentes chave: 
1. Um manipulador “request” provido pelo desenvolvedor da aplicação 
que é mapeado para um padrão URI; 
2. Um manipulador “response” que transfere o controle para outro recurso 
responsável por completar a resposta; 
3. Uma tag library que ajuda os desenvolvedores a criar páginas JSP de 
forma interativa. 
 
O funcionamento do framework está diretamente relacionado com a 
classe ActionServlet que controla o fluxo navegacional. A classe Action é usada para 
acessar as classes de negócios. Quando o ActionServlet recebe uma solicitação do 
container9, usa o URI para determinar qual Action usará para lidar com a solicitação. 
Uma Action pode validar a entrada (input) e acessar a camada de negócios para 
recuperar as informações nos bancos de dados e outros serviços de dados. 
(HUSTED, 2002, pg. 14) 
 
As requisições são direcionadas ao ActionServlet graças a um 
mapeamento (servlet-mapping) definido no arquivo descritor da aplicação, o 
Web.xml. É comum o uso do padrão *.do neste mapeamento, embora isto seja 
 
8 Coleção de tags (marcadores) personalizadas 
http://java.sun.com/products/jsp/tutorial/TagLibrariesTOC.html 
9 Container Java Enterprise Edition (JEE) é responsável por gerenciar o ciclo de vida dos objetos, dar 
suporte ao multithread, segurança, e suporte a páginas JSP (Java Server Pages). 
 
 
13
apenas uma convenção e não uma regra. A listagem 1 exibe um trecho do arquivo 
Web.xml, responsável pela definição do ActionServlet e pelo seu mapeamento para 
o padrão convencional. O elemento <servlet> configura o ActionServlet, 
identificando-o por “Action”, enquanto o elemento <servlet-mapping> associa o 
servlet “Action” ao padrão *.do. (NASCIMENTO, 2005) 
 
 
Listagem 1. Definição do ActionServlet do Struts no Web.xml. 
 
 
Assim, pode-se escalonar o fluxo de navegação dos componentes do 
Struts da seguinte forma: 
1. O usuário faz uma solicitação através de uma URL no browser 
(navegador de páginas Web). Por exemplo: 
“http://localhost:8080/cadastro/listarUsuarios.do”. A extensão “.do” será usada para 
invocar (mapear) o Servlet Controller (ActionServlet) do Struts. 
2. Caso seja a primeira solicitação que o container está recebendo para 
esta aplicação, ele irá invocar o método “init()” da ActionServlet carregando as 
configurações do arquivo “Struts-config.xml” em estruturas de dados na memória. 
 
 
14
Esta passagem será executada uma única vez, tendo em vista que nas solicitações 
subseqüentes, o ActionServlet consulta estas estruturas na memória para decidir o 
fluxo a ser seguido. 
3. Baseadono fluxo definido no arquivo “Struts-config.xml”, e que neste 
momento já se encontra carregado em estruturas na memória, o ActionSerlet 
identificará qual o ActionForm (classe responsável pela validação dos dados) irá 
invocar. Esta última, através do método “validate” irá verificar a integridade dos 
dados que foram recebidos na solicitação oriunda do navegador. 
4. O controle da aplicação é retomado pelo ActionServlet, que verifica o 
resultado da verificação do ActionForm. Caso ocorra alguma falha na validação o 
usuário recebe um formulário JSP/HTML (geralmente o mesmo que fez a 
solicitação), informando o motivo do não atendimento da solicitação, para que o 
usuário possa preencher corretamente os dados para realizar nova solicitação 
(request). Na hipótese da validação ter retornado positivamente, o ActionServlet 
encaminha o fluxo para o próximo passo, a Action. 
5. O controlador, baseado no fluxo da aplicação (estruturas já carregadas 
em memória) invoca uma classe Action. Nela, o método “execute” será invocado e 
delegará a requisição para a camada de negócio. 
6. A camada de negócio irá executar algum processo (geralmente popular 
um Bean10, ou uma coleção). O resultado da execução deste processo (objetos já 
populados) será usado na camada de apresentação para exibir os dados. 
7. Quando o controle do fluxo da aplicação votar ao Action que invocou o 
processo da camada de negócio, será analisado o resultado, e definido qual o mapa 
adotado para o fluxo da aplicação. Neste ponto, os objetos que foram populados na 
camada de negócio serão anexados como atributos na seção do usuário. 
8. Baseado no mapeamento feito pela Action, o controlador faz um 
forward para o JSP para apresentar os dados. 
9. Na camada de apresentação (View), os objetos que foram definidos 
como atributos da sessão do usuário serão consultados para montar o HTML para o 
browser. 
10. A resposta requisitada retorna ao usuário. 
 
 
10 Beans, ou JavaBeans, de acordo com sua especificação (http://java.sun.com/products/javabeans/) 
são “componentes reutilizáveis de software manipulável em uma ferramenta de construção”. 
 
 
15
Na Figura 5, observa-se o ciclo de vida do request no Struts descrito 
anteriormente. 
 
 
Figura 5: Ciclo de vida Struts. 
Fonte: RAIBLE, 2006. 
 
Para exemplificar o funcionamento do framework Struts são exibidos 
trechos de códigos de um sistema de Logon (autenticação). 
A Listagem 1 demonstra o código fonte responsável por exibir a tela de 
boas vindas. 
<%@ taglib uri="/tags/Struts-bean" prefix="bean" %> 
<%@ taglib uri="/tags/Struts-html" prefix="html" %> 
<%@ taglib uri="/tags/Struts-logic" prefix="logic" %> 
<HTML> 
<HEAD> 
<TITLE>Welcome!</TITLE> 
<html:base/> 
</HEAD> 
<BODY> 
<logic:present name="user"> 
<H3>Welcome <bean:write name="user" property="username"/>!</H3> 
</logic:present> 
<logic:notPresent scope="session" name="user"> 
<H3>Welcome World!</H3> 
</logic:notPresent> 
<html:errors/> 
<UL> 
<LI><html:link forward="logon">Sign in</html:link></LI> 
<logic:present name="user"> 
<LI><html:link forward="logoff">Sign out</html:link></LI> 
</logic:present> 
</UL> 
</BODY> 
</HTML> 
Listagem 1: Fonte JSP para a página de boas vindas. (HUSTED, 2004, p. 64) 
 
 
16
 
A Listagem 2 exibe o código fonte para a tela de Logon: 
<%@ taglib uri="/tags/Struts-html" prefix="html" %> 
<HTML> 
<HEAD> 
<TITLE>Sign in, Please!</TITLE> 
</HEAD> 
<BODY> 
<html:errors/> 
<html:form Action="/LogonSubmit" focus="username"> 
<TABLE border="0" width="100%"> 
<TR> 
<TH align="right">Username:</TH> 
<TD align="left"><html:text property="username"/></TD> 
</TR> 
<TR> 
<TH align="right">Password:</TH> 
<TD align="left"><html:password property="password"/></TD> 
</TR> 
<TR> 
<TD align="right"> <html:submit/> </TD> 
<TD align="left"> <html:reset/></TD> 
</TR> 
</TABLE> 
</html:form> 
</BODY> 
</HTML> 
Listagem 2: Fonte JSP para a página de conexão. (HUSTED, 2004, p. 68) 
 
 
Em ambas as Listagens (1 e 2), pode-se perceber a inserção das tags 
personalizadas do Struts, que dão maior flexibilidade ao desenvolvedor e tornam o 
código transparente para os Web Designers. 
Quando o formulário da Listagem 2 acima for enviado (submetido) dois 
objetos do framework entrarão em cena: o ActionForm e o Action. Parte do primeiro, 
ActionForm, é exemplificada na Listagem 3. 
 
public ActionErrors validate(ActionMapping mapping, 
 HttpServletRequest request) { 
 
 ActionErrors errors = new ActionErrors(); 
 
 if ((username == null) || (username.length() < 1)) 
 errors.add("username", 
 new ActionError("error.username.required")); 
 
 if ((password == null) || (password.length() < 1)) 
 errors.add("password", 
 new ActionError("error.password.required")); 
 
 
 
 
17
 return errors; 
} 
Listagem 3: Método para validação (LogonForm). (HUSTED, 2004, p. 74) 
 
Caso a validação ocorra com sucesso o ActionRequest (controlador) 
encaminha o fluxo da aplicação para a Action “LogonAction” que deve autenticar o 
usuário no sistema. O método perform desta Action é descrito na Listagem 4. 
 
public ActionForward perform(ActionMapping mapping, 
 ActionForm form, 
 HttpServletRequest request, 
 HttpServletResponse response) 
 throws IOException, ServletException { 
 
 String username = ((LogonForm) form).getUsername(); 
 String password = ((LogonForm) form).getPassword(); 
 
 boolean validated = false; 
 try { 
 validated = isUserLogon(username,password); 
 } 
 
 catch (UserDirectoryException ude) { 
 ActionErrors errors = new ActionErrors(); 
 errors.add(ActionErrors.GLOBAL_ERROR, 
 new ActionError("error.logon.connect")); 
 saveErrors(request,errors); 
 return (new ActionForward(mapping.getInput())); 
 } 
 
 if (!validated) { 
 //Retorna um erro predefino 
 ActionErrors errors = new ActionErrors(); 
 errors.add(ActionErrors.GLOBAL_ERROR, 
 new ActionError("error.logon.invalid")); 
 saveErrors(request,errors); 
 return (new ActionForward(mapping.getInput())); 
 } 
 
 // Salva o usuário logado na sessão 
 HttpSession session = request.getSession(); 
 session.setAttribute(Constants.USER_KEY, form); 
 
 // Retorna com sucesso 
 return (mapping.findForward(Constants.SUCCESS)); 
} 
Listagem 4: Fonte Java para a classe LogonAction. (Adaptado de HUSTED, 2004, 
p. 75) 
 
 
 
18
As mensagens que serão apresentadas ao usuário estão registradas no 
arquivo de configuração “application.properties”, como exemplificado na 
Listagem 5. 
 
welcome.title=Struts Logon Example Application 
welcome.heading=Welcome! 
errors.footer=</UL><HR> 
errors.header=<H3><FONT color="red">Validation Error</FONT></H3>You must 
correct the following error(s) before proceeding:<UL> 
error.username.required=<LI>Username is required</LI> 
error.password.required=<LI>Password is required</LI> 
error.logon.invalid=<LI>Username and password provided not found in user 
directory. Password must match exactly, including any lower or upper 
case characters.</LI> 
error.logon.connect=<LI>Could not connect to user directory.</LI> 
Listagem 5: Arquivo de configuração application.properties. (Adaptado de 
HUSTED, 2004) 
 
Todo funcionamento da aplicação depende do arquivo “Struts-
config.xml”. É nele que o fica armazenado o caminho a seguir, o fluxo que deve 
ser percorrido pelo framework. A Listagem 6 exibe as configurações utilizadas para 
que o processo de autenticação seja executado com sucesso. 
 
<?xml version="1.0" encoding="ISO-8859-1" ?> 
 
<Struts-config> 
 
 <form-beans> 
 
 <form-bean 
 name="logonForm" 
 type="app.LogonForm"/></form-beans> 
 
 
 <global-forwards> 
 <forward 
 name="logoff" 
 path="/Logoff.do"/> 
 <forward 
 name="logon" 
 path="/Logon.do"/> 
 <forward 
 name="welcome" 
 path="/Welcome.do"/> 
 </global-forwards> 
 
<!— Definições de mapeamento -> 
 
 <Action-mappings> 
 
 
19
 <Action 
 path="/Welcome" 
 type="org.Apache.Struts.Actions.ForwardAction" 
 parameter="/pages/Welcome.jsp"/> 
 
 <Action 
 path="/Logon" 
 type="org.Apache.Struts.Actions.ForwardAction" 
 parameter="/pages/Logon.jsp"/> 
 
 <Action 
 path="/LogonSubmit" 
 type="app.LogonAction" 
 name="logonForm" 
 scope="request" 
 validate="true" 
 input="/pages/Logon.jsp"> 
 <forward 
 name="success" 
 path="/pages/Welcome.jsp"/> 
 </Action> 
 
 </Action-mappings> 
</Struts-config> 
Listagem 6: Arquivo de configuração Struts-config.xml. (Adaptado de 
HUSTED, 2004) 
 
Além das classes Java e das JavaServer Pages, um desenvolvedor tem 
que criar ou alterar, vários arquivos de configuração para ter uma aplicação Struts 
ativada e sendo executada. Segundo Husted (2004), são eles: 
• Web.xml: Descritor de desenvolvimento da aplicação Web requerido 
pela especificação JavaServlet. O contêiner Servlet/JSP usa esse arquivo para 
carregar e configurar sua aplicação. 
• Struts-config.xml: O descritor de desenvolvimento do framework. 
É responsável por carregar e configurar inúmeros componentes usados pelo Struts. 
• application.properties: Fornece os recursos de mensagens 
para a aplicação Struts. 
 
Ainda de acordo com Husted (2004), “o centro do framework é o 
ActionServlet, que o Struts usa como controlador. Embora possa ser 
subclassificado, a maioria dos desenvolvedores trata o ActionServlet como uma 
caixa preta, configurando-o a partir do descritor de desenvolvimento da aplicação 
Web (Web.xml) e o deixam como está”. 
 
 
 
20
Como qualquer sistema complexo, o Struts é uma negociação de pacotes. 
Tem suas capacidades e fraquezas. Alguns desses pontos são subjetivos, porém 
ainda intrusivos. 
A Tabela 1 exibe as fraquezas do Struts. 
 
Tabela 1: Pontos fracos do Struts. 
Ponto fraco Observações 
Nenhum modelo de eventos O Struts está intimamente ligado ao modelo de solicitação-
resposta usado pelo HTTP. 
Depuração Não há suporte para depuração automática. 
Nenhum modelo default (padrão) ou 
recomendações concretas 
O acesso para um modelo de dados permanente é deixado 
inteiramente como exercício para o desenvolvedor. 
Um ActionServlet Apenas um ActionServlet pode ser usado em uma única 
aplicação, o que pode ocasionar conflitos de configuração. 
Requer compreensão dos componentes Para trabalhar com o Struts, um desenvolvedor precisa 
compreender várias classes especiais e como elas 
interagem. 
O revendedor não oferece suporte de 
prioridade 
A Apache Software Foundation é uma organização de 
voluntários sem uma equipe paga que possa fornecer 
muitos envios diariamente. 
Lista de discussão é um obstáculo Devido ao tamanho da lista de discussão pode ser difícil 
encontrar a melhor informação. 
Os lançamentos dos formatos não são 
rápidos 
As versões do Struts foram relativamente lentas. Não há 
um cronograma definido para os lançamentos. 
Limites i18n Os recursos de mensagem do Struts são muito bons ao 
internacionalizar labels e mensagens de erro, mas não são 
adequados para gerenciar blocos maiores de texto. 
Predisposição do JSP Embora o uso de uma arquitetura MVC possa tornar seus 
recursos disponíveis para qualquer sistema de 
apresentação, há uma predisposição de longa data do 
Struts para JSP. 
Localização de exceções do JSP Muitas mensagens no nível de sistema, como as exceções 
JSP, não são localizadas e sempre exibidas em Inglês. 
As propriedades das tags são 
explicativas 
As extensões das tags do Struts podem requerer vários 
parâmetros e podem ser difíceis de programar. 
Assinaturas perform e execute Assinatura perform é um limite quando da invocação das 
Actions, constituindo um obstáculo arquitetural. 
Nomenclatura não clara Pequenas inconsistências encontradas na nomenclatura 
de classes e parâmetros confundem os novos 
desenvolvedores e tornam o framework mais difícil de 
aprender. 
Fonte: HUSTED, 2005, p. 52. 
 
Por outro lado o Struts possui inúmeros pontos fortes, como descrito na 
Tabela 2: 
 
Tabela 2: Pontos fortes do Struts. 
Capacidade Observações 
 
 
21
Centrado no HTTP O Struts é desenhado em torno de um modelo de solicitação-resposta 
(request-response) padrão HTTP, familiar para muitos desenvolvedores 
Web. 
Registro padrão O Struts pode usar o sistema de registro default (padrão) do contêiner e 
não requer outro pacote para ser configurado ou entendido. 
Registro da depuração 
opcional 
Registra opcionalmente várias mensagens de status (situação) durante 
o processamento que podem ser úteis na depuração. 
Modelo neutro O Struts não é predisposto para nenhuma camada particular de 
permanência. 
Configuração centralizada A configuração do Struts encapsula o detalhe da implementação para 
uma aplicação ou módulo da aplicação, portanto pode ser revisado e 
gerenciado como um todo. 
Arquivo de recursos de 
mensagens diferentes para 
cada local 
Adicionar suporte a um novo local representa apenas adicionar outro 
arquivo de mensagens. 
Leve O Struts tem, relativamente, poucas classes básicas para os 
desenvolvedores aprenderem. 
Fonte aberta O código-fonte completo é fornecido sob a Apache Software License, 
deixando todas as suas opções abertas. 
Comunidade forte de 
desenvolvedores 
O número de desenvolvedores que utilizam Struts é grande, formando 
uma comunidade bastante ativa. 
Comunidade de 
revendedores 
O Struts é incorporado por vários produtos. 
Suporte Tratado em vários livros e artigos, possui fóruns profissionais com larga 
participação dos membros. 
Equipe de 
desenvolvimento 
Mais de 30 desenvolvedores contribuíram para a criação da versão 1.1 
do Struts. 
Versões estáveis As versões formais são submetidas a longos períodos de testes, o que 
assegura um produto com alta qualidade. 
Suporte ao i18n O suporte a localização (internacionalização) está completamente 
predefinido no Struts. 
Extensões de tags. Possui conjunto completo de extensões de tags com finalidade geral 
além daquelas específicas do framework. 
Boa documentação Os JavaDocs (arquivos de documentação) do Struts são detalhados e 
completos, evitando consultas ao código-fonte do mesmo. 
Baseado nos padrões de 
construção (Design 
Patterns) 
Implementa em sua arquitetura vários padrões clássicos de 
desenvolvimento. 
Extensível Todas as suas definições padrão podem ser configuradas. As classes 
básicas podem ser anuladas e as subclasses carregadas em seu lugar. 
 
 
22
O desenvolvedor pode personalizar as classes-chave como por 
exemplo, ActionForm e Action. 
Fonte: HUSTED, 2005, p. 53. 
 
Em busca da união entre o controle e o gerenciamento da aplicação Web 
com o desenvolvimento visual das aplicações desktop, os arquitetos da informação 
objetivaram desenvolver uma alternativa capaz de tornar a criação de portais de 
Internet mais prazerosa e semelhante à programação tradicional, surge, então, o 
JavaServer Faces. 
 
 
 
 2.2.1.2 Framework JavaServer Faces (JSF) 
 
 
De acordo com a definição de seus próprios criadores (Sun Microsystems, 
Inc.) JavaServer Faces, ou apenas, Faces, é um framework para desenvolvimento 
de aplicações baseadas na Web, compondo uma combinação entre o framework 
Apache Struts e a API Java voltada para interfaces gráficas, Swing. Tal como o 
Struts, o JSF provê o gerenciamento do ciclo (fluxo) da aplicação Web através de 
um controlador Servlet, e como o Swing, JSF fornece umrico e completo modelo de 
componentes com manipulação de eventos e renderização de componentes. 
 
JavaServer Faces é um padrão JEE e atualmente está em sua versão 1.2 
liberada pela Java Community Process (JCP) sob a especificação JSR-25211. Esta 
que é uma atualização a versão 1.1, registrada sob número JSR-127. Já está em 
desenvolvimento a JSR-314, que trata da versão 2.0 do JavaServer Faces. 
Participam do projeto: Apache Software Foundation, IBM, Sun Microsystems, Oracle, 
entre outras. 
 
De acordo com Mann (2005, p. 4) nos períodos que antecederam o 
surgimento do desenvolvimento voltado para a Web falava-se em RAD, Rapid 
Application Development, cujo principal objetivo era permitir a construção de 
 
11 http://www.jcp.org/en/jsr/detail?id=252. Consultado em 27 de agosto de 2008. 
 
 
23
poderosas aplicações com um conjunto de componentes reutilizáveis. Quem alguma 
vez usou ferramentas como Visual Basic, PowerBuilder, ou Delphi, sabe que eles 
eram um grande salto no desenvolvimento de aplicações de alta produtividade. Pela 
primeira vez, tornou-se fácil desenvolver interfaces de usuário complexas e integrá-
las com fontes de dados. 
Uma das propostas do JSF é permitir que as técnicas de “arrastar e 
soltar” (drag and drop) oriundas da tecnologia RAD possam ser utilizadas no 
desenvolvimento de aplicações voltadas para a Internet. 
 
Mann (2005, p. 4) destaca: 
Ferramentas RAD eram excelentes para o desenvolvimento de aplicações desktop, mas 
também foram bastante úteis para prototipagem rápida, pois elas poderiam criar 
rapidamente uma interface com pouco ou nenhum código. Além disso, menores 
barreiras de entrada permitiam, tanto programadores experientes quanto novatos, obter 
resultados imediatos. 
 
Dentro da perspectiva RAD, o JSF possui as seguintes partes: 
• Um conjunto de componentes pré-fabricados de interface de usuário. 
Por exemplo: botões, hyperlinks12, caixas de seleção e campos de texto. 
• Um modelo de programação orientado a eventos; 
• Um modelo de componentes que permite a desenvolvedores 
independentes fornecerem componentes adicionais. 
• O JSF, assim como o Struts, é um framework concebido dentro dos 
padrões do Model 2, os pontos básicos são (MANN, 2005, p. 18): 
• Consiste no uso dos Plain Old Java Objects (POJOs13), EJBs14, ou 
semelhantes; 
• Para a camada de visão (View) podem ser utilizados JSPs ou outras 
tecnologias de demonstração; 
• O controlador é sempre implementado em forma de Servlet. 
A infra-estrutura de aplicações Web pode ser encarada com uma pilha de 
serviços. Os serviços mais próximos da base prestam soluções mais básicas de 
canalização, mas de pouca abstração. Já os serviços do topo proporcionam maior 
 
12 Referência em um documento hipertexto para outro documento ou recurso na Web. 
13 Plain Old Java Objects: Objetos Java simples. 
14 Enterprise JavaBean: componente da plataforma JEE. http://java.sun.com/products/ejb/index.jsp 
 
 
24
abstração. Possuindo todos os serviços em conjunto obtém-se uma estrutura 
extremamente poderosa. (MANN, 2005, p. 20) 
A Figura 6 apresenta a relação entre JSF, Struts, JSPs, Servlets e os 
tradicionais Web Servers. A disposição das tecnologias na margem direita da figura 
demonstra a evolução gradual ocorrida na infra-estrutura das aplicações Web. É 
possível observar o momento comum (navegação, validação, Model 2, etc.) entre o 
JSF e o Struts, e a posterior superação do primeiro. 
 
 
Figura 6: Infra-estrutura de aplicações Web. 
Fonte: MANN, 2005, p. 20. 
 
 
A separação entre a apresentação e a lógica de negócios é um tema 
central sobre o design de aplicações Web, situação reforçada pelo padrão MVC. Na 
implementação JSF esta separação é realizada por beans. 
Os JavaBeans, ou apenas Beans, diferentemente dos objetos, podem ser 
configurados e manipulados sem o uso de programação. 
Tradicionalmente, os beans, são utilizados como componentes de 
interface de usuário (botões, campos de texto etc), porém, no contexto JSF são 
 
 
25
utilizados, sempre que preciso, para ligar classes Java a páginas Web ou arquivos 
de configuração. 
“[...] o desenvolvedor JSF não precisa escrever nenhum código para 
construir ou manipular um bean user. A implementação JSF constrói os beans de 
acordo com os elementos managed-bean (do inglês, bean gerenciado) contidos no 
arquivo de configuração”. (GEARY, 2007, p. 32) 
Em uma aplicação os beans são normalmente usados para : 
• Componentes de interface de usuário; 
• Uniformizar o comportamento de um formulário (backing beans); 
• Objetos de negócios cujas propriedades são exibidas nas páginas 
Web; 
• Serviços como fontes de dados externas, que precisem ser 
configurados quando uma aplicação for montada. 
 
De modo geral, as aplicações JSF rodam sobre um servlet container, e 
tradicionalmente contêm as seguintes características15: 
• Componentes JavaBeans que contém as especificações de 
funcionalidade e dados; 
• Interpretadores de eventos; 
• Páginas JSP; 
• Classes auxiliares para o lado servidor, tais como de acesso a banco 
de dados. 
• Uma tag library para renderização de componentes UI sobre a página; 
• Uma tag library para representação de manipuladores de eventos, 
validadores e outras ações. 
• Componentes UI representados como objetos estáticos (stateful) no 
servidor; 
• Backing beans, que definem propriedades e funções para os 
componentes UI; 
• Validadores, conversores e gerenciadores de eventos; 
• Um arquivo de configuração para a aplicação onde são especificados 
os recursos da aplicação. 
 
15 The J2EE 1.4 Tutorial, cap. 17. http://java.sun.com/j2ee/1.4/docs/tutorial/doc/ 
 
 
26
 
Diferentemente do framework Struts a especificação JSF define seis fases 
distintas, conforme mostrado na Figura 7. 
 
Figura 7: Ciclo de vida do JavaServer Faces. 
Fonte: GEARY, 2007. 
 
 
Geary (2007, p. 28) descreve as fases da seguinte forma: 
1. Restaurar Visão (Restore View): recupera a árvore de componentes 
para a página requisitada caso ela tenha sido exibida anteriormente (inclusive 
mantendo as informações inseridas pelo usuário), ou constrói uma nova árvore de 
componentes, caso esteja sendo exibida pela primeira vez. Caso a requisição não 
contenha os dados solicitados, o controlador pula para a fase de Renderizar 
resposta (Render response). Isto acontece quando a página é exibida pela primeira 
vez. 
2. Aplicar Valores de Requisição (Apply Request Values): Cada objeto 
verifica quais valores requisitados pertencem a ele e armazena-os. 
3. Processar Validações (Process Validations): Os valores aplicados no 
passo anterior são validados (testados) e aplicados como “valores locais”. Caso 
ocorram erros de conversão ou validação, o controlador invoca a fase de Renderizar 
Resposta, para que o usuário re-informe os dados (inputs). 
4. Atualizar Valores do Modelo (Update Model Values): Os valores locais 
são usados para atualizar os beans vinculados aos componentes. 
 
 
27
5. Invocar Aplicação (Invoke Application): O método Action do 
componente (botão ou link) que causou o envio do formulário. Após a sua execução 
retorna uma String16 com o resultado. Esta é passada para o controlador de 
navegação, que por sua vez procura a página seguinte. 
6. Renderizar Resposta (Render response): Codifica a resposta e a envia 
para o navegador. 
A Listagem 7 é demonstra um bean gerenciado do JSF, neste caso ele é 
responsável por obter as informações definidas através da interface com o usuário. 
Na Listagem 8 pode-se observar que seu escopo é de request, ou seja, “<managed-
bean-scope>request</managed-bean-scope>”. 
 
public class UserForm { 
 
private String id; 
public User user = new User(); 
public UserManager mgr; 
 
public void setId(String id) { 
this.id = id; 
} 
 
public voidsetUser(User user) { 
this.user = user; 
} 
 
public void setUserManager(UserManager userManager) { 
this.mgr = userManager; 
} 
 
public String edit() { 
if (id != null) { 
// assuming edit 
setUser(mgr.getUser(id)); 
} 
 
return "success"; 
} 
Listagem 7: Código fonte de um Managed Bean. (RAIBLE, 2006) 
 
 
Na Listagem 8 é exibido o arquivo “faces-config.xml”, responsável pela 
configuração da aplicação. Neste arquivo são definidas as regras de navegação 
(“<navigation-rule>”), informando para qual página o usuário será redirecionado 
após a submissão (request). 
 
16 Conjunto de caracteres alfanuméricos. 
 
 
28
<application> 
<variable-resolver> 
org.springframework.Web.jsf.DelegatingVariableResolver 
</variable-resolver> 
<locale-config> 
<default-locale>en</default-locale> 
<supported-locale>en</supported-locale> 
</locale-config> 
<message-bundle>messages</message-bundle> 
</application> 
 
<navigation-rule> 
<from-view-id>/userForm.jsp</from-view-id> 
<navigation-case> 
<from-outcome>*</from-outcome> 
<to-view-id>/userList.jsp</to-view-id> 
<redirect/> 
</navigation-case> 
<navigation-case> 
<from-outcome>cancel</from-outcome> 
<to-view-id>/userList.jsp</to-view-id> 
</navigation-case> 
<navigation-case> 
<from-outcome>success</from-outcome> 
<to-view-id>/userList.jsp</to-view-id> 
<redirect/> 
</navigation-case> 
</navigation-rule> 
 
<managed-bean> 
<managed-bean-name>userForm</managed-bean-name> 
 
<managed-bean-class> 
org.appfuse.Web.UserForm 
</managed-bean-class> 
 
<managed-bean-scope>request</managed-bean-scope> 
 
<managed-property> 
<property-name>id</property-name> 
<value>#{param.id}</value> 
</managed-property> 
 
<managed-property> 
<property-name>userManager</property-name> 
<value>#{userManager}</value> 
</managed-property> 
 
</managed-bean> 
Listagem 8: Arquivo faces-config.xml do JSF. (RAIBLE, 2006) 
 
 
Para a camada de visão, o JSF utiliza sua tag library para formatação das 
páginas JSP, conforme demonstrado na Listagem 9. Observa-se a vinculação com 
os demais arquivos através do identificador do formulário (<h:form id="userForm">). 
 
 
29
Através desta informação os dados informados no formulário são enviados ao bean 
descrito na Listagem 7. Em caso de erro na validação de algum campo, a aplicação 
retorna seu fluxo ao formulário e, as tags como “<h:message for="firstName" 
styleClass="errorMessage"/>” exibem as mensagens ao usuário. 
 
 
<f:view> 
 
<f:loadBundle var="messages" basename="messages"/> 
 
<h:form id="userForm"> 
<h:inputHidden value="#{userForm.user.id}"> 
<f:convertNumber/> 
</h:inputHidden> 
 
<h:panelGrid columns="3" styleClass="detail" columnClasses="label"> 
 
<h:outputLabel for="firstName" 
value="#{messages['user.firstName']}"/> 
<h:inputText value="#{userForm.user.firstName}" id="firstName"/> 
<h:message for="firstName" styleClass="errorMessage"/> 
 
<h:outputLabel for="lastName" 
value="#{messages['user.lastName']}"/> 
<h:inputText value="#{userForm.user.lastName}" id="lastName" 
required="true"/> 
<h:message for="lastName" styleClass="errorMessage"/> 
 
<h:outputLabel for="birthday" 
value="#{messages['user.birthday']}"/> 
<t:inputCalendar monthYearRowClass="yearMonthHeader" 
weekRowClass="weekHeader" id="birthday" 
currentDayCellClass="currentDayCell" 
value="#{userForm.user.birthday}" 
renderAsPopup="true" addResources="false"/> 
<h:message for="birthday" styleClass="errorMessage"/> 
</h:panelGrid> 
</h:form> 
 
</f:view> 
Listagem 9: Arquivo de View, página JSP formatada com tags JSF. (RAIBLE, 2006) 
 
E, por fim, a Figura 8, exibe o resultado que, após interpretado pelo 
navegador, será apresentado ao usuário. 
 
 
30
 
Figura 8: Resultado final para o usuário. 
Fonte: RAIBLE, 2006. 
 
 
Raible (2006) elenca alguns fatores positivos e negativos em relação ao 
JSF. Os primeiros: 
• Padrão JEE – grande demanda e vasta gama de empregos; 
• Desenvolvimento rápido e fácil; 
• Framework rico no gerenciamento de fluxo (navegação). 
 
Em relação aos pontos negativos, o autor destaca: 
• “Sopa” de tags para as páginas JSP; 
• Não ser pleno nas questões de Seguraça ou REST (Transferência de 
Estado Representacional); 
• Não ter uma única fonte para a implementação. 
 
Na comparação dos Frameworks Struts vs. JSF, Raible (2006) destaca 
alguns aspectos que podem ser vistos na Tabela 3. 
 
 
 
31
 
Tabela 3: Comparativo de algumas funcionalidades Struts vs. JSF. 
Funcionalidade Struts JSF 
Integração com listas de dados e 
paginação. 
 
Utiliza uma tag de exibição 
específica que faz parte da 
tag library; 
 
Possui uma tabela de dados 
(DataTable) sem ordenação. 
Redirecionamento pós 
autenticação e o armazenamento 
de URLs (bookmarking). 
 
Permite total controle sobre 
as URL (endereços); 
Efetua requisições (POST) 
para todos os fluxos, URLs 
não são consideras. 
 
Configuração dos validadores e 
suas mensagens. 
 
Utiliza uma solução madura, 
conhecida por 
CommonsValidator 
Possui mensagens padrão 
não tão agradáveis, porém 
são facilmente configuráveis. 
 
Testabilidade Disponibiliza StrutsTestCase 
que é uma extensão do JUnit 
que permite teste unitários 
nas Actions da aplicação. 
As classes de páginas JSF 
podem ser facilmente 
testadas. 
Capacidade de manutenção de 
mensagens durante 
redirecionamentos (redirect after 
POST): 
 
Permite mensagens oriundas 
de redirecionamentos 
JSF requer uma solução 
personalizada, mensagens 
internacionalizadas (i18n) são 
difíceis de serem gerenciadas 
em páginas que manipulam 
beans. 
Internacionalização Utiliza um arquivo de 
recursos (ResourceBundle) 
por localidade. 
Requer a declaração do 
arquivo de recursos na 
própria página. 
 
Fonte: RAIBLE, 2006. 
 
 
 
2.2.2 Frameworks ORM 
 
 
Nos dias atuais, tão importante quanto as funcionalidades de um software 
é a competência com a qual armazena os dados e informações inseridas por 
usuários e sistemas externos. Ou seja, a grande maioria dos softwares comerciais 
existentes no mercado somente torna-se verdadeiramente efetiva quando exerce a 
capacidade de persistir aquilo que é inserido e produzido por ele. 
Quase todos os aplicativos requerem dados persistentes. A persistência é 
um dos conceitos fundamentais em desenvolvimento de aplicativos. “Se um sistema 
de informação não preservasse os dados inseridos pelos usuários quando a 
 
 
32
máquina anfitriã fosse desligada, o sistema seria de pequeno uso prático” (BAUER, 
2005). 
Grande parte dos desenvolvedores de sistemas conhecem e utilizam a 
persistência de dados em forma de bancos de dados relacionais. De acordo com 
Bauer (2005) a tecnologia relacional é um denominador comum de muitos sistemas 
discrepantes e plataformas de tecnologias, tornando-se a representação mais 
comum para entidades de negócios. 
A SQL (Structured Query Language) ou Linguagem de Consulta 
Estruturada figura como ferramenta essencial para a manipulação dos bancos de 
dados relacionais, de tal importância que muitos desenvolvedores passam a chamá-
los de bancos de dados SQL. 
No entanto, nos últimos sete anos, a aceitação generalizada da 
linguagem de programação Java provocou a ascendência do paradigma orientado a 
objetos para o desenvolvimento de softwares. Este novo modelo quando voltado 
para as funções de persistência conduziu arquitetos e desenvolvedores a 
incompatibilidade do paradigma objeto/relacional. 
É neste momento, em meio a um debate caloroso sobre o “problema” da 
persistência, que surge uma solução chamada de Mapeamento Objeto/Relacional 
(ORM), que vem encontrando aceitação crescente. 
 
Para esta nova abordagem, Bauer (2005) explica que: 
[...] ao invés de trabalhar diretamente com as linhas e colunas de um conjunto de 
resultados SQL, a lógica de negócios interage com o [...] modelo de domínio orientado 
para objetos e sua realização em tempo de execução (runtime) como um gráfico de 
objetos interconectados.A lógica de negócios nunca é executada dentro de um banco de 
dados (como um procedimento armazenado SQL) mas, sim, implementada em Java. 
Isso permite que a lógica de negócios faça uso de conceitos orientados para objetos 
sofisticados como herança e polimorfismo. 
 
O mapeamento objeto/relacional é a persistência de objetos automatizada 
e transparente dentro de um aplicativo Java para as tabelas de um banco de dados 
relacional. 
A solução do ORM consiste nas quatro seguintes peças: 
1. Uma API para executar operações CRUD; 
2. A linguagem ou API para especificar consultas que referenciam classes 
e propriedades de classes; 
3. Um recurso para especificar o mapeamento de metadados; 
 
 
33
4. Uma técnica para a implementação do ORM para interagir com objetos 
transacionais a fim de executar a verificação suja, buscas de associações ociosas e 
outras funções de otimização. (BAUER, 2005) 
Quando uma implementação ORM como Hibernate3 ou Toplink é utilizada 
é fundamental que estas se baseiam na “idéia de separação entre interface, domínio 
e persistência. Todas as operações e consultas da interface são realizadas por meio 
da camada de domínio, e não em expressões SQL” (WAZLAWICK, 2004). 
De acordo com Wazlawick (2004) o Diagrama de Classes de Projeto 
permite a geração automática de uma estrutura de banco de dados relacional, a qual 
reflete, em memória secundária, exatamente a informação que os objetos 
representam em memória primária. 
Cada classe deve representar uma tabela e cada atributo classe um 
campo desta. A Figura 9 demonstra esta equivalência. 
 
 
Figura 9: Equivalência entre elementos do projeto orientado a objetos e o modelo 
relacional. 
Fonte: WAZLAWICK, 2004. 
 
Na prática, o que ocorre é a “tradução” do modelo de classes para o 
modelo relacional, implementado em grande parte das tecnologias de Banco de 
Dados utilizados atualmente. Como resultado deste trabalho pode-se aliar o 
desempenho desses repositórios com a dinamicidade e a as potencialidades da 
programação orientada a objetos. 
 
 
34
3 MATERIAIS E MÉTODOS 
 
Diante das inúmeras tecnologias existentes atualmente e da velocidade 
com que novas ferramentas surgem e adentram ao ambiente das empresas cabe 
aos profissionais de TI estar em permanente contato e buscar conhecer as novas 
criações a fim de aprimorar o desenvolvimento dos softwares de maneira geral. 
No que diz respeito ao processo de análise e projeto de sistemas, a 
técnica desenvolvida pelo Professor Raul Sidnei Wazlawick (WAZLAWICK, 2004) 
vem tendo grande aceitação por analistas e arquitetos. Baseada no Processo 
Unificado, a metodologia será utilizada como base para o desenvolvimento do 
sistema e será mais bem descrita na seqüência. 
Igualmente inovador, o framework MVC brasileiro Mentawai, que propõe a 
configuração programática (linguagem Java) da aplicação, servirá de plataforma 
para a camada de apresentação. 
Já a camada de persistência será implementada com o auxilio do 
framework ORM Java Persistence API (JPA) que compõe a especificação EJB 3.0 
(Enterprise JavaBean), efetivada através do banco de dados relacional MySQL. 
Estas ferramentas e tecnologias são descritas a seguir. 
 
 
 
3.1 ANÁLISE E PROJETO ORIENTADO A OBJETOS 
 
 
Classicamente, o processo de desenvolvimento de software divide-se em 
quatro grandes fases: análise, projeto, implementação e testes. 
A primeira etapa, a análise, tem como objetivo levar o analista a investigar 
e descobrir a realidade para a qual o sistema será elaborado. 
De acordo com Wazlawick (2004) esta etapa é importantíssima porque 
ninguém é capaz de entender com perfeição um problema usual de sistemas de 
informação na primeira vez que o olha. 
 
 
 
35
O processo de análise, então, será o enunciado do problema e, o projeto 
será uma proposta para sua resolução. Assim, a fase de projeto enfatizará uma 
proposição de solução que atenda aos requisitos da análise. 
Baseado no Processo Unificado (também conhecido como RUP, ou 
Rational Unified Process), fortemente associado à anotação UML, Wazlawick (2004) 
enfatiza que a fase de concepção incorpora o estudo de viabilidade e uma parte da 
análise de requisitos. A fase de elaboração incorpora a maior parte da análise de 
requisitos, a análise de domínio e o projeto. A fase de construção corresponde a 
programação e testes, e a fase de transição consiste na instalação e manutenção do 
sistema. 
A figura 10 resume as fases e a dinâmica do ciclo de vida interativo do 
UP: 
 
 
Figura 10: Ciclo de vida de software baseado em ciclos interativos. 
Fonte: WAZLAWICK, 2004, p. 24. 
 
Wazlawick (2004) salienta: 
 
O UP propõe um processo ágil, com poucos artefatos e pouca burocracia, o qual permite 
o desenvolvimento de software rapidamente, pois o que interessa ao cliente é o software 
pronto, e não uma pilha de documentos justificando por que não ficou pronto. A 
documentação deve ser dirigida para a produção do software. Cada passo no processo 
tem um objetivo muito claro e uma utilização precisa, visando sempre à produção de um 
código que atenda aos requisitos do melhor jeito possível no menor tempo. 
 
O projeto orientado a objetos tem como seu núcleo, o Diagrama de 
Classes, denominado DCP – Diagrama de Classes de Projeto. 
Ao contrário do que muitos pensam, de que os “diagramas são feitos para 
documentar”, os diagramas do processo unificado visam contribuir efetivamente para 
a fase de construção, gerando, em muitos casos, o próprio código que deverá 
 
 
36
compor a aplicação. Com o auxilio dos diagramas de seqüência, diagramas de 
colaboração e padrões de projeto (design patterns) e, baseado nas etapas 
anteriores é construído o diagrama de classes. 
O diagrama de classes é um esquema que descreve as classes que 
comporão o sistema. Cada classe descreve um conjunto de características familiares 
a um determinado tema, podendo ser composta por propriedades (atributos) e 
serviços (métodos). Quando esta classe torna-se concreta (instanciada) passa a ser 
chamada de Objeto. 
Por exemplo, a classe Funcionário possui os atributos nome e 
naturalidade e, os métodos definirNome() e definirNaturalidade(). A 
classe Funcionário instanciada torna-se um objeto, cujos atributos podem ser 
definidos através de seus métodos. Quando invoca-se definirNome(“João”) 
imediatamente a propriedade “nome” do novo objeto é alterada. 
 
 
 
3.2 LINGUAGEM DE PROGRAMAÇÃO JAVA 
 
 
Linguagem de programação criada por James Gosling na década de 90 
na Sun Microsystems. Similar à C#17 na sua sintaxe, mas orientada a objetos. Utiliza 
máquina virtual que interpreta o código compilado em bytecode, tornando 
extremamente portável entre sistemas diferentes, desde embarcados até 
mainframes. A plataforma EE – Enterprise Edition, plataforma empresarial – volta 
para desenvolvimento de aplicações para servidores. Possui Servlets e JSPs uma 
especialização do Servlet que permite alocação de código Java e código HTML 
(HyperText Markup Language). (DEITEL,2005, p. 6). 
 
 
 
 
 
 
17 Linguagem orientada a objetos derivada do C e do C++. 
 
 
37
3.2 CAMADA DE VISÃO - FRAMEWORK MVC MENTAWAI 
 
 
Inúmeros são os Frameworks existentes hoje no mercado (dois foram 
demonstrados no Capítulo II). Neste vasto ambiente insere-se o framework 
Mentawai. Desenvolvido por brasileiros, o Menta, como foi apelidado, propõe-se a 
abolir por completo o uso de XML e Annotations18 para sua configurações. Adotando 
a configuração programática, o Mentawai figurou como primeiro framework Web 
MVC a adotar, implementar, documentar e incentivar todo e qualquer tipo de 
configuração (Actions, filtros, validações, listas, pool de conexões, Inversão de 
Controle, etc.) através de arquivos Java. (http://www.mentaframework.org) 
O framework nasceu em oito de junho de 2005 e em pouco mais de um 
mês nascia o ApplicationManager:configuração em código Java independente do 
restante da aplicação e centralizada numa única classe. 
Apesar das críticas iniciais devido à aversão a XML, as vantagens da 
configuração programática foram gradualmente sendo elucidadas: 
• Mais natural, pois trata-se de código Java e não de uma especificação 
em XML. 
• Menos propensa a erros, já que uma configuração em Java pode ser 
compilada antes de ser carregada pela aplicação Web. 
• Ótima integração com IDEs (Integrated Development Environment ou 
Ambiente Integrado de Desenvolvimento), permitindo usar recursos como auto-
completar, auto-compilar (build automático), refactoring (refatoração), etc. 
• Flexibilidade total que apenas uma linguagem de programação pode 
oferecer, o que permite criar seus próprios métodos de configuração, laços, testes, 
ou seja, o desenvolvedor possui liberdade para fazer a configuração se adaptar e 
não o desenvolvedor se adaptar ao XML. 
• Utilizar linguagens de script como JRuby, Groovy, BeanShell, entre 
outras. para configurar sua aplicação, possibilitando uma configuração dinâmica que 
pode ser recarregada automaticamente pelo contêiner a cada modificação. 
• Possibilidade de documentação (JavaDoc) da configuração realizada e 
dos métodos utilizados. 
 
18 Anotações utilizadas para configuração inseridas diretamente no código Java. 
 
 
38
Outra característica do framework é o comprometimento em abstrair e 
simplificar as principais tarefas recorrentes de todo projeto Web. Ao invés de 
direcionar o desenvolvedor a outros Frameworks o Menta procura oferecer soluções 
ou abstrações para as funcionalidades básicas de toda aplicação: pool de conexões 
com o banco de dados, autenticação, autorização, IoC (Inversão de Controle), envio 
de e-mail, upload de arquivo, paginação, tag library, etc. 
Atualmente, o Mentawai é utilizado em ambiente de produção de diversas 
empresas, o destaque internacional é a Sun Microsystems que o está utilizando em 
alguns servidores de sua Intranet (rede corporativa privada) e a referência nacional é 
o Tribunal de Contas do Ceará. O framework possui uma comunidade ativa de 
usuários e desenvolvedores19. 
Na maioria das aplicações controladas por Frameworks MVC a 
configuração é realizada através de arquivos XML. No Mentawai todas as 
especificações da aplicação são feitas na classe ApplicationManager. Ela conterá as 
informações principais da aplicação. (OLIVEIRA, 2005) 
De acordo com Oliveira (2005), o Mentawai utiliza o paradigma de Actions 
(ações). Suas principais características são: 
• Uma Action tem uma entrada (org.mentawai.core.Input) e uma 
saída (org.mentawai.core.Output); 
• Toda ação gera um resultado (java.lang.String) ao término de sua 
execução, normalmente sucesso ou erro. Sendo que o desenvolvedor pode criar 
outros resultados. 
• Para cada resultado há uma conseqüência 
(org.mentawai.core.Consequence). Estas conseqüências, para aplicações 
Web, normalmente são Forward ou Redirect. Da mesma forma que os resultados, o 
desenvolvedor pode criar suas próprias conseqüências; 
Uma ação tem acesso aos Contextos (org.mentawai.core.Context), 
que são para a aplicação Web um contexto de sessão 
(org.mentawai.core.SessionContext) ou um contexto de aplicação 
(org.mentawai.core.ApplicationContext). O framework permite a criação 
de contextos pelo próprio desenvolvedor. 
 
 
19 http://www.mundojava.com.br/NovoSite/21materiacapa.shtml 
 
 
39
Um exemplo de action Mentawai pode ser vista na Listagem 10. 
package examples.hello; 
 
import org.mentawai.core.*; 
 
public class HelloMentawai extends BaseAction { 
 
 public String execute() throws ActionException { 
 String username = input.getStringValue("username"); 
 if (username == null || username.trim().equals("")) { 
 return ERROR; 
 } 
 output.setValue("username", username.toUpperCase()); 
 return SUCCESS; 
 } 
 
} 
Listagem 10: Exemplo de Action Mentawai. 
Fonte: OLIVEIRA, 2005. 
 
A ação descrita na Listagem 10 procura por um parâmetro “username” no 
seu input (entrada de dados). Como retorno ela envia para o output (saída de dados) 
o parâmetro “username” convertido para maiúsculo. 
Se nome de usuário recebido (vindo da página JSP) estiver vazio o 
resultado da Action será ERROR, caso contrário será SUCCESS. 
A Action HelloMentawai herda a classe BaseAction do framework 
que é uma interface que provê acesso a dados protegidos, acesso a dados de 
entrada (input) e saída (output), acesso ao contexto da sessão e da aplicação, entre 
outras funcionalidades. 
Para garantir o funcionamento da Action é preciso que a mesma esteja 
configurada no ApplicationManager, sem XML, apenas código Java, conforme 
descrito na Listagem 11. 
 
 
public class ApplicationManager extends 
org.mentawai.core.ApplicationManager { 
 
 
public void loadActions() { 
 
ActionConfig ac = new 
ActionConfig("/HelloWorld",HelloMentawai.class); 
 
ac.addConsequence(HelloMentawai.SUCCESS, new 
Forward("/hello.jsp")); 
 
ac.addConsequence(HelloMentawai.ERROR, new 
 
 
40
Forward("/username.jsp")); 
 
addActionConfig(ac); 
 
} 
} 
Listagem 11: Exemplo do ApplicationManager. (OLIVEIRA, 2005) 
 
 
Em caso de erro o usuário é direcionado à página “username.jsp” 
(Listagem 12) que fez o primeiro envio de dados à Action. 
<html> 
<body> 
<h1>Hello Metawai!</h1> 
<form Action="HelloWorld.mtw" method="post"> 
Type an username: <input name="username" size="25" /> 
<input type="submit" value="Send"> 
</form> 
</body> 
</html> 
Listagem 12: Formulário que envia os dados para a Action, “username.jsp”. 
(OLIVEIRA, 2005) 
 
Em caso de sucesso a navegação é direcionada para a página 
“hello.jsp” (Listagem 13), onde são utilizadas tags específicas do Menta para 
exibição de dados nos formulários JSP. 
 
<%@ taglib uri="/WEB-INF/lib/mentawai.jar" prefix="mtw" %> 
<html> 
<body> 
<h3>Hello <mtw:out value="username" /> from Mentawai!</h3> 
</body> 
</html> 
Listagem 13: Formulário que recebe os dados da Action, “hello.jsp”. (OLIVEIRA, 
2005) 
 
Em suma, o Mentawai é um framework com uma proposta diferenciada, 
que visa proporcionar flexibilidade e agilidade, sem exigir de seus usuários profundo 
conhecimento em XML. 
 
 
 
 
 
 
41
3.3 CAMADA DE PERSISTÊNCIA – FRAMEWORK EJB 3 
 
 
A chave para a simplificação do desenvolvimento de softwares 
empresariais é proporcionar Frameworks capazes de esconder a complexidade (tais 
como transações, segurança, e persistência) dos desenvolvedores. Um framework 
bem concebido promove reutilização de código, aumenta a produtividade do 
programador, e resulta em melhor qualidade de software. (YUAN, 2005) 
Um dos principais motivos da escolha dos desenvolvedores pela 
plataforma Java é a sua independência de vendedor. Da mesma forma o EJB 3.0 
(Enterprise JavaBeans) é um padrão aberto concebido por fornecedores 
independentes. Sua especificação é desenvolvida e apoiada por todos os grandes 
fornecedores, open source ou comerciais, da comunidade Java. 
O framework EJB 3.0 isola os desenvolvedores da aplicação servidora. 
Ou seja, ao contrário da solução JBoss20 cuja implementação é baseada em 
Hibernate21 e, da Oracle que é baseada em Toplink22, os desenvolvedores, para se 
utilizarem do EJB 3.0 não precisam conhecer as APIs específicas destes 
fornecedores. 
Sem depender de arquivos XML de configuração externos os POJO são, 
através de annotations (anotações, metadados), transformados em beans, 
Enterprise JavaBeans (PANDA, 2007). A Figura 11 demonstra essa transformação. 
 
 
Figura 11: EJB são objetos Java configurados através de annotations. 
Fonte: PANDA, .2007, p. 8. 
 
O EJB foi desenvolvido para prestar suporte às camadas de negócio e de 
persistência. A Figura 12 exibe a localização do framework EJB dentro da 
arquitetura de quatro camadas (Apresentação,