GWT / COMET: Alguma experiência?

Question

Existe alguma maneira de "se inscrever" do GWT para JSON Objects Stream e ouvir eventos de entrada em conexão de manutenção, sem tentar buscá-los de uma só vez? Acredito que o buzzword-du-jour para esta tecnologia é "cometa".

Vamos supor que eu tenha um serviço HTTP que abre conexão de manutenção e coloque objetos JSON com cotações de ações recebidas lá em tempo real:

{"symbol": "AAPL", "bid": "88.84", "ask":"88.86"}
{"symbol": "AAPL", "bid": "88.85", "ask":"88.87"}
{"symbol": "IBM", "bid": "87.48", "ask":"87.49"}
{"symbol": "GOOG", "bid": "305.64", "ask":"305.67"}
...

Preciso ouvir esses eventos e atualizar componentes GWT (tabelas, etiquetas) em tempo real. Alguma ideia de como fazer?

Answer 1

Há um módulo de cometa GWT para StreamHub:

http://code.google.com/p/gwt-comet-streamhub/

StreamHub é um servidor cometa com uma edição comunitária gratuita. Há um exemplo disso em ação aqui.

Você precisará fazer o download do servidor de comets Streamhub e criar um novo SubscriptionListener, usar o exemplo Stockdemo como ponto de partida e, em seguida, criar um novo JSONPAYLOAD para transmitir os dados:

Payload payload = new JsonPayload("AAPL");
payload.addField("bid", "88.84");
payload.addField("ask", "88.86");
server.publish("AAPL", payload);
...

Faça o download do jar no site do Google Code, adicione -o ao seu GWT Projects ClassPath e adicione a inclusão ao seu módulo GWT:

<inherits name="com.google.gwt.json.JSON" />
<inherits name="com.streamhub.StreamHubGWTAdapter" />

Conecte e inscreva -se no seu código GWT:

StreamHubGWTAdapter streamhub = new StreamHubGWTAdapter();
streamhub.connect("http://localhost:7979/");
StreamHubGWTUpdateListener listener = new StockListener();
streamhub.subscribe("AAPL", listener);
streamhub.subscribe("IBM", listener);
streamhub.subscribe("GOOG", listener);
...

Em seguida, processe as atualizações de como você gosta no ouvinte de atualização (também no código GWT):

public class StockListener implements StreamHubGWTUpdateListener {
      public void onUpdate(String topic, JSONObject update) {
          String bid = ((JSONString)update.get("bid")).stringValue();
          String ask = ((JSONString)update.get("ask")).stringValue();
          String symbol = topic;
          ...
      }
}

Não se esqueça de incluir Streamhub-min.js na página HTML principal de projetos GWT.

Answer 2

Eu usei essa técnica em alguns projetos, embora tenha seus problemas. Devo observar que fiz isso apenas especificamente através do GWT-RPC, mas o princípio é o mesmo para qualquer mecanismo que você esteja usando para lidar com dados. Dependendo do que exatamente você está fazendo, pode não haver muita necessidade de complicar demais as coisas.

Primeiro, no lado do cliente, não acredito que o GWT possa suportar adequadamente qualquer tipo de dados de streaming. A conexão deve fechar antes que o cliente possa realmente processar os dados. O que isso significa do ponto de vista do servidor-puh é que seu cliente se conectará ao servidor e bloqueará até que os dados estejam disponíveis, momento em que retornará. Qualquer código executado na conexão preenchida deve reabrir imediatamente uma nova conexão com o servidor para aguardar mais dados.

Do lado do servidor, você simplesmente entra em um ciclo de espera (o pacote concorrente Java é particularmente útil para isso com blocos e tempo limite), até que novos dados estejam disponíveis. Nesse momento, o servidor pode retornar um pacote de dados ao cliente que será atualizado de acordo. Há um monte de considerações, dependendo de como é o seu fluxo de dados, mas aqui estão alguns em que pensar:

• Um cliente é importante para cada atualização? Nesse caso, o servidor precisa armazenar em cache quaisquer eventos em potencial entre o momento em que o cliente obtém alguns dados e depois se reconecta.
• Haverá gobes de atualizações? Se for esse o caso, pode ser mais sábio empacotar várias atualizações e empurrar os pedaços por vez a cada vários segundos, em vez de fazer com que o cliente obtenha uma atualização por vez.
• O servidor provavelmente precisará de uma maneira de detectar se um cliente desapareceu para evitar acumular grandes quantidades de pacotes em cache para esse cliente.

Descobri que havia dois problemas com a abordagem de push do servidor. Com muitos clientes, isso significa muitas conexões abertas no servidor da Web. Dependendo do servidor da Web em questão, isso pode significar muitos threads que estão sendo criados e mantidos abertos. O segundo tem a ver com o limite típico do navegador de 2 solicitações por domínio. Se você puder servir suas imagens, CSS e outros domínios estáticos dos domínios de segundo nível, esse problema pode ser mitigado.

Answer 3

De fato, existe uma biblioteca do tipo Cometd para GWT - http://code.google.com/p/gwteventservice/

Mas eu não o usei pessoalmente, então não posso garantir que é bom ou não, mas o documento parece muito bom. Vale a pena tentar.

Há alguns outros que eu vi, como Cometd do GWT-Rocket biblioteca.

Answer 4

Algumas idéias preliminares para a implementação do cometa para GWT podem ser encontradas aqui... Embora eu me pergunte se há algo mais maduro.

Answer 5

Além disso, algumas dicas sobre a integração GWT/Comet estão disponíveis lá, usando uma tecnologia de borda ainda mais cortando e corta: "Continuações de Jetty". Vale a pena dar uma olhada.

Answer 6

Aqui Você pode encontrar uma descrição (com algumas amostras de origem) de como fazer isso para o IBM WebSphere Application Server. Não deve ser muito diferente com o Jetty ou qualquer outro servidor J2EE habilitado para cometa. Resumidamente, a idéia é: codifique seu objeto Java para a String JSON via GWT RPC e, em seguida, usando o Cometd, envie -o ao cliente, onde é recebido pelo Dojo, que desencadeia seu código JSNI, que chama seus métodos de widget, onde você desapego o objeto novamente usando GWT RPC. Pronto! :)

Minha experiência com essa configuração é positiva, não houve problemas com ela, exceto pelas perguntas de segurança. Não está realmente claro como implementar a segurança para o cometa neste caso ... parece que os servlets de atualização do cometa devem ter URLs diferentes e, em seguida, a segurança J2EE pode ser aplicada.

Answer 7

O projeto JBoss Erai possui um barramento de mensagens que fornece mensagens bidirecionais que fornecem uma boa alternativa ao COMETD.

Answer 8

Estamos usando o Atmosphere Framewrok (http://async-io.org/) para servidorpush/cometa na aplicação GWT.

Em uma estrutura lateral do cliente, possui integração GWT que é bastante direta. No lado do servidor, ele usa um servlet simples.

Atualmente, estamos usando -o na produção com mais de 1000 usuários concorrentes em ambiente em cluster. Tivemos alguns problemas no caminho que precisavam ser resolvidos modificando a fonte da atmosfera. Além disso, a documentação é realmente fina.

A estrutura é gratuita para usar.