[MÚSICA] [MÚSICA] Olá a todos, meu nome é Eduardo Guerra, esse é o curso de Desenvolvimento Ágil com Java Avançado. Hoje vamos falar sobre os escopos de uma aplicação Web. Sim, estamos de volta aí, com módulo sobre aplicações Web. A gente vai ver pouquinho mais sobre aplicações Web. Essa é uma questão muito importante, a gente tem uma aplicação Web, diferente de uma aplicação desktop, a gente tem muitas pessoas mexendo ao mesmo tempo, cada requisição ali é separada, certo? Então, a gente tem que saber onde guardar as informações, então, vamos entender mais ou menos o que é que seria essa escopo, quais os tipos de escopo que a gente tem e, quanto o que a gente utiliza cada? Então, o que é esse escopo? O escopo é como se fosse ali quadro de aviso, onde você pode ir lá e colocar uma informação e outras partes do software podem ir lá e retirar uma informação. E aí, dependendo, é como se cada escopo fosse quadro local diferente. Então, a gente vai ver que a gente vai ter quadros que são mais restritos e quadros que são mais públicos, digamos assim. Então, vamos dar uma olhadinha como é que isso funciona. Então, a gente tem esses vários escopos aqui, o mais restrito deles seria aqui uma requisição, que a gente utiliza o próprio objeto request para colocar e retirar essas informações. Ele seria escopo de digamos assim, privado, como se fosse lá aquele quadro de avisos dentro do seu, dentro do seu espaço pessoal, onde só você pode acessar. Esse escopo, quando você digamos assim, termina uma requisição, tudo o que estava nele é perdido. O segundo escopo é a sessão do usuário. A sessão do usuário são as várias requisições de mesmo usuário. Então, às vezes, " a sessão expira 20 minutos", às vezes a gente que utiliza a aplicação Web, às vezes está acostumado com isso. De " expirou aqui", " depois de tempo que tenho que logar de novo". Então, é esse período que a aplicação Web lembra as suas informações, esse período aí é o período que a sua sessão está ativa. Então, dentro da sessão você guarda informações que vão ser guardadas entre as várias requisições do mesmo usuário. E para recuperar uma sessão a gente usa request ponto getsession. O último escopo, aí isso aí seria, a sessão seria como se fosse ali quadro dentro de uma sala. Onde todo o mundo, que seria cada request ali, tenha acesso aquela, aquele quadro de aviso, para colocar e retirar, certo? Por fim, seria aí a aplicação. A aplicação é como se fosse sei lá, o hall de prédio. Aquele quadro de aviso, que todo o mundo ali tenha acesso para colocar e retirar. E a gente acessa o escopo da aplicação com getServletContext, então, toda a informação que você colocar no Service Context, na aplicação, você vai conseguir acessar de qualquer, a partir de qualquer requisição dentro daquela aplicação Web. Então, se você quer guardar uma informação, que seja persistente ou que esteja acessível a todos os usuários, o ServletContext, o contexto de aplicação, seria aí o mais adequado. E aí, cada desses objetos que a gente está vendo aqui, eles teriam esses dois métodos aqui: ele tem o setAttribute, para você digamos assim, pregar a informação ali no quadro e tem o getAttribute que seria para você ir lá e pegar aquela informação, lembrando que quando você pega a informação, ela continua lá no mural para outras pessoas acessarem também. Você simplesmente está pegando como se copiasse aquilo num outro papel. Uma coisa importante, é que diferente lá, quando gente viu lá o getParameter, que ele é uma string, o getsetAttribute ele pode receber e retornar object. Ou seja, você pode guardar qualquer desses escopos, qualquer objeto, seja uma lista, pode ser array, pode ser a classe usuário, às vezes, classes da sua própria aplicação. E isso é bem interessante, porque a gente pode guardar informações bem mais estruturadas, do que somente primitivos ou strings, certo? E dentro de uma aplicação Web, é que a gente passa informações. A gente viu lá que não é uma boa prática a gente utilizar atributos dentro de Servlets por exemplo, usar ali variáveis de instância dentro de Servlets pela questão da concorrência, e a gente viu que de alguma forma a gente precisa passar essa informação e é através desses escopos que a gente vai estar passando informações dentro da nossa aplicação. E aí, vem uma questão que a gente falou lá na primeira aula sobre aplicação Web que, o protocolo HTTP, ele não mantêm uma conexão ativa. E aí, você fala assim "Como então você consegue manter uma sessão, se você a cada requisição é simplesmente request e response?" Então, o que acontece é que essa parte de sessão não era uma funcionalidade nativa do protocolo HTTP e a gente precisa recorrer a alternativas para fazer isso. Então, as alternativas: os famosos cookies, que é pequeno arquivozinho que guarda lá no navegador e ele tem ali uma informação que vai e volta a cada requisição. No caso de uma aplicação Java, existe ali uma informação do cookie chamada JSESSIONID que ele guarda, identificador da sua sessão. A reescrita de URL quando você não, por exemplo o usuário desabilita os cookies, ele passa a não mandar essa informação, uma alternativa é a reescrita de URL. A reescrita de URL é como se ele adicionasse esse JSESSIONID na URL que você está acessando. Ele faz isso se você chamar esse response.encodeURL passando a URL, ele converte aquela URL nesse formato que ele transmite o JSESSIONID. Uma coisa interessante é que ele só vai fazer essa conversão mesmo caso a aplicação perceba que o usuário não está retornando os cookies. Então, é basicamente, se você mandar fazer a reescrita de URL, a primeira vez ele vai fazer, na segunda vez quando voltar a requisição e voltar cookie, o container Web já não faz mais aquela reescrita. Então, ele faz só se realmente for necessário, costuma ser uma alternativa se o usuário desabilitar os cookies. Uma coisa chata é que cada URL da sua aplicação você vai ter que chamar o encodeURL. Por fim, a forma mais segura de guardar a sessão e incrivelmente muito pouco usada é o ID da sessão SSL. Eu falei que o HTTP não guarda informação de requisição, que ele não mantém uma conexão, o que é diferente do protocolo HTTPS, que ele tem esse identificador da sessão que é a sessão criptográfica SSL que ele mantém. Então, você pode usar, se você fizer o SSL até ao Container Web, você pode usar o ID dessa sessão SSL. Está fora do nosso escopo mostrar como fazer isso mas eu acho importante vocês saberem que é possível, pode até ser que alguns Web Containers não deem suporte a isso mas pela especificação de servlet, existe aí sim essa possibilidade e seria a alternativa mais segura para a manutenção de sessão. Então, é isso. A gente falou sobre os diferentes escopos de uma aplicação Web, não poderia deixar de falar sobre a manutenção de sessão. Então, a gente viu os diferentes escopos, quando utilizar como colocar e retirar informação desses escopos. Muito obrigado, até à próxima aula. [MÚSICA] [MÚSICA]
