Comet - ReverseAjax com DWR - Resumo

Handerson Frota – Analista Programador;

Sócio Fundador da Triadworks;

Atualmente Analista Programador da IVIA;

Envolvido na programação desde os 13 anos iniciando com C, web desde 1997 e com Java desde 2001;

Entusiasta Java e Ajax;

Colunista da DevMedia, com artigos e vídeo aulas;

Coordenador e Fundador da Célula Java na Faculdade Lourenço Filho;

Já atuou em vários projetos de médio e grande porte exercendo as funções de: Programador, Analista, Arquiteto e Líder Técnico;

Conceitos Gerais.

O que é COMET ?

Mas quem utiliza COMET ?

Tecnologias.

Recomendações.

Algumas implementações.

COMET ou ReverseAjax ?

Configurando o DWR.

Exemplo de um Chat.

Exemplo de um Relógio.

Exemplo de um Login.

Considerações Finais.

Para falar sobre COMET precisamos antes entender como uma comunicação Ajax funciona; Entender como os conceitos são aplicados; E quais os conceitos aplicados;

Existem 3 maneiras de comunicar utilizando Ajax:

Polling

2. Piggyback

3. Comet

Polling – (Ativo) Quando o navegador(cliente) faz pedidos ao servidor em intervalos regulares e freqüentes. Gerando assim um tráfico extra e pesado na rede.

Servidor você tem alguma atualização pra mim ? SIM  NÃO 

Piggyback – (Passivo) O servidor tendo alguma atualização para o cliente aguarda até que o cliente faça uma nova solicitação, então ele “aproveita” para enviar juntamente com a respostas do cliente a sua atualização. Não gera tráfego extra, em contra partida é muito demorado.

Tenho refrigerante ! Servidor me dê um sanduíche. Receba seu sanduíche e refrigerante.

Comet – (Ativo) O servidor fica responsável em atualizar a qualquer momento o cliente. Uma única conexão é aberta e mantida pelo servidor.

Ele se utiliza basicamente de duas estratégias:

Streaming;

Long polling;

Streaming

O navegador abre uma única conexão persistente

para o servidor para todos os eventos que se

utilizam do COMET.

Quando o servidor envia algum evento a conexão

não é fechada.

2. Long polling O navegador faz um pedido para o servidor, que é mantido em aberto até que o servidor tenha novos dados a ser enviado. Após enviar um evento, o servidor encerra a conexão e imediatamente o navegador abre uma nova.

Seja qual for a técnica, o servidor é capaz de enviar novas informações com baixa latência; Streaming é considerado de melhor desempenho comparado ao Long Polling;

Opa, tenho novas atualizações ! Navegador receba novas atualizações.

Uma aplicação utilizando COMET pode entregar os dados para o cliente a qualquer momento, não apenas na resposta às informações fornecidas pelo usuário(navegador).

Programas de Chat: Gmail, Meebo, Yahoo etc.

Gmail usa para atualizar as conversas por email;

Google Docs usa para exibir as ações de outros colaboradores; Gpokr para jogos on-line; Linkedin, Polar Rose... Dentre outros...

Jetty (Java)

Twisted Python

Grizzly – Glassfish Plugin

Lighttpd

Perbal

Cometd(Bayeux)

mod_pubsub

Lightstreamer

DWR(Java)

Juggernaut(Rails)

Nevow(Python)

O COMET pode ser utilizado em vários tipos de ambientes e plataformas compatíveis. Mas existem determinados frameworks e servidores que tem uma integração maior com ele; Essa integração pode ser em forma de facilidade na codificação, performance dos métodos e facilidade de implementar.

Temos N frameworks e API´s que trabalham com COMET, mas alguns se destacam por todos os parâmetros citados anteriormente. Jetty, DWR e COMETD(Bayeux) são os que mais possuem benefícios para esse método;

Dojo client implementation dojox.cometd.init( serverUrl ); dojox.cometd.publish (“/topic”, {/* payload */} ); dojox.cometd.subscribe( “/topic” , function(){/* ... /* } );

package dojox.cometd; public interface Bayeux { void publish(Client formClient, String toChannel, Object data, String idMsg); void subscribe(String toChannel, Client subscriber); ... }

Collection sessions = context.getScriptSessionsByPage(url); ScriptProxy proxy = new ScriptProxy(sessions); proxy.addFunctionCall( “updateCallers” , call);

Collection sessions = context.getScriptSessionsByPage(url); Effect e = new Effect(sessions); e.fade( “clientId” );

Collection sessions = context.getScriptSessionsByPage(url); Server server = GI.getServer(sessions, “appname” ); Button button = server.getJSXById( “button” , Button.class); Button.setEnabled(Form.STATEDISABLED, true);

Conta corrente: import org.directwebremoting.dwr.Util; Util.setValue(“ contaID ”, 100);

import org...scriptaculous.Effect; Effect.shake(“ contaID ”, 100); Conta corrente:

import jsx3.gui.*; Server s = GI.getServer(“app”); Button b = s.getJSXById(“ id ”, Button.class); b.setEnabled(Form.STATEDISABLED, true); Conta corrente:

import org.dojotoolkit.dijit.Dijit; import org.dojotoolkit.dijit.Editor; Editor e = Dijit.byId(“ contaID ”, Editor.class); e.setValue(200); Conta corrente:

Algumas pessoas fazem essa pergunta: Comet é a mesma coisa de Reverse Ajax ? A resposta é: SIM. O DWR chama a técnica de Comet de Reverse Ajax, e ele utiliza também o Polling e Piggyback. Ele consegue detectar de forma transparente qual tipo de interação por ajax que o cliente está utilizando, deixando transparente para o programador.

Por padrão o DWR começa com o Reverse Ajax(Comet) desligado, permitindo apenas a transferência via Piggyback.

O Reverse Ajax do DWR possui dois modos: Ativo e Passivo.

O Modo Ativo possui ainda mais 3 modos:

Full Streaming(Comet - Streaming)

Early Closing (Comet - Long Polling)

Polling

Para ativar o Reverse Ajax na sua aplicação, é muito simples. São apenas dois passos: 1. Basta acrescentar o treco de código no seu web.xml. Com isso você ativa o Reverse Ajax.

2. Depois de ativado no web.xml, agora no segundo passo você vai definir qual a página que vai se utilizar do Reverse Ajax. Basta acrescentar na sua página a seguinte linha de código: Você poderá adicionar no onload da página ou no início de um arquivo JS, ou apenas como Script na página.

Este é o modo padrão quando o Reverse Ajax é ativado para as versões 2.0.3 e anteriores. A partir da versão 2.0.4 o padrão é a Early Closing. Ele tem como características respostas mais rápidas, porque ele fecha a conexão apenas uma vez a cada 60 segundos, ou verifica se o browser ainda está ativo.

Para ativar o modo Full Streaming na versão DWR 2.0.4 em diante, basta seguir as configurações: No web.xml ative o uso de Reverse Ajax.

Ainda no web.xml adicione o seguinte trecho. Depois basta acrescentar na sua página a seguinte linha de código:

No modo Early Closing ele irá manter a conexão aberta assim como na Full Streaming, no entanto ele ocupa apenas a conexão durante 60 segundos, se não houver uma saída para o navegador. Esse modo nas versões DWR 2.0.4 e superiores, não se faz necessária nenhuma configuração adicional. Para as versões 2.0.3 para baixo é preciso adicionar o seguinte trecho.

Neste caso o DWR irá manter a conexão aberta por mais de 500 milissegundos após a primeira saída, depois ele fecha e já solicita o a sua reabertura. Ele faz isso antes de forçar um flush.

Caso este modo esteja sendo utilizado em aplicações com um elevada taxa de transferência de dados(servidor-cliente) se faz necessário em alguns casos aumentar o tempo de conexão aberta com o servidor. Bastando alterar o valor no maxWaitAfterWrite = 1000 ou Mais, dependendo da sua necessidade.

Se por algum motivo você deseje utilizar essa técnica, também é bem simples configurar. Além da configuração padrão: web.xml(activeReverseAjaxEnabled=true) é preciso adicionar dois init-params, veja a seguir:

Você deve definir o PollingServerLoadMonitor. No modo Polling o default é de 5 segundos, mas é recomendado que você altere esse valor, pelo menos para 60 segundos. Isso para as versões DWR 2.0.3 em diante.

Neste exemplo iremos simular um chat simples. Apenas para exemplificar o uso do Reverse Ajax com DWR e ver como é simples o seu uso.

No exemplo a seguir vamos ver um exemplo de um relógio que servirá para qualquer usuário conectado ao servidor.

No exemplo a seguir, vou demonstrar mais uma utilidade para o Reverse Ajax com DWR. Não teremos nenhuma validação, iremos acessar dois browser(IE e Firefox) e mostrar o seu funcionamento.

Como vimos o DWR tem um excelente suporte a Reverse Ajax(Comet) em geral. Bem simples de se utilizar, fácil de configurar e robusto. O DWR 3.0 promete muito mais, com novas features, suporte a Rest, melhor integração com Spring, suporte ao Google Gears e Dojo Offline,Aptana Jaxer, OpenAjax, PubSub, Bayeux etc.