Artigo Java Magazine 54 - Controlando fluxos de navegação

Editorial publicado pela Java Magazine 54.

Gostei (0)

(0)

[fechar]

Você não gostou da qualidade deste conteúdo?

(opcional) Você gostaria de comentar o que não lhe agradou?

Esse artigo faz parte da revista Java Magazine edição 54. Clique aqui para ler todos os artigos desta edição

Controlando Fluxos de Navegação em aplicações web com Spring Web Flow, Spring e JavaServer Faces

Resolva problemas de navegação de seus sistemas web

Aprenda como criar aplicações web mais robustas com uma poderosa combinação de frameworks.

À medida que as aplicações web crescem em complexidade, cresce também o número de casos de uso cuja inserção de dados é feita através de formulários que se expandem em várias páginas. Um exemplo comum desse tipo de caso de uso é a realização de compras em uma loja virtual, pois para comprarmos precisamos fazer uma busca por produtos, escolher o produto desejado e adicioná-lo ao "carrinho de compras". Se estivermos satisfeitos com os itens do carrinho, finalizamos a compra, senão voltamos ao início para buscar novos produtos. Para finalizar a compra é necessário verificar se o usuário possui cadastro, se está logado, qual a forma de pagamento escolhida, etc. Enfim, há um grande número de possibilidades de interação do usuário com a aplicação para que o caso de uso seja finalizado.

O problema desse tipo de caso de uso é a dificuldade de gerenciamento de fluxos de navegação complexos em aplicações web. Isso deve-se principalmente ao fato de que essas aplicações funcionam com base no protocolo HTTP (Hypertext Transfer Protocol), sendo limitadas aos recursos oferecidos por ele.

Este artigo tem como objetivo mostrar os problemas relacionados à construção desses fluxos de navegação e explicar como os frameworks Spring, JavaServer Faces e Spring Web Flow podem solucioná-los. Para demonstrar a utilização dos frameworks citados iremos construir uma pequena aplicação web para jogar Black Jack, um jogo de cartas também conhecido como “21”.

Os desafios do HTTP

O protocolo HTTP é baseado em um mecanismo de requisição e resposta: o cliente envia uma requisição solicitando algum recurso e então o servidor envia ao cliente uma resposta com o recurso solicitado (ou uma informação de erro). Essa comunicação é feita sem manutenção de estado, ou seja, as informações enviadas através de uma requisição não são mantidas em requisições futuras.

Para contornar as características inerentes ao fluxo “stateless” da comunicação entre clientes e servidores sob o protocolo HTTP, os containers web criaram meios para manter objetos em memória sob diferentes escopos. A definição destes escopos está diretamente ligada ao tempo de vida do objeto no container e sua disponibilidade para uso da aplicação. Os escopos disponíveis são:

· Page: contém dados que são visíveis apenas dentro de uma página. Se uma página contém dados no escopo page, as páginas inseridas nela com [1] ou redirecionadas a partir dela com não são capazes de enxergá-los;

· Request: a informação nesse escopo é criada após a requisição e existe até que a resposta ao cliente seja completada;

· Session (Sessão): os dados no escopo session são criados algum tempo após a primeira requisição do usuário e são descartados depois de algum período de inatividade, por exemplo, quando o usuário fecha o navegador ou quando a sessão é invalidada pela aplicação. Um dado em session sobrevive a vários requests;

· Application: contém dados disponíveis a todos os clientes da aplicação e que estão disponíveis até que o servidor web seja reiniciado.

Para muitos problemas esses escopos são suficientes, mas os fluxos de navegação mais complexos não se encaixam naturalmente neste cenário. Como eles se expandem em várias páginas, é necessário gerenciar o ciclo de vida dos objetos manipulados pelo caso de uso, criando-os quando forem necessários e removendo-os quando o caso de uso acabar ou não necessitar mais dos mesmos. Dessa forma, os escopos page e request não se fazem suficientes, e a longevidade dos escopos session e application não é necessária, já que os dados armazenados nesses escopos continuam existindo após a finalização do caso de uso. Os usuários também podem utilizar diferentes casos de uso por vez, ou mesmo executar o mesmo caso de uso várias vezes. Em tal cenário, os dados associados com a execução de um caso de uso precisam ser limpos antes que uma nova execução seja iniciada. Resumindo, não existe um escopo que suporte casos de uso que utilizam múltiplas páginas.

Uma solução comumente adotada para resolver este problema é armazenar os dados em sessão e limpá-los manualmente após o fim do caso de uso. Apesar de a princípio parecer uma solução simples e eficiente, existem muitos problemas associados ao armazenamento em sessão:

· Como gerenciar o balanceamento de carga em ambientes em cluster?

· Qual o impacto no uso de memória do servidor com todos esses objetos em sessão?

· "

A exibição deste artigo foi interrompida.

Este é um post disponível para assinantes MVP

Este post também está disponível para assinantes da Java Magazine DIGITAL
ou para quem possui Créditos DevMedia. Clique aqui para saber mais!

David Pereira
é engenheiro de computação e mestre em engenharia elétrica pela UFRN. Trabalha como arquiteto de software na Superintendência de Informática da UFRN, é professor da Faculdade Natalense para o Desenvolvimento do RN (FARN) e é consultor independente em arquitetura de software e no Spring Framework.

O que você achou deste post?

Gostei (0)

(0)