Rafael Ponte

Uma das dúvidas mais frequentes na lista de discussão do javasf está relacionado em como o JSF mantém o estado da árvore de componentes de uma view, qual a diferença e qual deve-se usar: client ou server? Acredito que a melhor maneira de responder a estas perguntas está em saber a diferença entre os dois métodos, e é exatamente isso que pretendo explanar mais abaixo..

A framework nos fornece dois métodos para mantermos o estado da árvore de componentes, os métodos são “client” e “server”, ou seja, é possível manter o estado dos componentes no cliente (página gerada) ou servidor (session).

Mas o que diacho é esse “estado da árvore de componentes”? Bem, no JSF os dados são armazenados em dois caminhos diferentes: dentro do escopo de beans e dentro da árvore de componentes. O escopo de beans(managed-beans) por si só é auto-explicativo. Já o escopo da árvore de componentes é onde estão armazenados os dados(estados) destes componentes, eles são armazenados no response e então são recuperados quando um request chega, com isso o JSF consegue manter o estado de cada componente inalterado até que se mude para uma nova página.

No método “client” o estado da árvore será persistido no cliente, para ser mais exacto ele será serializado e encodado na base64 e ficará em um campo do tipo HTML-input-hidden na página gerada para o cliente(browser). Já no método “server” o estado será persistido na sessão do usuário, ou seja, no servidor e não mais no cliente. Cada um possui suas vantagens e desvantagens, veremos isso mais a frente..

Você poderá facilmente definir qual método pretende usar inserindo no web.xml da sua aplicação o seguinte trecho de código:

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

No código acima o param-value poderá ser definido como server ou client, por default o método é o server. Bem, depois de definido qual método usar e re-startar a aplicação começaremos a sentir as diferenças.

Diferenças

Método server

• há um maior consumo de memória no lado servidor pois o estado esta sendo mantido na sessão por usuário;
• problemas com o back-button do browser (é necessário mais consumo de memória para resolver este problema);
• baixo consumo de banda na rede;
• baixo consumo de memória no cliente;
• uso de cpu no servidor é baixo;
• clustering - mover a sessão para um outro nó do cluster (muitos dados na sessão);
• melhora comunição via AJAX pois não é preciso reenviar o estado da view ao servidor;
• páginas carregam mais rapidamente (ou pode-se dizer normalmente?);

Método client

• menos uso da session e consequentemente menos consumo de memória no lado servidor;
• sem consumo de memória entre requests;
• corrige problemas de refresh (tecla F5) e botão voltar (back button) do browser;
• resolve problemas de concorrência;
• melhora escalabilidade da aplicação;
• alto consumo de banda da rede;
• maior overhead de cpu no servidor e cliente;
• maior consumo de memória no lado cliente;
• problemas de segurança;
• excelente na fase de desenvolvimento pois conseguimos manter o estado da view mesmo depois de restartar o servidor;
• páginas carregam ligeiramente mais lentas (isso depende muito da complexidade e quantidade de componentes na página);

* Os itens em vermelho indicam as desvantagens

Cada um traz consigo melhorias e problemas em determinados pontos, em alguns pontos há efeito contrário de acordo com o método escolhido, ou seja, se no método “server” algo funciona então pode ser que no método “client” pare de funcionar, e vice-versa. A maioria destes problemas podem ser resolvidos durante o desenvolvimento com algumas boas práticas, configurações, frameworks auxiliares e até truques, como por exemplo,

• pode-se diminuir o consumo de banda com a compactação do estado dos componentes antes de enviar ao cliente (método client);
• pode-se melhorar a segurança da aplicação encriptando o estado dos componentes antes de enviar ao cliente (método client);
• pode-se também diminuir o consumo de memória no lado servidor através de configurações mais detalhadas da framework, utilizando-se de frameworks como Spring-annotation, JBoss-Seam e até componentes como t:saveState do Myfaces-Tomahawk que nos fornecem “escopos” para mantermos os dados entre requests;
• pode-se corrigir o problema do back-button do browser aumentando o número de views por sessão (método server);
• etc

Estes são apenas alguns exemplos de como contornar tais problemas, algumas soluções o JSF já nos fornece com algumas configurações mais específicas, outras necessitaremos de frameworks auxiliares. No final das contas conseguimos contorna-los sem muitas dificuldades.

Então, qual devo usar?

Como podem ver há várias diferenças entre eles, mas dizer qual o melhor método é algo que vai depender muito do tipo de aplicação, quantidade de usuários e acessos, se é intranet ou não, entre outros detalhes do projeto. O ideal é conhecer a diferença entre eles e analisar qual método se encaixa melhor nos requisitos e necessidades do projeto.

Boa parte deste texto foi baseado nas discussões da lista javasf, leituras em blogs, fóruns, wikis, e principalmente nesta excelente apresentação, http://wiki.apache.org/myfaces-data/attachments/Performance/attachments/PerformanceBOFatJavaOne

Espero que esse texto sirva de alguma ajuda aos novatos na tecnologia e até alguns veteranos :))

Tags: back button, client, Java, JavaServer Faces, JBoss, JEE, JSF, method, performance, Seam, server, state saving, state saving method, STATE_SAVING_METHOD, t:saveState, web

This entry was posted on Sunday, October 14th, 2007 at 8:01 pm and is filed under JEE, JSF, Java, JavaScript, web. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.