Este é um post disponível para assinantes MVP
dê seu feedback
post favorito
Escopos de Managed Beans no JSF 2.0 - Artigo Java Magazine 90
Este artigo apresenta os escopos especificados e implementados na versão 2.0 do JSF (JavaServer Faces). As características de cada escopo e o relacionamento de managed beans registrados com cada um deles fazem parte do texto desenvolvido. As possíveis relações entre os escopos, ou seja, entre os objetos registrados com eles são também informadas.
[Artigo já está disponível no Leitor Digital DevMedia®. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da Java Magazine 90
O JSF vem sendo amplamente utilizado em aplicações Web devido a sua grande extensibilidade e popularidade entre a comunidade de desenvolvedores. Em sua implementação de referência, o JavaServer Faces traz uma série de componentes prontos para uso, porém, através da extensibilidade oferecida, novos componentes também podem ser criados – além de haver a possibilidade do uso de uma implementação de terceiros, como o MyFaces
O ponto forte do JSF está em abstrair a complexidade da comunicação cliente-servidor (HTTP request e response). Esta abstração foca no desenvolvimento direcionado a componentes, com propriedades que podem ser configuradas e eventos que podem ser capturados, tornando a etapa de implementação mais intuitiva e produtiva.
O desenvolvimento com JSF é baseado em componentes, que possuem uma ligação direta com a aplicação, porém, cada um deles pode ter um papel diferenciado na mesma. Este papel pode estar associado à visibilidade que cada componente (managed bean) precisa ter em relação à aplicação. Esta visibilidade, que determina quais componentes podem manter uma associação entre si dentro de um determinado contexto, é conhecida como escopo de acesso. Desta forma, faz-se necessária a compreensão dos diferentes tipos de escopo que podem ser atribuídos aos managed beans que compõem a aplicação.
A comunicação entre cliente (browser) e servidor ocorre através de requisições (request) e respostas (response). A cada requisição do cliente um novo objeto REQUEST é enviado ao servidor, onde o mesmo será processado. Após o processamento o servidor encapsula a resposta em um objeto RESPONSE, retornando-a para o cliente. No momento em que a resposta é enviada ao cliente, termina-se o ciclo da requisição iniciada por ele. Todo este processo pode ocorrer mais de uma vez.
Sabendo-se que uma funcionalidade, como uma venda, pode gerar várias requisições, é importante um mecanismo que permita que dados obtidos ou gerados através destas requisições possam ser visíveis entre elas. Infelizmente o protocolo HTTP tem como característica a não persistência de estado, o que indica que os servidores não mantêm informações a respeito dos clientes que estão se conectando a ele entre uma requisição e outra. Desta forma, pode-se afirmar que toda requisição realizada por um cliente é tratada pelo servidor como uma nova. Sendo assim, como são mantidas as informações entre as requisições quando submetidas para diferentes pontos da aplicação? A resposta está no gerenciamento de sessão.
As sessões são inicializadas no primeiro HTTP REQUEST enviado pelo cliente ao servidor, que é responsável também pela gerência das mesmas. Esta sessão recebe um identificador único, utilizado pelo servidor para sua localização entre as diversas requisições realizadas. Isto acontece porque cada sessão pode armazenar informações que serão recuperadas por outras requisições futuras.
As informações pertencentes à sessão, como por exemplo a autenticação do usuário na aplicação, ficam disponíveis para o cliente durante o tempo de vida dela. Isso pode ser problemático quando se pensa em segurança. Em uma situação, por exemplo, de acesso ao seu Home Banking, por algum motivo você sai de perto de seu computador após o acesso ou uma transação. Neste momento, alguém mal intencionado pode fazer uso da sua conexão com a aplicação e realizar transações indevidas. Para minimizar estes problemas, cada sessão possui um tempo máximo para inatividade, onde o padrão é de trinta minutos, podendo ser configurado um valor diferente. Desta forma, se seu Home Banking estipula um tempo de cinco minutos de inatividade, isso pode minimizar o problema relatado.
Deve ser entendido como tempo de inatividade o intervalo entre uma requisição e outra. Desta forma, se o cliente submete uma requisição e a seguinte leva um tempo maior que o valor determinado como limite para ser realizada, quando esta chegar ao servidor, o mesmo já terá encerrado a sessão atribuída ao cliente.
Esse tempo de inatividade, dentre outros parâmetros, é configurado em um arquivo presente em todas as aplicações web, /WEB-INF/web.xml, conforme a Listagem 1. Uma vez que a sessão tenha sido encerrada por inatividade, todos os dados armazenados na mesma são perdidos e a próxima requisição do cliente implicará na criação de uma nova sessão.
É importante salientar que uma sessão, conforme dito anteriormente, é a comunicação realizada entre o cliente e o servidor, porém com a possibilidade de persistência de dados entre as requisições. Ressalta-se que, independentemente da quantidade de instâncias do mesmo cliente que forem abertas, estas instâncias compartilharão a mesma sessão no servidor.
Como pode ser visto na Figura 1, a especificação JSP traz os seguintes escopos: Application, Session, Request e Page. Com exceção de Page, os demais escopos também são reconhecidos em JSF.
Os escopos reconhecidos pelo JSF não sofreram alterações desde sua versão inicial até a versão 1.2. Com este “congelamento”, analistas e desenvolvedores acabavam utilizando em seus projetos outros frameworks que desenvolveram novos escopos para as necessidades que surgiam, tais como Apache MyFaces Orchestra ou JBoss Seam, os quais oferecem diferentes recursos para resolver problemas de escopo, antes não resolvidos pelo JSF.
É evidente que com o uso desses frameworks em uma aplicação não se obtém somente o benefício de novos escopos, mas sim outras funcionalidades interessantes. No entanto, o que se deseja enfatizar é que os escopos oferecidos pelo JSF até a versão 1.2 não atendiam mais às necessidades que surgiam com a evolução dos navegadores, como o recurso, já não tão recente, de abas. Como tratar requisições para a mesma aplicação no mesmo cliente, porém em guias diferentes?
Com base na especificação JSR 314, que define o JSF 2.0, foram implementadas novas funcionalidades, e uma delas trata exatamente dos novos escopos, assunto principal deste artigo. Nesta versão foram incluídas as seguintes opções de escopo: ViewScoped, NoneScoped e CustomScoped. Estes escopos têm por objetivo economizar recursos do servidor como, por exemplo: memória, espaço em disco e tempo de resposta. O uso destes novos escopos subsidia uma melhor relação da aplicação com o tratamento das informações durante a navegação entre páginas ou na própria página, o que pode ser obtido através de diversas requisições HTTP para carregamento de dados dinâmicos, através de requisições AJAX.
Os Escopos JSF
Antes da versão 2.0, o mapeamento de um managed bean era realizado no arquivo /WEB-INF/faces-config.xml, conforme a Listagem 2. Nesta nova versão, isto passa a ser opcional, uma vez que o novo padrão é o uso de anotações para esta atividade. Todo managed bean possui um escopo, e a definição dele pode ser realizada pelas anotações: @ApplicationScoped, @SessionScoped, @RequestScoped, @ViewScoped, @CustomScoped ou @NoneScoped.
Na Figura 2 é mostrada uma visão geral dos escopos do JSF, com exceção de @CustomScoped e @NoneScoped, pois o comportamento de @CustomScoped, como era de se esperar, é implementado de forma customizada, de acordo com as necessidades do desenvolvedor (ou do problema). Já o @NoneScoped não permite acesso diretamente pelas páginas, apenas por outros managed beans.
"ATENÇÃO! A exibição deste artigo foi interrompida.
Este é um post disponível para assinantes MVP
4
0
