Artigo Java Magazine 49 - Ajax Reverso, a Revolução

Ajax Reverso, a Revolução

Faça o código no servidor acionar o browser

  Na edição anterior apresentamos o framework Ajax DWR (Direct Web Remoting), explorando a maioriade seus recursos. Neste artigo veremos como o DWR permite solicitar a invocação de código JavaScript no browser a partir do servidor – técnica que ficou conhecida como Ajax Reverso, ou Reverse Ajax.

A proposta do DWR

O framework DWR se propõe a facilitar a utilização de Ajax na plataforma Java. Essa facilidade vem através de mecanismos que permitem que trechos de código JavaScript invoquem métodos em objetos Java residentes no servidor. Além dessa iniciado uma requisição. O que ocorre no caso do DWR (e de qualquer outra ferramenta que implemente Ajax Reverso ou recursos similares) é a emulação dessa funcionalidade.

O cliente solicita os dados ao servidor de forma assíncrona, mas a aparência é que o inverso está acontecendo. Para que isso seja possível, o servidor armazena as instruções JavaScript, que devem ser executadas no cliente, em um buffer e o cliente as obtém periodicamente. Após obter as instruções, elas são executadas no cliente, dando assim a impressão de que foi o servidor que iniciou a requisição.

Como é possível?

O DWR implementa três técnicas para realizar o Ajax Reverso. Essas técnicas definem como as solicitações de execução de comandos criadas pelo servidor são obtidas pelo cliente para execução. Veja como funcionam:

• Polling – É a técnica onde de tempos em tempos o cliente realiza uma requisição ao servidor, para verificar se o servidor deseja se comunicar com ele. O intervalo entre uma requisição e outra é muito pequeno. Essa é a técnica empregada no exemplo que veremos nesse artigo.
• Comet – Técnica em que não é finalizada a conexão http com o browser. Após o cliente realizar uma requisição, aconexão é mantida aberta e o servidor continua a escrever os dados nela. O DWR melhora o cenário fazendo com que a conexão dure um período fixo (60 segundos por padrão), abrindo uma nova conexão após esse intervalo. Isso evita que uma queda da conexão (devido a timeout, por exemplo) interrompa a capacidade, que está presente desde a versão 1, a versão 2 do DWR traz como novidade o Ajax Reverso. O Ajax Reverso utiliza uma série de tecnologias, tanto no cliente quanto no servidor, para permitir que dados sejam enviados do servidor para o cliente, sem que este último tenha de solicitá-los explicitamente.

Funcionamento do Ajax Reverso

Quando vemos o Ajax Reverso funcionando, parece que o servidor está invocando código no cliente. Isso não acontece de fato, devido às restrições do protocolo HTTP: é impossível para o servidor http enviar dados sem que o cliente tenha comunicação. Esse pattern tem sérias restrições de escalabilidade por manter uma porta TCP aberta para cada cliente, o que pode levar à ocupação de todas as portas disponíveis na máquina. Em cenários com um baixo número de clientes simultâneos ou onde é possível disponibilizar um grande parque de máquinas de baixo custo em cluster, a técnica Comet pode ser uma opção interessante.

·         PiggyBack – PiggyBack significa “carregar nos ombros”, o que sugere bem o que ocorre nessa técnica. Quando o servidor tem uma requisição a enviar, aguarda que o cliente solicite algum outro dado e aproveita para embutir a requisição na resposta. É a técnica mais complexa e que apresenta a menor responsividade. Porém usa uma estratégia “oportunista”, por isso adicionando menos overhead.

Para que o servidor possa se comunicar com o cliente, é necessário um buffer, que irá armazenar as solicitações a serem enviadas ao cliente até que ele venha buscá-las. Para armazenar os dados em um buffer, o DWR criou o conceito de scripting session ou sessão de script. Uma sessão de script é uma sessão utilizada pela camada JavaScript do DWR e cujo escopo está associado à página corrente. A sessão de script permanece no servidor e possui um identificador único, assim como a sessão HTTP.

Entendendo melhor a sessão de script

Imagine um cenário onde o servidor solicita ao cliente que invoque uma função JavaScript qualquer. Essa solicitação é armazenada na sessão de script. Quando  o cliente se conecta ao servidor (se aindanão estiver conectado), todos os dados da sessão de script são enviados para o cliente.

Podemos associar objetos à sessão de script através dos métodos getAttribute() esetAttribute(). É também possível invalidar a sessão e obter outras informações como verificar se ainda está ativa, etc.

"

ATENÇÃ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!

Saiba como acessar este post através de Créditos DevMedia:

Assinatura de Créditos – Aqui este post custa R$ 1,47
Com esse plano você compra R$ 180,00 em créditos e ganha, em média, 80% de desconto no preço do post.  
Assine agora

Plano ocasional - Aqui este post custa: R$ 1,96 (assinante) ou R$ 2,45 (não-assinante)
Você compra um mínimo de R$ 60,00 em créditos e ganha, em média, 50% de desconto no preço do post.  
Compre agora

Plano conveniência – Neste plano este post custa R$ 4,90
Neste plano você compra somente um post, pagando seu preço sem desconto.  
Compre agora