AJAX Reverso baseado em Comet com DWR Aprenda a trabalhar com o AJAX Reverso, técnica ainda pouco explorada que proporciona aos sistemas Web a funcionalidade de atualizar os clientes conforme o servidor tem seu estado modificado. O Comet é uma das formas de desenvolvimento do AJAX Reverso, tecnologia na qual o cliente Web não precisa realizar as tradicionais requisições para que o servidor responda a informações atualizadas. Este fator promove uma aproximação ao modelo ideal de transações de informações em que todos os clientes envolvidos em uma mesma aplicação podem manter-se atualizados desde a primeira modificação de conteúdo. Este artigo descreve a utilização da tecnologia Comet, implementada pelo framework DWR, aplicada em um software de leilão virtual como exemplo. om a evolução da internet, as aplicações Web tornaramse comuns no cotidiano. Hoje, muitas das aplicações Desktop são portadas para a Web devido a sua praticidade e facilidade de utilização, já que dispensa a instalação e grande parte da configuração. Dentre as várias tecnologias utilizadas para portar as aplicações para Web, o AJAX já tem seu espaço garantido. O AJAX possibilita que sejam carregados apenas os componentes solicitados pelo usuário, e não a página completa como no método tradicional de requisição e resposta. Com isso, o usuário ganha em desempenho, interatividade e menor sobrecarga no servidor. No AJAX Reverso, o servidor fica responsável em atualizar o cliente (usuário), já que o usuário não precisa fazer nenhum tipo de requisição para que o servidor envie uma resposta. Este artigo tem como objetivo demonstrar a criação de um leilão virtual, onde cada usuário dará um lance e será mostrado apenas o maior. Será desenvolvido com tecnologia JavaServer Faces, além da utilização do Framework DWR para implementar a função do AJAX Reverso. Quando o maior lance for enviado, o servidor é responsável em atualizar todos os usuários, sem que eles façam uma requisição para isso. Para melhor entendimento do artigo, sugere-se conhecimentos na arquitetura cliente/servidor utilizada na Internet, assim como da tecnologia AJAX, porém todos os conceitos são revisados. O presente artigo está organizado da seguinte forma: primeiramente, será explicado sobre o AJAX e como ele mudou o modelo tradicional da Web (requisições/respostas). Em seguida, será contextualizado o AJAX Reverso e, principalmente, o Comet junto com os frameworks que possibilitam sua implementação. Ao final, será apresentado um exemplo de como implementar o Comet com o framework DWR e um exemplo com JSF. 40
Sylvio Barbon Junior (sbarbonjr@gmail.com): é formado em Engenharia e Ciência da Computação, mestre em Física Computacional e atualmente doutorando em Fisíca Computacional pelo IFSC/ USP. Realiza trabalhos como consultor Java no interior do Estado de São Paulo. Possui certificação SCJP, é docente na Universidade do Estado de Minas Gerais (UEMG) e na FATEC de São José do Rio Preto. Junto com outros colaboradores mantém o site http://www.patternizando.com.br, para a discussão de desenvolvimento de software. Thiago Aranega Colebrusco (thiagocolebrusco@gmail.com): graduado em Tecnologia em Informática para Gestão de Negócios pela FATEC de São José do Rio Preto. Cursa especialização em Consultoria Web também pela FATEC Rio Preto. Trabalha como analistadesenvolvedor pela Net-Fit e também é colaborador do http://www.patternizando.com.br. Lucas Fernandes Colebrusco (colebrusco@gmail.com): formado em Tecnologia em Informática para Gestão de Negócios pela FATEC de São José do Rio Preto. Atualmente, cursa especialização em Consultoria Web pela mesma instituição. AJAX A tecnologia AJAX (Asynchronous Javascript And XML) é uma das maiores aliadas na aproximação entre o ambiente Web e o Desktop. O conceito de AJAX foi criado por Jesse James Garrett em um artigo on-line publicado em fevereiro de 2005. Com o AJAX, é possível que o navegador carregue conteúdo do servidor sem recarregar a página completamente. Apenas os componentes requisitados pelo cliente são carregados, evitando um grande uso de tráfego de dados e melhorando o desempenho das aplicações e tornando-as mais rápidas e próximas das aplicações Desktop. Além disso, este permite que várias requisições sejam feitas simultaneamente, trabalhando em cada parte da página, propiciando ao usuário maior agilidade e facilidade na utilização do sistema aderindo melhor aos requisitos de usabilidade. O AJAX consiste em requisições assíncronas manipuladas no cliente por meio de JavaScript, nas quais o mesmo provê o tratamento da requisição ao servidor e reposta de forma a ajustar o conteúdo recebido sem a necessidade de uma total atualização da página. Assim, o AJAX faz com que as interfaces das aplicações Web se tornem semelhantes às das aplicações Desktop. O AJAX tem como objetivo maximizar a interação entre os usuários e as aplicações Web, tornando-as mais simplificadas e com ganho em desempenho. Com isso, uma das maiores vantagens das aplicações Web que utilizam o AJAX é que todas as requisições e respostas são tratadas por JavaScript, que é responsável por atualizar partes específicas da página a partir da resposta e, para utilizálo, é necessário apenas possuir um dos navegadores atuais já que oferecem suporte a essa tecnologia, como, por exemplo, Mozilla Firefox, Internet Explorer, Google Chrome, Opera ou Safari. Figura 2. Modelo baseado em AJAX. Figura 3. Modelo baseado em Comet. A comparação entre as figuras 1 (Modelo tradicional) e 2 (Modelo baseado em AJAX) apresenta claramente a diferença entre uma conexão feita com as requisições tradicionais (sempre precisando de uma requisição para que o servidor possa responder) e uma conexão feita com AJAX (o servidor pode enviar a resposta de forma assíncrona). Na figura 3, é apresentado um modelo no qual o cliente não requisita atualização, porém, conforme demanda (evento) do servidor é realizada uma transferência de informação. Outro detalhe a ser observado na figura 3 é que a ligação entre cliente e servidor é mantida pelo Comet, sendo transparente ao cliente o uso do mesmo. Com o Comet, aplicações que atualizam dados continuamente como salas de bate-papo Web, por exemplo, podem se beneficiar de menor carga nos servidores. Figura 1. Modelo tradicional síncrono para Internet. Na figura 1, pode-se observar que existe um evento chamado de 41
CLICK para disparar uma requisição que será contemplada com uma resposta atualizada do servidor. O exemplo de uma sala de bate-papo, para o caso do modelo sem AJAX exigiria um evento do cliente, tal qual um click de botão ou a solução tradicional dos refreshs (atualizações) periódicas de todo o seu conteúdo. Já para o caso da figura 2 uma área específica poderia ser atualizada com as técnicas comentadas na figura 1, no entanto a exigência de um evento seria mantida. AJAX Reverso Diferenciando-se um pouco do AJAX comum, com o AJAX Reverso o servidor é capaz de enviar informações ao cliente sem que o mesmo tenha feito uma requisição. É realizada uma conexão diferenciada com o servidor, permitindo-o enviar respostas aos clientes sem que estes tenham que fazer novas requisições. Esse tipo de comunicação cliente-servidor pode ajudar muito os sistemas Web a ficarem mais dinâmicos e com maior usabilidade, além de garantir que a informação seja mostrada ao cliente em tempo real. Há três maneiras de implementar o AJAX Reverso, são elas: Polling, Piggyback e Comet. consiste em o cliente, em intervalos de tempo frequentes e regulares, perguntar ao servidor se há alguma nova atualização. Mesmo não havendo nenhuma informação ao cliente, gera tráfego e processamento desnecessários no servidor. Isso apenas simula a técnica do AJAX Reverso, já que mesmo que feito de forma pré-programada, o cliente faz requisições constantes ao servidor. um pouco mais interessante que o Polling, pois quando o servidor, por exemplo, tiver que enviar ao cliente uma mensagem, ele espera o cliente fazer uma nova requisição e, junto com a resposta, envia a nova mensagem, gerando menos tráfego que o Polling. Essa técnica não é adequada quando o usuário precisa da informação com urgência, pois o servidor aguarda uma nova requisição para enviar as informações junto com a resposta. abre uma conexão com o servidor e a deixa aberta para que o mesmo possa enviar as informações quando necessário. O Comet será mais bem abordado no próximo tópico. Os frameworks que suportam o AJAX Reverso, em sua maioria, dão a possibilidade de trabalhar utilizando as três técnicas individualmente ou até mesmo simultaneamente. Comet Comet é uma das maneiras de implementar o AJAX Reverso gerando menor tráfego e processamento já que o cliente vai receber a mensagem apenas quando ela estiver disponível. Em outras palavras, sem o Comet, o cliente teria que fazer as requisições a cada período fixo de tempo. Se forem curtos, o servidor pode sobrecarregar e, se forem longos, as atualizações podem estar atrasadas, já que o cliente não vai ter acesso à informação assim que disponível. Basicamente, o Comet pode ser dividido em duas formas: utiliza conexões HTTP de longa duração e quando a informação estiver disponível será enviada, fechando a conexão com o servidor. O cliente receberá a informação e abrirá uma nova conexão para aguardar o próximo envio do servidor. O grande problema é que pode gerar excesso de processamento nas aberturas e fechamentos das conexões. o navegador abre uma conexão com o servidor e é mantida aberta mesmo após o envio de cada informação. A vantagem é que o servidor consome muito pouco recurso para que essa conexão fique aberta, mas caso haja uma queda na conexão, poderá haver algum atraso nas informações, pois o servidor terá que abrir uma nova conexão. Em ambas as formas do Comet, o servidor é capaz de enviar novas informações ao cliente assim que disponível, gerando menos tráfego e processamento desnecessário. No entanto, quando o tipo de conteúdo disponibilizado pelo servidor não requer o broadcast da informação, ou seja, não precisa de sincronização de todos os clientes em tempo real, o custo de manter ativas as ligações com o servidor podem comprometer o desempenho do mesmo. O desempenho do servidor é comprometido uma vez que a ligação com cada cliente é mantida por uma thread ativa, ou seja, a troca de informações com o cliente aloca recursos de processamento e sincronização que pode comprometer a escalabilidade da aplicação. Para Saber Mais A edição 14 da MundoJ traz o artigo AJAX Desenvolvendo uma Web mais interativa. No qual se apresenta conceitos desta tecnologia, como também usos e vantagens. A edição 22 da MundoJ também trouxe diversos artigos que exploraram diferentes questões sobre o assunto, como desempenho e segurança. Na edição 31, o artigo Grizzly e Comet AJAX Reverso com Escalabilidade demonstra a criação de uma aplicação utilizando o AJAX Reverso. Frameworks que implementam o Comet Para implementação do AJAX Reverso, existem alguns frameworks que permitem essa funcionalidade. Segue uma pequena descrição de alguns deles: é um framework Open Source desenvolvido em Java e Javascript com o objetivo de facilitar o acesso a uma classe Java que utiliza o AJAX. Com ele, a comunicação via AJAX de uma classe Java é feita de maneira simples, pois é possível executar os métodos destas classes dentro do próprio Javascript utilizando apenas uma linha de código. Isso facilita a chamada de Javascript para Java e viceversa. O DWR é capaz de integrar-se a vários frameworks Java e Javascript, além de ser totalmente compatível com o AJAX Reverso. Ele também implementa o AJAX de forma cross-browser (funciona em vários browsers) e é o que será utilizado neste artigo por motivos de estabilidade, documentação ampla e integração com JSF de forma simples. o Atmosphere é Open Source e baseado no framework POJO utilizando Inversão de Controle (IoC) com o objetivo de simplificar a criação de aplicações em Comet para 42
que mesmo pessoas não muito experientes possam desenvolver suas aplicações. Tem como característica sua simplicidade e é o primeiro framework capaz de ser executado em vários servidores Java Web-Based que suportem a especificação Servlet 2.3, como, por exemplo, Tomcat, Jetty, GlassFish, Weblogic, Grizzly, JBossWeb e JBoss, Resin etc. é um framework Open Source que permite que sejam desenvolvidas aplicações com interfaces ricas para a Web, reduzindo o tempo que seria gasto já que é necessária pouca programação. O ZK conta com uma equipe bastante prestativa para ajudar os usuários que têm dúvidas e uma de suas maiores características é a simplicidade. Além de ser totalmente compatível com o AJAX Reverso, o ZK tem facilidade na integração com outros frameworks e tem uma documentação muito bem detalhada. Implementação do projeto com DWR (Direct Web Remoting) Para demonstrar o uso do DWR em um projeto, foi desenvolvida uma aplicação-exemplo que consiste em um leilão virtual em que cada usuário cadastra o seu lance e automaticamente tem o valor replicado para todos os clientes presentes no mesmo evento. Configuração do DWR Como dito anteriormente, o DWR é um framework Java que permite a interatividade entre navegador e servidor e suas respectivas requisições de forma simples. Para utilizá-lo em um projeto é necessário usar a biblioteca dwr.jar (neste artigo foi utilizada a versão 3 RC1). Outra biblioteca necessária é a Apache Commons, incorporada ao projeto através do arquivo commons-logging.jar, sendo que a versão utilizada foi a 1.1.1, última até a edição desta revista. Esta última biblioteca é pré-requisito para obter as informações sobre o estado da aplicação em tempo de execução. Vale à pena ressaltar que alguns problemas já relacionados à versão 2.0 do DWR têm solução prevista na versão 3.0 que ainda está na situação de Release Candidate. Todas as configurações do DWR, como padrão, são realizadas no arquivo dwr.xml que deve estar no diretório WEB-INF da aplicação Web. Este arquivo por padrão tem a seguinte estrutura apresentada na Listagem 1. Onde o arquivo dwr.xml tem as seguintes sessões: - <allow> define quais classes serão utilizadas e quais são os filtros que estão ativos para o projeto atual; - <create> a classe que tenha métodos baseados na implementação AJAX do DWR precisará especificar seu criador e método Javascript; - <convert> é a tag que especifica todos os parâmetros que podem ser convertidos. Uma vez que estamos falando de requisições HTML, todo conteúdo trocado é baseado em texto, assim operações de conversão devem ser realizadas. Muitas conversões já são automáticas, como, por exemplo, tipos primitivos e suas classes wrapper, String, Date inclusive Collections. No entanto, existe a possibilidade de especificação de conversão, inclusive de novos tipos; - <signatures> o dwr utiliza reflexão para implementar o processo de conversão. Quando a informação sobre a conversão Listagem 1. Implementação dwr.xml padrão. <!DOCTYPE dwr PUBLIC -//GetAhead Limited//DTD Direct Web Remoting 3.0//EN http://directwebremoting.org/schema/dwr30.dtd > <dwr> <allow> <filter class=... /> <create creator=... javascript=... /> <convert converter=... match=... /> </allow> <signatures>... </signatures> </dwr> Listagem 2. Implementação dwr.xml utilizada no projeto. <?xml version= 1.0 encoding= UTF-8?> <!DOCTYPE dwr PUBLIC -//GetAhead Limited//DTD Direct Web Remoting 3.0//EN http://getahead.org/dwr//dwr30.dtd > <dwr> <allow> <create creator= new javascript= LanceMB > <param name= class value= LanceMB /> </create> </allow> </dwr> não está disponível, a composição da assinatura auxilia no processo de conversão indicando quais são os tipos a serem convertidos baseados no tipo assinado. Para o projeto desenvolvido para este artigo, o dwr.xml foi configurado conforme a Listagem 2. 43
Configuração do aplicativo Web Conforme definido o dwr.xml, é necessário configurar o Servlet do DWR. Para isso, basta acrescentar a codificação conforme a Listagem 3. Nesta listagem também é possível verificar que o Seu Nome: Melhor Lance ---------------- Dono do Lance ---------------- Seu Lance Figura 4. Cadastro de lance. Listagem 3. Implementação web.xml com dwr. <servlet> <servlet-name>dwr-invoker</servlet-name> <servlet-class>org.directwebremoting.servlet.dwrservlet</servlet-class> <init-param> <param-name>activereverseajaxenabled</param-name> <param-value>true</param-value> </init-param> </servlet> <servlet-mapping> <servlet-name>dwr-invoker</servlet-name> <url-pattern>/dwr/*</url-pattern> </servlet-mapping> <listener> <listener-class>org.directwebremoting.servlet.dwrlistener</listenerclass> </listener> Um detalhe importante foi a necessidade da inserção da classe DwrListener. Sem a mesma, o projeto era renderizado, porém o servidor capturava algumas exceções do tipo NullPointerException em eventos assíncronos. Com a declaração do listener citado, a exceção foi solucionada. Implementação do exemplo com JSF Página xhtml A próxima etapa envolve a configuração das páginas que farão parte do mecanismo AJAX proposto. Como já comentado, o projeto proposto do leilão deverá manter atualizados todos os clientes a cada lance. O procedimento é: na tela principal o participante preenche o seu nome e realiza o lance, como na figura 4. Para a implementação da página, foi utilizada a implementação 2.0 do JSF e seus componentes AJAX, porém a mesma não é prérequisito para utilização do DWR. Para Saber Mais A edição 42 da MundoJ traz o artigo Frameworks RIA para JSF lado a lado Entrada de Dados. Onde são descritas as diferenças não só nos componentes de entrada de dados como descrito no título, mas também a instalação dos frameworks utilizados neste artigo e sua compatibilidade de navegadores. A codificação da página para entrada e exibição dos lances, conforme mostrado na figura 4, está disponível na Listagem 4. Alguns pontos devem ser observados com relação ao código da Listagem 3, entre eles, o atributo onload que, ao capturar o evento de carregamento da página, executa a função fnconload(). Esta é a função que define o comportamento de AJAX Reverso para as requisições desta página, ou seja, acrescenta o cliente na lista de atualizações por parte do servidor. Portanto, é imprescindível a associação do body ao método: dwr.engine.setactivereverseajax(true); Outras implementações necessárias são as importações dos scripts engine.js e utils.js, que são utilizadas para encapsular a interface gerada dinamicamente e trazem também uma lista de funções para atualização das informações via Javascript. A última importação relevante ao uso do DWR é a da interface criada dinamicamente a partir da classe habilitada a manipular as requisições. Essa classe é gerada pelo DWR apenas virtualmente, estando disponível para o servidor enquanto a aplicação estiver ativa. Tal classe foi configurada no dwr.xml, conforme Listagem 2. As importações comentadas estão em destaque na Listagem 5. Listagem 5. Importações necessárias para utilização do DWR. requestcontextpath/dwr/interface/lancemb.js > requestcontextpath/dwr/engine.js > requestcontextpath/dwr/util.js > 44
Listagem 4. Configurando a ativação do AJAX Reverso na página. <?xml version= 1.0 encoding= UTF-8?> <!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN http://www.w3.org/tr/xhtml1/dtd/xhtml1-transitional.dtd > <html xmlns= http://www.w3.org/1999/xhtml xmlns:h= http://java.sun.com/jsf/html xmlns:f= http://java.sun.com/jsf/core > <h:head> <title>ajax Reverso MundoJ</title> requestcontextpath/dwr/interface/lancemb.js > requestcontextpath/dwr/engine.js > requestcontextpath/dwr/util.js > <script type= text/javascript > function fnconload() { dwr.engine.setactivereverseajax(true); function receberlance(melhorlance, donolance) { dwr.util.byid( melhorlance ).innerhtml = melhorlance; dwr.util.byid( donolance ).innerhtml = donolance; function darlance() { var nome = dwr.util.getvalue( nome ); var valor = dwr.util.getvalue( valor ); LanceMB.enviarLance(nome, valor); </h:head> <h:body onload= fnconload(); > <h:form prependid= false > <center> <h:panelgrid columns= 1 > <h:outputtext value= Melhor Lance /> <h:outputtext value= ------------ id= melhorlance /> <h:outputtext value= Dono do Lance /> <h:outputtext value= ------------ id= donolance /> </h:panelgrid> <h:panelgrid columns= 5 > <h:outputtext value= Seu Nome: /> <h:inputtext id= nome /> <h:outputtext value= Seu Lance /> <h:inputtext id= valor /> <f:ajax immediate= true > <h:commandbutton value= Dar Lance! onclick= darlance(); /> </f:ajax> </h:panelgrid> </center> </h:form> </h:body> </html> Para a troca de mensagens com o servidor, foram criados os métodos receberlance() e darlance(). A primeira função atualiza as respectivas regiões da página-cliente com os valores recebidos como parâmetro da engine DWR, que por sua vez recebeu os dados, no caso deste projeto, de um ManagedBean JSF2.0. Já a função darlance() invoca a interface LanceMB e utiliza o método enviarlance() encaminhando ao ManagedBean os parâmetros nome e valor do lance enviados por meio da página-cliente. Implementação do exemplo com JSF Managed Bean A codificação da ManagedBean LanceMB pode ser verificada na Listagem 6, onde se observa a implementação do método enviarlance(string nome, String valor). Com relação à codificação desta ManagedBean, algumas considerações podem ser feitas. Para a integração com o DWR foram utilizadas duas classes: Browser e ScriptSessions. Estas possibilitam a detecção e troca de mensagens entre o servidor e o cliente A primeira delas é a classe que executa o trabalho de fazer a ligação entre as páginas e as classes no servidor, definindo através de seus métodos quais páginas devem ser vinculadas por aquela chamada. Já a classe ScriptSessions é a que realiza o trabalho de passar valores do servidor para a página escolhida, seja chamando funções ou apenas definindo atributos. O escopo escolhido para a ManagedBean foi o @ViewScoped, pois associa o ciclo de vida da ManagedBean ao da página de origem das requisições. Vale ressaltar que não é necessário utilizar o JSF para utilização do DWR, a seleção desta tecnologia foi apenas para demonstrar a técnica do AJAX Reverso com outra tecnologia que promove o foco do projeto nos eventos da camada view. Listagem 6. Classe ManagedBean LanceMB. import javax.faces.bean.managedbean; import javax.faces.bean.viewscoped; import org.directwebremoting.browser; import org.directwebremoting.scriptsessions; @ManagedBean(name = lancemb ) @ViewScoped public class LanceMB implements java.io.serializable { public void enviarlance(string nome, String valor) { try { final String melhorlance = valor; final String donolance = nome; Browser.withCurrentPage(new Runnable() { @Override public void run() { ScriptSessions.addFunctionCall( receberlance, melhorlance, donolance); ); catch (Exception e) { throw new RuntimeException(e); 45
Na figura 5 é ilustrado o lance de um participante, chamado Participante 1, junto com mais dois participantes. O participante 1 foi simulado no navegador Google Chrome, sendo os outros dois Figura 5. Simulação de lance na implementação de leilão. O download do projeto pode ser feito a partir da página: participantes simulados no FireFox e Internet Explorer, respectivamente. http://www.patternizando.com.br/ajax-reverso-baseado-emcomet-com-dwr Considerações finais São conhecidas outras formas de implementação que tentam alcançar a mesma funcionalidade de deixar os clientes no mesmo estado que o servidor, como nos refreshs automáticos ainda muito utilizados. Porém, esse tipo de técnica pode ser ineficaz pelo alto consumo de banda ou algum atraso na atualização das informações. A implementação do Comet pode ser feita em diversas linguagens de programação. Na linguagem Java, existem vários frameworks disponíveis no mercado capazes de auxiliar o desenvolvedor a alcançar esse objetivo. Utilizando o DWR, essa implementação se torna fácil, pois é necessário apenas incluir sua biblioteca no projeto e algumas configurações básicas, que são comuns em qualquer framework utilizado. Para produzir este artigo, esperava-se que fosse possível utilizar o framework Primefaces, que além de ser um conjunto de componentes AJAX utilizado para aplicações RIA, possui a funcionalidade de AJAX Reverso. Mas ainda há uma instabilidade nessa funcionalidade do Primefaces, que deve ser corrigida na versão 2.3, planejada ainda para o começo de 2011. Espera-se que a nova versão venha com essa instabilidade solucionada, já que a combinação dessas funcionalidades em apenas um framework seria muito útil para os desenvolvedores, possibilitando até um novo estudo abordando essa implementação. Destacando novamente que o DWR tem para sua versão 3.0 uma proposta de solução para seus problemas de escalabilidade, e atualmente a 3.0 está em Release Candidate. O Comet tende a ser mais utilizado nas aplicações em geral, já que trata as requisições de forma diferente do padrão Web e que mais frameworks tenham total compatibilidade com o AJAX Reverso, o que resulta em novas possibilidades de codificação para os desenvolvedores. Referências GUJ Discussões sobre o tema do artigo e assuntos relacionados Discuta este artigo com 100 mil outros desenvolvedores em www.guj.com.br/mundoj 46