2016-06-15 2 views
0

J'essaie de comprendre les cas d'utilisation/l'architecture des utilisateurs typiques de CometD pour voir si je suis sur la bonne voie. Voici un diagramme décrivant notre utilisation prévue.CometD: publier à partir du serveur externe

CometD with web services

Nous voudrions que le serveur cometd être plus d'un pub/sous d'événements pour nos services Web, Aucun passera par cometd, seules les données d'événement. Les services Web peuvent publier des événements pour les clients en fonction d'une action qu'ils traitent ou d'un processus processus/planifié en cours.

Mes questions sont basées sur le client Java:

  • Est-ce une utilisation appropriée du client cometd Java? De la documentation, il semble comme le client Java est utilisé pour les applications de la vie à court terme comme applications de bureau.
  • Étant donné le client Java pour CometD, devrions-nous avoir une instance unique ou un pool de clients pour gérer l'envoi d'événements à CometD à partir d'une instance de service Web?
  • Le code client semble assez élaboré pour gérer les messages de lot et plusieurs threads qui l'appellent et il semble que l'établissement d'un client est coûteux à faire à la volée pour publier un message, n'est-ce pas?

Nous vous remercions de votre temps!

Répondre

1

Oui, il s'agit d'une utilisation appropriée du client Java CometD.

Vous pouvez avoir une seule instance du client CometD Java, il est sûr pour une utilisation multithread, ou vous pouvez avoir un client CometD Java pour chaque service Web, probablement l'approche recommandée (comme vous pouvez l'identifier dans le CometD serveur quel Web Service a envoyé quoi).

Notez que le client CometD Java est asynchrone.

Si vous avez besoin d'une réponse ou une confirmation que le message que vous avez envoyé a été traité par le serveur cometd, vous devez être en mesure de suspendre la demande de service Web (via HttpServletRequest.startAsync() ou similaire), appelez le client cometd Java, et quand vous récupérez la confirmation du message pour terminer la réponse du service Web au client.

Vous pouvez obtenir des confirmations à l'aide des rappels dans les API du client Java CometD, voir CometD Java client API documentation. Pour être complet, si vous utilisez un canal de diffusion pour publier un message à partir du service Web, le message sera immédiatement retransmis aux clients distants par le serveur CometD. D'un autre côté, si vous utilisez un canal de service pour publier un message à partir du service Web, vous pourrez traiter le message sur le serveur CometD (et peut-être l'enrichir ou le supprimer selon une logique métier) avant de avoir la possibilité de le retransmettre ou de l'envoyer à un client spécifique.

+0

Génial, merci beaucoup pour l'aide! – Chap