ePublicity

ePublicity
Lúcio Samuel Gomes Morais - 25314
Pedro Filipe Monteiro Mendes - 25686
Trabalho realizado sob a orientação de
Prof. Doutor Paulo Jorge Teixeira Matos
Dr. Ricardo Filipe Afonso Órfão
Engenharia Informática
2012/2013
ePublicity
Relatório da UC de Projeto
Licenciatura em Engenharia Informática
Escola Superior de Tecnologia e de Gestão
Lúcio Morais, Pedro Mendes
Setembro de 2013
iii
A Escola Superior de Tecnologia e Gestão não se responsabiliza pelas opiniões expressas
neste relatório.
iv
Certifico que li este relatório e que na minha opinião, é adequado no seu
conteúdo e forma como demonstrador do trabalho desenvolvido no
âmbito da UC de Projeto.
___________________________________________
Prof. Doutor Paulo Jorge Teixeira Matos, Orientador
Certifico que li este relatório e que na minha opinião, é adequado no seu
conteúdo e forma como demonstrador do trabalho desenvolvido no
âmbito da UC de Projeto.
___________________________________________
Dr. Ricardo Filipe Afonso Órfão, Coorientador
Certifico que li este relatório e que na minha opinião, é adequado no seu
conteúdo e forma como demonstrador do trabalho desenvolvido no
âmbito da UC de Projeto.
___________________________________________
Prof. Doutor Paulo Alexandre Vara Alves, Arguente
Aceite para avaliação da UC de Projeto
v
vi
Agradecimentos
“Mas você – eu não posso nem quero explicar – eu agradeço.”
(Clarice Lispector)
Uma palavra, um olhar, um sorriso, um silêncio… tudo isto pode ser uma forma de
agradecimento mas nada, em momento algum, poderá expressar a gratidão que temos a todos
aqueles que nos apoiaram neste percurso que agora finda!
Agradecemos aos nossos Professores porque nos ajudaram, nos “aturaram” e porque sem eles
não era possível saber o que sabemos hoje. Destes, agradecemos especialmente ao nosso
Orientador, Professor Paulo Matos, pela ajuda na preparação e desenvolvimento deste
trabalho. Um reconhecimento também ao nosso Coorientador, Ricardo Órfão, pela ajuda que
nos prestou.
Aos nossos pais, irmãos e irmãs, tios e tias, família de longe e de perto, aos nossos amigos de
cá, de lá e de sempre: Muito Obrigado!
Um obrigado à própria Escola Superior de Tecnologia e Gestão e ao Instituto Politécnico de
Bragança pela qualidade de Ensino e excelentes condições de trabalho dignas do melhor
Instituto Politécnico de Portugal e à cidade de Bragança e seus conterrâneos por nos terem
acolhido tão bem e nos terem proporcionado os melhores anos da nossa Vida!
E, finalmente, como nada é feito sem a ajuda de cada um de nós, deixamos um agradecimento
muito especial a nós mesmos e a cada um: pelas piadas, pelos risos, pelas horas de
desorientação, por nunca termos desistido, pelo trabalho, pelo reconhecimento e porque “a
Vida é uma aventura, há que viver esta loucura e Amigos para Sempre”, Obrigado pela
verdadeira Amizade que fomos construindo ao longo destes três anos!
E como “there are 10 types of people in the world: those who understand binary and those
who don’t” e nós fazemos parte dos primeiros, ao fim destes três inesquecíveis anos já
podemos dizer: 01100011 01101111 01101110 01110011 01110101 01101101 01100001
01110100 01110101 01101101 00100000 01100101 01110011 01110100 00100001…
vii
viii
Resumo
Ultrapassando a barreira dos US$ 1.000.000.000.000 (triliões de dólares americanos) em 2012
(eMarketer, 2013), o comércio eletrónico tem, ao longo dos anos, ganho adeptos e
proporcionado maior comodidade aos vendedores e compradores pela facilidade de acesso e
negociação.
É necessário cativar as pessoas para que sejam frequentadoras assíduas; quer seja de um
museu, de uma biblioteca ou de um monumento, mas também de um site. Para que tal
aconteça é necessário oferecer segurança, comodidade e simplicidade de assimilação de
informação. Num site como o que se pretende desenvolver, é necessário assegurar vários
aspectos para o utilizador como a confidencialidade e segurança dos dados; e comodidade e
simplicidade de utilização.
O desenvolvimento deste projeto visou colocar em prática um modelo de negócio que visa
aproximar compradores dos vendedores, encurtar distâncias entre ambos, promover uma
oferta mais competitiva, criar oportunidades de negócio mas, acima de tudo, dar mais poder
ao consumidor.
O projeto foi materializado recorrendo à tecnologia Java Server Faces (JSF) e à linguagem
XHTML que proporcionam o suporte ao modelo e às suas aplicações por parte do servidor
(server-side). Esta tecnologia (JSF) permite a gestão dos estados dos componentes de
interface (UI components), a manipulação de eventos, validações do lado do servidor,
definições para a navegação nas e entre páginas e, sob o ponto de vista comercial (à escala
internacional,
como
se
pretende),
um
requisito
muito
importante:
suporte
à
internacionalização e acessibilidade.
Palavras-chave: comércio eletrónico, modelo de negócio
ix
x
Abstract
Overcoming the barrier of US$ 1.000.000.000.000 in 2012 (eMarketer, 2013), e-commerce
has, over the years, gaining followers and provided greater convenience to vendors and
buyers due to the ease of access and trading.
It is required to attract people to become assiduous frequenters; whether a museum, a library
or a monument, but also a site. To make that happens it is required to provide security,
comfort and simplicity in what concerns to assimilation of information. In a site as which is
intended to be developed, it is necessary to ensure some aspects for the user such data
confidentiality and security and commodity and simplicity of utilization.
With the development of this project we intend to put into practice a business model that aims
to approach buyers and vendors, shortening distances between both, promote a more
competitive offer, create business opportunities but, above all, give more leverage to
consumer.
This project was materialized using Java Server Faces (JSF) technology and XHTML
programming language that provide the support of the model and its application on the serverside. This technology (JSF) allows the state management of the interface component (UI
components), event handling, server-side validations, navigation rules inside and between
pages and, from the commercial point of view (in an international scale, as intended), two
very important requisites: internationalization and accessibility support.
Keywords: e-commerce, business model
xi
xii
AVISO
Este trabalho de fim de curso foi realizado sob acordo de confidencialidade e sigilo, através
de documento assinado pelos:
- Executantes do projeto:
Lúcio Samuel Gomes Morais, com o número mecanográfico 25314
Pedro Filipe Monteiro Mendes, com número mecanográfico 25686
- Pelo coorientador: Dr. Ricardo Filipe Afonso Órfão
- E pelo orientador, Prof. Doutor Paulo Jorge Teixeira Matos, a quem é devida a propriedade
intelectual do modelo de negócio subjacente a este trabalho e os resultados alcançados neste
projeto.
O presente relatório foi realizado exclusivamente para efeitos de avaliação do trabalho
efectuado pelos alunos supracitados, à unidade curricular de Projecto. Destina-se
exclusivamente ao arguente, que deverá necessariamente subscrever o acordo de sigilo e
confidencialidade em anexo, remetendo o original para o orientador do trabalho.
Mais se acrescenta que, segundo o acordo de confidencialidade e sigilo, a distribuição ou
divulgação, integral ou parcial, não autorizada deste documento requer a prévia autorização
formal por parte do orientador do projecto.
xiii
Conteúdo
1
Introdução ........................................................................................................................ 21
1.1
Enquadramento ........................................................................................................... 21
1.2
Objetivos ..................................................................................................................... 22
1.3
Estrutura do Documento ............................................................................................. 23
2
Modelo de negócio e principais requisitos ....................................................................... 1
2.1
Descrição....................................................................................................................... 1
2.2
Estrutura de dados ......................................................................................................... 2
3
Arquitetura e Tecnologias................................................................................................. 5
3.1
Java Server Faces (JSF) ................................................................................................ 5
3.2
eXtensible Hypertext Markup Language (XHTML) .................................................... 7
3.3
jQuery ........................................................................................................................... 7
3.4
Asynchronous Javascript and XML (AJAX) ................................................................ 8
3.5
Arquitetura do Sistema ................................................................................................. 8
4
Implementação ................................................................................................................. 14
4.1
Introdução ................................................................................................................... 14
4.2
Message Bundles – Sistema Multilingue .................................................................... 14
4.3
Arquivos de configuração web.xml e faces-config.xml ............................................... 15
4.4
Managed Bean ............................................................................................................ 16
4.5
Facades ....................................................................................................................... 17
4.6
Enterprise Java Beans Entities ................................................................................... 17
4.7
Unidade de Persistência .............................................................................................. 17
4.8
ServletContextListener ................................................................................................ 18
4.9
Phase-listeners ............................................................................................................ 18
4.10
Exception Handler Factory ..................................................................................... 19
4.11
Cookies .................................................................................................................... 19
4.12
Express Checkout – Paypal NVP API ..................................................................... 20
4.13
Google Translate API .............................................................................................. 22
4.14
Sistema automático de notificação .......................................................................... 23
4.15
Serviço de E-mail / SMTP ....................................................................................... 23
xiv
5
4.16
Encriptação, Codificação e Cifragem ...................................................................... 24
4.17
Managed Properties ................................................................................................ 24
4.18
Omnifaces ................................................................................................................ 25
4.19
Primefaces ............................................................................................................... 26
Conclusão ......................................................................................................................... 27
5.1
Análise de resultados .................................................................................................. 27
5.2
Análise autocrítica ...................................................................................................... 28
5.3
Trabalhos futuros ........................................................................................................ 29
15
xvi
Lista de Figuras
Figura 1 – Diagrama de atividades ...................................................................................................................... 2
Figura 2 – Representação do modelo relacional da base de dados ................................................................... 3
Figura 3 – Representação do modelo server-side e integração do MVC ........................................................... 6
Figura 5 – Processamento da UI Component tree na plataforma JSF .............................................................. 9
Figura 6 – Arquitetura do Sistema .................................................................................................................... 11
Figura 7 – Diagrama de casos de uso................................................................................................................. 12
Figura 8 – Diagrama de colaboração................................................................................................................. 12
Figura 9 – Diagrama de sequência NVP API - Paypal..................................................................................... 21
xvii
xviii
Lista de Abreviaturas
AJAX
Asynchronous Javascript And XML
API
Application Programming Interface
EJB
Enterprise Java Bean
EL
Expression Language
HTML
HyperText Markup Language
J2EE
Java Platform, Enterprise Edition
JPA
Java Persistence API
JPQL
Java Persistence Query Language
JSF
Java Server Faces
JSP
Java Server Pages
NVP
Name-Value Pair
MVC
Model-View-Controller
ORM
Object/Relational Mapping
RSS
Rich Site Summary
SGBD
Sistema de Gestão de Bases de Dados
SMTP
Simple Mail Transfer Protocol
UI Components
User Interface Components
URL
Uniform Resource Locator
XHTML
eXtensible HyperText Markup Language
XML
eXtensible Markup Language
xix
xx
Capítulo 1
1 Introdução
1.1 Enquadramento
O objetivo deste projeto foi explorar e demonstrar a viabilidade técnica de um modelo de
comércio eletrónico original, cuja autoria é do Prof. Paulo Matos.
O projeto foi realizado sob acordo de sigilo e confidencialidade, o que limita a informação e
os detalhes que são apresentados neste relatório. Uma vez que este se destina a avaliar o
trabalho desenvolvido na unidade curricular de Projeto, cuja vertente é essencialmente
tecnológica, entendeu-se enfatizar toda a descrição segundo esta perspetiva, omitindo todos os
detalhes considerados confidenciais.
Todas as explicações que, de alguma forma, requerem a perceção do problema são explicadas
segundo um convencional modelo de comércio eletrónico, representativo do tipo de
utilizadores, funcionalidades mais genéricas e requisitos expectáveis neste tipo de negócio.
Desde que a Internet se tornou mais acessível ao cidadão comum, em meados do ano 2000,
muitas pessoas e empresas começaram a aventurar-se no comércio eletrónico (Organization,
2013). Porquê? Este tipo de negócio traz vantagens que podem ser extremamente benéficas:
compra em tempo real; transferência de dinheiro automatizada; mudança de “montra”
(dinamização na mostra de produtos feita com a mudança de algumas linhas de código ou
apenas com alguns cliques); conhecimento em todo o mundo (aldeia global – qualquer parte
do mundo está perto); redução do custo operacional; especificação de um nicho de mercado
(modularizar/categorizar produtos por comprador específico); entre outras.
21
Existem inclusive diferentes modelos e implementações de comércio eletrónico, com
públicos-alvo e finalidades distintas. Desde os simples portais empresariais, com menor ou
maior sofisticação, até aos marketplaces como é o caso da Amazon, eBay, Alibaba, entre
outros. Alguns são de vendas diretas, outros de vendas indiretas, mas todos eles têm como
finalidade criar um canal de comercialização para os produtos que vão comercializar.
O produto, a abrangência comercial, a(s) língua(s) utilizada(s), as formas de pagamento, o
grafismo, a logística, a integração com outras soluções (móveis, redes sociais, afins), são
apenas alguns aspectos pertinentes na criação de um portal de comércio eletrónico, mas que
muito influenciam o seu sucesso.
Na impossibilidade de podermos aqui referir detalhes do modelo sobre o qual trabalhamos,
utilizaremos como modelo de referência o portal do eBay (com alguns extras), que é bastante
conhecido e partilha algumas das características com o modelo utilizado. Trata-se de um
marketplace que concentra ofertas de vários vendedores num único sítio, mantendo, no
entanto, a individualidade de cada um e que é frequentado por um elevado número de
potenciais compradores. É, assim, um canal de comercialização para um mercado de enorme
potencial.
1.2 Objetivos
O trabalho realizado ao longo deste projeto passou por explorar uma ideia original de
comércio eletrónico e concretizar o resultado através de uma implementação, tida sempre
como principal objetivo deste projeto. Em termos mais detalhados e, tendo por base o modelo
de referência anteriormente apresentado, os objetivos são:
 implementar um modelo de comércio eletrónico que permita a aquisição de
bens/serviços em condições mais favoráveis;
 criar um canal de comercialização para os vendedores que, pela dimensão mundial
e volume de negócio em causa, seja tão ou mais atrativo que outras alternativas de
comercialização;
 Facultar os serviços, preferencialmente, na língua nativa dos utilizadores.
A implementação deste modelo de negócio é feita através de um portal cujos utilizadores são
vendedores e potenciais compradores. A pesquisa de produtos não requer qualquer vínculo,
22
isto é, pode ser feita por qualquer pessoa não registada. Os procedimentos de negociação e
comercialização requerem o registo, quer de quem vende, quer de quem manifesta interesse
em comprar (comprador).
1.3 Estrutura do Documento
Este documento encontra-se dividido em 5 capítulos:
 Capítulo 1: Introdução – Onde é feito o enquadramento e apresentados os objetivos
principais do projeto.
 Capítulo 2: Modelo de negócio e principais requisitos – Descrição do modelo de
negócio que se pretende criar e dos principais requisitos estabelecidos.
 Capítulo 3: Arquitetura e tecnologias – Apresentação arquitetónica da solução e das
tecnologias utilizadas na sua implementação.
 Capítulo 4: Implementação – Descrição dos detalhes técnicos de maior relevo.
 Capítulo 5: Conclusão – Análise autocrítica da execução do projeto, incluindo a
análise dos resultados e trabalho futuro.
23
Capítulo 2
2 Modelo de negócio e principais requisitos
2.1 Descrição
O modelo de comércio eletrónico utilizado pressupõe dois tipos de atores: os vendedores e
potenciais clientes, a que designaremos por “interessados”.
O vendedor, ator necessariamente registado e com um certo grau de validação (avaliações
efetuadas por compradores anteriores, confirmação dos dados por parte da entidade
proprietária do portal, entre outros), coloca os seus produtos no portal para comercialização,
identificando e caracterizando o produto e definindo as condições de venda. Estas podem
incluir: o preço mínimo de venda, o prazo para a fase negocial, a data de início, o número de
unidades disponíveis, formas de pagamento, opções de envio e respetivos custos, entre outros.
Os interessados acedem aos produtos pesquisando diretamente no portal. Em alternativa,
poderão efetuar um registo e subscrever serviços de notificação que os avisem de quando é
que determinados produtos são colocados para licitação. Sendo do interesse dos envolvidos, e
estando registados, podem licitar o produto. Ao aceitar as condições definidas pelo vendedor
podem propor um preço de aquisição para o produto, desde que seja superior ao maior valor
apurado até esse instante.
Findo o período de negociação e havendo uma proposta que satisfaça as condições definidas
pelo vendedor, o interessado é convertido em comprador, tendo a obrigação e o direito de
efetuar a aquisição do produto nas condições negociadas, como demonstra a Figura 1.
1
Figura 1 – Diagrama de atividades
Uma vez concluída a negociação, entra-se na fase de pagamento fazendo o Express Checkout
através de uma conta Paypal (ou outra solução alternativa). A entidade gestora do site recebe
o pagamento, cobra a sua parte e deposita o restante na conta do vendedor. Este trata de
remeter o produto para o cliente; paralelamente, é aberta uma fase da avaliação cujo objetivo
é classificar compradores e vendedores, no sentido de facultar mais garantias em futuras
transações. Assim, o comprador avalia o vendedor e vice-versa.
2.2 Estrutura de dados
De forma a ser possível o registo dos dados introduzidos que permitem o funcionamento da
aplicação é necessária uma base de dados cujas principais tabelas são: Utilizador, Produto,
Língua e Categoria. A tabela Utilizador guarda as informações (nome, morada, e-mail, etc.)
referentes a cada utilizador, permitindo também a ligação a outras tabelas como Categoria,
Sessão, Língua e Mensagem. Estas tabelas permitem saber, respetivamente, as categorias
sobre as quais o utilizador deseja receber notificações, a data da última vez que se autenticou,
qual a língua selecionada para lhe ser apresentada a informação e quais as
2
mensagens/notificações a ele dirigidas. Relacionada com esta tabela encontra-se também a
tabela Produto.
Uma vez que é possível um utilizador participar em mais que uma licitação, é necessária a
utilização de uma tabela auxiliar que permita este tipo de multiplicidade (vulgarmente
designada como “de muitos para muitos”). Contudo, este não é o único caso em que este tipo
de tabelas é utilizado, uma vez que é possível encontrar o tipo de multiplicidade acima falado
entre as entidades Produto e Língua. A ligação entre estas tabelas permite que haja uma
tradução de duas propriedades (título e descrição) do produto que está
em leilão.
Figura 2 – Representação do modelo relacional da base de dados
3
Para poder licitar, o utilizador deve, primeiramente, completar as informações no seu perfil.
No caso de os campos não estarem devidamente preenchidos é-lhe barrada a possibilidade de
adesão às licitações. Estas validações são verificadas através do acesso aos campos presentes
na base de dados que dizem respeito ao utilizador em questão, sendo-lhe apresentada a
informação de que este necessita de completar devidamente o perfil. De forma que as
informações introduzidas (quer seja no processo de completar o perfil, quer seja na introdução
de informações noutras páginas) sejam validadas, são utilizados os sistemas de validação do
Primefaces juntamente com JSF. O seguinte exemplo, simplificado, ilustra a validação de
uma palavra-passe (que deve conter 6 caracteres).
<p:password feedback="true" required="true">
<f:validateLength minimum="6"/>
</p:password>
Caso se verifique que alguma informação não se encontra de acordo com os requisitos
necessários para a validação do campo, o utilizador será notificado através de um growl
(widget disponibilizado pelo Primefaces). Para poder entrar em contacto de uma outra forma
com os utilizadores registados, foi implementado um sistema automático de mensagens, assim
como a possibilidade de comunicação via correio eletrónico (através de SMTP).
A segurança, sendo um ponto essencial neste projeto, é também preservada através de
mecanismos de controlo do tempo da sessão, controlo no acesso a páginas que necessitem de
autenticação e em termos de segurança de palavras-passe (protegidas através de sistema de
encriptação e codificação). Com este requisito pretende-se aumentar a fiabilidade no sistema e
fazer com que os utilizadores se sintam mais seguros.
Uma vez que se pretende que o portal sirva os utilizadores numa escala internacional,
considera-se como requisito fundamental a disponibilização de mais de uma língua ou, pelo
menos, que haja uma língua maioritariamente conhecida dos utilizadores, como o Inglês.
Posto isto, foi implementado um sistema que permite aos utilizadores a navegação em mais de
uma língua. Note-se que quando estes se autenticam, a língua definida no perfil será
automaticamente escolhida para continuar a navegação.
Mais detalhes sobre a arquitetura e a sua implementação podem ser encontradas no capítulo 4.
4
Capítulo 3
3 Arquitetura e Tecnologias
3.1 Java Server Faces (JSF)
Inserida na plataforma J2EE (Java Platform, Enterprise Edition), a tecnologia JSF, lançada
em 2004 pela Sun Microsystems, é uma tecnologia de servidor destinada ao desenvolvimento
Web e resulta da evolução e integração dos conceitos e funcionalidades provenientes das
tecnologias JSP – Java Server Pages e Servlets. Esta tecnologia baseada em componentes (UI
components) permite:
 representar os componentes e gerir os seus estados;
 manipular eventos;
 fazer validações;
 converter dados;
 definir a navegação das páginas;
 disponibilizar vários idiomas;
É uma framework orientada a eventos, para aplicações Web e baseada num modelo de
camadas (MVC – Model-View-Controller), que promove a separação entre front e back-end
das páginas Web.
Tal como foi referido anteriormente, esta tecnologia encontra-se no lado do servidor, havendo
por parte do cliente um request e, em resposta, uma response. A Figura 3 ilustra esse mesmo
processo: depois do request para o Web Container, onde se encontra o servlet, são feitas
5
interações com os EJBs (Enterprise Java Beans) e/ou com bases de dados através do acesso
aos Managed Beans. Através destas interações são gerados objetos (UI components, event
listeners, validators e converters, que fazem o encapsulamento dos dados) que são enviados
como forma de resposta (response) e são executados/mostrados no browser.
Figura 3 – Representação do modelo server-side e integração do MVC
Fonte: (Corporation, 2004b)
Esta tecnologia baseia-se no modelo MVC (Model-View-Controller) que separa o sistema em
três componentes: Modelo (Model), Vista (View) e Controlador (Controller). O Model é
responsável pela manipulação dos dados da aplicação, por manter o estado da aplicação e por
fornecer ao controlador o acesso aos dados. A View é responsável pela interface do utilizador,
encaminhando as ações deste para o controlador (Controller). Este último é o responsável
pela ligação entre o Model e a View, controlando o “comportamento” da aplicação. Em JSF o
controlo é feito através de um servlet1, denominado Faces Servlet, por ficheiros XML2 de
configuração e por vários manipuladores de acções e observadores de eventos.
O servlet é um controlador que é responsável pela receção e interpretação das solicitações do
utilizador, encaminhando-as para a camada Model, e pelo retorno adequado à solicitação.
1
2
6
Classe em Java que permite estender as funcionalidades de um servidor como, por exemplo, adicionar conteúdo dinâmico.
Como pode ser visto na Figura 3, estão presentes os ficheiros de configuração web.xml e faces-config.xml.
3.2 eXtensible Hypertext Markup Language (XHTML)
A tecnologia JSF é uma framework que tem pontos de extensão como os Managed Beans, os
converters, os validators e os UI components. A própria tecnologia View pode ser substituída
por uma implementação de ViewHandler alternativa (Hlavats, 2009). A ViewHandler é uma
componente infra-estrutural da framework JSF que realiza um importante trabalho durante as
fases de Render Response e de Restore View, sendo responsável pela criação, restauro e
rendering dos UI components.
Na tecnologia JSP3, os ciclos de vida destes componentes diferem dos encontrados na
tecnologia JSF. Devido a este facto, o uso de JSF em páginas JSP trazia muitos problemas aos
desenvolvedores.
Para poder colmatar tais problemas foi desenvolvida uma linguagem de declaração de páginas
denominada Facelets (Oracle, 2013). Esta linguagem tem como características:
i.
O uso de XHTML na criação de páginas;
ii.
O suporte para a reutilização de código através de templates;
iii.
Maior rapidez na compilação;
iv.
Alto desempenho no render dos componentes;
v.
Validação de Expression Languages (ELs) em tempo de compilação;
Em suma, para poder ser possível obter uma maior eficácia e menor esforço, as Facelets são
utilizadas sob a forma de XHTML juntamente com JSF no desenvolvimento deste projeto.
3.3 jQuery
Biblioteca de JavaScript multi-browser, jQuery permite fazer muitas ações interagindo com
HTML e XHTML, especialmente animações e validações.
3
Anterior à tecnologia JSF. Por defeito, trata-se da tecnologia View das versões JSF 1.x.
7
3.4 Asynchronous Javascript and XML (AJAX)
Filosofia que permite que páginas pareçam mais interativas para os utilizadores, AJAX
permite fazer solicitações assíncronas. Por exemplo, esta filosofia é utilizada para fazer o
update de certos elementos, não sendo preciso fazer o reload da página.
3.5 Arquitetura do Sistema
Para poder explicar a arquitetura que suporta o projeto desenvolvido, é necessário reincidir na
tecnologia JSF e introduzir o ciclo de vida de um request nesta framework. Para um melhor
entendimento dos conceitos que se pretende introduzir, observe-se as Figuras 4 e 5 que
representam, respetivamente, as várias fases do processamento de um request e a integração
destas num servidor. Note-se que um request é invocado quando o utilizador, durante a sua
utilização do portal executa uma ação (por exemplo, quando clica num botão).
Figura 4 – Ciclo de vida do um request na framework JSF
Fonte: (Sacramento, 2013)
A cada fase do processamento do request (representada pela cor verde) estão destinadas
funções específicas, sendo que nem sempre o tratamento dado ao processamento passa por
8
todas elas. Os phase-listeners são o melhor exemplo disso mesmo, como se poderá verificar
mais à frente.
Figura 5 – Processamento da UI Component tree na plataforma JSF
Fonte: (Corporation, 2004a)
Quando um request invocado pela máquina do utilizador chega ao servlet (denominado Faces
Servlet) que se encontra no lado do servidor4, é invocada, obedecendo às regras do ficheiro
faces-config.xml, a primeira fase do processamento do request (Restore View phase). Nesta
fase gera-se a página JSF (ou XHTML), solicitada no request, e é criada (ou restaurada) a UI
components tree. São estes components que dão uma forma visual à página.
No caso de haver algum component na árvore que requeira um input, esse mesmo component
irá copiar o valor que lhe foi atribuído no input para uma string temporária. Este valor será
validado, de acordo com as regras de validação definidas na página, na terceira fase deste
processo (uma vez ocorrido um erro de validação, o ciclo é remetido, à semelhança do que
acontece quando um event listener é declarado, para a Response phase). Nesta terceira fase,
os valores armazenados são convertidos para o seu tipo de variável original. Em consequência
destas duas fases ocorre uma outra na qual se dá a cópia dos valores agora convertidos para os
backing beans (e eventualmente para a base de dados).
4
Neste projeto foi utilizado o Glassfish como servidor para a aplicação. Este servidor desenvolvido para a plataforma Java
EE dá suporte aos componentes da mesma plataforma utilizados no desenvolvimento deste projeto.
9
Terminado este processo, o request passa para a Invoke Application phase. É nesta fase que os
eventos são processados, sendo propagados para os listeners interessados.
Depois deste processo, finalmente é gerada uma resposta gráfica já com todos os components
atualizados.
Depois das considerações iniciais para o entendimento da arquitetura do projeto, comecemos
por enquadrar a mesma com as tecnologias utilizadas e as funcionalidades implementadas.
A filosofia AJAX é, por diversas vezes, utilizada neste projeto. A apresentação de mensagens
de validação e a verificação da existência de um utilizador com o mesmo nome do utilizador
durante o registo (e em tempo real) e respetivo feedback são exemplos da utilização desta
filosofia. Também é através desta que é possível fazer separadamente o processamento dos
componentes visuais que fazem parte da página. Esses componentes são os chamados UI
components, previamente introduzidos e explicados. Quando é executada uma ação que
requer este princípio de funcionamento, o request invocado apenas faz o re-render do
componente visual específico que se quer modificar, retirando-o da árvore de UI Components,
iniciando um novo ciclo de vida (executando as fases necessárias) e fazendo o render no fim
do processo. Os pedidos de AJAX permitem assim que se poupe poder de processamento,
uma vez que a não utilização desta filosofia iria fazer com que toda a árvore fosse analisada e
todos os components nela inseridos processados.
Os phase-listeners, falados anteriormente, também podem ser explicados através dos
conceitos já introduzidos. Estes poderosos listeners são executados antes do início (e depois
do fim) de cada fase. A sua execução tem como retorno dois valores possíveis:
renderResponse (que invoca a renderResponse phase) ou responseComplete (que interrompe
o ciclo de vida do request). Este listeners, declarados no ficheiro faces-config.xml permitem,
como foi referido, que uma fase seja verificada antes da sua execução. Como se pode verificar
na secção 4.9, estes elementos podem evitar processamentos desnecessários quando não se
encontram condições suficientes para o processamento de um component ou até mesmo de
uma fase em concreto.
10
Figura 6 – Arquitetura do Sistema
Em suma, tomando em conta a figura anterior e as tecnologias descritas, o sistema baseia-se
num modelo server-side, em que há a invocação de requests do lado do utilizador através da
sua ação em componentes visuais utilizados nas páginas XHTML (que contêm na sua maioria
elementos da tecnologia JSF) e a resposta por parte do servidor aos pedidos feitos (na Figura
7 pode-se verificar algumas das ações que os utilizadores podem executar dentro do portal).
Ainda do lado do utilizador há a utilização de tecnologias Web como jQuery e CSS e da
filosofia AJAX. Do lado do servidor (Glassfish) encontra-se o servlet que recebe os requests e
processa os UI Components, que dão forma visual às páginas Web que o utilizador recebe
como resposta. Estes componentes visuais são processados assim como os listeners
declarados – isto de acordo com regras definidas nos ficheiros de configuração que
apresentam extensão .xml. Dentro deste processamento há a presença de fases que têm, cada
uma, objetivos específicos, sendo que nem todas são sempre executadas. Por exemplo, há
fases que requerem o input de dados. Caso tal circunstância se verifique, terão que ser feitas
validações a esses mesmos inputs e, por conseguinte, o acesso aos beans. Estes, caso
necessitem, poderão aceder à base de dados através do uso de uma camada de persistência.
No que toca à arquitetura do modelo de negócio, esta baseia-se, como já foi referido, no
modelo de negócio presente no eBay, onde os utilizadores interessados em adquirir um
produto devem apresentar uma proposta de compra. Contudo, esta não é a única ação
disponível no site.
11
Figura 7 – Diagrama de casos de uso
Como se pode verificar pela figura anterior, todos os utilizadores, registados ou não, podem
pesquisar produtos que estejam em licitação, mas para licitar ou vender algum produto têm
que estar autenticados e, como tal, devem previamente efectuar o registo. Depois de de
registado e autenticados podem, por exemplo, ter acesso às notificações recebidas, modificar
opções do perfil e, principalmente, vender (caso seja vendedor) ou licitar produtos (caso seja
comprador). Para melhor compreender este processo, observe-se o diagrama de colaboração
presente na Figura 8.
Figura 8 – Diagrama de colaboração
12
O procedimento começa com a colocação do produto à venda por parte do vendedor. De
seguida, caso assim desejem, os interessados apresentam propostas de licitação. Cada
proposta tem que necessariamente superior à anterior. Findo o período definido para a
negociação, o sistema verifica qual o utilizador que apresentou a melhor proposta (proposta
com o maior valor monetário), notificando-o de que deve proceder ao pagamento. O
utilizador que apresentou a melhor proposta torna-se assim o comprador do produto em leilão
que, para além de ter que estar registado e autenticado, deve possuir uma conta Paypal através
da qual deverá efetuar o pagamento.
Uma vez paga a quantia acordada à entidade gestora do site, esta retém a sua cota parte e
deposita o restante na conta do vendedor. Este, por sua vez, deve cumprir o seu dever de
remeter o produto para o utilizador que o adquiriu.
13
Capítulo 4
4 Implementação
4.1 Introdução
Partindo das vantagens e desvantagens de cada tecnologia, foram elaborados modelos para
satisfazer as funcionalidades do sistema. Tais funcionalidades são, assim, suportadas por
tecnologia que envolve Java Server Faces e muitas das componentes Java associadas a esta
tecnologia. Entre estas componentes encontram-se arquivos de extensão .xml, Managed
Beans, facades e Enterprise Java Beans (EJBs), que fazem ligação à camada de persistência.
Esta camada suporta o sistema e faz com que seja possível guardar dados inseridos,
maioritariamente pelos utilizadores do portal.
4.2 Message Bundles – Sistema Multilingue
A tecnologia JSF possui mecanismos que facilitam a criação de portais multilingues –
disponibilidade de escolha linguística. Esse recurso é possível através das Message Bundles.
Estes arquivos de extensão .properties apresentam uma relação <chave,valor> em que a
chave é o termo que se encontra à esquerda do “=” (igual) e o valor (palavra ou frase que será
mostrada na interface) é tudo o que se encontra à direita deste. Para mostrar a aplicação
prática desta mais-valia tomemos o exemplo real utilizado no desenvolvimento deste projeto.
Para evitar a invocação em todas as páginas deste recurso, definimos no ficheiro facesconfig.xml a invocação única das message bundles através de:
14
<application>
<resource-bundle>
<base-name>languages.welcome5</base-name>
<var>msg</var>
</resource-bundle>
</application>
No que toca às traduções, dentro de cada ficheiro welcome_xxx.properties – xxx corresponde
ao locale – há, como foi dito, uma espécie de mapeamento <chave,valor> representado, por
exemplo, por title = Page Title e por title = Título da Página. Nestes exemplos os
locales são definidos por en (língua inglesa) e por pt_PT (língua portuguesa),
respectivamente.
Para poder utilizar os diferentes idiomas é definido nas páginas o locale, através de <f:view
locale="#{main_bean.locale}">,
em
que
#{main_bean.locale}
corresponde
à
invocação do método getLocale presente no bean denominado main_bean.
Como se pode verificar no excerto de código acima transcrito, é definida uma variável msg.
Através dela pode-se invocar a chave presente nos ficheiros de traduções através de
#{msg.title}.
Sendo assim e tendo
<f:view locale="#{main_bean.locale}">
<title>#{msg.title}</title>
</f:view>
na página a apresentar, teremos os títulos das páginas conforme o locale definido.
4.3 Arquivos de configuração web.xml e faces-config.xml
Introduzidos no capítulo 3.1, os ficheiros web.xml e faces-config.xml são extremamente
importantes no que consta à navegação entre páginas assim como na definição de regras. A
título de exemplo, o ficheiro faces-config.xml permite um “mapeamento” entre uma página e
um bean6. Quando uma página referencia um objecto deste tipo (por exemplo quando um
botão é clicado e é invocado um método presente num determinado bean), a implementação
do JSF instancia o bean através do scope definido. Neste ficheiro também são dadas as
instruções no que refere à navegação entre páginas. O excerto de código apresentado de
5
Em que languages é o package e welcome os ficheiros que se apresentam como welcome_en.properties e
welcome_pt_PT.properties e que contêm as traduções
15
seguida exemplifica a navegação entre a página de Login.xhtml e a página index.xhtml. Neste
caso, <from-outcome>index</from-outcome> é o resultado de uma ação num botão que
invoca um método dentro de um Managed Bean.
<navigation-rule>
<from-view-id>
/Login.xhtml
</from-view-id>
<navigation-case>
<from-outcome>index</from-outcome>
<to-view-id>/index.xhtml</to-view-id>
<redirect/>
</navigation-case>
</navigation-rule>
4.4 Managed Bean
Os Managed Beans, ou simplesmente beans, são ficheiros que albergam os métodos que
permitem que os UI components apresentem propriedades dinâmicas numa página. Por
exemplo, quando um utilizador clica num botão são submetidos valores para o bean. Este
chama os métodos necessários para produzir o resultado desejado. Para obter o resultado
esperado, estes ficheiros recorrem, muitas vezes, a outro tipo de ficheiros que fazem uma
ponte com a camada de persistência: os facades (que recorrem aos EJBs).
Pode-se considerar, assim, que os beans são canais entre a interface gráfica e o Modelo da
aplicação. Cada bean tem associado um scope que define o seu “tempo de vida”. Conforme o
scope, os estados das variáveis são ou não guardados. O exemplo a seguir demonstra o scope
do bean que permite a inserção de um novo produto para venda.
@ManagedBean(name = "postbean")
@ViewScoped
public class postbean implements Serializable {…}
Como se pode verificar, este bean apresenta um scope do tipo view, o que significa que os
valores presentes nas variáveis que se encontram neste bean irão permanecer até que haja uma
navegação para outra página ou caso a navegação na página que requer a utilização deste bean
seja encerrada.
6
Ou Managed Bean.
16
Neste projeto também são utilizados scopes do tipo request e do tipo application. Este último
tipo de scope é utilizado, por exemplo, para verificar o fim do tempo das licitações. O tipo
ApplicationScoped é utilizado neste caso uma vez que desde o início da aplicação até ao fim
desta (mesmo que seja um processo interminável) é necessário ter um processo que se repita
(este ficheiro contém um TimerTask) e necessita de manter os tempos da última execução.
4.5 Facades
Os facades (ou façades) disponibilizam uma interface simplificada para aceder a uma
funcionalidade, diminuindo o número de pedidos de acesso. Neste projeto, estes ficheiros
desempenham o importante papel de aceder às EJB Entities que contêm os atributos de cada
tabela presente na base de dados. É nestes ficheiros que se acede à Unidade de Persistência
através da criação de queries em JPQL (Java Persistence Query Language) que fazem a
ligação à base de dados através de um Entity Manager. Note-se que para cada Entity há um
facade correspondente. Assim, cada facade acede apenas e só à Entity que lhe corresponde.
4.6 Enterprise Java Beans Entities
Cada entidade EJB representa uma tabela na base de dados. Cada atributo é representado
como uma coluna e cada instância é uma linha da tabela. É aqui que todas as tabelas se
relacionam para formar o diagrama E/R.
4.7 Unidade de Persistência
Uma unidade de persistência faz com que seja possível a ligação a uma base de dados. Sem
uma persistência não seria possível guardar os dados necessários para o funcionamento da
aplicação. No desenvolvimento deste projeto foi utilizada a JPA (Java Persistence API), que
gere as Entidades e realiza o mapeamento destas em objetos (object/relational mapping ORM). É também através desta API que os facades realizam as queries (em JPQL), havendo
um retorno do resultado conforme a query.
17
Quanto à implementação da base de dados foi utilizado o SGBD (Sistema de Gestão de Bases
de Dados) MySQL.
4.8 ServletContextListener
Um ServletContextListener (ou simplesmente listener) é uma interface que se encontra à
espera da ocorrência de um evento (Oracle, 2011). Quando esse evento se proporciona, as
ações envolvidas dentro da interface são invocadas. Neste projeto os listeners declarados
iniciam com a aplicação.
Com foi referido no capítulo 2.1, quando termina o prazo de adesão à licitação, o estado desta
é verificado. Isto acontece devido a um listener que é conjugado com um TimerTask, o que
permite que em intervalos fixos de tempo (desde que iniciou) um determinado método seja
executado.
Um outro listener é utilizado para eliminar registos não confirmados de utilizadores na base
de dados7. Cada listener é declarado no ficheiro web.xml com a sintaxe abaixo demonstrada.
<listener>
<listener-class>
nome_do_package.nome_do_ficheiro
</listener-class>
</listener>
4.9 Phase-listeners
Os phase-listeners são um pouco diferentes dos listeners anteriormente apresentados, uma
vez que permitem que os componentes que fazem parte da página sejam notificados no início
e no fim do processamento para cada fase do request (Oracle, 2007).
Uma vez que neste projeto é possível fazer login, algumas páginas necessitam de ter
informação sobre os utilizadores. O barramento ao acesso a estas páginas, quando o utilizador
não se encontra autenticado, é feito através de um phase-listener declarado no ficheiro facesconfig.xml. O tempo da sessão é controlado através da conjugação de um session-timeout
7
Para melhor contextualização consultar o capítulo 4.15.
18
(declarado no ficheiro web.xml) com um phase-listener. Após passar o tempo definido no
session-timeout (fixado em 30 minutos), o utilizador é redirecionado para a página de login.
No que consta ao phase-listener primeiramente enumerado, este verifica se o utilizador tenta
aceder a alguma das páginas listadas e para as quais é necessária a autenticação, dando um
feedback ao componente que executou o pedido. Se esta condição se verificar e caso o
utilizador não se encontre autenticado, este é redireccionado para a página de login. O
seguinte excerto de código do ficheiro faces-config.xml demonstra a declaração de um phaselistener que neste caso remete para invocação do ficheiro isLoggedInToAccessPage.java
dentro do package denominado security.
<lifecycle>
<phase-listener>
security.isLoggedInToAccessPage
</phase-listener>
</redirect>
</lifecycle>
4.10 Exception Handler Factory
Na eventualidade da ocorrência de erros não esperados, apesar da prevenção do
acontecimento destes e do respetivo tratamento, o utilizador será redirecionado para a página
Error.xhtml, onde será informado da ocorrência de um erro. A declaração do ficheiro que
processa as exceções encontra-se no ficheiro de configuração faces-config.xml, como se pode
verificar de seguida.
<factory>
<exception-handler-factory>
security.CustomExceptionHandlerFactory
</exception-handler-factory>
</lifecycle>
4.11 Cookies
Sendo a publicidade aos produtos parte integrante deste projeto, a presença de cookies faz
com que haja uma maior, mas respeitável, proximidade com os utilizadores. Assim, os
19
cookies criados permitem saber quais os potenciais pontos de interesse do utilizador,
guardando informações sobre os produtos que visita. Com isto pretende-se que os utilizadores
se sintam mais próximos das oportunidades de negócio existentes, sendo-lhes apresentadas
propostas para licitação de produtos relacionados com a categoria dos produtos já visitados.
Refira-se ainda que este mecanismo de utilização de cookies também é utilizado para guardar
as informações de autenticação no portal e é aceite quando os utilizadores visitam o site pela
primeira vez, sendo informados da utilização destes.
4.12 Express Checkout – Paypal NVP API
Para poder efetuar as transações monetárias, o utilizador deve fazer o Express Checkout
através de uma conta Paypal.
De modo a implementar esta funcionalidade recorreu-se à API NVP (Name-Value Pair),
disponibilizada pela própria empresa. Nesta API é necessário especificar o método que se
pretende invocar (neste caso os métodos invocados denominam-se “SetExpressCheckout”,
“DoExpressCheckoutPayment” e “TransactionSearch”) assim como outros parâmetros
específicos para cada transação.
Note-se que esta opção de pagamento está disponível apenas para contas virtuais através da
utilização da plataforma Sandbox disponibilizada pela própria empresa. A implementação do
pagamento “real” será efetuada numa fase posterior.
Os métodos acima mencionados permitem o acesso ao Paypal mas nem todos funcionam da
mesma forma, ou seja, nem todos têm os mesmos parâmetros e/ou o mesmo tipo de retorno.
Por exemplo, todos os métodos mencionados requerem os dados de autenticação da conta
Paypal. Uma vez que este projeto, numa primeira fase experimental, utiliza a plataforma
Sandbox, os dados de autenticação requeridos contêm como parâmetros o nome do utilizador,
a palavra-passe e a assinatura.
Como foi referido, nem todos os métodos comunicam com a plataforma Paypal da mesma
forma. Por exemplo, o método SetExpressCheckout necessita de parâmetros como o preço
total, o URL de retorno (URL para o qual o comprador deve ser redirecionado quando este
pretende efetuar o pagamento através da plataforma Paypal) e o URL de cancelamento (URL
para qual o comprador deve ser redirecionado caso este não deseje pagar com Paypal). Ao
20
aceitar a primeira opção, o utilizador confirma a compra e é redirecionado para a página
afterCheckout.xhtml.
Aqui,
de
forma
automática
é
invocado
o
método
DoExpressCheckoutPayment que finaliza o pagamento. Este método requer novos parâmetros
denominados “paymentAction”, “token” e “payerId”. Estes dois últimos parâmetros são
recebidos quando o utilizador aceita pagar através do método Paypal, sendo recebidos através
do URL.
Depois de invocados estes dois métodos, é necessário confirmar que a transação foi realmente
efetuada. Para isso é necessário recorrer ao método TransactionSearch. De forma a poder
restringir a pesquisa de transações é possível especificar vários parâmetros 8. Através da
resposta em forma de par chave-valor (ou, em conformidade com a API, em forma de NVP –
Name-Value
Pair)
é
possível
verificar
o
valor
referente
ao
campo
“PAYMENTINFO_0_ACK”, sabendo-se então se o pagamento foi efetivamente efetuado.
Este processo de troca de informações entre plataformas pode-se ser verificado através do
digrama de sequência presente na Figura 9.
Figura 9 – Diagrama de sequência NVP API - Paypal
8
O parâmetro utilizado para restringir a pesquisa foi a data de início. Este parâmetro permite a pesquisa de transações desde a
data indicada até à atual.
21
Quanto aos dados propriamente ditos, são processados e transferidos entre plataformas
(ePublicty ↔ Paypal) através da abertura de uma HttpURLConnection e da inserção dos bytes
correspondentes à string que contém todos os parâmetros necessários para a invocação dos
métodos. A resposta por parte da plataforma Paypal é dada através de tokens. Estes são
tratados (separados), dando origem a uma HashMap<String,String> – par chave-valor, tal
como foi anteriormente referido. Acedendo a este tipo de mapa pode-se saber os valores que
acompanham as respetivas chaves.
4.13 Google Translate API
Quando um utilizador cria uma licitação para um produto, os campos “título” e “descrição”
são preenchidos de acordo com a sua língua nativa. Dado que este projeto apresenta um
sistema multilingue e todos os utilizadores têm a possibilidade de pesquisar intenções de
compra na sua própria língua, é necessário traduzir e compatibilizar os campos acima
referidos. Este processó é efetuado com recurso à API do Google Translator.
Esta API, lançada em 2011 pela Google, permite a tradução de palavras de uma língua para
outra. Para isto é necessário verificar qual a língua utilizada pelo utilizador e quais as outras
línguas disponíveis (neste caso encontram-se disponíveis apenas a língua portuguesa e
inglesa). Por último é necessário criar uma instância do tradutor e invocar o método translate
que este disponibiliza.
Por exemplo, caso o utilizador esteja a utilizar a língua portuguesa, para ser possível traduzir
o título e a descrição do produto para outras línguas invoca-se o método referido. O seguinte
excerto de código mostra esse procedimento:
Translator translate = Translator.getInstance();
String traducaoPtEn = translate.translate(titulo, Language.PORTUGUESE,
Language.ENGLISH);
Os campos traduzidos são colocados na tabela que faz a ligação entre a licitação e as línguas
disponíveis.
Note-se que estas traduções são executadas automaticamente, não havendo supervisionamento
da fiabilidade da tradução. Posto isto, as traduções não serão totalmente corretas em alguns
casos. De forma a minorar os erros de tradução, como trabalho futuro espera-se implementar
22
um sistema que permita ao utilizador que insere estas informações a edição das próprias
traduções, caso assim o deseje.
4.14 Sistema automático de notificação
Para poder ser possível comunicar com o utilizador, foi implementado um sistema de
mensagens. Este sistema permite que o utilizador seja notificado quando:
 Novas propostas na sua área de interesse são criadas;
 As licitações terminam (recebendo simplesmente a informação de término ou um link
para proceder ao pagamento);
De forma a poder alertar o utilizador da receção de novas notificações enquanto este se
encontra autenticado, é disponibilizado um notificador (como o presente na rede social
Facebook) com o número de notificações não visualizadas. Este notificador vem simplificar a
visualização das notificações, facilitando a navegação ao utilizador.
Note-se ainda que este notificador é atualizado de 3 em 3 segundos através da utilização do
componente <p:poll /> disponibilizado pelo Primefaces.
4.15 Serviço de E-mail / SMTP
Quando um utilizador se regista, é-lhe enviado um e-mail para poder confirmar a sua conta. A
confirmação deve ocorrer dentro de 15 minutos. Caso esta condição não se verifique, um
listener irá remover o registo da base de dados.
O serviço de e-mail é também utilizado quando o utilizador pretende recuperar a palavrapasse. Neste caso, um novo e-mail é enviado juntamente com novas credenciais.
Para permitir o envio de e-mails é utilizado o protocolo SMTP que acede à conta de e-mail
alusiva a este projeto ([email protected]).
23
4.16 Encriptação, Codificação e Cifragem
De forma a poder assegurar a segurança dos dados dos utilizadores, quando estes se
registam/modificam a palavra-passe, esta é criptografada e codificada9.
Outros elementos presentes no url (i.e. id dos produtos) e nos cookies (palavra-passe e nome
do utilizador) também são cifrados e codificados para que haja uma maior segurança para o
sistema.
4.17 Managed Properties
As managed properties permitem a injeção de dependências de um managed bean noutro.
Estas propriedades são utilizadas com alguma frequência ao longo deste projeto. Por exemplo,
quando pretende ler uma mensagem, é passado para o URL um identificador da mensagem
selecionada. Através das managed properties é possível encontrar diretamente, dentro do
managed bean, o identificador referente a essa mensagem. Para melhor compreender este
processo tome-se como referência as explicações que seguem e que se encontram
acompanhadas de excertos de código.
Antes de mais, o utilizador seleciona, dentro da tabela onde se encontram as mensagens, qual
a que deseja ler. Este evento de seleção faz com que seja invocado o método
redirectToItemPage, presente no bean messagesInfo.
<p:ajax event="rowSelect" listener="#{messagesInfo.redirectToItemPage}"/>
Este método recebe um SelectEvent (propriedade do Primefaces), podendo-se saber qual a
mensagem selecionada. Essa informação é essencial para poder identificar a mensagem de
forma inequívoca. De seguida, através de
NavigationHandler nh =
FacesContext.getCurrentInstance().getApplication().getNavigationHandler();
nh.handleNavigation(facesContext, null, "/readMessage.xhtml?message=" +
identificadorDaMensagem + "faces-redirect=true");
9
Por razões de segurança, os esquemas de encriptação e de codificação não são revelados.
24
é passado para o URL a propriedade message seguida de um sinal de “=” (igual) e do
identificador. É também através deste excerto de código que o utilizador é redirecionado para
a página readMessage.xhtml.
É nesta página que é apresentado o título e corpo da mensagem selecionada através do acesso
a um bean. É nesse bean que se encontra declarada a managed property que permite
identificar a mensagem.
@ManagedProperty("#{param.message}")
private String message;
Esta declaração permite o acesso direto ao campo message do URL, sendo apenas necessário
aceder à variável message presente no bean para apresentar os campos que se pretende.
4.18 Omnifaces
Esta biblioteca tem como objetivo facilitar a vida ao programador, focando-se em utilidades
utilizadas no dia-a-dia no JSF (JDevelopment, 2005).
Neste projeto, esta poderosa biblioteca é utilizada para fazer a conversões em menus e para
incluir os parâmetros de request presentes no URL, uma vez que são utilizadas managed
properties.
Para
poder
incluir
estes
parâmetros,
(disponibilizada dentro do form - <o:form
/>)
a opção
includeRequestParams
tem de estar como verdadeira
(includeRequestParams="true"). Esta opção permite que os valores que se encontram no
URL não se percam.
Para tornar mais concreta a utilização desta propriedade tomemos um exemplo de um
utilizador que não esteja autenticado. Caso este tente aceder a uma página que requer
autenticação, aquele é redirecionado para a página de login, “guardando-se” a página que
tentou aceder no URL. Quando o utilizador submete as informações para se autenticar, o form
é submetido e as informações que se encontram no URL mantidas, sendo possível utilizá-las
para redirecionar o utilizador para a página que tentava aceder.
25
4.19 Primefaces
Primefaces é, à semelhança da Omnifaces, uma biblioteca dedicada ao JSF mas que apresenta
muitas mais vantagens. Suportada inteiramente a partir da versão 2.0 do JSF, esta biblioteca já
referida várias vezes neste documento, apresenta grandes vantagens:
 É uma biblioteca orientada ao component;
 Apresenta ela própria grande variedade de components.
 A integração total com jQuery (devido à sua base em AJAX);
Esta foi a biblioteca mais utilizada neste projeto, sendo que foram utilizados os mais diversos
components como os polls, growls, dialogs, tabelas (dataTables), campos de inputText, botões
para navegação/submissão de forms, utilização de listeners, etc. em páginas todas
desenvolvidas.
Uma vez que se trata de uma biblioteca orientada ao component, a utilização da Pimefaces
juntamente com JSF permitiu em muitas ocasiões a validação de inputs, poupando assim
trabalho e permitindo a rápida integração com outros components como por exemplo os
growls, que permitem a apresentação de notificações, por exemplo, quando as regras de
validação dos campos/components não são obedecidas.
26
Capítulo 5
5 Conclusão
5.1 Análise de resultados
A utilização e, sobretudo, a aprendizagem da tecnologia JSF, que apresenta uma curva de
aprendizagem extremamente penosa, fez com que a produtividade não fosse o que se
esperava. Mesmo numa fase mais avançada foram encontradas novas formas de resolver
problemas.
Numa análise ao portal e tudo o que o envolve, sendo esta a base deste projeto, pensamos que,
apesar das limitações, se encontra agradável em termos de visualização e navegação para os
utilizadores.
Também é com grande agrado que podemos dizer que foram alcançados e até superados
muitos dos objetivos propostos no início do desenvolvimento deste projeto. Em termos de
objetivos alcançados e superados encontra-se:
 O próprio portal, pela navegação simples que permite uma fácil adaptação e pela
sua compatibilidade em termos de browsers.
 O core (parte fulcral) do sistema estar implementado e a funcionar corretamente.
 A
quantidade
de
funcionalidades
implementadas
(sistema
de
mensagens/notificações, serviço de comunicação por e-mail, upload de imagens
dos produtos, sistema multilingue, processos automáticos de verificação como a
validação de inputs, utilização de listeners conjugados com timerTasks,
implementação de sessão do utilizador e controlo desta, utilização de ficheiros de
27
configuração como faces-config.xml e web.xml com regras de navegação,
implementação de sistemas de segurança, etc.).
 A utilização de bibliotecas como o Primefaces, Omnifaces e jQuery.
 A utilização de acessórios externos ao mundo Java – utilização das APIs
disponibilizadas pelas companhias Google e Paypal.
 A utilização de cookies para poder dar poder comercial aos atores envolvidos neste
processo.
 A aprendizagem de novas tecnologias e de novas formas de programar.
No que diz respeito à estrutura interna (em termos de processo que permite a navegação e
processamento de informação), o projeto encontra-se dividido em módulos (pastas) que
permitem maior simplicidade e facilidade de acesso.
5.2 Análise autocrítica
Como foi referido no ponto anterior, foi investido muito tempo na aprendizagem da
tecnologia JSF, que pela sua complexidade tornou o projeto mais demorado e (muito) mais
complexo. Devido ao desconhecimento do JSF, tomaram-se opções de implementação à
medida que íamos visualizando exemplos e experimentando soluções. Face a isto, algumas
das soluções implementadas podem tornar-se imprecisas ou, pelo menos, não uniformes,
como seria desejável.
Uma vez que este projeto se trata de um portal dirigido para pessoas de todo o mundo, uma
das mais-valias é, sem dúvida, a disponibilização dos conteúdos em várias línguas10 e de
forma automatizada. Este é mais um ponto favorável do projeto, possibilitando a abrangência
de mais pessoas, como é o objetivo.
Um ponto que podíamos ter melhorado é a apresentação das páginas, porém, o curso do qual
fazemos parte e o projeto em questão não se dirige para o design.
Estava prevista a implementação de outras funcionalidades mas, pelos factos já referidos, o
tempo não foi suficiente para as tornar “palpáveis”.
10
Neste momento disponível em língua portuguesa e inglesa.
28
5.3 Trabalhos futuros
O projeto entregue não é nem será nunca uma versão definitiva, não só pelo facto de no futuro
poder/ter de ser modificado mas também pelo facto de ser necessária a implementação de
outras funcionalidades. Estas funcionalidades passariam por:
 Implementar subcategorias – apesar de na base de dados ser possível uma categoria
conter mais que uma subcategoria, não é possível neste momento a escolha destas.
Com a implementação desta funcionalidade pretende-se especificar ainda mais a área
escolhida, quer na submissão da licitação, quer na escolha da área de preferência na
qual se pretende ter mais atividade.
 Feedback – mecanismo que, como foi dito, deverá ser implementado e no qual as
partes envolvidas avaliam as contra-partes, criando assim um rating, quer para os
compradores, quer para os vendedores. Mecanismo este, que permite aos
intervenientes, em futuras negociações, aferir o grau de confiança da contra-parte.
Minimiza-se assim o risco de fraude e maximiza-se a probabilidade do negócio ser
efectuado com sucesso e de agrada para todos
 Sistema de RSS – Este serviço é uma alternativa ao e-mail, para facultar informações
sobre produtos e licitações de forma mais rápida e eficaz.
 Sistema de traduções mais eficaz – o projeto tem uma capacidade de tradução da
descrição e título dos produtos de Português para Inglês e vice-versa através da
biblioteca gtranslateAPI, fornecida pela Google. Através deste sistema, é possível
guardar na base de dados o título e a descrição introduzida, porém, este processo
poderá sofrer alterações, fazendo-se as traduções online no momento da abertura da
página. Este sistema de tradução também deverá ser melhorado, devendo permitir ao
utilizador que insere a informação sobre os produtos, modificar as próprias traduções
geradas.
 Integração mais completa da API disponibilizada pelo Paypal – neste momento é
possível fazer pagamento através da Sandbox disponibilizada e também de “forma
real”, contudo, este processo terá de ser mais completo.
29
 Maior utilização de cookies – para um melhor conhecimento do utilizador e das suas
opções de navegação;
 Condições de transação, transporte e entrega mais favoráveis – num mundo de
competição quem oferece mais facilidades e mais comodidade é quem leva a melhor.
No futuro pretende-se fazer parcerias negociais, no sentido de rentabilizar recursos e
disponibilizar mais alternativas para todas as partes envolvidas.
30
Referências bibliográficas
Corporation,
I.
(2004a).
Concepts:
Web
Application
Frameworks.
from
http://www.acis.org.co/fileadmin/Curso_Memorias/Curso_CMMI_Sep06/Modulo%202%20%20Product%20Engineering%20/RUP%20Overview/application%20developer/process/workflow/impl
emen/co_webappframe.htm
Corporation, I. (2004b). IBM Education Assistance - JavaServer Faces Architecture. from
http://publib.boulder.ibm.com/infocenter/ieduasst/v1r1m0/index.jsp?topic=/com.ibm.iea.rad_v6/rad/6.0
/JSF/WASv6_JSF_Details/player.html
eMarketer. (2013). Ecommerce Sales Topped $1 Trillion for First Time in 2012. from
http://www.emarketer.com/Article/Ecommerce-Sales-Topped-1-Trillion-First-Time-2012/1009649
Hlavats, I. (2009). JSF 1.2 Components: Develop Advanced Ajax-enabled JSF Applications: Packt Publishing
Ltd.
JDevelopment. (2005). Omnifaces - JDevelopment. from http://jdevelopment.nl/open-source/omnifaces/
Oracle.
(2007).
Interface
PhaseListener.
http://docs.oracle.com/javaee/5/api/javax/faces/event/PhaseListener.html
from
Oracle.
(2011).
Interface
ServletContextListener.
http://docs.oracle.com/javaee/6/api/javax/servlet/ServletContextListener.html
from
Oracle.
(2013).
What
is
Facelets
The
http://docs.oracle.com/javaee/6/tutorial/doc/gijtu.html
Java
EE
6
Tutorial.
from
Organization, W. T. (2013). e-Commerce in Developing Countries. In W. T. Organization (Ed.), (pp. 2).
Sacramento, W. M. (2013). Manipulando Eventos em JavaServer Faces – Parte
http://www.devmedia.com.br/manipulando-eventos-em-javaserver-faces-parte-i/6426
I.
from
31