pace=0 src="/loja/img/capa_java49_G.gif" border=0>
yle="FONT-SIZE: 10pt; FONT-FAMILY: Verdana">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.
A sessão de script é representada pela interface org.directwebremoting.ScriptSession. O método mais importante dessa interface é o addScript(), que recebe uma instância de org.directwebremoting.ScriptBuffer. A classe ScriptBuffer atua como buffer das instruções e dados para invocação de scripts no cliente. A Figura 1 ilustra a interface e a classe.
Figura 1. Interface ScriptSession e classe ScriptBuffer.
Repare que os métodos sobrecarregados appendData() da classe ScriptBuffer permitem adicionar vários tipos de dados ao buffer. Esses dados geralmente são os parâmetros do script que foi adicionado através do método appendScript(). Ao utilizar a versão appendData(Object), podemos informar objetos e coleções como parâmetros que, se associados a um conversor no dwr.xml, serão convertidos em suas representações JavaScript quando enviados para o cliente.
Vistos os elementos básicos, já podemos começar a usar a técnica de Ajax Reverso com o DWR em um exemplo prático.
Construindo um Home Broker com Ajax
Reverso
Para demonstrar o Ajax Reverso, vamos construir uma aplicação capaz de mostrar cotações de ações em tempo real – comumente chamada de “Home Broker”. As cotações serão fictícias, porém o exemplo permitirá mostrar como é útil o recurso de envio de informações para o cliente a partir do servidor.
Instalando o exemplo
O projeto de exemplo está disponível para download no site da Java Magazine, sendo oferecido como um WAR dentro de um ZIP. Utilizaremos o Eclipse com o WTP e um container web. Para este último, recomendamos o Apache Tomcat em sua versão 5.5 ou mais recente. Como base de dados utilizaremos o MySQL 5, cujo driver JDBC já está no ZIP. Extraia o arquivo mysql- connector-java-
No Eclipse, importe o projeto jmbroker. war, usando File|Import>Web>WAR. Utilize o nome do projeto como o contexto da aplicação (“/jmbroker”) e na tela seguinte não selecione nenhum dos JARs para que sejam criados como projetos. A estrutura criada deverá ser similar à da Figura 2.
Figura 2. Estrutura do projeto.
Arquitetura
A Figura 3 ilustra a arquitetura da aplicação. Uma ação é denominada “Papel” no exemplo. Esse termo é comum no mercado financeiro e nos ajuda a evitar confusões com a palavra “Ação”, muito usada em aplicações web. Veja a seguir os principais pacotes que compõem a aplicação e o conteúdo de cada um:
· br.com.jm.dwr – Classes usadas por todos os outros componentes.
· br.com.jm.dwr.web – Classes da camada web.
· br.com.jm.dwr.service – Classes que armazenam a lógica de negócio.
· ...
