Atenção: esse artigo tem um vídeo complementar. Clique e assista!
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.
Para que serve:
Orientar na identificação do escopo mais adequado para os managed beans de uma aplicação. Por meio desta orientação, busca-se subsidiar a compreensão do papel dos escopos possíveis para os objetos da aplicação e como a escolha de cada um viabiliza a interação entre eles e o uso dos recursos alocados pelo servidor para a aplicação.
Em que situação o tema é útil:
Na modelagem de uma aplicação web, a solução precisa saber como os objetos se inter-relacionam. Neste contexto, conhecer o ciclo de vida para cada escopo é uma necessidade para uma correta modelagem. Assim, não se preocupar com a utilização adequada dos escopos em uma aplicação pode comprometer o desempenho, a segurança dela, entre outras coisas.
Resumo DevMan:
No desenvolvimento de aplicações web com JSF, o conhecimento e domínio dos tipos de escopo disponibilizados para os managed beans é uma premissa. Com esta necessidade, este artigo apresenta o conceito de escopos em aplicações JavaServer Faces, abordando de maneira teórica e prática quando o uso de cada um deles é ou não recomendado.
Autores: Cleiton Luiz Siqueira, Everton Coimbra de Araujo e Thiago Alexandre Lenz
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.
...
