Inicial > programação, programação JSF > Client-side X Server-side em JSF. Onde salvar o estado?

Client-side X Server-side em JSF. Onde salvar o estado?

Um das decisões mais debatidas em JSF ou Seam e que os desenvolvedores dão pouca importância é onde salvar a árvore de componentes da view. Há duas opções disponíveis: do lado do cliente (client-side) e do lado do servidor (server-side), cada uma com suas vantagens e desvantagens.

Para entender melhor, vamos ver o ciclo de vida do JSF, entender em que contexto se encontra a criação da árvore de componentes, e porque ela existe:



O Ciclo JSF e a Árvore de Componentes

Ciclo do JSF Completo

Ciclo do JSF

A árvode de componentes do JSF é uma estrutura baseada em XML que identifica os componentes que estão na view. Quando se usa o JSF cada elemento da tela será associado a um espaço na árvore. O estado da árvore é armazenado para quando houver uma requisição do tipo postback*, alterações nos campos do formulário sejam aplicados às propriedades associados a esses campos e quaisquer eventos sejam enfileirados e invocados na sequência.

Na figura acima, observamos que da fase Restore View sai uma seta direto para a fase Render Response, ilustrada pela expressão “No Query Data”. Essa situação acontece quando temos uma requisição inicial em JSF (initial request), ou em uma forma mais simples de entender, quando chamamos uma tela pela primeira vez. É nesse ciclo de  apenas 2 fases que a árvore de componentes da view é criada. Uma vez que o response é processado, a árvore é serializada e enviada junto com o response para o cliente ou armazenada na sessão HTTP do usuário sob uma chave única.

A configuração

Para configurarmos o local onde salvamos a árvore de componentes, utilizamos um contexto de parâmetro chamado javax.faces.STATE_SAVING_METHOD no web.xml, conforme o código abaixo mostra:


<context-param>
<param-name>javax.faces.STATE_SAVING_METHOD</param-name>
<param-value>client</param-value>
</context-param>

Caso não se especifique nada, o local padrão será no servidor.

As abordagens

Server-side

Salvando o estado no servidor, a árvore de componentes é armazenada na sessão HTTP do usuário. Um token é enviado junto com o response e armazenado em um campo hidden. Posteriormente esse token é usado para recuperar a árvore da sessão em um postback*.

Client-side

A árvore é serializa, compactada, codificada e enviada junto com o response para o browser do cliente. O processo é invertido no postback* para que a árvore possa ser recuperada.


Vantagens X Desvantagens

Client-Side Server-Side
Desvantagens – Aumenta o tráfego na rede
– Clientes com conexões mais lentas podem perceber um grande lag
– Requisições Ajax tornam o tráfego na rede maior ainda por precisarem reconstruir a árvore
– Aumenta o tamanho da sessão HTTP
– Consome mais recursos do servidor
– Depende da sessão do usuário (pode ter impacto na experiência do usuário)
Vantagens- – Economiza memória do servidor;
– Não é afetada pela sessão do usuário;
– Risco maior para a segurança;
– Aumenta o processamento no servidor e no cliente;
– Reduz largamente o tráfego na rede;
– Diminui o tempo de resposta das requisições do usuário;
– Diminui o consumo de memória no cliente
– Baixo consumo de processamento no servidor;


E então, qual opção utilizar?

No livro Seam in Action, o autor Dan Allen sugere que se utilize a abordagem salvando no servidor. Ele alega que é muito ruim deixar o usuário esperando alguma resposta do sistema, pois, assim como temos pessoas com boa conexão ligadas à rede, existem aquelas que não possuem uma boa banda. Na minha opinião, faltou ele ressaltar que outros fatores devem ser pesados, como:

  1. O sistema é interno e a qualidade da rede é satisfatória?
  2. Quantas usuários simultâneos meu sistema terá?
  3. O servidor tem uma boa configuração?
  4. O sistema possui telas muito complexas, com formulários muito complexos?

Isso posto, acredito que algumas situações podem também favorecer a abordagem client-side. Para você que está começando, os itens acima podem lhe dar um bom “norte”.

Referências


* Postback: tipo de requisição em JSF que em uma situação normal utiliza todo o ciclo do framework (isso não ocorre quando, por exemplo, há um erro de validação, conversão, o immediate é utilizado, entre outros casos).

Anúncios
  1. 29/08/2009 às 16:47

    Conteúdo muito interessante.

    Prefiro manter o conteúdo (árvore) do lado servidor, exatamente pelo motivo que o autor citou. Mas levando em consideração o que o “Deputado” Pablo comentou, passei a acreditar que é uma situação a ser avaliada no inicio do projeto.

    =)

  2. 01/09/2009 às 13:11

    Sou da seguinte opinião: nada do que eu lhe disser tu deverás levar ao extremo, pois “cada caso é um caso” (eita jargão cafona). Eu posso lhe dizer para colocar tudo do lado do servidor, pois tenho uma infra excelente e não sinto gargalo nenhum. Mas tu podes ter uma infra mediana, até mesmo medíocre, e querer deixar para o cliente essa tarefa (se bem que não é assim também “cliente, se ferra aí! toma a bucha meu filho!” pois é sabido que do lado do servidor também há um trabalho nesse sentido, até acho que para economia o melhor é deixar do lado no servidor oO).

    Por via das dúvidas teste os dois casos. Acesse sua aplicação na rede, de fora dela, pela internet, por uma VPN ou o que for e tire a dúvida por sí. Conselho se fosse bom não se dariam tantos e de graça hehe.

    Infelizmente muita gente não liga para o “peso” das aplicações. A Vivo por exemplo tem um site pesadíssimo, onde para entrar no site, escolher a localidade e achar o telefone do SAC deles tu baixarás quase 900kb de informação! Isso em um telefone celular é MUITO (em tempo e em $ principalmente)! Na banda larga não é nada (em 5s tu carrega). Então um site cheio de flash e imagens + uma má definição ou mal emprego de uma tecnologia pode sim causar muita dor de cabeça. Então TESTE, sempre, tudo! 😉

    O post esclareceu para quem desconhecia esse funcionamento, mas não deve ser, assim como o livro, seu guru espiritual e a chave da resposta enigmática de onde persistir a árvore de componentes. 😉

    Ótimo post.

  3. 24/01/2011 às 10:11

    Como lidar com o problema da session expired com a aplicação no lado servidor?

  1. 03/01/2011 às 23:29

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

Conectando a %s

%d blogueiros gostam disto: