GWT / Comet: une expérience?

Question

Existe-t-il un moyen de "souscrire" " des objets GWT aux objets JSON, diffusez et écoutez les événements entrants sur une connexion persistante, sans essayer de les extraire tous en même temps? Je crois que le mot à la mode du jour pour cette technologie est "Comet".

Supposons que j'ai un service HTTP qui ouvre une connexion persistante et place les objets JSON avec les cours entrants en temps réel:

{"symbole": "" AAPL "," enchère ":" 88,84 "," demander ":" 88,86 "}
{"symbole": "" AAPL "," offre ":" 88.85 "," ask ":" 88.87 "}
{"symbole": "IBM", "enchère": "87.48", "ask": "87.49"}
{"symbole": "GOOG", "enchère": "305.64", "ask": "305.67"}
...

Je dois écouter ces événements et mettre à jour les composants de GWT (tableaux, étiquettes) en temps réel. Des idées comment le faire?

Answer 1

Il existe un module GWT Comet pour StreamHub:

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

StreamHub est un serveur Comet avec une édition communautaire gratuite. Vous en trouverez un exemple en action ici .

Vous devez télécharger le serveur StreamHub Comet et créer un nouveau SubscriptionListener, utiliser l'exemple StockDemo comme point de départ, puis créer un nouveau JsonPayload pour diffuser les données:

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

Téléchargez le fichier JAR à partir du site de codes Google, ajoutez-le à votre classpath de projets GWT et ajoutez l'inclusion à votre module GWT:

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

Connectez-vous et abonnez-vous à partir de votre code 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);
...

Traitez ensuite les mises à jour comme vous le souhaitez dans l'écouteur de mises à jour (également dans le code 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'oubliez pas d'inclure streamhub-min.js dans la page HTML principale de vos projets GWT.

Answer 2

J’ai utilisé cette technique dans quelques projets, bien que cela pose des problèmes. Je dois noter que je ne l’ai fait que spécifiquement par l’intermédiaire de GWT-RPC, mais le principe est le même quel que soit le mécanisme que vous utilisez pour gérer les données. Selon ce que vous faites exactement, il ne sera peut-être pas nécessaire de trop compliquer les choses.

Tout d’abord, côté client, je ne pense pas que GWT puisse correctement prendre en charge tout type de données en streaming. La connexion doit être fermée avant que le client puisse réellement traiter les données. Cela signifie que votre client se connecte au serveur et le bloque jusqu'à ce que les données soient disponibles, point auquel elles seront renvoyées. Quel que soit le code exécuté sur la connexion établie, vous devez immédiatement rouvrir une nouvelle connexion avec le serveur pour attendre plus de données.

Du côté du serveur, vous passez simplement dans un cycle d’attente (le package Java concurrent est particulièrement pratique pour cela avec des blocs et des délais), jusqu’à ce que de nouvelles données soient disponibles. À ce moment-là, le serveur peut renvoyer au client un paquet de données qui sera mis à jour en conséquence. Tout dépend de la nature de votre flux de données, mais voici quelques points à prendre en compte:

• Un client qui reçoit chaque mise à jour est-il important? Si tel est le cas, le serveur doit mettre en cache tous les événements potentiels entre le moment où le client obtient des données, puis se reconnecter.
• Y aura-t-il beaucoup de mises à jour? Si tel est le cas, il serait peut-être plus sage de regrouper un certain nombre de mises à jour et de supprimer des morceaux à la fois toutes les quelques secondes, au lieu de laisser le client obtenir une mise à jour à la fois.
• Le serveur aura probablement besoin d'un moyen de détecter si un client est parti afin d'éviter d'empiler de grandes quantités de packages mis en cache pour ce client.

J'ai constaté deux problèmes avec l'approche push du serveur. Avec beaucoup de clients, cela signifie beaucoup de connexions ouvertes sur le serveur Web. Selon le serveur Web en question, cela peut signifier que de nombreux threads sont créés et maintenus ouverts. La seconde a trait à la limite du navigateur typique de 2 demandes par domaine. Si vous êtes en mesure de servir vos images, vos fichiers CSS et tout autre contenu statique à partir de domaines de second niveau, ce problème peut être atténué.

Answer 3

il existe effectivement une bibliothèque de type cometd pour gwt - http://code.google.com / p / gwteventservice /

Mais je ne l’ai pas personnellement utilisé, je ne peux donc pas vraiment dire si c’est bon ou pas, mais le document semble plutôt bon. vaut la peine d'essayer.

Il y en a quelques-uns que j'ai vus, comme du groupe de gwt-rocket bibliothèque.

Answer 4

Vous pouvez trouver quelques idées préliminaires sur la mise en oeuvre de Comet pour GWT ici . bien que je me demande s’il ya quelque chose de plus mature.

Answer 5

De même, des informations sur l’intégration GWT / Comet sont disponibles , , en utilisant même technologie de pointe: "Jetty Continuations". Ça vaut le coup d'oeil.

Answer 6

Ici , vous trouverez une description (avec quelques exemples de sources) expliquant comment procéder pour IBM WebSphere Application Server. Ne devrait pas être trop différent avec Jetty ou tout autre serveur J2EE compatible Comet. En bref, l’idée est la suivante: codez votre objet Java en chaîne JSON via GWT RPC, puis utilisez-le pour l’envoyer au client, où il est reçu par Dojo, ce qui déclenche le code JSNI, qui appelle vos méthodes de widget, où vous désérialisez l’objet. à nouveau en utilisant GWT RPC. Voila! :)

Mon expérience avec cette configuration est positive, elle n’a posé aucun problème, à l’exception des questions de sécurité. Dans ce cas, la manière d’implémenter la sécurité pour comet n’est pas vraiment claire… Il semble que les servlets de mise à jour Comet devraient avoir des URL différentes et que la sécurité J2EE puisse être appliquée.

Answer 7

Le projet JBoss Errai dispose d’un bus de messages qui fournit une messagerie bidirectionnelle qui constitue une bonne alternative à cometd.

Answer 8

Nous utilisons Atmosphere Framewrok ( http://async-io.org/ ) pour ServerPush / Comet. en application GWT.

Côté client, l’intégration GWT est assez simple dans Framework. Côté serveur, il utilise un Servlet standard.

Nous l'utilisons actuellement en production avec plus de 1000 utilisateurs simultanés dans un environnement en cluster. Nous avons eu quelques problèmes sur le chemin qui devaient être résolus en modifiant la source d’atmosphère. De plus, la documentation est vraiment mince.

Framework est libre d'utilisation.